@Paul_Simmen@chrigu@chix@stef Euch allen einen ganz herzlichen Dank für eure Versuche und vorallem für eure wertvollen Beschreibungen!
Ich konnte mir zum Thema Regionen bisher noch keine belastbare Meinung bilden und werde mich dann bei den betreuten Repeatern zu gegebener Zeit an eure Empfehlungen halten.
Die meisten HB9BG Repeater werde ich in den nächsten Tagen wohl updaten können, bei Transalp wird dies erst bei meinem nächsten Besuch in wohl drei bis vier Wochen möglich sein.
Danke für die Rückmeldung, Urs! Ich bin grad am Vorbereiten des Back-Up Repeaters Grenchenberg. Vielleicht klapt’s bis Sonntag, dann hat’s ein Poschi ab Bahnhof Grenchen (immer nur am Woe!) Mag nicht per Pedes hochsteigen.
Vielen Dank für die Blumen, Christoph! Liam Cottle und Scott Powell sorgen mit ihren Entwicklungen nicht zuletzt dafür, dass sich auch in späten Tagen nur wenig Kalk in meinem Oberstübchen ablagert…
Gut Ding will Weile haben… es wird also wohl noch viel Wasser die Emme (bei dir die Giesse..?) hinab fliessen, bis alle RPT-Admin’s das aktuelle Betriebssystem geflasht haben.
Vielleicht können wir, wenn alles rund läuft, gegen Ende März den Schalter umlegen. Das wäre etwas…!
Hallo Bullit, mein Name ist Toediost, ich bin in Brigerbad stationiert. Habe gesehen dass Du das Oberwallis erwähnt hast. Sind wir in derselben geogr. Region? Freundliche Grüsse
Either you would have to configure a scope to a contact (or received a scoped advancement) or he has to limit this scope handling only to channel messages.
Lets see how he handles this.
Was für ein Versehen.
Entweder man müsste einen Scope für einen Kontakt konfigurieren (oder eine scoped Ankündigung empfangen) oder er muss diese Filterung nur auf Channel-Nachrichten beschränken.
wie erwähnt muss “ * Flood Allowed” unbedingt bleiben, da ansonsten momentan Usecases ohne Möglichkeit den Scope zu definieren ( DM, Repeater-Admin,…) nicht mehr funktionieren.
Ich gehe davon aus dass irgendwann im Companion ein “default scope” definiert werden kann um dies auch ohne “* Flood allowed” wieder zu ermöglichen, dies müsste dann jedoch vermutlich nicht nur im Companion sondern auch in den Repeatern definiert werden können. Ich glaube dass für Repeater Admin zuerst beidseitig geflooded wird bevor beide Seiten den Pfad gelernt haben und nicht mehr flooden.
meine Repeater in AG/ZH forwarden:
unscoped (*)
ch
ch-de
europe
Westschweiz (ch-fr) und Tessin (ch-it) habe ich nicht konfiguriert. Kommunikation zwischen den Sprachregionen sollte mit Scope “ch” erfolgen.
Repeater unmittelbar an der Sprachgrenze welche für beide Regionen wichtig sind, sollten sicher beide Regionen erlauben.
Für den Austausch mit den benachbarten Ländern, habe ich mal zusätzlich “europe” erlaubt, dies scheint in Deutschland auch bereits diskutiert zu werden. Repeater welche an Nachbarländer angrenzen, sollten sicher auch noch die direkt angrenzenden Regionen erlauben. hierzu als Info: meshcore:allgemeines:regions:reale-regions-in-repeatern [MeshCore Wiki DE]
In D ist die Sache publiziert. meshcore:allgemeines:regions:reale-regions-in-repeatern [MeshCore Wiki DE] Man schätzt dort offenbar den Nutzen von unverschachtetln Regionen höher ein, als dass auf ein Firmware, welche dann die Verschachtelung erlaubt, gewartet wird. Diese Einschätzung teile ich.
Bei einer Veröffentlich ist m.E. wichtig, dass der Nutzen, welcher mit der Nutzung der Regionen beim Senden verbunden ist (Einstellung der Region in Channels) explizit hervorgehoben wird.
Insbesondere weil wir Erfahrungen mit den Weitverbindungen machen wollen, sollte ch, ch-de, ch-fr, ch-it als Mindest-Einstellung im Repeater empfohlen werden. Es wird bestimmt in Zukunft in verschiedenen Landesteilen auch Versuche geben mit Kantons- oder Stadteinstellungen.
Unbedingt und mit Nachdruck ist darauf hinzuweisen, dass *^ immer Allowd sein muss. Wenn zum jetzigen Zeitpunkt jemand daran schraubt wird es kritisch.
Es wird schwierig, diese Region-Einstellungen zu kommunizieren, durchzusetzen und zu überwachen. Ein Automatismus über die App (Preset wie bei den Funkparametern oder Kopieren / Übernahme von benachbarten Repeatern) oder Firmware (fix vordefinierte Regions) würde das Ganze vereinfachen.
Ja bei den Repeatereinstellungen gerne hinzufügen,
aber auch auf der Channel Seite, ev. mit Recommendation für die einzelnen Channels: #switzerland > ch, #suisse > ch-fr, #svizzera > ch-it, usw.
Ich bin nicht so überzeugt von den Verschachtelten Regionen und
ich denke wir sollten was festlegen, bevor jeder sein eigenes Schema wählt.
Gruss Eric
PS: ev. auch der link zu Regionen der anliegenden Länder erwähnen?
für mich wäre hier in Basel auch de DE: de-bw, de-bw-loe, de-bw-muel relevant, sowie ev. Frankreich.
Heute habe ich Europa Nachrichten. Ich finde, zu den vorgeschlagenen Mindesteinstellungen sollte auch europe gehören. Nicht von Anfang an zu klein partitionieren, eher gross die Sache angehen und bei Bedarf verkleinern. My 5c.
den Link zum Wiki, welches unsere Nachbarn betreiben, wäre ebenfalls einzufügen. Jeder RPT-Admin kann dann selber entscheiden, was in seiner Region Sinn macht.
Angeregt durch deinen Vorschlag zur Anbindung der grenznahen Regionen wäre vielleicht sogar eine Region ‘europe’ sinnvoll. Dies um einen Kanal für Weitverbindungen einzurichten?
Ich bastle bei Gelegenheit mal eine separate Seite auf https://www.meshcore.ch zu diesem Thema. Ist wohl zu Gross um das einfach in SETTINGS | MeshCore Switzerland abzudecken. Ich kann die dann von Google auschliessen und zuerst mal hier Posten.
Auch wenn das Thema noch nicht abgeschlossen ist, ich denke je früher wir einen Ansatz vorschlagen desto weniger Chaos wird entstehen, sonst machen alle einfach irgendetwas.
Schlussendlich sind wir mit dem ‘Radio in der Hand’ abhängig von dem was die Software-Schmiede programmieren (bisher war das meistens gut, darum ist MeshCore auch eine kleine Erfolgsgeschichte).
Zudem müssen wir bedenken, dass wir nur empfehlen können… durchsetzen geht nicht. Empfehlen klappt dann eigentlich auch nur, wenn Vor- und Nachteile auf dem Tisch liegend abgewogen werden können.
Ich bin ein Anhänger der Idee, dass möglichst viele Parameter durch den Benutzer eingegeben werden können/müssen, damit er Anpassungen für den Betrieb im ‘Feld’ an die lokalen Gegebenheiten selber vornehmen muss. Auch wenn das etwas komplex ist und ‘selber Denken’ dafür gefragt ist.
Einstellungen, welche ein gewisses Verständnis für das gesamte System und die technischen Eigenheiten erfordern, helfen zudem, dass die Sache schlussendlich nicht zu einem ‘Spielzeug’, so im Sinn von ‘Plug and Play’ wird.