02.11.2021, 17:02
Das ist ganz bewusst nicht vorgesehen. Mit steigender Dichte der LoRa-Gateways - die ist vielerorts ja im Moment sogar schon sehr gut - halte ich das auch nicht für erforderlich. Digipeating belastet die LoRa-Frequenz sehr stark da die Aussendungen deutlich länger dauern als auf 2m. Zudem würde die Angabe eines oder mehrerer Digipeater auch das eigene Datenpaket weiter verlängern.
Wenn wir die LoRa-APRS Frequenz möglichst nur für Tracker bzw. bewegliche Stationen und ggf. gut überlegte Sonderanwendungen verwenden, Digipeating vermeiden und dafür besser viele Gateways einsetzen sowie die eigenen Datenpakete kurz halten (also keinen ganzen Lebenslauf oder redundante und damit überflüssige Angaben in den Infotext) werden wir lange Freude daran haben. Dies scheint mir persönlich im Moment am sinnvollsten zu sein.
Ähnlich sollte man vielleicht auch bei den TX-Gateways verfahren. Da macht es wohl auch nicht sehr viel Sinn den APRS-IS Traffic auf der LoRa-Frequenz weiterzuverbreiten. Aber das Thema betrifft ja nicht nur den APRScube. Daher habe ich hier mal ein paar Gedanken dazu geschrieben: http://forum.aprs-dl.de/showthread.php?t...283#pid283
Wenn wir die LoRa-APRS Frequenz möglichst nur für Tracker bzw. bewegliche Stationen und ggf. gut überlegte Sonderanwendungen verwenden, Digipeating vermeiden und dafür besser viele Gateways einsetzen sowie die eigenen Datenpakete kurz halten (also keinen ganzen Lebenslauf oder redundante und damit überflüssige Angaben in den Infotext) werden wir lange Freude daran haben. Dies scheint mir persönlich im Moment am sinnvollsten zu sein.
Ähnlich sollte man vielleicht auch bei den TX-Gateways verfahren. Da macht es wohl auch nicht sehr viel Sinn den APRS-IS Traffic auf der LoRa-Frequenz weiterzuverbreiten. Aber das Thema betrifft ja nicht nur den APRScube. Daher habe ich hier mal ein paar Gedanken dazu geschrieben: http://forum.aprs-dl.de/showthread.php?t...283#pid283
![[-]](https://forum.aprs-dl.de/images/collapse.png)