Schlagwort: Mesh

Textnachrichten über zig Kilometer verschicken, ohne Mobilfunk, ohne Internet und ohne dass irgendwo ein Server stehen muss. Mit ein paar Euro Hardware und einer ordentlichen Antenne geht das inzwischen ziemlich gut. Die Technik dahinter heißt LoRa, und darauf laufen verschiedene Mesh-Projekte. Ich habe mich hier für MeshCore entschieden und betreibe inzwischen einen festen Repeater auf dem Dach, einen Node fürs Handy und einen fürs Auto. Weil… Weil ich wohl noch immer ein Tech Nerd bin, den man mit so etwas bekommt. Dezentral, offen, community und nützlich!

Daraus ist wieder mal eine kleine Serie geworden. Die Teile sind geschrieben und die Veröffentlichung ist wieder wöchentlich geplant, wie auch bei der Bios Serie. Das klappt ja so ganz gut, nur manche Links auf die Folgebeiträge sind damit eher eine Art Cliffhanger geworden; was aber auch zu einer Serie passt, oder? Dieser erste Teil erklärt, wie so oft, die Grundlagen: was LoRa auf der Funkseite macht, welche Regeln im 868-MHz-Band gelten, wie MeshCore Nachrichten durch das Netz bringt und warum ich nicht beim vorinstallierten Meshtastic geblieben bin. Am Ende findest du eine Übersicht über alle sechs Teile.

Was LoRa ist

LoRa (Long Range) ist ein Funkverfahren von Semtech. Es ist nur die physikalische Schicht, also wie Bits über die Luft gehen. LoRaWAN ist etwas anderes: ein Netzwerkprotokoll mit Gateways und zentralen Servern, wie man es von Sensoren und TTN kennt. MeshCore und Meshtastic nutzen dagegen nur die LoRa-Modulation und bauen ihr eigenes Mesh darauf.

Technisch ist LoRa ein Chirp-Spread-Spectrum-Verfahren. Ein Symbol ist ein Chirp, also ein Ton, dessen Frequenz gleichmäßig über die gesamte Bandbreite läuft. Die Information steckt darin, an welcher Stelle der Chirp startet. Der Empfänger korreliert gegen diese bekannte Form und kann ein Signal noch dekodieren, wenn es deutlich unter dem Rauschen liegt. Daher kommt die Reichweite. Wie sich das im Detail verhält, legen drei Parameter fest:

• Spreading Factor (SF) legt fest, wie viele Bits ein Symbol trägt, von SF5 bis SF12. Ein Symbol besteht aus 2^SF Chips. Jede Stufe höher verdoppelt die Symboldauer, das Signal wird robuster und lässt sich bei schlechterem Signal-Rausch-Abstand noch empfangen, braucht aber doppelt so lange.
• Die Bandbreite (BW) sagt, wie breit der Chirp ist, typisch 62,5, 125 oder 250 kHz. Schmaler heißt langsamer, aber auch weniger Rauschen im Empfänger.
• Die Coding Rate (CR) ist der Anteil der Vorwärtsfehlerkorrektur. Bei 4/5 kommen auf vier Nutzbits fünf gesendete, bei 4/8 acht. Mehr Redundanz kostet Sendezeit, verzeiht dafür kaputte Bits.

Bei SF8 und 62,5 kHz dauert ein Symbol 2^8 / 62.500 Hz, also rund 4,1 ms. Daraus ergibt sich die Airtime, die Zeit, die ein Paket den Kanal belegt. Und die ist bei LoRa die knappe Ressource. Es gibt nur einen Kanal, alle teilen ihn sich, und jede Millisekunde, in der ein Node sendet, kann kein anderer in Reichweite sinnvoll senden. Ein Mesh, in dem jeder Node alles wiederholt, läuft deshalb schnell voll.

Der Rahmen: 869,4 bis 869,65 MHz

In Europa funken MeshCore und Meshtastic im 868-MHz-Bereich. Dafür braucht man keine Lizenz, muss sich aber an die Allgemeinzuteilung halten. Für das Teilband, in dem die Community hier unterwegs ist, gelten laut BNetzA Vfg 91/2025 (Band 54, entspricht ERC REC 70-03) diese Eckdaten (die werden wir später noch wieder sehen und immer mal wieder kontrollieren, dass wir uns daran auch sicher halten):

