Wenn es um IOS und OSX geht, was mt "allem" kommunizieren soll, sollte man nicht (mehr) auf BT Classice/Standard setzen. BLE funktioniert ab IOS7 auf allen halbwegs aktuellen Apple Geräten nun völlig lizenzfrei.
Hier mal kurz meine Erfahrung für die "Hardwareseite", also die BLE Integration in eigene Geräte für kleine bis mittlere Stückzahlen:
- wir hatten APP Ingenieure von Cypress und Nordic im Haus. Das PsoC-Konzept von Cypress müsste man mögen, wir hätten uns für den ARM basierten CombiCip von Nordic entschieden, ABER...
- alleine schon wegen der kompletten (Funk)Zulassung wurden von uns dann doch "BLE Chips", wo wir Antenne samt Anpassung selbst auf der Platine machen müssten, ausgeschlossen
- bei den Modulen, ging der Ärger dann weiter, da wir im eigenen Prozessor nix vom BLE Stack haben wollten, um BLE so auch mit existierenden kleinen 8Bit Controlern noch einsetzen zu können und auch Zulassungstechnisch in keinerlei Abhängigkeiten zwischen BLE-STACK und unseren Code zu bekommen, bzw. bei Updates beachten zu müssen
- stromsparend, voll freikonfigurierbare GATT-Services und Charateristics und optimale BLE Kompatibilität von Android4.4+, IOS7+, OSX10.10+, Win81+... das waren und sind unsere Anforderungen, weil wir im Hotelbereich Türen damit öffnen und quasi in Kontakt mit allen möglichen Gäste-Smartphones kommen können...
- wir haben uns aus wenige Auswahl dann für ein von MicroChip hergestelles und supportetes BLE-Modul entschieden, was man minimal mit 3 Leitungen (RX,TX,Wakeup) auch mit Batteriegeräten oder sogar StandAlone verwenden kann...
http://www.microchip.com/wwwproducts/en/RN4020
Unsere Technik und unser Einkauf ist bei Preisen um 5Eur/USD und sofortiger Verfügbarkeit "überall" und "immer" (Microchip,Future,Mouser,Farnell,...) auch soweit zufrieden. Wir haben nun schon ein paar tausend dieser Module verbaut und ausgeliefert. Schön war das auch das BLE-Firmwareupdate "OverTheAir" was diese Module Standalone integriert haben funktioniert hat, ohne das wir selbst da ausser dem Aktivieren des OTA-Mode etwas in den Geräten programmieren mussten.
Auf APP oder PC Seite verwenden wir ein eigenes gesichertes eventbasiertes Blockprotokoll mit 17Byte PayLoad und kommen so mit den 20Bytes per BLE-Transfer gut aus. Da wir nur mit unseren eigenen Apps bzw. mit von uns vertriebenen
SDK's kommunizieren, wollten wir binären Datentransfer und legten so absichtilich keinen Wert auf Kompatibilität zu bekannten BLE-StandardServices(Geschwindigkeit, Blutdruck,Puls,Batterie oder änliches)
Wir kommunizieren sowohl mit Swift(XCode),Java(AndroidStudio) als auch Delphi(XE8u1+) mit den verschiedensten BLE Geräten und konnten bis auf die leider nicht ganz 100% normgerechte Sendeleistung der RN4020 Module, welche so keine zuverlässige Entfernungsberechnung aus dem RSSI zulassen, keine Nachteile der "geschlossenen" Modulsoftware feststellen. Kompatibilität und Funktionssicherheit im realem Einsatz sind gut, und im Verhältinis zum quasi nicht vorhandenem Entwicklungsaufwand zur BLE-Hardware-Integration überragend.
Mit der Kombi aus Nordic+ARM mit separatem eigenständigem BLE-Core könnte man sicher noch ein paar Dinge optimieren, aber leider hat sich das für uns kaufmännisch nicht gerechnet, obwohl ich fachlich gerne mit dem aktuellem Wissen einiges optimieren und probieren würde... bei uns war&ist das RN4020 also "nur" eine gute Vernuftentscheidung, die zufällig sogar sehr gut funktioniert
