LoRa_WX

NEU: Jetzt auch mit neuen Funktionen

Vereinzelt wurde der Wunsch laut, ausgewertete Daten auch auf einem größeren, als dem auf dem Prozessorboard integrierten 0.96"-OLED-Board darstellen zu können. Dazu ist weiter unten etwas zu lesen. Ansonsten gibt es aber auch noch eine andere Lösung. So erlauben die verwendeten ESP32-Prozessoren schon von Haus aus auch eine Bluetooth-Funktionalität. Ermittelte Wetterdaten lassen sich dadurch drahtlos ( bei einer Reichweite von bis zu etwa 20m ) auch an Smartphones/Tablets übertragen. Abb.5 am Ende dieser Seite gibt es ein Beispiel für auf diese Weise übertragene und mit einem herkömmlichen Terminalprogramm ausgewertete Daten. Dabei erlaubt die von mir benutzte ( Android- ) APP von Kai Morich [6] vielfältige Darstellungvariationen, wie z.B auch nahezu bildfüllende Zeichen. Die erwähnte Bluetooth-Funktionalität wurde bereits in die unter Link [2] herunterladbaren Firmwarefunktionen intergriert.

YouTube Zu diesem Projekt auch ein Video von Manuel Lausmann : https://www.youtube.com/watch?v=akgEdKHjBhw

Angeregt durch einen Forumsbeitrag begann ich, neben einem Projekt zur LoRa-Aussendung von APRS-Positionsdaten, auch noch eine Version für APRS-Wetterdaten zu erstellen. Für den Anfang sollten dabei erst einmal nur die Daten der BOSCH-Sensoren des Typs BME280 zur Aussendung kommen. Über ihre I2C-Schnittstelle stellen diese Bausteine auf einfache Weise sowohl Werte von Temperatur, Luftfeuchte, Höhe und Luftdruck zur Verfügung: Die Genauigkeit der Werte entspricht dabei mittleren Anforderungen ( was immer das auch bedeutet ! ).

Abb.1 Komplette LoRa-APRS-Sendeeinheit für Wetterdaten
hier mit ESP32, OLED, LoRa-Board von TTGO und ( nicht sichtbar ) BME280-Sensor

Zur weiteren Datenaufbereitung und LoRa-Verabeitung galt es nun noch geeignete Prozessorboards zu finden. Bei der Suche nach hierfür geeigneten Lösungen stiess ich auf kleine Boards der Firmen HELTEC bzw. baugleich von ICQUANZX u.a., die bereits sowohl einen ESP32-Prozessor, ein OLED-SW-Display ( 128x64 Pixel ), als auch einen LoRa-Transceiverbaustein beinhalten. Ähnliche, durch ihre Ausstattung mit einer SMA-Antennenbuchse erkennbare Boards gibt es auch mit der Bezeichnung: TTGO LoRa32 (Abb.1) .

Bei allen Versionen ist zu beachten, dass sie Üblicherweise sowohl für einen Frequenzbereich um 433 MHz, als auch für einen solchen um 868 MHz angeboten werden. Nachdem es sich bei letztgenanntem Bereich um kein Amateurfunkband handelt, kommen für LoRa-APRS-Anwendungen in der Regel nur die 433 MHz-Versionen infage.

Der USB-Anschluss der Bausteine dient u.a. ihrer Spannungsversorgung mit 5V. Alternativ können aber auch 3.7V-LiPo-Akkus benutzt werden, wofür eine integrierte Ladeelektronik vorhanden ist. Zum Lieferumfang gehören zudem kleine Wendelantennen für den 433MHz-Bereich.

Anschaltung der BME280-Boards

Der Nachbau gestaltet sich sehr einfach. Hardwaremäßig müssen lediglich das Prozessorboard und der BME280-Baustein miteinander verbunden werden. Dabei sind neben der Masse- und der Versorgungsspannung lediglich noch die beiden Verbindungen zur I2C-Steuerung herzustellen ( benötigte Pull-Ups befinden sich bereits auf dem BME280-Board und werden somit nicht noch extern benötigt ). Die beiden oben genannten Familien von Prozessorbausteinen erfordern die Nutzung unterschiedlicher Portanschlüsse:

