!! IMPORTANT !! Its important to note that for multi byte path support if you keep V1 header with single byte path it is backwards compatible but if you enable multi-byte path’s all nodes in the path must be updated
From a practical perspective what this means, if I understand correctly, is all repeater should be updated first before trying multi-byte. More on this here Meschore multi-byte path hash's
Mentioning your other posting about the multi-byte path → they should, maybe, step back from releasing new firmware like crazy. Some tiny bugs are part of the game but bugs able to brick remote access etc are not an achiveable goals.
not everyone in here has repeaters who are easy to access. Dropping a new firmware with, more or less, important new functions once a month is nice. Updating every repeater in remote areas once a month not so much. If that new firmware has a possible major bug this causes major problems too.
in my opinion, extensive testing with less frequent releases is more reliable then what they do right now. Dont get me wrong - i like that progress. But not if quality control suffers.
Werde dieses Firmware-Update überspringen und meine Repeater beim nächsten ‘Service’ in ca. 4 Monaten aufrüsten!
Einen Repeater auf dem Fensterbrett updaten mag gehen. Einen Repeater mit langem Anmarschweg - irgendwo im Feld - updaten ist eine andere Sache.
ich verstehe den Bug nicht 100%. Habe 1.14 geladen und mit RAK4631 keinen negativen Impact gesehen. Auch nachdem ich Powersave engeschaltet hatte welches ich zuvor noch nie benutzt habe und jetzt da die Tage wieder länger werden eh nicht benötige.
Ich ich interpretiere den Bug so dass es ohne Powersave was man explizit einschalten muss eher ein kosmetisches Problem ist da Queue Länge immer als 0 angezeigt wird.
hasPendingWork() reports false even when packets are queued, causing Repeater to go to sleep with work still pending, and stats show queue_len = 0 incorrectly.
Mit Powersave eingeschaltet könnte ein für Management verwendetes Packet in der Queue stecken und trotzdem der Prozessor in Tiefschlaf gehen. Damit wäre Remote Management schwierig.
Gerne möchte ich auch erneut auf die Evo Releases aufmerksam machen: Releases · mattzzw/MeshCore-Evo · GitHub . Heute ist der Fix zwar da auch noch nicht enthalten, aber ich nehmen and dies wird bald integriert. Zusätzlich einige sinnvolle PR’s welche es noch nicht in Main geschafft haben. Bei useren deutschen Kollegen scheinen EVO release jedoch häufig eingesetzt zu werden.
PR1810: Allow direct message paths when denyf * is set, damit könnte nicht mit Region versehener Channel Verkehr bei Bedarf unterbunden werden ohne die anderen Verkehrsarten zu beeinträchtigen
Die in v1.14 enthaltenen Features finde ich sinnvoll. Zudem denke ich auch dass einige Repeater bereits seit längerem einen Upgrade nötig hätten. Wäre schade wenn sich die Einführung infolge des bereits behobenen Bugs um Monate verzögern würde.
Für mich persönlich werde ich die EVO‘s momentan nicht nutzen. Ständig einen Vergleich zweier Firmwares machen zu müssen, eventuelle Kompatibilitätsprobleme zwischen EVO und Non-EVO Repeatern eingehen usw ist nicht unbedingt erstrebenswert.
Und ich denke dass die meisten Repeater-Betreiber die offizielle Firmware verwenden werden. Auch wenn ich der EVO nichts negatives zusprechen will natürlich! Aber denke der Nutzen ist beschränkt wenn ohnehin viele Repeater noch auf deutlich älteren FW-Ständen sind (habe selber noch welche mit 1.10 oder 1.11) und eventuell teilweise Kompatibilitätsprobleme von Features auftreten würden weil EVO Features nicht von 0815-Meshcore-Firmware unterstützt werden würde.
EVO ist nur ein Repeater Release und absolut kompatibel mit Devicefirmware.
EVO wird vor allem bei unseren nördlichen Nachbarn eingesetzt und auch da entwickelt. Ist jeweils der gerade aktuelle DEV Release ( oder jetzt gerade auch MAIN) mit wenigen zusätzlichen PR’s und hilft in Bereichen mit vielen zusammenhängenden Regionen den Verkehr einigermassen einzudämmen.
Ich sehe momentan bei mir in den abendlichen Spitzenzeiten 50-60 Pakete pro Minute, da ist nicht mehr sehr viel Luft übrig.
Direktmessages und Repeater Admin geht dann häufig nicht mehr.
Am Anfang ist es noch spannend Adverts aus München, Stuttgart oder Genua zu erhalten. Spätestens wenn das Wallis nicht mehr eine Insel ist und du vor lauter Pings, HA Skripten und Adverts nicht mehr auf das Managementinterface deiner 1-2 Hops entfernten Repeater kommst, wirst du die Notwendigkeit sehen.
Von einem prominenten Repeater sehe ich zudem über eine Stunde bereits ca 7% Airtime, und das ist lediglich was ich empfangen und dekodieren kann. Nehme an das die eigentliche TX Airtime noch höher ist und langsam am zugelassenen Duty Cycle kratzt.
Auch da ist es zwingend nötig eine gute Duty Cycle Steuerung zu implementieren. Der normale Release macht dies nicht sondern erzwingt lediglich einen Mindestabstand zwischen Paketen. Wenn ein Node 50 Minuten lang inaktiv war und dann einen Burst sendet, hat das Verzögerungsmodell keinerlei Erinnerung an diese Ruhezeit. Es erzwingt nach einem einzelnen kurzen Paket eine unnötig lange Sendepause, obwohl der Node weit unter dem stündlichen Limit liegt.
I agree there is some good stuff in 1.14 but it still feels like its not quite the build you want to have running in your, hard to access or important repeaters, based on what I have been seeing in various discussion groups. Hence my comment not rush to install it.
I wish the EVO changes would be integrated into the dev branch of the MC firmware but there is no visibility on when this might happen…
Once the snow starts to melt I believe Valais will join the rest of the network.
Wie recht du hast, Stef… es ist wahrlich schwer zu verstehen. Einmal mehr stehen ganz viele Nutzer einer Technik vor der Tatsache, dass sie sich wegen dem Tun einiger vor deren Unfug schützen müssen.
Ich bin gegen ‘Räuber- und Polizeispiele’ sondern strebe eigentlich im Gespräch Lösungen zu Gunsten des Gemeinwohls an. So auch hier.
Meine Versuche, z.B. mit dem Betreiber des Pong-Bots in Winterthur in Kontakt zu treten (Aufruf mit meiner Mailadresse während zwei Wochen zu verschiedenen Zeiten, mit der Bitte um Kontaktaufnahme). Übrigens: Dieser Bot sendet auf entsprechenden Call-Code auch Propagationsdaten aus:
Wer mit dem Analyzer den Verkehr auf MeshCore in der Schweiz beobachtet, teilt deine Sorgen, Steff.
Ich werde wohl - weil bei einigen Menschen Handeln zum Eigennutz vor dem Handeln zum Gemeinnutz steht - nicht darum herum kommen ‘Firmware-Akrobatik’ zu betreiben. Das weil es mein Ziel ist, dass möglichst viele Nutzer von guten Repeaterstandorten profitieren können.
