IoT #8: Dekodierung eines Funk-Außensensors (1)

Ursprüngliches Vorhaben

Wie in folgendem Beitrag erwähnt, möchte ich mein IoT-System um die Messung von Innen- und Außentemperatur sowie der Luftfeuchte erweitern.

Den im verlinkten Beitrag genannten Sensor Bosch BME280 habe ich hier bereits herum liegen. Dieser kann übrigens zusätzlich auch den Luftdruck messen. Ursprünglich habe ich geplant, diesen Sensor für innen und außen zu verwenden.

Da der Mikrocontroller ESP8266 zu viel Energie benötigt, um ihn über Monate mit kleinen Batterien (2 – 4 x AA oder AAA) zu betreiben, musste eine andere Lösung her. Angedacht hatte ich einen Atmel ATtiny8x, der im Außenbereich mit Batterien betrieben wird und Sensordaten z. B. mittels 433 MHz an den im Innenraum befindlichen ESP8266 funkt. Dieser Mikrocontroller ist sehr sparsam. Für den Außensensor benötige ich dann jedoch ein spritzwassergeschütztes Gehäuse, eine Batteriehalterung etc.

Das Ganze wird dann relativ aufwändig und teuer, zumal zur Programmierung des Atmel-Mikrocontrollers eine entsprechende Programmier-Hardware nötig ist, die ich vermutlich kaum mehr verwenden werde. Ich habe zwar noch das Atmel STK500 von früher hier herum liegen, aber ob das alles noch kompatibel ist, weiß ich nicht. Da würde ich einen RS232-Adapter benötigen.😉

Planänderung: Verwendung von Consumer-Sensormodulen

Da liegt die Idee doch nahe, bestehende Funk-Sensoren zu verwenden. Hier gibt es einige, die ihre Daten mittels 433 MHz in die Gegend funken. Geeignete 433-MHz-Empfängermodule sind für Mikrocontroller ebenfalls erhältlich.

Die Verwendung bestehender Sensormodule hat einige Vorteile:

• Bewährte Technik (weniger Fehlerquellen)
• Spritzwassergeschütztes Gehäuse, z. B. IP44
• Kostengünstig (ab ca. 6 €)
• Ausgelegt für eine lange Batterielebensdauer über Monate oder Jahre
• Integriertes Display, was der Plausibilitätsprüfung dient

Der entscheidende Nachteil ist das fehlende Standard-Protokoll und verschiedene Modulationsarten. Jeder Hersteller und teils sogar verschiedene Modelle eines einzigen Herstellers, senden die Daten auf unterschiedliche Art. D. h. die Dekodierung des Signals wird eine Herausforderung. 🙂

Ich habe mir einfach mal einen Sensor für ca. 9 € gekauft und probiere, diesen einzubinden. Aufgebaut war das Ganze relativ schnell als Steckbrett- bzw. Breadboard-Lösung.

Dekodierung des Funk-Sensors

Ich habe einige Arduino-Bibliotheken zur Dekodierung probiert, doch keine konnte die Daten des Sensors dekodieren. Einen Hinweis habe ich auf GitHub und dem Projekt RTL_433 gefunden. Diese Software ist jedoch nicht für Mikrocontroller ausgelegt. Immerhin weiß ich nun, dass der Sensor 44 Bit sensen sollte und wie diese Daten zu interpretieren sind. Danke an dieser Stelle an die Entwickler! Der folgende Auszug stammt aus der verlinkten Website.

    0000 1111 | 0011 0000 | 0101 1100 | 1110 0111 | 0110 0001
    xxxx xxxx | cccc cccc | tttt tttt | tttt hhhh | hhhh ??nn

- x: ID // changes on battery switch
- c: Unknown Checksum (changes on every transmit if the other values are different)
- h: Humidity // BCD-encoded, each nibble is one digit
- t: Temperature   // in °F as binary number with one decimal place + 90 °F offset
- n: Channel // Channel number 1 - 3

Payload looks like this:
    [00] { 4} 00             : 0000
    [01] {40} 0f 30 5c e7 61 : 00001111 00110000 01011100 11100111 01100001

