LoRaTHERM APRS-Temperatursensor mit ESP32

[DG0MG]

Sie dürfen in diesem Board keine Dateianhänge sehen.

Wir hatte ja hier schon Eigenbau-Lösungen, die Strahlungsmesswerte ins über LoraWAN + TheThingsNetwork ins Internet schicken:

• Der Multigeiger
• @Xodor s Lösung: https://www.geigerzaehlerforum.de/index.php/topic,1365.0.html

Eigentlich hat mir das auch immer sehr gefallen: Einen batteriebetriebenen Sensor irgendwo an einen Ort ohne Infrastruktur stellen, das Ding sendet immermal und "irgendwie" finden die Messwerte ins Internet, wo man sie von überall aus anschauen kann. Ich hatte mich nun mal näher damit beschäftigt und geschaut, wo ich denn in der Nähe ein Gateway habe, das die Aussendungen meines Sensors empfangen könnte. Nun, da ist nicht viel. Gera:ja, Chmenitz:ja, aber Zwickau: ein einzelnes GW. Und ich kann mir nicht vorstellen, das ich das ohne größeren Antennen- oder Sendeleistungsaufwand erreichen würde. Die TTN-Freaks sagen jetzt natürlich: "Selber ein GW betreiben!". Nee, will ich nicht. Und so blieb das erstmal weiterhin nur ein Gedanke.

Nun gibts ja im Amateurfunk eine Spielart namens APRS, ein Datenübermittlungsverfahren vornehmlich für Standorte in Form von GPS-Koordinaten aber auch für Wetterstationen und Telemetriemesswerte. Ursprünglich erfolgte das über 1200-Baud-AFSK-Aussendungen in FM auf dem 2-Meter- oder 70cm-Band. Aber es gibt auch eine LoRA-Frequenz und um mich herum betreiben einige OMs solche LoRa-APRS-Gateways. Also Empfänger, die LoRa-Assendungen im 70cm-Band empfangen, dekodieren und ins Internet weiterleiten. Dazu braucht es btw. noch nicht einmal eine Lizenz, da ein solches GW möglichst nicht sendet.

Der im Amateurfunk verbreitete Anwendungszweck ist, im Auto, im Rucksack, am Fahrrad sog. "Tracker" mitzuführen, batteriebetriebene LoRa/GPS-Module, die gelegentlich die eigene Position aussenden. Die LoRa-Gateways empfangen die Daten und in einer Karte kann man sehen, wo der jeweilige Funkamateur gerade ist. Datenschutzmäßig ein Graus, aber die machen das freiwillig und sehen dann, wie weit ihr eigener Tracker gesendet hat, bzw. wo sein Signal empfangen wurde. Das zur Erklärung, warum diese Infrastruktur schon vorhanden ist.

Da die Möglichkeit für mich als Funkamateur vorhanden ist, wollte ich mal in diese Richtung rumprobieren. Mit einem ESP32-basierten TTGO-LILYGO hatte ich schon Erfahrung und so war die Hardwareauswahl nicht schwer:

Sie dürfen in diesem Board keine Dateianhänge sehen.

Allerdings eben für 433 MHz, nicht wie auf dem Bild für 868 MHz, es gibt verschiedene Modelle des Boards.

Und was misst man, wenn man nur erstmal probieren will? Die Temperatur!

Ich hab mich als Sensor für den DALLAS DS18B20 entschieden, der braucht keine komplizierte Verdrahtung zum Prozessor, auch ein Kalibrieren ist nicht nötig, die Daten werden bereits digital angeliefert:

Sie dürfen in diesem Board keine Dateianhänge sehen.

Fehlt noch die Software für den ESP32. Es gibt bereits Software für o.g. Tracker, die zusätzlich zum GPS-Signal auch einen DS18B20, einen BME280 oder einen DHT22 auslesen kann. Das läuft dann unter dem Label "kleine Wetterstation". Ich habe die ältere, rudimentäre Software von OE3CJB als Grundlage genommen:

• https://github.com/oe3cjb/TTGO-T-Beam-LoRa-APRS/blob/master/src/TTGO_T-Beam_LoRa_APRS.ino