ESP32-BORD mit LoRa und OLED	SDA	SCL
HELTEC LoRa32 / ICQUANZX LoRa 32	GPIO 4	GPIO 15
TTGO LoRa 32	GPIO 21	GPIO 22

Die I2C-Anschaltung der BME280-Bausteine entspricht einer Parallelschaltung zu den auf den Prozessorboards befindlichen OLED's.

Ein geeigneter Windsensor und seine Anschaltung

Mehrfach wurde ich gefragt, ob den via LoRa-APRS übertragenen Wetterdaten nicht auch solche eines Windsensors hinzugefügt werden könnten. Nach einiger Internetrecherche erwies sich das als unschwer machbar. Dabei half mir besonders ein YouTube-Video von Alex aus Graz [3]. Von ihm habe ich mir den Hinweis auf einen möglichen Windsensor [4] und auch einige passende ESP32-Subroutinen "ausgeborgt".
Der verwendete Windsensor ( Abb.1a ) ist relativ preiswert erhältlich und wird als Ersatzteil für eine industriell gefertigte Wetterstation geliefert. Einer Verwendung in rauher Umgebung dürfte er auf die Dauer allerdings kaum gewachsen sein. Für erste Versuche sollte er sich aber verwenden lassen.

Abb.1a Beispiel für Windsensor gem. [4]

In elektrischer Hinsicht ist seine Funktion äusserst einfach und beschränkt sich auf eine rotationsabhängige Unterbrechung der Verbindung zwischen seinen beiden Anschlussdrähten. Die Anschaltung erfolgt, indem an eine der beiden Adern die vom Prozessorboard bereitgestellte 3,3V-Spannung gelegt wird, während die zweite Ader mit dem als Schalteingang konfigurierten Port GPIO12 verbunden werden muss. Zusätzlich ist vom gleichen Punkt auch noch ein Widerstand von ca. 10 KOhm gegen Masse vorzusehen ( siehe dazu auch Abb.1b ).

Abb. 1b Zusammenschaltung der einzelnen Baugruppen des Wettertrackers

WICHTIG: Wer keinen Windsensor einsetzen möchte, der lässt die entsprechenden Anschlusspins einfach unbeschaltet.

Personalisierung des Quellcodes

Der Quellcode ( INO-File ) ist an einigen Stellen noch an die persönlichen Daten anzupassen. Beginnen wir mit dem auszusendenden Datenstring. Einschliesslich der APRS-Wetterdaten kann er etwa folgendermassen aussehen: "DJ7OO-12>APRS:!4957.60N/00812.00E_.../...s023t079h42b09970a00245_".
Die hierbei vom Anwender noch zu ändernden Daten finden sich in der ersten Hälfte:

DJ7OO-12>APRS:!4957.60N/00812.00E_

Das Absender-Call ( ggf. incl SSID ) und die fixen Positionsdaten sind durch Werte eigener Wahl zu ersetzen. Im Beispiel steht "4957.60N" für einen nördlichen Breitengrad im Format "GGMM.mm" zuzügl. N/S ( Hemispherenangabe ). "00812.00E" weist dagegen auf einen östlichen Längengrad im Format "GGGMM.mm" zuzügl. E/W hin.
Unverändert zu übenehmen ist der abschliessende Tiefstrich. Er ist für die Kennzeichung der Aussendungen als APRS-Wetterdatenmessages und Darstellung des WX-Icons zuständig.

WICHTIG:
Falls die Positionsdaten nur als Gradangabe mit mehreren Nachkommastellen vorliegen, so ist zuerst noch eine Umrechnung in das Format: [G]GG.MM.mm erforderlich. Hilfreich kann es dabei ggf. sein, die für den eigenen Einsatzstandort benötigten Werte mithilfe von z.B. Google-Earth zu ermitteln. Hier kann auch eine Auswahl zwischen unterschiedlichen Formatdarstellungen getroffen werden. Dazu ist unter: Tools/ Optionen und 3D-Ansicht bei "Breite/Länge anzeigen/ die Einstellung "Grad, Dezimalminuten" zu wählen.

