Reticulum Config für Berlin - Diskussion

[tobeku]

@unosonic sagte:

ja, mein home network über rnodes und wifi funktioniert soweit. eine der rnodes habe ich jetzt als transport node konfiguriert, nur hier im EG macht das nicht viel sinn. für den test auf dem dach brauche ich noch teile.. sind bestellt. hoffe das dauerhaft neben den MC repeater (BKreuzkoellnB910) installieren zu können, mal sehen.

Das wird technische Frequenz Probleme für MC und/oder Rnode bringen, denn beide "Repeater" senden ja immer.
Mögliche Interferenzen können Störungen verursachen und sich gegenseitig beeinflussen. Sorry für diesen "bösen" Tipp .

[tobeku]

tobeku sagte:

Da Reticulum nur P2P funktioniert, wird es zum Testen
oft etwas frustig. Ich habe eine BERLIN-BOX Rnode zum Testen
auf unserem Kanal programmiert, die zeitmäßig ANNOUNCES für ein
Automatisches Routing sendet, und nur eine simple
Echo-Kommunikation ermöglicht. Unterstützt wird
diese BERLIN-BOX Rnode mit einem Hop, durch eine Transport-Rnode
auf dem Dach. Noch liegt die Hardware auf dem Schreibtisch
zum gelegentlichen Testen und muss noch in ein Gehäuse.
Sie soll später dann 24/7 autark laufen.
Ich hoffe, dass durch dieses Projekt unser Reticulum
Berlin Stadtnetz weiter wachsen wird.
Mit meinen 3 Geräten funzt es zuverlässig über Sideband/Meshchat.

Keine Bilder testen, bitte nur TEXT
Das von mir selbst entwickelte Script wird evtl. weiter entwickelt, aber sehr viel später.

[unosonic]

kann sein, aber vielleicht auch nicht. wenn du zeit hast, probier mal folgende:

rnode auf dem dach, antwortet auf probes:

rnprobe rnstransport.probe 76cad2963a5fb051a12a486f98912846

oder schick mir eine nachricht an:

lxmf://a3482f1669f9c82e5fbc280544321208

ich lass mal den MCX offen.

@tobeku sagte:
Das wird technische Frequenz Probleme für MC und/oder Rnode bringen, denn beide "Repeater" senden ja immer.
Mögliche Interferenzen können Störungen verursachen und sich gegenseitig beeinflussen. Sorry für diesen "bösen" Tipp .

[unosonic]

[tobeku]

@unosonic sagte:

Habe an alle Deine LXMF Schlüssel versucht Nachrichten
zu senden:
e99d5c135cbd1c656d7cb5c6efac5505
2x backbone rmap
1204a52c64cb4dc3882cf86133d38ee6
rnode lora rmap
rnprobe rnstransport.probe 76cad2963a5fb051a12a486f98912846
Nachricht an
lxmf://a3482f1669f9c82e5fbc280544321208

Leider ohne Erfolg, egal woran es lag.... das wird schon

Vielleicht könnten wir einen Funkstrecken-Test mit simplen Announces machen, das währe doch ein Vorschlag, der vielleicht eher klappt.
Ich arbeite hier mit SIDEBAND an meiner RNODE.
Ich (MC USER) habe bei MESHCORE einen #reticulum Kanal eingerichtet, wir könnten uns hier genauer für Tests verabpreden.
z.B. Abends 19 - 19:30 oder so, oder Vorschlag
Vor Lankwitz nach Neukölln ist doch ein "Katzensprung"
Was hällst Du davon ?

[unosonic]

ich habe meinen "backbone" auf dem raspi gestern abend versehentlich abgeschaltet und erst heute morgen bemerkt.. hab den jetzt auf eine vm umgehoben (rns.radio.earth:4242), sollte jetzt stabil und hoffentlich dauerhaft laufen.
eben kam ein announce via lora rein:
4345141aa283fcc2af9f53ca71f3a510 / 2 hops / via 0b58396f989f82a9c85bffbb420e16d2 on RNodeInterface[rnode.7390]
mc://#reticulum habe ich subscribed, aber ich werde leider die kommenden Tage wenig Zeit haben, könnens probieren.

[unosonic]

nice flasher btw @ https://rmap.world/flasher/ !

[l5y]

Meine RNode läuft auf LoRa seit einigen Tagen am Ostkreuz, LXMF 4cf985bf933c21b1aa8dabd407d4ef69 - allerdings habe ich niemanden empfangen bisher.

Ich bin jetzt erstmal in Brandenburg für das Camp, da werde ich einiges mit Reticulum machen, aber hier in Berlin erstmal niemanden erreichen. Ich melde mich danach.

[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?