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.
Der Rheinwerk-Verlag hat eine besondere Aktion für Dich: Bis zum 11. Juni bekommst Du 25 % Rabatt auf alle deutschsprachigen E-Books und Jahresabos. Pick Dir aus unserer großen Auswahl die Rosinen raus, die Dir schmecken.
Für alle, die an Meshtastic interessiert sind, ist hier das Angebot:
Das Notfunk Netzwerk (NFN) ist eine Gruppe von Funkamateuren, CB-Funkern, IT-Fachkräften sowie Feuerwehrmännern, die daran arbeiten, ein flächendeckendes Notfunknetzwerk (Meshtastic) in Zusammenarbeit von Liegenschaften und Grundstückseigentümern in der Schweiz aufzubauen.
Im Ernstfall kann die Kommunikation dezentral über dieses Netzwerk erfolgen – Für JEDERMANN.
Um eine landesweite Erreichbarkeit zu gewährleisten, sind selbst hergestellte und autark arbeitende Solar-Nodes an hohen Standorten unerlässlich.
Im Januar 2025 wurde mit dem Aufbau des Netzwerks in der Zentralschweiz begonnen.
Die Nodes des NFN sind mit den folgenden Bezeichnungen NFN-631#1-1 / Web-SDR.ch erkennbar. Es bedeuten: NFN = Notfunk Netzwerk, 631 = die ersten drei Zahlen der PLZ, # dient als Platzhalter, 1 – 1= Username – Device Nr von diesem User.
Somit ist zu sehen, dass im Gebiet von der PLZ 631x von User 1, der erste Node zu sehen ist.
Dass der Ausbau im Gange ist, zeigen die von mir in Altendorf SZ empfangenen Nodes aus dem NFN-Mesh.
NFN Nodes
Die derzeitige aktiven Client–Solar-Nodes sind unter https://meshtastic.web-sdr.ch/ gelistet. Außerdem sind auf dieser Website Bauvorschläge für eigene Nodes veröffentlicht.
Das 3. Modell der dort gelisteten Vorschläge wurde mir dankenswerterweise vom NFN zum Test zur Verfügung gestellt.
Bauraum für die Installation von Node, Sensoren und Batterie
Schon beim Auspacken zeigte sich, dass die Solarzelle bereits auf Glühlampenlicht reagierte, was eine ordentliche Effektivität versprechen sollte.
Für den Test günstig ist die anfängliche Pause des fast sommerlichen Wetters. Der Test beginnt an einem trüben Tag, praktisch ohne Sonne. Am 10.05.25 lässt sich erstmals die Sonne wieder sehen und es geht relativ ausgeglichen weiter. Die Grafik zeigt die Resultate des Tests vom 7.05. bis 19.05.2025.
Fazit:
Für eine autark arbeitende Solarnode ist der Stromverbrauch der Node selbst von absoluter Bedeutung. Folgerichtig kam in der NFN-Node ein nRF52840 basierendes RAK4631-Modul von RAKwireless zum Einsatz.
Ein Li-Ion Akku mit einer Kapazität von 10’000 mAh deckt die Phasen ohne ausreichend Sonnenlicht ab, was hier aber nicht ausgereizt wurde.
Das Solarpanel war überraschend effektiv und selbst bei nicht so sonnigen Tagen wurde die Batterie nachgeladen.
Die Verwendung der hier beschriebene Solarnode vom Notfunk Netzwerk im autarken Einsatz kann ich nach den Tests hier nur empfehlen. Die Daten zum Nachbau sind freigegeben, sodass diesem nichts entgegensteht.
Ich danke dem NFN für die Bereitstellung der Node, wodurch dieser Test erst möglich wurde.
Lust auf mehr? Wenn Du ein ähnliches Projekt starten möchtest oder Fragen zu Deinem Setup hast – ich unterstütze Dich gern als Consultant. Jetzt unverbindlich Kontakt aufnehmen »
Nachdem der Meshtastic Public Broker in letzter Zeit keine zuverlässige Verbindung über MQTT sichergestellt hat, hat die MESH HESSEN Community die Initiative ergriffen und einen eigenen MQTT Broker aufgesetzt.
Die Community betreibt einen eigenen MQTT-Server, welcher sich krisensicher stationiert in einem historischen Bunker in Deutschland befindet.
Ich habe den Broker ausprobiert und die folgenden Screenshots zeigen das über MQTT erweiterte Mesh-Netzwerk im Programm MeshSense.
Mein Heimnetz ohne MQTT-Anbindung
Durch MQTT erweitertes Heimnetz
Die über MQTT empfangenen Nodes zeigen sich im Android Client gemäss folgenden Screenshots.
Nodes über MQTT
Da die MQTT-Verbindung das Internet nutzt, ist eine solche Erweiterung bei Ausfall einer Komponente im Übertragungsweg dann nicht mehr funktional. Das gilt es unbedingt bei der Erstellung einer solchen Erweiterung zu beachten.
Der SensorHub von RAKwireless ist ein modulares System, bestehend aus einem Hauptteil und mehreren vorkonfigurierten Sensorsonden. Mit steckbaren und austauschbaren Sonden und der Möglichkeit, Sensoren von Drittanbietern zum System hinzuzufügen, ist der SensorHub eine geeignete und vielseitige Lösungsplattform für verschiedene IoT-Anwendungen, bei denen eine Umweltüberwachung im Freien erforderlich ist.
Der SensorHub kann je nach Anwendung und Einsatzort mit nicht wiederaufladbaren oder solarbetriebenen Batterien oder mit einer externen Stromversorgung arbeiten.
Wenn Sie mit dem SensorHub eine autonom arbeitende IoT-Anwendung implementieren wollen, dann finden Sie in meinem eBook zum SensorHub weitere Anregungen.
ck blog 