Autor Thema: Dekodierung eines unbekannten FM bzw. FSK9600 Signals  (Gelesen 571 mal)

Offline Sven77

  • Jr. Member
  • **
  • Beiträge: 78
Dekodierung eines unbekannten FM bzw. FSK9600 Signals
« am: 29 November 2017, 16:50:26 »
Hallo in die Runde,

ich weiß gar nicht, ob ich hier richtig bin - muss aber irgendwo mal einen Anfang machen!
Ich würde gern den Temperatursensor meiner Abbrandsteuerung in meine Hausautomation einbinden. Zum einen als kleines Gimmick, zum anderen als weiteres Spielprojekt bzw. Machbarkeitsstudie und last but not least um bei brennendem Grundofen die Fussbodenheizung auszuschalten bzw. sehr weit herunter zu fahren.

Eins vorweg - dank vieler guter Tipps habe ich das Signal inzwischen entschlüsselt. Die kurze Zusammenfassung hier:

Man nehme einen RTL2838 DVB-T Stick, dazu eine SDR Software und sucht sich stückweise alles zusammen.
Entweder scannt man die üblichen Frequenzen, sucht nach einem Typenschild oder fragt (wie ich es getan habe) den Hersteller. Somit hatte ich zumindest die grobe Info "433 MHz".
Damals in einem ersten Versuch hatte ich SDR# benutzt und (irgend)ein Signal gesehen, s. Anhang "SDR_25dB Gain_Sequence.png".

Nun wollte ich in der kalten Jahreshälfte endlich mal wieder diesem Thema etwas Zeit opfern und bin ein gutes Stück weiter. In den diversen SDR-Programmen kann man die Modulation wählen und Mitschnitte als WAV speichern, um diese in Audacity zu analysieren.
Mir sagte zwar bisher weder die Raw-Ausgabe noch die in GQRX angebotene Raw-IQ-Demodulation und auch AM nichts, den Vergleich sieht man im Anhang "GQRX_RAW-RawIQ-AM.png". Mit FM hatte ich mich nicht weiter beschäftigt, da hier offenbar nur Rauschen drin war.

Ich habe dann jedoch an den o.g. Kandidaten schonmal erkannt: es werden alle 100ms ein Signal mit ca. 10ms Länge gesendet.
Mit dieser Info habe ich nochmal in die FM-Modulation hineingezoomt und stellte fest: TADA - das Rauschen war nur in der Stille, immer wenn gesendet wurde kamen hier brauchbare High/Low-Pegel zutage - s. "GQRX_NarrowFM_10x_30dB.png".
Um diese zu sehen, musste ich auch erstmal kräftig verstärken, auf den ersten Blick sah es immer aus wie 10ms Stille...  ;)
(das Bild zeigt untereinander 2 verschiedene Nachrichten zu unterschiedlichen Zeiten)

Nun gab es die nächste Hürde: wer macht mir aus der Kurve ein Bitmuster?
Die ersten 3ms waren offenbar immer das Preamble aus Nullen und Einsen. Abzählen Ablesen der Zeit zeigte mir: 9600 Baud!
Nur wie bekomme ich daraus die Bitfolge, ohne diese vielen Schritte und das Ablesen von Hand am Ende?

Schritt 1 auf diesem Weg:
Mit "rtl_fm" aus der RTL-SDR Sammlung kann man fertig FM demodulierte 16-Bit Signed Integer ausgeben lassen - die Frequenz konnte ich inzwischen auf 433.216MHz eingrenzen und als Samplingrate empfiehlt sich ein Vielfaches der Baudrate, in meinem Fall reicht das 4-fache gut aus, etwas mehr schadet nicht kostet aber mehr CPU-Leistung und sehr viel mehr (anfangs dachte ich "viel hilft viel" und ließ mit 3.2MHz abtasten) bringt nur unnötiges Rauschen und verkleinert die Amplitude (warum auch immer):
rtl_fm -f 433216000 -s 76800
Schritt 2:
Diese Ausgabe könnte man nun mit SOX in eine WAV-Datei packen und wäre genauso weit wie vorher...
Ich fand ein Projekt "pydemod", was aber schon wieder viel zu tief in die Protokolle eingriff, weshalb es mir auch nicht weiter half.
Also habe ich erstmal ein kleines C-Programm geschrieben, was die Samples einliest und immer nach 4 Samples eine 0 oder 1 ausgibt.
Damit stellte ich schnell fest: es wird hier weder weiter Kodiert, noch mit Start/Stop/Parity gearbeitet und noch nicht einmal wie sonst üblich aus einer 1 ein Low-Pegel gemacht. Ganz simpel: 4 Samples >0 bedeuten eine logische 1 und 4 Samples <0 eine logische 0.

