LoRa APRS mit einem alternativen iGate aus den dxlAPRS Tools

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 APRSwar sehr reizvoll. Was davon geht besser?

Leider ist das LoRa Verfahren immernoch geschützt, weswegen es keine quelloffnene Software zum Dekodieren gibt. Ein Empfang über SDR-Sticks ist damit (legal) 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. Manche davon sind auch teilweise oder vollständig vorbestückt erhältlich. Für Funkamateure wie mich, für die SMD Bauteile ein graus sind, ist das schon ein Vorteil.

Ich habe mir einen „Tracker D“ und ein „Gateway V“ besorgt und aufgebaut. Es funktionierte alles soweit auf Anhieb. Die Trackersoftware war noch etwas verbesserungswürdig (keine konformen Bewegungsdaten in den APRS-Paketen), aber da versprach der Entwickler Bernd OE1ACM mit einem Softwareupdate baldige Besserung. 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 daher, das 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 Gateway

Als ich dann das Projekt RPi-LoRa-KISS-TNC von Tom OE9TKH entdeckte, wurde ich hellhörig. Lustigerweise war auch mein Funkfreund Matze DM4TZE unterstützend an diesem Projekt beteiligt. Diese Software erzeugt eine TCP-KISS-Schnittstelle an einem LoRa APRS Gateway. Über diese 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 interesanter 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

Anleitung Installation LoRa APRS Gateway 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.

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“ oder ein „LoRa APRS Gateway V“ von OE1ACM vorhanden und funktionsfähig. Getestet habe ich die Funktion auf einem RaspberryPi 4 mit 4 GB RAM und einem RaspberryPi Zero WH. Theoretisch sollte es auch auf anderen Einplatinenrechnern wie dem BananaPi, OrangePi etc. laufen. Da müsste nur die GPIO Belegung geprüft und ggf. angepasst 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

Für das Vorhaben werden nur zwei der Tools aus der dxlAPRS Toolchain benötigt. Eine Installation der Tools ist hier ausführlich beschrieben:
http://www.dl1nux.de/dxlaprs-tools-grundinstallation/

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

3. RPi-LoRa-KISS-TNC installieren

Dies ist angelehnt an die Installationsanleitung von Tom OE9TKH, mit der Anpassung, das APRX eben nicht benötigt wird.

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 https://github.com/tomelec/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

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. Das Skript baut nun eine Schnittstelle zwischen eurer LoRa APRS Gatewayplatine und der TCP-KISS Schnittstelle auf Port 10001. An diese Schnittstelle können nur andere APRS Programme wie udpgate4 angedockt werden.

4. udpgate4 an TCP-KISS Schnittstelle andocken

Wie der Name udpgate4 schon sagt, basiert dieses APRS Gateway auf dem AXUDP Format. APRS Daten werden über UDP Ports an- und abgeliefert. Da wir aber erstmal nur eine TCP-KISS Schnittstelle für die Datenübertragung haben, müssen wir hier noch eine Brücke bauen, dies geschieht mit udpflex.

udpflex -U 127.0.0.1:9101:0 -T 127.0.0.1:10001 -V

Die Parameter bedeutet Folgendes (alle Parameter mit ./udpflex -h anzeigen):
-U <x.x.x.x:destport:listenport> = axudp „ip:destport/listenport“
-T 0.0.0.0:<tcpport> = listen on <tcp port> for TCP-KISS connect
-V = verbous errors and monitor data to stdout

udpflex dockt mit -T am TCP-KISS Port vom LoRa-KISS-TNC an und leitet die Daten per AXUDP weiter udpgate4 Port 9101. Dabei werden mit -V diverse Ausgaben am Bildschirm angezeigt, z.B. auch die übermittelten APRS Pakete. Läuft das Gateway nur standalone und keiner schaut sich die Ausgabe an, dann kann man -V auch weglassen. Das :0 hinter dem destination Port bezieht sich auf den listen port. Wenn es ein Zwei-Wege Gateway mit TX-Funktion ist, kommt anstatt der 0 der UDP-Port hin, von dem die zu sendenden Daten kommen. In dieser Anleitung beziehe ich mich aber auf ein reines LoRa APRS RX Gateway, ohne Sendefunktion.

Nun werden bereits die Daten zwischen den TCP-KISS und AXUDP Schnittstellen ausgetauscht. Von hier an kommt udpgate4 ins Spiel. Bitte die entsprechenden Programm- und Dateipfade beachten und ggf. anpassen.

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/0,-t/t -p 12345 -t 14580 -w 14501 -v -D /home/pi/dxlAPRS/aprs/www/

UDPGATE4 ist das iGate welches die APRS Pakete an einen beliebigen APRS-Server weiterleitet

Die Parameter:
-s <call> = server call of this server -s MYCALL-2 (-S no callcheck)
-R <ip>:<dport>/<lport>[+<byte/s>[:<radius>]][#<portname>] (axudp format)
-n <min>:<file> = netbeacon minutes:filename
-g :<filename> = read gateway urls from file url:port#filter,filter,…
-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 9101 (-r) auf dem gleichen Rechner (127.0.0.1) von udpflex.
  • Zwischen 127.0.0.1 und dem Port 9101 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 zu udpflex sendet. „#LoRa“ gibt den Namen des Ports an, welcher dann in der mh-Liste auf der Weboberfläche erscheint (wenn mehrere Ports konfiguriert sind). 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/0,-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 daher auch von anderen Stationen 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 einzelnen gesendeten APRS Frames im Terminalfenster ausgegeben (kann bei standalone Nutzung entfallen).

Die Datei netbeacon.txt muss man erstellen …

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

… und folgenden Inhalt hineinkopieren:

!5010.00N/01100.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

Nicht vergessen die eigenen Koordinaten einzupflegen und ggf. ein anderes APRS-Symbol zu bestimmen

Tipp: Ausfallsicherheit des Gateways:

Es kann auch ein File 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/0,-t/t
germany.aprs2.net:14580#m/0,-t/t,
rotate.aprs2.net:14580#m/0,-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.aprs.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.


In der Praxis sollte man alle Befehle schön hintereinander in eine Skriptdatei stecken und beim Hochfahren des Rechners starten lassen, z.B. über die /etc/crontab

sudo nano /etc/crontab

Dort fügt man folgende Zeile hinzu:

@reboot pi /home/pi/lora-gw.sh

Die Datei /home/pi/lora-gw.sh muss noch erstellt werden:

nano ~/lora-gw.sh

und folgender Inhalt eingefügt werden (bitte noch Rufzeichen und ggf. Ziel-Gateway anpassen!):

python3 /home/pi/RPi-LoRa-KISS-TNC/Start_lora-tnc.py &/home/pi/dxlAPRS/aprs/udpflex -U 127.0.0.1:9101:0 -T 127.0.0.1:10001 -V &
/home/pi/dxlAPRS/aprs/udpgate4 -s MYCALL-10 -R 127.0.0.1:0:9101#LoRa -n 30:/home/pi/netbeacon.txt -g rotate.aprs2.net:14580#m/0,-t/t -p 12345 -t 14580 -w 14501 -v -D /home/pi/dxlAPRS/aprs/www/ &

Die Datei /home/pi/lora-gw.sh muss anschließend noch ausführbar gemacht werden mit:

chmod 755 ~/lora-gw.sh

Beim Neustart des PIs sollte nun das Gateway sofort starten.


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

pi@lora-gw:~ $ ./lora-gw.sh
pi@lora-gw:~ $ send init to tnc
connect 127.0.0.1:10001
tcpkiss disconnect
T:connect to: rotate.aprs2.net 14580
G: :# aprsc 2.1.5-g8af3cdc<0D>
G: :# Parse errors on filter spec:
'm/0'<0D>
G: :# logresp DL1NUX-9 verified, server
T2HAKATA<0D>
connect 127.0.0.1:10001
KISS-Server: Connection from 127.0.0.1
G: :# aprsc 2.1.5-g8af3cdc 26 Apr 2020 13:25:00 GMT T2HAKATA 192.168.100.30:14580<0D>
LoRa RX[-60dBm/10dB, 60bytes]:
b'<\xff\x01DL1NUX-12>APRS:!5014.07N\\01059.01EQ/A=323mLoRa de DL1NUX'
To Server:
bytearray(b'\xc0\x00\x82\xa0\xa4\xa6@@`\x88\x98b\x9c\xaa\xb0y\x03\xf0!5014.07N\\01059.01EQ /A=323mLoRa de DL1NUX RSSI=-60dBm SNR=10dB\xc0')
KISS0:fm DL1NUX-12 to APRS ctl UIv1 pid F0
!5014.07N\01059.01EQ /A=323mLoRa de DL1NUX RSSI=-60dBm SNR=10dB
U:127.0.0.1:48538: 0>DL1NUX-12>APRS,qAU,DL1NUX-9:!5014.07N\01059.01EQ/A=323mLoRa de DL1NUX RSSI=-60dBm SNR=10dB
LoRa RX[-60dBm/10dB, 60bytes]:
b'<\xff\x01DL1NUX-12>APRS:!5014.07N\\01059.01EQ/A=323mLoRa de DL1NUX'
To Server:
bytearray(b'\xc0\x00\x82\xa0\xa4\xa6@@`\x88\x98b\x9c\xaa\xb0y\x03\xf0!5014.07N\\01059.01EQ /A=323mLoRa de DL1NUX RSSI=-60dBm SNR=10dB\xc0')
KISS0:fm DL1NUX-12 to APRS ctl UIv1 pid F0
!5014.07N\01059.01EQ /A=323mLoRa de DL1NUX RSSI=-60dBm SNR=10dB
U:dup:DL1NUX-12>APRS:!5014.07N\01059.01EQ /A=323mLoRa de DL1NUX RSSI=-60dBm SNR=10dB
LoRa RX[-60dBm/11dB, 60bytes]:
b'<\xff\x01DL1NUX-12>APRS:!5014.07N\\01059.01EQ /A=323mLoRa de DL1NUX'
To Server:
bytearray(b'\xc0\x00\x82\xa0\xa4\xa6@@`\x88\x98b\x9c\xaa\xb0y\x03\xf0!5014.07N\\01059.01EQ /A=323mLoRa de DL1NUX RSSI=-60dBm SNR=11dB\xc0')
KISS0:fm DL1NUX-12 to APRS ctl UIv1 pid F0
!5014.07N\01059.01EQ /A=323mLoRa de DL1NUX RSSI=-60dBm SNR=11dB
U: 0>DL1NUX-12>APRS,qAU,DL1NUX-9:!5014.07N\01059.01EQ /A=323mLoRa de DL1NUX RSSI=-60dBm SNR=11dB

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:


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

Letztes Update: 26.04.2020

2 Gedanken zu „LoRa APRS mit einem alternativen iGate aus den 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

Schreibe einen Kommentar

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