LoRa APRS iGate auf RaspberryPi mit dxlAPRS Tools

LoRa APRS ist eine immer weiter verbreitete neue Übertragungsart für APRS im Amateurfunk. APRS ist bereits seit vielen Jahren weit verbreitet. Durch das LoRa Modulationsverfahren können APRS Daten auch mit kleinsten Leistungen über größere Entfernungen störungsfrei übertragen werden.

Letztes Update: 27.11.2021

Die folgende Anleitung ist veraltet und dient nur noch Archivzwecken. Inzwischen ist es möglich mit ra02 aus den dxlAPRS Tools ein LoRa APRS iGate zu betreiben. Dies ist viel einfacher und dringend zu empfehlen. Hier gehts zum ensprechenden Artikel.

Übersicht:

Vorwort – Erste Schritte mit LoRa APRS
Anleitung LoRa APRS iGate mit dxlAPRS (Nur RX)
Anleitung LoRa APRS iGate mit dxlAPRS (RX und TX)
Downloads und Einrichtung
Support

Erste Schritte mit LoraAPRS

Im Jahr 2019, als wir beim DARC OV Haßberge B37 nach einer interessanten Nutzlast für einen Stratosphärenballon suchten, sind wir auf die Modulationsart LoRa gestoßen. Einer „Long Range“ Funkanwendung, die hauptsächlich im IoT Bereich für Datenübertragung genutzt wird. Findige Funkamateure aus Österreich haben begonnen das LoRa Verfahren auch für APRS im Amateurfunk zu verwenden. Die Idee APRS mit kleinsten Leistungen im 70cm Amateurfunkband zu betreiben und damit trotzdem erstaunliche Reichweiten zu erzielen war das ideale Experiment für einen Stratosphärenballonflug. Ein direkter Vergleich zwischen 2m APRS gegen 70cm APRS gegen 70cm LoRa APRS war sehr reizvoll. Was davon geht besser? Die Umsetzung dieses Tests wurde dann jedoch auf den zweiten Ballonstart verschoben.

Leider ist das LoRa Verfahren immernoch geschützt, weswegen es keine quelloffnene Software zum Dekodieren gibt. Ein Empfang über SDR-Sticks ist damit (legal) bisher nicht möglich, wenngleich es solche Projekte gibt die auf „Reverse Engineering“ basieren. Entwickler sind von sowas aber nicht wirklich angetan. Man ist daher auf die kommerziellen LoRa Funkchips angewiesen, möchte man im LoRa aktiv werden. Das Entwicklerteam rund um lora-aprs.at hat dazu einige Platinen für Tracker und Gateway entwickelt. Inzwischen gibt es auch schon sogenannte LoRa „TTGO Beams“, welche aus Fernost stammen und auch für LoRa APRS geeignet sind.

Ich habe mir einen „Tracker D“ und ein „Gateway V“ besorgt und aufgebaut. Es funktionierte alles soweit auf Anhieb. Einzig allein die Gatewaysoftware machte mir Kopfzerbrechen. Zur Verfügung gestellt wird ein Image mit einer vorinstallierten Software (IoT4Pi) für einen RaspberryPi (Zero). Fertige Images sind zwar schön und für viele nützlich, aber wenn man für alles einen extra RaspberryPi benötigt, ist das wenig effektiv. Auch „versteht“ man die Software nicht, wenn man etwas vorgefertigtes nutzt. Mein Wunsch war es, langfristig LoRa APRS in ein bestehendes iGate mit integrieren zu können. Quasi als „zusätzlichen“ Kanal für APRS Übertragungen neben 144,800 MHz und 432,500 MHz AFSK.

Alternatives LoRa APRS iGate

Als ich dann das Projekt RPi-LoRa-KISS-TNC von Tom OE9TKH entdeckte, wurde ich hellhörig. Diese Software stellt eine TCP-KISS-Schnittstelle an einem LoRa APRS Gateway bereit. Die Gatewayplatinen von OE1ACM sind dazu ebenfalls kompatibel. Über die bereitgestellte TCP-KISS Schnittstelle kann man dann eine beliebige APRS-Software „andocken“. Im Projekt von OE9TKH wird dazu die Software APRX genutzt. Diese fungiert dann als Schnittstelle zwischen dem APRS-IS Netzwerk und dem LoRa-APRS Funkkanal. Neben APRX hat auch Direwolf solch eine TCP-KISS-Schnittstelle. Viel interessanter für mich jedoch war, das LoRa APRS an die Gatewaysoftware udpgate4 von Chris OE5DXL anzubinden. In unserer Region laufen bereits einige APRS iGates mit der dxlAPRS Toolchain von OE5DXL. Was liegt da ferner als ein solches Gateway mit LoRa APRS zu erweitern? Dies hätte viele Vorteile.

  • Nutzung von „normalem“ APRS und LoRa APRS auf ein und dem selben RaspberryPi. Dadurch Einsparung von Hardwarekosten, Platzbedarf und Energie.
  • Nutzung der Flexibiliät und Funktionsvielfalt der dxlAPRS Toolchain

Diese Lösung funktionierte schon sehr gut. Allerdings benötigte man ein extra Tool um zwischen KISS und AXUDP die Daten zu transportieren. Der Wunsch lag nahe, dass das LoRa KISS TNC direkt in AXUDP, also ohne den Umweg über KISS, kommunizieren könnte. In ersten Gesprächen mit Chris machte er uns Hoffnung dass dies kein großes Problem wäre. Er würde uns auch den Python Code zur Verfügung stellen um APRS Daten in AXUDP zu übertragen. Matze DM4TZE machte sich nun daran den Code des RPi-LoRa-KISS-TNC passend umzuschreiben und zu ergänzen. Er hat dabei auch diverse Verbesserungen durchgeführt. Beispielsweise lassen sich die wichtigsten Konfigurationsparameter nun zentral in einer Datei einstellen.

Matze hat sein Projekt hier auf Github veröffentlicht: https://github.com/dm4tze/RPi-LoRa-KISS-TNC/tree/axudp. Der entsprechende branch „axudp“ ist zu beachten!

Anleitung Installation LoRa APRS iGate (nur RX) mit dxlAPRS Gatewaysoftware

Diese Anleitung basiert auf der Installationsanleitung von Tom OE9TKH (mit Stand 26.04.2020) und wurde etwas angepasst für die Nutzung mit dxlAPRS und der Programmvariante von Matze DM4TZE.

Ich gehe im Folgenden davon aus, das ein bereits bestehendes Raspbian auf einem RaspberryPi läuft, und gehe daher nicht weiter auf das Einrichten eines RaspberryPi mit Raspbian Betriebssystem ein. Auch ist bereits entweder ein „LoRa APRS Gateway HAT“ von OE1ROT oder ein „LoRa APRS Gateway V“ von OE1ACM vorhanden und funktionsfähig. Getestet wurde es mit dem RaspberryPI und einem OrangePI. Theoretisch sollte es auch auf anderen Einplatinenrechnern wie dem BananaPi etc. laufen. Allerdings ist auf die entsprechende GPIo Belegung zu achten und es müssen für das System angepasst Libraries für LoRa verwendet werden.

1. SPI Schnittstelle Aktivieren

Als erstes muss die SPI Schnittstelle im RaspberryPi aktiviert werden. Dies geschieht in der Konsole mit

sudo raspi-config

SPI aktiviert man dann unter INTERFACING OPTIONS > SPI
In der grafischen Oberfläche geht man im Startmenü unter EINSTELLUNGEN > RASPBERRY-PI-KONFIGURATION > SCHNITTSTELLEN. In beiden Fällen muss anschließend der RaspberryPi neu gestartet werden.

2. dxlAPRS Tools installieren

Die Installation der Tools ist hier noch ausführlicher beschrieben: http://dxlwiki.dl1nux.de/index.php?title=Installationsanleitung

Für den RaspberryPi Version 1 und Zero/W(H) wird die Version armv6, für alle neueren RaspberryPIs die Version armv7hf benötigt. Bitte bei der Installation beachten!

Beispiel für RaspberryPi 2B und neuer:

cd ~
wget http://dxlaprs.hamspirit.at/dxlAPRS_armv7hf-current.tgz
tar xzvf dxlAPRS_armv7hf-current.tgz --strip=1 scripts/updateDXLaprs
./updateDXLaprs dxlAPRS_armv7hf-current.tgz

Die dxlAPRS Tools befinden sich anschließend unter ~/dxlAPRS/aprs

Ein manuelles zusätzliches Update, wie in der Installationsbeschreibung erwähnt, kann optional durchgeführt werden.

3. RPi-LoRa-KISS-TNC installieren

Wir benötigen git und diverse python3 Pakete und laden anschließend die benötigten RPi-LoRa-KISS-TNC Pakete herunter:

cd ~
sudo apt install python3 python3-rpi.gpio python3-spidev git python3-pil python3-smbus
git clone --branch axudp https://github.com/dm4tze/RPi-LoRa-KISS-TNC.git
cd RPi-LoRa-KISS-TNC
git clone https://github.com/mayeranalytics/pySX127x.git

Nun müssen wir noch eine Datei bearbeiten:

nano pySX127x/SX127x/board_config.py

Wir ersetzen in Zeile 36
DIO0 = 22 # RaspPi GPIO 22
durch
DIO0 = 5 # RaspPi GPIO 5

4. Konfiguration anpassen

Im Ordner RPi-LoRa-KISS-TNC befindet sich die Datei config.py, welche wir noch anpassen müssen.

AXUDP_REMOTE_IP = „127.0.0.1“
AXUDP_REMOTE_PORT = 9001
AXUDP_LOCAL_IP = „127.0.0.1“
AXUDP_LOCAL_PORT = 0
USE_AXUDP = True
APPEND_SIGNAL_REPORT = True

Erklärung der Paramter:

AXUDP_REMOTE_IP An diese IP-Adresse werden die empfangene AXUDP Daten gesendet.
AXUDP_REMOTE_PORT An diesen Port werden die empfangene AXUDP Daten gesendet.
AXUDP_LOCAL_IP Von dieser IP-Adresse werden AXUDP Daten zum Zweck der Aussendung über HF empfangen (Nur für sendefähige iGates notwendig)
AXUDP_LOCAL_PORT Auf diesem Port werden AXUDP Daten zum Zweck der Aussendung über HF empfangen. Für RX only iGates Port = 0
USE_AXUDP True = Es werden AXUDP gesendet und empfangen.
False = Es wird das KISS Protokoll verwendet. In diesem Fall sind die Parameter TCP_HOST und TCP_PORT zu konfigurieren.
APPEND_SIGNAL_REPORT Füge einen Signal-Rapport mit RSSI und SNR in den Kommentartext ein.
Beispiel: DL1NUX-12>APRS:!5014.07N\01059.01EQ013/000/A=001059LoRa Tracker 60 mW RSSI=-113dBm SNR=-19dB
Hinweis: Diese Funktion solle nur zu Eperimentalzwecken aktiviert sein. Das Problem entsteht wenn mehrere iGates in Reichweite sind. Die Pakete unterscheiden sich wegen dem unterschiedlichen Kommentartext. Es tauchen daher alle Pakete im APRS-IS Netzwerk auf und nicht wie sonst üblich nur eines.

Im oben genannten Beispiel werden die empfangenen Daten lokal (127.0.0.1) an den Port 9001 gesendet.

5) Programme starten

Wenn man nun das Startskript Start_lora-tnc.py startet, sollte erstmal nichts weiter sichtbares passieren.

python3 Start_lora-tnc.py

Wenn hier Fehlermeldungen erscheinen, funktioniert entweder eure Platine nicht oder ihr habt vorher einen Fehler bei der Installation gemacht. Nun kommt udpgate4 ins Spiel. Bitte die entsprechenden Programm- und Dateipfade beachten und ggf. anpassen!

udpgate4 -s MYCALL-10 -R 127.0.0.1:0:9001#LoRa -n 30:/home/pi/dxlAPRS/aprs/netbeacon.txt -g rotate.aprs2.net:14580#m/1,-t/t -p PASSCODE -t 14580 -w 14501 -v -D /home/pi/dxlAPRS/aprs/www/

UDPGATE4 ist das iGate, welches die empfangenen APRS Pakete an einen beliebigen APRS-Server im Internet oder Hamnet weiterleitet.

Die Parameter:
-s <call> = server call of this server -s MYCALL-2
-R <ip>:<dport>/<lport>[+<byte/s>[:<radius>]][#<portname>] (axudp format)
-n <min>:<file> = netbeacon minutes:filename
-g <url>:<port>[#<filters>] connect to APRS-IS gateway, repeat -g for a list
-p <password> = login passwort for aprs-is servers -p 12345
-t <localport> = local igate tcp port for in connects -t 14580
-w <port> = port of www server -w 14501
-v = show frames and analytics on stdout
-D <path> = www server root directory (-D /usr/www/)

Erklärung:

  • Das iGate empfängt die APRS Pakete im AXUDP Format auf Port 9001 (-r) auf dem gleichen Rechner (127.0.0.1) vom RPi-LoRa-KISS-TNC.
  • Zwischen 127.0.0.1 und dem Port 9001 ist noch eine Null. Dies ist der „destination port“ der bei einem reinen Empfangs iGate irrelevant ist und daher auf „0“ steht. Bei einem Zwei-Wege Gateway, kommt hier der Port rein, der die Daten zum RPi-LoRa-KISS-TNC sendet. „#LoRa“ gibt den Namen des Ports an, welcher dann in der mh-Liste auf der Weboberfläche erscheint. Man kann so die verschiedenen „Eingangskanäle“ der APRS-Stationen unterscheiden, falls mehrere vorhanden sind.
  • Es wird außerdem alle 30 Minuten eine APRS Bake mit dem Inhalt der Datei netbeacon.txt eingerichtet („- n“). Die „Bake“ erzeugt für das iGate ein entsprechendes Symbol auf der APRS Karte (z.B. bei aprs.fi) unter dem Rufzeichen „MYCALL-10“. Es sollte keinesfalls öfter eine Bake gesendet werden! Es reichen sogar 60 Minuten. Die Symbole bleiben trotzdem auf der APRS Karte (z.B. aprs.fi) sichtbar. Die Aussendung der Bake kann unterbunden werden, wenn man den String mit -n komplett weglässt. Eine Ausfallsicherheit durch Angabe mehrerer iGates ist möglich, siehe unten.
  • Die APRS Daten werden an den Server rotate.aprs2.net auf Port 14580 gesendet. Es kann auch jeder beliebige andere APRS-Server im Internet oder Hamnet verwendet werden. Es sind noch Filter hinterlegt (#m/1,-t/t), welche Übermittlung und Anzeige von unnötigen Informationen aus dem APRS-Netzwerk unterdrückt.
  • Den Passcode für die Übermittlung (Kann z.B. hier generiert werden: https://apps.magicbug.co.uk/passcode/) übergibt der Paramter „-p“.
  • -t gibt den Port an, auf dem das iGate für eingehende Verbindungen lauscht. Dieser Port darf auf diesem Rechner noch nicht in Benutzung sein und lautet standardmäßg 14580. Das iGate kann dadurch auch von anderen Stationen per TCP connected werden zur Übermittlung von APRS-Daten an das entfernte APRS Gateway.
  • -w gibt den Port an, auf dem die Weboberfläche des iGate abrufbar ist (auf dem iGate Rechner selbst z.B. mit der Adresse 127.0.0.1:14501 im Browser abrufbar). Von anderen Rechnern aus mit http://IP-Adresse:14501
  • -D gibt den Pfad an, an dem die Dateien für die iGate Weboberfläche abgelegt sind.
  • Außerdem werden mit -v die gesendeten und empfangenen APRS Frames im Terminalfenster ausgegeben (kann bei standalone Nutzung entfallen).

Die Datei netbeacon.txtenthält den Bakentext und muss noch angelegt werden:

nano /home/pi/dxlAPRS/aprs/netbeacon.txt

Einfach den folgenden Inhalt hineinkopieren und nicht vergessen die eigenen Koordinaten einzutragen. Das für LoRa APRS vorgesehene Symbol (Schwarzer Diamant mit „L“ = L&) ist hier bereits integriert.

!5010.00NL01100.00E&LoRa APRS iGate von MYCALL
#
# Geokoordinaten in Grad und Dezimalminuten ohne °-Symbol
# Beispiel 50°10.00 N = 5010.00N und 011°00.00 E = 01100.00E
# Die Ost-Gradzahl muss immer! dreistellig angegeben werden, also 011 bei 11 Grad Ost
#
# APRS-Symbol ist änderbar durch ersetzen der Symbolzeichen nach dem N
# und nach dem E, siehe auch APRS Symboltabelle unter:
# https://www.yachttrack.org/info_camper/downloads/APRS_Symbol_Chart.pdf

Tipp: Ausfallsicherheit des Gateways:

Es kann auch eine Datei mit mehreren Gateway-Zielen angegeben werden, z.B. „-g :igates.txt“. Die igates.txt enthält dann je Zeile die komplette Syntax von -g, also inkl. Port und Filterangaben.

Beispiel igates.txt:
aprsc.db0gw.ampr.org:14580#m/1,-t/t
germany.aprs2.net:14580#m/1,-t/t,
rotate.aprs2.net:14580#m/1,-t/t

In diesem Beispiel wird standardmäßig der APRS-Server bei DB0GW im Hamnet connected. Sollte diese Verbindung ausfallen, wechselt das Gateway automatisch zu germany.aprs2.net. Sollte auch dieses ausfallen oder nicht erreichbar sein, probiert es rotate.aprs2.net. In der Zwischenzeit wird weiterhin versucht das erste Gateway zu erreichen. Sobald dieses wieder ereichbar ist, wird automatisch wieder dort hin gewechselt.

Mehr Informationen hierzu findet man auch im dxlWiki unter http://dxlwiki.dl1nux.de/index.php?title=Igates.txt

Zusammenfassung Startskript:

python3 /home/pi/RPi-LoRa-KISS-TNC/Start_lora-tnc.py
udpgate4 -s MYCALL-10 -R 127.0.0.1:0:9001#LoRa -n 30:/home/pi/dxlAPRS/aprs/netbeacon.txt -g rotate.aprs2.net:14580#m/1,-t/t -p PASSCODE -t 14580 -w 14501 -v -D /home/pi/dxlAPRS/aprs/www/

Möchte man die empfangenen Daten gleichzeit auch live in APRSMAP auf der Karte ansehen, kann man noch udpbox zwischenhängen. udpbox verfielfältigt in diesem Beispiel den Datenstrom auf zwei Ports. Einen für das iGate, einen für APRSMAP.

python3 /home/pi/RPi-LoRa-KISS-TNC/Start_lora-tnc.py
udpbox -R 127.0.0.1:9001 -l 127.0.0.1:9101 -l 127.0.0.1:9105 -v
udpgate4 -s MYCALL-10 -R 127.0.0.1:0:9101#LoRa -n 30:/home/pi/dxlAPRS/aprs/netbeacon.txt -g rotate.aprs2.net:14580#m/1,-t/t -p PASSCODE -t 14580 -w 14501 -v -D /home/pi/dxlAPRS/aprs/www/

Ein Archiv mit Startskript und den weiteren benötigten Dateien kann man am Ende dieser Anleitung herunterladen!


Sie sieht es aus, wenn man das Startskript ~/lora-gw.sh manuell startet und Pakete empfangen werden:


LoRa RX[-85dBm/13dB, 72bytes]: b'<\xff\x01DL1NUX-12>APRS:!5014.07N\\01059.02EQ191/000/A=001094LoRa Tracker 60 mW'
b'DL1NUX-12>APRS:!5014.07N\\01059.02EQ191/000/A=001094LoRa Tracker 60 mW RSSI=-85dBm SNR=13dB'
b'DL1NUX-12>APRS:!5014.07N\\01059.02EQ191/000/A=001094LoRa Tracker 60 mW RSSI=-85dBm SNR=13dB'
array('B', [1, 48, 86, 45, 56, 53, 32, 83, 49, 51, 32, 0, 130, 160, 164, 166, 64, 64, 96, 136, 152, 98, 156, 170, 176, 121, 3, 240, 33, 53, 48, 49, 52, 46, 48, 55, 78, 92, 48, 49, 48, 53, 57, 46, 48, 50, 69, 81, 49, 57, 49, 47, 48, 48, 48, 47, 65, 61, 48, 48, 49, 48, 57, 52, 76, 111, 82, 97, 32, 84, 114, 97, 99, 107, 101, 114, 32, 54, 48, 32, 109, 87, 32, 82, 83, 83, 73, 61, 45, 56, 53, 100, 66, 109, 32, 83, 78, 82, 61, 49, 51, 100, 66, 250, 206])
('127.0.0.1', 9001)
LoRa RX[-74dBm/9dB, 72bytes]: b'<\xff\x01DL1NUX-12>APRS:!5014.07N\\01059.02EQ010/000/A=001094LoRa Tracker 60 mW'
b'DL1NUX-12>APRS:!5014.07N\\01059.02EQ010/000/A=001094LoRa Tracker 60 mW RSSI=-74dBm SNR=9dB'
b'DL1NUX-12>APRS:!5014.07N\\01059.02EQ010/000/A=001094LoRa Tracker 60 mW RSSI=-74dBm SNR=9dB'
array('B', [1, 48, 86, 45, 55, 52, 32, 83, 57, 32, 0, 130, 160, 164, 166, 64, 64, 96, 136, 152, 98, 156, 170, 176, 121, 3, 240, 33, 53, 48, 49, 52, 46, 48, 55, 78, 92, 48, 49, 48, 53, 57, 46, 48, 50, 69, 81, 48, 49, 48, 47, 48, 48, 48, 47, 65, 61, 48, 48, 49, 48, 57, 52, 76, 111, 82, 97, 32, 84, 114, 97, 99, 107, 101, 114, 32, 54, 48, 32, 109, 87, 32, 82, 83, 83, 73, 61, 45, 55, 52, 100, 66, 109, 32, 83, 78, 82, 61, 57, 100, 66, 108, 163])
('127.0.0.1', 9001)

Hier sieht man das LoRa APRS Gateway DL1NUX-9 auf der APRS-Karte:

Hier kann man den LoRa APRS Tracker DL1NUX-12 sehen, empfangen von DL1NUX-9:

Und hier sieht man das öffentliche Webinterface von udpgate4 mit der mh-Liste und weiteren Informationen. Ab udpgate4 Version 0.71 wird auch der Empfangspegel RSSI in der Spalte „Lev“ in -dBm und das SNR in Spalte „SNR“ in dB angezeigt.


Sendefähiges LoRa APRS iGate mit dxlAPRS

Da die LoRa APRS Gatewayplatinen grundsätzlich auch sendefähig sind, kann man damit auch ein sendefähiges iGate bauen. Vieles ist im Bereich LoRa APRS aber noch experimentell, und es werden noch nicht alle Funktionen unterstützt, die von normalem APRS gewohnt sind.

Zusätzlich muss man bedenken, dass man in manchen Ländern (auch in DL) bei unbemanntem Betrieb eine Genehmigung der staatlichen Regulierungsbehörde benötigt (Relaisrufzeichen, Frequenzzuteilung etc.). Bei ausschließlich bemanntem Betrieb ist dies nicht erforderlich.

Beim sendefähigen iGate ist kaum mehr Aufwand erforderlich. Es wird dazu keine weitere Software benötigt, wenn alle vorher beschriebenen Schritte bereits durchgeführt werden. Nur das Startskript muss angepasst werden.

Was kann oder soll überhaupt über LoRa APRS ausgesendet werden?

  • Regelmäßige APRS Bake als Identifikation
  • Digipeating (wiederholte Aussendung) empfangener APRS-Pakete
  • APRS Textnachrichten
  • APRS-IS Aussendungen

Die Bake macht natürlich Sinn bei unbemannten Stationen und ist sogar mancherorts eine Pflichtaussendung.

Digipeating macht nur bedingt Sinn. Bei iGates ohne Netzanbindung (Internet, Hamnet), kann es sinnvoll sein lokale Stationen durch Digipeating bis ans nächste iGate zu führen, welches ans Netz angebunden ist und die Daten in das APRS-IS Netzwerk überträgt. Damit kann man auch diese Positionspakete auf aprs.fi & Co sehen. Bei iGates mit Netzanbindung sollte man sich gut überlegen, ob man wirklich digipeaten will und vor Allem WAS man alles digipeaten will. Glücklicherweise hat man mit der udpbox aus der dxlAPRS Toolchain einen herausragenden Digipeater, welche unzählige Konfigurations- und Filtermöglichkeiten hat. Diese sind auch notwendig, da durch die geringe Datenübertragungsrate des LoRa Übertragungsverfahrens die Aussendungen deutlich länger sind als bei normalen 1200 Baud AFSK, und damit die Belegung der Frequenz in Gebieten mit hoher Aktivität ein Problem werden kann. Derzeit (Stand 19.03.2021) sind aber weder die OE1ACM Tracker noch OE5BPAs Software für die TTGO Beams in der Lage einen APRS „WIDE“ Pfad auszusenden um das Digipeating anzutriggern, weswegen ein Digipeating von gehörten LoRa APRS Stationen derzeit noch nicht möglich ist. Der Digi kann es aber grundsätzlich.

Wenn das eigene iGate über Hamnet oder Internet mit dem APRS-IS Netzwerk verbunden ist, kann man APRS-Nachrichten an User in Reichweite übermitteln lassen, egal woher diese letzendlich kommen (APRS, DMR, Handy-Apps usw.). Wenn die Tracker oder Empfangsgeräte dies unterstützen, können diese Informationen dort angezeigt werden. Die OE1ACM Tracker unterstützen dies derzeit noch nicht (Stand 19.03.2021).

Es ist natürlich technisch auch möglich Positionspakete aus dem APRS-IS Netzwerk über LoRa APRS zu übertragen, z.B. Daten die von Handy-Apps geschickt werden, oder Wetterstationen die Ihre Pakete direkt übers Internet übermitteln. Davon wird aber dringend abgeraten! Bei falscher Konfiguration wird das Gateway nicht mehr mit dem Senden aufhören, da es die vielen Daten unter Umständen nicht rechtzeitig losbekommt. Zudem macht es auch kaum Sinn, da im LoRa APRS meist nicht per „HF“ mitgehört wird wie bei normalem 1200 Baud APRS. Technisch geht es, aber ich beschreibe es nicht in meiner Anleitung. Wer darüber mehr wissen will, soll mich direkt kontaktieren.

Im Vergleich zum nur-RX iGate gibt es folgende Erweiterungen:

  • Aktivierter Digipeater
  • Aktivierte HF-Bake
  • Aussendung von APRS-Nachrichten aus dem APRS-IS Netzwerk

In der Datei config.py des RPi-LoRa-KISS-TNC müssen zwei Parameter passend eingestellt werden

AXUDP_LOCAL_IP = „127.0.0.1“
AXUDP_LOCAL_PORT = 9002

python3 /home/pi/RPi-LoRa-KISS-TNC/Start_lora-tnc.py
udpbox -R 127.0.0.1:9001 -l 127.0.0.1:9101 -d MYCALL-10 -p 0,1,2,5,6,8 -t 540,28 -f p28,29,33,35-39,41-43,46,47,58,59,61,64,91,95,96,123 -k 0/0/20000 -b 600:/home/pi/dxlAPRS/aprs/digibeacon.txt -x NOCALL -l 127.0.0.1:9002 -l 127.0.0.1:9105 -v
udpgate4 -s MYCALL-10 -R 127.0.0.1:9002:9101+10#LoRa -n 30:/home/pi/dxlAPRS/aprs/netbeacon.txt -g rotate.aprs2.net:14580#m/1,-t/t -p PASSCODE -t 14580 -w 14501 -v -D /home/pi/dxlAPRS/aprs/www/
  • Die erste Zeile startet das RPi-LoRa-KISS-TNC.
  • In der zweiten Zeile wird udpbox gestartet, welches den Digi aktiviert (-d), die HF-Bake (-b) erzeugt und die daurch erzeugten Pakete an das RPi-LoRa-KISS-TNC übermittelt zum Aussenden (Port 9002). Zudem leitet es die empfangenen Daten sowohl an das iGate (Port 9101) als auch an APRSMAP weiter (Port 9105), welches die Darstellung der Pakete auf der Karte ermöglicht. Es sind auch noch diverse Filterregeln gesetzt, mehr dazu im dxlWiki unter http://dxlwiki.dl1nux.de/index.php?title=Udpbox
  • In der dritten Zeile wird das eigentliche iGate gestartet. Die Netzbake wird mit -n definiert. Der entfernte APRS-Server, an welchen die Daten gesendet werden, wird mit -g bestimmt. Auch die APRS-Nachrichten, welche ausgesendet werden können, werden von dort bezogen, mit „+10“ beim Parameter -R „beschränkt“ und an Port 9002 (RPi-LoRa-KISS-TNC Eingang) gesendet. Der APRS-Passcode für das eigene Call muss noch bei -p ergänzt werden.

 


Support

Diese Anleitung wurde mit bestem Wissen und Gewissen erstellt. Aber auch hier kann sich natürlich der Fehlerteufel verstecken. Deshalb sind alle Angaben ohne Gewähr! Auch geht die Entwicklung der dxlAPRS Tools und der LoRa-KISS-TNC Entwickler immer weiter, was auch Veränderungen mit sich bringen kann. Wenn ihr einen Fehler findet oder Fragen habt, zögert nicht mich zu kontaktieren. Gerne auch als Kommentar auf der Webseite.

Kontaktmöglichkeiten:

  • per E-Mail attila [at] dl1nux . de
  • per IRC Chat im Hamnet (HamIRCNet) im Kanal #hamnet-oberfranken
  • per Packet-Radio im DL/EU Converse Kanal 501

Support:

  • dxl-Wiki: http://dxlwiki.dl1nux.de
  • Telegram-Gruppe: https://t.me/joinchat/CRNMIBpKRcfQEBTPKLS0zg

4 Gedanken zu „LoRa APRS iGate auf RaspberryPi mit dxlAPRS Tools

    • Da es sich um ein „Mischprodukt“ handelt, kann es das nicht geben. Der Download und die Installation der benötigten Dateien ist aber in wenigen Schritten erledigt und kann so in jedes laufende System übernommen werden. Es ist ja alles soweit beschrieben. Wenn dazu Fragen sind, helfe ich gerne! vy73 Attila

  1. Ich habe heute (19.03.2021) den Artikel bearbeitet da Matze DM4TZE den RPi-LoRa-KISS-TNC so angepasst hat, dass es auch direkt AXUDP Pakete erzeugen kann. Damit entfällt der Zwischenschritt mit UDPFLEX.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.