Vollständig sind diese Information übrigens nicht. Der Sensor liefert auch den Batteriestatus (gut/gering). Vermutlich an den oben mit „??“ markierten Stellen. Die Nutzdaten (Payload) senden zu Beginn nicht unbedingt „0000“, sondern einfach 4 konstante Werte. Diese können zwar als 0 interpretiert werden, doch meiner Meinung nach ist dies nicht korrekt. Doch dazu im Folgenden mehr.

Modulationsart

Aufzeichnung aller High- und Low-Signale

Im ersten Schritt habe ich einfach am Mikrocontroller mit geloggt, was der 433-MHz-Empfänger empfängt. Die entsprechenden High- und Low-Zeiten sind in folgendem Diagramm dargestellt. Das sieht relativ unstrukturiert aus.

Gut erkennbar ist jedoch, dass die High-Time im Vergleich zur Low-Time relativ konstant ist. Es sieht so aus, als fungiert die High-Time als Trigger und die darauf folgende Dauer des Low-Signals entspricht einer binären 0 bzw. 1. Es könnte sich um die Puls-Pausen-Modulation bzw. Pulse Position Modulation (PPM) handeln, wenn ich das richtig sehe.

Aufzeichnung der Low-Signale

Also kurzerhand die Software umgeschrieben und nur die Low-Signale geloggt, die auf entsprechende High-Signale mit einer Dauer von ca. 500 µs folgen. Das Ergebnis schaut vielversprechend aus und ist in folgendem Diagramm dargestellt. Hier ist eine gewisse Struktur erkennbar:

Die Pulse über 6000 µs sehen nach Triggern aus, die Pulse um die 2000 µs könnten eine binäre 0 darstellen, die Pulse um 4000 µs eine binäre 1. Die Pulse mit einer Dauer von 1000 µs sind somit die oben genannten „0000“ der Nutzdaten. Hier sieht man schön, dass das nicht unbedingt Low-Signale darstellt, da die Dauer in einem separaten Bereich liegt. Mal empfängt das System jedoch 4 Signale, mal 5 Signale. Die oben erwähnten weiteren 40 Bit konnte ich selten messen. Häufig waren das nur 36 bis 38 Bit.

Ungültige Daten / Hohes Rauschen

Ich bin dann 3 Tage lang schier verzweifelt und habe zig Möglichkeiten probiert, per Software die Signale zu filtern. Als meine Frau dann laufend meinte „Du hast’s nicht drauf“, war der Kampfgeist geweckt!

Also einen Schritt zurück und die Hardware prüfen. Hier stellte ich ein hohes Grundrauschen fest. Das war sicherlich mit ein Problem. Ich war mir nur nicht sicher, ob das am günstigen Empfänger liegt oder andere Gründe hat.
Aus der Messtechnik ist bekannt, dass die Spannungsversorgung und eine entsprechend gute Masse das A und O sind. Den 433-MHz-Empfänger habe ich bisher über die 5 V versorgt, die per USB geliefert werden – und das war das Problem! Der 3,3-Volt-Spannungsregler des Mikrocontroller-Boards arbeitet sehr sauber. Nun betreibe ich den Empfänger mit 3,3 V und erhalte super Signale! 😊 Dies zeigt folgendes Diagramm. Im linken Bereich ist das Grundrauschen zu sehen. Die kleinen Ausschläge am linken Rand können kritisch sein und die Sensordaten verfälschen. Die hohen Ausschläge sind unkritisch, denn die Sensorsignale im rechten Bereich heben sich davon deutlich ab.

Das Ergebnis! Ziel erreicht!

Das Ergebnis ist im folgenden Diagramm dargestellt. Mit der Software lassen sich die wenigen Daten herausfiltern, die unplausible Ergebnisse liefern. 😊

Im Folgenden ein kleiner Auszug aus meiner Debug-Konsole der Android IDE. Der Sensor zeigt eine Temperatur von 22,1°C an und eine Luftfeuchte von 39 %.

Sensor Channel:       3
Humidity:            39   %
Temperature:         22,1 °C
Payload 40 Bits: 0101001110101000011001010010001110010011

Im nächsten Schritt wird das ans IoT-System angebunden und der genannte Sensor für den Innenraum integriert.