Reticulum Config für Berlin - Diskussion

[l5y]

Ah, ich sehe gerade rmap.world sagt man muss "discoverable = yes" setzen...

[unosonic]

und mode = ap, sonst kanns u.U. passieren, dass dein rnode announct wie blöde
kommende Woche habe ich wieder mehr Zeit zum spielen, bin gespannt.
Eine Sache ist interessant: ich habe eine transport rnode auf dem Dach und eine "normale" im EG am latop. Die Verbindung ist bestens:

Summary: Delivered
Hops: 1
RTT: 1.33 seconds
RSSI: -89 dBmSNR: 11.75 dB

bzw. 2 hops vom backbone node entfernt.

aber natürlich nur, wenns laptop eingeschaltet ist. Wenn das laptop aus ist über Nacht würde ich erwarten, dass die Dach-Rnode einen stale oder keinen path hat, aber es gibt einen:

Path found, destination <76cad2963a5fb051a12a486f98912846> is 16 hops away via <487add22d6900eef99657ac2bcd119e6> on BackboneInterface[Client on radio.earth/81.17.24.163:29197]
(81.17.24.163 ist irgendwer aus Panama City, der (ggf. temporär) als client zu meinem Backbone Interface connected hat. Wie auch immer, den gesamten Pfad würde ich gerne mal sehen. Vom EG durch die Welt aufs Dach

[unosonic]

hat eigentlich noch jemand eine funktionierende rnode dauerhaft und erreichbar am laufen? Ich sehe hier wiederholt microReticulum Announces. Suche Anschluss
Die ausgiebigen Tests mit @tobeku waren bisher noch nicht wirklich erfolgreich, ggf. haben wir ein Reichweitenproblem. Bei meinen Tests erreichte eine RNode max. 1/4 der Distanz eines Meshcore-Repeaters, bei gleicher Topographie. Woran das nun liegt, Protokolloverhead etc., weiss ich noch nicht.

[qozi]

Hallo zusammen! Ich war bis jetzt zum testen noch auf einer anderen Frequenz unterwegs, habe aber heute diesen Thread gefunden und umgestellt.

Mit meinem T-Beam finde ich aktuell niemanden. Morgen hänge ich noch eine Transport Node nach draußen, leider nicht so hoch aber mal gucken ob wir uns finden.

LXMF 9a4e585d17082ecce062bb62670a6a2b

[scotty]

@unosonic sagte:

Ich sehe hier wiederholt microReticulum Announces.

Welcher Name und Node-Typ wird denn da announced?

[BrutalBirdie]

Hallo @qozi und willkommen im Chaosmesh!

[unosonic]

@scotty

microReticulum Node [E072A1D76769]
nomadnet: 9a8ee2ecb0adc7998e6376e3cc1064d9

Kann die Seite auch über rnode laden, ist die typische Statusseite eines microReticulum.

[unosonic]

Critical Security Update: RNS 1.3.9 fixes severe rnsh (Reticulum shell utility) security flaw https://pypi.org/project/rns/

[tobeku]

Ich möchte einen kontrollierten Reticulum-Frequenztest für Berlin vorschlagen.

Unsere bisherige Reticulum-Einstellung 869,475 MHz / BW 125 kHz liegt vollständig innerhalb des Berliner Meshtastic-MediumFast-Kanals mit 250 kHz Bandbreite. Deshalb könnten zeitgleiche Meshtastic-Sendungen unsere Pakete beeinträchtigen.

Mein Testvorschlag:

• 869,850 MHz
• Bandbreite 62,5 kHz
• SF7
• CR 4/5
• maximal 25 mW ERP einschließlich Antennengewinn
• Einhaltung von höchstens 1 % Arbeitszyklus
• zunächst nur kurze LXMF-Texte und seltene Announces

Der Gedanke dahinter: Gegenüber unseren bisherigen 20 dBm verlieren wir durch die geringere Leistung 6 dB. Die Halbierung der Bandbreite bringt ungefähr 3 dB bessere Empfangsempfindlichkeit zurück. Wenn der neue Frequenzbereich wesentlich ruhiger ist, könnte der vermiedene Störpegel den verbleibenden Leistungsverlust deutlich überwiegen.

Es geht ausdrücklich noch nicht um eine allgemeine Umstellung, sondern um einen A/B-Test mit zwei Stationen:

1. Frequenz vorher an beiden Standorten mit SDR beobachten.
2. Eine Serie nummerierter Textnachrichten auf der bisherigen Einstellung senden.
3. Dieselbe Serie zu vergleichbaren Zeiten auf 869,850 MHz / BW 62,5 kHz wiederholen.
4. Zustellquote, RSSI, SNR und notwendige Wiederholungen vergleichen.

Für eine ungefähr 8 km lange Dach-zu-Dach-Strecke sollte der Versuch auch mit guten Außen-Verticals grundsätzlich möglich sein. Reticulum kann einzelne Verluste durch Zustellbestätigungen, Wiederholungen und Routing ausgleichen; ein ruhigerer Funkkanal wäre aber die entscheidende Voraussetzung.

Wer hätte Interesse, sich an einem solchen Test zu beteiligen?

[unosonic]

wir können gerne mal Deinen Vorschlag testen, aber ich komme nicht vor Anfang nächster Woche dazu. Wir haben nicht gerade Sichtverbindung auf den 8km.. noch jemand an Tests interessiert?

[l5y]

@tobeku said:

Mein Testvorschlag:

• 869,850 MHz
• Bandbreite 62,5 kHz
• SF7
• CR 4/5
• maximal 25 mW ERP einschließlich Antennengewinn
• Einhaltung von höchstens 1 % Arbeitszyklus
• zunächst nur kurze LXMF-Texte und seltene Announces

Sehe ich keinen Sinn.

1. 25mW ERP sind 20x weniger Sendeleistung (-13 dB).
2. Duty Cycle von 1% heißt nur 36 Sekunden Sendezeit pro Stunde.
3. die vorgeschlagene Frequenz ist auch nicht unbenutzt. Nur weil unser Fokus gerade auf Meshtastic liegt, heißt es nicht, dass rechts und links im Spektrum nicht auch ordentlich was los ist.

Die eingebüßte Sendeleistung ist aber immernoch das drastischste, da wir schon so jetzt ein sehr dünnes Netz haben. Mit den 25mW ERP kommst du auch vom Dach nirgendwo mehr an.

[tobeku]

I5Y: Sehe ich keinen Sinn.
Ich verstehe deine Einwände gegen eine dauerhafte Umstellung. Mein Vorschlag war aber ausdrücklich als Test gedacht.

Bereits vor der Festlegung auf 869.475 MHz hatte ich angeregt, das Band mit SDR-Empfängern an mehreren Standorten zu untersuchen, um die tatsächliche Belegung zu erfassen. Soweit ich weiß, ist das nicht erfolgt.

Neben den SDR-Beobachtungen haben mich auch die Auffälligkeiten in den Sideband-Logs zu dieser Hypothese gebracht. Beides zusammen ist für mich zumindest ein Anlass, einen Vergleichstest durchzuführen. Ob die Frequenz tatsächlich die Ursache ist, kann letztlich nur ein praktischer Test zeigen.

Inzwischen habe ich auf 869.475 MHz wiederholt LoRa-Aktivität beobachtet. Daraus leite ich nicht ab, dass diese Frequenz ungeeignet ist, sondern lediglich die Hypothese, dass die Kanalbelegung unsere Verbindungen beeinflussen könnte.

Diese Hypothese lässt sich weder durch Vermutungen bestätigen noch widerlegen – sondern nur durch einen Vergleichstest unter möglichst gleichen Bedingungen.

Wenn der Test keinen Unterschied zeigt, ist die Frequenz vermutlich nicht das Problem. Zeigt er eine Verbesserung, haben wir einen objektiven Hinweis, dass die Kanalbelegung eine Rolle spielt.

Genau deshalb halte ich einen Test für sinnvoll.
-> Selbst wenn sich herausstellt, dass 869.850 MHz ungeeignet ist, hätte man trotzdem etwas gelernt:
Waren die Paketverluste wirklich frequenzbedingt?
Oder liegt das Problem an Antennen, Standorten, SF, Bandbreite oder der Netzdichte?