Ein herzliches Hallo in die Runde,
ich habe im Bestand des Hauses eine Raumtemperatursteuerung von Eberle Typ Instat 868-r1. Leider findet sich in den Weiten des Netzes dazu nicht detailliertes, am passendsten waren noch 2 Themen hier, aber leider auch ohne Ergebnis.
Ziel ist ganz klar das Protokoll zu dekodieren und verwenden zu können.
Was ich bisher weiß, auch mit Hilfe des Wikis "Unbekannte Protokolle" hier und einem RTL-SDR mit URH :
868MHz, 2-FSK
Ein Protokoll mit 82 Bit hat die Form
0000000000001111111000000011000110011001010110101001100110101010011001010101010110
davon ist sind 34 Bit Präambel bzw Sync:
0000000000001111111000000011000110
Der folgende Teil
011001010110101001100110101010011001010101010110
ist mit ziemlicher Sicherheit Manchester-codiert. Decodierung verkürzt in dem Fall nur die Codelänge, hat mich aber bisher nicht weitergebracht, deshalb folgend immer in codierter Form:
Es kommen dann
- 24Bit für die Senderadresse
- 8 Bit für den Status des Thermostaten An/Aus
- 16 Bit mit unbekannter Verwendung
Nehme ich den mitgeschnittenen Rohdatencode für "An" bzw. "Aus" und sende über einen CC1101, kann ich das Ventil gezielt an- und ausschalten.
Und nun kommen die ungelösten Probleme, zuerst die letzten 16 bit: diese ändern sich, und wiederholen sich alle 16 Sendungen, sind aber bei verschiedenen Sendern nicht dieselben. Sende ich ohne einen Wechsel, geht der Empfänger auf Störung. Hat jemand eine Idee, weshalb diese Wechsel überhaupt nötig sind? Abschluß mit Paritätsbit kann ich ausschließen.
Dann der Code für An/Aus: der unterscheidet sich bei verschiedenen Sendern auch nach der Manchester-Decodierung, also "An" kann dann sein 1110 oder 0001.
Die Senderadresse wird für jedes Anlernen Sender/Empfänger immer wieder neu vergeben, da versuche ich derzeit herauszufinden was alles möglich sind, oder ob es da bestimmte Muster gibt.
Mit dem derzeitigen Stand kann ich lediglich wie ein Papagei nur bestehende Protokolle nachsprechen, muss also diese erst einmal mit einem Sender erzeugen und mitschneiden.
Leider habe ich auch kaum Erfahrung in dem Bereich, eventuell hat aber der ein oder andere hier ein paar Tips um dabei weiterzukommen.
Gruß,
Dieter
Zitatdie letzten 16 bit: diese ändern sich, und wiederholen sich alle 16 Sendungen, sind aber bei verschiedenen Sendern nicht dieselben. Sende ich ohne einen Wechsel, geht der Empfänger auf Störung.
Rolling-Code + CRC?
Meiner Erfahrung nach lohnt sich laenger nach Doku zu suchen.
Auch Beschreibungen von aehnlichen Geraeten vom gleichen Hersteller koennen als Ideengeber herhalten.
Und der Hersteller des Geraetes muss nicht gleich Hersteller des Protokolls sein.
Uebrigens: alle Achtung, ich kann mich an viele vergleichbare Sessions mit Kopfschmerzen danach erinnern :)
2.Post und dann sowas. Da kann ich Rudi nur zustimmen.
ZitatMeiner Erfahrung nach lohnt sich laenger nach Doku zu suchen.
Und auch da stimme ich ihm zu. Wenn man ein paar mehr Infos zum Funkprotokoll(Frequenz, Datenrate...) hat, kann man einen Abgleich mit der signalduino_protocols machen und vielleicht ist das Protokoll bereits vorhanden.
Grüße Markus
Das Protokoll hardcoremäßig zu zerlegen mache ich ja nur, weil ich nichts gefunden habe. Ich meine nach intensiver Suche. Mögliche Ähnlichkeiten waren bisher leider alles nichts.
Heißt das file komplett signalduino_protocols.pm?
Frequenz, Signallängen/Datenrate habe ich ja alles in der Zwischenzeit ausgelesen.
Leider gibt der Sender auch nach zerlegen nicht mehr Infos Preis, dass ein anderer Hersteller dahinterstecken könnte. Habe neben den bei mir aktiven jetzt noch Ersatz bekommen, älteren Datums, gleiche Beschriftung, unterschiedliche Hardware. Und leider auch unterschiedliches Protokoll. Aber da laufen die Tests noch.
Kein Rolling Code, soweit sicher. Der ist komplizierter. Und wiederholt sich auch nicht - zumindest nicht so schnell.
PS: das ist er zweite Winter an dem ich mich mit dem Teil beschäftige. Einfach ist doch langweilig :D
ZitatEinfach ist doch langweilig :D
stimmt. ;D
ZitatHeißt das file komplett signalduino_protocols.pm?
genau.
Und der Signalduino wäre auch genau die Hardware, die Du für die Anbindung an FHEM brauchst.
Kann es sein dass die Datei zwischenzeitlich "SD_ProtocolData.pm" heißt?
Die bin ich durch und habe auch speziell auf Thermostate geachtet, leider ohne Erfolg. Allein schon über die Tatsache, dass die ersten 3 Codes (0,1,2) bei mir später nicht mehr auftauchen, konnte man quasi alle bisher dokumentierten schon ausschließen.
Hier noch in SD-Notation:
P0=-4250;P1=2560;P2=-2570;P3=736;P4=-1080;P5=-378;P6=358;P7=-746 D=01234356567356565676565653565656765656565373565
Ich weiß, dass der Signalarduino die Hardware wäre, um es in FHEM einzubinden. Die Synology ist ja da, aber FHEM ohne eingehende Daten ist etwas öde :D Und zu steuern hat sie bisher auch nichts,
Es gibt
FSK_PCM:
- Es wird für RX und TX der FIFO des cc1101 verwendet.
- Damit der Begin der Nachricht erkannt wird muß ein SYNC angegeben werden.
- Es muß auch im FIFOTHR Reg ein threshold für den RX FIFO angegeben werden
und
FSK_PWM:
- es wird der asynchronous serial mode verwendet (RX: Data out GDO2, TX: GDO0)
- der cc1101 FIFO wird nicht verwendet
siehe
https://forum.fhem.de/index.php/topic,106594.msg1150650.html#msg1150650
Zitat
P0=-4250;P1=2560;P2=-2570;P3=736;P4=-1080;P5=-378;P6=358;P7=-746 D=01234356567356565676565653565656765656565373565
dies ist der asynchronous serial mode
Gruß Ralf
FSK-PCM und FSK-PWM und asynchron serial mode sind doch nur für Empfang bzw. Senden per CC1101 relevant oder?
Ich mache Signalanalyse derzeit nur per SDR und URH. Ein initialer Test mit versenden von Rohdaten per CC1101 aus der Arduino-IDE hatte nach Baudratenanpassung ja funktioniert. Wie gesagt, ein Signalarduino ist ja noch nicht in Betrieb, ich sehe derzeit aber auch noch keinen Vorteil ggüber SDR solange ich nicht sicher weiß, was für Daten da unterwegs sind. Und man weiß da nie genau, ob die Daten exakt stimmen oder ein Parameter nicht gestimmt hat und nur Kauderwelsch ankommt. Das Thema hatte ich schon mit der Wetterstation, seither immer per SDR.
Verbaut sind in den Thermostaten vermutlich TDA5100 bzw. TDK5100 als Sende-IC, habe mich aber nicht weiter damit beschäftigt weil die ja nur ausgeben was ihnen übermittelt wird.
Der verlinkte Thread ist interessant übrigens. Dauert aber noch bis ich komplett durch bin.
PS: habe mir zwischenzeitlich die Eigenschaft der Teile zu Nutze gemacht, beim Anlernen jedesmal eine neue ID zu erzeugen. Es muss noch durch ein paar Hirnwindungen, aber ich denke den Teil kann ich bald selber erzeugen.
ZitatFSK-PCM und FSK-PWM und asynchron serial mode sind doch nur für Empfang bzw. Senden per CC1101 relevant oder?
Ja
ZitatUnd man weiß da nie genau, ob die Daten exakt stimmen oder ein Parameter nicht gestimmt hat und nur Kauderwelsch ankommt.
Ja, beim cc1101 muß z.B. die datarate recht genau passen. Einige der Parameter müssten sich evtl aus dem Datenblatt und der Beschaltung des Sende IC ermitteln lassen.
Wenn die Senderadresse und der Status des Thermostaten An/Aus immer gleich sind, sollten die Parameter eigentlich passen.
Beim signalduino wird direkt der decodierte Manchester Code ausgegeben
z.B. dies hier
P0=-4250;P1=2560;P2=-2570;P3=736;P4=-1080;P5=-378;P6=358;P7=-746;D=01234356567356565676565653565656765656565373565;wird so ausgegeben
MC;LL=-746;LH=736;SL=-378;SH=358;D=88787D0;C=369;L=26;s5;b5;
Das Protokoll beim Einlernen habe ich nun zu 95% geklärt. Diesmal nach Manchesterdecoding um Zahlenwerte zu erhalten:
12 Bit Sender ID, theoretisch 0-4095 (000 - FFF), die Praxis zeigt zwar mehr Werte in der Mitte als an den Rändern, Mittelwert ist 2079 - ich denke das passt
4 Bit An/Aus: 0xC oder 0x 3, "3" sofern ID ungerade, "C" wenn gerade - ich denke das passt
8 Bit davon 4 Bit Verwendung noch unklar, bzw. im Widerspruch zum Thermostatbetrieb (da gibt es keine Korrelation zu An/aus). Hier Werte 0x5 oder 0xA, immer als C5 oder 3A in Abhängigkeit von An/Aus - ich denke das passt
davon 4 Bit Verwendung noch unklar, vermutlich zufällig 0-15 (0-F), Werte 0 .. E sind bestätigt, allerdings ist der Mittelwert 5,5 und damit unterschiedlich zu Sollwert 7,5 - möglicherweise doch CRC oder andere Fehlerkorrektur
Leider kenne ich mich zu wenig in der Theorie der Fehlerkorrektur aus, um da etwas gezielt nachzuprüfen. Als Test werde ich nun mal einen Code erzeugen und zum einlernen verschicken. Und dann nochmals mit anderem Finale. Wenn er keinen nur einen nimmt, ist es wohl Fehlerkorrektur und ich habe zufällig richtig geraten. Nimmt er beide hat es eine andere Bedeutung oder eben keine bzw. ist noch nicht definiert.
Eine Frage: kann man per FHEM solch eine Logik implementieren? Also wenn ID ungerade, dann nächster Code "soundso"?
Zitat von: Ralf9 am 24 Dezember 2021, 17:52:27
MC;LL=-746;LH=736;SL=-378;SH=358;D=88787D0;C=369;L=26;s5;b5;
Danke, das verstehe ich zum Großteil, bzw. bis zum "C=". Gibt es da ein Tutorial dafür, bzw. wofür steht C,L,s5 und b5?
ZitatDanke, das verstehe ich zum Großteil, bzw. bis zum "C=". Gibt es da ein Tutorial dafür, bzw. wofür steht C,L,s5 und b5?
C ist die Clock
L ist die Länge in Bits
s und b sind debugausgaben
Eine Schwierigkeit beim Manchesterdecoding ist die richtige Flanke (pos oder neg) am Anfang zu finden, damit die dekodierte Nachricht nicht invertiert ist, da beim ersten Long mit der dekodierung angefangen wird, gelingt dies zuverlässig.
b sind die Anzahl der Pulse bis zum ersten Manchesterbit, dies ist die Länge der Präambel bzw Sync
s sind die Anzahl der Pulse bis zum ersten Long
wenn s und b gleich sind, ist das long am Anfang der Manchesternachricht
Hallo nochmals,
zwischenzeitlich bin ich bei der Dekodierung der Lerncodes etwas weiter gekommen, leider aber nur ein wenig und jetzt klemme ich ganz. ich bin mir sicher, dass die letzten 4 Bits eine Art Prüfsumme sind. Sende ich Code an den Empfänger, wird von den 16 Möglichkeiten immer nur genau eine akzeptiert. Leider konnte ich aber bisher keine allgemeine Systematik bestimmen, nur einzelne Regeln. CRC konnte ich ausschließen, es gibt ja aber fast beliebig viele Möglichkeiten so einen Prüfcode zu berechnen. Ich habe nun systematisch zu einigen IDs einen Prüfcode ermittelt, komme aber hier nicht weiter. Hat jemand noch eine Idee?
Regeln:
- der Prüfcode wird aus den 3 Werten der ID errechnet
- der Prüfcode ist nicht eindeutig für alle Werte eines Blocks/ID
- Wert und Komplementärwert zu 15 (ID3) haben gleichen Code (7/8; 6/9; 5/10; etc)
- bestimmte Bitfolgen ergeben gleichen Prüfcode, wie "0001" über alle 3 IDs, oder die verschobenen "11"er
- keine Regel aber auffällig: so gut wie alle Prüfcodes meiner Muster sind gerade, nicht ungerade. Bei zufälligen IDs war es nahezu 50/50
Irgendwie habe ich das Gefühl, etwas wichtiges übersehen zu haben. Jegliche Idee oder Theorie ist willkommen, ich habe die aktuell verfügbaren Werte mal unten angehängt. Auch kann ich jeglichen anderen Wert generieren um eine Theorie zu bestätigen oder auszuschließen. Mir fehlt zB noch jegliche Idee, wie der Prüfcode sich um "1" erhöhen oder verringern lässt. Aber möglicherweise ist das auch nicht relevant.
Gruß,
Dieter
ID1 ID2 ID3 Code ID1 ID2 ID3 Code
0000 0000 0001 1010 0x0 0x0 0x1 0xA
0000 0000 0010 0110 0x0 0x0 0x2 0x6
0000 0000 0011 1000 0x0 0x0 0x3 0x8
0000 0000 0100 0000 0x0 0x0 0x4 0x0
0000 0000 0101 1110 0x0 0x0 0x5 0xE
0000 0000 0110 0010 0x0 0x0 0x6 0x2
0000 0000 0111 1100 0x0 0x0 0x7 0xC
0000 0000 1000 1100 0x0 0x0 0x8 0xC
0000 0000 1001 0010 0x0 0x0 0x9 0x2
0000 0000 1010 1110 0x0 0x0 0xA 0xE
0000 0000 1011 0000 0x0 0x0 0xB 0x0
0000 0000 1100 1000 0x0 0x0 0xC 0x8
0000 0000 1101 0110 0x0 0x0 0xD 0x6
0000 0000 1110 1010 0x0 0x0 0xE 0xA
0000 0000 1111 1000 0x0 0x0 0xF 0x8
0000 0000 0001 1010 0x0 0x0 0x1 0xA
0000 0000 0010 0110 0x0 0x0 0x2 0x6
0000 0000 0100 0000 0x0 0x0 0x4 0x0
0000 0000 1000 1100 0x0 0x0 0x8 0xC
0000 0001 0000 1010 0x0 0x1 0x0 0xA
0000 0010 0000 0110 0x0 0x2 0x0 0x6
0000 0100 0000 0000 0x0 0x4 0x0 0x0
0000 1000 0000 1100 0x0 0x8 0x0 0xC
0001 0000 0000 1010 0x1 0x0 0x0 0xA
0010 0000 0000 0110 0x2 0x0 0x0 0x6
0100 0000 0000 0000 0x4 0x0 0x0 0x0
1000 0000 0000 1110 0x8 0x0 0x0 0xE ?Warum nicht "C"?
0000 0000 0011 1000 0x0 0x0 0x3 0x8
0000 0000 1100 1000 0x0 0x0 0xC 0x8
0000 0011 0000 1000 0x0 0x3 0x0 0x8
0000 1100 0000 1000 0x0 0xC 0x0 0x8
0011 0000 0000 1000 0x3 0x0 0x0 0x8
0000 0000 0110 0010 0x0 0x0 0x6 0x2
0000 0110 0000 0010 0x0 0x6 0x0 0x2
0001 1000 0000 0010 0x1 0x8 0x0 0x2
0110 0000 0000 0010 0x6 0x0 0x0 0x2
0100 0000 0010 0011 0x4 0x0 0x2 0x3 verstehe ich gar nicht?
0000 1111 0000 0011 0x0 0xF 0x0 0x3 verstehe ich gar nicht?
Mit den wenigen Infos ist es schwer zu helfen, Du hast bis jetzt nur Teile der Nachrichten gepostet.
Zitat12 Bit Sender ID, theoretisch 0-4095 (000 - FFF), die Praxis zeigt zwar mehr Werte in der Mitte als an den Rändern, Mittelwert ist 2079 - ich denke das passt
4 Bit An/Aus: 0xC oder 0x 3, "3" sofern ID ungerade, "C" wenn gerade - ich denke das passt
8 Bit davon 4 Bit Verwendung noch unklar, bzw. im Widerspruch zum Thermostatbetrieb (da gibt es keine Korrelation zu An/aus). Hier Werte 0x5 oder 0xA, immer als C5 oder 3A in Abhängigkeit von An/Aus - ich denke das passt
davon 4 Bit Verwendung noch unklar, vermutlich zufällig 0-15 (0-F), Werte 0 .. E sind bestätigt, allerdings ist der Mittelwert 5,5 und damit unterschiedlich zu Sollwert 7,5 - möglicherweise doch CRC oder andere Fehlerkorrektur
Demnach besteht die Nachricht nach der Manchester Dekodierung aus 24 Bit (6 Hexziffern)
Geht die Manchester Dekodierung der empfangenen Nachrichten inzwischen automatisch?
Sind die ID 1, ID 2, ID 3 die 12 Bit Sender ID? Wann ändert sich die ID?
Bleibt der 4 Bit Code bei gleicher Sender ID gleich?
123456
IIISXY
III - Sender Id
S - 4 Bit An/Aus: 0xC oder 0x 3, "3" sofern ID ungerade, "C" wenn gerade - ich denke das passt
X -
Y - Prüfcode?Hast Du auch schon was zu X rausgefunden?
Kannst Du mal ca 20 - 50 der Hexnachrichten (6 Ziffern) posten? Mit verschiedenen und gleichen Sender Id, und An und Aus beschriften
Gruß Ralf
Hallo Ralf,
seither habe ich tatsächlich noch wesentliche Fortschritte gemacht, aktuell klemmt es tatsächlich erst einmal / nur noch an der Prüfsumme.
Ich habe über die Tage eine Vielzahl an Telegrammen mitgeschnitten und ausgewertet, alle der Einfachheit für das einlernen. Eine Vielzahl an Telegrammen habe ich mehrfach und sie sind dann identisch, also keine Art an rolling code an der Stelle. Insgesamt ~900 Möglichkeiten, nicht die Erwarteten ~4000 (FFF). Manchesterdecodierung mache ich aktuell manuell per Excel.
Es sind immer Header (2Bit, nicht dargestellt) und 6 Nibbles, die Reihenfolge ist Original, die Gruppierung in ID1-3, Par1/2 und Prüfsumme von mir. Einen ersten Test für die Prüfsumme hatte ich mit reveng auf CRC gemacht, leider ohne Erfolg (no models found).
Fokussierung auf einfache ID-Werte, also "000" bis "00F". Bei diesen ergibt sich die Prüfsumme durch einfaches Xor von ID1-3, einem der beiden Par-Nibble und magicNumber "8".
Sobald aber einer der ID1/2 nicht mehr "0" ist, passt die Berechnung nicht mehr. Dass die MagicNumber insgesamt variiert wäre ja noch OK, aber besonders seltsam finde ich zB "FFx" bei der von "FF7" nach "FF8" bis "FFA" eine andere MagicNumber nötig wäre, und dann noch zwei weitere für den Rest.
Berechne ich die MN komplett aus ID1-3, Par und PS über alle Werte, ergeben sich eine Art von Muster, aber ohne dass ich darin eine Art an Systematik erkennen würde. Lediglich für Gerade und Ungerade aufeinander folgende IDs ist die MN aber immer dieselbe.
Die Liste aller Codes ist angehängt, keine Ahnung ob das Format so passend ist.
Gruß,
Dieter
000 C5 4 001 3A A 002 C5 6 003 3A 8 004 C5 0 005 3A E 006 C5 2 007 3A C 008 C5 C 009 3A 2 00A C5 E 00B 3A 0 00C C5 8 00D 3A 6 00E C5 A 00F 3A 4
8A0 C5 4 8A1 3A A 8A2 C5 6 8A3 3A 8 8A4 C5 0 8A5 3A E 8A6 C5 2 8A7 3A C 8A8 C5 C 8A9 3A 2 8AA C5 E 8AB 3A 0 8AC C5 8 8AD 3A 6 8AE C5 A 8AF 3A 4
FF0 C5 4 FF1 3A A FF2 C5 6 FF3 3A 8 FF4 C5 0 FF5 3A E FF6 C5 2 FF7 3A C FF8 C5 B FF9 3A 5 FFA C5 9 FFB 3A 7 FFC C5 C FFD 3A 2 FFE C5 F FFF 3A 1
850 C5 4 851 3A A 852 C5 6 853 3A 8 854 C5 0 855 3A E 856 C5 2 857 3A C 858 C5 B 859 3A 5 85A C5 9 85B 3A 7 85C C5 C 85D 3A 2 85E C5 F 85F 3A 1
Ist das der Sender?
https://www.heizungslabel.de/sites/default/files/data/Eberle/files_public/3333-9.pdf
Die Hexcodes die Du gepostet hast, sind die alle bei aktiviertem Lernmodus?
Ändert sich der Hexcode, wenn der Lernmodus beendet ist?
Laut der Anleitung hat er die folgende Betriebsarten, werden diese in der 4. und 5. Stelle übertragen. Bleibt bei Änderung der Betriebsart der Prüfcode gleich?
Komforttemperatur
Absenktemperatur 2 K
Absenktemperatur 4 K
Aus
Zitat von: Ralf9 am 14 Januar 2022, 18:48:18
1) Ist das der Sender?
2) Die Hexcodes die Du gepostet hast, sind die alle bei aktiviertem Lernmodus?
3) Ändert sich der Hexcode, wenn der Lernmodus beendet ist?
4) Laut der Anleitung hat er die folgende Betriebsarten, werden diese in der 4. und 5. Stelle übertragen. Bleibt bei Änderung der Betriebsart der Prüfcode gleich?
1) ja
2) ja
3) ja
4) nein / nein
Die Betriebsarten werden imho gar nicht übertragen, der Sender/Thermostat sendet im normalen Betriebsmodus immer nur An/Aus. Von der Intelligenz dahinter geht nur das Ergebnis nach draussen: An/Aus. Und da "zählt" er dann weiter, aber auch immer mit Prüfsumme.
Um mir das Problem zu vereinfachen habe ich deshalb ja auf Lernmodus geschalten. Auch konnte ich da das Senden so forcieren, dass ich in annehmbarer Zeit auf die Anzahl an Codes gekommen bin. Sonst müsste ich ja immer 10min warten. Und da, soweit meine Einschätzung, die ID immer in den Prüfcode mit eingeht, wollte ich da maximale Anzahl an Werten haben, um den Algorithmus für den Prüfcode daraus rückrechnen zu können.
Der Ansatz hat ja ansatzweise auch funktioniert :P
Demnach sendet er im deaktiviertem Lernmodus nur alle 10 Min
Wie oft sendet er bei aktiviertem Lernmodus.
Kannst Du bitte mal die folgenden Hexnachrichten posten? alles mit der selben ID
bei aktiviertem Lernmodus: 2-3 Hexnachrichten
bei deaktiviertem Lernmodus:
Aus: 2 Hexnachrichten
Ein: 1-2 Hexnachrichten
Aus: 1 Hexnachricht
Ein: 1 Hexnachricht
Im Lernmodus sendet er alle ~6s, immer denselben Code
Voila. Nach erfolgreichem Einlernen kommt immer noch ein Reset aus mehreren Telegrammen, beginnend mit eigentlichem Reset plus An/Aus Serie. Das habe ich der Vollständigkeit aufgenommen, vor den manuellen Wechseln An/Aus.
Fällt mir da gerade auf: diese Telegramme sind mit einem anderen Sender aufgenommen wie die anderen, der hatte die ID D14 nicht im Programm. Die beiden unterscheiden sich in der Hardware und auch Details im Sendeprotokoll (Initialisierung), aber nicht dem eigentlichen Datenteil. Möglicherweise wurden die neue Softwarerevision um weitere ID-Bereiche erweitert. Beide werden aber vom Empfänger sauber erkannt.
Status Hex
Lernen D14 C5 D
Lernen D14 C5 D
Reset D14 45 6
Reset D14 AD 7
Reset D14 1D 6
Reset D14 A9 3
Reset D14 19 2
Reset D14 AE B
Reset D14 1E A
Reset D14 AB 1
Reset D14 A4 6
Aus D14 AC 9
Aus D14 A3 D
Ein D14 17 C
Ein D14 18 C
Aus D14 AF 5
Ein D14 1F 4
Dies gibt einige neue Erkenntnisse.
Die Prüfziffer wird aus den ersten 5 Hexziffern gebildet.
Die 5. Ziffer sieht nach einer Art Rolling Code aus.
Aus D14 AC 9
Aus D14 A3 D
Ein D14 17 C
Ein D14 18 C
Aus D14 AF 5
Ein D14 1F 4
Sind zwischen allen diesen Nachrichten jeweils ca 10 Minuten Abstand?
Die 2. und 3. Nachricht fallen aus der Reihe. Bei den anderen bleibt bei einem Wechsel von Aus nach Ein die 5.Ziffer gleich.
Wenn Du eine Aus- und Ein Nachricht mehrmals sendest, werden diese dann auch mehrmals erkannt?
Zitat von: Ralf9 am 15 Januar 2022, 10:52:28
1) Die Prüfziffer wird aus den ersten 5 Hexziffern gebildet.
2) Die 5. Ziffer sieht nach einer Art Rolling Code aus.
3) Sind zwischen allen diesen Nachrichten jeweils ca 10 Minuten Abstand?
Die 2. und 3. Nachricht fallen aus der Reihe. Bei den anderen bleibt bei einem Wechsel von Aus nach Ein die 5.Ziffer gleich.
4) Wenn Du eine Aus- und Ein Nachricht mehrmals sendest, werden diese dann auch mehrmals erkannt?
1) glaube ich auch. Wenn ich im Lernmodus bei 00x den dritten/vierten Nibble nicht auf gerade/ungerade anpasse, aber den für die ID richtigen Prüfcode nehme, wird das auch nicht erkannt.
2) jein. Bei An/Aus wird diese jedesmal geändert, ist aber bald durch, da ja nur 16 Möglichenkeiten vorhanden
3) nein, wenn ich Solltemperatur ändere von min nach max sendet derThermostat gleich ein An/Aus, nur wenn es gleich bleibt muss ich notgedrungen die 10min warten
4) mehrmals senden wird mit Fehler quittiert am Empfänger
Obiges leuchtet mir völlig ein. Auch der Wert des 5. Nibbles ist quasi egal, sofern er sich nur vom vorigen unterscheidet. Sonst 4). Also der kann beim Wechsel von An nach Ausschalten gleich bleiben, muss aber nicht. Wichtig ist nur dass er sich ändert wenn der Schaltzustand konstant bleibt.
Bleibt der letzte Nibble, der zur Überprüfung notwendig ist und korrekt sein muss.
Dies senden wird demnach nicht erkannt
Aus D14 AF 5
Ein D14 1F 4
Aus D14 AF 5
Ein D14 1F 4
Und dies senden?
Aus D14 A3 D
Ein D14 17 C
Aus D14 AF 5
Ein D14 1F 4
Aus D14 A3 D
Ein D14 17 C
Jeglichen An/Aus Wechsel hatte er eigentlich immer erkannt, es ändert sich ja auch was im Code. Nur wenn sich der Status nicht ändert, und der Code derselbe blieb, gab es Fehler. Das geschieht aber auf einer zweiten Ebene der Fehlererkennung, weil der eigentliche Code ja richtig ist.
Mein Testsender ist gerade nur umgebaut, so dass ich es derzeit nicht sicher verifizieren kann.
Ohne Algorithmus/Berechnung für die Prüfsumme kann ich halt keinen gültigen Code erzeugen, nur einen nehmen von dem ich weiß dass er funktioniert. Daran scheitert es derzeit.
Beim Algorithmus/Berechnung des Prüfcodes kann ich leider nicht weiterhelfen.
@elektron-bbs ist bei sowas normalerweise recht gut. Liest Du hier mit?
oder hat jemand anders eine Idee?
Wenn sich der Code nur ändern muß, müsste es zum Schalten evtl reichen, wenn 2 Ein- und 2 Aus Nachrichten aufgezeichnet werden.
Z.B.
Aus D14 A3 D
Ein D14 17 C
Aus D14 AF 5
Ein D14 1F 4
Dann:
Ein D14 17 C
Ein D14 1F 4
Ein D14 17 C
Aus D14 AF 5
Aus D14 A3 D
Ein D14 17 C
Aus D14 A3 D
Ja, die simpelste aber für mich eher unbefriedigende Lösung ist eine Tabelle mit IDs (ich glaube 20 sollten in allen Fällen reichen) und den dazugehörigen Codes zum Einlernen, Reset und Schalten mit jeweiliger Prüfsumme.
In jedem Fall wäre aber komplette Generierung der bessere Weg. Und einen Teil davon habe ich ja schon, fehlt der letzte Schritt.
ZitatJa, die simpelste aber für mich eher unbefriedigende Lösung ist eine Tabelle mit IDs (ich glaube 20 sollten in allen Fällen reichen) und den dazugehörigen Codes zum Einlernen, Reset und Schalten mit jeweiliger Prüfsumme.
Sowas liese sich auch in einem fhem Modul programmieren
So richtig sehe ich bei den Nachrichten noch nicht durch. Poste doch einfach erstmal, was das Teil sendet, wenn du es in Ruhe lässt, möglichst so, das nur ein Zustand gesendet wird. Also mal eine Stunde mit Zustand an und eine Stunde mit aus. Da sehen wir zumindest, ob ein rolling code im Spiel ist.
Das habe ich schon analysiert, es gibt einen quasi-Rollingcode über 16 Werte, 0-F. Anbei der aktuelle Stand meiner Analyse zu den Sendeprotokollen, ich hoffe das ist so verständlich.
Es gibt noch bestimmte Lücken, so weiß ich nicht 100%ig sicher ob die Reihenfolge der Rollingcodes bei allen gerade/ungerade IDs immer dieselbe ist. Für An/Aus unterscheidet sie sich zumindest. Nach meinen Tests spielt das aber wohl zumindest mit dem Softwarestand meines Empfängers keine Rolle. Zusätzliche/Andere Werte kann es aber nicht geben.
Auch habe ich den Teil2 des Resets noch nicht im Detail analysiert, der Empfänger reagiert zwar mit An/Aus aber bis auf den letzten scheinen es keine regulären An/Aus Codes zu sein.
Generell:26 Bit, 2Bit Header, 24 Bit Daten
(1) Lerncode, 24Bit in 6 Nibbles
xxx x x x
|| || || ||
|| || || \/
|| || || Prüfcode 0-F
|| || \/
|| || Parität ID ungerade: A
|| || ID gerade: 5
|| \/
|| Lernen ID ungerade: 3
|| ID gerade: C
\/
ID: 000-FFF, zufällige Änderung bei jedem Lernen
(2) Reset#1, 24Bit in 6 Nibbles
xxx x x x
|| || || ||
|| || || \/
|| || || Prüfcode 0-F
|| || \/
|| || Parität ID ungerade: A
|| || ID gerade: 5
|| \/
|| Reset ID ungerade: B
|| ID gerade: 4
\/
ID: 000-FFF, immer gleich
(2) Reset#2-#9, 24 Bit in 6 Nibbles
xxx x x x
|| || || ||
|| || || \/
|| || || Prüfcode 0-F
|| || \/
|| || An/Aus Schema, noch nicht näher analysiert
|| ||
|| \/
|| An/Aus Schema, noch nicht näher analysiert
|| Reihenfolge: Aus-An-Aus-An-Aus-An-Aus-Aus
\/
ID: 000-FFF, immer gleich
(3) Schaltbetrieb An, 24 Bit in 6 Nibbles
xxx x x x
|| || || ||
|| || || \/
|| || || Prüfcode 0-F
|| || \/
|| || Rollingcode ID ungerade (1 Sender): C, 3, 8, 7, F, 0, A, 5, D, 2, 9, 6, E, 1, B, 4, C
|| || ID gerade:
|| \/
|| An ID ungerade: E
|| ID gerade: 1
\/
ID: 000-FFF, immer gleich
(3) Schaltbetrieb Aus, 24 Bit in 6 Nibbles
xxx x x x
|| || || ||
|| || || \/
|| || || Prüfcode 0-F
|| || \/
|| || Rollingcode ID ungerade (1 Sender): F, 5, A, 2, D, 6, 9, 1, E, 4, B, 3, C, 7, 8, 0, F
|| || ID gerade:
|| \/
|| Aus ID ungerade: 5
|| ID gerade: A
\/
ID: 000-FFF, immer gleich
Ohne komplette Nachrichten kann ich nichts analysieren!
Irgendwie sieht es so aus, als ob immer nur etwas invertiert wird:
|| || Parität ID ungerade: A
|| || ID gerade: 5
|| Lernen ID ungerade: 3
|| ID gerade: C
|| || Parität ID ungerade: A
|| || ID gerade: 5
|| Reset ID ungerade: B
|| ID gerade: 4
|| An ID ungerade: E
|| ID gerade: 1
Oder du hast die Datenrate nicht passend eingestellt, so das sich eine Bitverschiebung ergibt.
Lade mal einige Aufzeichnungen von URH hoch.
Die Daten sind Manchestercodiert, die Datenrate ergibt sich da doch schon direkt aus dem Takt. Da sehe ich kein Fehlerpotential. Siehst du das anders?
Für die Nibbles 4 und 5 ist das relativ einfache "wenn-dann Logik", da fehlt eigentlich noch die Zusammenfassung und gut. Ja, das Protokolldesgn arbeitet da eben sehr stark mit bitinvertierten Codes, auch wenn ich mich die Frage warum es so gemacht wurde nicht klar ist. Aber, so fragen kann/darf man halt nicht immer. Ich verstehe zB auch nicht, warum ein Nibble mit Paritätscode plus ein extra Prüfcode existiert. Ist halt so und gut.
Nibble 6 ist für mich der aktuelle Knackpunkt weil der über Validität des Codes entscheidet.
Komplette Nachrichten habe ich doch schon hochgeladen, siehe post vom 14 Januar 2022, 13:21:55. Sogar das komplette File mit ~900 Datenpaketen. Klar kann ich dir auch die Rohdaten inklusive Replikationen geben. Nur der Mehrwert ist mir nicht klar, es sei denn du erwartest, dass deine Decodierung etwas anderes ergibt.
Einzig dass bei denen sich immer die ID ändert, aber eben nur die. Ähnliches hast kann ich auch für die An / Aus Serie machen, aber ich ar der Meinung an den IDs sieht man den Einfluß auf den Prüfcode besser. bei An/Aus ändert sich ja nur der RollingCode von 1-F, und damit der Prüfcode.
Mich machte schon in deiner ersten Nachricht stutzig, das da so viele Nullen in Folge, dann Einsen und wieder Nullen die Präambel sein sollen. Bei 2-FSK ist als Präambel eigentlich ein mehrmaliger Bitwechsel üblich, wie z.B. 0xAAAAAAAA.
Dann schreibst du etwas später:
ZitatHier noch in SD-Notation:
P0=-4250;P1=2560;P2=-2570;P3=736;P4=-1080;P5=-378;P6=358;P7=-746 D=01234356567356565676565653565656765656565373565
Das deutet auf eine sehr niedrige Datenrate hin. Diese großen Puls-/Pausezeiten kenne ich eigentlich eher bei ASK/OOK.
Ja, das war ein Protokoll mit neuer Softwarerevision. Ich habe zwischenzeitlich auch welche mit alter Softwarerev, aber da ist der Frequenzshift deutlich kleiner, und damit bekomme ich über URH die Signale fast nicht mehr aus dem Rauschen heraus. Das mag aber an meinen nicht ganz optimierten Parametern oder auch dem SDR liegen.
Aber ich stimme dir voll zu, diese Art an Protokoll entspricht nicht dem, was man für FM erwartet, speziell der eigentlich fehlende Synchronisationszyklus. Hat mich am Anfang auch stark verwirrt. Ist es aber mit Sicherheit. Das ist ja das schöne am SDR, dass man es mit eigenen Augen sehen kann. Übrigens auch der kleinere Frequenzshift, die beiden "Hörner" liegen da ziemlich nahe beieinander.
Die "000" oder -1080 ist aber in beiden Fällen der Übergang zum eigentlichen Datenpaket. Ich glaube, was davor kommt ist dem Empfänger relativ egal. Und für die paar Bit braucht es ja auch keine hohe Datenrate. Zwischenzeitlich hatte ich auch schon die Vermutung, das Protokoll ist, eventuell sogar bewusst, unnötig verkompliziert worden ohne aber richtige Verschlüsselung zu nutzen.
Hardwaretechnisch wird das ganze Protokoll übrigens komplett vom Controller erzeugt, also inkl. Manchestercodierung und Präambel. Der Sender ist ein TDK/TDA5100, also Steinzeittechnik gegenüber einem CC1101.
Aktualisierter Zwischenstand: ich habe mir bisher vergeblich an der Methode zur Prüfsumme die Zähne ausgebissen. Es ist ein XOr und doch nicht. Irgeneine Komplikation ist noch einprogrammiert die ich nicht durchschaue. Nur falls noch jemand reinschaut und eine Idee hat. Ansonsten packe ich bei Gelegenheit die ausgelesenen Werte von 10 IDs zusammen, und man kann halt die Sensornummer nicht frei wählen sondern nur aus der gegebenen Anzahl wählen.
Ich hätte nicht gedacht, dass man 3 Hexzahlen so kompliziert verrechnen kann.
Die folgende Tabelle enthält Codes aus dem Lernmodus. Das fixiert einen Teil der Werte, und nur die ersten 3 variieren. Es geht "nur" darum die Methode zu bestimmen wie das letzte Nibble (Prüfsumme) gebildet wird. XOr passt nur bei den Werten des ersten Blocks. Wäre überglücklich zu Hinweisen bei den anderen.
000C54
002C56
004C50
006C52
008C5C
00AC5E
00CC58
00EC5A
050C5E
052C5D
054C58
056C5A
058C54
05AC56
05CC53
05EC50
0A0C5E
0A2C5D
0A4C58
0A6C5A
0A8C53
0AAC51
0ACC57
0AEC55
hast Du auch crc4 getestet?
Laut dem hier gibts 2 verschiedene
https://reveng.sourceforge.io/crc-catalogue/1-15.htm#crc.cat-bits.4
es gibt auch crc online calculatoren z.B.
http://www.zorc.breitbandkatze.de/crc.html
Hallo Ralf,
Ja, habe mit Reveng einiges rumprobiert, aber auch CRC bringt nicht mehr Ergebnisse als XOr.
./reveng -w 4 -s 000C54 0013AA 002C56 0033A8 004C50
width=4 poly=0x5 init=0xc refin=false refout=false xorout=0x0 check=0x8 residue=0x0 name=(none)
width=4 poly=0xb init=0x2 refin=false refout=false xorout=0x0 check=0xf residue=0x0 name=(none)
/reveng -w 4 -s 050C5E 052C5D 054C58
./reveng: warning: you have only given 3 samples
./reveng: warning: to reduce false positives, give 4 or more samples
width=4 poly=0x3 init=0xd refin=true refout=true xorout=0x0 check=0x9 residue=0x0 name=(none)
./reveng -w 4 -s 050C5E 052C5D 054C58 056C5A
./reveng: no models found
Was ich so gar nicht verstehe, die Prüfsummer von 000C54 nach 002C56 ändert sich um 2, ebenso bei vielen anderen. Nicht immer 2, aber eigentlich immer gerade.
Von 050C5E nach 052C5D ändert sie sich aber nur um 1. Eigentlich kann das doch gar nicht sein.
Hast Du auch schon mal versucht ob es bei der Prüfsumme weiterhilft, wenn Du die Hexdaten invertierst?
Hast Du wegen dem Protokoll des "Eberle Typ Instat 868-r1" und der Prüfsumme auch schon woanders gefragt?
z.B.
https://stackoverflow.com
https://www.mikrocontroller.net
evtl findet sich dort jemand der es auch schon mit dem Protokoll versucht hat
Invertieren? Also "0" => "F" etc? Habe ich mal gemacht, um festzustellen dass es bei XOR exakt das gleiche Ergebnis bringt. was eigntlich logisch ist.
Ein Reversen der Bits innerhalb eines Nibbles habe ich nicht gemacht. Da aber "05xxx" das gleiche Ergebnis bringt wie "0Axxx" macht ja keinen Sinn.
Ja klar, Anfragen gibt es in MC, Stockoverflow/ReverseEngineering und auch in github/RTL_433. Bisher alles ohne Erfolg. Möglicherweise meldet sich im Laufe der Jahre da mal jemand :)
Ich glaube, ich habe das Rätsel geknackt. Problem war nicht der Prüfcode, sondern schon die Decodierung. Meine ursprüngliche Annahme mit Manchestercode war nur teilweise richtig, da "differentieller Manchester" verwendet wird. Daraus erklären sich dann auch die Muster, die keinen richtigen Sinn ergaben und auch die Codes vereinfachen sich.
Das ganze in URH als eigenen Decoder zusammengebastelt erhalte ich nun konsistente Ergebnisse.
Herausgefunden habe ich es tatsächlich nur deshalb, weil an Sendern mit Display die SenderID bzw. Raumnummer manuell einstellbar und inkrementierbar ist. Danach war der Rest ganz einfach.
868MHz, 2-FSK Modulation, low frequency "0", high frequency "1"
immer als 3-fache Wiederholung
Rohdaten: 82 Bit
xxxxxxxxxxxxxxxxxxxxxxxxxx xx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
00000000000011111110000000 11 000101010101010101010101010101010101010101010101010101
|<-- Preamble -->| | ?? ||<- data ->|
Decodierung: differential Manchester
eigentlicher Datensatz beginnt nach "000", "01" und "10" in erweiterten Präambel erzeugen zusätzlichen Overhead
DeCodiert: 30 Bit
111111010101010101010101010101
| ||<- data ->|
/\
||
Overhead
Generell:30 Bit, 6Bit Overhead, 24 Bit Daten in 6 Nibbles LSB
"1000" => 1
"0100" => 2
"1100" => 3
xxxx xxxx xxxx xxxx xxxx xxxx
0123 0123 0123 0123 0123 0123
|| || || || || ||
|| || || || || ||
|| || || || || ||
|| || || || || \/
|| || || || || Prüfcode 0-F
|| || || || ||
|| || || || \/
|| || || || Zähler 0-F
|| || || ||
|| || || \/
|| || || Actioncode 0-F
|| || \/
|| || ID2, 0-F, zufällige Änderung bei jedem Lernen
|| ||
|| \/
|| ID1, 0-F, zufällige Änderung bei jedem Lernen
||
\/
ID0, 0-F, zufällige Änderung bei jedem Lernen
Actioncodes:
A: Lernen
9: Reset
7: An
0: Aus
Zähler:
einfaches Hochzählen um "1" für jede Aktion
Ausnahme: bei Actionscode "A" bleibt Zähler konstant
Prüfcode:
Berechnung: 15 - ((Summe Nibbles 1-5) mod 15)
Validity Check: Summe Nibbles 1-6 mod 15 = 15
Lernen:
xxx81x, gesendet im 6 Sekunden Takt
Reset: Sequenz des Actioncodes
9/0/7/0/7/0/7/0/0
xxx91x
xxx02x
xxx73x
xxx04x
etc.
Hast Du Dich schon mit der Umwandlung von normalem Manchester in Differential Manchester befasst?
Funkbus verwendet auch Differential Manchester
https://forum.fhem.de/index.php/topic,127189.msg1217330.html#msg1217330
https://github.com/merbanan/rtl_433/blob/master/src/devices/funkbus.c
Ich hab mal eine vom sduino empfangene Manchester Funkbus Nachricht von Hand in Differential Manchester umgewandelt:
0110001010110000110000001000101011101010010100111
1 durch X ersetzen
0XX000X0X0XX0000XX000000X000X0X0XXX0X0X00X0X00XXX
0 durch zo (01) ersetzen
zoXXzozozoXzoXzoXXzozozozoXXzozozozozozoXzozozoXzoXzoXXXzoXzoXzozoXzoXzozoXXX
X durch oz (10) ersetzen
zoozozzozozoozzoozzoozozzozozozoozozzozozozozozoozzozozoozzoozzoozozozzoozzoozzozoozzoozzozoozozoz
-> wandeln in Differential Manchester
zz und oo durch 0 ersetzen
z0zo0ozoz00000zo0ozozoz0zo0ozozozozoz00ozoz00000zozo00000oz0000oz0zozoz
zo und oz durch 1 ersetzen
z010110000010111010111110011000001100000100001011z
Ist recht aufwändig, geht dies auch einfacher?
Gruß Ralf
Ich habe das in Calc gemacht, weil ich auch schpon Manchester hatte. Das war nicht schön, aber da muss man die Formel nur einmal zusammenbasteln und dann kopieren:
=TEIL(A2;1;1)&WENN(TEIL(A2;2;1)=TEIL(A2;1;1);"0";"1")&WENN(TEIL(A2;3;1)=TEIL(A2;2;1);"0";"1")&WENN(TEIL(A2;4;1)=TEIL(A2;3;1);"0";"1")&WENN(TEIL(A2;5;1)=TEIL(A2;4;1);"0";"1")&WENN(TEIL(A2;6;1)=TEIL(A2;5;1);"0";"1")&WENN(TEIL(A2;7;1)=TEIL(A2;6;1);"0";"1")&WENN(TEIL(A2;8;1)=TEIL(A2;7;1);"0";"1")&WENN(TEIL(A2;9;1)=TEIL(A2;8;1);"0";"1")&WENN(TEIL(A2;10;1)=TEIL(A2;9;1);"0";"1")&WENN(TEIL(A2;11;1)=TEIL(A2;10;1);"0";"1")&WENN(TEIL(A2;12;1)=TEIL(A2;11;1);"0";"1")&WENN(TEIL(A2;13;1)=TEIL(A2;12;1);"0";"1")&WENN(TEIL(A2;14;1)=TEIL(A2;13;1);"0";"1")&WENN(TEIL(A2;15;1)=TEIL(A2;14;1);"0";"1")&WENN(TEIL(A2;16;1)=TEIL(A2;15;1);"0";"1")&WENN(TEIL(A2;17;1)=TEIL(A2;16;1);"0";"1")&WENN(TEIL(A2;18;1)=TEIL(A2;17;1);"0";"1")&WENN(TEIL(A2;19;1)=TEIL(A2;18;1);"0";"1")&WENN(TEIL(A2;20;1)=TEIL(A2;19;1);"0";"1")&WENN(TEIL(A2;21;1)=TEIL(A2;20;1);"0";"1")&WENN(TEIL(A2;22;1)=TEIL(A2;21;1);"0";"1")&WENN(TEIL(A2;23;1)=TEIL(A2;22;1);"0";"1")&WENN(TEIL(A2;24;1)=TEIL(A2;22;1);"0";"1")&WENN(TEIL(A2;25;1)=TEIL(A2;24;1);"0";"1")&WENN(TEIL(A2;26;1)=TEIL(A2;25;1);"0";"1")
Da ich viele Daten nur in Manchester aber nicht mehr in Rohdaten hatte, ging es leider auch nur so.
Wenn mir das nochmal ankommt, würde ich mir aber wohl das Python-script hier dazu herannehmen https://github.com/triq-org/revdgst/blob/master/scripts/differential_manchester_decode.py (https://github.com/triq-org/revdgst/blob/master/scripts/differential_manchester_decode.py).
Soweit ich mich entsinne, war meine Suche nach einem Code für Manchester=> diffManchester in Github und SE erfolglos. Das muss ja aber nicht heißen, dass ich nicht etwas dazu übersehen habe
ZitatWenn mir das nochmal ankommt, würde ich mir aber wohl das Python-script hier dazu herannehmen https://github.com/triq-org/revdgst/blob/master/scripts/differential_manchester_decode.py.
Danke, das hilft weiter, damit wird es einfacher.
Hier ist es wahrscheinlich besser, wenn ich bei am Anfang fehlendem halben Bit ein Zeichen am Anfang entferne,
oder kann ich davon ausgehen, daß bei Differential Manchester die Rohdaten immer mit 0 anfangen?
Zitatdef differential_manchester_align(line):
"""Manchester align string by optionally prepending a half-bit."""
hh_pos = line.find("11")
ll_pos = line.find("00")
if hh_pos < 0 or (ll_pos >= 0 and ll_pos < hh_pos):
hh_pos = ll_pos
if hh_pos % 2 == 0:
return line
else:
return "0" + line
Zitat von: Ralf9 am 08 April 2022, 17:41:35
oder kann ich davon ausgehen, daß bei Differential Manchester die Rohdaten immer mit 0 anfangen?
Spannende Frage, die ich adhoc nicht beantworten kann. Wobei der Vorteil der differentiellen Übertragung genau darin liegt, dass Plus Minus sein kann oder umgekehrt und es damit eigentlich egal sein müsste. Gilt aber immer zur Dekodierung der Rohdaten, nicht wenn schon einfaches Manchester dekodiert wurde.
Ich habe mich mit Funkbus bisher nicht beschäftigt, für RTL_433 gibt es zumindest einen Decoder.
Hallo zusammen,
ich kann nun mittels meines PicoSDuino (https://forum.fhem.de/index.php?topic=143942.0) auch über fhem Daten der Eberle einlesen. Über URH weiß ich den grundsätzlichen Aufbau des Protokolls. Jetzt würde ich beides gerne sinnvoll zusammenbringen und habe mich dazu auch mit der Wiki (https://wiki.fhem.de/wiki/Unbekannte_Funkprotokolle) belesen
URH
[2026-04-11 08:08:43.794558] 1011111111111111111110000011000110100110010101100110011001100110011001101010100110
[2026-04-11 08:08:44.359941] 1011111111111111111110000011000110100110010101100110011001100110011001101010100110
[2026-04-11 08:08:44.800941] 1011111111111111111110000011000110100110010101100110011001100110011001101010100110
[2026-04-11 08:18:43.794841] 1011111111111111111110000011000110100110010101100110011001100110010110010110100110
[2026-04-11 08:18:44.354980] 1011111111111111111110000011000110100110010101100110011001100110010110010110100110
[2026-04-11 08:18:44.792459] 1011111111111111111110000011000110100110010101100110011001100110010110010110100110
Fhem Code
2026.04.11 08:08:44 4: myPicoDuino/msg READ: MU;P0=-390;P1=721;P2=6992;P3=-1802;P4=-1113;P5=344;P6=-732;CP=5;R=182;D=0102314105616505016161616161610505056105;e;
2026.04.11 08:18:44 4: myPicoDuino/msg READ: MU;P0=133;P1=-216;P2=806;P3=-1114;P4=-450;P5=365;P6=-711;P7=91;CP=2;R=178;D=2324562654542626262626542654245624740121;p;
und Einstellungen:
Readings
bWidth
Setting MDMCFG4 (10) to c7 = 101 KHz
2026-04-10 13:06:57
cc1101_config
freq:868.965MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:2733.71Baud)
2026-04-10 18:16:24
cc1101_config_ext
Modulation:2-FSK (SYNC_MODE:No preamble/sync) DEVIATN:14.282kHz
2026-04-10 18:16:24
ccpatable
868.350 MHz, C3E = 00 C2 00 00 00 00 00 00 => 10_dBm
2026-04-10 11:52:53
cmdBank
B: b=1 freq:868.670MHz bWidth:101KHz rAmpl:33dB sens:8dB (DataRate:6248.47Baud) [boffs=0100]
ccmode=0 sync=D391 Modulation:2-
2026-04-10 13:16:37
config
A: MS=1;MU=1;MC=1;Mred=0_MScnt=4;maxMuPrint=768;maxMsgSize=1024;maxNumPat=8;Mdebug=1;MdebFifoLimit=150/200
2026-04-10 11:14:00
dataRate
Setting MDMCFG4/3 (10 11) to 86 b9 = (2727.51) 2733.71* Baud
2026-04-10 18:05:06
ping
OK
2026-04-11 10:38:38
rfmode
HoneywActivL__SlowRf_FSK => ok,N=0,ccmode=0
2026-04-10 13:24:11
state
opened
Das FSK Signal, das ich per Duino sende ist visuell vom Eberle nicht zu unterscheiden (Mittenfrequenz und Deviation), die Baud habe ich mit 2732,24 vorgegeben, nach 1000000/366. 366µs als Signallänge konnte ich ziemlich genau über URH herausfinden. Obwohl im Log auch kürzere Signale von 133, 178 und 230 angezeigt werden.
Kann mir jemand sagen, wie ich weiter vorgehen muss um die Parameter des Empfangsmoduls so anzupassen, dass ich konsistente Readings bekomme? Umgekehrt könnte ich das Datenpaket zwar selber beschreiben, weil ich den Aufbau ja kenne. Zumindest einen Teil, weil sich durch den Zähler und CRC ja eine Art rolling Code ergibt. Aber was ich damit anfangen könnte, will mir nicht klarwerden.
Protokollaufbau:
Gesamtlänge 30000
Preamble ~770, typisch 10 H,L aber nicht je 366, option: 1000 undefiniert einschwingen
Sync 7000,-1800, 732, -1100 &11000
Sync2 -732, 366 &110
Data inkl Zähler und CRC 48x366µs, Manchester
Ich schaus mir heute Abend an.
Kannst Du bitte von fhem noch mehr raw Nachrichten posten? Am besten gleichzeitig mit den URH Daten
URH, immer nur der Erste ohne die zweifache Wiederholung. Der Code bei 08:18 ist derselbe wie 05:38, da ist der Zähler durch und es beginnt von neuem
[2026-04-11 05:38:44.912851] 1011111111111111111110000011000110100110010101100110011001100110010110010110100110
[2026-04-11 05:48:43.963851] 1011111111111111111110000011000110100110010101100110011001100110011010010101100110
[2026-04-11 05:58:43.989654] 1011111111111111111110000011000110100110010101100110011001100110010101101001100110
[2026-04-11 06:08:43.999743] 1011111111111111111110000011000110100110010101100110011001100110011001010101010101
[2026-04-11 06:18:43.992049] 1011111111111111111110000011000110100110010101100110011001100110010110101001010101
[2026-04-11 06:28:43.756159] 1011111111111111111110000011000110100110010101100110011001100110011010101010010101
[2026-04-11 06:38:43.759791] 1011111111111111111110000011000110100110010101100110011001100110010101010110010101
[2026-04-11 06:48:43.768224] 1011111111111111111110000011000110100110010101100110011001100110011001100101011010
[2026-04-11 06:58:43.779581] 1011111111111111111110000011000110100110010101100110011001100110010110011001011010
[2026-04-11 07:08:43.781510] 1011111111111111111110000011000110100110010101100110011001100110011010011010011010
[2026-04-11 07:18:43.791329] 1011111111111111111110000011000110100110010101100110011001100110010101100110011010
[2026-04-11 07:28:43.779387] 1011111111111111111110000011000110100110010101100110011001100110011001011010101001
[2026-04-11 07:38:43.794712] 1011111111111111111110000011000110100110010101100110011001100110010110100110101001
[2026-04-11 07:48:43.787060] 1011111111111111111110000011000110100110010101100110011001100110011010100101101001
[2026-04-11 07:58:43.786926] 1011111111111111111110000011000110100110010101100110011001100110010101011001101001
[2026-04-11 08:08:43.794558] 1011111111111111111110000011000110100110010101100110011001100110011001101010100110
[2026-04-11 08:18:43.794841] 1011111111111111111110000011000110100110010101100110011001100110010110010110100110
Logfile, ich habe die Codes derselben Empfangsminute dabei gelassen. Ich weiß ja nicht, ob er die Wiederholung als solche erkennt, oder wie URH eine eigene Dekodierung macht und eine Pause einschiebt. Für 08:18 und 05:38 erkenne ich keine Ähnlichkeit
2026.04.11 05:38:58 4: myPicoDuino/msg READ: MU;P0=-844;P1=230;P2=-495;P3=138;P4=-94;P5=-233;P6=608;P7=-1204;CP=1;R=175;D=6760601212601212126210606210606210603435;p;
2026.04.11 05:48:44 4: myPicoDuino/msg READ: MU;P0=639;P1=-506;P2=7007;P3=-1808;P4=-1102;P5=-369;P6=324;P7=-772;CP=0;R=175;D=0123040567076565070707070705676565070505;p;
2026.04.11 05:48:57 4: myPicoDuino/msg READ: MU;P0=236;P1=-544;P2=-149;P3=103;P5=588;P6=-1206;P7=-854;CP=0;R=174;D=56575701015701010151075757015701575102310;p;
2026.04.11 05:48:58 4: myPicoDuino/msg READ: MU;P0=250;P1=-4550;P2=2391;P3=-2683;P4=588;P5=-1098;P6=-852;P7=-478;CP=0;R=180;D=0123454646070746070707470646460746074645;p;
2026.04.11 05:48:58 4: myPicoDuino/msg READ: MU;P0=382;P1=135;P2=-303;P3=588;P4=-1181;P5=-806;P6=227;P7=-473;CP=6;R=173;D=343535676735676767376535356735673535670512;p;
2026.04.11 05:58:57 4: myPicoDuino/msg READ: MU;P0=253;P1=-509;P2=769;P4=-2631;P5=586;P6=-1180;P7=-858;CP=0;R=174;D=4565757010157010101510757510107575751210;e;
2026.04.11 05:58:58 4: myPicoDuino/msg READ: MU;P0=586;P1=-5046;P2=2432;P3=-2630;P4=-1197;P5=-858;P6=229;P7=-496;CP=6;R=178;D=0123040505676705676767076505076765050505;p;
2026.04.11 05:58:58 4: myPicoDuino/msg READ: MU;P0=261;P1=-497;P3=-227;P4=143;P5=592;P6=-1175;P7=-853;CP=0;R=178;D=5657570101570101015107575101075757510343430;p;
2026.04.11 06:08:43 4: myPicoDuino/msg READ: MU;P0=-407;P1=297;P2=6956;P3=-1818;P4=729;P5=-1130;P7=-735;CP=1;R=17;D=010234540174710104747474747471010101010101;p;
2026.04.11 06:08:44 4: myPicoDuino/msg READ: MU;P0=-1117;P1=-410;P2=344;P3=-765;P4=-182;P5=232;P6=-249;P7=699;CP=2;R=172;D=7071237321217373737373732121212121212456;p;
2026.04.11 06:08:44 4: myPicoDuino/msg READ: MU;P0=353;P1=-801;P2=723;P3=-399;P4=1236;P5=176;P7=-229;CP=0;R=172;D=0121030321212121212103030303030341510307;e;
2026.04.11 06:08:58 4: myPicoDuino/msg READ: MU;P0=-477;P1=255;P2=-4521;P3=2454;P4=-2629;P5=543;P6=-1182;P7=-837;CP=1;R=222;D=1234565757101057101010501757575017101010105;p;
2026.04.11 06:08:58 4: myPicoDuino/msg READ: MU;P0=-1176;P1=-837;P2=264;P3=-478;P4=-132;P5=130;P6=-2633;P7=593;CP=2;R=224;D=670717123237123232373217171732123232323245;e;
2026.04.11 06:18:43 4: myPicoDuino/msg READ: MU;P0=349;P1=-738;P2=457;P3=-194;P4=242;P5=705;P6=-1118;P7=-376;CP=0;R=181;D=5657015107075151515151075707010707072343;p;
2026.04.11 06:18:57 4: myPicoDuino/msg READ: MU;P0=2392;P1=-2680;P2=-1179;P3=-846;P4=257;P5=-485;P6=595;P7=-4247;CP=4;R=222;D=6701626363454563454545654363654345634545454;e;
2026.04.11 06:18:58 4: myPicoDuino/msg READ: MU;P0=-321;P1=-2633;P2=605;P3=-1172;P4=-847;P5=256;P6=-528;CP=5;R=224;D=1232424565624565656265424265456245656562620;e;
2026.04.11 06:18:58 4: myPicoDuino/msg READ: MU;P0=-1179;P1=-848;P2=256;P3=-479;P4=-4259;P5=2412;P6=-2628;P7=609;CP=2;R=224;D=456707171232371232323732171732123712323237;e;
2026.04.11 06:28:43 4: myPicoDuino/msg READ: MU;P0=-409;P1=7014;P2=-1847;P3=725;P4=-1115;P5=320;P6=-764;P7=562;CP=5;R=16;D=567012343056365050363636363630505050565050;p;
2026.04.11 06:28:44 4: myPicoDuino/msg READ: MU;P0=6981;P1=-1838;P2=732;P3=-1101;P4=323;P5=-755;P6=548;P7=-409;CP=4;R=177;D=7012327452547472525252525274747474547476;p;
2026.04.11 06:28:44 4: myPicoDuino/msg READ: MU;P0=352;P1=-387;P2=7009;P3=-1852;P4=727;P5=-1105;P7=-759;CP=0;R=178;D=0123454107470101474747474741010101070101;p;
2026.04.11 06:28:58 4: myPicoDuino/msg READ: MU;P0=-531;P1=598;P2=-180;P3=355;P5=-1177;P6=-837;P7=237;CP=7;R=224;D=15161670701670707010761616707010767070123230;e;
2026.04.11 06:28:58 4: myPicoDuino/msg READ: MU;P0=598;P1=-1185;P2=-837;P3=237;P4=-497;P5=320;P7=-333;CP=3;R=224;D=010202343402343434043202023434043234345407;p;
2026.04.11 06:38:43 4: myPicoDuino/msg READ: MU;P0=728;P1=-390;P2=7034;P3=-1798;P4=-1115;P6=349;P7=-758;CP=6;R=179;D=01230401670761610707070707616161610761616;p;
2026.04.11 06:38:58 4: myPicoDuino/msg READ: MU;P0=226;P1=-483;P2=313;P3=93;P4=-191;P5=590;P6=-1175;P7=-859;CP=0;R=225;D=565757010157010101510757510101075701012134;p;
2026.04.11 06:38:58 4: myPicoDuino/msg READ: MU;P0=574;P1=-1181;P2=-858;P3=258;P4=-464;P6=-135;P7=-222;CP=3;R=224;D=0102023434023434340432020434343202343436073;e;
2026.04.11 06:48:58 4: myPicoDuino/msg READ: MU;P0=-2670;P1=-1184;P2=238;P3=-489;P4=-858;P5=589;P6=-4372;P7=2377;CP=2;R=225;D=4567051545423235423232353245454542323235321;p;
2026.04.11 06:48:58 4: myPicoDuino/msg READ: MU;P0=397;P1=-539;P2=145;P3=589;P4=-1158;P5=-801;P6=240;CP=6;R=182;D=343535616135616161316535353561616131616101256;p;
2026.04.11 06:48:58 4: myPicoDuino/msg READ: MU;P0=-1173;P1=-869;P2=238;P3=-495;P4=90;P5=184;P6=-221;P7=590;CP=2;R=185;D=707171232371232323732171717123232373234156;e;
2026.04.11 06:58:58 4: myPicoDuino/msg READ: MU;P0=2431;P1=-2469;P2=598;P3=-1171;P4=-829;P5=-495;P6=239;P7=-4472;CP=6;R=221;D=670123242465652465656525642425642564652561;p;
2026.04.11 06:58:58 4: myPicoDuino/msg READ: MU;P0=-830;P1=239;P2=-494;P3=143;P4=2392;P5=-2635;P6=600;P7=-1225;CP=1;R=180;D=45676060121260121212621060621062101262103;e;
2026.04.11 06:58:58 4: myPicoDuino/msg READ: MU;P0=-808;P1=178;P2=-2631;P3=597;P4=-1172;P6=240;P7=-495;CP=6;R=173;D=2343030676730676767376030376037606737601;e;
2026.04.11 07:08:58 4: myPicoDuino/msg READ: MU;P0=-230;P1=404;P2=-2605;P3=608;P4=-1201;P5=-825;P6=251;P7=-470;CP=6;R=179;D=2343535676735676767376535356737676537656017;e;
2026.04.11 07:08:58 4: myPicoDuino/msg READ: MU;P0=2411;P1=-2632;P2=607;P3=-1180;P4=-839;P5=-498;P6=229;P7=-4336;CP=6;R=221;D=670123242465652465656525642424652565642565;p;
2026.04.11 07:08:58 4: myPicoDuino/msg READ: MU;P0=-1192;P1=-839;P2=232;P3=-493;P4=168;P5=-211;P6=-340;P7=608;CP=2;R=169;D=707171232371232323732171712373232173204546;p;
2026.04.11 07:18:58 4: myPicoDuino/msg READ: MU;P0=2439;P1=-2643;P2=589;P3=-1181;P4=-852;P5=229;P6=-500;P7=-4449;CP=5;R=174;D=70123242456562456565626542426565456242656;e;
2026.04.11 07:18:58 4: myPicoDuino/msg READ: MU;P0=-544;P1=-97;P2=231;P3=-2636;P4=588;P5=-1178;P6=-853;CP=2;R=180;D=345464620204620202040264640202620464020212;e;
2026.04.11 07:18:58 4: myPicoDuino/msg READ: MU;P0=-498;P1=229;P2=-4240;P3=2432;P4=-2633;P5=608;P6=-1132;P7=-852;CP=1;R=223;D=01234565757101057101010501757501017105750165;p;
2026.04.11 07:28:43 4: myPicoDuino/msg READ: MU;P0=363;P1=-757;P2=675;P3=-381;P4=257;P5=187;P6=-275;P7=-190;CP=0;R=178;D=01210303212121212121032303030143562357564;p;
2026.04.11 07:28:58 4: myPicoDuino/msg READ: MU;P0=408;P1=-267;P2=566;P3=-1215;P4=-854;P5=226;P6=-498;P7=-375;CP=5;R=225;D=2324245656245656562654242426565656565427010;p;
2026.04.11 07:28:58 4: myPicoDuino/msg READ: MU;P0=-212;P1=168;P2=-2635;P3=653;P4=-1173;P5=-854;P6=219;P7=-500;CP=6;R=224;D=23435356767356767673765353537676767676530601;e;
2026.04.11 07:28:58 4: myPicoDuino/msg READ: MU;P0=174;P1=127;P2=563;P3=-1188;P4=-856;P5=227;P6=-510;P7=-128;CP=5;R=223;D=23242456562456565626542424265656565654270716;p;
2026.04.11 07:38:43 4: myPicoDuino/msg READ: MU;P0=364;P1=-343;P2=720;P3=-521;P4=7018;P5=-1791;P6=-1141;P7=-767;CP=0;R=17;D=012303452621072701012727272727012107210107;p;
2026.04.11 07:38:58 4: myPicoDuino/msg READ: MU;P0=-4265;P1=2450;P2=-2640;P3=-1182;P4=-827;P5=231;P6=-495;P7=592;CP=5;R=221;D=56701273747456567456565676547476545656765654;p;
2026.04.11 07:38:58 4: myPicoDuino/msg READ: MU;P0=603;P1=-1207;P2=-830;P3=-489;P4=235;P5=-4146;P6=2444;P7=-2636;CP=4;R=223;D=34567010202434302434343034202034243430343420;p;
2026.04.11 07:38:58 4: myPicoDuino/msg READ: MU;P0=-1179;P1=236;P2=-489;P3=-828;P4=593;P5=-4288;P6=2446;P7=-2627;CP=1;R=223;D=3456740434312124312121242134342131212421213;p;
2026.04.11 07:48:43 4: myPicoDuino/msg READ: MU;P0=6986;P1=-1849;P2=819;P3=-1115;P4=-366;P5=-674;P6=359;P7=-498;CP=6;R=180;D=6701232465256464252525252524646564246525;e;
2026.04.11 07:48:44 4: myPicoDuino/msg READ: MU;P0=-1105;P1=-405;P2=361;P3=-772;P5=96;P6=126;P7=731;CP=2;R=173;D=70712373212173737373737121232171232323212151216;p;
2026.04.11 07:48:58 4: myPicoDuino/msg READ: MU;P0=426;P1=-2635;P2=593;P3=-1168;P4=-859;P5=242;P6=-515;P7=314;CP=5;R=223;D=12324245656245656562654242456565656265476032;e;
2026.04.11 07:48:58 4: myPicoDuino/msg READ: MU;P0=-4213;P1=2396;P2=-2683;P3=565;P4=-1179;P5=-859;P6=-491;P7=231;CP=7;R=224;D=67012343535767635767676367535357676767636753;p;
2026.04.11 07:58:44 4: myPicoDuino/msg READ: MU;P0=-252;P1=352;P2=753;P3=-1072;P4=-368;P6=-700;P7=184;CP=1;R=178;D=23241626141426262626261414142624161673701;p;
2026.04.11 07:58:44 4: myPicoDuino/msg READ: MU;P0=337;P1=-493;P2=7031;P3=-1802;P4=754;P5=-1120;P6=-334;P7=-711;CP=0;R=183;D=01234546074706064747474747060606474607060;p;
2026.04.11 07:58:58 4: myPicoDuino/msg READ: MU;P0=-1179;P1=-832;P2=229;P3=-495;P4=313;P5=-356;P6=-2640;P7=598;CP=2;R=224;D=670717123237123232373217173232323217321457;e;
2026.04.11 07:58:58 4: myPicoDuino/msg READ: MU;P0=-4892;P1=2419;P2=-2630;P3=684;P4=-1172;P5=-460;P6=-827;P7=228;CP=7;R=222;D=670123436367575367575753576363575757576357635;p;
2026.04.11 07:58:58 4: myPicoDuino/msg READ: MU;P0=-311;P1=341;P2=598;P3=-1163;P4=-827;P5=227;P6=-496;CP=5;R=223;D=232424565624565656265424265656565426542010;p;
2026.04.11 08:08:44 4: myPicoDuino/msg READ: MU;P0=-390;P1=721;P2=6992;P3=-1802;P4=-1113;P5=344;P6=-732;CP=5;R=182;D=0102314105616505016161616161610505056105;e;
2026.04.11 08:08:58 4: myPicoDuino/msg READ: MU;P0=-534;P1=301;P2=147;P3=586;P4=-1179;P5=-853;P6=230;CP=6;R=173;D=3435356060356060603065353535306065301020;p;
2026.04.11 08:08:58 4: myPicoDuino/msg READ: MU;P0=-4288;P1=2397;P2=-2637;P3=587;P4=-1147;P5=-853;P6=255;P7=-498;CP=6;R=173;D=0123435356767356767673765353535376765346;e;
2026.04.11 08:08:58 4: myPicoDuino/msg READ: MU;P0=203;P1=-99;P2=586;P3=-1198;P4=-854;P6=-530;P7=-289;CP=0;R=171;D=2324240606240606062604242424260604260701060;e;
2026.04.11 08:18:44 4: myPicoDuino/msg READ: MU;P0=133;P1=-216;P2=806;P3=-1114;P4=-450;P5=365;P6=-711;P7=91;CP=2;R=178;D=2324562654542626262626542654245624740121;p;
2026.04.11 08:18:58 4: myPicoDuino/msg READ: MU;P0=133;P1=-178;P2=408;P3=611;P4=-1141;P5=-834;P6=226;P7=-541;CP=6;R=174;D=3435356767356767673765353765353765340701672;p;
2026.04.11 08:18:58 4: myPicoDuino/msg READ: MU;P0=166;P1=-482;P2=-254;P3=609;P4=-1325;P5=-836;P6=230;CP=6;R=179;D=34353561613561616131653531653531653401626;p;
Ich habs bei mir mit einer neuen ProtokollId mal soweit eingebaut, daß eine msg in der Form
LlLlSsSsLlSsSsSsLsSlLlLlSsLlSsLlL
ausgegeben wird.
Dabei ist
s - short low
S - short high
l - long low
L - long high
nun fehlt mir noch eine Routine, die dieses Differential Manchester decodiert.
Wird es einfacher, wenn ich es in 0en und 1en wandle: s - 0, S - 1, l - 00, L - 11
2026.04.11 05:38:58 MU;P0=-844;P1=230;P2=-495;P3=138;P4=-94;P5=-233;P6=608;P7=-1204;CP=1;R=175;D=6760601212601212126210606210606210603435;p;
LlLlSsSsLlSsSsSsLsSlLlLsSlLlLsSlLl
2026.04.11 05:48:44 MU;P0=639;P1=-506;P2=7007;P3=-1808;P4=-1102;P5=-369;P6=324;P7=-772;CP=0;R=175;D=0123040567076565070707070705676565070505;p;
LsSlLlSsSsLlLlLlLlLlLsSlSsSsLlLsLs
2026.04.11 05:48:57 MU;P0=236;P1=-544;P2=-149;P3=103;P5=588;P6=-1206;P7=-854;CP=0;R=174;D=56575701015701010151075757015701575102310;p;
LlLlSsSsLlSsSsSsLsSlLlLlSsLlSsLlLsS
2026.04.11 05:48:58 MU;P0=250;P1=-4550;P2=2391;P3=-2683;P4=588;P5=-1098;P6=-852;P7=-478;CP=0;R=180;D=0123454646070746070707470646460746074645;p;
LlLlSsSsLlSsSsSsLsSlLlLlSsLlSsLlL
2026.04.11 05:48:58 MU;P0=382;P1=135;P2=-303;P3=588;P4=-1181;P5=-806;P6=227;P7=-473;CP=6;R=173;D=343535676735676767376535356735673535670512;p;
LlLlSsSsLlSsSsSsLsSlLlLlSsLlSsLlLlSs
2026.04.11 05:58:57 MU;P0=253;P1=-509;P2=769;P4=-2631;P5=586;P6=-1180;P7=-858;CP=0;R=174;D=4565757010157010101510757510107575751210;e;
LlLlSsSsLlSsSsSsLsSlLlLsSsSlLlLlLs
2026.04.11 05:58:58 MU;P0=586;P1=-5046;P2=2432;P3=-2630;P4=-1197;P5=-858;P6=229;P7=-496;CP=6;R=178;D=0123040505676705676767076505076765050505;p;
LlLlSsSsLlSsSsSsLsSlLlLsSsSlLlLlLl
2026.04.11 05:58:58 MU;P0=261;P1=-497;P3=-227;P4=143;P5=592;P6=-1175;P7=-853;CP=0;R=178;D=5657570101570101015107575101075757510343430;p;
LlLlSsSsLlSsSsSsLsSlLlLsSsSlLlLlLsS
2026.04.11 06:08:43 MU;P0=-407;P1=297;P2=6956;P3=-1818;P4=729;P5=-1130;P7=-735;CP=1;R=17;D=010234540174710104747474747471010101010101;p;
LsSlLlSsSsLlLlLlLlLlLlSsSsSsSsSsSsS
...
2026.04.11 08:18:58 MU;P0=133;P1=-178;P2=408;P3=611;P4=-1141;P5=-834;P6=226;P7=-541;CP=6;R=174;D=3435356767356767673765353765353765340701672;p;
LlLlSsSsLlSsSsSsLsSlLlLsSlLlLsSlL
2026.04.11 08:18:58 MU;P0=166;P1=-482;P2=-254;P3=609;P4=-1325;P5=-836;P6=230;CP=6;R=179;D=34353561613561616131653531653531653401626;p;
LlLlSsSsLlSsSsSsLsSlLlLsSlLlLsSlL
MU;P0=-477;P1=255;P2=-4521;P3=2454;P4=-2629;P5=543;P6=-1182;P7=-837;CP=1;R=222;D=1234565757101057101010501757575017101010105;p;
s P0=-477, l P7=-837, S P1=255, L P5=543
LlLlSsSsLlSsSsSsLsSlLlLlLsSlSsSsSsSsL
Schön, da zeichnet sich ein Bild und gewisse Konsistenz ab.
Allerdings, wenn ich die Folge nach binär übersetze, passt das nicht mit den URH Daten zusammen:
LlLlSsSsLlSsSs...ergibt doch
11001100101011001010... und das finde ich nicht in den URH-Daten
1011111111111111111110000011000110100110010101100110011001100110010110010110100110
Auch nicht, wenn ich invertiere. Oder habe ich da einen Denkfehler?
Ja, ich würde wohl erst Bitstream generieren und dann DiffManchester, gerade weil dafür ja schon Code vorliegt
URH sagt mir nichts, liefert er die Daten automatisch oder musstest Du ihn konfigurieren?
Kann es evtl auch sein, daß die Daten vom URH nicht ganz passen?
Hast Du auch mal rtl 433 getestet?
https://github.com/merbanan/rtl_433
Der rtl_433 erkennt das Protokoll der Instat leider auch nicht. Das wäre ja zu schön gewesen.
Mit URH (https://github.com/jopohl/urh) konnte ich step-by-step die notwendigen Infos bis zum Bitsteam gewinnen. Absolut sinnvolles Tool dafür. Mit Frickeln des Center habe ich auch bei den alten Eberle-Modulen die high/loW Unterscheidung hinbekommen.
Über die Anzeige "Signal" bzw. "Demudulated" sind auch die Signallängen perfekt zu bestimmen.
Danach kam ich aber nicht mehr recht weiter, weil die Dekodierung per Manchester/diffManchester immer exakt Anfang des Streams beginnt. Und das Sync ist ja leider nicht FSK like und manchmal auch etwas "einschwingt". Sprich da kommt am Anfang mal eine "0", dann mal eine "01" oder "001" in der Preamble was den Dekodierer völlig aus der Bahn wirft. Solange die Daten immer mit 100% Qualität reinkommen, kein Problem - aber wann ist das bei Funk schon mal der Fall. Man sieht es auch im zwieten Bild, der mittlere Stream ist nicht korrekt.
Von daher bin ich mir sehr sicher, dass die URH Daten passen. Höchstens invertiert können sie sein, je nachdem ob der hohe oder niedrige shift als "1" gelesen wird.
Die Nachrichten vom sduino sehen für mich gut aus.
Es sind recht viele fehlerhafte dabei.
Wie weit ist das Eberle Instat vom sduino weg? Die RSSI Werte sind grenzwertig
Der Start ist ca -2680, 595, -1179 und wird gut erkannt.
Ich hab auch mal die dekodierung des diffManchester eingebaut.
Zwei gleiche Bits in Folge ist 1 und unterschiedliche Bits (01 oder 10) sind 0.
2026.04.11 05:38:58 MU;P0=-844;P1=230;P2=-495;P3=138;P4=-94;P5=-233;P6=608;P7=-1204;CP=1;R=175;D=6760601212601212126210606210606210603435;p;
LlLlSsSsLlSsSsSsLsSlLlLsSlLlLsSlLl
1100110010101100101010110100110011010011001101001100 (52)
1111 0011 0001 0111 1011 1101 11
2026.04.11 05:48:57 MU;P0=236;P1=-544;P2=-149;P3=103;P5=588;P6=-1206;P7=-854;CP=0;R=174;D=56575701015701010151075757015701575102310;p;
LlLlSsSsLlSsSsSsLsSlLlLlSsLlSsLlLsS
1100110010101100101010110100110011001011001011001101 (52)
1111 0011 0001 0111 1101 1011 10
2026.04.11 05:58:57 MU;P0=253;P1=-509;P2=769;P4=-2631;P5=586;P6=-1180;P7=-858;CP=0;R=174;D=4565757010157010101510757510107575751210;e;
LlLlSsSsLlSsSsSsLsSlLlLsSsSlLlLlLs
110011001010110010101011010011001101010011001100110 (50)
1111 0011 0001 0111 1001 1111 1
2026.04.11 06:18:57 MU;P0=2392;P1=-2680;P2=-1179;P3=-846;P4=257;P5=-485;P6=595;P7=-4247;CP=4;R=222;D=6701626363454563454545654363654345634545454;e;
110011001010110010101011010011001101001011001010101 (50)
1111 0011 0001 0111 1010 1100 0
2026.04.11 07:08:58 MU;P0=-230;P1=404;P2=-2605;P3=608;P4=-1201;P5=-825;P6=251;P7=-470;CP=6;R=179;D=2343535676735676767376535356737676537656017;e;
11001100101011001010101101001100110010110101001101001 (52)
1111 0011 0001 0111 1101 0011 01
RSSI sollte sehr gut sein. Der Sender ist ca 2m vom sDuino entfernt. Und die richtige Antenne angeschlossen. Am URH musste ich die Verstärkung etwas senken. Ich hatte mehr die Befürchtung, dass das Signal zu stark reinkommt.
Welcher der Werte steht denn für den RSSI?
Viel mehr traue ich den eingestellten Empfangsparametern für den CC1101 nicht. Wie schon oben geschrieben, der Frequenzhub ist echt knapp, man sieht das bei URH sehr gut. Bzw eben nicht, oben das zweite Bild.
Die neueren Modelle haben einen deutlich größeren Hub, siehe Anhang. Auch ist das Intro ein anderes was aber nicht was zur Sache tut, weil die Daten selber nach dem gleichen System aufgebaut sind.
Edit: ich habe die gleichen Zeitraum empfangenen Daten dieses Sensors, URH und fhem eingefügt. Wohlgemerkt, die Empfangsparameter waren nicht darauf abgestimmt. Auch hier immer Tripel, beim ersten und letzten alle 3, sonst immer der erste.
Zitat[2026-04-11 05:40:11.620117] 000000000001111111000000011000110011001100110100110101010100110010101100101100101
[2026-04-11 05:40:12.975992] 000000000001111111000000011000110011001100110100110101010100110010101100101100101
[2026-04-11 05:40:14.072057] 000000000001111111000000011000110011001100110100110101010100110010101100101100101
[2026-04-11 05:50:11.629990] 000000000001111111000000011000110011001100110100110101010100110011001011001100101
[2026-04-11 06:00:11.632757] 000000000001111111000000011000110011001100110100110101010100110010110100101010110
[2026-04-11 06:10:11.610096] 000000000001111111000000011000110011001100110100110101010100110011010100110101001
[2026-04-11 06:20:11.617619] 000000000001111111000000011000110011001100110100110101010100110010101011010010110
[2026-04-11 06:30:11.594650] 000000000001111111000000011000110011001100110100110101010100110011001101001101001
[2026-04-11 06:40:11.613761] 000000000001111111000000011000110011001100110100110101010100110010110010101011001
[2026-04-11 06:50:11.595946] 000000000001111111000000011000110011001100110100110101010011001100101101010100110
[2026-04-11 07:00:11.596968] 000000000001111111000000011000110011001100110100110101010011001101010010110100110
[2026-04-11 07:10:11.611352] 000000000001111111000000011000110011001100110100110101010011001100110101010011001
[2026-04-11 07:20:11.597055] 000000000001111111000000011000110011001100110100110101010011001101001010110011001
[2026-04-11 07:30:11.595295] 000000000001111111000000011000110011001100110100110101010011001100101010101010101
[2026-04-11 07:40:11.601297] 000000000001111111000000011000110011001100110100110101010011001101010101001010101
[2026-04-11 07:50:11.607402] 000000000001111111000000011000110011001100110100110101010011001100110011010010101
[2026-04-11 08:00:11.603824] 000000000001111111000000011000110011001100110100110101010011001101001100110010101
[2026-04-11 08:10:11.593959] 000000000001111111000000011000110011001100110100110101010011001100101100101011010
[2026-04-11 08:20:11.587313] 000000000001111111000000011000110011001100110100110101010011001101010011001011010
[2026-04-11 08:20:12.943310] 000000000001111111000000011000110011001100110100110101010011001101010011001011010
[2026-04-11 08:20:14.031695] 000000000001111111000000011000110011001100110100110101010011001101010011001011010
Zitat2026.04.11 05:40:11 4: myPicoDuino/msg READ: MU;P0=-335;P1=402;P2=677;P3=-4277;P4=2534;P5=-2484;P6=-1061;P7=-704;CP=1;R=177;D=234526272727201720101010172710102710271020;p;
2026.04.11 05:40:12 4: myPicoDuino/msg READ: MU;P0=-1082;P1=-684;P2=-333;P3=372;P4=534;P5=1102;P6=178;P7=754;CP=3;R=173;D=70717171723172323232317132327132713242516;p;
2026.04.11 05:40:14 4: myPicoDuino/msg READ: MU;P0=-680;P1=-341;P2=363;P3=-4535;P4=2578;P5=-2454;P6=765;P7=-1035;CP=2;R=179;D=2345676060606120612121212060212160216021;p;
2026.04.11 05:50:12 4: myPicoDuino/msg READ: MU;P0=406;P1=130;P2=-206;P3=269;P4=764;P5=-1067;P6=-674;P7=-325;CP=0;R=178;D=4546464647064707070706464607464607071232;p;
2026.04.11 06:00:11 4: myPicoDuino/msg READ: MU;P0=383;P1=-373;P2=254;P3=-2492;P4=740;P5=-1048;P6=-672;CP=0;R=174;D=345464646410641010101064601410601010141212;e;
2026.04.11 06:10:12 4: myPicoDuino/msg READ: MU;P0=-694;P1=-340;P2=396;P3=269;P4=-217;P5=170;P6=751;P7=-1025;CP=2;R=178;D=6760606061206121212120606121206121202137345;p;
2026.04.11 06:20:11 4: myPicoDuino/msg READ: MU;P0=-667;P1=-328;P2=382;P3=752;P4=-4201;P5=2519;P6=-2478;P7=-1037;CP=2;R=178;D=45637303030312031212121203021212131202130;e;
2026.04.11 06:30:11 4: myPicoDuino/msg READ: MU;P0=-1046;P1=-678;P2=-353;P3=400;P4=-91;P5=184;P6=128;P7=768;CP=3;R=178;D=7071717172317232323231717172317231343254616;e;
2026.04.11 06:40:14 4: myPicoDuino/msg READ: MU;P0=282;P1=-169;P2=761;P3=-1026;P4=-679;P5=-317;P6=421;P7=-129;CP=6;R=179;D=23242424256425656565642465246565652467010;e;
2026.04.11 06:50:11 4: myPicoDuino/msg READ: MU;P0=201;P1=551;P3=754;P4=-1068;P5=-685;P6=-289;P7=384;CP=7;R=172;D=34353535367536767675353576367676753606160;e;
2026.04.11 07:00:11 4: myPicoDuino/msg READ: MU;P0=-328;P1=421;P2=716;P3=-235;P4=199;P6=-958;P7=-708;CP=1;R=168;D=26272727201720101017272010171020172616234;p;
2026.04.11 07:10:12 4: myPicoDuino/msg READ: MU;P0=392;P1=-4205;P2=2516;P3=-2481;P4=773;P5=-1073;P6=-676;P7=-301;CP=0;R=176;D=01234546464647064707070646464707070646070;p;
2026.04.11 07:10:14 4: myPicoDuino/msg READ: MU;P0=-682;P1=-330;P2=404;P3=-199;P4=-96;P5=282;P6=787;P7=-1070;CP=2;R=171;D=67606060612061212120606061212120606327245;e;
2026.04.11 07:30:11 4: myPicoDuino/msg READ: MU;P0=290;P1=126;P3=756;P4=-1070;P5=-727;P6=-305;P7=429;CP=7;R=10;D=343535353675367676753535767676767676767606150;p;
2026.04.11 07:40:11 4: myPicoDuino/msg READ: MU;P0=-316;P1=393;P3=572;P4=-181;P5=769;P6=-1068;P7=-663;CP=1;R=170;D=5657575750175010101757501010101710101034;p;
2026.04.11 07:50:14 4: myPicoDuino/msg READ: MU;P0=94;P1=731;P2=-1034;P3=-678;P4=-336;P5=403;P7=-183;CP=5;R=175;D=1213131314531454545313131314535454141704;p;
2026.04.11 08:00:12 4: myPicoDuino/msg READ: MU;P0=-136;P1=211;P2=99;P3=760;P4=-1037;P5=-747;P6=-340;P7=371;CP=7;R=172;D=34353535367536767675353675353576767015267;p;
2026.04.11 08:10:14 4: myPicoDuino/msg READ: MU;P0=-335;P1=371;P2=132;P3=554;P5=740;P6=-1007;P7=-674;CP=1;R=176;D=56575757501750101017575710571010501727361;p;
2026.04.11 08:20:12 4: myPicoDuino/msg READ: MU;P0=375;P1=185;P2=-441;P3=103;P4=761;P5=-1092;P6=-678;P7=-328;CP=0;R=175;D=4546464647064707070646470706460747051232;p;
2026.04.11 08:20:13 4: myPicoDuino/msg READ: MU;P0=-767;P1=-325;P2=381;P3=-443;P4=142;P5=-99;P6=754;P7=-1076;CP=2;R=175;D=6760606061206121212060612120602161234520;p;
Die RSSI Werte lagen zwischen ca -90 und -115
Hast Du beim sduino was an den Empfangsparametern angepasst?
Die Zeiten sehen jetzt besser aus:
alt
s -477, S 255, l -837, L 543
neu
s -335, S 402, l -704, L 677
s -341, S 363, l -680, L 765
s -316 S 393, l -663, L 769
s -353, S 400, l -678 L 768
Zitat von: Ralf9 am 14 April 2026, 19:18:10Die RSSI Werte lagen zwischen ca -90 und -115
Da fällt mir was ein: Empfang war am 433-Modul. Das hatte ich auf 868 hochgestellt weil ich es ja auch zum Senden genutzt habe. Dennoch so schlecht kann ich mir das nicht vorstellen.
Nein, die Einstellung war exakt dieselbe, sieht man an den Zeitstempeln. Nur die zum URH Signal passenden logs anhand der Zeiten rausgesucht. Im log sind bestimmt noch andere versteckt, ich habe 8 Sender am laufen die anderen sind aber alle schwächer an der Empfangsstation. Sagt URH
Einen weiteren Erfolg habe ich erzielt und zwar kann ich reproduzierbar Daten in RTL_433 einlesen, alle 10 Minuten sehe ich den Sensor mit geändertem Code, nach 16 Änderungen fängt es wieder von vorn an. Soll sol les sein.
Folgenden Parameter habe ich eingestellt, wie ich die in den sDuino überführe kann ich derzeit nicht. Die Einschränkung auf "2b" damit nicht zuviel reinflutet:
rtl_433 -f 868.9M -Y classic -M level -X 'n=Eberle,m=FSK_MC_ZEROBIT,s=350,l=719,r=4500,g=0,t=0,y=2523,bits>=30,match=2b'
Allerdings gibt "FSK-MC_ZEROBIT" eine sehr lange Bitfolge aus wie 2b95eaa2 und 2b95eb4c, die ich bisher nicht weiter decodieren kann.
Damit kann ich somit auch noch kein eigenständiges Device erstellen.
Beispielhaft hier noch die gewonnenen Pulsdaten: https://triq.org/pdv/#AAB0110701000009EF02D5016D105B043D00008455+AAB0110701000009EF02D5016D105B043D00009155+AAB0220701000009EF02D5016D105B043D0000A5A2A3B2A2B3A2A2B3A2A2B3A2B3A3B3B2B055 (https://triq.org/pdv/#AAB0110701000009EF02D5016D105B043D00008455+AAB0110701000009EF02D5016D105B043D00009155+AAB0220701000009EF02D5016D105B043D0000A5A2A3B2A2B3A2A2B3A2A2B3A2B3A3B3B2B055)
Die Pulsdaten vom RTL_433 sind ähnlich wie die vom sduino.
Ich habe es in das 00_SIGNALduinoAdv.pm eingebaut (siehe Anlage)
versionmodul v3.5.5-ralf_17.04.26
versionprotoL v3.5.5-ralf_17.04.26
2026.04.11 08:18:58 MU;P0=166;P1=-482;P2=-254;P3=609;P4=-1325;P5=-836;P6=230;CP=6;R=179;D=34353561613561616131653531653531653401626;p;
U218#F317BD_1111001100010111101111011
MU;P0=-335;P1=402;P2=677;P3=-4277;P4=2534;P5=-2484;P6=-1061;P7=-704;CP=1;R=177;D=234526272727201720101010172710102710271020;p;
U218#FEC39B_11111110110000111001101101Bei den Nachrichten F317xx passen die Zeiten nicht so richtig. Normalerweise müsste short low und high ungefähr gleich und die long low und high ungefähr gleich sein.
Die long müssten ungefähr das doppelte von short sein.
"218" => #
#
#
{
name => 'Eberle Instat r1',
#comment => '',
changed => '20260417 new',
id => '218',
knownFreqs => '868',
zero => [-1], # -330 short low
one => [1.18], # 390 short high
two => [-2.1], # -700 long low
float => [2.2], # 720 long high
start => [2.2, -3.2], # 720, -1050
clockabs => 330,
dispatchBin => 1,
#clockpos => ['zero',0],
format => 'twostate',
modulation => '2-FSK',
preamble => 'U218#',
#clientmodule => '',
#modulematch => '',
length_min => '10',
#length_max => '48',
postDemodulation => \&main::SIGNALduino_postDemo_EberleInstat,
},
"218.1" => #
#
#
{
name => 'Eberle Instat r1',
#comment => '',
changed => '20260417 new',
id => '218.1',
knownFreqs => '868',
zero => [-2.1], # -500 short low
one => [1], # 235 short high
two => [-3.6], # -840 long low
float => [2.5], # 580 long high
start => [2.5, -5], # 580, -1180
clockabs => 235,
dispatchBin => 1,
#clockpos => ['one',0],
format => 'twostate',
modulation => '2-FSK',
preamble => 'U218#',
#clientmodule => '',
#modulematch => '',
length_min => '10',
#length_max => '48',
postDemodulation => \&main::SIGNALduino_postDemo_EberleInstat,
}Die Zeiten ergeben sich durch clockabs * faktor
z.B. zero (short low) = -2.1 x 235 = 493.5
Es gibt eine Toleranz
my $tol=abs(abs($searchpattern)>3 ? abs($searchpattern)>16 ? $searchpattern*0.18 : $searchpattern*0.3 : 1); #tol is minimum 1 or higer, depending on our searched pulselengh
Ja, dass die Wertepaare SL/SH und LL/LH nicht gleich sind, ist mir auch mehrfach aufgefallen. Derzeit habe ich da keine Erklärung dafür. Wenn ich per RTL-SDR aufnehme und auswerte, sind die jeweils nahezu gleich lang, und Long auch das Doppelte der shorts. Also exakt so, wie man es auch erwartet.
Mit den neuen pm-Modulen habe ich jetzt ein paar Tage verbracht - und war nahezu am verzweifeln weil zwar immer mal Werte demoduliert wurden, aber mit den Werten nichts anzufangen war.
So habe ich doch wieder URH parallel laufen lassen und vorher tatsächlich einen Erfolg. Es taucht ein Bitstream mit Länge 50 auf der nach DM in URH und sDuino identisch ist. Den Kontext aus dem log poste ich mit dazu.
[2026-04-20 14:32:45.000385] 111111000001011000111101111100
[2026-04-20 14:32:46.366999] 111111000001011000111101111100
[2026-04-20 14:32:47.965502] 111111000001011000111101111100
2026.04.20 14:32:47 4: myPicoDuino/msg READ: ␂MU;P0=-215;P1=-582;P2=-2497;P3=91;P4=854;P5=-985;P7=504;CP=7;R=183;D=45407070707071704170707041417041414070723;p;␃
2026.04.20 14:32:47 4: myPicoDuino: Fingerprint for MU Protocol id 218 -> Eberle Instat r1 matches, trying to demodulate
2026.04.20 14:32:47 4: myPicoDuino: EberleInstat, rawbitmsg=11010101010100101100101010110011001011001100110101 (50)
2026.04.20 14:32:47 4: myPicoDuino: decoded matched MU Protocol id 218 dmsg U218#82C7BE_1000001011000111101111100 length 1 RSSI = -110.5
2026.04.20 14:32:47 4: myPicoDuino: equalDMS U218#82C7BE_1000001011000111101111100 (1)
2026.04.20 14:32:48 4: myPicoDuino/msg READ: ␂MU;P0=-928;P1=-220;P2=499;P3=-592;P5=-4532;P7=854;CP=2;R=183;D=7071212121212321732121217373217373712125;e;␃
2026.04.20 14:32:48 4: myPicoDuino: Fingerprint for MU Protocol id 218 -> Eberle Instat r1 matches, trying to demodulate
2026.04.20 14:32:48 4: myPicoDuino: EberleInstat, rawbitmsg=11010101010100101100101010110011001011001100110101 (50)
2026.04.20 14:32:48 4: myPicoDuino: decoded matched MU Protocol id 218 dmsg U218#82C7BE_1000001011000111101111100 length 1 RSSI = -110.5
2026.04.20 14:32:48 4: myPicoDuino: equalDMS U218#82C7BE_1000001011000111101111100 (1)
2026.04.20 14:32:48 4: myPicoDuino Dispatch: U218#82C7BE_1000001011000111101111100, Dropped (1) due to short time and equal msg
Zumindest mal für 2 Sender habe ich Übereinstimmungen:
[2026-04-20 14:49:10.797667] 111111111111011000111110000000
2026.04.20 14:49:11 4:U218#FEC7C0_1111111011000111110000000 (1)
[2026-04-20 14:32:47.965502] 111111000001011000111101111100
2026.04.20 14:32:48 4:U218#82C7BE_1000001011000111101111100 (1)
[2026-04-20 14:42:45.005738] 111111000001011000111110110010
2026.04.20 14:42:45 4:U218#82C7D9_1000001011000111110110010 (1)
[2026-04-20 14:52:46.378028] 111111000001011000111100111010
2026.04.20 14:52:47 4:U218#82C79D_1000001011000111100111010 (1)
Hier die examplarische Auswertung, um aus den Bits/Nibbles sinnvolle Werte zu erhalten. Jedes Nibble beginnt mit dem niedrigstwertigen Bit.
2026.04.20 14:32:48 4:U218#82C7BE_1000001011000111101111100 (1) => Slicen in 6 Nibbles
U218#82C7BE_1 0000 0101 1000 1111 0111 1100 => Invertierung
1111 1010 0111 0000 1000 0011
F 5 E 0 1 C
&E5F => 3920, entspricht 4-stelligen Codenummer des Senders
Nibble 4:
A: Learn
9: Reset
7: on
0: off => korrekt
Nibble 5:
Counter: 1000 => 1
14:42: 0100 => 2 korrekt
14:52: 1100 => 3 korrekt
CRC/Validity Check: (Sum Nibble 1-6) Mod 15 = 5
=> muss noch überprüft werden ob korrekt
Auffällig waren noch einige Blöcke die gleich als Manchester interpretiert wurden. Macht es Sinn, da Manchester zu disablen? Die sollen doch per MU in das Auswertemodul, oder?
2026.04.20 13:15:19 4: myPicoDuino/msg READ: ␂MC;LL=-674;LH=777;SL=-316;SH=409;D=8576E8C;C=362;L=26;R=29;s4;b4;␃
2026.04.20 13:15:19 4: myPicoDuino/msg READ: ␂MC;LL=-671;LH=781;SL=-316;SH=409;D=8576E8C;C=362;L=26;R=32;s2;b2;␃
2026.04.20 13:15:22 4: myPicoDuino/msg READ: ␂MC;LL=-672;LH=772;SL=-317;SH=409;D=857788C;C=361;L=26;R=32;s2;b2;␃
2026.04.20 13:15:23 4: myPicoDuino/msg READ: ␂MC;LL=-671;LH=771;SL=-321;SH=410;D=857788C;C=362;L=26;R=32;s2;b2;␃
2026.04.20 13:15:23 4: myPicoDuino/msg READ: ␂MC;LL=-671;LH=772;SL=-318;SH=432;D=857788C;C=365;L=26;R=33;s4;b4;␃
2026.04.20 13:15:24 4: myPicoDuino/msg READ: ␂MC;LL=-744;LH=772;SL=-310;SH=427;D=8575594;C=375;L=26;R=178;i;s3;b3;␃
2026.04.20 13:15:25 4: myPicoDuino/msg READ: ␂MC;LL=-680;LH=769;SL=-309;SH=371;D=8575594;C=354;L=26;R=195;s3;b3;␃
2026.04.20 13:15:25 4: myPicoDuino/msg READ: ␂MC;LL=-648;LH=789;SL=-315;SH=419;D=8577990;C=361;L=26;R=33;s4;b4;␃
Ich habe es ins 00_SIGNALduinoAdv.pm eingebaut (siehe Anlage)
Damit das Bit zuviel am Anfang wegfällt, habe ich den start geändert in
start => [2.2, -3.2, 2.2], # 720, -1050, 720
Habe die Bits invertiert und mit reverse die Nibbles umgedreht.
Nun sieht man, daß das Nibble 5 von 0 nach F hoch und das Nibble 6 von F nach 0 runter zählt.
Schaut gut aus, die Sendernummer und Zähler passt schon mal, da alle Sender derzeit auf aus sieht man das recht gut. Die Empfangsqualität könnte aber noch besser sein, die Bitstreamlänge ist noch nicht konstant, ergibt aber zumeist doch korrekte Werte.
Wie ich da ran gehe, weiß ich aber noch nicht so recht.
2026.04.21 18:35:48 4: myPicoDuino: equalDMS U218#46E0AD_001001100111000001011011_(24) (1)
2026.04.21 18:45:48 4: myPicoDuino: equalDMS U218#46E0BC_001001100111000011010011_(24) (1)
2026.04.21 18:55:45 4: myPicoDuino: equalDMS U218#46E0CB_0010011001110000011110100_(25) (1)
2026.04.21 19:05:48 4: myPicoDuino: equalDMS U218#46E0DA_001001100111000010110101_(24) (1)
2026.04.21 19:15:45 4: myPicoDuino: equalDMS U218#46E0E9_0010011001110000011110011_(25) (1)
2026.04.21 19:25:45 4: myPicoDuino: equalDMS U218#46E0F8_001001100111000011110001_(24) (1)
2026.04.21 19:35:48 4: myPicoDuino: equalDMS U218#46E007_001001100111000000001110_(24) (1)
2026.04.21 19:45:47 4: myPicoDuino: equalDMS U218#46E016_001001100111000010000110_(24) (1)
2026.04.21 19:55:48 4: myPicoDuino: equalDMS U218#46E02_0010011001110000010010_(22) (1)
2026.04.21 19:59:44 4: myPicoDuino: equalDMS U218#46E133_001001100111100011001100_(24) (1)
2026.04.21 18:36:19 4: myPicoDuino: equalDMS U218#7030F6_1110000011000000111101101_(25) (1)
2026.04.21 19:06:18 4: myPicoDuino: equalDMS U218#703023_111000001100000001001100_(24) (1)
2026.04.21 19:16:19 4: myPicoDuino: equalDMS U218#703032_111000001100000011000100_(24) (1)
2026.04.21 19:26:18 4: myPicoDuino: equalDMS U218#703041_1110000011000000001010001_(25) (1)
2026.04.21 19:46:18 4: myPicoDuino: equalDMS U218#70306F_111000001100000001101111_(24) (1)
2026.04.21 19:56:18 4: myPicoDuino: equalDMS U218#70307E_1110000011000000111001111_(25) (1)
2026.04.21 18:36:46 4: myPicoDuino: equalDMS U218#89B08B_000110011101000000011101_(24) (1)
2026.04.21 18:46:46 4: myPicoDuino: equalDMS U218#89B09A_000110011101000010010101_(24) (1)
2026.04.21 18:56:46 4: myPicoDuino: equalDMS U218#89B0A9_000110011101000001011001_(24) (1)
2026.04.21 19:06:46 4: myPicoDuino: equalDMS U218#89B0B8_000110011101000011010001_(24) (1)
2026.04.21 19:16:46 4: myPicoDuino: equalDMS U218#89B0C7_000110011101000000111110_(24) (1)
2026.04.21 19:26:46 4: myPicoDuino: equalDMS U218#89B0D6_000110011101000010110110_(24) (1)
2026.04.21 19:36:46 4: myPicoDuino: equalDMS U218#89B0E5_0001100111010000011110100_(25) (1)
2026.04.21 19:46:46 4: myPicoDuino: equalDMS U218#89B0F4_000110011101000011110010_(24) (1)
2026.04.21 18:37:33 4: myPicoDuino: equalDMS U218#1A90CF_100001011001000000111111_(24) (1)
2026.04.21 18:47:33 4: myPicoDuino: equalDMS U218#1A90DE_100001011001000010110111_(24) (1)
2026.04.21 18:57:34 4: myPicoDuino: equalDMS U218#1A90ED_1000010110010000011110111_(25) (1)
2026.04.21 19:07:32 4: myPicoDuino: equalDMS U218#1A90FC_100001011001000011110011_(24) (1)
2026.04.21 19:17:32 4: myPicoDuino: equalDMS U218#1A900B_100001011001000000001101_(24) (1)
2026.04.21 19:37:33 4: myPicoDuino: equalDMS U218#1A9029_1000010110010000010010010_(25) (1)
2026.04.21 19:57:32 4: myPicoDuino: equalDMS U218#1A9047_1000010110010000001011101_(25) (1)
Evtl passt die Datarate noch nicht ganz, sie muss recht genau stimmen.
ja, das steht bei FSK generell so drin, habe ich gesehen. Nur was "recht genau" ist steht nirgends. Dazu habe ich ein paar Tests angestellt. Rechnerisch sollte die Datenrate bei mir ja 2733 Baud sein. Also habe ich
- die Baudrate veringert => die Erkennung wurde deutlich schlechter.
- die Baudate erhöht => da ist das Bild wesentlich uneinheitlicher.
Generell zu sagen ist, dass
- immer 6 Sender erkannt wurden
- die RSSI Angaben aus meiner Sicht keinen Aufschluß geben (der gleiche Sender innerhalb einer Sekunde einmal -60dB, dann -100dB, und auch in der Wiederholung extrem schwankend). Für mich also erst mal kein Maßstab.
- dann habe ich die Anzahl der erkannten Signale über eine halbe Stunde gezählt. Maximal wären 54 möglich. Das Ergebnis ist unten in der Tabelle
Auffällig ist für mich, dass immer bei Tausender-bauds (4000, 5000, 6000) die Quote deutlich über den 500erten ist. Dafür habe ich keine Erklärung. Tests zu weiteren Zwischenwerten 250er / 750er laufen noch wie es da aussieht.
Die eigentliche Baudrate treffen muss ich zumindest nicht. Und vielfaches sind es auch nicht. Sonst eine Idee, was ich noch machen / auswerten könnte?
Was wäre denn der nächste Schritt um das Device U218 "richtig" einzubinden? Sprich, dass es zB wie ein Funkschalter dargestellt wird. Also mit den Werten "Identnummer des Senders", Status, Zähler und CRC.
Und im übernächsten Schritt dann das Senden der Telegramme, so dass auch die Aktoren angesteuert werden können.
2733.71 Baud => 26 matches
3000.26 Baud => 36 matches
3508.57 Baud => 29 matches
4004.48 Baud => 39 matches
4500.39 Baud => 29 matches
5008.70 Baud => 36 matches
5504.61 Baud => 29 matches
6000.52 Baud => 40 matches
Wie siehts mit der DEVIATN aus? Hast Du die ermittelt oder durch probieren herausgefunden?
Zitat von: DerD am 24 April 2026, 19:03:03Was wäre denn der nächste Schritt um das Device U218 "richtig" einzubinden? Sprich, dass es zB wie ein Funkschalter dargestellt wird. Also mit den Werten "Identnummer des Senders", Status, Zähler und CRC.
Es fehlt noch die Bedeutung vom Status Nibble. Hast Du geschaut ob dies immer die gleichen Werte sind oder ob da noch was anderers drin stecken könnte?
Ich kann nicht erkennen, daß da eine Prüfsumme drin steckt.
Deviation ist abgeglichen zwischen Sender und CC1101 per SDR-RTL und Waterfalldiagramm. Da sehe ich kein Potential.
zu den Bedeutungen der Nibbles hier. Ausgeben kann man die Prüfsumme schon, die finale Verifizierung des Algorithmus steht aber noch aus. Immer wieder hatte ich da Unstimmigkeiten, was aber auch von der Dekodierung gekommen sein mag. Und der CRC zu Recht nicht gepasst hat.
Zitat von: DerD am 20 April 2026, 17:24:09...
Hier die examplarische Auswertung, um aus den Bits/Nibbles sinnvolle Werte zu erhalten. Jedes Nibble beginnt mit dem niedrigstwertigen Bit.
2026.04.20 14:32:48 4:U218#82C7BE_1000001011000111101111100 (1) => Slicen in 6 Nibbles
U218#82C7BE_1 0000 0101 1000 1111 0111 1100 => Invertierung
1111 1010 0111 0000 1000 0011
F 5 E 0 1 C
&E5F => 3920, entspricht 4-stelligen Codenummer des Senders
Nibble 4:
A: Learn
9: Reset
7: on
0: off => korrekt
Nibble 5:
Counter: 1000 => 1
14:42: 0100 => 2 korrekt
14:52: 1100 => 3 korrekt
CRC/Validity Check: (Sum Nibble 1-6) Mod 15 = 5
=> muss noch überprüft werden ob korrekt
bzw ausführlicher:
Zitat von: DerD am 11 März 2022, 13:22:19...
...
xxxx xxxx xxxx xxxx xxxx xxxx
0123 0123 0123 0123 0123 0123
|| || || || || ||
|| || || || || ||
|| || || || || ||
|| || || || || \/
|| || || || || Prüfcode 0-F
|| || || || ||
|| || || || \/
|| || || || Zähler 0-F
|| || || ||
|| || || \/
|| || || Actioncode 0-F
|| || \/
|| || ID2, 0-F, zufällige Änderung bei jedem Lernen
|| ||
|| \/
|| ID1, 0-F, zufällige Änderung bei jedem Lernen
||
\/
ID0, 0-F, zufällige Änderung bei jedem Lernen
Actioncodes:
A: Lernen
9: Reset
7: An
0: Aus
Zähler:
einfaches Hochzählen um "1" für jede Aktion
Ausnahme: bei Actionscode "A" bleibt Zähler konstant
Prüfcode:
Berechnung: 15 - ((Summe Nibbles 1-5) mod 15)
Validity Check: Summe Nibbles 1-6 mod 15 = 15
Lernen:
xxx81x, gesendet im 6 Sekunden Takt
Reset: Sequenz des Actioncodes
9/0/7/0/7/0/7/0/0
xxx91x
xxx02x
xxx73x
xxx04x
etc.
ZitatNibble 4:
A: Learn
9: Reset
7: on
0: off => korrekt
Bei den Nachrichten vom 2026.04.11 gibts auch Nibble 4: 1
z.B.
2026.04.11 06:40:14 MU;P0=282;P1=-169;P2=761;P3=-1026;P4=-679;P5=-317;P6=421;P7=-129;CP=6;R=179;D=23242424256425656565642465246565652467010;e;
U218#04E193_000000100111100010011100_(24)04E166
04E175
04E184
04E193
04E0A3
04E0B2
Kannst Du bitte auch mal posten wie die Nachrichten aussehen, wenn es von off nach on wechselt?
Hast Du inzwischen überprüft ob Deine berechnung der Prüfsumme passt?
Guter Hinweis mit dem Wert "1" bei Nibble 4. Das ist wohl ein Status den ich bisher nicht aktiv generieren konnte und dessen Bedeutung mir derzeit auch nicht bekannt ist. Es scheint aber korrekt zu sein, die Checksumme berücksichtigt die Änderung um 1 ja.
2026.05.03 08:34:41 4: MySignalPicoLAN/msg READ: ␂MU;P0=343;P1=-764;P2=-4954;P3=2491;P4=-2546;P5=688;P6=-1138;P7=-394;CP=0;R=19;D=23456570157015707070107070707075701510757010;e;␃
2026.05.03 08:34:41 4: MySignalPicoLAN: Fingerprint for MU Protocol id 218 -> Eberle Instat r1 matches, trying to demodulate
2026.05.03 08:34:41 4: MySignalPicoLAN: EberleInstat, rawbitmsg=0100110100110101010010101010101101001100101101001 (48)
2026.05.03 08:34:41 4: MySignalPicoLAN: decoded matched MU Protocol id 218 dmsg U218#9CD715_100100111011111010001010_(24) length 1 RSSI = -64.5
2026.05.03 08:34:41 4: MySignalPicoLAN: equalDMS U218#9CD715_100100111011111010001010_(24) (1)
2026.05.03 08:34:41 4: MySignalPicoLAN Dispatch: U218#9CD715_100100111011111010001010_(24), Dropped (1) due to short time and equal msg
2026.05.03 08:34:57 4: MySignalPicoLAN/msg READ: ␂MU;P0=-1299;P1=-398;P2=336;P3=-775;P5=2469;P6=-2556;P7=673;CP=2;R=30;D=567071237123712121232121737371237121232120;e;␃
2026.05.03 08:34:57 4: MySignalPicoLAN: Fingerprint for MU Protocol id 218 -> Eberle Instat r1 matches, trying to demodulate
2026.05.03 08:34:57 4: MySignalPicoLAN: EberleInstat, rawbitmsg=0100110100110101010010101100110011010011010100101 (48)
2026.05.03 08:34:57 4: MySignalPicoLAN: decoded matched MU Protocol id 218 dmsg U218#9CD02B_100100111011000001001101_(24) length 1 RSSI = -59
2026.05.03 08:34:57 4: MySignalPicoLAN: equalDMS U218#9CD02B_100100111011000001001101_(24) (1)
2026.05.03 08:35:00 4: MySignalPicoLAN/msg READ: ␂MU;P0=328;P1=2454;P2=-2614;P3=659;P4=-1226;P5=-406;P6=244;P7=-797;CP=0;R=31;D=12343567373507050537050505053565070505370504;e;␃
2026.05.03 08:35:00 4: MySignalPicoLAN: Fingerprint for MU Protocol id 218 -> Eberle Instat r1 matches, trying to demodulate
2026.05.03 08:35:00 4: MySignalPicoLAN/msg READ: ␂MU;P0=329;P1=-797;P2=-4616;P3=2468;P4=-2591;P5=662;P6=-1143;P7=-390;CP=0;R=37;D=234565701515701070751070707075707010707510707;e;␃
2026.05.03 08:35:00 4: MySignalPicoLAN: Fingerprint for MU Protocol id 218 -> Eberle Instat r1 matches, trying to demodulate
2026.05.03 08:35:00 4: MySignalPicoLAN: EberleInstat, rawbitmsg=01001100110100101011001010101011010100101011001010 (50)
2026.05.03 08:35:00 4: MySignalPicoLAN: decoded matched MU Protocol id 218 dmsg U218#1A97B9_1000010110011110110110011_(25) length 1 RSSI = -55.5
2026.05.03 08:35:00 4: MySignalPicoLAN: equalDMS U218#1A97B9_1000010110011110110110011_(25) (1)
2026.05.03 08:35:29 4: MySignalPicoLAN/msg READ: ␂MU;P0=-4435;P1=2458;P2=-2583;P3=649;P4=-1138;P5=-407;P6=312;P7=-780;CP=6;R=37;D=0123435673735676565376537373765656565656567;e;␃
2026.05.03 08:35:29 4: MySignalPicoLAN: Fingerprint for MU Protocol id 218 -> Eberle Instat r1 matches, trying to demodulate
2026.05.03 08:35:29 4: MySignalPicoLAN: EberleInstat, rawbitmsg=010011001101001010110010110011001100101010101010100 (50)
2026.05.03 08:35:29 4: MySignalPicoLAN: decoded matched MU Protocol id 218 dmsg U218#1A90CF_1000010110010000001111111_(25) length 1 RSSI = -55.5
2026.05.03 08:35:29 4: MySignalPicoLAN: equalDMS U218#1A90CF_1000010110010000001111111_(25) (1)
2026.05.03 08:35:30 4: MySignalPicoLAN/msg READ: ␂MU;P0=-4643;P1=2474;P2=-2627;P3=650;P4=-1133;P5=-406;P6=344;P7=-792;CP=6;R=29;D=0123435673735676565376537373765656565656562;e;␃
2026.05.03 08:35:30 4: MySignalPicoLAN: Fingerprint for MU Protocol id 218 -> Eberle Instat r1 matches, trying to demodulate
2026.05.03 08:35:30 4: MySignalPicoLAN: EberleInstat, rawbitmsg=0100110011010010101100101100110011001010101010101 (48)
2026.05.03 08:35:30 4: MySignalPicoLAN: decoded matched MU Protocol id 218 dmsg U218#1A90CF_100001011001000000111111_(24) length 1 RSSI = -59.5
2026.05.03 08:35:30 4: MySignalPicoLAN: equalDMS U218#1A90CF_100001011001000000111111_(24) (1)
2026.05.03 08:35:33 4: MySignalPicoLAN/keepalive ok, retry = 0
Manuell bzw. automatisch an/aus wechselt 7/0 auf Nibble 4.
Die Verifizierung der Prüfsummenberechnung steht tatsächlich noch aus. Es klemmt daran, dass ich aus den unendlich langen log-files die entsprechenden patterns mit 'U218' nicht automatisiert rausbekomme, so dass ich eine gescheite und möglichst umfassende Wertebasis habe.
Deshalb war hier meine Idee, für jeden Sender ein jeweiliges Device automatisiert zu erstellen und die ausgelesenen Nibblewerte in entsprechende log-files zu plotten. Ist aber daran gescheitert, dass ich es auch zusammen mit GPT nicht geschafft habe, ein passendes instat.pm zu erstellen und korrekt einzubinden :(
Zitat von: DerD am 03 Mai 2026, 09:29:01Die Verifizierung der Prüfsummenberechnung steht tatsächlich noch aus. Es klemmt daran, dass ich aus den unendlich langen log-files die entsprechenden patterns mit 'U218' nicht automatisiert rausbekomme, so dass ich eine gescheite und möglichst umfassende Wertebasis habe.
Es werden events erzeugt, die können mit einem notify ausgewertet werden.
z.B.
define instatNot notify MySignalPicoLAN:DMSG.*U218.* {\\
my $e = $EVENT;;\\
my (undef, $d) = split('#', $e);;\\
my ($dd, undef, $dl) = split('_', $d);;\\
Log 2, ('test---test ' . $dd . ' ' . $dl)}
Die Prüfsumme ist bestimmt, anhand der gewonnenen Liste konnte das schnell bestimmt werden (im Gegensatz zu fhem kann GPT das sehr gut): das Komplement zu 0xF (15) der Nibble-Summe.
Checksum=(0xF−(∑Nibblesmod16))mod16
Beispiel: 04E01C
Nibbles: 0, 4, E(14), 0, 1
Summe: 0+4+14+0+1=19
19mod16=3
0xF−3=12=C ✅
Beispiel: 04E02B
Summe: 0+4+14+0+2=20
20mod16=4
0xF−4=11=B ✅
89B71B:
Nibbles (ohne Checksumme): 8, 9, B(11), 7, 1
Summe: 8+9+11+7+1=36
36mod16=4
0xF−4=11=B
Interpretation:
Das ist eine einfache 4-Bit One's-Complement Checksumme über die Nibbles, so gewählt, dass gilt:
(Summe aller 6 Nibbles)mod16=0xF
Was den Wert von Nibble4 mit "1" angeht, habe ich die Vermutung, dass da vielleicht ein Battery-Low gesendet wird, auch wenn der Empfänger (zumindest meiner) dafür keine Verwendung hat. Die Ventile bleiben auf "zu". Ist derzeit aber noch reine Spekulation. Habe ich bei 2 Sendern jetzt gesehen, und leider noch ohne Systematik. Nur einmal als Reihe, und davon hatte ich zufällig Werte zum hier posten erwischt.
Um ein jeweiliges Logfile für jeden Sender zu haben, habe ich mir mit sowas beholfen. Nicht schön und alle manuell angelegt. Aber sie tun zumindest mal was sie sollen.
define log9CD FileLog ./log/log9CD-%Y.log MySignalPicoLAN:DMSG.*U218#9CD.*
# CFGFN
# DEF ./log/log9CD-%Y.log MySignalPicoLAN:DMSG.*U218#9CD.*
# FD 19
# FUUID 69f8c7fc-f33f-3e5d-3ea0-f9ef6e4863e3358f
# NAME log9CD
# NOTIFYDEV MySignalPicoLAN
# NR 67
# NTFY_ORDER 50-log9CD
# REGEXP MySignalPicoLAN:DMSG.*U218#9CD.*
# STATE active
# TYPE FileLog
# currentlogfile ./log/log9CD-2026.log
# logfile ./log/log9CD-%Y.log
# READINGS:
# 2026-05-04 19:08:01 linesInTheFile 1
#
setstate log9CD active
setstate log9CD 2026-05-04 19:08:01 linesInTheFile 1
Kleine Überraschung was den Statusnibble betrifft. Da gibt es mehr Varianten als ich bisher hatte, was mit den unterschiedlichen Sendern zu tun hat.
Was ich bisher wusste, VN0102 und VN0204 unterscheiden sich im Protokoll und Frequenzshift. Dann gibt Sender analog und mit digitalem Display. Die digitalen haben Protokoll und Frequenzshift wie VN0204. Also dachte ich, der Rest ist auch gleich. Nix da, jetzt sehe ich nämlich, dass die andere Statuswerte schicken:
VN0204 VN0102 Analog "ein": 7
VN0204 VN0102 Analog "aus": 0
Rev 2.6 digital "ein": 1
Rev 2.6 digital "aus" 0-5K: 0
Rev 2.6 digital "aus" 5-10K: 4
Rev 2.6 digital "aus" >10K: 2
Also in Abhängigkeit Soll/Isttemperatur gibt es verschiedene "aus" Modi. Einen weiteren "An"-Modus zusätzlich zu "1" habe ich noch nicht gefunden, auch wenn Soll >5K über Ist.
Mehr wie "Aus" können meine Aktoren aber auch nicht. Kann sein, dass da auch Klimaanlagensteuerung möglich ist, was ich nicht habe.
Bei den analogen dreht sich im Kühl- statt Heizbetrieb "ein" und "aus" einfach um, also "0" statt "7" und umgekehrt.
Was die Demodulation angeht, da gibt es noch Protokolle die durchrutschen. Hier zB die ersten beiden, der dritte klappt dann, ist aber dennoch nicht vollständig. Hast du eine Ideen warum? Protokolle mit weniger RSSI werden dagegen korrekt demoduliert.
2026.05.05 13:12:01 4: MySignalPicoLAN/msg READ: ␂MU;P0=485;P1=2449;P2=-2637;P3=644;P4=-1082;P5=-451;P6=275;P7=-796;CP=6;R=5;D=123435656567373765653737376565656535656704;e;␃
2026.05.05 13:12:01 4: MySignalPicoLAN: Fingerprint for MU Protocol id 218 -> Eberle Instat r1 matches, trying to demodulate
2026.05.05 13:12:01 4: MySignalPicoLAN/msg READ: ␂MU;P0=225;P1=-293;P2=-2614;P3=649;P4=-1188;P5=-476;P6=318;P7=-806;CP=6;R=211;D=23435656567373765653737376565656535050761;e;␃
2026.05.05 13:12:01 4: MySignalPicoLAN: Fingerprint for MU Protocol id 218 -> Eberle Instat r1 matches, trying to demodulate
2026.05.05 13:12:02 4: MySignalPicoLAN/msg READ: ␂MU;P0=225;P1=2444;P2=-2602;P3=648;P4=-1086;P5=-477;P6=301;P7=-803;CP=6;R=220;D=123435656567373765653737376565656535050764;e;␃
2026.05.05 13:12:02 4: MySignalPicoLAN: Fingerprint for MU Protocol id 218 -> Eberle Instat r1 matches, trying to demodulate
2026.05.05 13:12:02 4: MySignalPicoLAN: EberleInstat, rawbitmsg=0101010011001100101011001100110010101010110 (42)
2026.05.05 13:12:02 4: MySignalPicoLAN: decoded matched MU Protocol id 218 dmsg U218#7030F_111000001100000011110_(21) length 1 RSSI = -92
2026.05.05 13:12:02 4: MySignalPicoLAN: equalDMS U218#7030F_111000001100000011110_(21) (1)
ZitatWas die Demodulation angeht, da gibt es noch Protokolle die durchrutschen. Hier zB die ersten beiden, der dritte klappt dann, ist aber dennoch nicht vollständig. Hast du eine Ideen warum? Protokolle mit weniger RSSI werden dagegen korrekt demoduliert.
Das erste und zweite wird bei mir als id 218.1 erkannt.
Bei der zweiten und dritten haben am Ende 2 Pulszeiten nicht gepasst, habe 0 durch 6 ersetzt, dann hats gepasst
MU;P0=485;P1=2449;P2=-2637;P3=644;P4=-1082;P5=-451;P6=275;P7=-796;CP=6;R=5;D=123435656567373765653737376565656535656704;e;
decoded matched MU Protocol id 218.1 dmsg U218#7030F6_111000001100000011110110_(24) length 1 RSSI = -71.5
MU;P0=225;P1=-293;P2=-2614;P3=649;P4=-1188;P5=-476;P6=318;P7=-806;CP=6;R=211;D=23435656567373765653737376565656535656761;e;
decoded matched MU Protocol id 218.1 dmsg U218#7030F6_111000001100000011110110_(24) length 1 RSSI = -96.5
MU;P0=225;P1=2444;P2=-2602;P3=648;P4=-1086;P5=-477;P6=301;P7=-803;CP=6;R=220;D=123435656567373765653737376565656535050764;e;
decoded matched MU Protocol id 218 dmsg U218#7030F6_111000001100000011110110_(24) length 1 RSSI = -92
Zitat von: Ralf9 am 05 Mai 2026, 21:57:30Bei der zweiten und dritten haben am Ende 2 Pulszeiten nicht gepasst, habe 0 durch 6 ersetzt, dann hats gepasst
So ganz habe ich das nicht kapiert was du damit sagst. War das eine manuelle Anpassung der Streamdaten oder der Auswerteparameter? Bei ersterem wäre für die Routine außer Enpfangsverbesserung ja nichts möglich, oder?
Ich hatte für den 218.1 nie eine Erkennung gehabt, deshalb aus der whitelist genommen.
Der 703-Sender wird im Regelfalll auch von 218 erkannt. Nur in den Einzelfällen nicht, wie den obigen. Kann man da nicht was anpassen, dass es die auch erkennt?
Da wollte ich eh mal fragen warum es den überhaupt gibt. Die Parameter sind nämlich auch etwas seltsam, short low fast so lang wie long high.
zero => [-2.1], # -500 short low
one => [1], # 235 short high
two => [-3.6], # -840 long low
float => [2.5], # 580 long high
Ergänzung:
cmdBank:
A: b=0 freq:868.965MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:4004.48Baud) [boffs=0000]
ccmode=0 sync=D391 Modulation:2-FSK (SYNC_MODE:No preamble/sync) DEVIATN:14.282kHzccregAll:
ccreg 00: 0D 2E 2D 07 D3 91 3D 04 32 00 00 06 00 21 6B F6
ccreg 10: 57 43 00 23 B9 31 07 00 18 14 6C 07 00 90 87 6B
ccreg 20: F8 56 11 ED 2D 14 11 41 00 59 7F 3F 88 31 0B
cc1101 reg detail - addr, name, value, (OOK default),[reset]
0x00 IOCFG2 - 0x0D [29]
0x01 IOCFG1 - 0x2E
0x02 IOCFG0 - 0x2D [3F]
0x03 FIFOTHR - 0x07
0x04 SYNC1 - 0xD3
0x05 SYNC0 - 0x91
0x06 PKTLEN - 0x3D [0F]
0x07 PKTCTRL1 - 0x04
0x08 PKTCTRL0 - 0x32 [45]
0x09 ADDR - 0x00
0x0A CHANNR - 0x00
0x0B FSCTRL1 - 0x06 [0F]
0x0C FSCTRL0 - 0x00
0x0D FREQ2 - 0x21 (10) [1E]
0x0E FREQ1 - 0x6B (B0) [C4]
0x0F FREQ0 - 0xF6 (71) [EC]
0x10 MDMCFG4 - 0x57 [8C]
0x11 MDMCFG3 - 0x43 (C4) [22]
0x12 MDMCFG2 - 0x00 (30) [02]
0x13 MDMCFG1 - 0x23 [22]
0x14 MDMCFG0 - 0xB9 [F8]
0x15 DEVIATN - 0x31 (00) [47]
0x16 MCSM2 - 0x07
0x17 MCSM1 - 0x00 [30]
0x18 MCSM0 - 0x18 [04]
0x19 FOCCFG - 0x14 [36]
0x1A BSCFG - 0x6C
0x1B AGCCTRL2 - 0x07 [03]
0x1C AGCCTRL1 - 0x00 [40]
0x1D AGCCTRL0 - 0x90 [91]
0x1E WOREVT1 - 0x87
0x1F WOREVT0 - 0x6B
0x20 WORCTRL - 0xF8
0x21 FREND1 - 0x56
0x22 FREND0 - 0x11 [16]
0x23 FSCAL3 - 0xED (E9) [A9]
0x24 FSCAL2 - 0x2D (2A) [0A]
0x25 FSCAL1 - 0x14 (00) [20]
0x26 FSCAL0 - 0x11 (1F) [0D]
0x27 RCCTRL1 - 0x41
0x28 RCCTRL0 - 0x00
0x29 FSTEST - 0x59
0x2A PTEST - 0x7F
0x2B AGCTEST - 0x3F
0x2C TEST2 - 0x88
0x2D TEST1 - 0x31
0x2E TEST0 - 0x0B
Zitat von: DerD am 06 Mai 2026, 09:03:04So ganz habe ich das nicht kapiert was du damit sagst. War das eine manuelle Anpassung der Streamdaten oder der Auswerteparameter?
Das war eine manuelle Anpassung der Streamdaten, da bleibt nur eine Empfangsverbesserung.
ZitatDa wollte ich eh mal fragen warum es den überhaupt gibt. Die Parameter sind nämlich auch etwas seltsam, short low fast so lang wie long high.
Die id 218.1 gibts damit auch diese MU Nachrichten mit den seltsamen Pulszeiten erkannt werden.
Hier ist der rfmode, eingelesen wird er mit "get raw"
CW000D,022D,0307,04D3,0591,063D,0704,0832,0D21,0E6B,0FF6,1057,1143,1200,1323,14B9,1531,1700,1818,1914,1B07,1C00,1D90,23E9,242A,2500,2611,3D00,3E00,4045,4162,4249,436E,4473,4574,4661,4774Mir sind dabei 2 cc Register aufgefallen:
0x1B AGCCTRL2 - 0x07 , -> bei fast allen anderen rfmode ist es 0x43
0x1D AGCCTRL0 - 0x90 , -> bei fast allen anderen rfmode ist es 0x91
Zitat von: Ralf9 am 07 Mai 2026, 20:10:55Hier ist der rfmode, eingelesen wird er mit "get raw"
CW000D,022D,0307,04D3,0591,063D,0704,0832,0D21,0E6B,0FF6,1057,1143,1200,1323,14B9,1531,1700,1818,1914,1B07,1C00,1D90,23E9,242A,2500,2611,3D00,3E00,4045,4162,4249,436E,4473,4574,4661,4774
Mir sind dabei 2 cc Register aufgefallen:
0x1B AGCCTRL2 - 0x07 , -> bei fast allen anderen rfmode ist es 0x43
0x1D AGCCTRL0 - 0x90 , -> bei fast allen anderen rfmode ist es 0x91
0x1D AGCCTRL0 - 0x90 ist erklärbar, hatte ich manuell auf 4db gesetzt um es empfindlich zu machen. Jetzt steht es wieder auf 8dB mit dem Ergebnis 0x1D AGCCTRL0 - 0x91 (90). Hat aber keinen offensichtlichen Einfluß auf die Erkennung bei mir, auch nicht bei Maximalwert 16db.
Das bei 0x1B AGCCTRL2 - 0x07 kann ich nicht erklären. cc1101_rAmpl steht auf 42dB (gewollt) und damit 0x07, das entspräche laut Datenblatt ja der Grundeinstellung (00000011) plus eben 42dB also 00000111 (0x07)
0x43 stände für "The highest gain setting can not be used" und 33db. Das kann ich manuell über die settings so gar nicht vergeben, nur per raw definition vermutlich.
Zitat von: Ralf9 am 07 Mai 2026, 20:10:55Die id 218.1 gibts damit auch diese MU Nachrichten mit den seltsamen Pulszeiten erkannt werden.
Dann vielleicht mal ein Schritt zurück: ich hatte als Basis rfmode den hier ausgewählt "HoneywActivL__SlowRf_FSK" und basierend darauf Frequenz, Deviation angepasst. Möglicherweise sollte ich von einer anderen Basis ausgehen? So wie ich das im SDR sehe, sind die Pulszeiten für SL/SH und LL/LH nämlich jeweils ziemlich gleich. Sprich es könnten die Einstellungen des CC1101 sein die nicht passen. Hast du einen Tipp was da zu empfehlen ist? Ich habe ja auch keinen anderen FSK-Sender mit dem ich testen könnte ob es da anders ist.
Zitat von: DerD am 09 Mai 2026, 10:22:400x1D AGCCTRL0 - 0x90 ist erklärbar, hatte ich manuell auf 4db gesetzt um es empfindlich zu machen. Jetzt steht es wieder auf 8dB mit dem Ergebnis 0x1D AGCCTRL0 - 0x91 (90). Hat aber keinen offensichtlichen Einfluß auf die Erkennung bei mir, auch nicht bei Maximalwert 16db.
0x1D AGCCTRL0 hat bei FSK eine andere Bedeutung als bei ASK/OOK
Zitat von: DerD am 09 Mai 2026, 10:22:40Das bei 0x1B AGCCTRL2 - 0x07 kann ich nicht erklären. cc1101_rAmpl steht auf 42dB (gewollt) und damit 0x07, das entspräche laut Datenblatt ja der Grundeinstellung (00000011) plus eben 42dB also 00000111 (0x07)
0x43 stände für "The highest gain setting can not be used" und 33db. Das kann ich manuell über die settings so gar nicht vergeben, nur per raw definition vermutlich.
Hast Du auch mal die 0x43 getestet ob es beim Empfang einen Unterschied macht?
Zitat von: DerD am 09 Mai 2026, 10:22:40Dann vielleicht mal ein Schritt zurück: ich hatte als Basis rfmode den hier ausgewählt "HoneywActivL__SlowRf_FSK" und basierend darauf Frequenz, Deviation angepasst. Möglicherweise sollte ich von einer anderen Basis ausgehen? So wie ich das im SDR sehe, sind die Pulszeiten für SL/SH und LL/LH nämlich jeweils ziemlich gleich. Sprich es könnten die Einstellungen des CC1101 sein die nicht passen. Hast du einen Tipp was da zu empfehlen ist? Ich habe ja auch keinen anderen FSK-Sender mit dem ich testen könnte ob es da anders ist.
Ich hab mir mal die Unterschiede zu den FSK rfmodes angeschaut.
Die rfmodes stehen am Anfang der signalduino_protocols.pm und können einfach miteinander verglichen werden.
0x12 MDMCFG2, wenn das sync-word bekannt ist, kannst Du auch mal 02 und 06 testen
0x14 MDMCFG0, bei den anderen rfmode wird 0xF8 verwendet
0x19 FOCCFG, bei FSK 0x16
0x1C AGCCTRL1, bei FSK 0x68 oder 0x40