Schritt 3:
Ein paar Beispiele aufzeichnen und mit angezeigten Werten vergleichen...
Reine Fleißarbeit - Ergebnis: es werden 32s 01-Pärchen gesendet, danach die Hex-Folge 2D.D4.46.49.52.45 und dann variable Daten.
Schnell fällt auf, dass die letzten 4 Bytes dieser Folge der ASCII-Code für "FIRE" ist - wir dekodieren also das richtige!  :D
Dahinter folgt ein Byte für die aktuelle Verbrennungsstufe, ein Word für die Temperatur in °C, ein Byte für die abgelaufenen Stunden, eins für die Minuten, ein noch unbekanntes was bisher immer 0 ist und zuletzt 16-Bit Prüfsumme.
Auch diese war dank Online-CRC-Berechnung schnell entschlüsselt: es ist der sogenannte "CRC-CCITT (XModem)" Code.

Also noch schnell eine Prüfsummenprüfung mit ins Programm und den Programmabbruch nach erfolgreichem Dekodieren - schon kann ich mir die Ausgabe von rtl_fm in mein Programm pipen und erhalte eine auswertbare Anzeige:
rtl_fm -f 433216000 -s 76800 | ./hoxdemod

SOOOO....
Und an dieser Stelle weiß ich jetzt nicht mehr weiter!

Ein DVB-T-Stick samt RTL-SDR und selbstgebasteltem Demodulator erscheint mir ein wenig übertrieben, um ein einfaches FM-Signal mitzulesen!
Billige 433MHz Receiver können aber offenbar nur AM.
Ich habe noch 2 Stück CC1101, leider für 868MHz, aber grundlegend sollten diese ja auch für 433MHz nutzbar sein.

Aber wie gehe ich vor? Auch hier scheint alles schon sehr signalspezifisch hinterlegt zu sein.
Wie kann ich mit einem nanoCUL oder SIGNALduino einfach FM-Bitfolgen auslesen, um schrittweise zu probieren, ob die CC1101 das überhaupt empfangen können?
Oder sollte ich gleich das (inzwischen ja bekannte) Protokoll irgendwo einpflegen?

Ich hätte halt gern einen Arduino o.ä., der mir direkt einfach die zyklisch empfangbaren 14 Bytes zur Verfügung stellt, ohne mich um 76.8kHz Samples in 16-Bit Tiefe zu plagen.
Irgendwelche Ideen?
VG, Sven

Offline KölnSolar

  • Hero Member
  • *****
  • Beiträge: 2012
Antw:Dekodierung eines unbekannten FM bzw. FSK9600 Signals
« Antwort #1 am: 29 November 2017, 17:39:07 »
SDR kenne ich nicht wirklich, weshalb mir Deine Analysen auch nicht viel sagen. Aber AM/FM sind ja eigentlich analoge Modulationsverfahren. Bist Du Dir sicher, dass Du da nicht auf dem falschen Dampfer unterwegs bist ?
Zitat
High/Low-Pegel zutage
passt ja eigentlich auch nicht zu FM, sondern zu ASK oder doch FSK :-\
Wenn Du also etwas besser das Modulationsverfahren beschreibst, kann ich Dir vielleicht sagen, ob Du mit Sduino/CUL/CC1100 weitermachen kannst.

Grüße Markus

RPi3/2 Stretch-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-CUL868-FS20A4-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty-Boop-EchoDot

Offline Sven77

  • Jr. Member
  • **
  • Beiträge: 78
Antw:Dekodierung eines unbekannten FM bzw. FSK9600 Signals
« Antwort #2 am: 29 November 2017, 19:46:58 »
AM/FM sind ja eigentlich analoge Modulationsverfahren. [...]  passt ja eigentlich auch nicht zu FM, sondern zu ASK oder doch FSK :-\
Nun, genau da liegt ja eigentlich auch mein Problem:
Es gibt heutzutage mehr Bezeichnungen als ich an zwei Händen abzhählen kann...

