HC-05: Bytes gehen in Übertragung verloren

[Transmitter (Gast)]

Hallo, ich benutze eine HC-05 Bluetooth Modul um Daten an meinen Rechner 
zu senden. Bei der Übertragung wird immer ein Bündel an Daten gesendet. 
Die Baudrate ist auf 115200 eingestellt. Start Bit ist 0, Stopp Bit und 
Parität Bit sind 1.
Gemessen habe ich am RX Pin mit einem Scope 115206,046 Baud. Anstiegs- 
und Abfallszeit sind 285ns. Das ist durch einen RC Tiefpass bedingt, um 
Rauschen auf der RX Leitung zu unterdrücken. Das Rauschen habe ich mit 
50mVeff gemessen.

Meiner Meinung nach zeigen diese Messungen keine Offensichtlichen 
Probleme. Allerdings werden nicht immer alle Bytes übertragen. Es gehen 
fast immer 5 bis 20 Bytes verloren. Wenn das Datenpaket nur aus leeren 
Bytes besteht, geht jedoch nie ein Byte verloren.
Besonders der letzte Punkt wundert mich.
Hat jemand eine Ahnung was hier los sein könnte? Ist es vielleicht der 
Computer der Probleme macht? Ich verbinde mich mit einem Üblichen 
Bluetoothmanager unter Linux und sammle die Daten via cat /dev/rfcomm0.

[c r (Gast)]

Was ist denn ein leeres Byte?

[Helmut -. (dc3yc)]

Schaltplan, Programm? Wozu ein Tiefpass? In welches Signal ist der 
eingeschleift?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

c r schrieb:
> Was ist denn ein leeres Byte?
Und was passiert, wenn "leere Bytes" mit anderem Inhalt übertragen 
werden?

Ich würde mal die Verbindung aufbauen
, dann RX und TX am Modul brücken und vom PC Terminal aus kontrollieren, 
ob und welche Bytes da Probleme machen.

[Achim H. (pluto25)]

Transmitter schrieb:
> Start Bit ist 0,
Wie denn sonst?
Funktioniert es ohne Parität? evt mit zwei Stopbits?

[Stefan F. (Gast)]

Wie groß sind deine Datenpakete und wie lange sind die Pausen 
dazwischen?

Eins solltest du wissen: 115200 Baud ist schon nahe am Maximum, was 
diese Module überhaupt schaffen. Wenn da nur der kleinste 
Übertragunsgfehler stört, hat das Modul bei kontinuierlicher Übertragung 
keine Zeit mehr, den Fehler durch Wiederholung zu korrigieren.

Sie funktionieren recht zuverlässig, wenn du kleine Pakete (z.B. 64 
Bytes) sendest und dann auf eine Empfangsbestätigung des Empfängers 
wartest, bevor du weiter sendest. Also Half-Duplex.

[Jim M. (turboj)]

Transmitter schrieb:
> Hat jemand eine Ahnung was hier los sein könnte?

Baudraten von 115200 und mehr brauchen bei Bluetooth Modulen immer 
Hardware Flußsteuerung (RTC/CTS flow control). Denn es können wie oben 
erwähnt im Modul die Puffer volllaufen - dann darf der µC keine Daten 
mehr senden, denn die gehen dann futsch.

Das erklärt auch warum mehrere Bytes verloren gehen, denn erst im 
nächsten Übertragungsintervall wird wieder Platz im Puffer frei.

Falls der Ziel-µC kein RTS/CTS kennt, kann man sich das auch in Software 
zusammen stricken - einfach den Zustand der RTS Leitung prüfen bevor man 
ein TX Byte sendet.

[Transmitter (Gast)]

Hallo nochmal. Ein paar Stunden habe ich mich noch dran gesetzt. Das 
HC-05 Modul wird das Problem sein. Wenn ich die Daten per Kabel and 
einen Arduino und dann an den Rechner schicke klappt alles.
Mit einem Leeren Byte meine ich ein Datenbyte was komplet Null ist. also 
0x00. Streng genommen ist es ja auch nicht leer, entschuldigt meine 
Ausdrucksweise. Der Transmitter ist auf einem FPGA realisiert und sehr 
simpel gehalten. Also habe ich auch keine tollen Korrektur- oder 
Wiederholungs Features. Irgendwie sowas werde ich aber implementieren 
müssen da der Datenstrom etwa 10s anhält.

[Stefan F. (Gast)]

Transmitter schrieb:
> Das HC-05 Modul wird das Problem sein.

Da kannst du so viele Module probieren wie du willst. Ein anderes Modul 
kann dein Problem durch größere Puffer bestenfalls entschärfen, aber 
nicht lösen.

Das Problem ist, dass du in deiner Anwendung die Eigenschaften der 
Übertragungsstrecke nicht berücksichtigst hast.

Mache wie bereits empfohlen entweder Half-Duplex mit kleinen Paketen und 
Bestätigungen oder nutze die Handshake Leitungen.