Ein Webinterface für das TTGO LoRa APRS iGate

Die meisten LoRa APRS iGates laufen derzeit mit einem TTGO Board. Diese sind recht preiswert zu bekommen. Die bekannteste Software dafür kommt von Peter Buchegger OE5BPA. Diese funktioniert auch recht gut, hat aber wie fast alle anderen Lösungen auch einen entscheidenden Nachteil: Man hat keine große Kontrolle oder Übersicht über die Empfangslage des iGates. Man weiß also nicht genau was es alles empfängt bzw. in der Vergangenheit empfangen hat, es sei denn, man verbindet sich über die Debug-Konsole und schaut live mit. Das kann man aber nicht 24/7 tun. Zu Packet Radio Zeiten gab es sogenannte MH-Listen, die angezeigt haben was der Digi, so in der Vergangenheit alles gehört hat. Dies fehlt bei fast allen APRS Programmen komplett, manche haben zumindest etwas rudimentäres an Bord.

Auch die Statistiken bei APRS.fi und aprsdirect.com sind nicht voll aussagekräftig, da diese Webseiten ein empfangenes Paket nur einem iGate zuordnen können, und zwar dem, der es als erstes dort angeliefert hat. Empfangen beispielsweise drei iGates ein und dasselbe Paket, werden es zwar alle drei ins APRS Netzwerk einspeisen. Aber nur bei einem taucht es im Internet in der Statistik auf. So kann es einem so vorkommen, dass das iGate nur wenig empfängt. Tatsächlich hört es aber sehr viel mehr, ist aber nur auf einem „längeren Weg“ angebunden und somit sind die anderen iGates nur schneller gewesen beim Abliefern der Daten. Einen echten Überblick kann man sich so nicht verschaffen.

Die iGate-Software „udpgate4“ von Chris OE5DXL bietet als einziges APRS Tool eine informative und leistungsstarke Weboberfläche, welche sich zudem auch noch per CSS an die eigenen Bedürfnisse anpassen lässt. Man sieht hier nicht nur die empfangenen Stationen, sondern auch die ausgesendeten Informationen (z.B. Geschwindigkeit, Richtung, Temperatur), die Anzahl der empfangenen Pakete und vieles mehr in einer Tabelle. Vieles lässt sich über Parameter nach den eigenen Bedürfnissen anpassen.

Die Idee war nun, die bereits laufenden TTGO Boards mit einfachen Mitteln mit udpgate4 zusammen zu bringen um diese mit einem Webinterface zu erweitern.

Die Lösung ist das kleine Python-Tool „is2axudp“ von Matze DM4TZE. Zusammen mit dem Tool „wx.py“ von Chris OE5DXL simuliert es einen APRS-Server, nimmt die Daten vom TTGO iGate an, wandelt diese in das AXUDP Format um und sendet diese an das iGate udpgate4. Dieses bereitet die Weboberfläche auf und sendet die Daten an einen beliebigen APRS-Server.

Technisch gesehen werden is2axudp und udpgate4 nur „dazwischengeschoben“. Man erhält dadurch aber ein sehr informatives Webinterface für die eigene Empfangsstation, welches man zusätzlich noch über Hamnet oder Internet verfügbar machen könnte. Und wenn man eventuell eh schon einen RaspberryPi zu Hause laufen hat, kann man dies einfach zusätzlich mit laufen lassen, denn es benötigt kaum Ressourcen. Natürlich geht dies auch mit einem bereits laufenden PC oder sogar einer virtuellen Maschine. Es ist keine Hardware-Verbindung zwischen TTGO und dem Rechner notwendig.

Voraussetzungen:

  • bereits bestehendes TTGO iGate (es muss nur die Konfiguration angepasst werden)
  • 24/7 laufender RaspberryPi oder PC, gerne auch als virtuelle Maschine, mit Linux Betriebssystem
  • Der Rechner benöigt eine statische IP Adresse im Heimnetzwerk und es muss Python3 installiert sein
  • TTGO muss sich per Netzwerk (WLAN, LAN) mit dem Rechner verbinden können (sollten sich im gleichen Netwzerk befinden bzw. per Routing erreichbar sein)

