Hallo Zusammen, ich habe ein Signal von einem 433 MHz-Empfänger aufgezeichnet (siehe Bild) und möchte dies nun dekodieren. Ich denke, dass dieses Signal Manchester codiert ist, weiß aber nicht, welche Variante des Manchester Signals hier vorliegt also z.B. Manchester, Manchester-Differentiell, Bi-Phase mark code, Bi-Phase space code (sofern es Manchester ist). Zudem benötige ich die Bitrate des Signals für die Auswertung im Logicanalyser. Mich hat irritiert, dass die Präambel scheinbar langsamer ist als die Nutzdaten? Vielen Dank für eure Hilfe im Voraus!
Probier mal folgenden einfachen Algorithmus: Der Datenstrom hat die Periodendauer TP. Das ist der reziproke Wert der Bitrate. 1. Triggere auf eine beliebige* Flanke zum Zeitpunkt T0 2. Nimm das Datum nach T0 + 0.75 * TP und schiebe es in ein Register 3. Gehe zu 1. Ist doch einfach, oder? Jedenfalls schaffen es schon (Uralt-)TTL-Kaefer ein solches Datenformat zu dekodiern. *) Erwischt man die falsche Flanke, werden nur die Daten invertiert. Daher braucht man eine dagegen resistente Praeambel.
Danke für deine Antwort! Ich habe mal mit PulseView und dem OOK Manchester decoder das Singal ausgewertet, erhalte aber Fehler. Ich bin mir nicht sicher, ob es wirklich Manchester ist oder irgendein anderes Protokoll. Vielleicht hat ja jemand so etwas in der Art schon mal gesehen?
Alexander K. schrieb: >Ich bin mir nicht sicher, ob es >wirklich Manchester ist oder irgendein anderes Protokoll. Manchester Codierung ist ja erfunden worden um Gleichspannungsfreiheit im Signal zu erreichen. Dadurch kann man das Signal auch durch NF-Übertrager schicken oder über ein Leitungsweg in dem sich Koppelkondensatoren befinden. Im Gegensatz zu RS-232 das nicht Gleichspannungsfrei ist. Also prüfen ob es Gleichspannungsfrei ist, dann ist es Manchester.
Alexander K. schrieb: > ich habe ein Signal von einem 433 MHz-Empfänger aufgezeichnet (siehe > Bild) und möchte dies nun dekodieren. Ich denke, dass dieses Signal > Manchester codiert ist Bei einer Manchester-Codierung kommen nur genau zwei Halbperiodenlängen vor, von denen die eine genau das Doppelte der anderen beträgt. Und in der Summe der Häufigkeiten halten sich jeweils die halblangen und die langen Low- und High-Phasen exakt die Waage (nur +-1 Abweichung über die gesamte Nachricht ist erlaubt). Also: das ist definitiv keine Manchester-Codierung, da sie keine der beiden wesentlichen Eigenschaften einer solchen besitzt.
Die langsamen Wechsel sind vermutlich Synchronisierung. Dann kommen die eigentlichen Daten. Das Low-Signal in den eigentlichen Daten ist immer gleich lang. Das High-Signal ist unterschiedlich lang.
Manchmal kommt man auch weiter, wenn man weiß bzw. die Info teilt, wer das 433MHz Signal sendet, bei Funksteckdosen wäre RC-Switch zB eine guter Einstieg, auch für Wetterstationen gibt es schon diveres. Nimm mal die einzelnen Pulsdauern einer Serie als Werte, dann schauen wieviel unterschiedliche Vielfache des kürzesten Pulses auftauchen. Bei Manchester (was es definitiv nicht ist) wäre das 1T, 2T.
Danke für eure Antworten! > Wie heißt das Empfänger-IC? Empfänger ist der CMT2210LCW. 433 MHz OOK-Modulation. >Manchmal kommt man auch weiter, wenn man weiß bzw. die Info teilt, wer >das 433MHz Signal sendet... Über das Funksignal werden LED RGB Armbänder gesteuert. Link: https://www.rfbracelet.com/product/rf-led-bracelet/ In dem angehängten Bild habe ich mal drei Telegramme übereinander gelegt. Das Erste schaltet das LED-Band auf Rot, das zweite Telegramm schaltet auf Grün und das Dritte auf Blau. Die drei Bytes, die sich jeweils unterscheiden, lassen sich auch in dem Bild gut erkennen. Die beiden letzten Bytes im Telegramm werden wahrscheinlich noch für die Adressierung mehrerer Gruppen sowie für Flash/Strobe Effekte da sein. Jetzt stellt sich nur noch die Frage, wie die Daten kodiert sind. >Die langsamen Wechsel sind vermutlich Synchronisierung. Dann kommen die >eigentlichen Daten. Das Low-Signal in den eigentlichen Daten ist immer gleich >lang. Das High-Signal ist unterschiedlich lang. Das könnte echt der Schlüssel zur Lösung sein, vielleicht kann ja jemand mit dem Screenshot des Signals und der Info über die RGB-Zuordnung einen Schluss daraus ziehen?
:
Bearbeitet durch User
Dieter R. schrieb: > DMX over 433MHz? Nein, es ist ein anderes Protokoll. Ich möchte aber genau so etwas umsetzen, dass ich diese LED Armbänder über DMX steuern kann. Ich habe bisher nur eine einfache Fernbedienung mit Tastern dafür. Mit der Fernbedienung und dem entsprechenden Empfänger wurden auch die hier im Thread gezeigten Signale generiert.
Alexander K. schrieb: > Das könnte echt der Schlüssel zur Lösung sein, vielleicht kann ja jemand > mit dem Screenshot des Signals und der Info über die RGB-Zuordnung einen > Schluss daraus ziehen? Dazu braucht man noch mehr Input. Kannst du die LEDs auch auf "dunkelgrau" setzen, also alle drei an, aber mit der geringstmöglichen Helligkeit? Und dann auf ein etwas helleres "Grau"? Die entsprechenden Telegramme im Vergleich zu den drei, die du schon gepostet hast, sollte die Lösung des Rätsels ermöglichen.
c-hater schrieb: > Dazu braucht man noch mehr Input. Kannst du die LEDs auch auf > "dunkelgrau" setzen, also alle drei an, aber mit der geringstmöglichen > Helligkeit? Und dann auf ein etwas helleres "Grau"? Leider kann die Fernsteuerung die ich habe nur die festeingestellte Farben auf voller Helligkeit ansteuern also z.B. Rot, Gelb, Grün, Weiß ... Ich habe nochmal einen Plot gemacht, bei dem das Signal für "Gelb" aufgezeichnet ist.
Alexander K. schrieb: > Leider kann die Fernsteuerung die ich habe nur die festeingestellte > Farben auf voller Helligkeit ansteuern also z.B. Rot, Gelb, Grün, Weiß > ... > Ich habe nochmal einen Plot gemacht, bei dem das Signal für "Gelb" > aufgezeichnet ist. Die Sache war erstmal nützlich, denn sie hat geklärt, dass kein "stuffing" für das irreguläre vorletzte Bit eines Bytes verantwortlich ist. Für mich sieht das so aus, als wäre das Protokoll für Hardware mit unterschiedlichen Fähigkeiten ausgelegt. Die FB kann offensichtlich nur "an/aus" pro Farbe, steuert also wohl nur das höchstwertige Bit an. Damit wäre die Bitorder der Farbbytes klar: LSB->MSB. Das Kennzeichen, welche Bits zu verwenden sind, dürfte sein: Im "Farbbyte" kommen erstmal Einsen (die werden ignoriert), dann eine Null(wird auch ignoriert) und dann die Bits des tatsächliche Payloads, hier also nur genau eins pro Farbe. Wenn diese Vermutungen richtig sind, müßte man halt erstmal testweise das Low-Bit früher im Byte erscheinen lassen und die Bits dahinter variieren. Das Problem ist: das würde nur bei Empfänger-Hardware irgendwas bewirken, die tatsächlich in der Lage ist, Variationen jenseits von "an/aus" darzustellen. Hardware die das nicht kann, würde entweder das Kommando komplett ignorieren oder weiterhin nur das eine Bit wirklich auswerten. Es wäre aber auch schon interessant, diese beiden Fälle zu unterscheiden. Wenn nämlich trotz Verschiebung des "Startbits" nach vorn weiterhin das höchstwertige Bit korrekt für "an/aus" ausgewertet wird, wäre das praktisch der Nachweis, dass erstens das Protokoll korrekt verstanden wurde und zweitens, dass auch die Zielhardware nur "an/aus" kann, nicht nur die FB.
Ich habe inzwischen ein Testprogramm für einen Sender geschrieben und mir ist dabei aufgefallen, dass das letzte Byte wohl zur Fehlererkennung genutzt wird. Interessant dabei ist, dass eine Änderung dieser "Prüfsumme" nur auftritt, wenn sich der Inhalt der Daten ändert. Bei Telegrammen für die Farben Rot oder Grün, bei denen nur die Position eines einzelnen Bytes eine andere ist, bleibt die "Prüfsumme" dieselbe. Ein Telegramm enthält 6 Bytes mit folgender Zuordnung: Byte 1: Adresse -> Wert 0 ist Broadcast Byte 2: Rot Byte 3: Grün Byte 4: Blau Byte 5: Blink- und Blitzeffekte Byte 6: Fehlererkennung / Prüfsumme --> Gesucht Hier mal ein Paar Beispiele für Telegramme: Farbe Byte 1-5 Prüfsumme Byte 6 Rot: 0,253,0,0,255 Prüfsumme: 167 Grün: 0,0,253,0,255 Prüfsumme: 167 Blau: 0,0,0,253,255 Prüfsumme: 167 Weiß: 0,253,253,253,255 Prüfsumme: 167 Gelb: 0,253,253,0,255 Prüfsumme: 90 Lila: 0,253,0,253,255 Prüfsumme: 90 Cyan: 0,0,253,253,255 Prüfsumme: 90 Hellgrün: 0,130,253,0,255 Prüfsumme: 230 Blau Strobe: 0,0,0,253,12 Prüfsumme: 84 Blau Blinken: 0,0,0,253,4 Prüfsumme: 92 Leider konnte ich bisher aus diesen Daten keinen Weg finden, die Prüfsumme zu berechnen. Kann mir jemand einen Tipp geben, wie ich vorgehen kann?
:
Bearbeitet durch User
Alexander K. schrieb: > Leider konnte ich bisher aus diesen Daten keinen Weg finden, die > Prüfsumme zu berechnen. Kann mir jemand einen Tipp geben, wie ich > vorgehen kann? 165 XOR byte0 XOR byte1 ...
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.