ASK wäre ja sicher das Pendent zu AM, also dann eher FSK. Aber auch hier gibt es noch GFSK und sicher noch weitere... Oder ist es doch irgendein PSK? Ich selbst weiß es wirklich nicht - daher habe ich die Signalkurven oben mit abgebildet und hoffe, dass jemand etwas gutes darin erkennen kann...

Was mir auch unklar ist: wäre denn "jedes" FSK mit jedem kompatibel?
Ich habe irgendwo gelesen, dass JeeLink und CUL inkompatibel zueinander sind - ich verstehe aber nicht so recht, warum - wo doch beide eigentlich ganz flexibel einsetzbar sind?!  :-\ :-[
VG, Sven

Offline KölnSolar

  • Hero Member
  • *****
  • Beiträge: 2012
Antw:Dekodierung eines unbekannten FM bzw. FSK9600 Signals
« Antwort #3 am: 30 November 2017, 07:44:08 »
Zitat
Was mir auch unklar ist: wäre denn "jedes" FSK mit jedem kompatibel?
Wohl eher nicht. FSK ist ja nur ein Oberbegriff für Modulationsverfahren.

Zitat
Ich habe irgendwo gelesen, dass JeeLink und CUL inkompatibel zueinander sind - ich verstehe aber nicht so recht, warum - wo doch beide eigentlich ganz flexibel einsetzbar sind?!
Ich vermute, dass das eine zu pauschale Aussage ist. Ein Jeelink oder CUL bestehen ja aus Hard- u. Firmware u. die Inkompatibilität besteht vermutlich in der Firmware(bzgl. FSK)

Unterschiede der Hardware
CC1100(CUL, S'duino)
Zitat
2-FSK, 4-FSK, GFSK, and MSK supported as well as OOK and flexible ASK shaping
RFM12B(Jeelink)
Zitat
multi-channel FSK transceiver(modifiziert auch ASK/OOK)

Ein Beispiel für FSK ist Homematic. hier kannst Du ableiten, dass das Protokoll mit beiden Chips abbildbar ist. Weitere devices/Protokolle mit FSK: PCA301, Lacrosse, MAX!, ZWAVE, SWAP... Vielleicht helfen Dir diese Stichwörter als Suchbegriffe weiter.

Zitat
daher habe ich die Signalkurven oben mit abgebildet und hoffe, dass jemand etwas gutes darin erkennen kann...
Ich bemüh mich ja..verstehe es aber nicht. Da schwingt "etwas" um einen Nullpunkt. Was zur Hölle ist der Nullpunkt u. was die Amplituden  :-\ Die Schwing-Frequenz fix 433,21 MHz ? Oder doch variabel(FSK) ?

Ich bin halt kein Profi und kenne mich eher mit dem einfachen ASK/OOK aus  :-[


RPi3/2 Stretch-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-CUL868-FS20A4-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty-Boop-EchoDot

Offline Harst

  • New Member
  • *
  • Beiträge: 42
Antw:Dekodierung eines unbekannten FM bzw. FSK9600 Signals
« Antwort #4 am: 01 Dezember 2017, 01:44:34 »
Das sieht sehr nach FSK aus. Es sind zeitgleich Signale auf mehreren Frequenzen zu sehen. OOK, AM  oder ASK haben im unteren Fenster nur eine senkrechte Linie.

Horst

Offline Sven77

  • Jr. Member
  • **
  • Beiträge: 78
Antw:Dekodierung eines unbekannten FM bzw. FSK9600 Signals
« Antwort #5 am: 08 Dezember 2017, 08:10:05 »
Ich habe das Thema auch in einem anderen Thread aufgegriffen und dort eine weitere Erkenntnis gepostet:
https://forum.fhem.de/index.php/topic,35064.msg726694.html#msg726694

Das verwendete Startwort 0x2DD4 scheint beim RFM12(b) (also auch Jeelink?) Standard zu sein, ich versuche also mit diesen Infos weiter, das Signal mit culfw auszulesen.
Danke nochmal für alle Tipps an dieser Stelle!
VG, Sven