• Funkturm-Wilsdruff-Update-2026

    🗼 Funkturm Wilsdruff: Es wird ernst – die Nodes gehen live!

    Update April 2026 | MeshDD • Meshtastic Dresden

    In unserem letzten Beitrag über den Funkturm Wilsdruff haben wir euch von einem besonderen Standort erzählt: dem wiederaufgebauten Denkmal des legendären „Bleistifts“ auf der Hühndorfer Höhe bei Wilsdruff. Was damals noch Planung war, nimmt jetzt konkrete Formen an – und wir brauchen eure Unterstützung!

    📅 Ein festes Datum: 11. April 2026

    Der Förderverein Funkturm Wilsdruff e. V. hat es geschafft: Am 11. April 2026 um 11 Uhr wird das Funkturm-Denkmal auf der Hühndorfer Höhe feierlich eingeweiht. Der „Bleistift“ kehrt zurück – als sichtbares Denkmal für ein Stück sächsische Rundfunkgeschichte.

    Und MeshDD ist dabei. Zur Eröffnung wollen wir zwei autarke Mesh-Nodes gleichzeitig live schalten:

    • Node 1 – Meshtastic: Ein LoRa-Knoten, der das bestehende MeshDD-Netz im Dresdner Raum als starken Backbone-Knoten verstärkt.
    • Node 2 – MeshCore: Mit intelligentem Routing und höherer Bandbreiteneffizienz – ideal für dichte städtische Netze.

    Beide Nodes werden solargestützt betrieben – 100 % autark, ohne Netzstrom, ohne Ausfallrisiko. Genau die Philosophie, für die MeshDD steht.

    🌍 Warum dieser Standort so besonders ist

    Die Hühndorfer Höhe bietet freie Sicht in alle Richtungen – ein idealer Backbone-Standort für das gesamte Dresdner Mesh-Netz. Wer schon mal auf der alten Sendeanlage gestanden hat, weiß: Von hier aus reicht die Funkverbindung weit in die Region.

    Mit Meshtastic und MeshCore parallel in Betrieb entsteht ein doppelt abgesichertes, krisenfestes Kommunikationsnetz für Dresden und Umgebung – ohne Internet, ohne Mobilfunk, ohne zentrale Infrastruktur.

    🛠️ Was noch fehlt – und wie du helfen kannst

    Die Technik muss jetzt beschafft, montiert und getestet werden. Die Zeit drängt! Wir suchen sowohl Geldspenden als auch Hardware-Spenden:

    Hardware, die wir noch benötigen:

    • LoRa-Boards (Meshtastic & MeshCore kompatibel)
    • Solarpanels & LiFePO4-Akkus
    • Wetterfeste Gehäuse
    • Richtantennen 868 MHz
    • Montagematerial & Kabel

    Geldspenden helfen uns bei:

    • Fehlenden Komponenten
    • Hubsteiger-Miete für die Montage in der Höhe
    • Wetter- und Blitzschutz
    • Reserve-Hardware für den laufenden Betrieb

    💛 So kannst du jetzt helfen

    💶 Online spenden:
    👉 https://gofund.me/6cfb3f64e

    Jeder Betrag zählt – egal wie klein oder groß. Alle Mittel fließen direkt ins Projekt. MeshDD wird vollständig ehrenamtlich betrieben.

    📦 Hardware spenden oder Fragen stellen:

    ⏰ Wenige Wochen bis zur Einweihung!

    Der 11. April 2026 rückt näher. Wer dabei sein möchte, wenn in Wilsdruff Geschichte geschrieben wird – und gleichzeitig freie, autarke Kommunikation für die Region live geht – ist herzlich eingeladen.

    Denkmal-Einweihung: 11.04.2026, 11 Uhr, Hühndorfer Höhe, Wilsdruff

    Spendenaufruf_MeshDD_WilsdruffHerunterladen

    Werde Teil der Geschichte! 📡

    MeshDD – Meshtastic Dresden • meshdresden.eu • t.me/mesh_dresden

  • MeshDresden testet MeshCore

    Datum: März 2026

    Wer die Entwicklung von MeshDresden in den letzten Monaten verfolgt hat, weiß: Wir stehen nicht still. Nach dem MediumFast-Test, der uns wertvolle Erkenntnisse über Netzlast, Reichweite und Community-Koordination gebracht hat, wagen wir den nächsten Schritt – und erweitern unseren Blick über Meshtastic hinaus.

    MeshDresden testet ab sofort auch MeshCore.

    Warum MeshCore?

    Die Frage ist berechtigt: Wir haben eine funktionierende Meshtastic-Infrastruktur, einen eigenen Bot mit Dashboard, NINA-Integration und wachsende Community. Warum also ein weiteres System ins Spiel bringen?

    Die Antwort ist einfach: Weil wir neugierig sind – und weil es technisch spannend ist.

    MeshCore verfolgt einen grundlegend anderen Ansatz als Meshtastic. Während Meshtastic auf echtem Flooding-Mesh basiert, bei dem jeder Node alles weiterleitet, setzt MeshCore auf ein strukturiertes Infrastrukturmodell: Dedizierte Repeater übernehmen die Weiterleitung, Endgeräte (sogenannte „Companions“) konzentrieren sich auf das Senden und Empfangen von Nachrichten. Das reduziert Kollisionen, schont die Kanalkapazität – und könnte gerade in einem aktiven Stadtnetz wie dem Dresdner Mesh interessante Vorteile bringen.

    Ein Punkt, der uns besonders reizt: MeshCore unterstützt theoretisch bis zu 64 Hops und bringt native Store-and-Forward-Funktionalität mit – also die Möglichkeit, Nachrichten zwischenzuspeichern, bis der Empfänger wieder erreichbar ist. Beides sind Schwächen, die wir mit Meshtastic im Alltag durchaus spüren.

    Was wir testen wollen

    Der Test ist offen angelegt. Wir wollen ehrlich schauen, was MeshCore im Dresdner Stadtgebiet kann – ohne vorab ein Ergebnis festzulegen. Konkret interessiert uns:

    • Wie verhält sich MeshCore unter realen Bedingungen im Elbtal mit seinen typischen Funkschatten?
    • Wie viel Aufwand erfordert der Aufbau einer funktionierenden Repeater-Infrastruktur?
    • Welche Auswirkungen hat die getrennte Rollen-Architektur auf die Netzstabilität?
    • Lässt sich MeshCore sinnvoll parallel zu Meshtastic betreiben?

    Für die Tests nutzen wir vorhandene Hardware, die bereits als Meshtastic-Knoten dient. Ein Teil davon wird probeweise mit der MeshCore-Firmware bespielt – als dedizierter Repeater. Die Ergebnisse fließen direkt in Blogbeiträge hier auf der Seite ein.

    MeshDresden legt sich nicht fest

    Das ist uns wichtig, und wir möchten es ausdrücklich betonen: MeshDresden ist keine Meshtastic-Seite – und wird auch keine reine MeshCore-Seite.

    Wir betrachten LoRa-Mesh-Kommunikation als Ganzes. Meshtastic und MeshCore sind zwei unterschiedliche Wege zum gleichen Ziel: robuste, unabhängige Kommunikation ohne zentralisierte Infrastruktur. Beide Ansätze haben ihre Daseinsberechtigung, beide haben Stärken und Schwächen – und beide verdienen eine faire Auseinandersetzung.

    Die Kategorien auf dieser Seite spiegeln das bereits wider: Unter meshtastic und meshcore werden wir beide Welten dokumentieren, vergleichen und voneinander lernen. Was für unsere Community in Dresden funktioniert, zeigt sich im Betrieb – nicht in der Theorie.

    Praktische Hinweise für Interessierte

    Wer MeshCore selbst ausprobieren möchte, braucht zunächst kompatible Hardware. Viele der gängigen LoRa-Boards, die auch Meshtastic unterstützen (z. B. LilyGo T-Deck, Heltec-Module), lassen sich mit der MeshCore-Firmware flashen. Wichtig ist dabei die Unterscheidung zwischen den Firmware-Images:

    • Repeater-Image: Für fest installierte Knoten, die als Infrastruktur dienen sollen
    • Companion-Image: Für mobile Endgeräte oder Handhelds

    Die Konfiguration erfordert mehr Planung als bei Meshtastic – aber genau das ist auch ein Teil des Tests: Wie aufwendig ist der Einstieg, und lohnt sich der Mehraufwand?

    Wie geht es weiter?

    Wir werden regelmäßig berichten – über erste Erfahrungen, konkrete Messwerte und den Vergleich mit dem bestehenden Meshtastic-Netz. Der MeshMonitor und der MDDB-Bot bleiben weiterhin auf Meshtastic ausgerichtet; ob und wie wir MeshCore dort integrieren, hängt vom Testverlauf ab.

    Bleibt neugierig.

    73 de Mesh Dresden

    Dieser Beitrag gehört zur Kategorie meshcore und meshtastic.

  • Vergleich: Meshtastic vs. MeshCore
    (Stand 2024/2025)

    Ein technischer Vergleich der beiden führenden Open-Source-Firmwares für die Off-Grid-Kommunikation via LoRa (Long Range).

    1. System-Philosophie

    MerkmalMeshtasticMeshCore
    Primärer FokusDynamische Ad-hoc-NetzeStrukturierte Infrastruktur-Netze
    Routing-ModellFlooding (Echtes Mesh): Jeder Client leitet alles weiter.Managed Mesh: Dedizierte Repeater leiten für Clients („Companions“) weiter.
    NutzererlebnisEinsteigerfreundlich, Plug-and-Play.Performance-orientiert, erfordert Planung.

    2. Analyse der neuesten Firmware-Versionen

    Meshtastic (v2.5.x – v2.7.x)

    Die Entwicklung konzentriert sich aktuell massiv auf Usability und Kryptografie.

    • BaseUI & MUI: Ermöglicht die Konfiguration direkt am Geräte-Display (ohne Smartphone).
    • Public Key Cryptography (PKC): Einführung einer sicheren Schlüsselverwaltung für private Direktnachrichten und Remote-Admin-Zugriff.
    • Next-Hop-Routing: Optimierung des Pfadfindungs-Algorithmus zur Reduzierung von Funkkollisionen in dichten Netzen.
    MeshCore (v1.12.x – v1.13.x)

    Hier liegt der Fokus auf Effizienz und der Trennung von Rollen.

    • Rollen-Spezialisierung: Getrennte Firmware-Images für Repeater (Infrastruktur) und Companions (Endgeräte).
    • Ultra-Low-Power Mode: Die neueste Firmware senkt den Ruhestrom für Repeater auf bis zu 8,5 mA.
    • MCTerm: Eigene Terminal-Oberfläche für Hardware mit Tastatur (z. B. T-Deck), um Messaging komplett autark zu gestalten.

    3. Vor- und Nachteile im Überblick

    Meshtastic
    • Vorteile:
      • Riesige Community: Höchste Chance auf bestehende Netzknoten.
      • Maximale Mobilität: Perfekt für Wandergruppen oder Katastrophenschutz ohne feste Stationen.
      • Hardware-Vielfalt: Unterstützt fast jedes verfügbare LoRa-Board (Heltec, RAK, LilyGo).
    • Nachteile:
      • Network Congestion: In Städten oft „überfüllt“ durch zu viele Status-Pakete (Telemetrie).
      • Stromverbrauch: Höhere Belastung für mobile Geräte durch ständiges Routing fremder Daten.
    MeshCore
    • Vorteile:
      • Stabilität: Durch die Konzentration auf feste Repeater bleibt der Funkkanal für Nachrichten frei.
      • Reichweite: Unterstützt theoretisch bis zu 64 Hops (Meshtastic meist limitiert auf 7).
      • Store-and-Forward: Native Unterstützung für Server, die Nachrichten speichern, bis der Empfänger wieder online ist.
    • Nachteile:
      • Setup-Aufwand: Erfordert mehr technisches Verständnis bei der Ersteinrichtung.
      • Kleineres Ökosystem: Weniger öffentliche Knoten und weniger Drittanbieter-Apps.

    4. Fazit & Empfehlung

    • Wähle Meshtastic, wenn du ein mobiles Netz für Outdoor-Aktivitäten suchst oder Teil der globalen Mesh-Community sein möchtest.
    • Wähle MeshCore, wenn du ein stabiles, regionales Funknetzwerk mit fester Infrastruktur (z. B. in deiner Stadt oder auf einem Firmengelände) aufbauen willst.

    Erstellt für den Vergleich von LoRa-Mesh-Technologien.

  • Vom Bot zum Dashboard…
    Dieser Beitrag ist ein Update zum ursprünglichen Artikel über den MeshDD-Bot. Seitdem hat sich das Projekt grundlegend weiterentwickelt – aus einem einfachen Bot ist ein vollständiges Webdashboard geworden.

    Vom Bot zum Dashboard – MeshDD-Dashboard (MDDB) v0.9

    Was als schlichter Kommando-Bot für unser Dresdner Meshtastic-Netz gestartet ist, hat sich in den vergangenen Wochen zu einem vollwertigen Webdashboard mit Echtzeit-Monitoring, Benutzerverwaltung, NINA-Warnintegration und RF-Statistiken entwickelt. Der offizielle Name ist jetzt MeshDD-Dashboard (MDDB) – der Bot steckt weiterhin drin, ist aber nur noch eine von vielen Komponenten. Dieser Beitrag gibt einen Überblick über den aktuellen Stand und einen Ausblick auf das, was als Nächstes kommt.

    Was das Dashboard heute kann

    Das Dashboard-Hauptfenster
    Die Startseite ist öffentlich zugänglich und zeigt in Echtzeit per WebSocket:
    • Vier Statusboxen: Gesamt-Nodes, im letzten 24h-Fenster aktive Nodes, aktuell online (konfigurierbar, Standard: 15 Minuten) und beantwortete Bot-Anfragen
    • Nodes-Tabelle mit Name, Hardware-Modell, RSSI, Batteriestatus (farbcodiert), Hop-Anzahl, GPS-Indikator und letzter Aktivität – per Spaltenklick sortierbar und mit Suchfeld
    • Node-Detail-Modal: Klick auf eine Zeile öffnet alle Daten des Nodes inklusive einer Leaflet-Minikarte mit seiner Position
    • Vier Diagramme: Kanal-Anfragen (Doughnut), Hop-Verteilung (Balken), Hardware-Top-5 (Balken), Pakettypen der letzten 24h (Doughnut)
    • Nachrichten direkt senden (für eingeloggte Mitarbeiter und Admins): Kanal wählen, Text eingeben, abschicken – ohne Meshtastic-App
    • Konfigurierbare Links-Karte: Frei befüllbar mit eigenen Links (z.B. MeshMap, Meshtastic.org)
    Live-Karte
    Die Karte zeigt alle Nodes mit bekannter GPS-Position auf einer Leaflet-Karte. Die Marker sind farbcodiert nach Hop-Anzahl (blau = direkt, grün = 1 Hop, orange = 2 Hops, …) und werden mit zunehmendem Alter transparenter – Nodes die älter als 72 Stunden sind werden ausgeblendet. Das Kartentileset wechselt automatisch mit dem Hell-/Dunkel-Theme (OpenStreetMap ↔ CartoDB Dark Matter).
    Paket-Log
    Alle empfangenen Meshtastic-Pakete laufen in Echtzeit auf – öffentlich einsehbar. Die Tabelle zeigt Zeit, Absender, Empfänger, Pakettyp, Kanal, SNR, RSSI, Hop-Limit und dekodierte Nutzdaten (Position, Telemetrie, NodeInfo usw.). Eine mehrstufige Filterzeile erlaubt das kombinierte Filtern nach Absender, Empfänger, Kanal, maximaler Hop-Anzahl und Freitext.
    Nachrichtenverlauf
    Der Nachrichtenverlauf zeigt empfangene und gesendete Textnachrichten im Chat-Bubble-Design: empfangene Nachrichten links mit farbigem Kanalrand, vom Bot gesendete Nachrichten rechts in Grün. Kanalfilter-Buttons ermöglichen das schnelle Ein- und Ausblenden einzelner Kanäle. Die Seite ist öffentlich zugänglich.

    NINA-Warnmeldungen

    Die NINA-Integration war eines der komplexeren Features. Der Bot fragt die NINA-API des BBK (Bundesamt für Bevölkerungsschutz und Katastrophenhilfe) ab und kann neue Warnmeldungen automatisch ins Mesh senden. Seit Version 0.9.2 ist die Konfiguration pro Schweregrad möglich:
    Stufe Beispiel Standardverhalten
    Minor – Gering Allgemeine Hinweise Abgerufen, kein Mesh-Versand, Abfrage alle 10 Min.
    Moderate – Mäßig Unwetterwarnungen Stufe 1 Abgerufen, kein Mesh-Versand, Abfrage alle 5 Min.
    Severe – Schwerwiegend Sturmböen, Hochwasser Mesh-Versand aktiv, Abfrage alle 5 Min., Wiederholung alle 30 Min.
    Extreme – Extrem BBK-Zivilschutzwarnung Mesh-Versand aktiv, Abfrage alle 60 Sek., Wiederholung alle 10 Min.
    Jede Stufe hat ihren eigenen Abfrageintervall, Wiederholungsintervall (0 = nur Änderungen senden), Zielkanal und Mesh-Freigabe. Wenn man z.B. Minor-Meldungen nur im Dashboard beobachten, aber nicht ins Netz senden will, kann das je Stufe einstellt werden. Ein Versandlog protokolliert jede Aussendung mit Zeit, Kanal, Schweregrad und Meldungstext – filterbar nach Neu/Wiederholung, live per WebSocket aktualisiert. Warnmeldungen werden regional über AGS-Codes (Amtliche Gemeindeschlüssel) gefiltert – bei uns sind die Stadt Dresden sowie die umliegenden Landkreise konfiguriert. Verfügbare Quellen: Katwarn, BIWAPP, MoWaS, DWD, LHP und Polizei.

    Scheduler

    Der Scheduler ermöglicht zeitgesteuerte Bot-Aktionen per Cron-Ausdruck. Jobs können entweder Bot-Kommandos ausführen oder freie Textnachrichten senden. Nachrichten unterstützen Template-Variablen wie {time}, {date}, {nodes}, {nodes_online} oder {version} – nützlich für automatische Statusmeldungen ins Netz.

    RF-Statistiken

    Unter /rf-stats gibt es einen interaktiven Zeitgraph mit drei Datenserien:
    • Air Util TX – tatsächlich gemessene Kanalauslastung des eigenen Nodes (aus Telemetriepaketen)
    • Channel Util – gesamte Kanalnutzung aus Gerätesicht
    • Geschätzte Airtime – berechnet aus Paketanzahl und LoRa-Airtime-Formel (abhängig vom konfigurierten Preset)
    Zeitraum (1h / 6h / 24h / 7d) und Fenstergröße (1 / 5 / 15 / 60 Minuten) sind frei wählbar. Vier Stat-Karten zeigen die aktuellen Werte des letzten Zeitfensters.

    Konfiguration im Dashboard

    Über die Konfigurationsseite können Admins Bot-Name, Befehlspräfix, Meshtastic-Host/Port, Webserver-Port, Online-Schwellwert und benutzerdefinierte Links direkt im Browser bearbeiten – ohne die YAML-Datei anfassen zu müssen. Außerdem gibt es einen Toggle „Kommandos aktiv“: bei Deaktivierung ignoriert der Bot eingehende Mesh-Anfragen stumm, sendet aber weiterhin Scheduler- und NINA-Nachrichten.

    Benutzerverwaltung und Rollen

    Das Dashboard kennt drei Zugriffsebenen:
    • Public: Dashboard, Karte, Pakete, Nachrichten – keine Anmeldung nötig
    • Mitarbeiter: Zusätzlich Scheduler und NINA (Lesezugriff), Nachrichten senden
    • Admin: Vollzugriff inkl. Konfiguration, Benutzerverwaltung und alle Schreibrechte
    Neue Mitarbeiter werden per E-Mail eingeladen: ein automatisch generiertes Passwort wird zugesendet, beim ersten Login ist ein Passwortwechsel Pflicht.

    Bot-Kommandos

    Die klassischen Mesh-Kommandos sind natürlich noch an Bord. Alle mit dem konfigurierten Präfix (Standard: ?):
    Kommando Funktion
    ?ping Pong mit Hop-Anzahl des Absenders
    ?nodes Nodes online und gesamt
    ?mesh Detaillierte Netzübersicht (Online, 24h, Hops, Hardware)
    ?me Eigene Node-Daten (Hardware, Hops, SNR, RSSI, Batterie, Position)
    ?weather [plz:XXXXX] Aktuelles Wetter an der Node-Position oder per PLZ
    ?stats Bot-Statistiken
    ?info Bot-Name, Version, Laufzeit
    ?uptime Laufzeit
    ?help Übersicht aller Kommandos
    Lange Antworten werden automatisch in Teilnachrichten mit Nummerierung [1/3] aufgeteilt.

    Technischer Hintergrund

    Das Projekt ist komplett in Python (asyncio) geschrieben und läuft als systemd-Service. Die wichtigsten Technologien:
    • meshtastic – Python-Bibliothek für die TCP-Verbindung zum Meshtastic-Gerät
    • aiohttp – Asynchroner Webserver mit WebSocket-Unterstützung
    • aiosqlite / SQLite – Lokale Datenbank (WAL-Modus) für Nodes, Nachrichten, Pakete, NINA-Log, Benutzer
    • aiohttp-session + bcrypt – Session-Authentifizierung mit verschlüsselten Cookies
    • Bootstrap 5.3 + Tabler CSS – Responsives Dashboard mit Hell-/Dunkel-Theme
    • Leaflet.js – Interaktive Karte
    • Chart.js 4 – Zeitgraphen und Diagramme
    • aiosmtplib – Asynchroner E-Mail-Versand für Einladungen und Passwort-Reset
    Die gesamte Konfiguration liegt in config/config.yaml (live-reloaded, Änderungen werden ohne Neustart aktiv). NINA- und Scheduler-Konfiguration haben eigene YAML-Dateien.

    Was als Nächstes geplant ist

    Das Projekt wird aktiv weiterentwickelt. In Planung sind drei größere Themenblöcke:
    Nachrichten-Warteschlange
    Aktuell werden ausgehende Nachrichten ohne Wartezeit direkt gesendet. Geplant ist eine Warteschlange, die zwischen Sendungen automatisch pausiert – orientiert an der aktuellen Airtime-Auslastung des Nodes. So bleibt der Bot dutycycle-konform und verhält sich netzfreundlich, auch wenn NINA oder der Scheduler mehrere Nachrichten auf einmal produzieren.
    MQTT-Anbindung
    Ein eigener MQTT-Client soll den Bot mit einem Broker verbinden:
    • Publisher: Node-Updates, empfangene Nachrichten und NINA-Warnungen werden an den Broker gemeldet
    • Subscriber: Nachrichten vom Broker können direkt ins Mesh gesendet werden
    • Dashboard-Statusanzeige: Verbindungsstatus und Statistiken auf der Hauptseite sichtbar
    Das öffnet die Möglichkeit, den MDDB in bestehende Heimautomations- oder Monitoring-Infrastruktur einzubinden.
    Docker-Deployment
    Für eine einfachere Installation soll es ein Docker-Image geben – mit separaten Bind-Mounts für config/ und data/ sowie einem docker-compose.yml. Dazu kommt ein GET /health-Endpunkt (JSON mit Status, Version, Meshtastic-Verbindungsstatus und Uptime) und eine vollständige Quickstart-Dokumentation im README.

    Mitmachen und Quellcode

    Das Projekt ist auf unserem Forgejo-Server gehostet und steht als Open Source zur Verfügung. Wer den MDDB ebenfalls betreiben oder zum Projekt beitragen möchte, ist herzlich eingeladen. Der aktuelle Stand (v0.09.02, Februar 2026) ist stabil und läuft im Dresdner Mesh produktiv. 73 de Mesh Dresden
  • Reichweitentest im MeshDD !?

    Ein Reichweitentest bei Meshtastic hat einige spezifische Auswirkungen auf das Netzwerk, die man kennen sollte.

    Was passiert beim Reichweitentest?

    Wenn du den integrierten Reichweitentest (range_test Modul) aktivierst, sendet der Sender-Node in regelmäßigen Abständen (z.B. alle 60 Sekunden) spezielle Testpakete. Alle Nodes mit aktiviertem Empfänger-Modus loggen die empfangenen Pakete mit RSSI, SNR und GPS-Position – sofern vorhanden.

    Das klingt harmlos, hat aber einen wichtigen Effekt:

    Netzwerklast und Airtime

    Jedes Testpaket wird wie eine normale Nachricht behandelt – es wird also durch das Mesh weitergeleitet (geflutet). Bei einem aktiven Netzwerk wie MeshDD bedeutet das:

    • Jeder Node im Netzwerk empfängt und rebroadcastet die Pakete
    • Bei kurzen Intervallen (< 60s) steigt die Airtime-Auslastung erheblich
    • Es kann zu Kollisionen kommen, besonders auf stark genutzten Kanälen wie LongFast
    • Andere Nutzer im Netz bekommen mehr „Hintergrundlärm“

    Empfehlung für den Einsatz in einem Community-Mesh

    Vor dem Test:

    • Ankündigung im Mesh oder per MQTT an die Community (bei euch über den MeshDD-Bot wäre ideal)
    • Kurze Testdauer planen – nicht stundenlang laufen lassen
    • Intervall nicht unter 60 Sekunden setzen, besser 120–300s

    Während des Tests:

    • Nur einen aktiven Sender gleichzeitig betreiben
    • Empfänger-Nodes können überall im Netz parallel laufen, da sie nur passiv loggen

    Nach dem Test:

    • Das Modul sofort wieder deaktivieren – es bleibt sonst aktiv und belastet das Netz dauerhaft
    • Ergebnisse (CSV-Log) auswerten – Meshtastic speichert sie auf dem Gerät oder per serielle Verbindung auslesbar

    Auswertung der Ergebnisse

    Die gespeicherten Daten enthalten pro empfangenem Paket:

    • Sender-Node-ID
    • RSSI / SNR
    • GPS-Koordinaten des Empfängers (wenn verfügbar)

    Das lässt sich gut in Python weiterverarbeiten – z.B. in deine bestehende Heatmap-Infrastruktur einspeisen, um Empfangsqualität geografisch darzustellen.

    Fazit

    Der Reichweitentest ist ein nützliches Werkzeug, aber in einem aktiven Community-Netz wie MeshDD sollte er koordiniert, zeitlich begrenzt und mit moderatem Intervall eingesetzt werden. Am besten kombiniert mit einer automatischen Benachrichtigung über euren Bot, damit andere Nutzer wissen, dass gerade ein Test läuft.

Nach oben scrollen