Bestimmung der Sendefrequenz

Die Festlegung der Sendefrequenz erfolgt im Quellcode mithilfe des Befehls: "lora_SetFreq" gefolgt von drei durch Kommata getrennten Dezimalwerten. Defaultmäßig wird damit die standardmäßig benutzte LoRa-APRS-Frequenz 433.775 MHz angewählt. Wer eine andere Frequenz nutzen möchte, der kann sich an dem folgenden Berechnungsbeispiel orientieren:

LoRa frequency calculation (sample for 434.4 MHz):
------------------------------------------------------------------------------
434400000/61.03515625 = 71172096
71172096 (DEC) = 6C 99 99 (HEX)
6C 99 99 (HEX) = 108 153 153 (DEC)

Die sich daraus zur Anwahl der Frequenz 434.400 MHz ergebende Befehlszeile lautet damit: "lora_SetFreq(108, 153, 153);"
während sie für 433.775 Mhz folgendermassen aussieht: "lora_SetFreq(108, 113, 153);

Bestimmung der Sendefolgen

Vorab noch einige Bemerkungen zu den Sendefolgen:
Unter LoRa führt die Aussendung von Wetterdaten mit ihren insgesamt ca. 60 Zeichen zu einer Kanalbelegung in der Größenordnung von etwa 4 Sekunden. Nachdem kurze Sendefolgen aber auch kaum zur besseren Erfassung von Wetterdatenänderungen beitragen, sollte man die zeitlichen Abstände zwischen den Aussendungen sinnvoll wählen und den verwendeten Kanal nur massvoll belegen. So hat sich an dieser Stelle z.B. eine Sendefolge von 30 Minuten als gängiger Wert erwiesen.
Um für Testzwecke aber ggf. zeitweise auch kürzere Zeitfolgen zu ermöglichen, enthält der Quellcode hierfür auch entsprechende Wertangaben. Nicht benutzte Codezeilen sind dabei jeweils auszuklammern.

calc = 1800; // 1800sec. = 30 Min.
// calc = 900; // 900sec. = 15 Min.
// calc = 600; // 600sec. = 10 Min.
// calc = 300; // 300sec. = 5 Min.
// calc = 60; // 60sec. = 1 Min.

Abb.2

Für den Zeitpunkt der Aussendungen geht das Display für einige Sekunden auf eine Anzeige gem. Abb.2. Zudem wird der Stand eines nach jeder Datenausgabe incrementierenden Zählers angezeigt.

Firmware-Download und seine Weiterverarbeitung

Die unter [2] bereitgestellten Firmwareversionen lassen sich zur Übertragbarkeit auch von Winddaten erweitern. Dabei werden sie sowohl in einer Version für die Boards "HELTEC LoRa32" und Baugleiche ( wie z.B. ICQUANZX ), als auch für solche mit TTGO-Bausteinen wie "TTGO LoRa32" bereitgestellt.
Zur Steuerung der LoRa-Bausteine ( Serie: RFM9x ) werden die altbewährten Libraries von Stuart Robinson, GW7HPW benutzt. Die dazu jeweils noch beigefügten Files: "LoRaTX.h" sind dabei in den gleichen Ordner zu kopieren, in dem auch die INO-Files abgelegt werden.

Hinweise zu ggf. erforderlich werdenden Frequenzumstellungen ( derzeit: 433.775 MHz ) sind im Quellcode zu finden.

Wer mit Arduino-Programmierung und der Weiterverarbeitung von Daten vertraut ist, der sollte mit dem Hochladen der Programmcodes keine Probleme haben. Ggf. sind allerdings vorher auch noch die benutzten ADAFRUIT-Includes im Library-Ordner der Arduino-IDE abzulegen.

