Eine vollständige Ursachenanalyse

MeshDresden · Kategorie: Technik · Zielgruppe: Repeater-Betreiber und fortgeschrittene Nutzer

---

---

MeshCore gilt als robust – und ist es auch. Trotzdem gibt es Situationen, in denen Nachrichten lautlos verschwinden: keine Fehlermeldung, keine Bestätigung, kein Hinweis. Wer das zum ersten Mal erlebt, sucht zuerst am falschen Ort.

Dieser Bericht systematisiert alle bekannten Ursachen für Nachrichtenausfälle in MeshCore – vom physikalischen Layer bis zur Firmware-Konfiguration. Viele davon betreffen direkt den path.hash.mode und die damit zusammenhängenden Firmware-Versionen. Andere haben damit gar nichts zu tun, sind aber genauso tückisch.

---

Überblick: Die Ursachen auf einen Blick

Nachrichtenausfälle in MeshCore lassen sich in fünf Kategorien einteilen:

1. Firmware-Inkompatibilität – falscher path.hash.mode trifft alten Repeater
2. Uhren- und Timestamp-Probleme – Replay-Protection greift zu Unrecht
3. LoRa-Physik und Funkstrecke – Signal kommt schlicht nicht an
4. Duty-Cycle und Airtime – der Repeater schweigt aus gesetzlichen Gründen
5. Routing- und Konfigurationsfehler – falsche Pfade, flood.max, Regionfilter

---

1. Firmware-Inkompatibilität durch path.hash.mode

Das Problem

Seit Firmware-Version 1.14 unterstützt MeshCore drei Hash-Größen für den Path-Eintrag im Paket: 1, 2 oder 3 Bytes pro Repeater-Hop. Der Modus wird mit set path.hash.mode am Repeater gesetzt und bestimmt auch, welchen Modus der Repeater beim Weiterleiten seiner eigenen Adverts verwendet.

Das kritische Problem: Repeater mit Firmware ≤ 1.13 droppen alle Pakete mit 2- oder 3-Byte-Path-Hash kommentarlos. Es gibt keine Fehlermeldung. Die Nachricht verschwindet im Netz, ohne dass Sender oder Empfänger etwas merken.

Die drei Modi im Vergleich

Modus	Bytes/Hop	Max. Hops (Flood)	Eindeutige IDs	Firmware-Anforderung
0	1 Byte	63	254	alle
1	2 Bytes	31	65.536	≥ 1.14
2	3 Bytes	21	16.777.216	≥ 1.14

Der Path ist im Paket auf 64 Bytes begrenzt. Daraus ergibt sich die maximale Hop-Anzahl je Modus: max_hops = 64 / hash_size.

Paketstruktur im Überblick

Das path_len-Byte kodiert Hash-Größe und Hop-Anzahl gemeinsam:

path_len = ((hash_size - 1) << 6) | (hop_count & 63)

Firmware ≤ 1.12 verstand diese Kodierung nicht und droppte Pakete mit mehr als 64 Path-Bytes. Ab 1.14 wird das Feld korrekt interpretiert.

Firmware-Kompatibilitätsmatrix

Wann ist mode 1 oder 2 sicher?

• Für Adverts des Repeaters: Sofort nach Update auf ≥ 1.14 sinnvoll. Analyse-Tools wie LetsMesh.net können Repeater mit 2- oder 3-Byte-Hashes zuverlässiger unterscheiden. Pre-1.14-Repeater droppen diese Adverts, was aber die Netzfunktion nicht beeinträchtigt.
• Für Channel- und Direktnachrichten: Erst dann umstellen, wenn die große Mehrheit der aktiven Repeater im regionalen Netz auf ≥ 1.14 aktualisiert ist. Der Sender legt den Modus fest, nicht der Repeater.
• Companion App: Mode 1 und 2 sind erst ab App-Version 1.41.0 in den experimentellen Einstellungen verfügbar (Einstellungen → Experimentelle Einstellungen).

Auswirkung auf Nachrichtenlänge

Der nutzbare Textplatz reduziert sich mit steigendem Modus und steigender Hop-Anzahl, bleibt aber in der Praxis unkritisch:

