Hallo, ich versuche Datenpakete mit wenigen Byte (<=20) zwischen einem HM10 Modul und einem Android-Phone (Galaxy S6) mit möglichst hoher Updaterate (>20Hz) in beide Richtungen gleichzeitig zu senden und habe dabei eine erstaunlich miese Performance im Vergleich zum Senden nur in einer Richtung. Vorab: Es geht mir bei dieser Frage nicht darum dass mir irgendwer mein Problem durch ein langwieriges Frage/Antwortspiel löst - es ist klar dass das Thema komplex ist. Bitte nur weiterlesen/antworten falls jemand genau dieses Problem schon hatte (gleizeitig senden/empfangen weniger Bytes aber mit möglichst hoher Updaterate/geringer Latenz). Es würde mir auch reichen zu wissen ob es jemand anders hingekriegt hat (mit welcher Performance?) - auch falls mit anderem BLE-Serial Modul aber ebenfalls Android (Phone/Tablet). Ein paar Details: Das HM10 ist im "Peripheral" Mode (connect geht von Android-App aus) und es werden jeweils Pakete von 8 Byte geschickt (also innerhalb der 20-Byte Grenze der characteristik). Wenn die Übertragung nur in eine Richtung läuft ist der Empfang regelmäßig und ich erreiche folgende Updateraten: Android --> HM10 > 100Hz (mehr nicht getestet weil ausreichend) HM10 --> Android bis 25Hz werden nur wenige Pakete verschluckt, darüber immer mehr (in dieser Richtung also deutlich schlechter, wäre aber noch ok) Wenn ich jetzt aber gleichzeitig sende und empfange (beides mit 25 Hz und weniger) kommen die Pakete vom Android-Phone nur noch unregelmäßig beim HM10 an, in der Gegenrichtung ist die Updaterate noch halbwegs regelmäßig aber es kommt zu Übertragungsfehlern bei einzelnen Paketen. Gruß, Achim
Welche Baudrate ist beim HM10 eingestellt? Mehr als 9600 erfordert meiner Erfahrung nach Hardware-Handshake beim Uart.
Das ganze basiert ja auf Bluetooth LE. Für die Richtung Peripheral->Controller gibt es zwei technische Möglichkeiten: Indications, dabei läßt sich das Peripheral, die Verarbeitung der Daten quittieren und Notifications, bei denen diese nicht der Fall ist. Versuche doch mal in der Dokumentation heraus zu bekommen, wie dieses Modul das umsetzt und ob Du da ggf. etwas an der Umsetzung parametrisieren kannst. BLE schafft die gewünschte Übertragungsrate auf jeden Fall. Das Bottleneck scheint die Umsetzung durch das Modul zu sein. mfg Torsten
Achim M. schrieb: > ich versuche Datenpakete mit wenigen Byte (<=20) zwischen einem HM10 > Modul und einem Android-Phone (Galaxy S6) mit möglichst hoher Updaterate > (>20Hz) in beide Richtungen gleichzeitig zu senden Du kannst nicht gleichzeitig in beide Richtungen Daten übertragen, weil für beide Richtungen der gleiche Frequenzbereich genutzt wird und der Sender darum den eigenen Empfänger zustopft. In einer so einfachen Konfiguration geht es nur halbduplex, d.h. immer schön abwechselnd.
Danke Euch für die Hinweise, das werde ich mal checken und dann berichten War mir tatsächlich nicht klar das BLE nicht Vollduplexfähig ist... das erklärt natürlich bisschen was ;-) Als Baudrate habe ich 38200 eingestellt, wäre ja schon etwas schräg wenn das HM10 dafür schon eine Sonderbehandlung (HW-Handshake) braucht - ich werde es aber auch mal mit 9600 testen.
Achim M. schrieb: > War mir tatsächlich nicht klar das BLE nicht Vollduplexfähig ist... das > erklärt natürlich bisschen was Soweit mir bekannt ist, sind alle Funkstrecken im Consumer Bereich entweder unidirektional oder Half-Duplex.
Achim M. schrieb: > War mir tatsächlich nicht klar das BLE nicht Vollduplexfähig ist... das > erklärt natürlich bisschen was ;-) Auf der selben Frequenz kann nich gleichzeitig Gesendet und Empfangen werden. Das ist aber nicht das Problem. BLE funkt mit einer Symbolrate von 1MBit. In einem Connection Event, werden zuerst Daten vom Controller zum Peripheral gesendet und der kann dann sofort Antworten und Daten zum Controller funken. Die Limitierung, die Du beobachtest liegt in der Umsetzung des Moduls, nicht in BLE.
So, nach einigen Stunden rumgewurschtel: Die Änderung meines Code in Richtung half-duplex (also immer erst senden wenn was empfangen wurde) schien zunächst keine Verbesserung zu bringen - bis ich noch eine weitere Änderung an der Android-Seite vorgenommen habe: Ich sende jetzt nur noch in der Funktion onCharacteristicRead(...) (vom BluetoothGattCallback) - d.h. wenn der Leseprozess der zuletzt empfangenen Daten definitiv abgeschlossen ist. Der HM10 stellt für die Uart-IO nur eine Characteristik zu verfügung - vermutlich kamen sich schreiben und lesen dabei zuvor ins Gehege. Ich war fälschlicherweise davon ausgegangen dass mit dem Aufruf von onCharacteristicChanged() (ebenfalls BluetoothGattCallback) die Daten schon emfpangen wären und mit characteristic.read nur noch (aus einem Puffer) ausgelesen werden müssen. Es signalisiert aber nur die "notification" vom HM10 dass neue Daten anliegen und der leseprozess dauert dann offenbar länger - daher sollte man also brav auch onCharacteristicRead() implementieren! Die max. Updaterate (jeweils ein Paket hin und eins zurück) liegt allerdings auch damit bei mageren 7 Hz, immerhin gibt es keine Übertragunsfehler mehr. Die Uart-Baudrate hat eindeutig keinen Einfluss auf die Performance. >> Das ganze basiert ja auf Bluetooth LE. Für die Richtung >> Peripheral->Controller gibt es zwei technische Möglichkeiten: >> Indications, dabei läßt sich das Peripheral, die Verarbeitung der Daten >> quittieren und Notifications, bei denen diese nicht der Fall ist. Ob sich hier etwas ändern lässt habe ich noch nicht recherchiert, im "Auslieferungszustand" verwendet der HM10 jedenfalls Notifications Der Service der für die Uart-IO vom HM10 zur Verfügung gestellt wird ist ein "custom" service - d.h. keiner der in der BT4-Spezifikation gelistet ist und man kann offenbar auch die uuid dafür ändern. Bei meiner Recherche bin ich irgendwo auch über die Aussage gestolpert man könne (diesem Custom-Service) sogar eine zweite Characteristik hinzufügen. Evtl. "lauert" ja auch hier eine Möglichkeit die Perfomance zu verbessern. Falls ich irgendwann noch etwas dazu rausfinde werde ich berichten, im Moment habe ich die Nase voll und ich gebe mich erstmal mit nur einer Senderichtung zufrieden ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte 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.