Mit den ESP32S- und ESP32-C-Series stellt Espressif weitere ESP32-SoCs unterschiedlicher Leistung zur Verfügung.
Die folgende Tabelle vermittelt einen Überblick über neuere Mitglieder der ESP32-Familie, die auch bereits durch die Arduino IDE unterstützt werden.
SOC
CPU
Cores
Memory
Special
ESP32-S2
Xtensa 32-bit LX7
Single-Core
128 KB ROM, 320 KB SRAM, 16 KB RTC SRAM
LCD Interface, Camera Interface, Touch Sensor, WiFi, BT 5.0, Native USB
ESP32-S3
Xtensa 32-bit LX7
Dual-Core
384 KB ROM, 512 KB SRAM, 16 KB RTC SRAM
Vector Instructions Support, WiFi, BT 5.2 (LE), Native USB
ESP32-C3
32-bit RISC-V Processor
Single-Core
400 KB RAM, 384 KB ROM, 8 KB RTC SRAM
WiFi, BT 5.2 (LE), Native USB
Übersicht ESP32-Sx & ESP32-Cx
Für die gelisteten SOCs stehen Developmentkits bereit und ich habe mit diesen die Resultate des CoreMark Benchmarks (mit Default Einstellungen) ermittelt:
CPU
Clock
DevKit
CoreMark
CoreMark/MHz
ESP32-C3
160 MHz
Beetle ESP32-C3
304.15
1.9
ESP32-S2
240 MHz
ESP32-S2-DevKitM-1
361.47
1.5
ESP32-S3
240 MHz
ESP32-S3-DevKitC-1
451.30
1.9
ESP32
240 MHz
ESPduino32 w/ ESP-WROOM-32
336.36
1.4
CoreMark Resultate
Der Output des CoreMark Benchmarks für ein ESP32-S3 DevKitC-1 sieht beispielsweise folgendermassen aus:
CoreMark Performance Benchmark
for ESP32-S3 DevKitC-1
Arduino SW Version 10607
Clock frequency 240 MHz
CoreMark measures how quickly your processor can manage linked
lists, compute matrix multiply, and execute state machine code.
Iterations/Sec is the main benchmark result, higher numbers are better
Running.... (usually requires 12 to 20 seconds)
2K performance run parameters for coremark.
CoreMark Size : 666
Total ticks : 13295
Total time (secs): 13.30
Iterations/Sec : 451.30
Iterations : 6000
Compiler version : GCC8.4.0
Compiler flags : (flags unknown)
Memory location : STACK
seedcrc : 0xE9F5
[0]crclist : 0xE714
[0]crcmatrix : 0x1FD7
[0]crcstate : 0x8E3A
[0]crcfinal : 0xA14C
Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 451.30 / GCC8.4.0 (flags unknown) / STACK
Erst kürzlich wurde der ESP32-C5 angekündigt und es steht erstmals ein Device zur Verfügung, welches WiFi sowohl mit 2.4 GHz als auch mit 5 GHz erlaubt. Wenn es hierzu ein Developmentkit gibt, können die betreffenden Ergebnisse ergänzt werden.
Das 0.3 Watt, 3.3 Volt Solar Power System von Voltaic Systems versorgt LoRa- und andere Low-Power IoT-Knoten kontinuierlich mit Energie. Zum Lieferumfang gehören: – IP67 wasserdichtes Gehäuse mit Montageset für Mastmontage – 0.3 Watt, 6 Volt Solar Panel montiert auf das Gehäuse – 250 F Lithium Ion Capacitor Solar Charger mit 3.3 V DC Ausgangsspannung
In der Regel findet man als Energiespeicher LiPo-Akkus. Für Geräte mit sehr niedrigem Stromverbrauch (350 μA bei 3.3 V) verwendet Voltaic Systems einen Lithium-Ionen-Kondensator (LIC) als Speicher. LICs kosten zwar mehr pro Wattstunde und haben eine geringere Energiedichte als Lithium-Ionen-Batterien, haben aber einen viel breiteren Temperaturbereich, können weitaus mehr Zyklen durchlaufen und weisen keine Sicherheitsprobleme auf.
Auf der Grundlage von LoRa lassen sich IoT-Knoten mit geringem Stromverbrauch realisieren. Die Verwendung von WiFi ist aufgrund des höheren Stromverbrauchs während der Übertragung komplexer. Mit dem ePulse – Low Power ESP32 Entwicklungsboard können Sie den Stromverbrauch durch die Implementierung längerer Tiefschlafphasen erheblich reduzieren. Die folgende Abbildung zeigt das hier verwendete ESP32-Board.
ePulse – Low Power ESP32 Development Board
Der mittlere Stromverbrauch wird nach folgender Gleichung berechnet:
op kennzeichnet die Betriebsphase (WiFi-Übertragung) und DS die Tiefschlafphase des verwendeten Mikrocontrollers. Informationen zum Deep Sleep des ESP32 finden Sie u.a. im Beitrag How to Put an ESP32 into Deep Sleep.
Für lange Deep Sleep Zeiten (tDS >> top) gilt vereinfacht die Beziehung:
Das bedeutet, dass der resultierende Strombedarf um das Verhältnis von Betriebszeit zu Tiefschlafzeit sinkt. Für das oben erwähnte ESP32-Board erhalten wir mit Iop = 110 mA, top = 4 s, IDS = 25 uA und tDS = 1796 s einen Mittelwert der Stromaufnahme von 270 uA. Für Umweltdaten ist ein Messzyklus von 30 Minuten akzeptabel, und die Stromversorgung sollte ausreichend sein.
Mit dem Programm LilyGo_T-OI_Plus_Voltaic_Battery_Monitor.ino habe ich einen Langzeittest gestartet, bei dem die Spannung am LIC erfasst und alle 30 min in eine InfluxDB-Datenbank eingetragen wird.
Das folgende Bild zeigt den Verlauf der LIC-Spannung über die letzten 24 h an einem sonnigen Tag. Es ist deutlich zu erkennen, dass morgens gegen 9:00 die Spannung durch die Sonneneinstrahlung steigt. Bis gegen 15:00 war das Solarpanel eher beschattet, danach wurde es direkt von der Sonne bestrahlt.
Die Datenübertragung über WiFi stellt im gewissen Sinn eine Worst-Case-Betrachtung dar, da mit anderen Übertragungsarten, wie ESPNow, LoRa etc., wesentlich günstigere Ausgangsbedingungen existieren.
Für den Ausseneinsatz habe ich den IoT-Knoten noch um einen Temperatursensor DS18B20 erweitert.
Solarbetriebener IoT-Knoten mit Temperatursensor DS18B20
Im Programm LilyGo_T-OI_Plus_Voltaic_Battery_Monitor.ino bedarf es nur weniger Codezeilen für den DS18B20, da geeignete Libraries zur Verfügung stehen. Der Langzeittest wird also mit dem erweiterten Programm weitergeführt. Es werden die Spannung am LIC und die Außentemperatur erfasst und alle 30 min in eine InfluxDB-Datenbank eingetragen. Die visualisierten Daten sind im folgenden Screenshot zu sehen, der ab und an aktualisiert wird.
Wie der Temperaturverlauf im unteren Diagramm zeigt, ist immer noch Hochsommer mit Temperaturen bis zu 40 °C bei direkter Sonnenbestrahlung des Temperatursensors.
Am 24.08. und 25.08 (hier nicht mehr dargestellt) brach nachts die Kommunikation ab. Die Ursache lag beim Schließen der elektrisch stark dämpfenden Terassentür. Der Standort des Devices war zwar bezüglich der Bestrahlung durch die Sonne optimal, was eine rasche Aufladung zur Folge hatte. Bezüglich der WiFi-Reichweite war der Standort nicht optimal.
Es ist also besonders wichtig, eine unterbrechungsfreie WiFi-Übertragung sicherzustellen oder im Programm, diese zu erkennen und zu viele (ergebnislose) Verbindungsversuche zu unterbinden. Ein (z.B. gewitter-bedingter) Stromausfall, der den Router deaktiviert, zeigt die gleichen Folgen.
Im September war es mit dem Sommerwetter vorbei und es schloss sich eine Regenperiode an, die ein vernünftiges Nachladen des LIC nicht zuließ. Der Spannungsverlauf zeigte sich gemäß dem folgenden Bild, wobei es teilweise Kommunikationsabbrüche gab. Erst nach dem Erreichen einer Mindestspannung am LIC wurde die Kommunikation wieder aufgenommen.
Fazit:
Eine Verbesserung des Ladezustands ist erforderlich und kann durch die folgenden Maßnahmen erreicht werden:
Optimierung des Standortes resp. bessere Ausrichtung zur Sonneneinstrahlung
Ersatz der WiFi-Kommunikation durch ESPNow oder LoRaWAN/LoRaP2P
Vergrößerung des Sendeintervalls
Durch die Optimierung des Standortes konnte ein ordentliches Nachladen erreicht werden, auch wenn nicht jeden Tag optimale Sonneneinstrahlung vorgeherrscht hat.
In den Wintermonaten mit Dauernebel und praktisch ohne Sonnenschein hat das System seine Grenzen erreicht. Die bereits im Fazit genannten Modifikationen könnten Verbesserung bringen.
Beim Erfassen mobiler Daten spielt die Datenübertragung eine entscheidende Rolle. Ausschlaggebend ist die jeweilige Netzabdeckung, sobald die Abdeckung durch ein eigenes Gateway nicht mehr gegeben ist.
Ich möchte Daten im Fahrzeug erfassen. Für die Fahrzeugposition und Geschwindigkeit bieten sich die über das GPS ermittelten Daten an. Umweltdaten, wie externe und interne Temperatur, Luftfeuchtigkeit und Luftdruck, können mit den bekannten Sensoren erfasst werden. Zur Bewegungs- oder Crashdetektion können IMU-Sensoren eingesetzt werden.
Ein Datensatz, der die gewünschten Daten enthält, kann schließlich drahtlos übermittelt werden. Für die Datenübertragung kommen Netzwerke in Frage, die eine ausreichende Abdeckung sicherstellen.
Ich betrachte hier die DACH-Region (D, A, CH) als Einsatzgebiet einer solchen Anwendung. In der Schweiz bietet Swisscom eine nahezu komplette Abdeckung mit LoRaWAN an, was in den anderen beiden Ländern so nicht der Fall ist. Damit bleibt im gesamten Gebiet LTE-M für den mobilen Einsatz.
Für die Datenkommunikation mit LTE-M bedarf es einer SIM-Card, die heute von zahlreichen Anbietern verfügbar ist. Ich verwende für meine Anwendungen SIM-Cards von 1NCE.
Der Preis des 1NCE IoT Datentarifs sieht 10 Jahre Konnektivität und Services für einmalig 10 Euro vor. 1NCE bietet mit der 1NCE IoT Flat Rate einen Datentarif an, der bereits alle benötigten Services inkludiert:
SIM-Card
Globale Netzabdeckung in über 100+ Ländern
Alle Mobilfunkstandards (2G, 3G, 4G, LTE-M, NB-IoT)
500 MB Datenvolumen mit bis zu 1Mbit/s
250 SMS (verwende ich nicht)
Als Hardware verwendet ich ein LILYGO® TTGO T-SIM7000G Modul auf Basis eines ESP32-WROVER.
LILYGO® TTGO T-SIM7000G Module
Neben dem ESP32-WROVER-B mit 4 MB Flash & 8 MB PSRAM sind die folgenden Komponenten auf dem Board zu finden: SIMCOM SIM7000G Modul, Interfaces für USB Type-C, SD-Card, Nano SIM Card, Batteriehalter für LiPo 18650 und Solar Input. LTE- und GPS-Antenne werden über U.FL-Stecker mit dem Board kontaktiert.
Zur Ansteuerung von Sensoren können die zahlreich vorhandenen GPIOs oder der I2C-Bus verwendet werden. Die Batteriespannung kann über einen Spannungsteiler und GPIO35 (ADC07) erfasst werden.
Zum Test der Verbindung aus dem bewegten Fahrzeug verwende ich das Programm TTGO_LTE-M_NetworkTest1.ino, welches an Stelle von Messwerten eine Countervariable und bei Batteriebetrieb die Batteriespannung über MQTT an den Public Broker broker.hivemq.com übertragt.
Vor der mobilen Anwendung möchte ich die Laufzeit des LiPo 18650 bei einem Sendeintervall von 10 Sekunden ermitteln. Die folgende Tabelle habe ich dem Testverlauf entsprechend nachgeführt.
Nach reichlich einem Tag war die batteriegestützte Übertragung im 10-Sekundentakt abgeschlossen. In dieser Zeit wurde ca. 10 MB an Daten über LTE-M versendet.
Nach dem Aufladen der Batterie habe ich eine Testfahrt unternommen, um den Übergang von einer Funkzelle zur anderen zu testen. Die Route ist im Bild gezeigt und die Kommunikation hat funktioniert.
Testfahrt
Ich habe das LILYGO® TTGO T-SIM7000G Modul durch ein M5Stack ENV.II Unit zur Erfassung von Temperatur und Luftfeuchtigkeit ergänzt und bin damit in der Lage mit Hilfe der GPS-Daten die Koordinaten des betreffenden Standorts und die Geschwindigkeit, mit Hilfe der Daten des ENV.II Sensors Temperatur, Luftfeuchtigkeit und barometrischen Druck (hier nicht verwendet) und die Batteriespannung des 18650 LiPo Akkus zu messen. Die erfassten Daten übermittle ich via MQTT an den Public Broker von Hivemq.
Das im Bild gezeigte Modul kann sowohl über USB also auch über den eingebauten 18650 LiPo Akku betrieben werden. GPS und ENV.II Sensor können über MQTT-Kommandos aktiviert resp. deaktiviert werden.
Im linken Bild wird das Modul zuerst über USB betrieben, anschließend durch Trennen der USB-Verbindung auf Batteriebetrieb umgeschaltet und schließlich durch erneutes Verbinden mit USB die Spannungsversorgung wieder über USB vorgenommen.
Im rechten Bild sind zu Beginn sowohl GPS als auch der ENV.II Sensor eingeschaltet und eine komplette JSON-Message über MQTT ausgegeben. Durch das Kommando TTGO/sensor:0 wird der ENV.II Sensor ausgeschaltet und der betreffende Inhalt fehlt folglich in der MQTT-Message. Durch das Kommando TTGO/gps:0 erfolgt das Deaktivieren des GPS und auch die betreffenden Inhalte fehlen in der MQTT-Message, so dass nur noch der Name des Moduls und die Batteriespannung ausgegeben werden. Über die Kommandos TTGO/gps:1 und TTGO/sensor:1 sind schließlich GPS und ENV.II Sensor wieder aktiv.
Umschaltung USB powered nach battery powered und zurückAusschalten des ENV.II Sensors und GPS und zurück
Den Messablauf zeigt das folgende Video:
Der Beginn der Sequenz wird durch zweimaliges kurzes Blinken der blauen LED signalisiert. Während der Suche nach den GPS-Satelliten blinkt die blaue LED im Takt von 2 Sekunden. Hier ist nur eine Phase (2 secON, 2 sec OFF) zu sehen. Das Versenden der MQTT-Message wird durch fünfmaliges kurzes Blinken der blauen LED signalisiert.
Für den Test der Batterieentladung werden GPS und ENV.II Sensor eingeschaltet, da das praktisch das Worst-Case-Szenario darstellt. Den Messzyklus habe ich hier auf 60 Sekunden gesetzt, da das ehestens dem Fahrzeugeinsatz entspricht.
Die folgende Tabelle zeigt den Verlauf der Batteriespannung unter der genannten Bedingung.
Die Laufzeit batteriebetrieben liegt damit bei einem Tag.
Da die MQTT-Clients auf dem PC oder dem Smartphone in der Regel nach einer bestimmten Zeit dunkel geschaltet werden, habe ich einen M5Stack MQTT Client aufgebaut, der im Dauerbetrieb laufen kann.
Damit ein zeitlicher Bezug hergestellt werden kann, den die MQTT-Clients auf dem PC oder Smartphone selbst übernehmen, habe ich noch eine Abfrage eines NTP-Servers vorgesehen.
LiLyGo bietet eine Reihe von Mikrocontrollermodulen mit LCD oder OLED-Display an, die weitgehend auf ESP8266 oder ESP32 aufbauen. Die LiLyGo TTGO T5 Serie umfasst vergleichbare Mikrocontrollermodule mit ePaper-Displays, die sich durch extrem geringe Stromaufnahme gerade für den Batteriebetrieb eignen.
Über den LiLyGo Mini ePaper Core 1.02″ hatte ich bereits berichtet. Das LiLyGo T-Display ePaper 1.02″ hat vergleichbare Eigenschaften, steht aber als PCB mit den folgenden technischen Daten zur Verfügung:
Stromaufnahme 15 uA im Deep Sleep (bei Batteriebetrieb)
LiLyGo T-Display ePaper 1.02″ – Front- und Rückseite
Auf Github finden Sie alle erforderlichen Daten. Folgen Sie dem Produktlink T-Display E-paper 1.02″ um weitere Informationen zum speziellen Modul zu erhalten. Leider ist das Schema des Moduls auf Github noch nicht gelistet.
Das Programmbeispiel LilyGo_EPD102_HW.ino zeigt die Ausgabe der oben dargestellten Grafik gefolgt von der hier gezeigten Textausgabe.
Da ein ePaper Display nur beim Umschalten (Refresh) der Anzeige Strom zieht, kann nach Aktualisierung und Versenden eines Messwertes des ESP32 wieder in den Deep Sleep versetzt werden.
Ich werde die Eignung des Moduls für den Batteriebetrieb vergleichbar zum Vorgehen im Beitrag Batteriebetriebene IoT-Knoten testen und erwarte ähnliche Resultate wie für den T5 mit LiPo 1000 mAh.
Der ESP32-C3 RISC-V Mikrocontroller weist im Deep Sleep eine sehr geringe Stromaufnahme von nur 5 uA auf und ist damit für den Batteriebetrieb geeignet. Sensoren können über den I2C- und SPI-Bus oder seriell (UART) angeschlossen werden.
ESP32-C3-0.42LCD Pinout
Über das 72×40 Pixel Display können unter Verwendung der U8g2libTexte und Grafiken ausgegeben werden. Die folgenden Bilder (sorry für die Qualität) zeigen die Ausgabe
Das Board hat einen Batterieanschluss, aber kein Powermanagement, d.h. auch keine Lademöglichkeit für die Batterie. Ich verwende hier GPIO3 als ADC-Eingang zur Messung der 5V Spannung, die entweder über USB oder die Batterie zur Verfügung gestellt wird.
Über einen Qwiic-Connector können Sensoren angeschlossen werden. Ich habe das Board auf diesem Weg mit einem Sparkfun SHTC3 zur Messung von Temperatur und relativer Luftfeuchte erweitert.
Durch das Programm 01Space_ESP32-C3_SHTC3.ino werden die Messwerte in folgender Form zur Anzeige gebracht:
28.0 C 48 %rH 1240 mV
Der ADC Eingang ist hier noch unbeschaltet (floating).
In der Zwischenzeit ist ein sehr guter Beitrag im Technik Blog von Stefan Draeger erschienen (https://draeger-it.blog/mikrocontroller-esp32-c3-mit-lcd-display/). Dank der praktischen Hinweise im Beitrag können Sie sich einigen Ärger ersparen. Also, unbedingt hineinschauen.
Ausgestattet mit einem Low-Power ESP32-C3 RISC-V CPU und Batteriehalterung sowie Lademanagement für einen 16340 LiPo-Akku erscheint der LILYGO® TTGO T-OI PLUS ein für IoT-Anwendungen geeignetes Controllermodul zu sein.
LILYGO® TTGO T-OI PLUS RISC-V ESP32-C3
Zur externen Erweiterung stehen SPI- und I2C-Bus sowie eine UART-Schnittstelle zur Verfügung. Der Grove Connector, auf den dier I2C-Bus herausgeführt wird, ist so nicht brauchbar, wie das folgende Bild zeigt.
Entweder Sie konfektionieren das Grove Kabel passend zur fehlerhaften Belegung auf dem Board oder Sie nutzen die Anschlüsse an der betreffenden Pinleiste.
Bei einem batteriebetriebenen Mikrocontroller ist das Monitoring der Batteriespannung ein wichtiges Indiz für den Ladezustand und damit der Laufzeit der Anwendung. Hier war es nicht einfach mit dem Auslesen des ADC-Kanals getan. Das Programm ESP32-C3_AnalogReadCal.ino zeigt Ihnen eine mögliche Vorgehensweise.
Abfrage der Batteriespannung
Mit dem Programm ESP32-C3_Battery_Monitor frage ich die Batteriespannung ab, verbindet mich anschliessend mit der InfluxDB Cloud und sende alle 30 Minuten den erhobenen Messwert in die Datenbank. Dieses Vorgehen entspricht dem im Beitrag Batteriebetriebene IoT-Knoten beschriebenen Vorgehen, so dass die Daten vergleichbar sind.
Der Test wurde am 24.06.2022 08:25 mit einer Batteriespannung von 4.086 V gestartet. Abgeschlossen war der Test am 10:07.2022 11:00 nach 386 h bei einer Batteriespannung von 2.86 V.
Am T-OI Plus Board selbst wurden keine Veränderungen vorgenommen, d.h. die rote LED leuchtet dauernd und die grüne LED schalte ich während der WiFi-Verbindung an.
Zur Reduktion der Stromaufnahme kann die rote LED physisch entfernt und die Ansteuerung der grünen LED unterdrückt werden. Ausserdem kann an Stelle der WiFi-Verbindung eine ESPNow-Kommunikation eingerichtet werden. Das durch diese Massnahme eine bedeutende Erhöhung der Batterielaufzeit erreicht werden kann, wurde im Beitrag ESP32 – Ultra-Long Battery Life With ESP-NOW gezeigt.
Ich wiederhole den Test nach Abtrennen der roten LED. Der Test wurde am 24.07.2022 13:19 mit einer Batteriespannung von 4.160 V gestartet.
Bereits zu Beginn der Entladung ist die deutlich flachere Entladekurve absehbar. Ich werde beide Bilder aktuell halten.
StackyPi ist ein kompaktes auf dem RP2040-Mikrocontroller aufbauendes Board mit einer Raspberry Pi-kompatiblen Stiftleiste (Header), die den Anschluss der sogenannten Raspberry Pi HATs (HAT – Hardware Attached on Top) ermöglicht. Dadurch erschliessen sich dem Anwender weitere, im Raspberry Pi-Umfeld bereits etablierte Peripherie-Erweiterungen.
Einige willkürlich ausgewählte pHATs zeigt die folgende Galerie. Ich werde im folgenden das Coral Environmental Sensor Board als Beispiel einer Integration eines pHATs in eine RP2040 Arduino Umgebung verwenden.
Für die Verbindung mit einem pHAT ist die Belegung der Stiftleiste und die Zuordnung der Pins des RP2040 besonders wichtig.
Weitere Informationen finden Sie auf der SB-Components Website. Wichtig ist ausserdem, die Zuordnung der Pins an Hand des Schemas zu verifizieren.
Das Board weist die folgenden Komponenten auf:
● 128×32 OLED Display ● Umgebungslichtsensor OPT3002 ● Drucksensor BMP280 ● Temperatur- und Feuchtesensor HDC2010 ● Cryptoprocessor ( ATECC608A) with Google keys ● Grove connectors: 1x UART, 1x I2C, 1x PWM, 1x 3.3/5V analog ● General purpose button ● General purpose LED
Mit einer Reihe von kleinen Arduino Programmen werde ich die peripheren Komponenten in Betrieb nehmen. Die dokumentierten Quelltexte finden Sie auf Github.
OLED Display
Das OLED Display hat eine Auflösung von 128 x 32 Pixeln und wird mit einem SSD1306 Controller über SPI0 betrieben.
Unter Verwendung der Libraries von Adafruit und der im Quelltextausschnitt gezeigten Initialiserung erzeugt das Programm StackyPi_ESB_OLED.ino die folgenden Ausgaben auf dem OLED Display.
Ich habe das beklannt I2C Scanprogramm auf die beiden I2C-Busse des RP2040 angepasst und kann damit die angeschlossenen Sensoren ermittel. Das Programm StackyPi_ESB_I2C.ino findet fünf an I2C0 angeschlossene I2C Devices. An I2C1 ist keine Device angeschlossen.
Die ermittelten Adressen sind wie folgt den I2C-Bus-Devices zugeordnet:
Mit dem auf der ClosedCube OPT3002 Library aufbauenden Programm StackyPi_ESB_OPT3002.ino wird der Light-to-Digital Sensor OPT3002 von TI abgefragt und die erhobenen Messwerte zur Anzeige gebracht.
Barometrischer Drucksensor BMP280
Mit dem auf der BMx280IM Library aufbauenden Programm StackyPi_ESB_BMP280.ino wird der Drucksensor BMP280 von Bosch abgefragt und die erhobenen Messwerte zur Anzeige gebracht.
Analog/Digital-Umsetzer TLA2021
Mit dem auf der Adafruit_TLA202x Library aufbauenden Programm StackyPi_ESB_ADC.ino wird der Kanal 0 des ADC TLA2021 von TI abgefragt und die erhobenen Messwerte zur Anzeige gebracht. Der Kanaol 0 des ADC ist auf den Grove Konnektor auf der rechten Seite herausgeführt. Der Jumper ist auf VDD_A = 3.3 V zusetzen.
Coral ESB Wetterstation
Mit den vorhandenen Sensoren kann nun leicht eine mit externen Sensoren erweiterbare Wetterstation aufgebaut werden.
Sensor
erfasste Grössen
HDC2010
Temperatur, relative Luftfeuchtigkeit
BMP280
Barometrischer Druck, Temperatur
OPT3002
Umgebungshelligkeit
Aufbauend auf den bislang vorgestellten Softwarekomponenten habe ich das Programm StackyPi_ESB_Weather.ino zusammengestellt.
Nach der umgangreicheren Initialisierung der Sensoren und des OLED Display beginnt die zyklische Abfrage der Sensoren und die Ausgabe der Messwerte über die serielle Schnittstelle.
Wegen der recht geringen Auflösung des OLED Display erfolgt im Abstand von zwei Sekunden stets nur die Ausgabe eines Messwertes. Sie können das auch im Video verfolgen.
Das Interesse an Messungen zur Radioaktivität resultierte in der Vergangenheit aus dem Test von Nuklearwaffen und den sich stark verbreitenden Kernkraftwerken seit den 1960er Jahren. Heute hat das Thema wieder an Aktualität gewonnen, nachdem eine verpasste Energiewende zur Sicherung des Energiebedarfs den Bau weiterer Kernkraftwerke nach sich ziehen wird und verantwortungslose Politiker offen mit einer atomaren Drohkulisse agieren.
Ich habe nach Möglichkeiten zur Messung radioaktiver Strahlung recherchiert, um eine autonom arbeitende Messstation aufzubauen, die Messwerte erfasst und drahtlos weiterleitet. Die drahtlose Weiterleitung kann dabei via WiFi über einen Router ins Internet, über LoRaWAN beispielsweise ins TTS (CE) oder ESP-NOW an einen Konzentrator zu Anzeige und/oder Weiterleitung erfolgen. Im Vordergrund steht aber zuerst die Messwerterfassung selbst über die ich hier berichten werde.
Arduino-Komponenten haben sich schon lange für das Prototyping qualifiziert und werden dabei durch M5Stack-, Grove-, QwIIC-, mikroBus-Komponenten u.a.m. wirkungsvoll unterstützt.
Die WisBLOCK Komponenten der in Shenzhen ansässigen Fa. RAKwireless Technology Co. erweitern die vorhandenen Möglichkeiten zusätzlich. Gemäß Aussage des Herstellers ist WisBlock ist eine komplette, qualifizierte Systemlösung, die aus einer Reihe von modularen IoT-Blöcken wie Sensoren, Rechnerkernen und Konnektivität besteht. Es stehen zahlreiche Module zur Verfügung, die sich in Baseboards, Core-Module für LoRaWAN (nRF52840 SX1262, RP2040 SX1262) sowie WiFi &BLE (ESP32), Wireless-Module (WiFi, NB-IoT, GSM, LoRaWAN, NFC-Reader), sowie Sensor-, Interface-, Display-, Speicher- und Power-Module unterteilen lassen. Informieren Sie sich im OnLine-Shop von RAKwireless unter über das breite und kostengünstige Angebot. Hinzu kommen verschiedene Gehäusevarianten, von denen mir für IoT-Anwendungen vor allem das RAKBox-B2 Gehäuse mit Solarpanel interessant erscheint.
Die M5Stack Atom Serie mit einer Größe von nur 24 * 24mm sind sehr kompakte Entwicklungsboards der M5Stack Development Kit Serie. Die angebotenen Varianten verwenden alle einen ESP32-PICO, der WiFi- und Bluetooth-Konnektivität bietet und über 4 MB seriellen SPI-Flash verfügt. Über sechs GPIOs kann der Controller mit externen Sensoren und Aktoren verbunden werden. Die Typ-C-USB-Schnittstelle ermöglicht ein schnelles Programm-Upload und stellt eine RS232-Schnittstelle zur Verfügung. Eine HY2.0-Schnittstelle dient als Grove-Port.
Das einfachste Modell der M5Stack Atom Serie ist der Atom Lite, der zusätzlich noch eine Infrarot- und eine RGB-LED und zwei Tasten bietet. Das folgende Blockdiagramm zeigt die zur Verfügung stehenden Komponenten.
M5Stack Atom Lite Blockdiagram
Zahlreiche Hardware-Erweiterung ermöglichen eine einfache Anpassung an die betreffende Anwendung. Zu nennen sind beispielsweise das ATOMIC DIY Proto Kit for ATOM Series, ATOM HUB DIY Proto Board Kit, ATOM HUB AC/DC Remote Control Switch Kit, Atom DTU LoRaWAN Kit 868MHz, Atom DTU NB-IoT Kit Global Version und andere mehr. Eine Übersicht finden Sie unter https://shop.m5stack.com/collections/atom-series.
Naturgemäss fehlt dem kompakten Controllerboard ein Display, was aber mit den folgenden M5Stack Displaykomponenten beigestellt werden kann.
M5Stack OLED UnitM5Stack LCD UnitM5Stack Atom Display Driver
Die M5Stack OLED Unit ist ein OLED-Display mit einer Diagonalen von 1.3 “ und einer Auflösung von 128 x 64 Pixeln. Die M5Stack LCD Unit ist ein farbiges LCD mit einer Diagonalen von 1.14 “ und einer Auflösung von 240 x 135 Pixeln. Beide Display Units verfügen über ein Grove-I2C-Port und können über den I2C-Bus vom Atom aus angesteuert werden.
Der M5Stack Atom Display Driver ist ein All-in-One-Displaytreiber-Kit und weist ein HDMI-Interface zu einem Computer-Bildschirm mit einer maximalen Auflösung von 1280 x 720 Pixeln auf. Es wird ein FPGA verwendet, um die traditionelle SPI-TFT-LCD-Datenausgabe zu simulieren und bietet ein Videosignal mit präzisen Farben. Der Built-In ATOM PSRAM Main Controller (ESP32-PICO-V3-02 mit 8 MB Flash + 2 MB PSRAM) bietet auch wieder WiFi und Dual-Mode-Bluetooth.
Im Post AZ-Touch ESP32 Grafiktest hatte ich einen Grafik-Benchmark gezeigt, der die Eigenschaften der Kombination ESP32-Mikrocontroller und ILI9341-TFT-Display verdeutlichen sollte. Diesen Benchmark habe ich für die drei gezeigten Display angepasst, um deren Verhalten zu vergleichen. Sie finden das Programm M5Atom_Display.ino auf Github. Im folgenden Video sehen Sie die Ausgaben des M5Stack Atom Display Drivers auf einem 22″ Bildschirm.
Bei den beiden kleineren Displays wird bei den Textausgaben und der JPG-Ausgabe mitunter der Bildschirmrand verlassen. Eine entsprechende Skalierung wurde bewusst nicht vorgenommen, da der Test für derart kleine Auflösungen ohnehin nur bedingt geeignet ist.
Die folgende Grafik zeigt die Laufzeit der einzelnen Tests und vermittelt dabei einen ersten Eindruck. Obwohl bei Pixel und Line Test die Laufzeiten stark differieren, liegen die Laufzeiten der meisten Tests durchaus in der Nähe des über SPI angesteuerten ILI9341-Displays.
ckArduino 
Du muss angemeldet sein, um einen Kommentar zu veröffentlichen.