ckArduino

RAKwireless Air Quality Node

Air quality is an essential issue in times of Corona and especially then. We have lower risks of infections during the summer, but we already get various prognoses for the following autumn and winter again.
Pollutants include fine dust, asbestos, Formaldehyde, PCB, radon, cleaning agents, mold, dust, tobacco smoke, VOCs (volatile organic compounds), and CO₂, which affect indoor air quality.
The proportion of carbon dioxide in the air we breathe today is approximately 415 ppm (corresponds to 0.04% of the air). The air breathed out by a person has a CO₂ content of around 40,000 ppm. Accordingly, in unventilated bedrooms, fully occupied classrooms, or meeting rooms, we can quickly measure up to 5,000 ppm. These high CO₂ concentrations harm attention, performance, and health in general.
NDIR sensors (non-dispersive infrared sensors) use the concentration-dependent absorption of electromagnetic radiation in the infrared range. At a wavelength of 4.3 μm, there is maximum absorption of CO₂ without much influence from other gases.
The CO₂ concentration can therefore be measured very selectively.
With MOX sensors, the gas flowing past causes a change in a gas-sensitive metal oxide layer (MOX). This change in resistance is thus a measure of the concentration of volatile organic components (VOC) recorded in their entirety and cannot be dissolved into a particular substance. The broadband VOC-measuring MOX sensors detect a spectrum of substances hazardous to health in specific concentrations.
Here I would only like to deal with the measured values of CO₂ and VOC recorded by the two sensor variants mentioned above, as these represent the dominant topic in the current situation of COVID-19 and are used in so-called CO2 traffic lights.
I am sure that you know that aerosols mainly transmit coronaviruses. Suppose we use the CO2 concentration as a measure of the air quality. Then we have a good indication of the air quality pollution by the air breathed out by the people present and the risk of infection from viruses transmitted via the aerosols.
Suppose we use more broadband measures of MOX sensors to measure the air quality. In that case, we have a good indication of air quality pollution by various pollutants, including human vapors and odors.
In an extensive study, I examined the behavior of NDIR and MOX sensors when measuring air quality. Sorry, the text is German, but the following graphic shows an important result.

Die Luftqualität ist in Zeiten von Corona und besonders dann ein wichtiges Thema. Im Sommer haben wir ein geringeres Infektionsrisiko, aber für den folgenden Herbst und Winter gibt es bereits wieder verschiedene Prognosen.
Zu den Schadstoffen gehören Feinstaub, Asbest, Formaldehyd, PCB, Radon, Reinigungsmittel, Schimmel, Staub, Tabakrauch, VOC (flüchtige organische Verbindungen) und CO₂, die die Luftqualität in Innenräumen beeinträchtigen.
Der Anteil von Kohlendioxid in der Luft, die wir heute einatmen, beträgt etwa 415 ppm (entspricht 0,04 % der Luft). Die von einem Menschen ausgeatmete Luft hat einen CO₂-Gehalt von etwa 40.000 ppm. In ungelüfteten Schlafzimmern, voll besetzten Klassenzimmern oder Besprechungsräumen können wir daher schnell bis zu 5.000 ppm messen. Diese hohen CO₂-Konzentrationen beeinträchtigen die Aufmerksamkeit, die Leistungsfähigkeit und die Gesundheit im Allgemeinen.
NDIR-Sensoren (non-dispersive infrared sensors) nutzen die konzentrationsabhängige Absorption elektromagnetischer Strahlung im Infrarotbereich. Bei einer Wellenlänge von 4,3 μm ist die Absorption von CO₂ am höchsten, ohne dass andere Gase einen großen Einfluss haben. Die CO₂-Konzentration kann daher sehr selektiv gemessen werden.
Bei MOX-Sensoren bewirkt das vorbeiströmende Gas eine Veränderung einer gasempfindlichen Metalloxidschicht (MOX). Diese Widerstandsänderung ist somit ein Maß für die Konzentration der flüchtigen organischen Bestandteile (VOC), die in ihrer Gesamtheit erfasst und nicht in eine bestimmte Substanz aufgelöst werden können. Die breitbandigen VOC-messenden MOX-Sensoren detektieren ein Spektrum von gesundheitsgefährdenden Stoffen in bestimmten Konzentrationen.
Ich möchte hier nur auf die Messwerte von CO₂ und VOC eingehen, die von den beiden oben genannten Sensorvarianten erfasst werden, da diese in der aktuellen Situation von COVID-19 das beherrschende Thema darstellen und in sogenannten CO2-Ampeln eingesetzt werden.
Sie wissen sicher, dass Coronaviren hauptsächlich über Aerosole übertragen werden. Nehmen wir an, wir verwenden die CO2-Konzentration als Maß für die Luftqualität. Dann haben wir einen guten Anhaltspunkt für die Luftverschmutzung durch die von den anwesenden Personen ausgeatmete Luft und das Risiko einer Infektion durch Viren, die über die Aerosole übertragen werden.
Angenommen, wir verwenden breitbandigere MOX-Sensoren zur Messung der Luftqualität. In diesem Fall haben wir einen guten Hinweis auf die Verschmutzung der Luftqualität durch verschiedene Schadstoffe, einschließlich menschlicher Dämpfe und Gerüche.
In einer umfangreichen Studie habe ich das Verhalten von NDIR- und MOX-Sensoren bei der Messung der Luftqualität untersucht.

