1. Zusammenfassung der Testergebnisse
2. Positive Beobachtungen
3. Kritische Probleme
4. Bewertung und Ausblick
5. Betrachtung zur Netzlast
6. Fazit für Dresden

1. Zusammenfassung der Testergebnisse

Der Test zur Umstellung von LongFast auf MediumFast im Dresdner Mesh-Netzwerk zeigt ein
gemischtes Bild mit deutlichen Einschränkungen. Die Testphase vom 31. Januar bis 7. Februar 2026 wurde durch eine zu geringe Beteiligung, teilweise zeitlich zu kurze Teilnahme einzelner Nodes (< 1Tag) und geografische Herausforderungen im Elbtal beeinträchtigt.

---

2. Positive Beobachtungen

– Direktverbindungen und kurze Strecken

Bei Direktverbindungen und 1-Hop-Verbindungen mit kurzen Distanzen zeigten sich deutliche Verbesserungen bei Zustellraten und -geschwindigkeit. Die Teilnehmer berichteten von spürbar schnelleren Antwortzeiten im City-Bereich.

– Geringere Latenz

Wenn Nachrichten erfolgreich übertragen wurden, erfolgte die Antwort praktisch sofort. Die Übertragungsgeschwindigkeit war deutlich besser als bei LongFast. Es konnte bei ausgewählten Verbindungen sogar ein Chat-Charakter erreicht werden.

– Höhere Datenrate

Die theoretisch höhere Übertragungsgeschwindigkeit von MediumFast (~3,9 kbps vs. ~1,9 kbps) konnte in optimalen Bedingungen nachgewiesen werden.

---

3. Kritische Probleme

– Mangelhafte Teilnahme

Von ca. 150 LongFast-Nodes haben nur ca. 30-37 Nodes zu Spitzenzeiten am Test teilgenommen (ca. 20-25%). Teilweise davon in territorial getrennten Bereichen. Diese geringe Beteiligung führte zu einem stark ausgedünnten Netzwerk.

– Multi-Hop-Verbindungen versagen

Bei Verbindungen über 2-3 Hops keine oder stark eingeschränkte Kommunikation möglich. Viele Traceroutes laufen ins Leere, obwohl nur 2-3 Hops angezeigt werden.

– Doppelte Paketübertragung

Positions-Broadcasts kommen doppelt an (z.B. über WdGa und W114). Problem: Nodes hören sich gegenseitig nicht und senden deshalb beide weiter.

– Netzwerk-Fragmentierung

Das ausgedünnte Netz führt vorrangig zu Weitverbindungen auf den Hops. Die geografischen Besonderheiten des Elbtals (Senke zwischen Hängen) verschärfen das Problem.

---

4. Bewertung und Ausblick

– Aktueller Status

Das Dresdner Mesh-Netzwerk ist mit MediumFast als Notfallkommunikations-medium derzeit nicht brauchbar – eine zuverlässige Kommunikation über zwei Hops ist kaum möglich.

– Hauptursachen für das Scheitern

• Zu geringe Teilnahmequote am Test (unter 25%)
• Kritische Masse für MediumFast noch nicht erreicht
• Geografische Herausforderungen des Elbtals erfordern mehr Nodes
• Fehlende Koordination und Dokumentation bei der Umstellung

---

5. Betrachtung zur Netzlast

Der Testlauf ein weiteres Thema deutlich gemacht:
unnötige Netzlast durch Telemetrie und automatisierte Funktionen.

– Positions-Daten / GPS

GPS und Positionsdaten werden von festen Nodes nur in ganz geringen Umfang benötigt.

Eine Aussendung im Abstand von 3 – 6 Stunden ist vollkommen zureichend.

Für Tracker wo eine Nachverfolgbarkeit gewünscht ist sollte die „intelligente Position“ verwendet werden. Bei dieser Funktion wird die Aussendung von Positionsdaten bewegungsabhängig gesteuert.

– Telemetrie-Dienste

Telemetrie sollte nur aktiviert sein, wenn sie tatsächlich benötigt wird.

Empfehlungen:

• Telemetrie nur bei aktivem Monitoring oder konkretem Analysebedarf einschalten
• sinnvolle Sendeintervalle wählen (keine unnötig kurzen Abstände)
• „mehr Daten“ bedeutet nicht automatisch „mehr Erkenntnis“, aber immer mehr Airtime

– Automatisierte Traceroutes

Auch automatisierte Traceroutes können das Mesh stark belasten.

Bitte beachten:

• keine hochfrequenten oder dauerhaften Traceroutes
• kein paralleles Traceroute-„Spamming“ über mehrere Nodes
• Traceroutes gezielt und zeitlich begrenzt einsetzen

Traceroutes sind ein Diagnosewerkzeug – kein Dauerbetrieb.

---

6. Fazit für Dresden

Der Test einer Umstellung zum Preset MediumFast hat wichtige Sachen aufgezeigt und Erkenntnisse gebracht, auch wenn das gewünschte Ergebnis nicht erreicht wurde.

Eine Umfrage auf unserem Telegram-Channel hat gezeigt:

Für 50% ist aktuell ist ein zusammenhängendes Mesh wichtiger als maximale Geschwindigkeit, weshalb LongFast wieder eingesetzt werden sollte.

Weiter 25% sind offen für weitere Tests mit MediumFast oder gar der Umstellung dahin.

Gleichzeitig zeigt sich aber auch für beide Presets:

Ein stabiles Mesh hängt nicht nur vom Preset ab, sondern auch vom verantwortungsvollen Umgang mit Telemetrie und Diagnosefunktionen.

Die Umstellung von LongFast auf MediumFast wird häufig vorgenommen, um die Bandbreite in dichteren Netzwerken zu erhöhen und Staus (Congestion) zu vermeiden, geht jedoch mit einer leicht verringerten Reichweite einher. 

Wichtige Vorbemerkung (Stand 2026)

Alle Knoten in Ihrem lokalen Mesh müssen dieselben LoRa-Einstellungen verwenden, um sich gegenseitig hören zu können. Eine schrittweise Umstellung führt dazu, dass Geräte auf verschiedenen Presets vorübergehend nicht mehr miteinander kommunizieren, es sei denn, es wird eine Bridge genutzt. 

Schritt-für-Schritt-Anleitung

1. LoRa-Modem-Preset ändern

Dies ist die wichtigste Hardware-Einstellung für das Funkmodul. 

• Android App: Gehen Sie zu Einstellungen > LoRa > Modem Preset und wählen Sie MEDIUM_FAST aus.
• iOS App: Navigieren Sie zu Settings > Radio Configuration > LoRa > Modem Preset und stellen Sie es auf MediumFast.
• Web UI: Unter Radio > LoRa das Dropdown-Menü für Modem preset auf MEDIUM_FAST ändern.
• CLI (Kommandozeile): Nutzen Sie den Befehl:
  meshtastic --set lora.modem_preset MEDIUM_FAST. 

2. Primären Kanal anpassen

Da der Standardkanalname oft fest mit dem Preset verknüpft ist, sollten Sie den Namen Ihres Hauptkanals (Index 0) explizit prüfen. 

• Kanalname: Ändern Sie den Namen von LongFast auf MediumFast.
• PSK (Verschlüsselung): Stellen Sie sicher, dass der Key weiterhin auf dem Standardwert AQ== (Base64) steht, sofern Sie ein öffentliches Mesh nutzen wollen. 

3. Frequenz-Slot (Frequency Slot) prüfen

In vielen Regionen (wie Nordamerika) ändert sich die Anzahl der verfügbaren Slots je nach Preset. 

• Stellen Sie sicher, dass der Frequency Slot auf dem für MediumFast in Ihrer Region üblichen Standardwert steht (am besten 0 für Automatik).

4. Optionale Anpassungen für Stabilität

• Hop Limit: Es wird oft empfohlen, das Hop-Limit bei MediumFast auf 5 zu erhöhen, um die schnellere Paketverarbeitung optimal zu nutzen.
• NodeDB Reset: Nach der Umstellung empfiehlt sich ein Reset der Knotendatenbank (Settings > Administration > NodeDB Reset), damit Ihr Gerät die Liste der erreichbaren Knoten unter den neuen Bedingungen neu aufbaut. 

Zusammenfassung der CLI-Befehle (für Fortgeschrittene)

meshtastic --set lora.modem_preset MEDIUM_FAST
meshtastic --ch-set name "MediumFast" --ch-index 0
meshtastic --set lora.hop_limit 5
meshtastic --reset-nodedb