Diese (und auch alle anderen, die ich gefunden habe) sind aber alle so geschrieben, dass der Prozessor quasi "immer an" ist. Er verbraucht also dauerhaft ~100mA. Über den genauen Wert braucht man nicht streiten, für längeren Batteriebetrieb ist das in jedem Fall absolut nicht geeignet. Die Software muss also die Stromsparfähigkeiten des ESP32 nutzen, hauptsächlich den sog. DEEPSLEEP, in dem der Prozessor nur noch einige Microampere verbraucht.

Die Software wurde so umgeschrieben, dass sie nach einem RESET des Prozessors die Hardware inititalisiert, Debug-Ausgaben auf dem Display und der seriellen Schnittstelle macht, eine Temperaturmessung vornimmt, diese in einem gültigen LoRa-APRS-Frame aussendet, alle Hardware (Funkmodul, Display) abschaltet und den Prozessor wieder in den Tiefschlaf schickt. Aus diesem wacht er nach einer vorbestimmten Zeit wieder auf nd das Spiel beginnt von neuem. Es gibt keine Uhr, die Zeit wird durch einen RC-Oscillator bestimmt, ist also nicht hochgenau.
Über den DEEPSLEEP hinweg werden keine Variablen gespeichert, der Prozessor merkt sich auch seinen ProgramCounter nicht, fängt also jedesmal wie nach einem Kaltstart an. Die einzige Variable, die nicht zwischendrin "verloren" geht, ist der Aufwach-Zähler, der mit jeder Aussendung eins höher zählt. Diese Variable liegt in einem speziellen Bereich des statischen RAMs, der über den DeepSleep erhalten bleibt. Aus diesem Zähler werden verschiedene Handlungsweisen der Software abgeleitet.

Die Hardware ist ganz einfach: Der DS18B20 hat 3 Beine: Betriebsspannung (Vdd), Datenpin (DQ) und GND.

// Temperatursensor
// =================
//    ________
//   /        \   Sensor: DS18B20 
//  | -- -- -- |  Blick von unten auf die Beine
//  +----------+  Datenblatt: https://www.analog.com/media/en/technical-documentation/data-sheets/ds18b20.pdf
//    Vdd DQ GND
//

GND kommt an GND des TTGO
Vdd kommt an +3,3V des TTGO
DQ kommt an IO-Pin 4 des TTGO
Zusätzlich kommt zwischen Vdd und DQ (oder +3,3V und IO4) ein Widerstand 4,7kOhm.
Wenn der Sensor nicht gerade misst, beträgt sein Ruhestrom wenige µA. Es soll wohl Fake-Chips geben, die dann stattdessen mA ziehen. Ich hab meine DS18B20 bei Reichelt gekauft, die waren in Ordnung.

Die Stromversorgung erfolgt aus zwei parallelgeschaltenen 18650er Li-Ion-Akkus.
Die Antenne ist ein Dipol aus vernickeltem Federstahl. Durch das Stück Platinenmaterial in der Dose kann man mit dem Lötkolben die Schenkellängen abstimmen.

Sie dürfen in diesem Board keine Dateianhänge sehen. Sie dürfen in diesem Board keine Dateianhänge sehen.

diese Baugruppe war - so wie auf dem Bild zu sehen, vom 10.8.2024 bis zum 17.5.2025 (280 Tage!) am Zaun eines Wasserhochbehälters befestigt, an dem ich jeden Tag auf dem Weg zum QRL zweimal vorbeifahre. Ich hatte also auch eine optische Kontrolle 

Die Aussendung erfolgte alle 10 Minuten und war etwa 2,5 Sekunden lang. Die von verschiedenen Gateways empfangenen Pakete werden zur Webseite aprs.fi geschickt, wo man die Telemetriedaten auch anschauen kann:

• https://aprs.fi/telemetry/a/DG0MG-11?range=week

Eine Übersicht des Monats sieht so aus:

Sie dürfen in diesem Board keine Dateianhänge sehen.

und so eine Jahreskurve:

Sie dürfen in diesem Board keine Dateianhänge sehen.