In one of the experiments, I measured with two CO₂ sensors and one MOX sensor.
The CO₂ sensors used were SCD30 (NDIR) and SCD41 (PASense), developed by the Swiss company Sensirion. The MOX sensor was an SGP30, also from Sensirion.
Because there were no additional substances in addition to the human vapors, the measured values of the MOX sensor SGP30 also follow the two CO₂ sensors SCD30 and SCD41.
The air quality measurement with the more cost-effective MOX sensors shows results comparable to the pure CO₂ concentration everywhere where the breathing air and human vapors dominate. Deviations occur in polluted environments (e.g.,
with formaldehyde), but this general problem requires a separate solution.
RAKwireless WisBlock offers all required components to build an Air Quality Node.

In einem der Experimente habe ich mit zwei CO₂-Sensoren und einem MOX-Sensor gemessen.
Bei den verwendeten CO₂-Sensoren handelte es sich um den SCD30 (NDIR) und den SCD41 (PASense), die von der Schweizer Firma Sensirion entwickelt wurden. Der MOX-Sensor war ein SGP30, ebenfalls von Sensirion.
Da neben den menschlichen Ausdünstungen keine weiteren Stoffe vorhanden waren, folgen die Messwerte des MOX-Sensors SGP30 auch denen der beiden CO₂-Sensoren SCD30 und SCD41.
Die Luftqualitätsmessung mit den kostengünstigeren MOX-Sensoren zeigt überall dort, wo die Atemluft und die menschlichen Ausdünstungen dominieren, mit der reinen CO₂-Konzentration vergleichbare Ergebnisse. Abweichungen treten in verschmutzten Umgebungen (z.B., mit Formaldehyd) auf, aber dieses generelle Problem erfordert eine separate Lösung.
RAKwireless WisBlock bietet alle erforderlichen Komponenten für den Aufbau eines Luftqualitätsknotens.

*RAKId*	*WisBlock Name*
RAK19007	RAK19007 WisBlock Base Board 2nd Gen
RAK11200	RAK11200 is a WisBlock Core module based on Espressif ESP32-WROVER
RAK14001	RAK14001 WisBlock RGB LED Module
RAK12047	RAK12047 WisBlock VOC Sensor based on MOx-based Sensirion Gas Sensor SGP40
RAK1901	RAK1901 WisBlock Sensor based on Sensirion SHTC3
RAKBox-B3	WisBlock RAKBox-B3 Enclosure

From the hardware side, there are some issues:
– I had to change the orientation of the base due to the used core. Therefore, I cannot use all screws for fixing the baseboard RAK19007.
– The USB Type C needs more room than the enclosure offers. Therefore, powering via USB is impossible, and I power the device via the solar connector and 5 V DC.

The following libraries support the sensors and the RGB LED:

Was die Hardware betrifft, so gibt es einige Probleme:
– Ich musste die Ausrichtung des Baseboards aufgrund des verwendeten CPU-Moduls ändern. Daher kann ich nicht alle Schrauben zur Befestigung des Baseboards RAK19007 verwenden.
– Der USB Typ C benötigt mehr Platz als das Gehäuse bietet. Daher ist eine Stromversorgung über USB nicht möglich, und ich versorge das Gerät über den Solaranschluss und 5 V DC.