Hops	Text-Bytes mode 0	Text-Bytes mode 1	Text-Bytes mode 2
3	172 B	168 B	162 B
5	170 B	166 B	160 B
10	165 B	155 B	139 B
21	154 B	121 B	84 B
31	144 B	83 B	—

(Direktnachricht, 9 Byte Overhead für dest_hash + src_hash + MAC + Timestamp + type)

Fazit: Die Nachrichtenlänge ist in der Praxis kein limitierender Faktor. Das entscheidende Problem ist die Firmware-Kompatibilität – nicht die Payload-Größe.

---

2. Uhren- und Timestamp-Probleme

Dies ist eine der häufigsten und am schwierigsten zu diagnostizierenden Ursachen für Nachrichtenausfälle in autonomen Repeater-Setups.

Wie Timestamps in MeshCore funktionieren

Jede MeshCore-Nachricht enthält einen 32-Bit-Unix-Timestamp (Sekunden seit 1.1.1970). Dieser Timestamp dient zwei Zwecken:

1. Replay-Protection: Der Empfänger akzeptiert eine Nachricht nur, wenn ihr Timestamp größer ist als der zuletzt gesehene Timestamp desselben Senders. Nachrichten mit altem Timestamp werden als möglicher Replay-Angriff gewertet und lautlos verworfen.
2. Advert-Gültigkeit: Adverts werden ebenfalls anhand ihres Timestamps validiert. Ein Advert mit einem Timestamp in der Vergangenheit wird vom Empfänger ignoriert.

Das Clock-Problem bei autonomem Betrieb

Die vier Fehlerszenarien

Szenario 1 – Neustart ohne Zeitquelle:
Ein Repeater ohne RTC und ohne aktive GPS- oder NTP-Synchronisierung greift nach einem Neustart auf den zuletzt im persistenten Speicher gesicherten Timestamp zurück – sofern ein solcher vorhanden ist. Hatte der Repeater zuvor eine funktionierende Zeitquelle (z.B. eine Remote-Management-Verbindung oder GPS), überlebt dieser Wert den Neustart im Flash und wird als Startzeit verwendet. Fehlt jeder gespeicherte Wert, fällt die Firmware auf einen eingebetteten Fallback zurück – je nach Build das Compile-Datum oder ein hardcodierter Standardwert. In beiden Fällen kann die resultierende Uhrzeit erheblich von der tatsächlichen Zeit abweichen, was dazu führt, dass Adverts und Nachrichten von anderen Knoten als veraltet verworfen werden.

Szenario 2 – Clock drift in die Zukunft:
Wenn ein Repeater-Clock versehentlich in die Zukunft springt, kann die Uhr anschließend nicht mehr rückwärts korrigiert werden – die Firmware akzeptiert keine Clock-Synchronisierung, die die Uhr rückwärts stellt. Einziger Ausweg: vollständiger Stromabbruch inklusive Batterie und Solar.

Szenario 3 – Companion-App synchronisiert falsche Zeit:
Die iOS-App hatte zeitweise einen Bug, bei dem sie die Zeit des Companion-Radios statt der Telefonuhr für die Clock-Synchronisierung eines Repeaters verwendete. War das Companion-Radio nicht korrekt gestellt, bekam der Repeater eine falsche Zeit.

Szenario 4 – Autonomer Repeater ohne Clock-Sync:
Ein Repeater ohne GPS und ohne regelmäßige Remote-Management-Verbindung driftet über Monate. Die Replay-Protection greift zunehmend fehlerhaft, der Repeater wird effektiv aus dem Netz ausgeschlossen – ohne jede Fehlermeldung.

Gegenmassnahmen

Maßnahme	Aufwand	Wirkung
RTC-Modul (z.B. DS3231)	mittel	permanente Zeithaltung über Neustarts
GPS-Modul + gps sync CLI	mittel	sehr genaue Zeit, automatisch
Regelmäßige Remote-Management-Verbindung	gering	Clock-Sync via Smartphone
Cron-Job mit meshcore-cli / Python	mittel	programmatische Synchronisierung

Für den Funkturm Wilsdruff: Der Repeater läuft solar-powered autonom. Ohne RTC-Modul oder GPS ist ein Clock-Reset nach Stromausfall wahrscheinlich. Empfehlung: RTC-Modul nachrüsten oder in meshcore-bot-web eine regelmäßige Clock-Synchronisierung per Python-meshcore-Paket implementieren.

---

3. LoRa-Physik und Funkstrecke

Nicht jeder Nachrichtenausfall hat eine Software-Ursache. Die Physik des LoRa-Übertragungswegs ist mindestens genauso wichtig.

SNR und Empfangsqualität

SNR	Bewertung	Zuverlässigkeit
> +5 dB	gut	sehr hoch
−5 bis +5 dB	moderat	schwankend
< −5 dB	schlecht	Paketverluste wahrscheinlich

Weitere physikalische Ursachen

Kollisionen durch simultane Übertragungen: LoRa-Pakete belegen die Frequenz für die gesamte Time-on-Air – bei SF12 und 125 kHz Bandbreite können das mehrere Sekunden sein. MeshCore begegnet dem durch randomisierte Weiterleitungsverzögerungen (txdelay), aber in dichten Netzen bleibt Kollision ein relevanter Faktor.

Channel Activity Detection (CAD): Bevor ein Repeater sendet, prüft er ob der Kanal frei ist. Ist er für mehr als 4 Sekunden belegt, verwirft der Repeater das Paket mit einem Timeout-Fehler.

Frequenz- und Parametermismatch: Sender und Empfänger müssen auf exakt denselben Parametern funken (Frequenz, BW, SF, CR). Ein einziges abweichendes Bit führt zu totalem Ausfall ohne jede Rückmeldung.

Verschlüsselungsmismatch: Wenn der empfangende Knoten den falschen Channel-Schlüssel hat, kann er die Nachricht nicht entschlüsseln – sie wird lautlos verworfen.

---

4. Duty-Cycle, Airtime-Limiter und EU-Regulierung

Das gesetzliche Rahmenproblem

Im EU-Frequenzband 869,525 MHz gilt ein gesetzlicher Duty-Cycle von maximal 10%. Das bedeutet: Pro Stunde darf ein Sender maximal 360 Sekunden senden.

Einstellung	Effective Duty-Cycle	EU-konform
af = 1 (Default)	~50%	NEIN
af = 2	~33%	nein
af = 9	~10%	ja
set dutycycle 10	10%	ja

Wichtig: Der Standardwert af = 1 ist in Deutschland nicht gesetzeskonform. Repeater-Betreiber sind dafür verantwortlich, den korrekten Wert zu setzen.

Wie der Limiter Nachrichten verwirft

Wenn ein Repeater seinen Duty-Cycle ausgeschöpft hat, schweigt er. Er empfängt Pakete, leitet sie aber nicht weiter. Aus Sicht des sendenden Clients sieht es aus wie ein Funkausfall oder ein toter Repeater.

Der neue dutycycle-Befehl (ab Firmware 1.15.0)

set dutycycle 10    # EU-konform, 10% Limit
set dutycycle 50    # alter Default (nicht EU-konform)
set dutycycle 100   # kein Limit (nur für Tests!)

---

5. Routing- und Konfigurationsfehler

Veralteter direkter Pfad (stale path)

MeshCore lernt beim ersten erfolgreichen Flood-Durchlauf den direkten Pfad zu einem Knoten und speichert ihn. Fällt ein Repeater im gespeicherten Pfad aus, schlägt die Nachricht dreimal fehl, bevor der Client den Pfad zurücksetzt und erneut flutet. In dieser Übergangszeit kommen Nachrichten nicht an.

flood.max zu niedrig

set flood.max 64    # Default, empfohlen
set flood.max 10    # würde Pakete nach 10 Hops still verwerfen

Loop-Detection mit Hash-Kollision

Stufe	1-Byte-Hash	2-Byte-Hash
minimal	≥ 4× eigene ID verwirft	≥ 2× eigene ID verwirft
moderate	≥ 2× eigene ID verwirft	≥ 1× eigene ID verwirft
strict	≥ 1× eigene ID verwirft	≥ 1× eigene ID verwirft

Bei strict mit 1-Byte-Hashes und Kollisionen kann ein Repeater legitime Pakete verwerfen, weil er glaubt, sie bereits gesehen zu haben. Das ist ein direktes Zusammenspiel von Loop-Detection und dem Kollisionsproblem bei mode 0.

Regionfilter und Kanalschlüssel

