Hallo zusammen, ich stehe vor folgendem Problem: Ich entwickle eine Projekt, dass mir die Fernsteierung eines Controllers mittels Bluetooth ermöglichen soll. Soweit hat es mit Bluetooth 2.1 und SPP super einfach funktioniert. Nun wird leider das 2.1 und SPP von einigen Geräten nicht unterstützt. Also möchte ich zu >4.0 übergehen. Nun ist ab diesen Versionen die einfache SPP übertragung nicht mehr möglich. Kann mir jemand helfen und sagen, wie ich auf einfachster Weise dann kleine Daten auslesen und beschreiben kann? Vielen DANK
:
Bearbeitet durch User
Konstanty K. schrieb: > das 2.1 und SPP von > einigen Geräten nicht unterstützt. Also möchte ich zu >4.0 übergehen. normal ist das 4.x gerät abwärtskompatibel.
Ja "normal" schon. Aber ich weis dass Apple Produkte kein SPP unterstützen. Somit muss ich auf andere Profile zurückgreifen.
> normal ist das 4.x gerät abwärtskompatibel.
BLE hat nichts mit normalen Bluetooth zutun! Das sind zwei ganz
unterschiedliche Dinge die sich zufaellig im selben Chip befinden
koennen und dieselbe Antenne nutzen. Das war es dann aber auch schon.
Olaf
Olaf schrieb: >> normal ist das 4.x gerät abwärtskompatibel. > > BLE hat nichts mit normalen Bluetooth zutun! Das sind zwei ganz > unterschiedliche Dinge die sich zufaellig im selben Chip befinden > koennen und dieselbe Antenne nutzen. Das war es dann aber auch schon. Das stimmst zwar aber: Die ganzen BT 4.0 USB Sticks sind aber abwärtskompatibel, ebenso wie iPhone, Android & Co. Es ist sehr unklar welche "Geräte" der OP meint die kein Bluetooth Classic unterstützen sollen. Wir reden hier von der "PC" Seite. Hier dürfte der OP schlicht einem Irrtum aufgesessen sein.
> Es ist sehr unklar welche "Geräte" der OP meint die kein Bluetooth > Classic unterstützen sollen. Wir reden hier von der "PC" Seite. Da bin ich nicht so sicher. Bei Classic musst du doch ein Protokoll verwenden das dein System auch kennen muss. Bei BLE gibt es zwar jede Menge vordefinierter UUids, aber im Prinzip soll man da auch einfach eigene Bytes verschicken können. (auch wenn mir letzteres noch nicht gelungen ist) Olaf
Okay, ich kann bestaetigen das es mit Qt5.5/5.6 moeglich ist eine Verbindung zu einem selbst programmierten (Eclipse-Projekt/kein Makefile) BLE-Device (nRF51822) aufzubauen und dort zuverlaessig Daten in beiden Richtungen auszutauschen die keine offiziell vergebene Uuid haben. Was mich etwas erstaunt, hat man einmal eine Verbindung von einem Android-Tablet zum Server/Device aufgebaut so bleibt sie bestehen auch wenn man das Tablet ausschaltet. Das ganze laeuft mit einer Stromaufnahme von 0.5mA bei aktivierter Connect-LED und alle 200ms Datenuebertragung. Bei ausgeschalter LED (blaue LED mit 3k3 Vorwiderstand) sicher noch deutlich weniger. Aber ich bin jetzt zu faul die abzuloeten. :) Olaf p.s: Allerdings hab ich jetzt bestimmt ein graues Haar mehr. Das ganze Thema ist ziemlich komplex....
Konstanty K. schrieb: > Ja "normal" schon. Aber ich weis dass Apple Produkte kein SPP > unterstützen. Somit muss ich auf andere Profile zurückgreifen. Das heißt doch daß Du ein komplett anderes Problem hast, welches nur am Rande mit Bluetooth zu tun hat: Du willst eine App für das komplett verdongelte iOS programmieren, die mit von Dir entwickelter Hardware kommuniziert, ohne daß Du den Obulus für das Freischalten dieser Hardware an Apple abdrücken willst.
Konstanty K. schrieb: > Kann mir jemand helfen und sagen, wie ich auf einfachster Weise dann > kleine Daten auslesen und beschreiben kann? Das Protokoll dazu lautet GATT. Du definierst einen Service, der enthält Characteristics. Characteristics sind so etwas wie Datenpunkte, die (in der Regel) maximal 20 Byte lang sein können und die Du lesen und Schreiben kannst (und dich auch über Änderungen informieren lassen kannst). Identifiziert werden Service und Characteristic über selbst gewählte 128-Bit UUIDs (es sei den, Du verwendest einen von Bluetooth verabschiedeten Service). Die APIs auf Controller-Seite sind meiner Meinung nach alle extrem und unnötig kompliziert. Zum Testen kann man sehr bequeme mit Node und https://github.com/sandeepmistry/noble etwas zusammen stricken. Oder einen der vielen, verfügbaren generischen GATT Clients verwenden (LightBlue, BLExplr etc). Hast Du schon einen bestimmten Controller im Auge?
Torsten R. schrieb: > Die APIs auf Controller-Seite sind meiner Meinung nach alle extrem und > unnötig kompliziert. Was für Idioten entwickeln bloss solche Scheiße??? Warum muß die simple Übertragung von ein paar Bytes so umständlich sein? Wenn das so weitergeht ist das bald von einem Hirn nicht mehr zu stemmen. Hauptsache wohl die Urheber dieses Mülls können sich in ihrer Genialität sonnen, die sie natürlich aus solchen überdreht komplexen Architekturen ableiten ;-((
> Was für Idioten entwickeln bloss solche Scheiße??? > Warum muß die simple Übertragung von ein paar Bytes so umständlich sein? Ja, das habe ich heute morgen bestimmt auch so 10x gedacht. Aber sobald man es verstanden hat und die Sache funktioniert relativiert sich das ganze etwas. :-) > Genialität sonnen, die sie natürlich aus solchen überdreht komplexen > Architekturen ableiten ;-(( Ich denke das Problem ist das wir jetzt immer mehr Leute haben die erst ihr Informatikstudium hinter sich gebracht haben und dann ohne Praxiserfahrung loslegen. Da kommt dann oft ziemlich verkopfter Scheiss raus. Dafuer gab es frueher mehr den Praktiker der Dinge produziert hat die zu Anfang schoen einfach waren, aber dann spaeter in der Weiterentwicklung boese Designfehler hatten. Das Ideal ist natuerlich irgenwo in der Mitte. Und fuer Deutsche kommt noch hinzu das man sich auch mit guten Englischkenntnissen bei so formalem Gelaber etwas schwerer tut als ein Englaender. Aber wisst ihr was das beste an der Sache ist? Wenn man sowas einmal selber programmiert hat und sieht in welchem Zustand das alles noch ist, dann muss man SEHR muede laecheln wenn so ein grenzdebiler Marketingschlipstraeger mal wieder was von IoT labert. :-D Olaf
Olaf schrieb: > Das Ideal ist natuerlich irgenwo in der Mitte. Und zur Ehrenrettung der Kollegen muss mach auch sagen, dass die natürlich alles in eine Standard rein bringen wollen, was evtl. später mal nützlich ist. Da selbst, wenn es später mal neue Versionen des Standards geben wird, die Geräte mit dem ersten Standard dann noch sehr lange unterwegs sind. Und ... BLE wurde natürlich nicht mit dem Hauptanwendungsfall: "Mal ein Paar Bytes hin und her schieben" entwickelt. Ich finde der größte Murks sind ja auch die APIs. Mit Bluetoe, braucht es 41 Zeilen, um eine Firmware zu schreiben, mit der ich via BLE eine LED an und aus machen kann (https://github.com/TorstenRobitzki/bluetoe/blob/master/examples/nrf51/blinky.cpp). Mit der original API von Nordic bräuchte ich wahrscheinlich mindestens 300 und mit der von TI 500 Zeilen. Und mit Noble schreibe ich den dazugehörigen Client mit 20 Zeilen. Die Bluetooth Spec ist meiner Meinung nach recht gut lesbar. Deshalb sollte eine BLE API Dokumentation aber nicht voraussetzen, diese gelesen zu haben, damit man in der Lage ist, die API Dokumentation zu verstehen.
> Mit der original API von Nordic bräuchte ich wahrscheinlich > mindestens 300 und mit der von TI 500 Zeilen. Ich habe diese Funktionalitaet, LED on/off und Taste mit einem notifier abfragen hier in QT in etwa 500Zeilen. Wobei es vermutlich in der Haelfte ginge wenn ich die Kommentare und verzweifelte Fehlermeldungen weglasse. Und wenn ich mich nochmal richtig aufraffe und alles in eine neue Ueberklasse schreibe die ich dann in Zukunft nutze, komme ich vermutlich auf 50-100Zeilen. Aber das heisst ja nichts. Letztlich bedeutet es nur das ich die Funktionalitaet auf das beschneide was ich meistens brauche. Es aendert aber nichts daran das die im Hintergrund ablaufende Funktionalitaet trotzdem sehr komplex ist. Es erstaunt mich z.B das der Verbindungsaufbau bei BLE im Bereich von einigen (5-10) Sekunden liegt wenn ich sehe das mein Server alle 200ms sendet. Man sollte doch meinen das dies deutlich schneller geht. Dafuer weiss ich jetzt das der Nachbar staendig vor der Glotze haengt und das es irgendwo einen Nachbarn mit Herzproblemen gibt. :-D Aber bei allem berechtigten Genoergel man bekommt auch einiges. Der geringe Stromverbrauch bei BLE ist schon nicht schlecht und ich hab hier gerade einen Verbindungsaufbau mit -103dBm hinbekommen. Sowas muss man selbst erstmal selber hinbekommen.... BTW: Weiss einer wieso der RSSI-Wert nur einmal beim Verbindungsaufbau gemessen wird und nicht dauernd? Olaf
Hier mal zwei Tips: COD-Generator: http://bluetooth-pentest.narod.ru/software/bluetooth_class_of_device-service_generator.html Damit konnte ich mich gerade ratz-fatz unter Qt mit meinem Device verbinden: QBluetoothDeviceInfo *TestInfo; QString MyName; QBluetoothAddress *MyAddress; quint32 MyClassOfDevice; //Definition meines eigenen Devices MyAddress = new QBluetoothAddress("E1:AC:1A:87:97:AB"); MyName = "OlafsBluetooth"; MyClassOfDevice = 0x3f00; TestInfo = new QBluetoothDeviceInfo(*MyAddress, MyName, MyClassOfDevice); ble_Control = new QLowEnergyController(*TestInfo, this); ble_Control->connectToDevice(); Jetzt muss man nur noch die Services auslesen, sich den richtigen aussuchen und die LED leuchtet. :-) Olaf
Olaf schrieb: > Jetzt muss man nur noch die Services auslesen, sich den richtigen > aussuchen und die LED leuchtet. :-) C oder Java Programmierer? ;-)
> C oder Java Programmierer? ;-)
C doppelplus natuerlich!
BTW: Theorethisch sollte obiger Ansatz, der unter Android funktioniert,
auch unter Win8.1 funktionieren. Das ist aber leider nicht der Fall. Das
System wirft immer ein "Cannot find local adapter" raus. Ausserdem
laesst sich mein BLE Device nicht mehr mit Win8.1 koppeln obwohl das
schonmal funktioniert hat. Ich glaube Microsoftprodukte sind wirklich
schlecht wie es einem die Vorurteile glauben machen. Nicht nur das die
Kacke nicht vernuenftig funktioniert, es gibt auch keine
aussagekraeftigen Fehlermeldungen.
Olaf
Olaf schrieb: > Das > System wirft immer ein "Cannot find local adapter" raus. Kann es sein, dass die Hardware keine Treiber hat (oder so)?
Jim M. schrieb: > Das stimmst zwar aber: > Die ganzen BT 4.0 USB Sticks sind aber abwärtskompatibel, ebenso wie > iPhone, Android & Co. Jein. Es gibt auch reine BT 4.0 Module. Der TE will ja mit IOS kommunizieren. Unter IOS hast du als Entwickler überhaupt keine Zugriff auf BT. BT ist da nur für Geräte wie Kopfhörer usw. gedacht. Bei BT LE ist es anders. Dazu gibt es das CoreBluetooth Framework. Dazu findest du einigen Beispiel-Code im Internet, allerdings fast alle mit Objective-C. Für Swift habe ich nur 1 Video gefunden: https://www.youtube.com/watch?v=9YY1VxwEbQY&feature=iv&src_vid=P4rA6IVGx_o&annotation_id=annotation_2412050895 BT LE scheint sehr kompliziert zu sein, ist es aber nicht, wenn man es mal verstanden hat. Es gibt 2 Rollen: Central (das IOS) Gerät und Peripheral, das ist das Ding von dem du die Daten willst. Das IOS Gerät kann auch Peripheral sein. Das Peripheral macht so im Sekundenabstand Werbung für sich, das IOS Gerät findet es in einem Scan automatisch. Dann kann man die Services abfragen, das sind quasi "Dienste", für diese kannst du nach den Characteristics abfragen. Jeder Service und jede Characteristics können eine beliebige 128-bit ID haben, die kannst du dir selbst erzeugen. Da du beides kennst, kannst du einfach gezielt nach Peripherals mit deiner ID scannen:
1 | manager.scanForPeripheralsWithServices([CBUUID(string: kServiceUUID)], options: [CBCentralManagerScanOptionAllowDuplicatesKey:false]) |
Wenn du den passenden Characteristics gefunden hast, connectest du dich und subscribest dich dafür. Sobald es neue Daten gibt, wird dein Delegate aufgerufen und du kannst auf die Daten zugreifen. Das funktioniert alles über Delegates, du brauchst nichts pollen oder sonstwie abfragen. Was halt etwas lästig ist, ist dass du nur maximal 20 Bytes auf einmal übertragen kannst (lässt sich auf 512 Bytes vergrößern, falls das Gerät das kann, der Standart garantiert aber nur 20 Bytes), so dass du in der Sende-Routine die Daten in 20-Byte Häppchen zerlegen musst. Deswegen hat die Senderoutine halt 25 Zeilen statt 2. Der Code für das iPhone als Central hat bei mir 300 Zeilen mit allen möglichen Features. Am iPad habe ich ein Peripheral programmiert, das hat 250 Zeilen. Also, wie gesagt, wenn man es verstanden hat, ist es einfach. Die Doku zu Core Bluetooth ist hier: https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/AboutCoreBluetooth/Introduction.html#//apple_ref/doc/uid/TP40013257-CH1-SW1 (leider in Objective-C, lässt sich aber einfach in Swift umschreiben, ich habe da schon etwas Übung). Ich kommuniziere mit einem uBlox Bluetooth LE Module, dass einfach serielle Daten weiterleitet. Wenn man vorher mit zwei IOS Geräten die Kommunikation zustande gebracht hat, geht die Anbindung an das Modul recht schnell. Wenn du möchtest kann ich dir den Sourcecode schicken, den Peripheral kannst du als fertiges Projekt haben, den Central teil halt nur als einzelnes File, weil das bei mir schon in die App eingebaut ist.
> Kann es sein, dass die Hardware keine Treiber hat (oder so)? Nein. Win8.1 zeigt mir ja bereits das Geraet in seinem Bluetooth-Verbindungsfenster an und hat dazu aus dem Geraet "OlafsBluetooth" ausgelesen. Ausserdem kann ich am nRF51822 an einer LED sehen das bereits fuer kurze Zeit eine Verbindung aufgebaut wurde. Und hat es ja schonmal funktioniert! Allerdings hat damals das koppeln auch nicht sofort geklappt, sondern erst nach ein paar Versuchen. Das ist wohl irgendein Timingproblem. Die Fehlermeldung "Cannot find local adapter" kommt aus meinem Qt Programm, aber das laeuft ja jetzt noch garnicht. So wie ich die Geheimnisse von Win8.1 verstehe muss ich erstmal wieder mein Device mit Win8 verbinden und danach hoffe ich dann das die Fehlermeldung in Qt weggeht. Ausser natuerlich da ist noch eine weitere Baustelle. Olaf
> BT LE scheint sehr kompliziert zu sein, ist es aber nicht, wenn man > es mal verstanden hat. Dir ist schon klar das es Leute gibt die geneigt sind dir zu wiedersprechen wenn sie so einen deutschen Satz lesen: "Es gibt 2 Rollen:" :-) Das Problem mit BLE ist wohl einfach das es alles noch sehr neu ist. Auch wenn das eigentlich garnicht stimmt. Ist ja IMHO von 2011. Aber es kommt jetzt erst so langsam bei der breiten Masse an. Es gibt da einfach noch eine Menge Spielraum wo man sich fragt ob man selber etwas nicht verstanden hat, oder ob es ein Bug ist. Mal ein Beispiel: ServiceListe = ble_Control->services(); for (int i = 0; i<ServiceListe.count(); i++) { MyString = "Uuid: "; MyString.append( QString::number(ServiceListe.at(i).toUInt16() )); ui->textEdit_Status->append(MyString); } Das liefert mir unter Qt: 0x1800, 0x1801 und 0. Erwartet haette ich aber 0x1800, 0x1801 und 0x1523. Letzeres ist die Characeristic mit der ich reden will und auch erfolgreich reden kann. Bug, Feature oder Doofheit? Olaf
Olaf schrieb: > Das liefert mir unter Qt: 0x1800, 0x1801 und 0. Erwartet haette ich aber > 0x1800, 0x1801 und 0x1523. Letzeres ist die Characeristic mit der ich > reden will und auch erfolgreich reden kann. Bug, Feature oder Doofheit? Kann es sein, dass der dritte Service keine 16-Bit UUID hat? Was sollte 0x1523 den sein? In der Liste der Adopted Specifications taucht der nicht auf.
Lass dir den Service als String ausgeben. Die Services sind 128 bit, 16 bit ist nur die Abkürzung für bekannte Services.
Olaf schrieb: > wenn sie so einen deutschen Satz lesen: "Es gibt 2 > Rollen:" :-) Was ist daran unverständlich? Es ist natürlich keine Rolle am Stuhl gemeint, sondern eine Rolle wie beim Schauspieler.
> Lass dir den Service als String ausgeben. Die Services sind 128 bit, 16 > bit ist nur die Abkürzung für bekannte Services. Ich weiss. Als String sieht das dann so aus: Service {00001800-0000-1000-8000-00805f9b34fb} gefunden Service {00001801-0000-1000-8000-00805f9b34fb} gefunden Service {00001523-0000-1000-8000-00805f9b34fb} gefunden Deshalb habe ich mich ja gewundert das ich als 16 oder 32Bit Uuid im letzten Fall nur 0 bekomme. Ich vermute das hat etwas damit zutun das dem 0x1523 noch die beiden Characteristic 0x1524 (Taster) und 0x1525 (Led) untergeordnet sind. Aber sicher bin ich mir da jetzt nicht. Und es war ja auch nur als Beispiel gedacht. Wenn man auf sowas beim Erstkontakt trifft dann ist das schon verwirrend. Olaf
> Aber wisst ihr was das beste an der Sache ist? Wenn man sowas einmal > selber programmiert hat und sieht in welchem Zustand das alles noch > ist, dann muss man SEHR muede laecheln wenn so ein grenzdebiler > Marketingschlipstraeger mal wieder was von IoT labert. Wenn ich meinem Ex-Chef was von unprofessionellen Arbeitsmitteln und zu viel Geiz-Ist-Geil Mentalität vorgeheult hatte, dann antwortete er immer: "Die anderen kochen auch nur mit Wasser." Das war vor 20 Jahren. Heute weiß ich, das er absolut Recht hatte.
Angehängte Dateien:
-
SCR01.GIF
17 KB
Nochmal ein paar Tips und Daten zu BLE. Das Bild zeigt die maximale Stromaufnahme eines nRF51822. Es sind allerdings deshalb nur 21mA weil ich auf meiner Testplatine noch einen 10uF Kondensator und einen 100uF Elko habe. Im Sendebetrieb zieht der sicher noch mehr. Allerdings immer nur sehr kurz. Der Mittelwert lag so bei 300-400uA. Allerdings hatte ich zwei LEDs angeschlossen. (mit 3k3 Vorwiderstand. Mittlerweile habe ich bei den Leds 100k als Vorwiderstand, sende alle 500ms einen 10Bit ADC-Wert und habe entsprechend den AD-Wandler im nRF51 laufen. Damit liege ich dann bei einem mittleren Strom von 170uA. Wobei die Schaltung und das Programm sicher noch nicht auf maximale Stromersparnis optimiert sind! Zwei Dinge sind mir aber aufgefallen: 1. Wenn das Program im BLE-Server abstuerzt weil man Unsinn programmiert hat dann geht der Stromverbrauch sofort auf 10mA hoch. Grund dafuer ist natuerlich das der Controller dann irgendwas macht und niemals mehr in den Sleepmode geht. Das ist natuerlich fuer Batteriebetrieb bitter! Ich hoffe der nRF51 hat einen integrierten WatchDog, hab noch nicht nach geschaut. 2. Wenn man den J-Link angesteckt hat dann liegt die Stromaufnahme immer bei einigen mA. Auch wenn man den J-Link-Stecker im Betrieb abzieht bleibt das so. Fuer Strommessungen muss der Controller ohne Debugger eingeschaltet werden. Vermutlich aktiviert der J-Link irgendwas in dem Controller das ordentlich Strom zieht. Ansonsten bin ich jetzt begeistert. :-) Olaf
Olaf schrieb: > Wenn man den J-Link angesteckt hat dann liegt die > Stromaufnahme immer bei einigen mA. SWD geht nur bei aktivem CPU Takt. Der JLink schaltet deswegen die erweiterten Sparmöglichkeiten des Chips aus, sonst könnte man nicht debuggen. Natürlich haben die NRF51ger einen Watchdog. Siehe Kapitel 20 im Reference Manual.
Torsten R. schrieb: > Hast Du schon einen bestimmten Controller im Auge? Bisher hatte ich nur mit dem RN42 gearbeitet. Es wird aber wahrscheinlich der BT121 der scheinbar iAP2, SPP und BLE4.1 hat.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.