Die folgenden Bibliotheken unterstützen die Sensoren und die RGB-LED:

#include "SHTSensor.h" //http://librarymanager/All#arduino-sht
By:Johannes Winkelmann
#include "SparkFun_SGP40_Arduino_Library.h" //http://libraryma
nager/All#SparkFun_SGP40
#include <NCP5623.h> //http://librarymanager/All#NCP5623 By:
RAKWireless

For SGP40, there are different libraries available. I want to use the VOC index (iVOC) supported by the Sparkfun library above.
The color of the RGB LED signalizes different ranges of iVOC as defined in the following note from Sensirion.
In my program RAK11200_sensors.ino, the iVOC controls the color of the LED inside the enclosure. The four images of the RAKBox-B3 Enclosure show the signalization of the iVOC ranges:

Für SGP40 gibt es verschiedene Bibliotheken. Ich möchte den VOC-Index (iVOC) verwenden, der von der obigen Sparkfun-Bibliothek unterstützt wird.
Die Farbe der RGB-LED signalisiert verschiedene Bereiche von iVOC, wie in der folgenden Notiz von Sensirion definiert.
In meinem Programm RAK11200_sensors.ino steuert der iVOC die Farbe der LED im Inneren des Gehäuses. Die vier Bilder des RAKBox-B3-Gehäuses zeigen die Signalisierung der iVOC-Bereiche:

*LED Color*	*iVOC Range*
Off	0 … 9
Green	10 … 199
Yellow	200 … 399
Red	> 400

Additionally, the Air Quality Node sends messages to WhatsApp, signalizing the need for ventilation or not.
This way, you will have a visual signalization of the air quality near the Air Quality Node and a message about the need for ventilation on your smartphone everywhere.

Außerdem sendet der Luftqualitätsknoten Nachrichten an WhatsApp, die signalisieren, ob
gelüftet werden muss oder nicht.
Auf diese Weise haben Sie eine visuelle Signalisierung der Luftqualität in der Nähe des Air Quality Node und eine Nachricht über die Notwendigkeit des Lüftens auf Ihrem Smartphone überall.

WiFi is used for the HTTP POST request to send
messages to Whatsapp.

For communication, RAKwireless offers BLE, and LoRaWAN as alternative solutions.

Adding a relay can control a ventilator depending on
the iVOC.

WiFi wird für die HTTP POST-Anfrage zum Senden von Nachrichten an Whatsapp.

Für die Kommunikation bietet RAKwireless BLE und LoRaWAN als alternative Lösungen an.

Das Hinzufügen eines Relais kann einen Ventilator in Abhängigkeit vom iVOC steuern.

As an alternative to the hardware used here RAKwireless offers the Air Quality Kit based on Bosch BME680.

Als Alternative zu der hier verwendeten Hardware bietet RAKwireless das Air Quality Kit auf Basis des Bosch BME680 an.

2022-11-29/CK

Banana Pi BPI-PicoW-S3B

Der weit verbreitete Raspberry Pi Pico(W) hat mit dem Banana Pi BPI-PicoW einen interessanten Compagnion bekommen. Baut der Raspberry Pi Pico auf dem ebenfalls von der Raspberry Pi Foundation entwickelten Mikrocontroller RP2040 auf, nutzt der BPI-PicoW einen ESP32-S3 von Espressif. Beides sind Dual-Core Controller mit einer guten Ausstattung an Peripherie. Die folgende Tabelle zeigt die Gemeinsamkeiten und Unterschiede beider Boards.

Die programmierbare IO des RP2040 ist ein Alleinstellungsmerkmal des Raspberry Pi Pico und ist deshalb im BPI-PicoW nicht zu finden.

Im ESP32-S3 sind zwei ULP-Copozessoren vorhanden, die ein Ultra Low Power Design unterstützen. Der Strombedarf im Deep Sleep liegt beim ESP32-S3 bei niedrigen 8 uA, die vom Raspberry Pi Pico nicht erreicht werden. Ähnlich sieht es bei der Performance der CPU, dokumentiert durch die Coremark Resultate, aus.

Beim Raspberry Pi Pico steht derzeit nur WiFi zur Verfügung. BLE ist für einen späteren Release angekündigt.

Der BPI-PicoW kann über AliExpress bestellt werden. Der Preis liegt derzeit bei € 5.74.

