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 76800Schritt 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!
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 | ./hoxdemodSOOOO....
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?