• Frequenzbereich 869,4 bis 869,65 MHz
• maximal 500 mW ERP, das sind 27 dBm
• höchstens 10 % Duty Cycle, also maximal 360 Sekunden Sendezeit pro Stunde und Gerät

ERP heißt Effective Radiated Power und bezieht sich auf die Abstrahlung einer Dipolantenne. Wichtig ist: Der Antennengewinn zählt mit. Wer am Board 27 dBm einstellt und dann eine Antenne mit ein paar dBi Gewinn anschraubt, liegt drüber. Kabelverluste ziehen wieder etwas ab. Beim Heltec V4 mit seinem zusätzlichen Leistungsverstärker ist das kein theoretisches Thema, mit einer Außenantenne kommt man auf dem Papier schnell an die Grenze. Wie man das ausrechnet und warum Messen mit Hobby-Equipment schwierig ist, steht ausführlich in Teil 4.

Die 10 % Duty Cycle klingen nach viel. Bei Paketen, die eine Drittelsekunde bis eine ganze Sekunde dauern, ist ein viel genutzter Repeater aber schneller am Limit, als man denkt. Airtime zählt also zweimal, einmal auf dem gemeinsamen Kanal und einmal im eigenen Budget. Klingt schon fast wie Afu (Amateurfunk) und ja man beschäftigt sich zum Teil mit den gleichen Dingen und Physik.

Das Preset hier in der Region

Damit sich Nodes überhaupt hören, müssen Frequenz, Bandbreite, SF und CR exakt übereinstimmen. Die Community im Rheinland nutzt das Preset „EU/UK (Narrow)“. Bei mir sind das diese konfigurierten Werte:

Frequenz:    869.618 MHz
Bandbreite:  62.5 kHz
SF:          8
CR:          8   (= 4/8)

Nominell belegt der Kanal damit 869,618 MHz plus/minus 31,25 kHz, also 869,58675 bis 869,64925 MHz. Das liegt im Teilband, bis zur oberen Kante bleiben aber nur 750 Hz. Das ist die rechnerische Spanne aus Mittenfrequenz und Bandbreite, keine Messung der tatsächlichen Aussendung.

Schmale Bandbreite mit SF8 heißt nicht automatisch kurze Pakete. Ich habe das mit der Time-on-Air-Formel aus dem SX126x-Datenblatt nachgerechnet (16 Symbole Präambel, CRC an, expliziter Header), daneben das Meshtastic-Standardpreset LongFast:

Nutzlast	MeshCore SF8 / 62,5 kHz / CR 4/8	SF8 / 62,5 kHz / CR 4/5	Meshtastic LongFast SF11 / 250 kHz / CR 4/5
20 Byte	312 ms	239 ms	395 ms
50 Byte	542 ms	382 ms	641 ms
100 Byte	968 ms	648 ms	1010 ms
180 Byte	1623 ms	1058 ms	1583 ms

Die Airtime liegt also ungefähr auf dem Niveau von LongFast. CR 4/8 bringt Robustheit und bezahlt sie mit Sendezeit. Auch die theoretische Empfindlichkeit ist ähnlich, rund -130 dBm für SF8 bei 62,5 kHz gegenüber rund -131,5 dBm für SF11 bei 250 kHz. Beides sind gerechnete Schätzwerte, keine Messungen. Ich bin auch nur eine Wurst, korrigiert mich also bitte unbedingt. Einfach als Kommentar, oder ihr erreicht mich über einen anderen Weg, vielleicht sogar direkt über das MeshCore Netz? So kann ich lernen, besser werden, euch dankbar sein und es hier korrigieren.

Was MeshCore ist

MeshCore ist eine Open-Source-Firmware für LoRa-Boards wie den Heltec V4 oder RAK-WisBlock-Module. Es gibt sie in mehreren Varianten, und die Rolle eines Geräts steht damit fest:

• Ein Companion ist das Funkmodem für dein Handy oder deinen Rechner. Die Oberfläche und der Nachrichtenverlauf leben in der App, die per Bluetooth oder USB verbunden ist. Der Node selbst speichert Kontakte und puffert eingehende Nachrichten, solange das Handy weg ist.
• Ein Repeater ist Infrastruktur. Er läuft unbeaufsichtigt, idealerweise hoch oben, und leitet Pakete für andere weiter.
• Ein Room Server ist eine Art kleines Forum auf Funkbasis, dazu weiter unten mehr.

Diese Trennung ist der zentrale Unterschied zu einem Mesh, in dem jedes Gerät mitwiederholt. Bei MeshCore übernehmen das die Repeater. Meine Companions haben den Repeat-Modus aus. Einen eingeschränkten Companion-Repeat gibt es nur für spezielle Frequenzen. Und auch die Repeater wiederholen nicht blind alles: Berechtigte Repeater leiten weiter, abhängig von Scope, Duplikaterkennung, Hop-Limits und Airtime-Budget. Der Repeater-Modus an meinem Companion ist nicht dafür gedacht, wirklich als Repeater im ganzen Netzwerk zu arbeiten, sondern eher, wenn man mit einer kleinen Gruppe unterwegs ist, vielleicht sogar an einer Stelle, an welcher kein anderer Empfang ist und dennoch die Kommunikation sichergestellt sein soll. Klar es gibt den direkten Weg zwischen den einzelnen Geräten aber wenn man mit einer kleinen Gruppe eine längere Wanderung macht, kann es ja passieren, dass die ersten ein gutes Stück weiter vorne sind und die letzten deutlich zurück, dann kann ein Companion mit Repeater-Modus in der Mitte schon helfen, nur ist die Gruppe auf diesen speziellen Frequenzen dann raus aus dem Mesh-Rheinland-Netz.

Flood, Direct und Pfad-Hashes

MeshCore kennt zwei Arten, ein Paket zu verschicken. Beim Flood Routing sendet der Absender das Paket einfach aus, und jeder berechtigte Repeater, der es hört, sendet es nach einer kleinen zufälligen Verzögerung erneut. Die Verzögerung soll verhindern, dass mehrere Repeater gleichzeitig senden. Stellt euch einfach einen Saal voll Leute vor, wenn alle gleichzeitig schreien, hört man auch wieder nichts. Hört ein Repeater dasselbe Paket ein zweites Mal, verwirft er es. Dafür merkt er sich die Hashes der Pakete, die er gesehen hat, nicht die Kennungen der Nodes. Der Hash wird über Pakettyp und Nutzdaten gebildet, ohne Pfad. Die Liste ist ein Ringpuffer mit maximal 160 Einträgen, neue Einträge überschreiben die ältesten. „Dasselbe Paket ein zweites Mal“ erkennt der Repeater also nur, solange es noch in diesen letzten 160 Einträgen steht.

Gegen Schleifen gibt es einen eigenen Mechanismus, nur für Flood-Pakete. Der Repeater zählt, wie oft sein eigener Pfad-Hash schon im Pfad des Pakets steht, und leitet ab einer bestimmten Anzahl nicht mehr weiter. Wie streng das ist, stellt man mit set loop.detect auf off, minimal, moderate oder strict ein. Mit 2-Byte-Pfad-Hashes und minimal, wie bei mir, ist bei zwei Vorkommen Schluss. Details stehen in der MeshCore CLI-Doku zur Loop Detection.

Dabei wird übrigens die Uhr wichtig. Der Zeitstempel des Absenders steckt in den verschlüsselten Nutzdaten. Weil die Verschlüsselung deterministisch ist, ist er bei Textnachrichten das, was zwei gleiche Texte zu zwei verschiedenen Paketen macht. Bei Text- und Kanalnachrichten aus der App liefert die App diesen Zeitstempel vom Handy mit, da spielt die Uhr des Nodes keine Rolle. Seine eigene Uhr nutzt der Node aber für seine Adverts und für die Anmeldung an Repeatern und Room Servern. Beides ist über den Zeitstempel gegen Wiederholung geschützt: Ein Advert, das älter ist als das zuletzt gesehene, wird ignoriert, und eine Anmeldung mit älterem Zeitstempel als die letzte wird abgelehnt. Kommt ein Node nach einem Neustart mit falscher, zurückgestellter Uhr hoch, laufen seine Adverts und Anmeldungen also im Zweifel ins Leere, bis die Uhr wieder stimmt. Noch ein Grund für die RTC, zu der ich in Teil 3 komme.

Jeder Repeater hängt beim Weiterleiten eine kurze Kennung an das Paket, die ersten ein bis drei Bytes seines öffentlichen Schlüssels. MeshCore nennt das Pfad-Hash, es ist aber einfach der Anfang des Schlüssels. Ein Flood-Paket trägt also die Liste der Repeater mit, über die es gelaufen ist, zum Beispiel 84ca. Kommt eine Direktnachricht so beim Empfänger an, kennen beide Seiten damit einen funktionierenden Pfad.

Ab dann greift Direct Routing: Das Paket bekommt den bekannten Pfad mit, und nur der jeweils nächste Repeater in dieser Liste leitet weiter. Alle anderen bleiben still. Das spart eine Menge Airtime. Bricht der Pfad weg, etwa weil du mit dem Handy-Node unterwegs bist und ein anderer Repeater näher ist, fällt die Nachricht wieder auf Flood zurück, und der Pfad wird neu gelernt.

Wie groß so ein Pfad-Hash ist, legt der Absender fest, möglich sind 1, 2 oder 3 Byte pro Hop. Bei einem Byte kollidieren die Kennungen in einer so dichten Gegend wie hier ständig, deshalb bittet die lokale Community um 2 Byte. Warum das so ist und wo man es einstellt, steht in Teil 6.

Damit Nodes sich überhaupt kennen, gibt es Adverts. Ein Advert ist ein signiertes Paket mit öffentlichem Schlüssel, Name, Typ und optional einer Position. Repeater senden ihre Adverts in langen Abständen als Flood, hier in der Gegend typischerweise etwa alle 50 Stunden. Companions schicken ihr Advert normalerweise nur, wenn du es in der App auslöst. Die App legt gehörte Nodes dann als Kontakt an. Adverts zu spammen ist also eher nicht sinnvoll. Wenn du an einem neuen Ort bist oder neue weitere Companions in der Nähe sind, mit welchen du deinen „Kontakt“ teilen möchtest, dann hau halt einen Advert raus. Einfach so, doof. Kurz: Adverts am Companion senden, sollte immer einen Grund haben, den du erklären kannst. „Nur mal so“ ist dabei kein Grund.

Ein letztes Konzept nur als Vorgeschmack: Region-Scopes. Ein Flood-Paket kann eine Region wie de oder rheinland tragen, und Repeater entscheiden anhand dieser Markierung, ob sie es weiterleiten. Hier im Rheinland ist das der wichtigste Stellhebel überhaupt, er bekommt in Teil 6 den Platz, den es braucht.

Kontakte, Schlüssel und warum der Name nichts beweist

Jeder MeshCore-Node hat ein Ed25519-Schlüsselpaar. Der öffentliche Schlüssel ist 32 Byte lang und ist die eigentliche Identität. Der Name im Advert ist zwar von der Signatur abgedeckt, aber nicht eindeutig. Jeder kann seinen Node „Kernel-Error“ nennen. Ein Kontakt mit passendem Namen sagt also nur, dass irgendwer diesen Namen gewählt hat.

Wer denkt schon jetzt an Verschlüsselung? Ja, ich auch. Ihr wisst ja, wie gerne ich Verschlüsselung habe und diese gibt es auch hier. Vielleicht mit ein Grund, warum mich das Thema so abholt? Für Direktnachrichten leiten beide Seiten per ECDH aus ihren statischen Schlüsseln ein gemeinsames Geheimnis ab. Die Nutzlast wird mit AES-128 verschlüsselt, blockweise im ECB-Modus, und mit einem auf 2 Byte gekürzten HMAC-SHA256 abgesichert. Das spart Bytes, hat aber Folgen: keine Forward Secrecy, gleiche 16-Byte-Blöcke sehen unter ECB gleich aus, und ein gefälschtes Paket kommt mit einer Wahrscheinlichkeit von 1 zu 65.536 durch den MAC. Pfade und Pakettypen sieht ohnehin jeder, der mithört. Gegen neugierige Zuhörer reicht das. Für Vertrauliches nimm einen Ende-zu-Ende-Messenger.

Kanäle nutzen dagegen einen gemeinsamen 16-Byte-Schlüssel. Der des Public-Kanals ist überall derselbe, der Kanal ist also öffentlich. Ich habe auch noch ein paar Screenshots für euch, da habe ich öffentliche Informationen/Nachrichten auch nicht weiter versteckt. Weil, na sie eh für jeden öffentlich einsehbar sind 😀

Wenn du sicher sein willst, mit wem du schreibst, vergleichst du den öffentlichen Schlüssel über einen unabhängigen Weg, also persönlich per QR-Code, über einen bereits verifizierten Messenger oder am Telefon. Ein Advert mit dem richtigen Namen ist keine Verifikation. Wie das in der App aussieht, zeige ich in Teil 2, dort steht auch der Kontakt meines Companions.

Room Server

Kanäle sind reine Broadcasts. Wer gerade nicht empfängt, hat die Nachricht verpasst. Ein Room Server löst das wie ein kleines Schwarzes Brett: Mitglieder melden sich an, die letzten 32 Beiträge liegen in einem Ringpuffer auf dem Node und werden jedem angemeldeten Mitglied einzeln und verschlüsselt zugestellt. Wer beim Schreiben offline war, bekommt die verpassten Beiträge nach der nächsten Anmeldung nachgeliefert, aber nur, solange sie noch in diesen 32 Einträgen stehen. Ob ein Raum offen ist, entscheidet sein Betreiber über das Passwort. Hier in der Umgebung gibt es mehrere, darunter „Hi @ meshrheinland.de“ von der Community.

Warum MeshCore und nicht Meshtastic

Der Heltec V4 kam mit Meshtastic vorinstalliert, und Meshtastic ist ein ausgereiftes Projekt mit großer Verbreitung und guten Apps. Dort können je nach Rolle auch Endgeräte weiterleiten, MeshCore trennt Endgerät und Infrastruktur strikter. Entscheidend war für mich aber etwas anderes. Ein Mesh ist nur so gut wie die Nodes in Funkreichweite, also wollte ich wissen, was hier wirklich läuft.

Dafür habe ich am 10.10.2026 die öffentlichen Node-Listen beider Projekte als JSON gezogen, für Meshtastic von meshmap.net, für MeshCore von map.meshcore.dev. Ein kleines Python-Skript filtert nach Luftlinie um meinen Standort im Raum Rheinbach und nach dem Zeitpunkt, an dem der Server den Node zuletzt gesehen hat. Achtung, falls du das nachbaust: Nimm den serverseitigen Zeitstempel. Das Feld last_advert bei MeshCore stammt von der Uhr des Nodes, und die liegt teils Jahre daneben, manchmal auch in der Zukunft. Die Teile haben meist keine RTC und daher kommen die gerne beim Restart mit „irgendwas“ an Datum/Uhrzeit hoch. Keine Sorge, wie wir eine RTC dazu bekommen und das rebootfest machen, kommt auch noch.

Radius	MeshCore 24 h	Meshtastic 24 h	MeshCore 14 Tage	Meshtastic 14 Tage
1 km	4	0	5	0
5 km	4	0	6	0
10 km	7	3	11	3
20 km	33	5	62	5
40 km	91	20	192	20

Die Zahlen sind kumulativ. Von den 192 MeshCore-Nodes im 40-km-Radius waren 177 Repeater, 9 Room Server und 6 Companions. Der nächste MeshCore-Repeater stand nur wenige hundert Meter entfernt, der nächste Meshtastic-Router einige Kilometer.

Fair bleiben muss man trotzdem. meshmap.net kennt nur Meshtastic-Nodes, die über MQTT-Gateways gemeldet werden, und verwirft Positionen nach etwa 8 Stunden. Die 14-Tage-Spalte ist für Meshtastic deshalb strukturell zu niedrig, die 24-Stunden-Spalte ist der fairere Vergleich. Auch dort steht es bei 40 km noch 91 zu 20. Auf der anderen Seite beweist ein Eintrag auf der MeshCore-Karte keine nutzbare Funkverbindung. Die Einträge kommen von Uploadern und aus der App, Positionen können ungenau oder veraltet sein.

