Für Neueinsteiger:innen - der Schnellstart im MeshCore-Netz Bayern

mschuster91 · 16. Mai 2026 um 09:47

Servus,

schön, dass Du Dich für MeshCore interessierst! Hier einige kurze Hinweise zur optimalen Konfiguration:

Allgemein - Companions und Repeater

Als Frequenz-Preset verwenden wir in gesamt Deutschland „EU/UK Narrow“ - 869.618 MHz auf 62.5 kHz Bandbreite, Spreading Factor (SF) 8, Codierungsrate (CR) 8. Eine andere Frequenz, Bandbreite oder Spreading Factor führt dazu, dass Dein Node andere Nodes nicht hört und umgekehrt Dein Node nicht gehört wird. Der CR-Parameter kann geändert werden, aber CR8 stellt einen guten Kompromiss zwischen Störfestigkeit und Sendedauer dar. Diese Einstellung kann man in der App unter „Einstellungen“ setzen:

Die Netzkapazität von MeshCore ist begrenzt. Auf der von MeshCore genutzten Frequenzzuteilung der Bundesnetzagentur, Verfügung 91/2025 Nr. 54 (Seite 17), sind 500 mW ERP und entweder eine zertifizierte Störungsminderungs-Technik oder ein Arbeitszyklus von <= 10% innerhalb einer fortschreitenden Stunde (Seite 3) vorgeschrieben. Bei einer durchschnittlichen Sendezeit von 1 Sekunde pro Paket ergibt sich also, dass ein Repeater maximal 360 Pakete pro Stunde senden darf.
Um die Reichweite von Kanal-Nachrichten nicht ins Endlose ansteigen zu lassen (und damit die knappe Netzkapazität sinnlos aufzubrauchen), kann man als Sender eines Pakets „Regionen“ (oder Scopes, die Begriffe sind äquivalent) auf der Ebene eines jeden Kanals setzen. Die in Bayern verwendeten Regions gibt es im Wiki zu lesen, am Ende dieses Beitrags gibt’s die für (Süd-)Bayern und München relevanten Regionen und empfohlenen Kanäle. Dadurch verwerfen Repeater, die die Region eines Paketes nicht in ihrer Allow-Liste eingetragen haben, dieses Paket und sparen sich so eigene Airtime.
Plakatives Beispiel: würde ein Niederbayer ein „I ess jetz erst amoi a Lebakassemme“ in Public schreiben und das Paket käme bis nach Hamburg in Norddeutschland, dann könnte schon der Franke auf dem Weg nichts mehr damit anfangen, weil eine Semmel für ihn „Weckla“ heißt, und der Hamburger fragt sich, was ein „Lebakas“ ist. Also sollte der Niederbayer seine Nachricht mit de-by-ndb senden.
Bitte keine Experimente mit Home Assistant und ähnlichen Telemetrie-Integrationen mit hoher Traffic-Rate. Die Netzkapazität von MeshCore ist, wie geschrieben, sehr begrenzt und die Telemetrie stopft das Netz bereits massiv zu!
Für Tests bitte die Kanäle #bot und #test nutzen, idealerweise mit der Region des aktuellen Aufenthaltsorts, sonst kriegt man mit „ping“ ohne Region (oder mit de-by) z.B. in Landshut Antworten von mindestens 5 Bots.

Austausch mit anderen MeshCore-Interessierten

auf Telegram gibt es
- die bundesweite Gruppe Meshcore DE
- eine Gruppe für Landshut (bitte m.schuster91@googlemail.com anschreiben oder auf #landshut in MeshCore einmal vorstellen)
auf Whatsapp gibt es eine allgemeine Mesh-Gruppe mit einem Unterkanal für München
auf meshcore-de.fyi gibt es ein großes Wiki
In Landshut und München gibt es alle 4 Wochen einen User-Treff, jeweils Mittwoch 18:30. Für die Details zu Landshut bitte m.schuster91@googlemail.com anschreiben, für die nächste Runde in München einfach hier im Forum schauen.

Bots

Bitte Bots nur in #bot und #test oder privaten Kanälen einrichten. Im Public-Kanal wird sonst der Traffic zu viel (niemand möchte am Morgen aufwachen und erstmal 100 Nachrichten ohne Relevanz lesen), und generell sollte man als Betreiber:in eines Bots aufpassen, ob der Bot nicht z.B. durch zwischenzeitliche Lückenschlüsse redundant geworden ist.

Aus Nutzersicht… bitte Bots spärlich nutzen.

Repeater-Admins

Mehr Repeater sind prinzipiell immer gut. Damit es aber noch besser wird:

Bitte verwendet nach Möglichkeit die Evo-Firmware, diese bietet einige Vorteile gegenüber der Standard-Firmware.
Um den regulatorischen Anforderungen der ISM-Frequenzzuteilung zu entsprechen, darf die Airtime (also: wie viel % der Zeit in einer Stunde darf ein Repeater senden) maximal 10% betragen (siehe oben). Diese Einstellung lässt sich auf der CLI mit „set dutycycle 10“ setzen.
Bitte achtet darauf, dass eure Repeater entweder ein RTC (Real Time Clock)-Modul oder ein GPS-Modul mit Zeitsynchronisierung haben, ansonsten muss man der Erfahrung nach alle 3-4 Wochen sowie nach jedem Reboot manuell die Uhr über Verwalten => Uhr synchronisieren einstellen. Hat der Repeater keine halbwegs genaue Uhrzeit, werden dessen Advert-Pakete von anderen Knoten verworfen und die Verwaltung des Repeaters kann auch gestört sein!
Konfigurieren der Regions geht über Verwalten => Regions verwalten. Wichtig: nach dem Hinzufügen der Regions oben rechts den Speichern-Haken betätigen, sonst gehen die Regions nach einem Reboot verloren!

Bei Repeatern setzt der „Default Region Scope“ die Region für Flood-Adverts dieses Repeaters.
Das Zero-Hop-Advert Intervall beschreibt, alle wieviel Minuten (min. 60) der Repeater an seine benachbarten Repeater und Companions im direkten Einzugsbereich seinen Public Key und Namen schickt. Kann man locker auf 120 Minuten setzen, entweder per UI oder per CLI (set advert.interval 120).
Das Flood-Advert Intervall bestimmt, alle wieviel Stunden ein Flood Advert (d.h. ein Advert, das durch das gesamte Netz wabert) gesendet wird. Bitte auf 150h setzen - alles kürzer belastet das Netz zu sehr, alles über 168h/7 Tage hinaus verursacht, dass diverse Kartendienste das Paket als „veraltet“ einstufen.

Kanäle und Regions

Persönliche Empfehlung an Kanälen und dazu passenden Regions:

default region: de-by
Public: de-by
#muenchen: de-by-muc
#region-muc: de-by-emm
#bayern: de-by
#landshut: de-by-la
#ergolding: de-by-la
#ergoldsbach: de-by-la
#bot, #test, #ping: jeweilige Heimatregion, z.b. de-by-la - es bringt wenig wenn man auf eine „ping“-Anfrage in Landshut fünf Antworten von den Bots aus halb Bayern erhält.

Man kann für jeden Kanal eine eigene Region setzen, die für alle gesendeten Nachrichten gültig ist.

Die derzeit genutzten (und auf vielen Repeatern gepflegten) Regions in Südbayern grob zusammengefasst:

* ist nicht, wie im IT-Kontext üblich, eine Wildcard - die Konfiguration von * im Repeater beschreibt lediglich, wie der Repeater Pakete ohne gesetzte Region behandelt. Pakete mit einer dem Repeater unbekannten Region werden immer verworfen!
europe - würde, wenn die Lückenschlüsse im Mesh verschwinden, theoretisch für eine Verbreitung in ganz Europa sorgen. Ist quasi kaum noch irgendwo gesetzt.
de - gesamt Deutschland. Ist auf vielen exponierten (=auf Bergen und hohen Sendemasten untergebrachten) Repeatern aus einem ähnlichen Grund wie europe mittlerweile blockiert.
de-by: gesamt Bayern
de-by-obb & de-by-obay: gesamt Oberbayern
de-by-muc: Stadt und Landkreis München
de-by-ed: Stadt und Landkreis Erding
de-by-emm: Europäische Metropolregion München
de-by-ndb & de-by-nbay: gesamt Niederbayern
de-by-la: Stadt und Landkreis Landshut
isarmesh: Alles entlang der Isar

Idealerweise sollten auf allen Repeatern mindestens die Regions de-by, de-by-<Regierungsbezirk>, de-by-<Landkreis> und ggf. de-by-<Stadt> eingepflegt sein.

Dabei ist wichtig, dass alle Repeater entlang des gewünschten Pfades die jeweilige Region in ihrer „allow forward“-Liste drinnen haben, sonst „verfällt“ die Nachricht einfach irgendwann (was ja Sinn der Sache ist). Das bedeutet auch, dass man bei korrekter Einstellung z.B. nicht aus München heraus im Channel #landshut mit Landshutern reden kann und umgekehrt aus Landshut heraus mit Münchnern im Channel #muenchen reden kann, da die jeweiligen Repeater die „fremde“ Region nicht eingestellt haben.

Man kann die Liste pflegen, indem man im Public-Kanal rechts oben auf die 3 Punkte und dann auf „Region festlegen“ geht:

Die Default-Region lässt sich unter Einstellungen => Experimentelle Einstellungen setzen:

Da die Default-Region auch für die Pakete zur Discovery von Pfaden für Direktnachrichten genutzt wird, empfiehlt sich hier de-by, da de von immer mehr Repeatern verworfen wird.