FAQ zu MeschCore

Das lässt sich nur Näherungsweise angeben. Hier einige Zeitangaben für Typische Pakete:

Man erkennt daran recht gut, dass normale MeshCore-Nachrichten den Kanal nur für wenige Hundert Millisekunden belegen. Selbst eine lange Nachricht blockiert den Sender typischerweise weniger als 1 Sekunde. Das eigentliche Problem für das Netz sind daher meist nicht einzelne Nachrichten, sondern große Flood-Bereiche (z.B. DE), zu hohe Hop-Zahlen und viele Repeater, die dieselben Pakete weiterleiten. Diese Faktoren erzeugen deutlich mehr Airtime als eine normale Chat-Nachricht.

Die Airtime (genauer: Airtime Factor, AF) bestimmt, wie viele Sende-Pausen ein MeshCore-Knoten nach jeder Übertragung einlegt. Dadurch wird begrenzt, wie viel Sendezeit ein Gerät belegen kann und das Funknetz wird entlastet. Die Umrechnung erfolgt nach folgender Formel:

Duty Cycle [%] = 100 / (Airtime Factor + 1)

Beispiele:
AF 1 = 50 % Duty Cycle
AF 9 = 10 % Duty Cycle
AF 99 = 1 % Duty Cycle

Für die in Deutschland häufig verwendete MeshCore-Frequenz 869,618 MHz wird ein Airtime Factor von 9 empfohlen. Dies entspricht einem Duty Cycle von 10 %. der von der Bundesnetzagentur für diesen Freqeunzbereich auch als Maximum vorgegeben ist. Der entsprechende Konsolenbefehl lautet:

set af 9

Was passiert, wenn die Airtime überschritten wird?

Während dieser Pausen kann der Knoten keine weiteren Pakete senden und muss warten, bis die vorgeschriebene Pause abgelaufen ist. Erst danach dürfen wieder Nachrichten oder Weiterleitungen übertragen werden. Das schützt das Funknetz vor Überlastung und sorgt dafür, dass einzelne Geräte den Kanal nicht dauerhaft belegen. Die aktuelle Implementierung erzwingt diese Pausen also direkt nach jeder Übertragung und nicht erst nach Erreichen eines Stundenlimits.

Für Repeater-Betreiber hat das einen positiven Nebeneffekt: Die Last wird sehr gleichmäßig verteilt. Ein Repeater kann nicht plötzlich viele Pakete hintereinander aussenden, sondern wird nach jedem Sendevorgang eingebremst. Dadurch entstehen weniger Kanalbelegungen und Kollisionen. Allerdings ist das Verfahren konservativer als ein echter gleitender 10-%-Duty-Cycle.

Empfehlung

Für die meisten MeshCore-Nutzer und Repeater in Deutschland ist derzeit:

set af 9

eine sinnvolle und netzfreundliche Einstellung. Sie begrenzt die Senderaktivität auf 10 % Airtime, ohne die Erreichbarkeit unnötig einzuschränken.

Wichtig: Neben einer vernünftigen Airtime-Einstellung tragen vor allem korrekt konfigurierte Regionen (Scopes) und begrenzte Flood-Hops zur Entlastung des MeshCore-Netzes bei. Diese Maßnahmen haben aktuell einen deutlich größeren Einfluss auf die Netzstabilität als der Airtime Factor allein.

Öffentliche Nachrichten in MeshCore sollten immer einer lokalen Region zugeordnet werden. Diese Region wird auch als Scope bezeichnet. Durch die Zuordnung zu einer Region wird sichergestellt, dass Nachrichten nur innerhalb des gewünschten Gebiets verteilt werden und nicht unnötig durch das gesamte Netzwerk in Deutschland wandern.

Welche Regionen unterstützt werden und wie weit Nachrichten innerhalb dieser Regionen weitergeleitet werden dürfen, legen die Administratoren der Repeater fest. Die erlaubten Regionen werden direkt im Repeater konfiguriert. Die maximale Weiterleitungsdistanz wird über den Parameter flood.max bestimmt. Standardmäßig liegt dieser Wert bei 64 Hops, was für die meisten Netze deutlich zu hoch ist. In der Praxis werden meist Werte zwischen 10 und 15 Hops verwendet. Dadurch werden auch große Regionen, beispielsweise „DE“, sinnvoll begrenzt.

Wird bei einer öffentlichen Nachricht keine Region angegeben, spricht man von einer unscoped Nachricht. Da die Repeater in diesem Fall nicht erkennen können, für welche Region die Nachricht bestimmt ist, wird sie potenziell quer durch das gesamte deutsche Netzwerk weitergeleitet. Um eine Überlastung des Netzes zu verhindern, begrenzen viele Betreiber solche Nachrichten mit dem Parameter flood.max.unscoped auf wenige Hops, meistens zwischen 4 und 6. Theoretisch wäre es sinnvoll, unscoped Nachrichten komplett zu sperren, jedoch möchte man damit unerfahrenen Nutzern im Krisen- oder Notfall weiterhin die Möglichkeit geben, Hilfe anzufordern.

Die Einstellung flood.max.unscoped steht erst seit Firmware-Version 1.16 zur Verfügung. In älteren Versionen konnten Administratoren lediglich komplette Regionen, beispielsweise „DE“, mit deny flood DE sperren. Aus diesem Grund sollten Companions ihren Benutzern grundsätzlich immer eine passende lokale Region zuweisen.

Da das MeshCore-Netzwerk kontinuierlich wächst und die Belastung des Netzes zunimmt, müssen viele Repeater-Betreiber inzwischen Maßnahmen zur Entlastung treffen. Um eine Überlastung oder sogar einen Kollaps des Netzes zu verhindern, wird die Region „DE“ zunehmend komplett gesperrt. Gleichzeitig werden unscoped Nachrichten entweder stark eingeschränkt oder teilweise vollständig deaktiviert.

Für neue oder unerfahrene Nutzer bedeutet dies, dass eine korrekte Konfiguration immer wichtiger wird. Wer keine passende Region eingestellt hat, kann unter Umständen große Teile des Netzes nicht mehr erreichen. Daher gehört die Auswahl einer lokalen Region heute zu den wichtigsten Grundeinstellungen eines MeshCore-Clients.

Ein Companion „gehört“ nicht automatisch einer Region an.
Regionen dienen ausschließlich dazu, den Nachrichtenfluss räumlich einzugrenzen, damit Pakete nur dort weitergeleitet werden, wo sie wirklich relevant sind.

Für jeden Channel kann ein Companion eine eigene Channel‑Region definieren.
Diese Region sollte so klein wie möglich gewählt werden, um unnötige Weiterleitungen zu vermeiden. Beispiel: Nachrichten aus Meschede gehören in die Region sauerland, nicht in de.

Zusätzlich kann (und sollte) ein Companion eine Default‑Region setzen. Sie wird verwendet, wenn ein Channel keine eigene Region definiert hat.
Die Default‑Region ist außerdem wichtig für:

• Adverts (damit Repeater wissen, wohin sie dich einordnen sollen)
• Pakete ohne expliziten Scope

Nein. Ein MeshCore‑Companion leitet grundsätzlich keine Nachrichten weiter.
Das ist ein zentraler Bestandteil des MeshCore‑Designs:
Nur so wird verhindert, dass Geräte das Netz überlasten, unnötige Weiterleitungen erzeugen oder Kollisionen verursachen, die dazu führen könnten, dass Nachrichten ihre Empfänger nicht erreichen.

Nur zwei Gerätetypen können Nachrichten weiterleiten:

• Repeater
• Roomserver
  Der Roomserver tut dies auch nur, wenn die Einstellung „Repeat on“ aktiv ist.

Seit MeshCore Version 1.15 kann auch ein Companion die Repeat‑Funktion aktivieren.
Diese Funktion ist jedoch ausschließlich für Notfälle gedacht.

