[gelöst]FS20 Protokoll Codeumrechnung bzw. fs20send internas

Begonnen von KölnSolar, 02 Juli 2017, 18:39:59

Vorheriges Thema - Nächstes Thema

KölnSolar

Hallo zusammen,
ich versuche ja gerade meine Betty in einen CUL umzufunktionieren bzw. Funktionen der culfw zu benutzen. IT-Protokoll senden klappt schon mal bestens.

Nun hänge ich an FS20. In den internals eines in FHEM definierten Schalters steht: XMIT=35aa u. BTN=38. Ich rufe nun fs20send
mit char *schalter = "F35aa3811" u. fs20send(schalter) auf.

Die Daten kommen dort auch an und es werden nach der Umkodierung 5 Bytes nach den sync-bits gesendet: 0x35 0x55 0x0D 0x22 0x22.

Was ich dann nicht mehr in der Programmlogik verstehe: Darauf folgend gibt es einen Kommentar zu einem Programmblock "broken Bytes". bitoff ist 1, so dass nach meinem Verständnis weitere 5 bits eines bytes mit Wert 0xE0 gesendet werden.

Aufgrund des Kommentars "broken bytes" frage ich mich nun, ob ich fs20send mit anderen Daten hätte aufrufen müssen. Oder hat mich vielleicht nur der Kommentar in die Irre geleitet und dass dieser lediglich bedeutet, dass kein vollständiges byte gesendet wird ?

Kann mir jemand bestätigen, dass die Umkodierung des Protokolls korrekt ist? Dann würde der Fehler in meinen CC1100-Einstellungen liegen.
Grüße Markus

Edit: Falls mein Aufruf i.O. ist: Der CC1100 ist genau wie beim 433 Senden eingestellt. Lediglich die Frequenz habe ich für FS20 auf 868.35 umgestellt. Muss ich evtl. noch einen anderen Parameter des CC1100 ändern ? Vielleicht auch noch wichtig: Der CC1100 ist wohl ein 433er, also erwartete Leistung bei 868 eh gering.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

rudolfkoenig

Zitates werden nach der Umkodierung 5 Bytes nach den sync-bits gesendet
Ich habe jetzt keine Musse parity zu rechnen, aber mit Daten + checksum + parity komme ich auf 5 Bytes + 5 bits.
Zitatbitoff ist 1, so dass nach meinem Verständnis weitere 5 bits eines bytes mit Wert 0xE0 gesendet werden.
Der Code in sendraw sollte mit bitoff 1 nicht 5 sondern 6 Bits senden: Bit #7,6,5,4,3,2

KölnSolar

Vielen lieben Dank Rudi.

ZitatDer Code in sendraw sollte mit bitoff 1 nicht 5 sondern 6 Bits senden: Bit #7,6,5,4,3,2
Stimmt. Da hatte ich den Code falsch interpretiert.

Heute Nacht hat es sich dann aufgelöst  ;D Ich konnte nur nicht schreiben, weil die Forums-Webseite down war  >:(

Die Betty funkt nun auch auf 868 mit o.g. Aufruf der fs20send. Ich hatte mir ein "Pseudo-Debugging"(Ausgaben auf dem Betty-LCD) gebastelt, wodurch ich feststellte, dass ich noch an den credits scheiterte. Danach konnte ich zwar einen vollständigen Programmdurchlauf beobachten, aber keinen Empfang am CUL. Schließlich hab ich mit raw X39 gedebugged und siehe da, es kam "irgendwie" etwas am CUL an. Nur stimmten die timings oft ganz und gar nicht. Nachdem ich dann sehr detailliert das Empfangene analysiert hatte, fiel mir auf, dass genau mein Pseudo-Debugging zu starken Verzögerungen führte. Den Code wieder entfernt, redeten Betty u. CUL perfekt miteinander  ;D

Wie erwartet ist die Sendeleistung relativ schwach, aber da lässt sich u.U. noch etwas an der PA table feilen.
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt