Reticulum Config für Berlin - TBD
-
Ich habe mal die Bandbelegung durchgerechnet. Entscheidend ist die Geometrie:
Das Hochleistungs-Subband 869,400–869,650 MHz (500 mW e.r.p., 10 % Duty/Polite Spectrum Access) ist nur 250 kHz breit. Meshtastic liegt mit 250 kHz mittig auf 869,525 MHz und füllt das Band komplett. Bei voller Leistung ist eine Kollision mit Meshtastic also leider nicht vermeidbar. Nehmen wir das mal hin, weil es keine Alternative gibt.
Ausweichen können wir immerhin MeshCore, da ist ja viel los auf der Frequenz. Dessen 62,5-kHz-Block (869,618 MHz) belegt 869,587–869,649 MHz, also den oberen Bandrand. Alles darunter ist MeshCore-frei. Damit passt ein 125-kHz-Kanal mit Mittenfrequenz zwischen 869,4625 (Bodengrenze) und 869,524 MHz (MeshCore-Grenze).
Vorschlag, Mitte 869,475 MHz:
[[RNode Reticulum Berlin]] type = RNodeInterface enabled = yes frequency = 869475000 bandwidth = 125000 spreadingfactor = 7 codingrate = 5 txpower = 22Belegung: 869,4125–869,5375 MHz. Rund 13 kHz über dem Bandboden, rund 49 kHz Abstand zur MeshCore-Unterkante.
-
Ich habe mal die Bandbelegung durchgerechnet. Entscheidend ist die Geometrie:
Das Hochleistungs-Subband 869,400–869,650 MHz (500 mW e.r.p., 10 % Duty/Polite Spectrum Access) ist nur 250 kHz breit. Meshtastic liegt mit 250 kHz mittig auf 869,525 MHz und füllt das Band komplett. Bei voller Leistung ist eine Kollision mit Meshtastic also leider nicht vermeidbar. Nehmen wir das mal hin, weil es keine Alternative gibt.
Ausweichen können wir immerhin MeshCore, da ist ja viel los auf der Frequenz. Dessen 62,5-kHz-Block (869,618 MHz) belegt 869,587–869,649 MHz, also den oberen Bandrand. Alles darunter ist MeshCore-frei. Damit passt ein 125-kHz-Kanal mit Mittenfrequenz zwischen 869,4625 (Bodengrenze) und 869,524 MHz (MeshCore-Grenze).
Vorschlag, Mitte 869,475 MHz:
[[RNode Reticulum Berlin]] type = RNodeInterface enabled = yes frequency = 869475000 bandwidth = 125000 spreadingfactor = 7 codingrate = 5 txpower = 22Belegung: 869,4125–869,5375 MHz. Rund 13 kHz über dem Bandboden, rund 49 kHz Abstand zur MeshCore-Unterkante.
-
Mein TIPP: Bitte die Überschrift zu diesem Beitrag im Forum korrigieren, da viele Leute, diese Angaben als gegeben sehen und denken dass "Reticulum Config für Berlin 869.430MHz/62.5kHz/8/5 Narrow" letztlich vom Berlin Chaos Mesh Forum so festgelegt wurden. In google wird dies leider so angezeigt.
Das hilft dann auch Newcomern bei der Orientierung zu diesem Thema. -
Zum Glück ist das ja alles nur eine Software-Einstellung bei Retriculum
und ändert nix an der Hardware.
869,475 MHz hat operationell einen eingeschränkten Spielraum,
und bietet damit nur einen geringen Koexistenzspielraum,
weil es weniger Spielraum für eine saubere Kanaltrennung lässt.
Es wird potenziell störanfälliger.Der Vorschlag 869525000 aus wiesbaden ist regoros, verdeutlicht jedoch
die Probleme "Krieg der Frequenzen", was praktisch eine
direkte Kollision mit MT bedeutet. War ein bisl provokant von mir. Sorry.Vorzugsweise bspw. 869587500, die jedoch durch die
unterschiedlichen Präambeln zu MT ausgelichen wäre, eine bessere
Koexistenz mit MT ermöglicht, die Störungen reduziert und
gleichzeitig eine bessere Performance für Retriculum bietet.
Um hier dann mögliche Kollisionen zu mindern wären
CSMA/CAD-Mechanismen mit TCXO angebracht.Letztlich wäre ja eine Testbetrieb mit 869587500 möglich,
wobei uns vorher ein grober check mit einem SDR Klarheit
verschaffen würde.BTW: Meine fertige Transport Rnode "lauscht" bereits,
evtl. sogar auf 869587500, wer macht mit ? -
Ich habe heute mittels SDR die wirklich schicke Frequenz 869587500
bei mir mal untersucht. Scheinbar gibt es in meiner Umgebung
Thermometer, Babyphone oder medizinische Geräte welche GENAU
auf dieser Frequenz gemeine Störungen verursachen. Stark.
Eine Verschiebung (des SDR) hier im Süden Berlins auf 86960000
sogar besser 869700000 mit BW 125000 würde mich persönlich aus diesem
blöden Störbereich bringen.
Habe hier praktisch kein MT Signal lokalisiert. GUT!
Das kann örtlich (bspw. Norden) natürlich total anders sein und eine
Abstimmung notwendig machen. Evtl. sogar durch Tests.SDR: Also Abschied von allen möglichen tollen Berechnungen,
sondern hin zur Praxis und das mögliche Frequenzband untersuchen.
Es müßte doch mit dem Teufel zugehen, wenn es dazu nicht eine
Lösung geben könnte. Ich denke wir tauschen uns als Pioniere
hierzu aus. Das alles ist Neuland und keine KI würde das verstehen.FAZIT: Grau ist alle Theorie, ob nun MT oder MC beeinflußt
werden könnten ergibt sich aus der Präamble (Layer3) von Reticulum
die sich beide nicht beeinflüssen würden.(durch CSMA/CA etc.)
Aber diese anderen Geräte (s.o.) würden nachweislich unser
Projekt Stadtnetz Reticulum zu Fall bringen.Nachtrag: bei 869450000 ebenfalls kaum Störungen im "Wasserfall".
Untere Signalkante: 869,450 MHz − 0,0625 MHz = 869,3875 MHz
Obere Signalkante: 869,450 MHz + 0,0625 MHz = 869,5125 MHz
Die untere Kante (869,3875 MHz) rutscht zwar um winzige 12,5 kHz unter die 869,400-MHz-Grenze. Das ist aber völlig legal, da das direkt
angrenzende Band (863 bis 870 MHz) ebenfalls für diese Funkgeräte
freigegeben ist.
Die obere Signalkante endet exakt 12,5 kHz vor dem Beginn des
Meshtastic-Kanals, also keine Störungen.Nun ist I5y mit Ihrem "Wasserfall" dran und wird uns berichten.
-
Ich persönlich unterstütze keine Option, die außerhalb des 500-mW-Bands liegt oder auf MeshCore sitzt. Beides ist nicht zukunftssicher.
869,700 liegt komplett außerhalb von 869,400–869,650. Dort sind nur <5 mW erlaubt. Das heißt: volle Leistung aufgeben, genau die Prämisse, mit der wir angefangen haben. Fällt raus.
869,5875 und 869,525 sitzen beide auf dem Meshcore Block (869,587-869,649). Unterschiedliche Präambeln machen daraus keine Orthogonalität; das ist PHY, nicht Layer 3, und verhindert nur Fehl-Sync. Co-Kanal-Energie hebt trotzdem den Noise Floor und frisst Pakete, bei gleichem Spread Factor direkt. Und Meshcore wächst, wer sich heute auf deren Frequenz legt, muss in einem Jahr umziehen, wenn der Verkehr dort zunimmt.
Was übrig bleibt; volle Leistung, 125 kHz, MeshCore frei: ist weiterhin nur das Fenster 869,4625 bis 869,524. Darin liegt 869,475. Das bleibt mein Vorschlag.
Wenn das SDR dieses Fenster wirklich verrauscht zeigt, dann stehen die Anforderungen im Konflikt, und wir entscheiden offen: Leistung runter oder MeshCore-Überlapp in Kauf nehmen.
-
Ich werde auch nur legal im 500-mW-Band funken. Der 869,475-MHz-Vorschlag von @l5y ist wohl der beste Kompromiss. Bei mir sieht der SDR-Wasserfall so aus (allerdings hier in einem Bereich weit über dem Rauschen, zeigt also keine schwachen Störsignale):

