Bluetooth Low Energy Delphi 6

[mensch72]

BLE als solches für einfachen 1:1 binär Datenstream als "BT-SPP" gibt es ja nicht... In BT4-BLE wird per das zu 99% per GATT-Profile mit Standard- und/oder Private-Services samt entsprechenden Standard und/oder Private-Charakteristics gemacht.

- Ab Delphi XE8.1 funktioniert der BLE Zugriff zumindest unter Android4.4.2+ & IOS8+ sowie +OSx10.9+ OutOfTheBox problemlos.
- Ab Win8.1 funktioniert auch die meiste in aktuellen Notebooks verbaute BT4/BLE Hardware, wenn man unter Windows das BLE-Gerät scannt und "verbindet"
- XE7..bis einschließlich DX10u1 Seattle implemetieren OutOfTheBox das "DiscoverDevices" unter Windows8+ schlicht garnicht, scannen also nicht und liefern nur die vorher schon systemweit fest verbundenen BLE/BT Geräte... für quasi fixe&bekannte 1:n Verbindungen ist das mit etwas Setup-Aufwand OK, aber für Anwendungen, wo man ständig neue/aktuelle BLE-Geräte in der Umgebung scannen und dann live automatisch connecten will, war&ist das so bisher unter Windows8+ mit Delphi unbrauchbar... nicht umsonst sind die DemoVideos für BLE von Emba immer auf einem MAC unter OSx bzw als MobileDevice/OS ;)
- DX10.1 Berlin soll da was verbessert haben, aber ich hatte noch keine Zeit es unter Windows zu probieren, ob der Scan("DiscoverDevices") nun unter Delphi in Windows funtioniert... Ein BLE Scan Demo liefert Emba ja mit :)

-> wenn es mit Delphi6 gehen soll, würde ich eine per USB angeschlossene Hardware als "BLE-Dongle" empfehlen, welche nur einen virtuellen ComPort samt ASCII-CMD-API zur Verfügung stellt.
=> http://www.buyrfid.co.uk/store/index...product_id=107

Zufällig ist es Teil meines Alltagsgeschäfts, BLE für beliebige 8Bit Microcontroler basierte Baugruppen&Geräte zu implementieren:)

MicroChip bietet da mit dem RN4020 Modul eine Lösung, welche simpel seriell angesprochen wird, und vergleichbar früheren "AT-Commands" konfiguriert wird und dann wenn es sein muss sogar zur transparanten 1:1 Datenübertragung(MLDP als "SPP-Emulation") genutzt werden könnte... ich habe mich aber für einen PrivateService entschieden und übertrage mit 2 private Charateristics blockweise je bis zu 20Bytes 1:1 bidrektional eventbasiert("mit Notification")... das reicht für unsere Anwendúng und ist 100% kompatibel mit Android, IOS und OSX, nur für Windows verwenden wir bisher der Einfachheit halber so einen simplen sereiellen USB-Stick, welcher das gleiche Modul drin hat. Das funktioniert mit jedem Delphi, bei uns real genutzt ab D2007.

Man beachte, das 97% der billigen oder festverbauten BT(4)/BLE (USB-)Dongles nur HCI können, und quasi alles vom BT/BLE-Stack/Treiber unter/für WindowsAPI realisiert ist.
Seriell frei programmierbare BLE-Hardware (GATT-Profile, private Services, private Charateristics, Notifications) als USB-Dongle gibt es nur ganz wenige!

[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:

Zitat von v2afrank (Beitrag 1339153)

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 :D )

[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:

Zitat von Valle (Beitrag 1339158)

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 :shock:

Rollo

[v2afrank]

Ggf. mach ich einen neuen Thread auf aber erst mal so, da es meiner Meinung nach hier hin gehört
Ich habe jetzt einen Bluetooth Stick von Hama und habe mir die Testversion von Delphi Berlin runtergeladen. Unter Windows funktioniert der Stick einwandfrei. Nehme ich allerdings das BLEScanner Demo von Delphi bekomme ich nur die Meldung Bluetooth Gerät nicht gefunden , nicht verbunden oder ausgeschaltet. Weiß jemand was ich falsch mache ?

[mensch72]

Zitat:

Zitat von v2afrank (Beitrag 1339439)

Unter Windows funktioniert der Stick einwandfrei. Nehme ich allerdings das BLEScanner Demo von Delphi bekomme ich nur die Meldung Bluetooth Gerät nicht gefunden , nicht verbunden oder ausgeschaltet. Weiß jemand was ich falsch mache ?

Du machst unter Delphi FMX nichts falsch.. die Implementation vom FMX-BLE Adapter unter Windows hat leider auch unter "DX-Berlin" immer noch den Fehler, das "DiscoverDevices" egal was man für einen TimeOut angibt stets sofort zurückkommt OHNE ZU SCANNEN!?

-> derzeit unter WindowsFMX einzige mir bekannte OutOfTheBox Möglichkeit: man "verbinde" sich im WindowsBLE Manager mit dem BLE Gerät... dann wird es auch im Delphi-BLEscanner (ohne Scan sofort)"gefunden"