https://forum.aprs-dl.de/ Mon, 06 Apr 2026 09:00:49 +0000 MyBB https://forum.aprs-dl.de/showthread.php?tid=63 Mon, 28 Nov 2022 16:52:42 +0100 DG3BFP]]> https://forum.aprs-dl.de/showthread.php?tid=63
Auf APRS.org finde ich keine Hinweise zu der SSID bei LoRa, die Datei ist ja auch von 2012.
Ich habe bereits das Netz zu dem Thema durchsucht, auch im englisch sprachigen Bereich, aber keine Hinweise dazu gefunden.

Das L steht wohl für LoRa.
Wieso wurde die 4 gewählt?]]>
Auf APRS.org finde ich keine Hinweise zu der SSID bei LoRa, die Datei ist ja auch von 2012.
Ich habe bereits das Netz zu dem Thema durchsucht, auch im englisch sprachigen Bereich, aber keine Hinweise dazu gefunden.

Das L steht wohl für LoRa.
Wieso wurde die 4 gewählt?]]> https://forum.aprs-dl.de/showthread.php?tid=37 Thu, 18 Mar 2021 11:52:27 +0100 DL3DCW]]> https://forum.aprs-dl.de/showthread.php?tid=37
http://www.aprs.org/symbols/symbols-new.txt]]>
http://www.aprs.org/symbols/symbols-new.txt]]> https://forum.aprs-dl.de/showthread.php?tid=35 Wed, 17 Mar 2021 09:47:19 +0100 DL3DCW]]> https://forum.aprs-dl.de/showthread.php?tid=35
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]]>
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]]> https://forum.aprs-dl.de/showthread.php?tid=32 Wed, 10 Mar 2021 08:35:21 +0100 DL3DCW]]> https://forum.aprs-dl.de/showthread.php?tid=32
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.]]>
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.]]>