Zum Kompilieren und Hochladen benutzte ich ansonsten eine neuere, auf ESP32-Nutzung erweiterte Version der ARDUINO-IDE. Während für HELTEC- und baugleiche Boards dabei unter "Werkzeuge" das Board "HELTEC WiFi LoRa 32 OLED" zu wählen ist, lautet der Name zur Anwahl der TTGO-Boards: "TTGO LoRa32-OLED V1".

Erste Betrieberfahrungen

Schon nach der ersten Inbetriebnahme erschienen die ausgesandten Wetterdaten auf der Seite von APRS-Fi. Dabei noch festgestellte kleinere Formatfehler wurden inzwischen beseitigt. Unter Verwendung der mit den Bausteinen gelieferten kurzen Antenne konnten die mit etwa 50mW-Sendeleistung ( +17dBm ) erfolgten Aussendungen bereits von einem Gateway in etwa 5 Km Distanz ( siehe Bild ) und auch von unserem Lora-Repeater "DL0OJ-14" in etwa 15 Km Entfernung empfangen und verarbeitet werden.

Abb.3 Beispiel für Wetterdatenempfang auf der Seite: APRS.fi
( hier noch Version ohne Winddaten )

Werden Winddaten in "m/s" dargestellt, so können sie durch Multiplikation mit dem Faktor 3.6 in "Km/h" umgerechnet werden.

Was noch aussteht, ist eine Kontrolle der Verarbeitung negativer Temperaturwerte. Danach könnten ggf. noch kleinere Änderungen im Quellcode erforderlich werden. Um diesen Test durchführen zu können, muss ich mir allerdings erst noch eine Dose Kältespray besorgen !

Mögliche Erweiterungen

Inzwischen gibt es zum Projekt auch noch einige weitere Ideen. So fragte ein OM an, ob neben den Daten des BME280 nicht auch noch weitere, über die Analogeingänge des Prozessors zugeführte Daten in die Ausgangssignale eingefügt werden könnten. Das ist natürlich denkbar, aber eine andere Sache reizt mich dezeit noch mehr: Nachdem das derzeitige Konzept nur für den Einsatz an Feststandorten vorgesehen ist, würde mich ansonsten noch interessieren, die fixen Positionsdaten durch solche eines GPS-Bausteins zu ersetzen, wodurch auch einen Einsatz bei z.B. Ballonmissionen infrage kommen würde. Hierbei denke ich auch an eine Nutzung separater Frequenzen z.B. im Rahmen von SRD-Allgemeingenehmigungen.

Abb.4 Verwendung einer BME280-Sendeeinheit ( TTGO-Version ) zur APRS-Aussendung von Wetterdaten
Eine hierfür eingerichtete M5Stack-Deodereinheit dient zur Signalkontrolle auf der LoRa-APRS-Frequenz

Abb.4 zeigt u.a. die speziell für den Empfang von Wetterdaten eingerichtete Version meines mit einem M5Stack realisierten und in [1] beschriebenen LoRa-APRS-Decoders. Eine wesentlich einfachere ( und deutlich preiswertere ) Version verwendet dagegen für den gleichen Zweck nur eines der schon oben erwähnten Boards.

Hier noch ein paar grundsätzliche Bemerkungen zur Erweiterbarkeit des Lora-Wetterdatentrackers: Grundsätzlich lassen sich alle in irgendeinem elektrischen Format verfügbaren Messwerte auch verarbeiten. Entscheidend ist dabei das Format der Schnittstelle. Im einfachsten Fall kann es sich dabei nur um die in einem festgelegten Zeitraum ankommenden Zählimpulse handeln, möglich sind aber auch Analogsignale ( die dafür ggf. an die am Porteingang maximal zulässige Spannung anzupassen sind ), sowie serielle Datensignale oder auch z.B. via I2C-Bus bereitgestellte Daten.
Ausgegeben werden können sie entweder im APRS-Textanhang, wobei kein bestimmtes Format einzuhalten ist, oder entsprechend der für APRS-Wetterdaten getroffenen Festlegung, so wie sie unter "APRS101" [5] beschrieben ist. Die Verwendung des APRS-Wetterdatenformates hat den Vorteil, dass es verschiedene Programme gibt, die eine erweiterte Auswertbarkeit der einzelnen Daten auf der Empfangsseite erlauben.