-

Das europäische SRD-Band (Short Range Devices) ist im Bereich 869,40 bis
869,65 MHz standardmäßig in ein 25-kHz-Raster unterteilt (z. B. 869,400
MHz, 869,425 MHz, 869,450 MHz, 869,475 MHz, 869,500 MHz usw.)869,475 MHz ist somit der De-facto-Standard für "Kanal g3". OK!
Mir persönlich wäre Aufgrund von periodischen Störungen etwas
"weniger" lieber, aber das ist eben nicht zu ändern.
Hoffentlich habt ihr vorort keine Funk-Heizungssteuerungen & Smart Home
oder ähnliche Geräte und habt dies mit einem SDR im Blick.Dann lausche ich ebenfalls auf 869475000hz sf8 cr5 tx20. No Problem.
Es bleibt also dabei: JA? Beschluss ? -

Kleine Pakete (60 Bytes): SF7 benötigt 113 ms Airtime | SF8 benötigt 205 ms Airtime
Große Pakete (120 Bytes): SF7 benötigt 200 ms Airtime | SF8 benötigt 359 ms Airtime
Mein Vorschlag: Wir sollten standardmäßig auf 869,475 MHz mit SF7 setzen.
Wer Empfangsprobleme hat, sollte zuerst die Hardware optimieren (gute Antenne
nach draußen/ans Fenster, bessere Module (!)), anstatt das gesamte Netz durch
SF8 träge (sorry) zu machen.
Und letztlich auch MTU250 einstellen, ebenfalls LBT (ein RAK4631 mit SX1262 kann das)
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden