NEU: Jetzt auch
mit neuen Funktionen und Auswertung von Daten weiterer Sensoren
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.
Weiter unten findet man auch neue Information, bei denen es um die Erweiterung
dargestellter und via LoEa-APRS übertragener Daten von Windrichtung,
Regen- und Lichtmenge geht.
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 wurden
zur Übertragbarkeit auch von Winddaten erweitert ( sind aber auch
ohne nutzbar ). Es gibt 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 "LoRa32" und "T-Beam".
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" 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
Sensor-Erweiterungen
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 Windrichtungen,
anfallenden Regenmengen und Helligkeitswerten.
Abb.6 Als Ersatzteile ( bei z.B. AMAZON ) erhältliche Sensoren
1. Windrichtungssensor
Als Ersatzteil für eine industriemäßig hergestellte Wetterstation,
gibt es vom Hersteller des Sensors zur Erfassung der Windgeschwindigkeit
auch einen solchen zur Bestimmung der Windrichtung. Je nach erkannter
Richtung, stellt er über zwei seiner Anschlusspunkte acht unterschiedliche
Widerstandswerte bereit. Zugeführt über einen Analogeingang des
Prozessors lassen sich daraus im Abstand von 45 Grad liegende Werte der
jeweiligen Windrichtung ermitteln. Im vorliegenden Fall wird dazu der Eingangsport
GPIO 39 verwendet.
2. Regensensor
Aus der gleichen Serie stammt auch ein Regensensor. Seine Funktion beruht
darauf, dass die Verbindung zwischen zwei Anschlusspunkten in Abhängigkeit
von der durchflossenen Regenmenge mehrfach unterbrochen wird. Bei der vorliegenden
Anwendung wird dabei über den Interrupteingang GPIO 13 jeweils
ein Zählimpuls ausgelöst, was funktionsmäßig somit
eine Ähnlichkeit zur der über GPIO 12 erfolgenden Windmengenmessung
aufweist.
3. Lichtmengenmessung
Zur Erkennung der Tag- und Nachtphasen werden die Daten eines Sensors zur
Lichtmengenmessung verwendet. Das benutzte Exemplar verwendet einen Sensor
des Typs "BH1750". Er ist auf einem Board mit der Bezeichnung "GY-302" verbaut
und wird über I2C-Bus gesteuert. Nachdem Helligkeitswerte unter APRS
nicht speziell unterstützt werden, werden sie im vorliegenden Fall
nur im Textanhang übertragen ( siehe dazu auch Abb.8 ).
4. Softwareerweiterung
Ursprünglich hatte ich nur meine oben beschriebenen Softwareversionen
durch zusätzliche Einbindung der von den drei genannten Sensoren bereitgestellten
Daten erweitert. In der LoRa-APRS-Gruppe von Facebook "endeckte" ich
danach die Wetterstation von Tomas, OK5TVR. Obwohl teilweise auch auf meiner
Ursprungsversion beruhend, gefiel sie mir in mancherlei Beziehung besser,
als die erweiterte eigene Version. Es gab aber auch ein paar Punkte, an
denen ich mir einige Abweichungen vorstellte und so entstanden hieraus die
beigefügten dritten Versionen * für jeweils TTGO- und HELTEC-Boards
[8]. Bei ihnen fehlt derzeit noch die Datenausgabe via Bluetooth, soll aber
demnächst nachgerüstet werden.
Abb.7 Zusammenschaltung der Baugruppen für die erweiterte Wetterstationsversion
Abb.8 Beispiel für Displaydarstellung bei Verwendung der erweiterten
Software
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