Der Preis des Raspberry Pi PicoW liegt bei € 7.20 (berrybase.de). Beide Boards sind somit sehr kostengünstig und eine leistungsfähige Basis für IoT-Projekte.

Abschliessend finden Sie noch die Pinbelegungen beider Boards zum Vergleich.

2022-10-04/CK

ESP32-Familie

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
ESP32-C6	32-bit RISC-V Processor	Single-Core	512 KB RAM, 320 KB ROM, 16 KB	WiFi, BT 5.3 (LE), BT Mesh, Thread 1.3, Zigbee 3.0, 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-C6	160 MHz	nanoESP32-C6	330.69	2.067
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 folgendermaßen 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.

2024-04-09/CK

Solar Power System für IoT-Knoten

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.

Das bedeutet, dass das System länger in Betrieb bleibt, insbesondere unter extremen Bedingungen. Außerdem muss man sich um den Transport des Systems viel weniger Sorgen machen. Weitere Detail finden Sie unter https://blog.voltaicsystems.com/things-network-presentation-using-solar-to-power-a-lora-node/.

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 (t_DS >> t_op) 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 I_op = 110 mA, t_op = 4 s, I_DS = 25 uA und t_DS = 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.

2022-02-19/CK

Mobile Datenerfassung über LTE-M

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.

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 I²C-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.

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ü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.

Das hier verwendete Programm ist ebenfalls auf GitHub unter ckArduino/ESP32/M5Stack_MQTT_Client1 at main · ckuehnel/ckArduino · GitHub abgelegt.

2022-08-08/CK

LiLyGo T-Display ePaper 1.02″

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:

ePaper 1.02″ Auflösung: 128×80
Mikrocontroller ESP32-D0WDQ6-V3
4 MB FLASH
TP4054 Linear Li-lon Battery Charger
Boot, Reset und User Key
RGB-LED
On-board WiFi Antenne
Typ-C USB für T-U2T
JST 2pin 1,25mm Batterieanschluss
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.

2022-06-22/ck

IoT-Knoten mit 01Space ESP32-C3-0.42LCD

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 I²C- und SPI-Bus oder seriell (UART) angeschlossen werden.

Ü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

Hello World
by ESP32-C3
RISC-V MCU

durch das Programm 01Space_ESP32-C3_HW.ino.

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.

2022-07-27/CK (wird noch erweitert)

LilyGo T-OI plus RISC-V ESP32-C3

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.

Zur externen Erweiterung stehen SPI- und I²C-Bus sowie eine UART-Schnittstelle zur Verfügung. Der Grove Connector, auf den dier I²C-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.

Ich habe mit dem LilyGo T-OI plus Board experimentiert und stelle Ihnen die Resultate vor. Die Quelltexte finden Sie auf Github unter https://github.com/ckuehnel/ckArduino/tree/main/ESP32-C3.

Abfrage M5Stack ENV.II Unit durch ESP32-C3

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.

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.

2022-08-26/CK

StackyPi

Verbinde Raspberry Pi HATs mit dem Pi Pico

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

Ein Datenblatt finden Sie hier.

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.

#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h>

// Coral ESB Pin Definitions
#define DC 26
#define RST 22
#define CS 5
#define MOSI 3
#define CLK 2

#define SCREEN_WIDTH 128
#define SCREEN_HEIGHT 32

Adafruit_SSD1306 display(SCREEN_WIDTH, SCREEN_HEIGHT, MOSI, CLK, DC, RST, CS);

I²C Bus Scan

Ich habe das beklannt I²C Scanprogramm auf die beiden I²C-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 I²C-Bus-Devices zugeordnet:

*I²C Addr*	*Device*
0x30	Crypto Chip ATECC608
0x40	Temperatur-/Feuchtesensor HDC2010
0x45	Lichtsensor OPT3002
0x49	Analog/Digital-Umsetzer TLA2021
0x76	Barometrischer Drucksensor BMP280

Temperatur-/Feuchtesensor HDC2010

Das auf der sSense-HDC2010 Library aufbauenden Programm StackyPi_ESB_HDC2010.ino fragt den Low Power Humidity and Temperature Digital Sensor HDC2010 von TI ab und bringt die Messwerte zur Anzeige gebracht.

Lichtsensor OPT3002

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.

2022-05-10/CK

Messung radioaktiver Strahlung

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.

PiGI – Raspberry Pi Geiger-Müller Interface