Am Beispiel eines RapsberryPi erkläre ich nun die Vorgehensweise:

1. Grundinstallation dxlAPRS Tools

Eine ausführliche Dokumentation findet ihr im dxlWiki: http://dxlwiki.dl1nux.de/index.php?title=Installationsanleitung

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 Tools befinden sich nun im Ordner /home/pi/dxlAPRS/aprs.

Das Installationspaket enthält meist eine bereits veraltete Version des iGates. Mit folgendem Befehl kann man sich die aktuelle Version direkt vom Server von OE5DXL laden:

cd ~/dxlAPRS/aprs
wget -N http://oe5dxl.hamspirit.at:8025/aprs/bin/armv7hf/udpgate4

2. Einrichten von is2axudp

2.1. Laden von is2axudp

Detaillierte Infos findet ihr ebefalls im dxlWiki: http://dxlwiki.dl1nux.de/index.php?title=Is2axudp.py

cd ~
git clone https://github.com/dl1nux/is2axudp.git

Die zwei Python-Skripte befinden sich nun im Ordner /home/pi/is2axudp/

2.2. Anpassen der Datei is2axudp.py

Die Datei is2axudp.py muss noch wie folgt angepasst werden:

a) In der Zeile …
serversocket.bind((„0.0.0.0“, 1234))

… muss der Port angepasst werden, auf dem das Skript die Daten empfangen soll, z.B. 8888
serversocket.bind((„0.0.0.0“, 8888))

b) In der Zeile …
sendax(data,(„127.0.0.1“,9999),{})

… muss die Ziel-IP und der Port angegeben werden, wo die in AXUDP gewandelten Daten zu udpgate4 geschickt werden sollen. Da sich udpgate4 auf dem gleichen Rechner befindet, muss hier nur der richtige Port eingetragen sein, sagen wir 8899.
sendax(data,(„127.0.0.1“,8899),{})

c) In der Zeile …
data = data.replace(b‘,TCPIP*‘,b‘,WIDE1-1′)

… müssen Anpassungen vorgenommen werden. Hier können und müssen Textstrings der übertragenen APRS-Pakete ausgetauscht werden. Das TTGO iGate sendet die Daten bereits in einem Format für die APRS-Server mit dem APRS-Pfad „,qAR,MYCALL-XY„.

Beispiel:

DL1NUX-12>APLT00-1,qAR,MYCALL-XY:!5014.06N/01059.01E>/A=000975TTGO Attila Mobil !w1I!

Da udpgate4 damit nichts anfangen kann müssen wir den eingefügten Pfad (,qAR,MYCALL-XY) aus dem String wieder entfernen. In der Zeile kann ein Text „XXX“ durch einen anderen Text „YYY“ ersetzt werden. Da wir den Pfad nur löschen müssen, ändern wir die Zeile wie folgt:
data = data.replace(b‘,qAR,MYCALL-XY‘,b“)

Der String ,TCPIP* wird ersetzt durch ,qAR,MYCALL-XY , wobei MYCALL-XY das iGate Call ist, welches in der Konfiguration des TTGO iGates eingetragen ist. Der String ,WIDE1-1 wird komplett entfernt, es bleiben nur noch die zwei Apostrophe übrig, und zwar OHNE Leerstelle dazwischen. Bitte besonders auf die Kommas achten, diese sind wichtig. Es dürfen auch keine zusätzlichen Leerzeichen eingefügt werden, da sonst das APRS-Paket ungültig wird!

3. Anpassen der Konfiguration des TTGO iGates

Die folgenden Zeilen sind relevant:

"callsign": "MYCALL-XY",
"wifi": {
"SSID": "WLAN-Name",
"password": "WLAN-Passwort"
"aprs_is": {
"active": true,
"passcode": "12345",
"server": "192.168.178.65",
"port": 8888

Unter „callsign“ muss das Rufzeichen stehen, das auch später in der is2axudp.py wieder entfernt werden muss. Es wird nirgendwo weiter auftauchen, es spielt also keine große Rolle welches Call da drin steht. Es darf nur nicht „NOCALL-10“ drin stehen bleiben, denn das wird von der iGate Software auf dem TTGO erkannt und dann startet sie nicht da noch kein anderes Call eingetragen wurde.

Unter „wifi“ müssen die WLAN Zugangsdaten stehen, mit dem sich das TTGO verbindet. Von diesem Netzwerk aus muss der Rechner, auf dem is2axudp läuft, erreichbar sein.

Unter „aprs_is“ wird die Verbindung zu is2axudp definiert. Der Passcode ist egal, er wird nicht überprüft. Als Serveradresse muss die IP-Adresse oder der DNS Name des Rechners stehen, auf dem is2axudp läuft. Wenn eine IP-Adresse eingetragen wird, darf diese sich nicht ändern. Er muss also eine statische IP haben bzw. der Router muss immer die gleiche IP per DHCP vergeben. Es muss auch der Port eingetragen werden, auf dem is2axudp.py „hört“. Im Beispiel oben haben wir Port 8888 genommen.

4. Anpassungen für udpgate4

Bevor man nun die Anwendungen startet, muss für udpgate4 eine Datei mit der Netzwerkbake erstellt werden, die in das APRS-IS Netzwerk gesendet wird.

cd ~/dxlAPRS/aprs/
nano netbeacon.txt

Dort kopiert man folgenden Inhalt rein und passt ihn an:

!5014.00NL01100.00E&TTGO iGate Musterstadt JO12ZZ
#
# Geokoordinaten in Degree Dezimalminute without Degree Symbol°
# Here is 48°12.83 N = 4812.83N and 016°15.85 E = 01615.85E

Relevant ist hier nur die obere Zeile. Hier müssen die Koordinaten im Format DDMM.MM, also in Grad und Dezimalminuten, eingegeben werden. Das APRS-Symbol mit dem L in der schwarzen Raute wird durch die Zeichen L sowie & hinter dem N und E definiert und kann bei Bedarf geändert werden. Nach dem „&“ startet der Kommentartext der Bake. Hier könnt ihr belibigen Bakentext hinterlassen, der dann auch auf APRS.fi & Co erscheint.

5. Starten der Anwendung per Startskript

Um is2axudp und udpgate4 zu starten erstellen wir uns ein einfaches Startskript im aprs Ordner:

cd ~/dxlAPRS/aprs/
nano start.sh

Nun fügen wir erstmal folgenden Text mit Copy & Paste ein bevor wir ihn editieren:

killall -9 udpgate4 is2axudp.py
/home/pi/is2axudp/is2axudp.py &
/home/pi/dxlAPRS/aprs/udpgate4 -s MYCALL-XY -R 127.0.0.1:0:8899 -H 10080 -I 1440 -u 50 -B 1440 -n 30:/home/pi/dxlAPRS/aprs/netbeacon.txt -g rotate.aprs2.net:14580#m/1 -p 12345 -w 14501 -v -D /home/pi/dxlAPRS/aprs/www/ &

Hinweis: Die erste Zeile (killall) dient nur dazu eventuell bereits laufende Prozesse zu beenden.

Ihr müsst natürlich noch eure Daten passend eintragen:

  • MYCALL-XY ersetzen mit eurem Call+SSID wie es auch bei APRS.fi erscheinen soll
  • Unter -R 127.0.0.1:0:8899 muss der richtige Port stehen, den ihr als ausgehenden Port in der is2axudp.py eingestellt habt. Hier empfängt udpgate4 die Daten. Im Beispiel war dies der Port 8899.
  • Bei -p müsst ihr euren persönlichen APRS Passcode angeben um euch bei den APRS-Servern zu authentifizieren.
  • Bei -g könnt ihr optional einen anderen APRS-Server eintragen, zu dem ihr die Daten weitersenden wollt.
  • Alle anderen Optionen könnt ihr im dxlWiki nachlesen, dort könnt ihr dann auch sehen was ihr noch alles anpassen könnt: http://dxlwiki.dl1nux.de/index.php?title=Udpgate4

Speichern der Datei mit STRG+O und verlassen mit STRG-X.

Dann müssen noch die richtigen Dateirechte vergeben um sie ausführbar zu machen:

chmod 755 start.sh

Das Skript startet man nun an der Konsole mit:

cd ~/dxlAPRS/aprs/
./start.sh

6. Ergebnis

Wenn beide Tools laufen, könnt ihr im Browser das Webinterface auf Port 14501 aufrufen unter IP-ADRESSSE:14501/mh, z.B. 192.168.178.65:14501/mh. Das sieht dann z.B. so aus:

Ihr könnt viele Dinge hier tun:

  • Spalten sortieren mit Klick auf die Spaltenüberschrift
  • Die zuletzt empfangenen Pakete einer Station anzeigen lassen durch Klick auf die Zahl in der Spalte „Pack“. Die Anzahl ist einstellbar durch den Parameter -u.
  • Durch Klick auf das Rufzeichen könnt ihr auf eine externe Webseite geleitet werden, z.B. findu.com oder aprs.fi um euch z.B. dort die Rohdaten anzeigen zu lassen. Wohin euch der Link führt, steuert ihr mit der Datei calllink.txt im Ordner dxlAPRS/aprs/www
  • Durch ändern der Aufrufparameter könnt ihr steuern welchen Zeitraum ihr sehen wollt (-H bzw. -I)

Fragen dazu wie immer gerne als Kommentar oder in unserer dxlAPRS Telegram Community. Den Link zur Telegram-Gruppe findet ihr auf der Startseite des dxlWiki.

Stand: 21.11.2021

2 Gedanken zu „Ein Webinterface für das TTGO LoRa APRS iGate

  1. Hallo, habe folgende Fehlermeldung vom udpgate4 „vermute ich“ nach dem start des start.sh scriptes kommt folgendes:

    pi@dxlAPRS:~/dxlAPRS/aprs $ T:connect to: rotate.aprs2.net 14580
    G:flt:# aprsc 2.1.13-g79b6c3e
    G:flt:# logresp DG8JT-10 verified, server T2FINLAND
    connection
    user DG8JT-10 pass XXXXX vers ESP32-APRS-IS 0.2

    DG8JT-7>AP,qAO,DG8JT-10:!/4v+IPCJnje0G

    via path error
    AP,qAO,DG8JT-10:!/4v+IPCJnje0G

    ->

    src call not found
    DG8JT-7>AP,qAO,DF8JO-11:!/4v+IPCJnje0G

    DG8JT-7 ist der Lora Sender -10 der RX
    kann es sein, weil der DG8JT-7 komprimierte Daten sendet und is2axudp nicht übersetzten kann?

    Danke für ein Hilfe.

    73 Joachim DG8JT

    • Hallo Jocahim. Überprüfe nochmals deine Änderungen. Der is2axudp übersetzt nichts. Der ersetzt nur ein paar Zeichen im String damit diese korrekt bei udpgate4 ankommen und verarbeitet werden. Ich hatte das früher auch mal, kann mich aber nicht mehr an die Ursache erinnern. Es funktionierte jedenfalls dann. Evtl. Prozess neu starten? Laut aprs.fi werden die Daten aber übermittelt. Ich persönlich würde das TO-Call noch ändern, nur „AP“ ist etws kurz. Das APRS Protokoll erwartet da 6 Stellen. Evtl. kommt es damit zu Problemen. vy73

Schreibe einen Kommentar zu Joachim Antworten abbrechen

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.