Wer einen Raspberry Pi für die Smart-Home-Steuerung einsetzt, kennt das Problem vermutlich: Es hängen schnell mehrere USB-Geräte am Rechner, deren interne tty-Adresse sich nach dem Aus- und wieder Einstecken einfach ändern kann. Ist das USB-Gerät dann lediglich statisch z.B. per /dev/ttyUSB0 eingebunden, sind die Probleme vorprogrammiert. Gleiches Problem tritt auch bei über USB angeschlossenen Nodes mit Meshtastic auf.

Wie sich dieses zeitraubende Problem mit nur wenigen Befehlen in den Griff bekommen lässt und zudem die Übersichtlichkeit gesteigert werden kann, ist Inhalt des nachfolgenden Blogpost.

Unter Linux man die USB-Schnittstellen (wie /dev/ttyUSB0) durch udev-Regeln feste Namen in Form von symbolischen Links (Symlinks) zuweisen. Da sich die Standard-Kernelnamen bei jedem Neustart oder Umstecken ändern können, ermöglicht dies eine dauerhafte Adressierung Ihrer Geräte. 

1. Geräteinformationen auslesen 

Identifiziere zunächst die eindeutigen Merkmale des USB-Geräts (z. B. Vendor-ID, Product-ID oder Seriennummer). Schließe das Gerät an und führe folgenden Befehl aus (ersetze ttyUSB0 ggf. durch den aktuellen Namen): 

udevadm info -a -n /dev/ttyUSB0

Notiere dir die Werte für idVendor, idProduct und idealerweise die serial. 

2. udev-Regel erstellen

Erstelle eine neue Regeldatei im Verzeichnis /etc/udev/rules.d/. Der Dateiname muss auf .rules enden. 

sudo nano /etc/udev/rules.d/99-usb-namen.rules

Füge eine Zeile nach folgendem Muster ein:

SUBSYSTEM=="tty", ATTRS{idVendor}=="xxxx", ATTRS{idProduct}=="yyyy", ATTRS{serial}=="zzzz", SYMLINK+="mein_geraet"

Verwende Code mit Vorsicht.

• xxxx / yyyy: Die ausgelesenen IDs.
• zzzz: Die Seriennummer (wichtig, falls man zwei identische Adapter verwendet).
• mein_geraet: Der gewünschte feste Name. Das Gerät ist dann unter /dev/mein_geraet erreichbar. 

3. Regeln aktivieren

Lade die udev-Regeln neu, um die Änderungen ohne Neustart zu übernehmen:

sudo udevadm control --reload-rules
sudo udevadm trigger

📡 Wechsel von LongFast zu einem schnelleren Preset 🚀

Liebe Mesh-Community,

unsere Netzabdeckung steht mittlerweile richtig gut – Zeit, dass wir auch bei der Geschwindigkeit aufs nächste Level kommen!

Warum MediumFast ?

Preset	Datenrate	Reichweite	Airtime*	Best für
LongFast (aktuell)	~1,9 kbps	~10+ km	~2-6 Sek	Maximale Richweite
MediumFast	~3,9 kbps	~5-8 km	~1-3 Sek	Balanciert
ShortFast	~10,9 kbps	~2-4 km	~0,3-1 Sek	Dichte Netze, Stadt

*Airtime = Zeit pro durchschnittlicher Nachricht

Konkret heißt das:

• 📨 LongFast: Eine Textnachricht braucht ~3-4 Sekunden Sendezeit
• 📨 MediumFast: Dieselbe Nachricht in ~1-2 Sekunden – mehr als doppelt so schnell!
• 📨 ShortFast: Blitzschnelle ~0,5 Sekunden – bis zu 8x schneller!

Warum der Wechsel jetzt Sinn macht:

• ⚡ Deutlich schnellere Nachrichtenübertragung – Gespräche fühlen sich fast wie Echtzeit an
• 💬 Weniger Kanal-Belegung – mehr Nodes können parallel senden
• 📊 Besserer Durchsatz – optimal für unsere gewachsene, gut vernetzte Community
• 🔋 Geringerer Stromverbrauch – kürzere Sendezeiten schonen den Akku

Was ändert sich? Mit einem schnelleren Preset tauschen wir etwas Reichweite gegen spürbar höhere Geschwindigkeit. Da unser Mesh inzwischen gut ausgebaut ist mit vielen Repeatern dazwischen, können wir uns das problemlos leisten!

Meine Empfehlung: MediumFast

• Immer noch solide 5-8 km Reichweite
• Doppelte Geschwindigkeit gegenüber LongFast
• Perfekter Kompromiss für unsere Netzstruktur