Ein falsch konfigurierter Regionfilter (REGION_DENY_FLOOD, REGION_DENY_DIRECT) oder ein falscher Channel-Schlüssel führen ebenfalls zu stillen Drops ohne Fehlermeldung.

---

Diagnose: Systematisches Vorgehen

Schritt 1 – Firmware-Version prüfen

get fw.version

Ziel: alle Repeater im Netz auf ≥ 1.14. Veraltete Firmware ist die häufigste Ursache für stille Drops bei mode 1/2.

Schritt 2 – Clock-Status prüfen

get time

Das Ergebnis sollte einem plausiblen Unix-Timestamp entsprechen (≥ 1.700.000.000 für das Jahr 2023+). Ist der Wert deutlich niedriger, läuft die Uhr falsch.

Schritt 3 – Airtime und Duty-Cycle prüfen

get dutycycle    # ab v1.15.0
get af           # vor v1.15.0
get stats        # TX/RX-Counts, Airtime, Uptime

Schritt 4 – Nachbarn und SNR analysieren

get neighbors

Zeigt die zuletzt gesehenen Nachbarknoten mit Timestamp und SNR (Wert × 4). Ein Repeater ohne Nachbarn hat entweder ein HF-Problem oder ist ausgefallen.

Schritt 5 – Hash-Mode im Netz erfassen

Über LetsMesh.net lässt sich ablesen, welche Repeater 1-, 2- oder 3-Byte-Adverts senden – ohne jeden Repeater einzeln abzufragen.

---

Zusammenfassung: Ursachen und Gegenmassnahmen

Ursache	Symptom	Lösung
path.hash.mode 1/2 + pre-1.14-Repeater	stilles Drop	Firmware-Update oder mode 0 behalten
Falsche Repeater-Uhr	Replay-Drop, Advert-Ignore	RTC, GPS oder regelmäßige Clock-Sync
Clock in der Zukunft	Sync nicht möglich	Vollständiger Stromabbruch
Niedriger SNR	Paketverluste	Antennenoptimierung, Repeater-Positionierung
Kollisionen / CAD-Timeout	sporadische Ausfälle	txdelay erhöhen, Kanalauslastung reduzieren
Duty-Cycle erschöpft	Repeater schweigt	set dutycycle 10 (EU-konform)
Stale Path nach Repeater-Ausfall	3× Fehlschlag, dann Flood	normales Verhalten, kein Handlungsbedarf
flood.max zu niedrig	entfernte Knoten nicht erreichbar	Default 64 verwenden
Loop-Detection + Hash-Kollision	Pakete werden verworfen	mode 1 (mehr eindeutige IDs)
Falscher Channel-Schlüssel	stilles Drop	Kanalschlüssel auf allen Geräten prüfen
Regionfilter	Pakete werden geblockt	Region-Konfiguration prüfen

---

Quellen: MeshCore Dokumentation · MeshCore GitHub FAQ · MeshCore CLI Reference · EastMesh Wiki · MeshCore Switzerland Settings · GitHub Issues #1329, #1332, #1882, #2047

Gezielte Nachrichtenweiterleitung im Mesh-Netz

Mit der Einführung von Regions in MeshCore steht Betreibern und Nutzern ein mächtiges Werkzeug zur Verfügung, um die Netzlast zu reduzieren und Kanal-Nachrichten gezielt auf bestimmte geografische Bereiche zu beschränken. Was steckt dahinter – und was bedeutet das konkret für unser Dresdner Netz?

Warum Regions?

Regions wurden eingeführt, um die Last im Mesh-Netz zu begrenzen. Durch die Nutzung von Regions enthält das Netz weniger unnötige Hops. Bisher wurden Kanal-Nachrichten von jedem erreichbaren Repeater weitergeleitet – unabhängig davon, ob die Empfänger überhaupt in der Nähe waren. Mit Regions lässt sich das nun steuern.

Eine Diskussion in Dresden muss nicht in die ganze Welt verteilt werden. Genau das verhindert das Region-System.

Wichtig zu wissen: Regions gelten aktuell ausschließlich für Kanäle (Channels) und haben keinen Einfluss auf direkte Nachrichten (DMs).

Das Grundprinzip

Repeater unterstützen „Regionen“, für welche sie Nachrichten weiterleiten. Nutzerinnen und Nutzer definieren in Channels mit einem „Scope“, auf welche Region ihre Nachrichten beschränkt bleiben sollen.

Konkret läuft das so ab:

1. Ein Repeater-Betreiber konfiguriert eine oder mehrere Regions auf seinem Gerät.
2. Er legt fest, welche Regions weitergeleitet (allowf) werden sollen.
3. Die Nutzerin oder der Nutzer versieht eine Kanal-Nachricht mit einem Region-Flag.
4. Nur Repeater, die das entsprechende Region-Flag kennen, leiten die Nachricht weiter.

Standardmäßig ist ein Repeater auf * gesetzt – das bedeutet, er leitet Nachrichten ohne Region-Flag weiter. So wird verhindert, dass bestehende öffentliche Kanäle ohne Region-Konfiguration blockiert werden.

Region-Codes

Die Bezeichnungen folgen Konventionen, auf die sich Menschen nach Diskussionen geeinigt haben. Die technische Basis sind etablierte Standards:

• Länder: ISO 3166-1 alpha-2 (z. B. de für Deutschland)
• Bundesländer/Regionen: UN/LOCODE Subdivision Codes (z. B. de-sn für Sachsen)

Aktuell gibt es noch keine funktionierende Hierarchie: de und de-sn sind gleichwertige, unabhängige Scopes. Ein Repeater mit nur de-sn reagiert also nicht automatisch auf Nachrichten mit dem Flag de – deshalb ist es wichtig, mehrere Ebenen gemeinsam zu konfigurieren.

Empfohlene Einstellungen für den Großraum Dresden

Repeater im Großraum Dresden sollten folgende Regionen erlauben:

• europe
• de
• de-ost
• de-sn
• de-sn-vvo
• de-sn-dd

Das Eintragen mehrerer Regions ist besonders sinnvoll, wenn der Repeater geografisch an einer Grenze zu einer anderen Region liegt. Unser Funkturm Wilsdruff liegt beispielsweise zwischen mehreren Landkreisen – dort macht die vollständige Liste besonders viel Sinn.

Nutzerinnen und Nutzern mit Companions im Großraum Dresden empfehlen wir, standardmäßig einen dieser Scopes zu verwenden:

• de-sn
• de-sn-dd

Für den alltäglichen Stadt-Chat ist de-sn-dd die engste und sinnvollste Wahl – Nachrichten bleiben auf Dresden beschränkt und belasten das überregionale Netz nicht.

Konfiguration am Repeater

Per CLI

Wer seinen Repeater per serieller Konsole oder Remote-Admin verwaltet, setzt die Regions direkt:

region put europe
region put de
region put de-ost
region put de-sn
region put de-sn-vvo
region put de-sn-dd
region allowf europe
region allowf de
region allowf de-ost
region allowf de-sn
region allowf de-sn-vvo
region allowf de-sn-dd
region save

Per App

1. In der MeshCore-App am Repeater anmelden
2. Einstellungen öffnen → Manage Regions
3. Mit dem +-Symbol jede Region einzeln eintragen
4. Für jede Region auch Allow Flood aktivieren
5. Speichern – kein Neustart erforderlich

Regions in der Client-App setzen

Auch als normaler Nutzer kann man Nachrichten mit einem Region-Scope versehen:

1. Kanal öffnen
2. Menü oben rechts (drei Punkte) antippen
3. Set Region Scope wählen
4. Gewünschten Scope eintragen (z. B. de-sn-dd)

Die Möglichkeit, Kanal-Nachrichten auf lokale Repeater-Regions zu beschränken, wurde mit App-Version 1.38.0 im Januar 2026 eingeführt. Die Firmware-seitige Unterstützung mit den entsprechenden CLI-Befehlen kam bereits mit dem Release vom November 2025.

Kanäle in Dresden

In Dresden sind folgende Hashtag-Kanäle in Verwendung:

• #dresden – allgemeiner Chat
• #dd-ping – Tests
• #dd-repeater – Support rund um Repeater
• #dd-roomserver – Support rund um Room Server
• #dd-companion – Support rund um Companions
• #dd-meshcon – Real-Life-Treffen

Für Notfälle gilt die Konvention: #emergency. Den Notfunkkanal gerne mitlesen, aber nicht aus Spaß beschreiben.

