Hallo zusammen,

das Anhängen der SNR/RSSI-Werte an Positionspakete beim "Gateway V" (iot4pi LoRa-APRS-iGate) kann mit nachstehendem "Patch" deaktiviert werden. Dies ist vor allem bei einer höheren Gatewaydichte erforderlich da sonst die Diplikatsfilterung nicht mehr funktioniert und damit das APRS-Netzwerk überlastet werden kann (siehe dazu auch hier):

Hallo zusammen,

einige LoRa-Gateways fügen den empfangenen Positionspaketen SNR/RSSI-Messwerte hinzu. Dies mag zwar auf ersten Blick recht nützlich sein; sobald die Dichte an Gateways regional zunimmt führt das jedoch zu Problemen. Wird dann eine Aussendung von mehreren Gateways gleichzeitig empfangen funktioniert die Duplikatsfilterung nicht mehr:

2021-03-16 06:46:58 CET: DL3DCW-9>APRS,qAO,DL3DP-4:!5121.22N/00720.17E>LoRa-Station SNR=-1dB RSSI=-84db
2021-03-16 06:46:58 CET: DL3DCW-9>APRS,qAO,DF6DP-10:!5121.22N/00720.17E>LoRa-Station SNR=-9dB RSSI=-75db
2021-03-16 06:46:58 CET: DL3DCW-9>APRS,qAO,DL3DCW-10:!5121.22N/00720.17E>LoRa-Station SNR=-19dB RSSI=-91db

Völlig identische Positionspakete werden somit mehrfach ins APRS-Netzwerk weitergeleitet. Innerhalb des APRS-IS ist das natürlich kein Problem. Bei Wiederaussendung der Positionsdaten via Funk aber doch. Denn dann werden diese Mehrfachpakete auch alle kurz hintereinader wieder ausgesendet. Und belegen die Frequenz damit völlig unnötig. Bei aprs.fi gibt es dann folgenden Hinweis:

Diese Station sendet Pakete mit einer hohen Geschwindigkeit, was zur überlastung des APRS Netzwerks führen kann.

In diesem Fall liegt das nicht an einem zu kurzem Sendeinterall sondern an den Duplikaten. Es ist daher nicht sinnvoll das z.B. Gateways "Manipulationen" an den empfangenen Datenpaketen - wie die Ergänzung des SNR/RSSI-Wertes - vornehmen. Daher sollte man diese Funktion möglichst abschalten bzw. lediglich für kurze Tests verwenden.

Schönen Gruß
Frank

P.S. Einen "Patch" zur Dekativierung von SNR/RSSI beim "Gateway V" (iot4pi LoRa-APRS-iGate) gibt es hier: https://forum.aprs-dl.de/showthread.php?tid=36&pid=85

Ich habe heute die aktuelle Version MyBB 1.8.26  installiert.
Es handelt sich um ein Sicherheitsupdate, welches eine Sicherheitslücke mit hohem Risiko, vier mit mittlerem und eine mit niedrigem Risiko schließt.


Falls Fehler bemerkt werden, bitte Mail an mich.

In unserer Region (Wuppertal/Bochum/Hagen) gibt es seit ein paar Wochen die ersten LoRa-Gateways. Weitere sind in Vorbereitung:

   

Derzeit verwenden viele LoRa-Gateways in der Region zur eindeutigen Kennzeichnung das weiße "L" auf rotem Hintergrund.

Derzeit haben sich in DL anscheindend folgende Parameter für LoRa-APRS durchgesetzt:

Frequenzen:

TX-Frequenz: 433.775 MHz (von Tracker zu iGate)
RX-Frequenz: 433.900 MHz (von iGate zu Tracker - bei RxGates nicht aktiv)

Übertragungsparameter:

Spreading factor: SF12
Bandwidth: 125 kHz
Coding rate: 4/5

Empfehlungen:

Info-/Kommentarfeld: Für eine bessere Effizienz sollte der Eintrag so kurz wie möglich sein. Redundante Information sollte man vermeiden.
Kompression: Für eine bessere Effizienz sollte man möglichst Kompression/MIC-E benutzen. Das spart etwa 10-20% Übertragungszeit.

Digipeating:

Digipeating findet meines Wissens nur an sehr wenigen Standorten statt. Man sollte überlegen ob dies überhaupt erforderlich ist. Denn im Vergleich zu 2m-APRS dauert eine LoRa-Aussendung deutlich länger (etwa 3 Sekunden). Digipeating würde die Frequenz also vermutlich recht stark belasten. Der Einsatz von möglichst vielen (Rx)Gates könnte sinnvoller sein.

Format:

Meinen Beobachtungen nach wird an den meisten Standorten in DL das OE-Format eingesetzt. Das betrifft die ersten drei Bytes der LoRa-Aussendung. Diese sind 0x3c, 0xff, 0x01. Der Rest des Datenpaketes wird in reinem ASCII übertragen. Die CRC-Berechnung/Auswertung übernimmt der LoRa-Chip.

Protokoll:

Auch für LoRa-APRS gelten natürlich Protokollbeschreibung sowie Empfehlungen von Bob, WB4APR (siehe http://www.aprs.org).

SSID/Symbole:

Auch hier gelten die Empfehlungen von WB4APR. Bei den Symbolen zur Kennzeichnung von LoRa-iGates gibt es im Moment noch unterschiedliche Ansätze. Eine Vereinheitlichung halte ich für sinnvoll.

Hinweis: Die oben aufgefühten "Grundeinstellungen" fußen auf meinen aktuellen Beobachtungen und sind nicht in Stein gemeißelt. Ich denke das sich einiges ganz bestimmt noch weiterentwicklen wird und es ggf. Änderungen gibt.

APRScube - Projekt:

Hier mal mein eigenes kleines LoRa-APRS Projekt: Der "APRScube". Er ist als Tracker sowie als Gateway einsetzbar.

   

Die Hardware basiert auf fertigen Modulen der "M5Stack"-Reihe und ist komplett modular aufgebaut. Es gibt eine Menge Zubehör.

   

Tischfuß mit Temperatur- und Feuchtesensor; externer Sensor zusätzlich mit Luftdruck. Übertragung per APRS-Telemetrie.

Angehängte Dateien

  APRScube_install.pdf (Größe: 599,66 KB / Downloads: 255)
  APRScube_manual.pdf (Größe: 689,03 KB / Downloads: 280)
  APRScube_firmware_13.zip (Größe: 516,18 KB / Downloads: 170)
  APRScube_firmware_13f.zip (Größe: 523,81 KB / Downloads: 161)
  APRScube_firmware_13i.zip (Größe: 527,23 KB / Downloads: 307)

LoRa-APRS "Gateway V" von Bernd, OE1ACM und Christoph, OE1CGC. Weitere Infos und Bezugsquelle unter www.lora-aprs.at

   

LoRa-APRS "Tracker 1W" von Bernd, OE1ACM und Christoph, OE1CGC. Weitere Infos und Bezugsquelle unter www.lora-aprs.at

   

LoRa-APRS "Tracker D" von Bernd, OE1ACM und Christoph, OE1CGC. Weitere Infos und Bezugsquelle unter www.lora-aprs.at

   

Wäre es möglich die als Anhang hochgeladenen Bilder nicht nur als Thumbnail sondern z.B. bis zu einer gewissen maximalen Größe (z.B. 800x600) vollständig darzustellen?

Ich finde die Thumbnails zu klein um diese übersichtlich in einen Beitrag einzubauen. Denn man muss als Leser meist immer drauf klicken um den Inhalt erkennen zu können.

Bisher habe ich daher die Bilder meistens extern eingebunden. Dann kann man diese so groß darstellen das es prima und übersichlich in einen Beitrag passt. Allerdings ist es blöd wenn irgendwann mal die externe Quelle wegfällt oder die Dateien verschoben werden. Dann fehlen den Foren/Beiträgen die Bilder ...