NEU: Bereitstellung von Wetterdaten auch via Bluetooth

Die verwendeten ESP32-Prozessoren erlauben schon von Haus aus auch eine Bluetooth-Funktionalität. Ermittelte Wetterdaten lassen sich dadurch drahtlos ( bei einer Reichweite von bis zu etwa 20m ) auch an Smartphones/Tablets übertragen. Abb.5 zeigt ein Beispiel für auf diese Weise übertragene und mit einem herkömmlichen Terminalprogramm ausgewertete Daten. Dabei erlaubt die von mir benutzte ( Android- ) APP von Kai Morich [6] vielfältige Darstellungvariationen, wie z.B auch nahezu bildfüllende Zeichen. Die erwähnte Bluetooth-Funktionalität wurde in die unter Link [2] herunterladbaren aktuellen Firmwareversionen bereits integriert. Bei der Erstinbetriebnahme ist einmalig vom Smartphone/Tablet ein Pairing mit dem ESP32-Prozessorbaustein herzustellen. Je nach verwendeter Version werden sich diese hier mit den Namen "HELTEC_WX_TX_1" oder "TTGO_WX_TX_1" anmelden.

Abb.5 Beispiel für Darstellung von Wetterdaten mithilfe eines Terminalprogramms

( Anm: Darstellungen von u.a. Zeichengrößen und Timestamps sind über EINSTELLUNGEN wählbar )

Korrektur der BME280-Luftdruck-Messwerte

Zu diesem Thema schrieb mir Peter, OE7SPI :

..... habe mich die letzten tage damit beschäftigt warum der Luftdruck immer zu nieder angezeigt wird. In der LoRa APRS gruppe hatte ich auch nichts gefunden ausser das andere schon das gleiche beobachtet habe. Durch Zufall habe ich heute ein längeres Gespräch mitn OE7AJT der auch mit dem gleichen Phänomen kämpfte im laufe unsres Gespräch fanden wir zufällig die Antwort das der Wert 100.0F für die Messung auf Meereshöhe gilt und wie der Wert ist für die jeweilige Station aussieht. Im Datenblatt vom BME 280 haben wir auch nicht mehr als den 100.0 Wert gefunden. Da aber der OE7AJT in der nähe vom Flughafen Erding wohnt und damit sehr genaue Werte zum vergleichen hat ist er durch probieren auf den Wert 95 gekommen. Durch herumgoogeln fanden wir noch die Infos die ich dir auch geschickt habe. Also ohne Anpassung des Wertes wird der aktuelle Wert ohne Berücksichtigung der Meereshöhe angezeigt und mit Anpassung den reduzierten Luftdruck wie er im allgemeinen bei den Wetterberichten gemeldet wird. Hoffe das du unsere Recherchen bestätigen kannst. Diese Info sollte auch in geeigneter form verteilt werden denke ich aber ich bin kein guter Erklärer wen ich dir den Weg zu dir nachhause erkläre findest du nieee mehr Heim. 73 de Peter

Peter hat zum Thema auch eine Korrekturtabelle zusammengestellt. Wer möchte, der kann im Quellcode ( sinnvollerweise direkt in Anschluss an die Zeile: pres = bme.readPressure()/100.0F; ) eine zusätzliche Zeile zur Addition des jeweiligen Korrekturwertes entsprechend der eigenen Betriebshöhe einfügen: pres = pres + <korrekturwert> ; .
Beispiel: Betriebshöhe sei 225m; Inhalt der Korrekturzeile: pres = pres + 27;

Tabelle 1 Korrekturwerte

