Bluetooth Low Energy Delphi 6

[v2afrank]

Danke für Eure Antworten.
Also unsere Anwendung soll ausschließlich unter Windows mit verschiedenen Empfängern kommunizieren wobei immer mal wieder ein Scan gemacht wird und sich mit den entsprechenden Devices verbunden wird. Also ziemlich dynamisch.
Die Empfänger sind dann eben unsere Hardwarekomponenten. Wobei ich momentan sagen würde dass die Anforderung Windows 8 oder höher schon ein KO Kriterium ist. Aber das soll unser Vertrieb entscheiden.
Wo hier anscheinend doch einige Spezialisten sind. BLE kam aus folgendem Grund ins Spiel. Irgendwann soll eine IOS Anwendung geschrieben werden die es den Aplle devices erlaubt mit unserer Hardware zu kommunizieren. Um BT mit IOS zu ermöglichen muss angeblich ein extra Chip verbaut werden oder eben BLE verwendet werden. Diese Extrakosten würden wir uns gerne ersparen. Kann das jemand bestätigen ?

[Valle]

Zitat von v2afrank:

BLE kam aus folgendem Grund ins Spiel. Irgendwann soll eine IOS Anwendung geschrieben werden die es den Aplle devices erlaubt mit unserer Hardware zu kommunizieren. Um BT mit IOS zu ermöglichen muss angeblich ein extra Chip verbaut werden oder eben BLE verwendet werden. Diese Extrakosten würden wir uns gerne ersparen. Kann das jemand bestätigen ?

Wie meinst du das, "extra Chip"? Die iPhones haben selbstverständlich BLE und andere Bluethooth Standards eingebaut. Diese kannst du über die üblichen Entwicklungsmethoden für iOS-Apps ganz normal verwenden und damit Geräte verbinden.

Wenn ihr die Geräte selbst entwickeln wollt, dann müssen die natürlich einen Bluetooth Chip beinhalten. Da muss man sich dann schon zwischen BLE oder "herkömmlichem" Bluetooth entscheiden, da die beiden nicht miteinander kompatibel sind.

Ich bin ein wenig vertraut mit der BLE Produktreihe von Cypress und kann dir sehr empfehlen. Deren BLE Pioneer Kit ist zum Entwickeln und Lernen von BLE ziemlich praktisch. Ein BLE Dongle für Windows Rechner liegt übrigens bei. (Das ist keine Werbung, ich find die wirklich gut )

[v2afrank]

Klar müssen wir einen BT Chip einbauen. Ich bin mir jetzt gerade nur nicht sicher welchen die Hardwarker rausgesucht haben. Von denen kam auch die Aussage mit dem extra Chip. Ich habe mal kurz gegoogelt und es scheint das man den Apple Authentication co-processor einsetzen muss. Es sei den eben man nutzt den LE Moduse

[Valle]

Achso, okay. Soweit ich das verstanden habe, kannst du das SPP-Profil nur nutzen, wenn du diesen Co-Processor einbaust, was wohl einen enormen finanziellen Aufwand darstellen wird.

Mit SPP-Profil sparst du dir natürlich die BLE Bibliotheken für Delphi, denn da nutzt du ja einen Serialport.

Die Frage ist also eher, ob SPP denn das geeignete Profil für eure Anwendung ist. Das mit dem Co-Processor von Apple erscheint mir auch unpraktisch.

[himitsu]

BLE selber ist halt auf die 20 Byte pro Packet beschränkt. Alles was mehr braucht, müßte aufgeteilt und in mehreren Packeten übertragen werden.
BLE ist halt darauf ausgelegt "kleine" Datenmengen schnell und ohne großen Overhead zu übertragen.

Mir war so, als wenn SPP in iOS gesperrt war, abgesehn von ein paar "zertifizierten" Apps, oder so. (MFi Programm)
Aber das war noch zu Zeiten von iOS 6, wenn ich mich Recht erinner ... k.A. was mit iOS 7+ ist.
https://support.apple.com/de-de/HT204387
https://mfi.apple.com/MFiWeb/getFAQ.action

Zitat von Valle:

Die Frage ist also eher, ob SPP denn das geeignete Profil für eure Anwendung ist.

http://www.embedded-expertise.com/bl...ssic-or-smart/

Da ihr eh selber entwickeln wollt?
Wenn ich mal dazu komm, wollte ich mir die süßen Dinger von BlueGiga ansehn.
https://www.bluegiga.com/
Dort war auch nett, dass die den integrierten Microcontroller teilweise offen haben und man da direkt ein eigenes "Programm" darin laufen lassen kann.
Also wo man sich bei Kleinstgeräten einen zusätzlichen Microcontroller sparen könnte, der dann die eigentliche Funktion übernimmt. Die meisten BT-Platinen machen ja "nur" die Kommunication und müssten dann von irgendwem gesteuert werden.
Für sowas wie Sensor/Steuerausgang->Bluetooth->Sonstwas, würde dann eine Knopfzelle, deren Platine und der Sensor ausreichen, wenn einem wenige I/O-Pins und ein "kleines" Programm ausreicht.
Deren Controller ist eh nicht voll ausgelastet und den Platz stellen sie einem zur Verfügung.

[mensch72]

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

[Rollo62]

@Mensch72:

Zitat:

völlig lizenzfrei

Ich glaube wenn man HomeKit nutzen will ist auch BLE nicht lizenzfrei, aber ansonsten hast du Recht.
Wenn eben geht BLE einsetzen.

Aber Classic BT selber bauen (evtl. wenn man Video/Audio braucht), da schlägt dann auch Apple noch voll zu.

Ich denke eine eigene Funklösung zu bauen macht nur Sinn wenn es um Stückzahlen >=200K geht, mal grob geschätzt.
Macht auch keinen Sinn wenn man superkleine Module an allen Ecken kaufen kann, und Cypress-Module bei 3USD losgehen.
Angeblich gibt es auch schon vorzertifizierte BLE Module in China, weit darunter.

Dafür spart man sich eine Menge Ärger, und kann einfach das nehmen was man braucht und funktioniert.
BT ist sowieso komplett durchgeregelt und überreguliert, da spielt ja eigentlich eine eigene Anpassung keine Rolle mehr.
Wenn über SPI/RS232 angebunden sehe ich das ähnlich wie bei einem ein FTDI-USB Chip.

Vielleicht gibt es hier im Forum ja noch andere Erfahrungen, aber den Fehler Funk selber zu machen hatten wir
nur einmal mit ISM vor Jahren gemacht.
Die Kosten für alle Prüfungen und Zertifizierungen in allen Ländern sind leider extrem.

Auch hat BT-SIG seit geraumen Zeit seine Praktiken verschärft, ganz so als wollten sie keine kleineren Projekte
an BLE teilhaben lassen, mit 1-2K pro Jahr, dann wird auch immer eine teure BLE Logo-Zertifizierung fällig.
Das war vor ein paar Jahren noch nicht nötig.
Für mich sind das Alles Abzockvereine, so wie das Maut-Konsortium

Rollo