Möglicher Fehler beim raw-Befehl

[C_Herrmann]

Hallo,

beim Experimentieren mit dem Cul raw Kommando habe ich festgestellt, dass am Ende zu viele Daten gesendet werden.

Gesendeter String:
G0031E16823236854326d1

Empfangenes Ergebnis:
3 Byte (54326d) und diese Bits: 0000001

Eigentlich sollte nach den 3 Bytes nur eine 1 statt der 7 Bits gesendet werden.

Hier ist das Datagramm, welches ich mit einem SDR fähigen DVB-T Stick aufgezeichnet habe:
(http://forum.fhem.de/index.php?action=dlattach;topic=19930.0;attach=11869)

Liegt hier ein Fehler in der CUL-Firmware vor?

Gruß,
Christian

p.s.
Ein Wiki-Artikel über die Datenanalyse per SDR fähigem DVB-T Stick ist in Arbeit.

[C_Herrmann]

Hallo,

Ich habe nun weitere Tests mit dem raw-Befehl gemacht und festgestellt, dass auch beim Senden von 2 Byte 7 Bits angehängt werden.

Gesendet:
G0020E368232368547B

Empfangene Bits:
01010100011110110001001

Umwandlung in Hex:
0101 0100 0111 1011 0001001
5       4       7       b       7 Bits

Hier ist das Datagramm:
(http://forum.fhem.de/index.php?action=dlattach;topic=19930.0;attach=11892)

Der Fehler tritt auch auf, wenn ich den CUL am PC anschließe un den raw-Befehl über ein Terminal sende.

Gruß,
Christian

p.s.
Der Wiki-Artikel über die Funksignalanalyse per SDR fähigem DVB-T Stick ist fertig.
http://www.fhemwiki.de/wiki/Funksignalanalyse_mit_DVB-T_Stick

[atietzel]

Hallo Christian,

die Funktion ist ok, wenn auch nicht schön. Die Doku ist vermutlich falsch. Ich habe mir das nämlich gerade selbst auch angesehen und bin darüber gestolpert.
Die zusätzlichen Bits werden folgendermaßen abgearbeitet:

    for(i = 7; i > bitoff; i--)                 // broken bytes
      send_bit(msg[j] & _BV(i));

bitoff ist die Zahl, die aus deinem String des Raw-Kommandos stammt. Es ist also falsch herum. Mit einer 0 sendest du also 7 zusätzliche Bits... Bei meinem Telegramm sende ich sechs bytes plus zwei bits es muss bei mir folgendermaßen aussehen:
G0A65F132171732885A94F4A50FC0
komischerweise funktioniert etwas anderes nicht:
G0A27F1321717325555 sehe ich zwar auf dem Oszilloskop aber der zweite CUL empfängt es nicht.
Mache ich statt dessen
G0A26F1321717325555
kommt das Telegramm an und wird als zwei Bytes ohne zusätzliche Bits mit X77 angezeigt...

[C_Herrmann]

Hallo atietzel,

Die zusätzlichen Bits werden folgendermaßen abgearbeitet:

    for(i = 7; i > bitoff; i--)                 // broken bytes
      send_bit(msg[j] & _BV(i));

ich hatte das auch schon gefunden. Da es der Protokollbeschreibung in culfw.de widerspricht, hatte ich in der Gruppe CUL-Entwicklung-Fehlerberichte unter http://forum.fhem.de/index.php/topic,19999.0.html weitere Angaben gemacht. Ich hätte in diesem Thread einen Hinweis darauf geben sollen.

bitoff ist die Zahl, die aus deinem String des Raw-Kommandos stammt. Es ist also falsch herum. Mit einer 0 sendest du also 7 zusätzliche Bits...

Das finde ich verwirrend. Um keine broken Bits zu senden, muss 7 oder 8 - F eingegeben werden. Es scheint der FS20-Kompatibilität geschuldet zu sein.

komischerweise funktioniert etwas anderes nicht:
G0A27F1321717325555 sehe ich zwar auf dem Oszilloskop aber der zweite CUL empfängt es nicht.
Mache ich statt dessen
G0A26F1321717325555
kommt das Telegramm an und wird als zwei Bytes ohne zusätzliche Bits mit X77 angezeigt...

Sendetests mit Deinen Strings und dem DVB-T Stick als Empfänger zeigen dies:
G0A27F1321717325555 ergibt 10*0 + 1*1 als Sync 5 5 5 5.
G0A26F1321717325555 ergibt 10*0 1*1 als Sync 5 5 5 5 und ein 1er Bit.
Seltsam, dass das letzte Bit bei Dir nicht empfangen wird. Vielleicht wird es als Parity oder Checksum interpretiert und deswegen nicht angezeigt.

Wenn ich 1 Byte für die broken Bits anhänge, werden diese Datagramme gesendet:
G0A26F1321717325555FF ergibt das Gleiche wie ohne broken Bits.
G0A26F132171732555500 hat am Ende ein 0er Bit statt 1er Bit. Der Rest ist gleich.


Gruß,
Christian

[atietzel]

Hallo atietzel,

ich hatte das auch schon gefunden. Da es der Protokollbeschreibung in culfw.de widerspricht, hatte ich in der Gruppe CUL-Entwicklung-Fehlerberichte unter http://forum.fhem.de/index.php/topic,19999.0.html weitere Angaben gemacht. Ich hätte in diesem Thread einen Hinweis darauf geben sollen.

Ok, dann wird sich da ja schon drum gekümmert...

Das finde ich verwirrend. Um keine broken Bits zu senden, muss 7 oder 8 - F eingegeben werden. Es scheint der FS20-Kompatibilität geschuldet zu sein.

nach dem Code ist für "kein zusätzliches" Bit alles ab 7 inclusive gültig. Das erste zusätzlich Bit wird mit 6 gesendet...

Sendetests mit Deinen Strings [...]
Seltsam, dass das letzte Bit bei Dir nicht empfangen wird. Vielleicht wird es als Parity oder Checksum interpretiert und deswegen nicht angezeigt [...]

Ich habe mittlerweile die Erfahrung gemacht, das der "Slow-RF" Mode in der Implementierung mit dem 8 MHz getakteten Atmega durchaus durch die Interruptroutinen (125Hz) beim Senden Jitter erzeugt und im Fall des Empfangens dann durchaus noch mal Jitter oben drauf kommt. Ich nutze einen CUL und ein CSM damit ist die Erkennung der Bitzellen manchmal wohl schon deutlich an der Kante. Anders kann ich mir das nicht erklären, auch wenn man dazu genauere Untersuchungen machen müsste.
Ich möchte ein Low-Power Projekt realisieren und wollte auf bestehende Protokolle aufbauen (S300TH senden und FHT8v Telegramme auswerten), damit es einfach wird. Stelle aber fest, dass ich höchst wahrscheinlich höherwertige Funktionen den CC1101 stärker nutzen möchte. Die simple Tastung ist mir insgesamt zu unsicher. Das mag auch ein Grund gewesen sein, warum e-Q3 mittlerweile auch in allen "höherwertigen" Produkten die Tastung nicht mehr verwendet und stattdessen auch auf höhere Funktionen des CC1101 ausgewichen sind. Nach Datenblatt ist das Ding ja recht interessant!
Also in sofern hat sich das Thema hier (fast) erledigt.

[C_Herrmann]

Hallo,

Ich möchte ein Low-Power Projekt realisieren und wollte auf bestehende Protokolle aufbauen (S300TH senden und FHT8v Telegramme auswerten), damit es einfach wird. Stelle aber fest, dass ich höchst wahrscheinlich höherwertige Funktionen den CC1101 stärker nutzen möchte. Die simple Tastung ist mir insgesamt zu unsicher. Das mag auch ein Grund gewesen sein, warum e-Q3 mittlerweile auch in allen "höherwertigen" Produkten die Tastung nicht mehr verwendet und stattdessen auch auf höhere Funktionen des CC1101 ausgewichen sind. Nach Datenblatt ist das Ding ja recht interessant!

Ich kann mich über die Zuverlässigkeit meiner FS20-Komponenten und FHT nicht beklagen. Sie laufen hier zuverlässig seit mehr als 3 Jahren unter Fhem. Probleme hatte ich nur mit den UNIRoll-Empfängern. Das lag aber nicht am CUL. Bei der Analyse habe ich die Datentelegramme ausgewertet und die Unstimmigkeit mit dem Broken Bit entdeckt. Wenn Du die Datentelegramme aus meinen ersten Beiträgen hier ansiehst, ist kein wesentlicher Jitter erkennbar. Solange die Puls-/Pausenzeiten nicht bis an die unterste Grenze ausgereizt werden, sollte es keine Probleme geben. Wenn Du die Nutzerstatistik auf http://fhem.de/stats/statistics.html ansiehst, ist FS20 das meistgenutzte System. Das wäre sicher anders, wenn die Zuverlässigkeit schlecht wäre.

Gruß,
Christian

[atietzel]

Ich habe auch etliche  FHT8v und einige FS20 Komponenten seit Jahren im Betrieb und kann mich nicht beschweren.
Bei dieser Kombination ist aber immer eine Komponente im Spiel, deren Inneres ich nicht kenne.
Ich sehe nur, dass wenn hier der original S300TH an einen Standard CUL sendet, dass es um einen deutlichen Faktor häufiger klappt, dass der CUL die Aussendung versteht, als wenn ich diese von einem CSM emuliert sende (ich habe auch schon mit unterschiedlichen Zeiten für die Bitzellen experimentiert, hat nicht viel gebracht). Wenn ich die RSSI-Messung einschalte sehe ich, dass es an der Feldstärke nicht liegen kann. Alle Komponenten sind unter drei Meter von einander entfernt. Wenn ich das Oszilloskop auf die entsprechenden Pins setze und mir ansehe, was hinter dem Empfangenden CC1101 Richtung Microcontroller geht, ist dort ein auf den ersten Blick sauberes Signal zu sehen (Jitter ist aber zu erkennen, ich habe jetzt gerade den Aufbau nicht hier und weiß nicht mehr, in welcher Größenordnung).

Trotzdem schwankt z.B. die erkannten Low-Low, Low-High, High-Low und High-High (weiß nicht, ob ich das jetzt richtig rum aufgezählt habe) Werte in der höchsten Stufe der Loggings (X77 oder so) recht deutlich. Das hat mich auf den Gedanken gebracht, dass die Effekte sich offensichtlich auf der Strecke CSM->CUL offensichtlich Summieren und bei der SlowRF durchaus zu einem Zustand führen, der nicht selten zu Fehlern führt. Im Übrigen werden die Aussendungen Richtung FS20 mehrfach wiederholt, was den Effekt deutlich abmildert.

Bei den FHT8v war ich es selbst, der vorgeschlagen hat auf Retransmissions zu verzichten und dafür lieber gelegentliche Aussetzer zu akzeptieren. Wie gesagt, es funktioniert hinreichend gut aber ist eben nicht besonders stabil. Wenn höhere Qualität in der Übertragungssicherheit gefordert ist, dann versteht man, warum da soviel (ausgefeilte) Logik im CC1101 drin ist. Und wie man sieht, geht die Zeit von FS20 Komponenten jetzt auch schon langsam zu Ende. Was durchaus schade ist, denn ich fand das Preis Leistungsverhältnis nicht schlecht.