Beschreibung DHT22/AM2302 Temperatur-/Feuchtelogger mit BASCOM.

[Searcher]

Mich hatte interessiert, wie schnell eine Raumtemperatur nach Abdrehen der Heizung absinkt. Dafür gibt es fertige Temperaturlogger zu kaufen aber, dachte ich, so ein Ding ist doch schnell selbst gebastelt. Als Sensor fand ich den DHT22 auf "Breakout mit Pullup und Abblock C" als AM2302 benannt und begann zu werkeln.

Auf dem Breadboard schnell zusammengsteckt werkelt nun ein Bascom Program auf ATtiny25 mit dem DHT22, der im AM2302 Modul schon mit einem 5,1k Pullup Widerstand auf der Datenletung versehen ist. Einzige Funktion: Temperatur und rel. Luftfeuchte vom DHT22 in Intervallen aufzeichnen und später über RS232 an PC ausgeben; ohne Uhrzeit oä.

Zwei Tasten dazu und ein Schalter plus LED als Lebenszeichenanzeige. Über den Schalter wird der Logger mit 3,7V aus einer 10440 LiIon Zelle versorgt. Ein Taster startet den Meß- und Logvorgang. Der andere startet den Auslesevorgang der gepeicherten Daten, die über RS232 Softserial zu einem PC gesendet werden. Weitere Auswertung dann in zB Excel.

Eine Datenleitung vom DHT22, ein Starttaster, ein Auslesetaster, eine LED, ein RS232 Ausgang: alle 5 freien I/O vom ATtiny25 belegt.

Der DHT22 soll mit Vcc von 3,3 bis 5,5V arbeiten. Dem ATtiny25 reichen die Spannungen auch und somit ist die 3,7V Zelle (aufgeladen sind es fast 4,2V) bei einem Stromverbrauch der Schaltung von etwa 6µA (gemessen! wirklich so wenig?) im Sleep locker ausreichend. Aufgeweckt wird der ATtiny alle ca. 8 Sekunden über Watchdog und checkt über eine Zählvariable, ob eine Messung durchgeführt werden soll. Das Meßintervall ist zur Zeit auf 1/2 Stunde eingestellt. Falls keine Messung -> sofort wieder in den Sleep, sonst schnell den DHT22 abgefragt, Daten in den EEPROM gespeichert und dann wieder in den Sleep.

Die Daten vom DHT22 bestehen aus 2 Byte Temperaturwert, 2 Byte relativen Feuchtigkeitsprozenten und einem Byte Checksumme. Die 4 Nutzbytes pro Messung werden im EEPROM abgelegt. Macht bei 128 Byte EEPROM rund 30 Messungen und noch ein Byte für Anzahl abgelegter Messungen. Keine Ahnung ob man EEPROM Speicherplatz $00 noch freilassen muß, da sie unter bestimten Umständen korrumpiert werden könnte. Und schon ist der EEPROM voll. 30 Messungen jede halbe Stunde -> Zeitraum von ca. 15 Stunden. Nutzt man nur den Temperaturwert wird der Zeitraum länger.

Auch der Programmspeicher mit 2k ist nicht besonders üppig, reicht für meinen Zweck aber noch ganz gut aus. Aufgehalten bei der Programmierung hat mich das 1-wire Hardware Protokoll des DHT22 und das ökonomische Aufsammeln und Speichern/Abrufen der Daten.

Als Anforderung der Daten muß der µC über den Output Portpin die Datenleitung, die über einen Pullup auf high liegt, für ein paar ms auf low ziehen. Der Outputpin muß dann auf Input umkonfiguriert werden und auf Antwort vom DHT22 gewartet werden. Die Antwort und die folgenden Pegelwechsel finden in einem festgelegten Zeitraster statt (siehe Datenblatt). Schaltet man auf Input um und startet man die Überwachung der DHT22 Antwort zu früh, kann es wie bei mir zu einer Fehlinterpretation des Zustandes der Datenleitung kommen, die mir schon eine Weile Kopfzerbrechen gekostet hat.

Da die Pegelzeiten vom DHT22 Toleranzen unterliegen wird jedesmal auf einen Pegelwechsel gewartet und dann die verflossene Zeit seit dem letzten Pegelwechsel genommen. Ein Timer überwacht die zulässige Zeit und verhindert durch Interrupt ein "Aufhängen" des Programms durch einen Sensorfehler. Vielleicht versuche ich nochmal eine Pegelpollingvariante anstelle der Pegelwartevariante. Die Pegellevelzeiten bewegen sich von ca. 20µs bis ca. 100µs.

Zum Aufsammeln der 40 einzelnen Bits der Daten vom DHT22 hat sich bei mir eine overlay Variable vom Datentyp Double (64 Bit Variable) als praktisch erwiesen. Die einzelnen Bits einer Variablen lassen sich in Bascom recht einfach adressieren.

Dazu sind nacheinander folgende Variablen declariert (Reihenfolge ist wichtig):
DIM rx_chksum as byte
DIM tmp as integer
DIM rh as integer
DIM bit_stream as double at rx_chksum overlay

Man kann dann die einlaufenden 40 Datenbits in einer Laufschleife mit Variable zB "bit_counter" zählen und die "bit_position" in "bit_stream" mit "39 minus bit_counter" ausrechnen.
Erstes bit: bit_counter = 0, bit_position = 39 - 0 (ergibt 39). Ersten übertragenen Bitwert in "bit_stream.bit_position" speichern. Zweiter Bitwert kommt nach bit_position 38 da bit_counter nun auf 1 steht. (Adressierung der 40 Datenbits in Bitstream geht von 0 bis 39)

Durch die Deklarierung als Overlay stehen nun die Werte in den Variablen für rx_chksum, tmp und rh schon richtig drin. Kleine Sonderbehandlung für tmp notwendig, da ein Temperaturwert unter Null Grad nicht als Integer übertragen wird sondern als 16-Bit Wert mit MSB auf 1. Also 1000_0000_0000_0100 bedeuten Minus 4 Grad da das MSB eine 1 ist. Eine 0000_0000_0000_0100 sind dagegen Plus 4 Grad.

Ein weiteres Overlay "DIM messung(4) as byte at tmp overlay" erleichtert zusammen mit "DIM eram_messwerte(121) as eram byte" das Abspeichern im EEPROM.


Gruß
Searcher

[Manf]

Sehr schönes Projekt, wirklich.
Ich gehe auch manchmal solchen Fragestellungen nach, im Einzelfall, wenn man es nur einmal braucht, kommt man dabei auf Ideen wie die Aufnahme des Thermometers mit einer Digtalkamera.
Die Auswertung der aufgenommenen Daten ist dabei natürlich etwas aufwendiger und die Information pro Datenmenge ist geradezu erschreckend gering.
Die Technik liefert andererseits extrem große preiswerte Speicher.
Bei der Controllerlösung lernt man natürlich mehr, am besten denkt man auch nicht zuviel drüber nach.