Der Plan: Um einen reibungslosen Test und vielleicht auch späteren Übergang zu gewährleisten, würden wir gerne ab 31.01.2026 für eine Woche gemeinsam umstellen und testen.

Eure Meinung zählt! Welches Preset bevorzugt ihr? Schreibt eure Gedanken!

• 🟢 MediumFast (meine Empfehlung)
• 🔵 ShortFast (wenn euer Gebiet sehr dicht ist)
• 🟡 Bleibt bei LongFast (wenn ihr viele Randgebiete bedient)

Lasst uns gemeinsam schneller werden! 💪

Was für die Umstellung auf MediumFast zu tun ist findet ihr in diesen Beitrag.

Dazu gern hier Kommentare hinterlassen…. oder unter https://t.me/mesh_dresden/176 mit diskutieren.

---

Übersicht der drei ausgewählte Netzwerke

Mesh Hessen – ShortSlow (bereits umgestellt)

• Preset: LongFast → ShortSlow
• Netzwerkgröße: Über 150 aktive Nodes
• Strategie: Radikalste Umstellung für maximale Effizienz
• Grund: Netzwerküberlastung durch hohe Node-Dichte

Mesh Berlin – MediumFast (bereits umgestellt)

• Preset: MediumFast auf 868 MHz
• Strategie: Pragmatischer Mittelweg
• Besonderheit: Nutzung beider Frequenzen (433 MHz und 868 MHz)
• Vorteil: Balance zwischen Reichweite und Geschwindigkeit in urbaner Umgebung

Mesh Kiel – MediumFast (in Testphase)

• Preset: LongFast → MediumFast (Test)
• Testlauf: 26. Januar bis 1. Februar 2026
• Abdeckung: Stadtgebiet Kiel plus angrenzende Kreise
• Besonderheit: Strukturierter, datengetriebener Testansatz mit wissenschaftlicher Auswertung

Warum die Umstellung notwendig wird

Probleme mit LongFast bei wachsenden Netzwerken:

• Hohe Airtime-Auslastung
• Steigende Latenzen
• Erhöhte Kollisionswahrscheinlichkeit
• Ineffizientes Routing bei vielen aktiven Teilnehmern

Vorteile schnellerer Presets (MediumFast/ShortSlow):

• Höhere effektive Datenrate
• Geringere Airtime pro Nachricht
• Stabileres Routing bei hoher Node-Dichte
• Reduzierte Latenz
• Verbesserte Zuverlässigkeit und Nutzererfahrung

Preset-Spektrum (schnell → langsam)

1. SHORT_TURBO – Schnellste, kürzeste Reichweite
2. SHORT_FAST / SHORT_SLOW
3. MEDIUM_FAST ← Berlin & Kiel
4. LONG_FAST ← Standard (ursprünglich alle drei)
5. LONG_SLOW
6. VERY_LONG_SLOW – Langsamste, längste Reichweite

Kiels methodischer Ansatz

Testdesign:

• Einwöchiger strukturierter Testlauf
• Feedback über Telegram und E-Mail
• Fokus auf messbare Daten: RSSI, SNR, Hop-Anzahl, Routing-Verhalten
• Abschlussbericht nach Testwoche geplant

Aufgaben für Node-Betreiber:

• Umstellung auf MediumFast
• Beobachtung der Netzwerkparameter
• Dokumentation von Auffälligkeiten

Kritischer Hinweis zur Kompatibilität

⚠️ Nodes mit unterschiedlichen Presets können nicht miteinander kommunizieren, auch wenn sie die gleiche Frequenz nutzen. Während der Umstellungsphase sind Nodes mit alten Presets faktisch vom Mesh isoliert.

Entwicklungstrend

Gemeinsame Erkenntnis aller drei Netzwerke: Bei wachsender Netzwerkgröße stößt das Standard-Preset LongFast an seine Grenzen. Der Wechsel zu schnelleren Presets verbessert die Netzwerkeffizienz erheblich – die theoretisch reduzierte Reichweite wird durch höhere Datenrate, geringere Airtime und Multi-Hop-Routing mehr als kompensiert.

Entwicklungsstufen:

1. Hessen: Vorreiter, größtes Netzwerk, radikalste Lösung
2. Berlin: Etablierter Mittelweg in urbaner Umgebung
3. Kiel: Aktuell in professionell durchgeführter Testphase

---

Stand: Januar 2026