Air Quality Visualization

Looking for a suitable visualization of the measured values of the RAKwireless Air Quality Node, I found the app MyAmbience from Sensirion.

Primarily, the app is used to test Sensirion’s smart gadgets, which are connected to a mobile device via Bluetooth, in order to be able to visualize the collected measured values. With MyAmbience you can:
• View live data from all Sensirion gadgets.
• Track their history and export the data.
• Compare data from different devices.

But, here the inclusion of self-created sensor nodes is more important. For this purpose, Sensirion offers the Arduino BLE Gadget Library (https://github.com/Sensirion/arduino-ble-gadget), an Arduino library for integrating the data of self-created sensor nodes based on the ESP32 platform.

I have used this library in the application RAK11200_Sensors_BLE.ino. The following screenshots show the visualized data.

The first screenshot shows the dashboard with the values for temperature, relative humidity, and AQI (VOC). The second screenshot shows the AQI before and after ventilation.

If a sensor node is powered by a battery, then knowing the state of charge of this battery is of outstanding importance. Sensirion has announced that it will adapt the MyAmbience app to this end in spring 2023.

Auf der Suche nach einer geeigneten Visualisierung der Messwerte der RAKwireless Air Quality Node habe ich die App MyAmbience von Sensirion gefunden.

In erster Linie dient die App dem Test von Sensirions Smart Gadgets, die über Bluetooth mit einem Mobilgerät verbunden werden, um die erhobenen Messwerte visualisieren zu können. Mit MyAmbience können Sie:
• Live-Daten von allen Sensirion Gadgets anzeigen.
• Deren Verlauf verfolgen und die Daten exportieren.
• Daten verschiedener Geräte vergleichen.

Hier ist aber das Einbeziehen von selbsterstellten Sensorknoten wichtiger. Dafür bietet Sensirion mit der Arduino-BLE-Gadget Library (https://github.com/Sensirion/arduino-ble-gadget) eine Arduino-Library zur Integration der Daten selbst erstellter Sensorknoten auf Basis der ESP32-Plattform an.

Ich habe diese Library in der Anwendung RAK11200_Sensors_BLE.ino verwendet. Die folgenden Screenshots zeigen die visualisierten Daten.

Im ersten Screenshot ist das Dashboard mit den Werten für Temperatur, rel. Luftfeuchte und dem AQI (VOC) gezeigt. Im zweiten Screenshot ist der Verlauf des AQI vor und nach dem Lüften gezeigt.

Wird ein Sensorknoten von Batterie betrieben, dann ist die Kenntnis des Ladezustands dieser Batterie von herausragender Bedeutung. Sensirion hat angekündigt, im Frühjahr 2023 die App MyAmbience dahingehend zu erweitern.


2023-01-16/CK

CO2-Ampel bleibt aktuell

Die Corona-Inzidenzen weisen einen deutlichen Abwärtstrend auf, allerdings halten Erkältungskrankheiten, die saisonale Grippe, das RS-Virus u.a. den Krankenstand hoch. Infektionen in einer aerosolbelasteten Umgebung bleiben als unabhängig von Corona weiterhin aktuell.

Im Blogbeitrag Luftqualität mit NDIR- und MOX-Sensoren messen hatte ich den Einsatz unterschiedlicher Sensorik zur Bestimmung der Luftqualität beschrieben. Der Markt zeigt in rascher Folge Neuentwicklungen im Bereich Sensorik und Luftreinigung. Nicht immer sind die Spezifikationen klar ausgewiesen.

Mit wenig Aufwand können bereits sehr geeignete Messeinrichtungen zur Beurteilung der Luftgüte erstellt werden. Ich zeige Ihnen hier eine sehr kompakte Variante eines Messgeräts zur Erfassung von Temperatur, relativer Luftfeuchte und CO2-Gehalt der Umgebungsluft für den Einsatz in Innenräumen bestehend aus

  • M5Stack AtomS3 Controller und
  • M5Stack CO2 Unit with Temperature and Humidity Sensor (SCD40)

Beide Komponenten können die in den Bildern gezeigte kompakte Baugruppe bilden. Sensor und Controller sind durch ein kurzes Grove-Kabel verbunden. Die Spannungsversorgung erfolgt über ein USB-TypeC-Kabel aus einem kleinen Steckernetzteil.

CO2: 400 ppm – 1000 ppmCO2: 1000 ppm – 2000 ppmCO2: > 2000 ppm

Der SCD40 von Sensirion zeigt für die hier betrachtete Anwendung sehr gute Eigenschaften und mit der M5Stack CO2 Unit ist dieser Sensor auch sehr einfach handhabbar. Als Controller kann jeder nahezu beliebige Controller mit einem I2C-Interface eingesetzt werden. Den leistungsmäßig vollkommen überdimensionierten AtomS3 (Basis ESP32-S3) habe ich wegen der passenden Bauform und des integrierten Displays hier eingesetzt.

Auf dem Display werden CO2-Konzentration sowie Temperatur und relative Luftfeuchte angezeigt. Der Displayhintergrund kennzeichnet farblich die unterschiedlichen Belastungsstufen (Zuordnung unter dem jeweiligen Bild).

Wenn Sie Interesse am Nachbau haben, dann finden Sie das Programm unter https://github.com/ckuehnel/Arduino2023/tree/main/M5Atom/M5AtomS3_SCD40_1.

Die M5Stack CO2 Unit finden Sie im M5Stack Shop zu $ 33.90 und den M5Stack AtomS3 zu $ 15.50. Einheimische Distributoren werden die Komponenten auch zur Verfügung haben.

In der zweiten Auflage meines Arduino Buchs sowie im zugehörigen Repository und meinem Arduino Blog finden Sie weitere Vorschläge zur Überwachung des Raumklimas mit interessanter Sensorik.


2023-01-16/CK

Wemos LOLIN ESP32-S3 Pro

Im Blogbeitrag zur ESP-Familie hatte ich die Erweiterungen der ESP32-Familie durch ESP32-S2, ESP32-S3 und ESP32-C3 betrachtet.

Neben dem ESP32-S3-DevKit von Espressif war der Banana Pi BPI-PicoW-S3B ein interessantes Board, das mit dem Wemos Lolin S3 Pro ESP32-S3 WROOM wiederum einen interessanten Companion bekommt. Das Wemos Lolin S3 Pro Entwicklungsboard ist mit 16 MB QSPI-Flash und 8 MB PSRAM ausgestattet und nutzt den ESP32-S3 WROOM von Espressif. Außerdem weist das Board verschiedene I/O sowie ein SPI-Port zur Ansteuerung eines TFT-Displays, einen microSD-Card-Slot und ein LOLIN-I2C-Anschluss auf. Über zwei 16-polige Stiftleisten sind ADC, DAC, I2C, SPI, UART usw. erreichbar. Ein USB-Typ-C-Anschluss dient der Spannungsversorgung, dem Programm-Upload und der seriellen Kommunikation sowie Unterstützung für einen LiPo-Akku mit 500 mA Ladeleistung. Ich habe es von https://arduino-projekte.info/ bezogen.

Die folgenden Bilder zeigen Front- und Rückseite des Wemos Lolin S3 Pro.

Wemos LOLIN ESP32-S3 Pro

Das Board kann mit der Arduino IDE programmiert werden. Im folgenden Bild ist die Konfiguration über das Menu Tools gezeigt.

Konfiguration über das Menu Tools

Beim ESP32-S3 kommt der leistungsstärkere Controller Xtensa 32-bit LX7. Mit dem CoreMark Benchmark habe ich auch für dieses ESP32-Derivate einen Performancetest gemacht. Im Screenshot ist das Ergebnis ablesbar. Mit einem CoreMark von 450 bestätigt er das bereits für das ESP32-S3-DevKitC-1 gewonnene Ergebnis.

Durch die Möglichkeit, über das SPI-Port ein Display und über das I2C-Port sehr einfach externe Sensorik anschließen zu können, ist das Board ein interessanter Kandidat für IoT-Anwendungen.


Vom gleichen Hersteller wird ein 2.4″ TFT mit den folgenden technischen Daten angeboten:

  • 2.4” diagonal LCD TFT display
  • 320 x 240 pixel
  • TFT Driver IC: ILI9341
  • Touch Screen controller IC: XPT2046
  • Compatible with D1 mini, D1 mini Pro, D32 Pro, S3 Pro.

Bei Aliexpress habe ich es für weniger als € 12 kaufen können.

Wie schon beim AZ-Touch mit ESP32 habe ich den Grafik-Benchmark (https://ckarduino.wordpress.com/2020/10/13/az-touch-esp32-grafiktest/) laufen lassen, der die folgenden Ergebnisse gebracht hat:

Die Daten sind von unterschiedlichen Testruns.

Das Programm für die hier gezeigte Kombination aus LOLIN S3 Pro und LOLIN TFT-2.4 ist auf Github abgelegt.

Interessant am vorgestellten Display ist die Möglichkeit, das LOLIN S3 Pro Board direkt mit einem zum Lieferumfang gehörenden 10-pol. Kabel zu verbinden oder einen Wemos D1 direkt auf der Rückseite einstecken zu können.

Über eine QWIC-Connector und ein ebenfalls zum Lieferumfang gehörendes 4-pol. Kabel lassen sich Sensoren anschließen, wodurch in Handumdrehen ein IoT-Knoten erstellt ist.


2023-01-28/CK

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.

RAKIdWisBlock Name
RAK19007RAK19007 WisBlock Base Board 2nd Gen
RAK11200RAK11200 is a WisBlock Core module based on Espressif
ESP32-WROVER
RAK14001RAK14001 WisBlock RGB LED Module
RAK12047RAK12047 WisBlock VOC Sensor based on MOx-based
Sensirion Gas Sensor SGP40
RAK1901RAK1901 WisBlock Sensor based on Sensirion SHTC3
RAKBox-B3WisBlock RAKBox-B3 Enclosure
RAK19007 installed in RAKBox-B3

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 ColoriVOC Range
Off0 … 9
Green10 … 199
Yellow200 … 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.

BPI-PicoW Pin Out
Raspberry Pi Pico W Pin Out

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.

SOCCPUCoresMemorySpecial
ESP32-S2Xtensa 32-bit LX7Single-Core128 KB ROM, 320 KB SRAM, 16 KB RTC SRAMLCD Interface, Camera Interface, Touch Sensor,
WiFi, BT 5.0, Native USB
ESP32-S3Xtensa 32-bit LX7Dual-Core384 KB ROM, 512 KB SRAM, 16 KB RTC SRAMVector Instructions Support,
WiFi, BT 5.2 (LE), Native USB
ESP32-C332-bit RISC-V ProcessorSingle-Core400 KB RAM, 384 KB ROM, 8 KB RTC SRAMWiFi, 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:

CPUClockDevKitCoreMarkCoreMark/MHz
ESP32-C3160 MHzBeetle ESP32-C3304.151.9
ESP32-S2240 MHzESP32-S2-DevKitM-1361.471.5
ESP32-S3240 MHzESP32-S3-DevKitC-1451.301.9
ESP32240 MHzESPduino32 w/ ESP-WROOM-32336.361.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.


2022-09-26/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 (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 Libaries zur Verfügung stehen. Der Langzeittest wird also mit dem erweiterten Programm weitergeführt. Es werden die Spannung am LIC und die Aussentemperatur 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 Schliessen 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 zuviele (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 zuliess. Der Spannungsverlauf zeigte sich gemäss 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 Massnahmen erreicht werden:

  • Optimierung des Standortes resp. bessere Ausrichtung zur Sonneneinstrahlung
  • Ersatz der WiFi-Kommunikation durch ESPNow oder LoRaWAN/LoRaP2P
  • Vergrösserung des Sendeintervalls

Durch die Optimierung des Standortes konnte ein ordentliches Nachladen erreicht werden, auch wenn nicht jeden Tag optimale Sonneneinstrahlung vorgeherrscht hat.


2022-11-12/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.

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, anschliessend durch Trennen der USB-Verbindung auf Batteriebetrieb umgeschaltet und schliesslich 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 schliesslich GPS und ENV.II Sensor wieder aktiv.

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 Sateliten blinkt die blaue LED im Takt von 2 Sekunden. Hier ist nur ein 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-Scenario 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 den 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 zuverwendete 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 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

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)