Es gibt außerdem einen Test-Kanal #de-sn-dd, in dem Nutzerinnen und Nutzer z. B. mit dem gleichnamigen engen Scope experimentieren können.

Weiterführende Links

• 🔗 Deutschlandweite Basis-Regions
• 🔗 Regionale Regions der Communities
• 🔗 Meshcore Dresden

---

📡 Telegram: t.me/mesh_dresden | info@meshdresden.eu

Mehr Eindeutigkeit im wachsenden Mesh-Netz

Mit Firmware-Version 1.14 hat MeshCore eine wichtige Neuerung erhalten: den Multi-Byte Path Hash. Was es damit auf sich hat, warum das für wachsende Netze wie unser Dresdner Netz relevant ist – und was Repeater-Betreiber jetzt tun sollten, erklären wir hier.

Was ist ein Path Hash?

Wenn eine Nachricht das MeshCore-Netz durchläuft, hinterlässt jeder beteiligte Repeater eine kurze Kennung im Paket – den sogenannten Path Hash. Dieser Hash ist ein Ausschnitt aus dem öffentlichen Schlüssel des Repeaters.

Bisher verwendete MeshCore standardmäßig nur 1 Byte pro Repeater im Pfad. Das erlaubt zwar bis zu 64 Hops – reicht also für sehr große Netze –, hat aber einen Nachteil: Mit nur 1 Byte gibt es lediglich 254 mögliche eindeutige Werte (0x00 und 0xFF sind reserviert). In größeren oder überregional vernetzten Meshes wird es deshalb schnell zu Kollisionen kommen: zwei verschiedene Repeater teilen sich dann denselben Hash-Wert.

Das Netz funktioniert zwar weiterhin korrekt, denn Pakete werden trotzdem weitergeleitet. Aber Analyse-Tools wie der LetsMesh.net Analyzer oder MeshMapper können die Routen nicht mehr eindeutig darstellen – mehrere Repeater erscheinen dann als ein und dasselbe Gerät.

Multi-Byte Path Hash: die Lösung

Mit Firmware 1.14 wurde die Möglichkeit eingeführt, Path Hashes mit 1, 2 oder 3 Bytes zu verwenden. Die Unterschiede im Überblick:

Modus	Bytes	Mögliche IDs	Maximale Hops
0 (Standard)	1 Byte	254	64
1	2 Byte	65.534	32
2	3 Byte	~16 Mio.	21

Der Wechsel auf 2 Byte reduziert die Kollisionswahrscheinlichkeit drastisch – bei 32 möglichen Hops, die für die meisten Netze völlig ausreichend sind.

Was steuert path.hash.mode genau?

Der CLI-Befehl path.hash.mode auf einem Repeater legt fest, mit welchem Hash-Format der Repeater seine eigenen Adverts (also seine Ankündigungen im Netz) sendet.

Wichtig zu verstehen: Der Befehl beeinflusst nicht, welche Pakete der Repeater weiterleitet. Ein Repeater mit Firmware 1.14+ leitet Pakete mit 1-, 2- und 3-Byte-Hashes immer gleichermaßen weiter – unabhängig von der eigenen Einstellung.

Verfügbare Modi

set path.hash.mode 0   # 1-Byte-Hash (Standard, Kompatibilität mit älteren Firmwares)
set path.hash.mode 1   # 2-Byte-Hash (empfohlen für Repeater auf 1.14+)
set path.hash.mode 2   # 3-Byte-Hash (maximale Eindeutigkeit, 21 Hops)

Den aktuellen Wert auslesen:

get path.hash.mode

Path Hash Size für Nachrichten (Companion/App)

Neben dem Repeater-Setting gibt es auch auf Seite der Companion-App eine Einstellung für die Hash-Größe ausgehender Nachrichten:

Einstellungen (Zahnrad) → Experimental Settings → Default Path Hash Size

Hier kann zwischen 1-Byte, 2-Byte und 3-Byte gewählt werden. Diese Einstellung gilt dann für Kanal-Nachrichten und Direktnachrichten, die das Gerät selbst abschickt.

Achtung: Diese Einstellung sollte erst umgestellt werden, wenn der überwiegende Teil der Repeater im eigenen regionalen Mesh bereits auf Firmware 1.14+ läuft. Ältere Firmware-Versionen vor 1.14 können 2- und 3-Byte-Pakete nicht weiterleiten und lassen sie stillschweigend fallen.

