Python gehört schon seit Jahren zu den beliebtesten Programmiersprachen überhaupt. Die von Python zur Verfügung gestellten Eigenschaften stellen Anforderungen an die Hardware, die von Mikrocontrollern nicht ohne Weiteres erfüllt werden können. Ein PC kann das. Ein Raspberry Pi mit Linux als Betriebssystem kann das, ein Mikrocontroller wie ein Espressif ESP32, ein Nordic nRF52840, ein STM32 oder eines der verschiedenen Arduino-Boards hingegen nicht.
Das hat Damien P. George, einen Physiker und Softwareentwickler aus Cambridge (UK), im Jahr 2013 dazu bewogen, MicroPython zu entwickeln. Ziel der Entwicklung von MicroPython war, eine voll funktionsfähige, aber kompakte Version von Python 3 zu schaffen, die auf Mikrocontrollern (wie STM32, ESP8266, ESP32, RP2040 usw.) läuft. Mit diesem Buch werden Sie die Gemeinsamkeiten und Unterschiede von Python und MicroPython kennenlernen und schließlich in der Lage sein, mit MicroPython auf recht kleinen Mikrocontrollern zu arbeiten.
Aufbau eines BLE-Netzwerks für diverse Umwelt-Sensoren
Ziel des Projekts ist der Aufbau eines skalierbaren, extrem stromsparenden Sensor-Netzwerks zur Überwachung von Umgebungsdaten. Der NanoBeacon IN100 SoC von InPlay Inc. kommt im SparkFun NanoBeacon Board – IN100 und im DFRobot Fermion BLE Sensor Beacon zum Einsatz.
Das SparkFun NanoBeacon Board – IN100 kann durch Sensoren mit einem QWIIC-Interface erweitert werden. Beim Einsatz der Fermion-Baureihe von DFRobot können verschiedene Sensoren (u.a. LM35, SHT40, SGP40) direkt mit dem Fermion BLE Sensor Beacon kontaktiert werden.
In beiden Fällen ist eine drahtlose Vernetzung der so gestalteten BLE-Sensoren möglich. Die übermittelten Daten können von einem zentralen ESP32-Gateway ausgewertet und zur Langzeitanalyse an eine IoT-Plattform übermittelt werden.
Ich verwende MicroPython für die Programmierung des ESP32-Gateways. Auf der Sensor-Seite kommt der Fermion BLE Sensor Beacon zum Einsatz. Datacake dient in bewährter Weise als IoT-Plattform.
Systemarchitektur & Datenfluss
Das System nutzt eine dreistufige Architektur, um maximale Effizienz und Reichweite zu erzielen:
Sensor-Knoten (Edge): Mehrere Fermion BLE-Module fungieren als eigenständige Sender (Beacons). Sie erfassen analoge Signale (z-B. LM35) sowie digitale I²C-Daten (z.B. SHT40 für Feuchte/Temp, SGP40 für Luftqualität). Die Daten werden ohne festes Pairing direkt in die BLE Manufacturer Data (Advertising-Pakete) eingebettet.
Zentral-Gateway (Processing): Ein ESP32 scannt unter MicroPython kontinuierlich das BLE-Spektrum. Er identifiziert die Fermion-Knoten anhand ihrer IDs, extrahiert die Rohdaten aus den Manufacturer-Bytes und berechnet die physikalischen Einheiten. Die aktuellen Messwerte werden unmittelbar auf einem OLED-Display (SSD1306) am ESP32 angezeigt.
Visualisierung der aufbereiteten Daten und via MQTT an das Datacake-Dashboard versendeten Daten, wo sie für Monitoring, Alarme und Historien-Analysen zur Verfügung stehen.
Besondere Merkmale
Ultra-Low Power: Durch den Verzicht auf eine dauerhafte BLE-Verbindung (Broadcasting) erreichen die Sensor-Knoten Batterielaufzeiten im Bereich von Monaten bis hin zu Jahren.
Skalierbarkeit: Das System kann problemlos um weitere Knoten ergänzt werden, da der ESP32 als passiver Empfänger eine Vielzahl von Sendern gleichzeitig verarbeiten kann.
Robustheit: Die Trennung von Erfassung (Fermion) und Verarbeitung (ESP32/Cloud) ermöglicht einen stabilen Betrieb auch in komplexen Umgebungen.
Aufbau eines Sensor-Knotens
Der Fermion BLE Sensor Beacon ist ein drahtloser Beacon, der Sensordaten über Bluetooth sendet. Ein integrierter 11-Bit-ADC kann zur Erfassung analoger Messwerte eingesetzt werden und über das I2C-Interface können Sensoren mit I²C-Interface ausgelesen werden. Auf die vom Beacon gesendeten Sensordaten kann innerhalb der Sendereichweite des Beacons mit Mobiltelefonen, Mikrocontrollern und anderen Geräten, die den BLE-Empfang unterstützen, zugegriffen werden.
Fermion BLE-Sensor-Beacons integrieren stromsparende Bluetooth 5.3-Technologie mit selbstkonfigurierbaren Datenformaten wie iBeacon, Eddystone, benutzerdefiniert und mehr. Die BLE-Sensor-Beacons können mit einer CR2032-Knopfzellenbatterie betrieben werden. Es stehen bis zu sechs konfigurierbare GPIOs zur Verfügung, die alternativ auch zu zwei unabhängigen I²C-Schnittstellen konfiguriert werden können.
Fermion BLE-Sensor-Beacon
Das Datenformat der Beacon-Übertragung, der Inhalt der Übertragung, das Übertragungsintervall usw. können über die grafische Benutzeroberfläche NanoBeacon Config Tool konfiguriert werden, ohne dass für die Fertigstellung eines Bluetooth-Beacons die Programmierung von Code erforderlich ist.
NanoBeacon Config Tool
Für einen ersten Versuch wurde der Beacon so konfiguriert, dass die interne Temperatur (Chiptemperatur) mit zwei Byte in den Manufacturer-Daten verankert wurde. Im NanoBeacon Config Tool ist das mit den Bytes 13 und 14 zu sehen,
Für die Visualisierung der empfangenen Daten verwende ich das nRF-Tool. Im folgenden Screenshot sind die Manufacturer-Daten markiert. Nach dem Hersteller-Code 0x0505 stehen die Bytes 0x0A3F = 2623D = 26.23°C. Von einem BLE-Scanner bzw. BLE-Gateway sind die übermittelten Daten nur noch zu parsen und jegliches Geheimnis ist gelüftet.
Manufacturer Data
Zu Beginn habe ich der Einfachheit halber einen XIAO-ESP32-C3 auf einem XIAO-Erweiterungsboard als BLE-Scanner eingesetzt. Installiert ist die aktuelle MicroPython-Firmware v1.27.
Die MicroPython-Anwendung scannt die Umgebung nach Bluetooth-Signalen, die von Geräten wie Smartwatches, Fitness-Trackern, Sensoren oder Beacons ausgesendet werden, und identifiziert alle BLE-Geräte in Reichweite, die im Advertising-Modus Signale aussenden. Sie misst die Signalstärke (RSSI) und ruft Metadaten, darunter auch die Manufacturer-Daten, ab. In den Manufacturer-Daten ist hier der Temperaturmesswert verankert. Auf dem OLED-Display des XIAO-Erweiterungsboards werden diese Daten schließlich zur Anzeige gebracht.
BLE-Gateway mit ESP32-C3
Für den Einsatz in Innenräumen eignet sich das RAKBox-B3-Gehäuse, da es für die Sensorik gut belüftet ist und ausreichend Schutz der Komponenten sichert.
RAKBox-B3 Indoor Enclosure
In der nächsten Projektphase wird das System um Fermion-Sensoren sowie kommerzielle BLE-Geräte ergänzt. Dabei entwickeln wir den BLE-Scanner zu einem BLE-MQTT-Gateway weiter, um die erfassten Daten zur Visualisierung an die Datacake-Plattform zu übertragen.
Parallel dazu arbeite ich an einem Fachbuch über MicroPython im IoT-Umfeld. Darin finden Sie – neben einer fundierten Einführung in MicroPython für gängige Mikrocontroller – praxisnahe Anwendungen auf Basis von WiFi, Ethernet, ESP-Now und BLE.
Der Badger2350 von Pimoroni ist ein kompaktes, stromsparendes eInk-Badge-Board, das speziell für portable Anzeigen und langlebige IoT-Projekte entwickelt wurde. Statt auf hohe Rechenleistung oder Multimedia setzt die Hardware konsequent auf Effizienz, gute Lesbarkeit und extrem niedrigen Energieverbrauch – Eigenschaften, die in vielen Maker- und IoT-Szenarien entscheidend sind.
Durch das integrierte eInk-Display lassen sich Informationen dauerhaft anzeigen, ohne kontinuierlich Strom zu verbrauchen. In Kombination mit einfacher Programmierung in MicroPython, einer aktiven Entwickler-Community und zahlreichen Beispielprojekten eignet sich das Board sowohl für schnelle Prototypen als auch für produktive Anwendungen. Ob Statusanzeigen im Smart Home, digitale Labels oder batteriebetriebene Sensorstationen – der Badger2350 ist besonders dort interessant, wo Informationen sichtbar bleiben sollen, ohne dass ständig Energie fließt.
Pimoroni Badger2350
Badger2350 baut auf der folgenden Hardware auf:
2.7″ eInk-Display mit 264 x 176 Pixeln und vier Graustufen
Raspberry Pi RP2350A (Dual Arm Cortex M33 @ 250 MHz mit 520 KB 0SRAM)
16 MB Flash, 8 MB PSRAM
Raspberry Pi RM2 module (CYW43439) für IEEE 802.11 b/g/n WLAN & BT
1000mAh LiPo battery:
PCF85063A RTC für WakeUp von Sleep
Polycarbonate case
4-zone mono LED case lighting
Buttons: 5 User, Reset & Home
Connectors: USB-C zur Spannungsversorgung und Programm-Upload, I2C-Connector (Qwiic/STEMMA QT)
Für die Programmierung in MicroPython bietet Pimoroni eine spezielle Firmware an, die unter https://badgewa.re/docs beschrieben ist.
Ich habe einen ersten Test unternommen, um mit uname() dem System Informationen zu entlocken und das Programm in den bestehenden Launcher einzubinden.
Menu mit zusätzlicher AppApp uname
Wie Sie aus den beiden Abbildungen sehen, hat das der Dokumentation folgend auch alles funktioniert. Eine App kann in den Launcher eingebunden werden und dann von da aufgerufen werden, oder aber als main.py als eigenständige App arbeiten. Ich habe hier den ersten Weg gewählt.
Mir den Möglichkeiten, die der Badger2350 bietet, sind Anwendungen aus den folgenden Bereichen denkbar:
Monitoring von Umweltdaten mit lokalem Statusdisplay
Solarbetriebene Sensorstationen
Energieverbrauch (z. B. PV-Ertrag oder Stromzählerdaten)
MQTT-Dashboard für wichtige Zustände
Inventar-Tracking mit QR-Code auf eInk
Statusanzeigen für Funk-Gateways
u.a.m.
Der Badger2350 überzeugt vor allem durch seine klare Ausrichtung auf stromsparende Anzeige- und IoT-Anwendungen. Seine Stärken spielt das Board überall dort aus, wo Daten selten aktualisiert werden, aber dauerhaft sichtbar sein sollen: Statusanzeigen, Sensordashboards, digitale Labels oder portable Informationssysteme sind typische Einsatzfelder. Weniger geeignet ist es dagegen für grafikintensive Anwendungen oder Projekte mit schnellen Display-Updates.
KI ist in unseren Alltag eingedrungen und hilft an der einen und anderen Stelle. Um KI zu nutzen ist es aber nicht erforderlich, vor dem PC zu sitzen und Kontakt mit einer KI-Plattform, wie ChatGPT, Gemini o.a. aufzunehmen, sondern kann bestimmt Aufgaben bereits mit Mikrocontrollern automatisieren.
So können Sie beispielsweise einen Prompt erstellen, der Ihnen beim Zubettgehen die zu erwartenden Strassenverhältnisse am kommenden Morgen abfragt o.ä.
Alles, was dazu erforderlich ist, zeigt die folgende Abbildung. Natürlich können Sie den ESP32-S2 noch mit einem Display ausstatten, damit die Antwort adäquat präsentiert wird.
Ich habe einen mit MicroPython ausgestatteten ESP32-S2 mit Gemini verbunden und kann eine Anfrage senden, die von Gemini beantwortet wird.
Für das bevorstehende Handballspiel D gegen DK habe ich die (nicht ganz ernstgemeinte) Frage nach dem Sieger gestellt. Die Antwort sehen Sie in der Ausgabe über die Console.
Ich werde mir das Spiel heute Abend anschauen.
Das Resultat war aus deutscher Sicht ernüchternd – Gratulation an Dänemark zu einer starken Leistung. #Handball #EM2026
Auch Gemini hat eine Meinung dazu, die sich bei mehrfachen Anfragen aber durchaus unterscheidet:
Cardputer ADV ist ein Controller im Kreditkartenformat, ausgestattet mit einem M5Stack Stamp-S3A-Coremodul (ESP32-S3FN8). Er verfügt über ein 1,14-Zoll-LCD und eine einfache Tastatur mit 56 Tasten. Der interne 1750-mAh-Lithium-Akku gewährleistet eine gute Akkulaufzeit. Ein 6-Achsen-Bewegungssensor BMI270, ein Infrarot-Sender, ein microSD-Slot sowie ein Grove-Anschluss bilden die Peripherie und ein EXT 2.54-14P-Erweiterungsbus ist zum Anschluss von Sensoren und anderen Peripheriegeräten vorgesehen.
Cardputer ADV
Beim Einsatz als Meshtastic-Knoten wird über diesen Erweiterungsbus ein Cap LoRa868 angeschlossen.
Cap LoRa868
Cap LoRa868 ist ein Erweiterungsmodul für LoRa- und GNSS-Kommunikation. Das LoRa-Modul basiert auf einem SX1262, ist mit einer externen SMA-Antenne ausgestattet und unterstützt das Frequenzband 868 MHz bis 923 MHz. Das GPS-Modul basiert auf einer AT6668-Lösung und verfügt über eine integrierte Keramikantenne. Es bietet Multisatellitenunterstützung – kompatibel mit GPS, BDS, GALILEO, GLONASS, QZSS und SBAS – für maximale Flexibilität.
Zur Installation der Meshtastic-Firmware ist es am einfachsten, den M5Burner von M5Stack zu verwenden. M5Burner ermöglicht Benutzern das einfache Flashen verschiedener Firmware-Versionen auf unterschiedliche Geräte. Cap LoRa868 sollte noch nicht installiert sein. Der M5Burner kann von der Website https://docs.m5stack.com/en/guide/lora/meshtastic/cardputer_adv heruntergeladen werden.
Nach der Installation des M5Burners kann die Meshtastic Firmware für den Cardputer ADV heruntergeladen und auf das Target übertragen werden. Die Details sind auf der o.a. Website beschrieben.
Ist die Meshtastic-Firmware installiert, meldet sich der neue Knoten, wie in der ersten Abbildung gezeigt, und kann in der üblichen Weise konfiguriert werden.
Arduino UNO-Q, die neueste Ankündigung von Arduino, war heute in meinem Briefkasten.
Nach meinen Experimenten mit dem Arduino Yun bin ich gespannt, wie sich diese Kombination aus Mikrocontroller und Linux-Device behaupten wird.
Die Installation der zugehörigen IDE Arduino App Lab ist erstmal sehr einfach. Die komplexe Installation läuft komplett im Hintergrund und schliesslich wird man aufgefordert seinen Arduino UNO-Q über USB mit dem PC zu verbinden.
Im Editor sind die o.a. Fenster sichtbar. Sketch.ino bildet die Arduino Seite ab, während main.py die Python Anwendung auf der Linux-Seite zeigt.
Die Verbindung der beiden Umgebungen übernimmt die sogenannte Bridge.
Ausgelesen werden von der Seite open-meteo.com das aktuelle Wetter und eine entsprechendes Icon auf dem Matrixdisplay angezeigt.
Auf diese Weise können sehr einfach von Sensoren erfasste Messwerte auf den unterschiedlichen Plattformen visualisiert bzw. abgespeichert werden, oder mit Hilfe aus dem Internet bezogener Informationen auf konkrete Hardware eingewirkt werden.
Mit dem Arduino UNO-Q steht eine interessante Plattform für IoT- und KI-Anwendungen zur Verfügung.
Neben der Programmierung des Arduino UNO Q über das Arduino App Lab kann auf die CPU des Linux-Devices auch über Secure Shell (SSH) zugegriffen werden.
Damit können Sie unter anderem:
Auf die Shell des Boards zugreifen und Vorgänge auf dem Board über das Netzwerk starten.
Dateien vom lokalen Computer über das Netzwerk auf das Board übertragen (mit SCP).
Zum Test habe ich mit dem Editor Nano das Shell Script info erstellt, welches Informationen zur installierten Linux-Distribution ausgibt.
Ausführung von Shell Scripten
Um einen ersten Eindruck von der Leistungsfähigkeit des Linux-Systems zu erhalten habe ich die Benchmark-Programme UNIXBench und Coremark installiert.
Arduino UNO Q UNIXBench
Vergleicht man die UNIXBench Resultate mit den unter https://ckblog2016.net/resultate-unixbench/ veröffentlichten Ergebnissen anderer Linux-Devices im Embedded Bereich, dann hat man mit dem Linux-Device des Arduino UNO Q ein durchaus leistungsfähiges System in den Händen.
Die M5Stack UNIT-C6L ist ein LoRa-Kommunikationsgerät, bestehend aus dem Stamp C6LoRa-Modul mit dem RISC-V-Controller ESP32-C6. Integriert sind der LoRa-Transceiver SX1262 und RF-Schalter. Das Modul unterstützt den Frequenzbereich von 868 bis 923 MHz für eine robuste drahtlose Kommunikation.
Das User-Interface besteht aus einem 0,66″-OLED-Monochrom-Display mit einer Auflösung von 64 x 48 Pixeln, einer programmierbaren RGB-LED, einem Buzzer einem Benutzertaster.
Zwei SMA-Antennenanschlüsse für 2,4-GHz-WiFi 6 und LoRa ermöglichen eine hohe Leistung.
Mit der von M5Stack bekannten HY2.0-4P-Erweiterungsschnittstelle (Grove) und den LEGO-kompatiblen Befestigungslöchern können Sensoren oder Module einfach hinzugefügt werden.
M5Stack UNIT-C6L
Die Inbetriebnahme der UNIT-C6L erfolgt in der bei anderen Meshtastic-Modulen üblichen Weise. Eine schrittweise Anleitung ist hier zu finden.
Innerhalb weniger Minuten ist diese Meshtastic Node in Betrieb genommen. Die Firmware war mit v2.7.10 recht aktuell, dennoch habe ich v2.7.11 geflasht.
Die folgenden Abbildungen zeigen das doch recht kleine OLED-Display, was sicher noch einer weiteren Anpassung bedarf. In der ersten Abbildung ist zu sehen, dass für den hier geplanten stationären Einsatz mit festen Ortskoordinaten gearbeitet wird.
In der zweiten Abbildung sind Speicherauslastung und Firmware-Version zu sehen.
Die dritte Abbildung zeigt Messwerte eines am Grove-Anschluss angeschlossenen M5Stack ENV.II Sensors. Der alte Inhalt wird nicht sauber gelöscht.
Die vierte Abbildung zeigt die WiFi-Verbindung. Dass sie in meinem Fall 192.168.1.208 lautete, muss man allerdings auf anderem Weg ermitteln.
Mitteilungen werden erwartungsgemäss empfangen, jedoch kaum oder gar nicht sichtbar ausgegeben, wie die fünfte Abbildung verdeutlicht.
Die sechste Abbildung soll die aktuelle Zeit anzeigen. Hier war es 16:43 😉
Zumindest für die Anzeige der Uhrzeit habe ich eine mögliche Alternative gefunden.
Über die Fronttaste kann man die digitale Anzeige der Uhr durch eine analoge ersetzen. Wie die nebenstehende Abbildung zeigt, ist die Uhr auf diese Weise zumindest les- und damit nutzbar.
Bei zahlreichen Meshtastic Nodes mit OLED-Display wird ein 0,96″-Display mit einer Auflösung von 128 x 64 Pixeln verwendet. Die Firmware scheint auf diese Auflösung zugeschnitten zu sein, wie die folgenden Abbildung eines Heltec V3 zeigen.
Die M5Stack UNIT-C6L erfüllt, mit Ausnahme der Displayanzeigen, alle Erwartungen. Der Grove-Anschluss ist mit der seriellen Schnittstelle für den Anschluss einer GPS-Unit belegt. Sollen I2C-Sensoren da angeschlossen werden, muss die Firmware entsprechend angepasst werden.
Die Anpassung der Anzeigeninhalte an die geringere Auflösung des 0.66″-OLED-Displays war bereits eine Herausforderung und wird wahrscheinlich als Kompromiss so bestehen bleiben. Danke, Thomas Göttgens, für den hilfreichen Gedankenaustausch.
Ich möchte diese Meshtastic Node in einem geschützten Außenbereich zur Erfassung von Umweltdaten einsetzen. Das fehlerfreie Ablesen des Displays ist für diese Anwendung zweitrangig, zur Signalisation des Betriebszustands aber ganz brauchbar.
Zur Komplettierung meiner Sammlung von Meshtastic Nodes habe ich bei LilyGO die LilyGO T-Desk Pro Meshtastic Node bestellt.
Die Lieferung liess nicht lange auf sich warten und ich packte erwartungsfroh die Sendung aus. Was ich fand war eine 915 MHz Version, die meine Stimmung erstmal trübte.
Ob ich den Fehler bei der Bestellung gemacht habe oder der Lieferant bei der Bearbeitung, kann ich nicht sagen. Eine Meldung bei LilyGO blieb unbeantwortet. Was nun?
Eine Anfrage in verschiedenen Foren brachte mir Antworten von einfach Firmware auf EU_868 konfigurieren bis hin zu geht überhaupt nicht, weil Frequenzen nicht passen.
Ein Blick in das Schaltbild des LilyGO T-Deck Pro zeigt, dass die Optionen des Antenna Match Networks kaum genutzt sind und möglicherweise mit der nicht optimalen Anpassung gelebt werden kann. Die Aussagen in der TI Design Note DN038 lassen das ebenfalls vermuten.
Also habe ich es auf dem brutalen Weg versucht und ohne Hardwareanpassungen nur die Firmware auf EU_868 eingestellt.
In den Screenshots zeigt sich, dass hier 97 Nodes online sind und offenbar die Anpassung der Firmware bereits zum Ziel geführt hat. Ob ein solches Vorgehen im Allgemeinen funktioniert, wage ich damit nicht zu sagen. Hier hat es funktioniert.
Für IoT-Anwendungen stehen heute verschiedene Funktechnologien zur Verfügung. Alle namhaften Anbieter stellen LoRaWAN- oder LTE-M/NB-IoT-Module zur Verfügung und der Anwender bzw. die Applikation entscheidet, welche Technologie zum Einsatz kommt.
LTE-M (Cat-M1) und NB-IoT (Narrowband IoT) sind beides Mobilfunkstandards aus dem LTE-Umfeld und wurden speziell für das Internet der Dinge (IoT) entwickelt.
Unter der Marke QuickSpot, bietet das belgische Unternehmen DPTechnics BV eine Reihe von IoT-Bausteinen an, die den Anwender bei der Produktentwicklung unterstützen soll. Ein bemerkenswertes Produkt ist Walter, ein Open-Source-Multifunk-IoT-System-on-Module (SoM), das einen ESP32-S3-Mikrocontroller mit einem Sequans GM02SP LTE-M/NB-IoT-Modem und einem GNSS-Empfänger kombiniert.
Walter unterstützt verschiedene Drahtlosoptionen, einschließlich WiFi, Bluetooth, LTE-M, NB-IoT und GPS, und ist für eine einfache Integration in IoT-Projekte konzipiert. Das Modul ist vollständig zertifiziert (CE, FCC, IC, UKCA, RCM) und wird mit Open-Source-Softwarebibliotheken für Plattformen wie Arduino, MicroPython und ESP-IDF geliefert.
Inbetriebnahme von Walter und Programmbeispiel zu WiFi- und LTE-M-Kommunikation sind in diesem eBook zusammengestellt.
Hier ist eine Zusammenfassung, was im Einzelnen behandelt wird:
Walter ist ein Open-Source-IoT-Modul von DPTechnics BV, das sich perfekt für Entwickler und Maker eignet, die Projekte mit LTE-M, NB-IoT, WiFi, Bluetooth und GPS umsetzen möchten – egal ob mobil, netzunabhängig oder energieeffizient.
Walter umfasst:
ESP32-S3 Mikrocontroller mit 16 MB Flash & 2 MB PSRAM
LTE-M/NB-IoT-Modem (Sequans GM02SP)
GNSS-Empfänger (GPS/Galileo)
Onboard-Antennen für WiFi & Bluetooth
Stromversorgung über USB-C oder Batterie (auch Solar)
24 GPIOs & viele Schnittstellen (I2C, SPI, CAN, UART, etc.)
Die vorhandenen Schnittstellen lassen flexible Erweiterungen zu. I²C- und OneWire-Sensoren sind problemlos anschließbar (z. B. SHT31, DS18B20). Beispielprojekte zur Wetterdatenerfassung, Temperaturmessung in Bojen werden gezeigt.
Verbindung zu OpenWeatherMap, MQTT-Brokern (HiveMQ, ThingSpeak) oder einem UDP-Demoserver werden beschrieben. Beispielcode für WiFi- oder LTE-basierten Wetterdatenabruf und Cloud-Upload.
Die Programmierung von Walter kann mit der Arduino IDE, MicroPython & ESP-IDF erfolgen. Alle Libraries & Beispiele auf GitHub: github.com/QuickSpot. Die Programmbeispiele im eBook sind mit der Arduino IDE erstellt.
Ideal für mobile & energieeffiziente Projekte. Unterstützt DeepSleep & geschaltete Sensorversorgung. Ideal für Outdoor, Umweltmonitoring, Smart Farming, u. v. m.
Kurz gesagt: Walter ist ein vielseitiges, sofort einsatzbereites LTE-IoT-Modul für Entwickler und Maker, die mit LTE-M bzw. NB-IoT eine Alternative zu WiFi oder LoRa/LoRaWAN suchen.
Ab dem 7.08.2025 gibt es auch einen Print der deutschen Ausgabe über Amazon.
Der Auszug aus Google Maps zeigt unsere Reiseroute.
Reiseroute
Die folgenden Auszüge aus dem Mapping von https://meshtastic.liamcottle.net/ zeigen die zu erwartenden Kontakte mit Knoten nahe unserer Route.
Start ist am oberen Zürichsee mit zahlreichen Nodes in Richtung Zürich, aber erst im Rheintal finden sich weitere Nodes in unserer Fahrtrichtung.
Walensee /Rheintal
Die Fahrt geht über die A7 nach Norden und erst zwischen Würzburg und Schweinfurt zeigen sich einige Nodes.
Würzburg, Schweinfurt
Entlang der A71 ist wenig zu erwarten, bis dann im Gebiet Erfurt bis Jena wieder etliche Nodes zu erwarten sind.
Erfurt / Jena
Weiter geht es über die A9 nach Norden, wo im Bereich Halle Leipzig zahlreiche Nodes zu erwarten sind.
Halle, Leipzig
Auf dem Berliner Ring sollten sich dann Nodes aus dem Bereich Potsdam Berlin zeigen.
Potsdam, Berlin
Vom Berliner Norden bis nach Rostock werden wohl keine Nodes zu sehen sein. Erst im Rostocker Umland könnten sich einige Nodes zeigen.
Rostock
Zwischen Rostock und Stralsund scheint weitgehend Funkstille zu herrschen. Erst in Stralsund werden ein paar Nodes erwartet. Auf der Insel Hiddensee wird dann meine temporär installierte Node S3GW zu sehen sein.
Stralsund
Ich arbeite wieder mit den Default-Einstellungen für LongFast, da ich nicht die lokalen Channels der durchfahrenen Gebiete vorgeben wollte. Möglicherweise wären dann weitere Knoten erreichbar.
Diesmal habe ich eine Magnetfußantenne auf dem Dach meines PKW installiert, um besseren Funkempfang (5 dBi) zu erreichen. Um hinreichend wetterfest zu sein, sollten Antenne und Magnetfuß mit N-Type Steckverbindern ausgerüstet sein. Ein kleinerer Magnetfuß muss unbedingt vermieden werden, da sich sonst die Antenne bei höheren Geschwindigkeiten oder starkem Wind vom Dach lösen kann.
Wie erwartet konnte ich in Sargans und im Rheintal einige wenige Nodes empfangen.
RheintalWähredn
Während der weiteren Fahrt meldete sich ab und an eine Node, wurde aber im Mapping nicht gezeigt. Erste in Jena habe ich das Bild vorgefunden, was ich von meiner letzten Reise her kenne.
Jena
Eine Gesamtansicht der Nodes zeigt der Screenshot von MeshSense.
Nodes in und um Jena
Der Rest der Fahrt war bezüglich Meshtastic-Kontakten ein Totalausfall.
Nodes auf der Insel Hiddensee
Unser Feriendomizil ist im Süderhof am südlichen Ende von Vitte. Die Standorte des festen Nodes habe ich im Kartenausschnitt unten eingetragen.
Die Meshtastic Gateway soll in der oberen Etage in Fensternähe installiert werden. Über den Zugang zum WLAN des Hauses kann diese Node dann zusätzlich über MQTT kommunizieren. Die Idee ist, die Standorte im Mapping von Liam Cottle zu markieren.
Unter dieser Voraussetzung kann mit dem Meshtastic Site Planner die Abdeckung des Mesh-Netzwerks simuliert werden. Wie die folgende Abbildung zeigt, sollte der gesamte obere Teil der Insel bis hinunter nach Neuendorf abgedeckt werden.
Ob wieder Nodes aus Dänemark und Schweden zu sehen sein werden, bleibt noch unklar.
Nachdem alle Nodes eingerichtet sind, ist Hiddensee erstmal abgedeckt. Im Feriendomizil ist S3GW stationär, während andere Nodes mit unterwegs sind. Die Verbindungen auf Hiddensee funktioniert erwartungsgemäß.
Solarnode RAK3 am Strand von Vitte
Mobilnode T1k2 am Strand in Kloster
Weitergehende Kontakte sind eher sporadischer Natur. Kontakt nach Kopenhagen und Malmö hatte ich auch diesmal wieder, wie die folgenden Screenshots zeigen.
Nodes während der Rückfahrt
Während der Rückfahrt hatte ich einige wenige Kontakte, die sich aber praktisch kaum im Mapping zeigten.
Nodes in Süddeutschland
Nodes zu Hause
Fazit
Die Kontakte zu anderen Nodes während der Reise und während des Aufenthalts in Norddeutschland waren da, wenn auch nicht in dem Maße, wie ich es erwartet hatte.
Von der Antenne auf dem Fahrzeugdach hätte ich eine größere Ausbeute während der Fahrt erwartet. Die Haftung des Magnetfußes war sehr gut. Bei Geschwindigkeiten bis ca. 160 km/h war kein Verschieben o.ä. zu verzeichnen.
Die stationären Verbindungen in Ballungsräumen waren auch besser als im Jahr zuvor. Da hat sich in der Community einiges getan.
Im Norden dann hatte ich zwar gute Reichweiten bis nach DK und S. Mitteilungen konnten aber nicht ausgetauscht werden. Ich habe dann den Kontakt zu den lokalen Gruppen über deren Portale erreicht. Zu den Nodes in Mecklenburg-Vorpommern habe ich keinen Kontakt bekommen, was topografische Gründe haben soll. Der Kontakt zu meinen eigenen Nodes an unterschiedlichen Orten der Insel war immer gegeben.
ck blog 