Forum: HF, Funk und Felder Manchester Signal dekodieren


von Alexander K. (alexander_43)


Angehängte Dateien:

Lesenswert?

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!

von Knicker (Gast)


Lesenswert?

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.

von Alexander K. (alexander_43)


Angehängte Dateien:

Lesenswert?

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?

von Günter Lenz (Gast)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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.

von Entdecker (Gast)


Lesenswert?

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.

von Qwertz (Gast)


Lesenswert?

Wie heißt das Empfänger-IC?

von Dieter R. (dieter_r)


Lesenswert?

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.

von Alexander K. (alexander_43)


Angehängte Dateien:

Lesenswert?

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
von Dieter R. (dieter_r)


Lesenswert?

DMX over 433MHz?

von Alexander K. (alexander_43)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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.

von Alexander K. (alexander_43)


Angehängte Dateien:

Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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.

von Alexander K. (alexander_43)


Lesenswert?

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
von K. S. (the_yrr)


Lesenswert?

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
Noch kein Account? Hier anmelden.