Bluetooth, HC-05, Übertragung nur bedingt synchron

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Bluetooth, HC-05, Übertragung nur bedingt synchron

      Hallo Community,

      beim Betrieb der Bluetooth-Module HC-05 wollte ich alle 2ms ein Byte mit 115200Bd vom Master HC-05 zum Slave HC-05 übertragen. (Testaufbau mit Arduino UNO/Sender und Terminalprogramm als Empfänger)

      Was ich nicht erwartet hatte ist, dass sich der Zyklus der empfangenen Daten am HC-05 Slave-Ausgang deutlich vom Senderzyklus (2ms) unterscheidet. Zwar sind alle Daten fehlerfrei vorhanden, allerdings nicht im Abstand von 2ms , sondern unregelmäßig, mal im Abstand von ca. 10ms, mal auch kürzer und fast immer in Blöcken von 4 oder 5 Bytes zusammenhängend. (siehe auch Bilder)

      Die Bilder zeigen einmal alle 2ms das anstehende Byte (obere Spur) und unten die in Blöcken erscheinenden Ausgabedaten am Slave-Modul.
      Das zweite Bild zeigt einen Ausschnitt aus dem ersten Bild, man erkennt, dass die einzelne Bitdauer zur Übertagung mit 115200Bd passt, aber der Abstand zwischen zwei Blöcken mal ca. 10ms liegt .

      Ich wollte eine solche Funkübertragung nutzen, um Messwerte kontinuierlich auf einem Grafikdisplay darzustellen. Durch diese blockweise Übertagung werden, ohne zusätzliche Maßnahmen, lineare Zusammenhänge jedoch verzerrt dargestellt.


      Meine Frage ist, gibt es Bluetooth-Module, bei denen die Ausgabe der empfangenen Daten im selben Rhythmus geschieht, wie sie dem Sendemodul bereitgestellt werden?

      Bei Reichelt gibt es ein Modul, welches auf dem Roving RN-42 basiert. Hat jemand hiermit Erfahrung bzgl. synchroner Datenübertragung? Oder wie ist es mit dem BTM-222?

      Oder liegt es generell im Bluetooth-Verfahren (Frequenzsprünge) begründet, dass die Daten nur blockweise übertragen werden. Bei Sprachübertragung (Musik) scheint es ja auch synchron zu laufen.

      Gruß

      Ulrich
      Files
    • Ulrich wrote:

      Oder liegt es generell im Bluetooth-Verfahren (Frequenzsprünge) begründet, dass die Daten nur blockweise übertragen werden. Bei Sprachübertragung (Musik) scheint es ja auch synchron zu laufen.
      Was ist schon synchron? Ich habe mal gehört, dass bis 50ms Verzögerung noch alös synchron gilt ;)
      Bluetooth überträgt ja nicht nur einzelne Bytes, sondern puffert diese und schnürt Pakete mit Frequenzaushandlung und Fehlerkorrektur. Wenn ein Paket ausbleibt, wegen Störungen z.B., dann kann es wiederholt angefordert werden.

      In deinem Oszibild sieht man schön, dass der minimale Abstand der Pakete eben 10ms ist.

      Ich würde die Daten im Empfänger einfach aufsammeln und im gewünschten 2ms Raster ausgeben.
    • Hallo Michael,

      offenbar gibt es bei Bluetooth auch einen synchronen Modus (siehe SCO in festen Zeitschlitzen, z.B. bei lippensynchroner Übertragung des TV-Tons ? )

      Meine Frage war ja, ob es solche Bluetooth-Module auch für unseren Home-Einsatz gibt, bzw. ob schon Erfahrungen mit SCO-Betrieb vorliegen würden.

      Gruß
      Ulrich
      Files
    • Ulrich wrote:

      offenbar gibt es bei Bluetooth auch einen synchronen Modus (siehe SCO in festen Zeitschlitzen, z.B. bei lippensynchroner Übertragung des TV-Tons ? )
      scheinbar gibt es so was, ich habe aber auch eine Implementierung außerhalb des Bluetooth-Moduls gefunden:
      dinotools.de/2014/03/05/raspbe…-per-bluetooth-verbinden/
      Das wäre dann in etwa die von mir vorgeschlagene Variante ;)

      Die synchrone Übertragung heißt aber nicht, dass das Signal zeitgleich ankommt, das heißt nur, dass fehlerhafte Pakete verworfen werden, damit der Fluss nicht stockt. Da bringt halt Artefakte in die Daten, willst du das?
    • Hi Michael,


      habe mal ein wenig weiter herum getestet, um zu sehen wie und wann was mit den HC-05 Modulen übertragen wird.


      Zur Eräuerung:
      Ins HC-05 Sendemodul wird ein Zählerstand aus einem UNO via „Print“-Befehl eingespeist, hier die Zahl 23 mit CR und LF als Abschluß. (das Paket besteht dann aus 4 Zeichen, 2, 3,CR,LF)


      Offenbar ist es so, dass erst bei einer Zyklusrate ab 20ms aufwärts zu jedem „Print“ (UNO an HC-05 Sender)-auch ein zugehöriger Empfang des kompletten Pakets am HC-05 Ausgang feststellbar ist.


      Wenn die Zyklusrate kleiner als 20ms ist, kann man, wie in den drei folgenden Bildern dargestellt, erkennen, dass Teile einer Sendung (hier das einzelne Zeichen „LF“) erst eine Weile später vom HC-05 Empfänger ausgegeben werden.


      In einem Übersichtsbild ist das eingespeistes Paket (untere Spur, es enthält auch CR, LF) und die darauffolgende Aktion am HC-05-Empfänger-Ausgang, die in zwei Teile gestaffelt ist, abläuft. Die beiden anderen Bilder zeigen die gedehnten Ansichten von Teil-1 und Teil-2 aus dem Übersichtsbild.



      Im Bild Teil-1 sind drei Zeichen (Zähler stand 32 und 33 und 0D=CR) dargestellt und in Teil-2 wird der 0A=LF-Abschluß deutlich später ausgegeben (wurde er nachgesendet?).D. h, die Pakete werden gestückelt übertragen.


      Für den Anwender ist es jedoch nahezu uninteressant, wann welche Zeichen gesendet werden, Hauptsache die empfangenen Daten sind fehlerfrei, aber es bedeutet auch, dass auf der Empfangsseite auch auf das LF als Abschluss zu testen ist, was aber mit dem „Input“-Befehl automatisch gegeben ist.


      Deshalb werde ich die Pakete, wie du vorgeschlagen hast, am Empfangsort erst mal in einem Array aufsammeln und anschließend mit der erforderlichen Zyklusrate an das grafische Display ausgeben.


      Gruß

      Ulrich
      Files