Basierend auf der folgenden Formel wurden die Korrekturwerte ermittelt. Mit ihr kann berechnet werden, um wieviel der Druck in einer bestimmten Höhe geringer ist als auf 0m Seehöhe, so dort der "Normaldruck" 1013,25 hPa beträgt. Für eine Höhe von z.B. 100m ergibt das einen Wert von 1001,3 hPa. Die sich ergebende Differenz von ca. 12 ist dabei auch der benötigte Korrekturwert.

Tabelle 2

Sensorerweiterungen

Mehrfach wurde der Wunsch geäussert, die Wetterstation mit weiteren Sensoren auszustatten und auch deren Daten via LoRa-APRS zu übertragen. Infrage kommen dabei Sensoren zur Erfassung von z.B. Windrichtungen, anfallenden Regenmengen und Helligkeitswerten. Versuchsweise hatte ich meine oben beschriebene Station auch einmal entsprechend erweitert und dazu auch passende Softwareversionen erstellt. Danach hat sich allerdings herausgestellt, dass die Schnittstellen einzelner Sensorversionen doch sehr unterschiedlich sein können und sich bei Nachbauten dann Probleme ergaben, die immer auch eine individuelle Softwareanpassung erforderten. Aus diesem Grund werde ich auf die Bereitstellung entsprechender Versionen leider zukünftig verzichten.

Abb.7 Beispiel für die Zusammenschaltung der Baugruppen bei erweiterten Wetterstationsversionen

Abb.8 Beispiel für Displaydarstellung bei Verwendung einer erweiterten Version

Verwendung von 2.42"-OLED-Display

Für viele Anwendungen wird eine unzureichende Displaygrösse der bei den LoRa ESP32 HELTEC- und TTGO-Boards verwendeten 0.96"-OLED-Displays beklagt. Deshalb wurden Versuche unternommen, auch grössere OLED's mit 2.42"-Diagonalabmessung zu verwenden [7]. Es war schon etwas überraschend , als bereits erste Tests zeigten, dass sich schon die für die Originalversion benutzten Libraries auch für die 2.42-OLED's nutzen liessen. Das gilt zumindest, wenn hierbei die Version: "Adafruit_SSD1306" zum Einsatz kommt.

Abb.9 Grössenvergleich der Darstellung zwischen 0.96" und 2.42"-Display

Tabelle 3 Anschaltung OLED 2.42" an LoRa ESP32-Boards

Die Pins sind entsprechend dieser Liste mit den TTGO- bzw. HELTEC-Boards [ Klammerwerte ] zu verbinden
** wenn mit Masse verbunden : I2C-Adresse 0x3C
* externe Pull-Up-Widerstaende für SDA und SDA werden NICHT benoetigt, da auf den Prozessor- und Display-Board bereits vorhanden

Im Lieferzustand sind die 2.42"-Displays zur Steuerung via SPI-Bus eingerichtet. In Verbindung mit den erwähnten ESP32-Boards ist dagegen ihr I2C-Bus-Modus zu benutzen, wofuer sie vorab noch umgerüstet werden muessen. Dazu ist auf der Displayrückseite der Widerstand "R4" zu entfernen. Weiterhin sind die Anschlusspins für die Widerstaende "R5" und "R3" kurzzuschliessen bzw. hier jeweils ein Null-Ohm-Widerstand einzufügen ( siehe Abb.10 ).

Abb.10 Displayrückseite in Konfiguration für I2C-Mode

NEU in 12/2023: Inzwischen sind auch Versionen der 2.42"-OLED's verfügbar, die ausschliesslich eine Nutzung des I2C-Busses erlauben und damit auch die vorherige Hardwareanpassung entfällt. Nachdem sich dabei zudem auch die Zusammenschaltung vereinfacht, werden sie von mir inzwischen favorisiert. Erkennbar sind sie daran, dass sie lediglich 4 Anschlusspins ( Masse, +3,3V, SDA, SDL ) besitzen, wobei diese doppelt auf 2 Seiten der Displayplatine herausgeführt sind. Zugeführte RESET-Signale entfallen hierbei.

Abb.11 Boardrückseite 2.42"-OLED in der I2C-Version