Wird Repeat am Companion eingeschaltet, obwohl ein Repeater in der Nähe ist, kann das Netz massiv überlastet werden. Dadurch steigt das Risiko, dass gesendete Nachrichten nicht mehr beim Empfänger ankommen.

Ein Zero‑Hop‑Ping ist ein direkter Test zu einem einzelnen Repeater, ohne Weiterleitung über andere Knoten.
Der Companion sendet das Ping‑Paket nur an den ausgewählten Repeater, und nur dieser antwortet. Du wählst im Companion einen Repeater aus, und der Companion sendet ein Ping‑Paket Zero‑Hop direkt an diesen Repeater. Damit prüfst du ausschließlich, ob dieser eine Repeater erreichbar ist und wie gut die direkte Funkverbindung zwischen deinem Companion und diesem Repeater ist. Multi‑Hop‑Pings sind in MeshCore nicht möglich. Die nachfolgende Grafik zeigt Details zum Ping.

Ja, du musst im Companion selbst eine Region setzen.
Der Repeater entscheidet nur, welche Regionen er weiterleitet – aber er trägt keine Region für dich ein. Ohne gesetzte Region wird deine Nachricht von vielen Repeatern inzwischen ignoriert.

Eine Region muss für jeden Channel separat im Companion festgelegt werden – sie bestimmt, mit welcher Region deine Pakete gesendet werden.
Die Default‑Region ist ein Fallback, falls ein Paket keinen Scope hat, man also z.B. eine Region vergessen hat. Aher auch für Adverts.
Beides musst du selbst im Companion setzen, der Repeater übernimmt das nicht.

Die Coding‑Rate bestimmt, wie stark eine LoRa‑Nachricht gegen Fehler geschützt ist.
Bei CR = 5 wird weniger Redundanz gesendet – die Übertragung ist schneller, aber anfälliger für Störungen. Bei CR = 5 werden 4 Nutzbits und 1 Redundanzbit übertragen.
Bei CR = 8 wird mehr Redundanz hinzugefügt – die Übertragung dauert länger, ist dafür deutlich robuster und zuverlässiger.Bei CR = 8 werden 4 Nutzbits und 4 Redundanzbit übertragen.
Die Redundanzbits ermöglichen eine Fehlererkennung bzw, Fehlerkorrektur. Je höher die Coding-Rate ist um so mehr Redundanzbits werden übertragen.

Eine kleine 868-MHz-Antenne (λ ≈ 34 cm, Viertelwelle ≈ 8,6 cm) ist ein empfindliches Resonanzsystem. Sie arbeitet nicht isoliert – ihre unmittelbare Umgebung ist elektrisch betrachtet ein Teil der Antenne.

Was passiert, wenn die Antenne direkt am Kunststoffgehäuse anliegt?

Kunststoff besitzt eine Dielektrizitätszahl (εr > 1). Diese beschreibt, wie sich das Material gegenüber hochfrequenten elektromagnetischen Feldern im Vergleich zum Vakuum verhält. Liegt die Antenne am Gehäuse an, wird sie dadurch elektrisch „verlängert“. Die Resonanzfrequenz verschiebt sich nach unten und die Anpassung (SWR) verschlechtert sich.

Zusätzlich verändert sich die Feldverteilung der elektromagnetischen Wellen im Nahbereich der Antenne. Dadurch sinkt der Wirkungsgrad – es wird weniger Leistung abgestrahlt beziehungsweise empfangen.

Gerade bei kurzen 868-MHz-Antennen reichen bereits wenige Millimeter Abstand, um die Resonanz wieder näher an den vorgesehenen Wert zu bringen, Verluste zu reduzieren und damit die Reichweite zu verbessern. Unterschiede von mehreren dB sind dabei durchaus typisch – und können darüber entscheiden, ob eine Verbindung „gerade noch nicht funktioniert“ oder schon stabil läuft.

Wenn von vornherein bekannt ist, dass die Antenne im Gehäuse integriert werden soll, kann dies bei der Konstruktion berücksichtigt werden. In diesem Fall wird die Antenne entsprechend anders dimensioniert und auf die reale Einbausituation abgestimmt.

