433MHz Funksignale entschlüsseln und anwenden – Teil 2

  • 433MHz Funksignale entschlüsseln und anwenden – Teil 2


    Motivation
    Im ersten Teil hatten wir gesehen, wie Signale eingelesen, Datagramme erkannt und extrahiert werden und diese hernach über den Sender abgespielt werden um Aktoren zu betätigen. In diesem Teil soll es darum gehen, wie wir die Signale von Datagrammen einfacher Protokolle erkennen können. Als Proband dient uns das Funkthermometer TFA Dostmann 30.3199 mit der Modellnummer KW-9010. Bild 1 zeigt das Thermometer.



    Bild 1: 433 MHz Funkthermometer KW-9010



    Funktionen des Funkthermometers
    Das Thermometer besitzt die folgenden Funktionen:

    • Innentemperatur: -30°C-60°C
    • Anzeige: °C/F
    • Kanäle: 1..3
    • Außentemperaturfühler: steckbar; unbekannter Temperaturbereich

    Somit ist der grobe Rahmen der Information beschrieben, die wir in den Datagramm erwarten können, welche uns das Thermometer sendet.



    Signalaufnahme
    Die Signalaufnahme erfolgt wie gehabt, indem wir die vom Thermometer gesendeten Temperaturen in eine Datei speichern.

    Code
    sudo ~/HuboDemo/Transceiver/./Transceiver.out r temp.txt


    Dabei ist es ganz nützlich, daß das Thermometer auf seiner Rückseite einen Knopf besitzt, über den der Sendevorgang ausgelöst werden kann. Als etwas schwierig gestaltet sich der Umstand, daß die Temperatur das Raumes nie ganz konstant ist, weswegen wir nie 100%ig reproduzierbare Bedingungen vorfinden.


    Signale erkennen
    Tabelle 1 zeigt die für verschiedene Temperaturen aufgezeichneten Datagramme des Kanals 2 sowie die Differenzen der Pulsweiten der einzelnen Messungen untereinander. Dabei fallen die im Datagramm codierten Temperaturwerte ggf. leicht anders aus, als die im Tabellenkopf dargestellten (und vom Display abgelesenen) Werte.



    Tabelle 1: Datagramme verschiedener Temperaturen des Funkkanals 2 und berechnete Differenzen der Pulsweiten.


    Auch hier erkennt man sofort, daß das Datagramm sich der Pulsweiten 450µs, 1990µs, 4550µ und 9560µs bedient. Farbig hervorgehoben sind einige große Abweichungen der einzelnen Datagramme untereinander. Da jedes Datagramm einem anderen Temperaturwert entspricht, ist davon auszugehen, daß in diesen Teilen auch die Codierung der Temperatur zu suchen ist. Mehr dazu jedoch später.
    Wichtiger ist zunächst der Umstand, daß zwischen den „wohlbekannten“ absoluten Zeiten nur geringe Abweichungen (<=15µs) bestehen. D.h. die empfangenen Signale weisen keine Störungen auf.
    Extrahiert man nun die verschiedenen Zeiten und mißt ihnen eine Bedeutung zu, dann erlauben sich zwei grundsätzliche Interpretationen (siehe Tabellen 2).



    Tabellen 2: Zwei mögliche Interpretationen der Zeiten 1990µs und 4550µs.


    Die Zeit von 450µs ist vor jedem anderen Wert zu finden und definiert somit den Start eines logischen Bits. Der Wert von 9560µs definiert das Ende eines Datagramms. Welche der beiden Zeiten von 1990µs und 4550µs nun eine logische „0“ oder „1“ definiert, wissen wir an dieser Stelle noch nicht. Dies wird sich später beim Versuch der Dekodierung des Signals zeigen (eine der beiden Kodierungen führt zu keinem vernünftigen Ergebnis) und ist lediglich eine Fleißarbeit, auf die wir hier nicht weiter eingehen. In der Folge nehmen wir an, daß die größere Zahl (also 4550µs) die „1“ definiert und die kleinere die „0“.



    Daten interpretieren – oder - „Kaffeesatzlesen wie Sherlock Holmes“
    Jetzt beginnt der interessante Teil, nämlich derjenige der Interpretation der Daten des Datagramms. Diese Aufgabe ist eine Fleißarbeit, bei der auch eine gewisse Erfahrung mit Protokollen im allgemeinen nicht schadet. Tabelle 3 zeigt die für verschiedene Temperaturen, Funkkanäle usw. aufgezeichneten Datagramme.



    Tabelle3: Datagramme mit verschiedenen Parametern wie Funkkanal, Temperatur, gezogenem oder gestecktem externen Sensor usw..


    Bevor wir uns an die eigentliche Arbeit der Kaffeesatzleserei machen, gruppieren wir die Bits in Nibble. Das kann dabei helfen, Anfänge oder Enden logischer Kodierungen zu finden. Zwar lieben es viele Hardwareentwickler, Informationen wüst über Byte- und Nibblegrenzen hinweg zu verteilen, jedoch markieren solche Grenzen in Protokollen häufig den Beginn oder das Ende logischer Einheiten. Auch BCD-Kodierungen sind leicht in Nibblen auszumachen.


    Am einfachsten beginnt man damit, diejenigen Parameter zu ändern, die sich eindeutig reproduzieren lassen. Im Falle des Thermometers ist das nicht die Temperatur, sondern z.B. der Funkkanal. Wir versuchen die Temperatur so konstant wie möglich zu halten, wechseln den Funkkanal und suchen nach Veränderlichen. Zeile 31 definiert das LSB, Zeile 30 das MSB der Kanäle 1..3.
    Die nächste reproduzierbare Stelle stellt ein gesteckter oder abgezogener externer Temperatursensor dar. Wiederum versuchen wir mittels einiger Datagramme bei denen der Sensor nicht gesteckt ist (Spalten E-AA) und anderer, bei denen er gesteckt ist (Spalten AC-AG), einen Unterschied zu finden. Wie man nun erkennt, scheint die Information in gleich 3 Zeilen mehrfach vorzuliegen (lila gefärbte Zeilen 10, 17 und 32). Hieraus erlauben sich mehrere Schlußfolgerungen:
    a.) Die Beobachtung ist noch nicht hinreichend erhärtet und bedarf weiterer Tests.
    b.) Die Information liegt tatsächlich mehrfach (einmal dabei in invertierter Form) vor oder
    c.) das Protokoll wird ggf. von anderen Sensoren gesprochen, wobei diesen Zeilen dann eine andere Bedeutung zukommt, für diesen Sensor jedoch gleich ausfällt.


    Als wichtigste Information fehlt nun die eigentliche Temperatur. Hier hilft es, dabei zunächst nahe beieinander liegende Temperaturen zu untersuchen. Mit einem Satz „genügend nahe beieinanderliegender Temperaturen“ und etwas Glück gelingt es, den „LSB“-Teil der Temperaturcodierung ausfindig zu machen. Natürlich kann man dabei auch auf die Nase fallen, wenn eine ganze Reihe gesetzter Bits auf einmal zur nächstgrößeren Zahl kippt. Im vorliegenden Fall sind die Temperaturen in 1/10°C kodiert. Die Zeilen 20-29 zeigen die jeweiligen Kodierungen. Das LSB befindet sich dabei in Zeile 29. Das per Messung höchste ermittelte Bit befindet sich in Zeile 21 und „kratzt“ das Nibble 4 an. Mit diesem Wissen und dem Wissen, daß das Thermometer bis 60°C mißt, kann geschlußfolgert werden, daß mindestens Zeile 20 auch noch einen Temperaturwert kodiert.


    Betrachten wir das Datagramm der Spalte AA, für das die Einheit Fahrenheit gewählt wurde, so fällt auf, daß das Thermometer weiterhin in seiner Grundeinheit °C sendet. Offenbar wirkt sich diese Einstellung des Thermometers lediglich auf die Anzeige des Displays aus, nicht jedoch auf den Temperaturwertebereich des Datagramms (gelber Bereich).



    Offene Punkte
    Ungeklärt ist u.a. die Frage der Kodierung negativer Temperaturen. Dies könnte gleichermaßen im Einerkomplement erfolgen, wie auch in Form eines eigens dafür „abgestellten“ Bits (z.B. Zeile 18). Berücksichtigt man, daß das Protokoll vermutlich auch von anderen Sensoren (mit höherem Temperaturbereich) gesprochen wird, so wäre es gut möglich, daß die beiden Bits der Zeilen 18 und 19 durchaus noch der Temperaturkodierung zuzusprechen wären. Weitere Versuche mit Temperaturen > =102,4°C bzw. <0°C würden dies erhärten oder widerlegen.
    Gänzlich unerforscht ist Nibble 1 und der größte Teil des Nibble 2. Das das Thermometer eine Art Checksumme berechnet ist gut möglich, diese jedoch am Anfang eines Datagramms zu finden, eher unüblich.


    Viel Spaß beim Grübeln wünscht...


    schnasseldag

  • Man kann sich die Sache auch etwas einfacher machen, denn andere haben schon aehnliche Geraete analysiert.


    Hier zum Beispiel ein (wahrscheinlich) aehnliches Geraet von TFA: https://github.com/merbanan/rt…s/tfa_twin_plus_30.3049.c


    Falls es ein gebraeuchliches Protokoll ist, dann kann es rtl_433 wahrscheinlich erkennen und benennen. Anhand des Namens findet man dann das entsprechende File in diesem Repository.


    Das habe ich zum Beispiel mit einem billigen Sensor von pearl so gemacht. rtl_433 hat das Protokoll als prologue erkannt und in prologue.c fand ich eine sehr gute Beschreibung dazu.


    Hat mir ein paar Stunden gruebeln erspart :thumbs1:

  • Tell: Mir ging es in diesem Beitrag weniger um das Protokoll des Temperatursensors als solches, sondern vielmehr darum, einige Gedankenanstöße zu liefern, wie man mit Geräten unbekannten Protokolls verfahren kann. Befaßt man sich mit der Materie auf dieser Ebene, so kommt man an so vielen Fragen und Stolpersteinen vorbei, daß man ähnlich geartete Probleme in seinen Projekten erkennt und sich zu helfen weis. Der Einsatz fertiger Software zur Analyse kann bei unbekannten Protokollen nicht helfen und führt dann oft zu Fragen wie: "Bei mir geht's nicht - kann mir jemand helfen?". Das Forum ist voll davon...