mikrocontroller.net

Forum: HF, Funk und Felder Manchester Signal dekodieren


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Alexander K. (alexander_43)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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)


Bewertung
-1 lesenswert
nicht 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:

Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
1 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht lesenswert
Wie heißt das Empfänger-IC?

von Dieter R. (dieter_r)


Bewertung
0 lesenswert
nicht 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:

Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht lesenswert
DMX over 433MHz?

von Alexander K. (alexander_43)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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:

Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
1 lesenswert
nicht 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 ...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.