Das ist nichts Ungewöhnliches und heißt nicht automatisch, dass die teureren Antennen schlecht sind. Entscheidend sind vor allem Antennendiagramm und SWR, und nicht allein der angegebene dBi-Wert.

Eine Antenne mit höherem Gewinn (z. B. 5 dBi) bündelt die Energie stärker in der Horizontalen und hat dafür weniger Abstrahlung nach oben und unten. Wenn der Repeater relativ hoch oder ungünstig zur Hauptkeule liegt, kann eine Antenne mit weniger Gewinn oder anderem Diagramm dort sogar besseren Empfang liefern.

Zusätzlich spielt das SWR bei genau deiner Frequenz eine große Rolle. Wenn die billige Antenne zufällig besser auf z. B. 868 MHz abgestimmt ist (niedrigeres SWR), wird weniger Signal reflektiert und mehr effektiv empfangen. Teurere Antennen sind oft breitbandiger ausgelegt und nicht unbedingt genau bei deiner Frequenz optimal.

Wenn Kabel und Standort identisch sind, bleibt im Wesentlichen nur:
– unterschiedliches Strahlungsdiagramm
– unterschiedliches SWR bei der Nutzfrequenz
– minimaler Einfluss durch einen evtl. Adapter

Eine pauschale Antwort darauf, ob eine 70‑cm‑Antenne (430–440 MHz) auch im LoRa‑Band bei 868 MHz funktioniert, gibt es nicht. Das müsste man im Einzelfall messen.

Zwar liegt 868 MHz ziemlich genau beim Doppelten der 70‑cm‑Frequenz, sodass theoretisch ein Oberwellen‑ oder Mehrband‑Effekt auftreten könnte, aber darauf kann man sich nicht verlassen.

Diese Nebenresonanzen waren beim Design der Antenne nicht geplant und entstehen durch die Geometrie und die Abmessungen der Antenne. Dass die Antennen bei 868MHz funktioniert, kann durchaus sein, aber da das kein geplantes Feature war, ist dass dann eher Zufall. Vielleicht stimmt auch das SWR, aber dass sagt dann noch nichts über den Wirkungsgrad aus, der durchaus 10-20dB schlechter sein kann als auf der „Originalfrequenz“

Bei Deiner 2m/70cm Antenne hat man auch nicht darauf vertraut. 432MHz (70cm) ist das Dreifache von 144MHz (2m), also eine Nebenresonanz. Man hat es aber vorgezogen, für beide Bänder separate Elemente vorzusehen, wie man an den Elementlängen unschwer erkennen kann.

Ob die Antenne bei 868 MHz noch einen brauchbaren Wirkungsgrad oder ein akzeptables SWR hat, hängt also stark vom konkreten Antennendesign ab.

Am Ende hilft nur ausprobieren und messen.

Das passiert, wenn der Roomserver keine Default-Region gesetzt hat. Repeater mit gesetzter Region (z. B. de-nw) blockieren Pakete ohne Region. Direktverbindungen funktionieren, Verbindungen über Repeater nicht.
So kann die Default Region im Roomserver gesetzt werden

Repeater leiten nur Pakete weiter, die eine gültige Region haben. Ohne Default-Region im Roomserver verwirft der Repeater die Adverts und Login-Anfragen des Roomservers.

In MeshCore 1.15 gibt es keine Regionseinstellung in der Weboberfläche. Die Region muss per CLI gesetzt werden. Ohne gesetzte Region ist der Roomserver „regionlos“ und Repeater blockieren seine Pakete.

Das Logging-System in MeshCore 1.15 ist unvollständig implementiert. log start und log stop steuern nur den internen RAM-Logbuffer. Der Befehl log zum Auslesen ist nicht implementiert. Logs sind nur über die USB-Konsole sichtbar.

Beim Repeater und beim Companion kann die Default-Region über die Weboberfläche gesetzt werden. Bei Roomserver geht das nicht. Die Default-Region wird hier per CLI gesetzt:

Danach funktionieren Adverts und Login über Repeater.