Dazu kommen die Funkparameter. 178 der 192 MeshCore-Einträge meldeten 869,618 MHz, 62,5 kHz, SF8 und CR 4/8, die übrigen 14 CR 4/5. Diese Werte meldet allerdings der empfangende Uploader, sie sind keine authentifizierte Angabe des Senders. An der Richtung ändert das nichts. Hier gibt es eine aktive MeshCore-Community, die Mesh Rheinland, mit klaren Empfehlungen für Preset und Konfiguration und mit CoreScope als Live-Karte und Paketanalyse. Bei Repeatern in ein paar hundert Metern Entfernung geht es für meinen Dach-Node also weniger um erste Abdeckung als darum, einen gut platzierten zusätzlichen Hop beizusteuern.

Wer lieber zuhört, dem empfehle ich den MRMCD-2026-Vortrag „MeshCore: Grenzenloser Spaß auf 868 MHz“ und den Beitrag „MeshCore: So kommuniziert ihr auch beim Blackout!“ von heise und c’t.

Mein Aufbau und die Serie

Stand Anfang November 2026 sieht mein Setup so aus: Ein Heltec V4 läuft als fester Repeater „DE-NW-SU-Todenfeld-KE“ in einem Aluminiumgehäuse auf dem Dachboden, mit Akku, Echtzeituhr und einer 5,8-dBi-Antenne am Satellitenmast über dem Dach. Strom und Logging kommen vom Raspberry Pi, der dort oben schon als ADS-B-Feeder arbeitet. Mein persönlicher Companion „Kernel-Error“ ist ein Heltec-V4-Komplettkit, das per Bluetooth am Handy hängt. Ein weiterer Heltec mit GPS fährt als „ErrorCar“ im Auto mit und sammelt Messpunkte für MeshMapper. Dazu kommt ein RAK3312 in einer Akkubox als portabler zweiter Repeater mit eigener Identität und ohne veröffentlichte Position. Ich vermute aber, dass der RAK ein Problemchen hat. Da wird es ggf. noch etwas außerhalb dieser Serie geben. Messen mit dem tinySA und einer 30 dB Dämpfung dazwischen um die Sendeleistung zu messen und so weiter und so weiter. Was ich ebenfalls noch im Sinn habe, ist ein Sensor, den jeder abfragen kann. Vielleicht für Luftqualität, radioaktive Strahlung, Temperatur usw. Aber das ist noch alles nicht gemacht und hängt davon ab, wie viel Zeit und Energie ich aufbringen kann; das ist im Moment Mangelware bei mir.

Die Serie geht diesen Weg der Reihe nach durch:

• Teil 1: LoRa, Routing und warum MeshCore. Das hier.
• Teil 2: Einstieg mit dem Companion. Heltec V4 flashen, mit der App koppeln, erstes Advert, Kontakte, Kanäle und Clients unter Linux.
• Teil 3: Der Repeater. Standort, Gehäuse, Akku, RTC, Schlüssel, Logging über den Pi und Firmware-Updates.
• Teil 4: Antennen und Messen. dBi, ERP, Kabelverluste, Stecker, SAW-Filter und was der tinySA dazu sagt.
• Teil 5: MeshMapper. Abdeckung mit dem Auto-Node kartieren, ohne die eigene Position zu verraten.
• Teil 6: Konfiguration, die zählt. Region-Scopes, Pfad-Hash, Duty Cycle, Advert-Intervalle und das Community-Rezept als Checkliste.

Bevor du Hardware kaufst

Schau in die Karte deiner Community, bevor du dich für ein Projekt entscheidest. Auf map.meshcore.dev und meshmap.net siehst du in ein paar Minuten, was in deiner Gegend wirklich aktiv ist, und wenn es eine lokale Gruppe gibt, verrät die dir auch das passende Preset. Wenn MeshCore bei dir lebt, geht es in Teil 2 mit dem ersten Companion weiter.

Siehe auch: Teil 2: Companion, Teil 3: Repeater, Teil 4: Antennen und Messen, Teil 5: MeshMapper, Teil 6: Konfiguration.

Links zu Amazon und AliExpress sind Affiliate-Links: Kaufst du darüber, bekomme ich eine kleine Provision, für dich ändert sich am Preis nichts. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. Wenn du also so einen Beitrag hier hilfreich findest, ist das ein Weg um das zu zeigen.

Wenn ihr Fragen habt oder wissen wollt, wie es bei euch in der Gegend mit MeshCore aussieht, dann dürft ihr mich gerne fragen.