Reticulum Config für Berlin - Diskussion

[tobeku]

@l5y Prima, Du bist auf dem richtigen Weg, dann können wir ja bald mal "testen", das wird sicherlich spannend.

[tobeku]

@scotty Das siehst Du absolut richtig, deshalb haben "Wir" ja eine Korrektur vorgenommen.

[scotty]

@tobeku Keine Kollisionen mit MT und höhere Datenrate - mega! Ich wäre dabei.

Du hast als Funkamateur wahrscheinlich mehr Ahnung von der Materie als ich (Funk-Noob). Könntest du mir erklären, was ich beim Regulatorien-Foo falsch verstehe?
In der von dir angegebenen Allgemeinzuteilung 91/2025 (Tabelle 2) fallen 869,3MHz mit 125kHz BW in die Bänder 52 und 53 für "Zuverlässige Alarmanlagen" mit 10mW (ERP) und duty 0,1% (52) bzw. 1% (53). Außerdem ist die Kanalbandbreite in beiden auf 25kHz beschränkt.
Ich konnte nirgends eine andere (allgemeine) Freigabe für 869,3MHz finden. Kannst du mir da auf die Sprünge helfen?

[tobeku]

Dieser Beitrag wurde gelöscht!

[tobeku]

Dieser Beitrag wurde gelöscht!

[tobeku]

Dieser Beitrag wurde gelöscht!

[l5y]

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 = 22

Belegung: 869,4125–869,5375 MHz. Rund 13 kHz über dem Bandboden, rund 49 kHz Abstand zur MeshCore-Unterkante.

[scotty]

@l5y Ja, das sieht meiner unbedeutenden Meinung nach brauchbar aus. Habs spaßhalber mal visualisiert.

[tobeku]

Dieser Beitrag wurde gelöscht!

[tobeku]

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.

[l5y]

Überscheidet das dann nicht? Wie würde das ausehen?

Ich ändere die Überschrift sobald wir was haben ...

[tobeku]

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 ?

[l5y]

Ich habe es erstmal aus dem Titel genommen.

Ich setze mich gerne nochmal mit dem SDR hin, aber das schaffe ich nicht vor dem Wandertag...

[tobeku]

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.

[l5y]

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.

[scotty]

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):

[tobeku]

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 ?

[l5y]

SF7 oder SF8?

[tobeku]

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)

[l5y]

Na dann haben wir es doch.

[[RNode Reticulum Berlin]]
  type = RNodeInterface
  enabled = yes
  frequency = 869475000
  bandwidth = 125000
  spreadingfactor = 7
  codingrate = 5
  txpower = 22