Warum jetzt schon auf 2-Byte am Repeater wechseln?

Auch wenn im Dresdner Netz noch nicht alle Companion-Geräte auf 2-Byte-Nachrichten wechseln sollten, gibt es gute Gründe, die Repeater-Adverts bereits jetzt umzustellen:

• Bessere Netzwerkanalyse: Tools können Repeater mit 2-Byte-Adverts zuverlässiger auseinanderhalten.
• Kein Nachteil: Adverts mit 2 oder 3 Byte werden von allen 1.14+-Repeatern problemlos weitergeleitet.
• Community-Signal: Wer seinen Repeater auf Mode 1 oder 2 setzt, signalisiert damit, dass er bereits auf Firmware 1.14+ läuft – das hilft der Gemeinschaft einzuschätzen, wann der Gesamtumstieg sinnvoll ist.

2- und 3-Byte-Adverts haben eine etwas geringere Reichweite als 1-Byte-Adverts – aber ein Repeater muss seine eigene Anwesenheit ohnehin nicht über 21 oder 32 Hops hinaus ankündigen.

Empfehlung für Repeater-Betreiber in Dresden

Wer seinen Repeater bereits auf Firmware 1.14.0 oder neuer aktualisiert hat, kann path.hash.mode 1 (2-Byte) bedenkenlos setzen:

set path.hash.mode 1

Ein Neustart ist nicht erforderlich. Den Companion vorerst auf dem Standard-1-Byte-Modus belassen, bis sich die Community abgestimmt hat und die Repeater-Dichte auf 1.14+ ausreichend groß ist.

Welche Firmware dein Repeater aktuell läuft, lässt sich per CLI abfragen:

version

Firmware-Updates gibt es über den Web-Flasher: flasher.meshcore.co.uk

Weiterführende Links

• 🔗 MeshCore FAQ: Multi-Byte Path Hash
• 🔗 MeshCore CLI-Referenz: path.hash.mode
• 🔗 Firmware-Releases auf GitHub

---

📡 Telegram: t.me/mesh_dresden | info@meshdresden.eu

🗼 Funkturm Wilsdruff: Der erste Node ist da – jetzt fehlt noch der zweite!

Update März 2026 | MeshDD • Meshtastic Dresden

---

Es tut sich was! Seit unserem letzten Aufruf haben 8 großartige Menschen insgesamt 305 € gespendet – herzlichen Dank an alle, die dabei sind! Ihr habt uns bereits über ein Drittel des Weges gebracht.

Und noch eine echte Erfolgsmeldung: Der erste Node ist bereits beschafft! Ein autarker Meshtastic-Knoten für die Hühndorfer Höhe ist in den Startlöchern. Das ist nicht selbstverständlich – das ist eure Unterstützung in Hardware gegossen.

---

📊 So stehen wir

💰 Gespendet	355 € von 800 €
👥 Spender	9 Personen
📦 Nodes bereit	1 von 2
📅 Einweihung	11. April 2026

Wir sind auf einem guten Weg – aber die Zeit läuft. Bis zur feierlichen Einweihung des Denkmals am 11. April um 11 Uhr wollen wir beide Nodes live schalten: einen Meshtastic- und einen MeshCore-Knoten, vollständig solargestützt, vollständig autark.

Die verbleibenden 445 € gehen nicht nur in den zweiten Node – sondern auch in Montagezubehör und die handwerkliche Unterstützung bei der Installation. Antennenhalterungen, Kabel, wetterfeste Gehäuse, Befestigungsmaterial und die helfenden Hände, die das alles sicher auf der Hühndorfer Höhe in Position bringen – das alles kostet. Das klingt nach viel – aber wenn noch einmal 8 Menschen mitmachen, schaffen wir das locker.

---

🙌 Warum es sich lohnt

Die Hühndorfer Höhe ist geografisch einer der besten Standorte im Dresdner Raum: freie Sicht in alle Richtungen, exponierte Lage, ideal für große Reichweiten. Ein Node dort ist kein netter Zusatz – er ist ein echter Backbone-Knoten für das gesamte MeshDD-Netz.

Und der symbolische Wert ist einmalig: Wo einst ein 153 Meter hoher Sendemast Mittelwellenprogramme über Sachsen verteilte, entsteht jetzt ein freier, dezentraler Kommunikationsknoten. Alte Geschichte, neue Technologie, gleiche Idee: Menschen verbinden.

---

👉 Jetzt den zweiten Node ermöglichen

Jeder Betrag zählt – ob 5 €, 20 € oder mehr. Wer lieber Hardware beisteuern möchte (LoRa-Boards, Solarpanels, Gehäuse, Kabel), ist ebenfalls herzlich willkommen.

Spenden: https://gofund.me/f00d56d6f
Kontakt: info@meshdresden.eu | t.me/mesh_dresden

Wir sehen uns am 11. April auf der Hühndorfer Höhe. 📡

---

MeshDD – Meshtastic Dresden • vollständig ehrenamtlich • vollständig unabhängig

📡 Jetzt zählt jeder Euro – Spendenaufruf Funkturm Wilsdruff

MeshDD • April 2026

---

Wer unsere letzten Beiträge verfolgt hat, weiß: Der Funkturm Wilsdruff lebt wieder – zumindest als Denkmal auf der Hühndorfer Höhe. Der legendäre „Bleistift“, jahrzehntelang Wahrzeichen der sächsischen Rundfunklandschaft, kehrt am 11. April 2026 feierlich zurück. Und MeshDD ist live dabei.

Was im letzten Update schon klang wie ein konkreter Plan, ist jetzt harte Deadline: Weniger als fünf Wochen trennen uns noch von dem Moment, an dem zwei autarke Mesh-Nodes – einer Meshtastic, einer MeshCore – gleichzeitig vom besten Höhenstandort der Region ins Netz gehen sollen.

---

🛠️ Was wirklich dahintersteckt

Ein solcher Standort klingt glamourös. Die Realität ist: Akkus, Solarpanels, wetterfeste Gehäuse, Richtantennen, Blitzschutz, Kabel, Montagematerial – das summiert sich. Und dann ist da noch die Hubsteigervermietung, ohne die an der Montagehöhe schlicht nichts geht. All das muss vor dem 11. April beschafft, geliefert, getestet und montiert sein.

MeshDD arbeitet 100 % ehrenamtlich. Es gibt keine Fördergelder, keinen Sponsor, keine stille Kasse im Hintergrund. Was wir einsetzen können, kommt direkt aus der Community.

---

💶 Kleinvieh macht auch Mist

Wir sagen das ohne Ironie und ohne falsche Bescheidenheit: Auch 5 Euro helfen. Wirklich. Wenn 30 Menschen 5 Euro geben, ist ein SolarNode finanziert. Jede Überweisung, jede GoFundMe-Beteiligung bringt uns einen Schritt weiter – und keinen Schritt zurück.

Wir planen außerdem eine Ausfallreserve: Hardware, die im Lager bleibt, damit der Node bei einem Defekt nicht wochenlang offline ist. Auch das kostet Geld. Auch dafür bitten wir um Unterstützung.

👉 Jetzt spenden – direkt und unkompliziert:
https://gofund.me/f00d56d6f

---

📦 Hardware willkommen

Wer statt Geld lieber Hardware beisteuern möchte – umso besser! Gesucht sind vor allem:

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

Meldet euch einfach im Telegram-Kanal oder per Mail an info@meshdresden.eu – wir klären dann den Rest.

---

📅 Der Countdown läuft

Am 11. April 2026 um 11 Uhr wird auf der Hühndorfer Höhe Geschichte geschrieben – ein wiedergeborenes Denkmal, und mittendrin zwei freie, autarke Mesh-Knoten, die ohne Internet, ohne Mobilfunk, ohne zentrale Infrastruktur kommunizieren.

Das ist nicht nur ein technisches Projekt. Das ist ein Zeichen dafür, dass freie Kommunikation funktioniert – auch wenn sonst nichts mehr geht.

Seid dabei. Unterstützt uns. Jetzt.

📬 Telegram: t.me/mesh_dresden
📧 E-Mail: info@meshdresden.eu
🌐 Web: meshdresden.eu

---

MeshDD – Meshtastic Dresden • vollständig ehrenamtlich • vollständig unabhängig