HB9EYZ - APRS (Smartbeaconing, ISS, APIR, Tools etc.)

V1.0

 


APRS - Eigenentwicklungen und Erfahrungsberichte über Software für Windows, Linux & Android Smartphones


APRS Smartbeaconing Simulation

APRS Packets werden normalerweise time-based ausgegeben (Status, WX, Telemetry etc). Für Position-Packets ist dieser Ansatz ungeeignet: entweder werden zu viele oder zu wenige Packets gesendet. Der Algorithmus Smartbeaconing™ löst dieses Problem: Packets werden abhängig von der Geschwindigkeit und dem Richtungswechsel generiert. Die Original-Beschreibung und der Pseudo-Code sind bei hamhud.net zu finden.

Smartbeaconing™ ermittelt den Zeitpunkt für das Position-Packet anhand von 7 fix eingestellten Parametern sowie der vom GPS gemessenen Geschwindigkeit (Speed) und Richtung (Heading). Es gibt keine one-fits-all Einstellung. Dieser Blogger empfiehlt verschiedene Einstellungen für 'car drive', bicycling', 'walking' und 'sailing'. Alle Angaben in 'knots' (Seemeilen, 1,852km).

Slow Speed (km/h)
Wenn 'GPS Speed' kleiner als 'Slow Speed' werden Position-Packets alle 'Slow Rate' Sekunden gesendet.
Richtungswechsel werden nicht berücksichtigt.
Slow Rate (seconds)
Abstand Position-Packets
Fast Speed (km/h)
Wenn 'GPS Speed' grösser als 'Fast Speed' werden Position-Packets alle 'Fast Rate' Sekunden gesendet.
List 'GPS Speed' zwischen 'Slow Speed' und 'Fast Speed' wird der Abstand der Position-Packets berechnet (höher bei kleinerer 'GPS Speed'.
Richtungswechsel werden berücksichtigt.
Fast Rate (seconds)
Abstand Position-Packets
Minimum Turn Angle (degrees)
Minimalwert für Richtungsänderung
Turn Slope (factor)
Läuft unter bem Begriff "CornerPegging". Dieser 'factor' wird durch 'GPS Speed' geteilt und zum 'Minimum Turn Angel' dazugezählt. Bei höheren 'GPS Speed' wird bei kleineren Richtungswechseln ein Position-Packet ausgelöst. Der Wert von 'factor' muss ausprobiert werden.
Minimum Turn Time Mindestabstand Position-Packets in Kurven

Um all die Parameter-Werte mit dem Browser testen zu können, habe ich 'APRS Smartbeaconing Simulation' entwickelt. Die notwendigen Test-Daten wurden auf einer Autofahrt Lausen - Liestal - Schönmatt - Liestal - Augst - Sissach - Lausen gesammelt. Jede Sekunde wurde die aktuelle Position aufgezeichnet.

ISS - Passes & Packets

APRS-Aktivitäten können mit aprs.fi monitored werden. Die Packets des Digipeaters RS0ISS können leider nicht vernünftig ausgewertet werden. findu.com bietet eine rudimentäre f Aufbereitung der Daten an, scheint aber etwas in die Jahre gekommen zu sein.
Die ISS ist von meinem Home-Locator JN37VL ungefähr bei 5 täglichen Durchflügen zu erreichen (Radio Passes).

Projektziel: Interaktive Browserkarte mit Anzeige der vergangenen und zukünftigen Überflüge, Locations der Call-Signs und Packets.



Die Overview-Karte sowie die detaillierten Packet-Daten sind hier zu finden.

Als APRS-Client für die ISS verwendet ich UISS mit DireWolf als TNC. Die notwendige Konfiguration ist hier beschrieben.
UISS hat endlos viele Funktionen. Im Normalfall wird nur "TX APRS Position" und "TX APRS Message" mit den dazugehörenden Push-Buttons benötigt. Eine 'M-Heard' Station kann mit einem Doppelclick in das Feld 'TX APRS Message For' kopiert werden.

Setup
Bei dieser Mashup-Applikation spielen diverse Softwarekomponenten zusammen. Als Programmiersprachen werden Python, PHP und Javascript, als Datenbanksysteme SQLite und MySQL eingesetzt.
- Cron-Job auf Raspberry holt die Pass-Daten (Zentrum: JN37VL) 1 mal täglich ab n2yo.com
  und speichert diese lokal in einer SQLite DB und auf dem Webspace in einer MySQL DB ab.
- Endlos-Job auf Raspberry holt die APRS Daten während eines Passes ab aprs-is.net
  und speichert diese in einer MySQL DB auf dem Webspace
- Webpage holt die Pass- und APRS-Daten zur Laufzeit ab der MySQL DB und bereitet die Map dynamisch auf

APIR

APIR steht für "APRS Pi Remote Control". Übliche APRS-Clients wie APRSIS32, UI-View, Xastir etc dienen dazu, APRS-Packets auf Karten darzustellen. APIR ist als Remote Control konzipiert und kann zum Ansteuern von Raspberry GPIO-Pins verwendet werden. Zusätzliche Funktionen sind TX von Wetter-Daten und Telemetrie. Die aktuelle Version 0.2 verwendet 'Soundmodem' als Sofware-TNC. 'Soundmodem' ist relativ unempfindlich und wird nicht mehr weiter entwickelt. Die folgende Version von APIR wird 'DireWolf' als Software-TNC verwenden. 'DireWolf' kann auch als Digipeater sowie als I-Gate konfiguriert werden.

Prototyp "HB9BL-1", verwendet im Clublokal vom HB9FS


Hardware
Raspberry Pi Model B
USB-Soundcard
Der Raspberry hat nur einen Audio-Ausgang. Für Audio IN/OUT wird eine USB-Soundcard benötigt.
Powering DC-DC Wandler 12V --> 5V USB
A/D Wandler MCP3008
Die GPIO Pins des Raspberry können nur digitale Werte verarbeiten. Mit dem MCP3008 können auf max. 8 Kanälen Input analoge Werte von 0V - 3.3V eingespiesen werden. Die Python-Library "MCP3008" wandelt die Input-Spannungen auf Werte von 0 - 1024 um. Der MCP3008 wird für die Überwachung der Akku-Spannung benötigt.
Clock DS3132
Der Raspberry hängt nicht am Internet und muss die Zeit ab einer externen Uhr lesen.
PTT Circuit Transformer 1:1, Opto-Koppler
PTT Watchdog Digispark ATtiny85
Der PTT Watchdog läuft unabhängig vom Raspberry auf dem Digispark.

Software
Software TNC V0: Soundmodem (RX: axlisten, TX: beacon)
Nachteile: langsam, schwacher Decoder, 'beacon' ohne PTT-Steuerung und daher nur mit VOX sinnvoll verwendbar
V2: DireWolf (RX/TX: KISSutil)
Am elegantesten wäre die Python KISS Library von ampledata. Trotz vieler Versuche und der Verwendung diverser Versionen dieser Library konnte der socket-write nicht zum Laufen gebracht werden.
KISSutil ist ein Teil des DireWolf Packages und bietet eine simple File-Schnittstelle: DireWolf schreibt die RX-Packets ins RX-Directory. APIR schreibt die zu sendenden Packets ins TX-Directory.
PTT-Steuerung, LBT (Listen before Talking) usw. werden von Direwolf abgedeckt.
APIR Python
PTT Watchdog Arduino C++

Functionality APIR
Die Commands werden als APRS Message an HB9BL-1 gesendet. Wird '?' als Suffix angegeben, enthält die Antwort-Message die Beschreibung des Commands-
tbc
Command Beschreibung
?APRS Request of all queries that can be answered by this station.
?APRSO Object query. List of all objects created by this station.
?APRSP Send position
?APRSD Stations heard direct (without digipeater hops) last 1 hour
?APRSL Stations heard via hop last 1 hour.
?APRSS Send status
?APRST | ?PING Path by which the packet was heard.
?APRSV | ?VER | ?ABOUT Software version, operating system, CPU load

Functionality PTT Watchdog
Das Aussenden einer APRS-Message dauert ein paar Sekunden. Das PTT-Signal wird vom Raspberry via den PTT Watchdog an den TRX geleitet. Die maximale PTT-Time wird durch den PTT Watchdog kontrolliert. Nach 10 Sekunden wird PTT auf OFF gesetzt und so ein Dauerträger auf 144.800 MHz vermieden. Der Wert ist hardcoded, könnte auch über einen externen Poti konfigurierbar gemacht werden.

DireWolf Sofware Soundcard

"Dire Wolf is a software "soundcard" AX.25 packet modem/TNC and APRS encoder/decoder. It can be used stand-alone to observe APRS traffic, as a tracker, digipeater, APRStt gateway, or Internet Gateway (IGate)."

DireWolf decodiert besser als Chip-basierte und ältere Sofware-basierte TNCs:


Technisch Interessierte finden hier eine Beschreibung des DireWolf-Approaches mit 9 Demodulatoren.

DireWolf läuft auf Windows & Linux. Nach diversen Tests ist dies mein bevorzugter "Virtual TNC und läuft auf Notebook, Netbook & Raspberry.

APRS Messaging via IGate

APRS Packets werden als Broadcast TXed, haben also keinen bestimmten Empfänger. Ausnahme sind die Packets vom Typ "Message" (Data Type Indicator ":"). Diese Packets enthalten immer einen Empfänger-Call.
IGates dienen dazu, empfangene Packets via Internet an APRS-IS weiterzuleiten. "aprs.fi" bezieht die APRS-Daten ab APRS-IS. Bidirektionale IGates können via APRS-IS "empfangene" Packets wieder an RF gaten. Diese Funktionalität ist für Packtes vom Type "Message" gedacht. So können Messages weltweit versendet werden. Die Verwendung von APRS-IS als Transportmedium ist für die APRS-Clients transparent. Prämisse: dieses Packets werden nur von IGates ausgesendet, welche den Empfänger-Call innerhalb einer konfigurierten Zeitspanne (meistens 30 Minuten) via RF "gehört" haben. Solche Packets werden immer als Third Party Packets ausgesendet. Third Party Packet bedeutet, dass das ursprüngliche Packet mit einem Header ergänzt wird und mit dem Absender IGates TXed wird. Damit wird verhindert, dass der Original-Absender von lokalen IGates als "gehört" gespeichert wird und laufend Packets erhält, die er so nie empfangen kann.


Packet-Aufbau RF - beide Stationen in RF-Reichweite (direkt oder Digi)

HB9EYZ-3 TXed die Query-Message "?cpu" an HB9BL-14.

HB9EYZ-3>APWW11,WIDE1-1::HB9BL-14 :?cpu


HB9BL-14 TXed die Response an HB9EYZ-3.

HB9BL-14>APWW11,WIDE1-1::HB9EYZ-3 :*CPU: Host/Kernel/OS: rpi60 5.10.63-v7+ GNU/Linux...



Packet-Flow via APRS-IS: HAM 1 und HAM 2 können via "RF" Messages austauschen



Packet-Aufbau APRS-IS - Stationen sind nicht in RF-Reichweite

HB9EYZ-3 TXed aus dem Ferien-QTH im Tessin die Query-Message "?cpu" an HB9BL-14 (QTH im Baselland).

HB9EYZ-3>APWW11,WIDE1-1::HB9BL-14 :?cpu


IZ1UQG-N1 (IGate) empfängt die Message von HB9EYZ-3 und gated sie an APRS-IS.

APRS-iS weiss, dass HB9IPA (IGate) HB9BL-14 gehört hat und schickt das Packet via Internet an HB9IPA.

HB9EYZ-3>APWW11,TCPIP*,qAC,IZ1UQG-N1::HB9BL-14 :?cpu


HB9IPA(IGate) empfängt aus APRS-IS die Message von HB9EYZ-3 und überprüft, ob HB9BL-14 innerhalb des konfigurierten Zeitraums gehört wurde. Wenn ok, wird das Third Party Packet aufbereitet und TXed.

HB9IPA>APDW17,WIDE1-1:}HB9EYZ-3>APWW11,TCPIP,HB9IPA*::HB9BL-14 :?cpu


HB9EAS-10(IGate) empfängt das Packet von HB9IPA via RF. Da das Packet den Pattern "TCPIP" enthält, wird es nicht an APRS-IS gated sondern nur digipeated.

HB9IPA>APDW17,HB9EAS-10*:}HB9EYZ-3>APWW11,TCPIP,HB9IPA*::HB9BL-14 :?cpu


HB9BL-14 empfängt die Packets von HB9IPA (direkt) und HB9EAS-10 (digipeated) via RF. Der verwendete APRS-Client (hier APIR-DWXC) unterdrückt Dupes, entfernt den Third Party Header und verarbeitet die Query-Message.

HB9EYZ-3>APWW11,TCPIP,HB9IPA*::HB9BL-14 :?cpu


HB9BL-14 TXed die Response an HB9EYZ-3. Das Packet wird, wie oben beschreiben, ins Tessin gesendet und dort von den IGates, die HB9EYZ-3 gehört haben, an RF gated.

HB9EYZ-3 RXed die Response von HB9BL-14, gesendet von diversen lokalen IGates. Der verwendete APRS-Client (FT-5DE, APRSISCE etc) unterdrückt Dupes, entfernt den Third Party Header und zeigt die Response-Message an.

Beispiel: Screenshot FT-5DE (Message von "ANSRVR" via TCPIP + Digi 'DO0AB'


Spezifikationen
Successful-APRS-IGate-Operation
IGate Design, Third Party Packets

APRSISCE/32 - APRS Client

"APRSISCE/32 is an advanced Automatic Packet Reporting System (APRS) Client for Amateur Radio, written for Windows (x86 and x64)."

In diesem Screenshot werden nur Packets angezeigt, die vom TRX empfangen und via DireWolf geliefert werden. Die Schnittstelle zu APRS-IS wurde abgeschaltet.


APRSISCE/32 läuft (leider) nur auf Windows. Nach diversen Tests von allen möglichen APRS-Clients ist dies mein bevorzugter Client. Als passender TNC wird natürlich DireWolf eingesetzt.

APRSdroid

APRSdroid ist ein APRS Client. Positionen können via Internet (APRS-IS) oder via TRX (AFSK) verteilt werden. Ein separater TNC ist nicht notwendig.

APRSdroid - Map   APRSdroid - Hub


 

APRSdroid - Log (TCP)   XPERIA & APRSdroid + UV-3R (Vox-Betrieb)


 

APRSdroid - Konfiguration AFSK   APRSdroid - Log (AFSK)   APRSdroid - Map aprs.fi


 

 

APRS Daten Empfang via UV-3R konnte mangels 4-Pol-Stecker für das XPERIA noch nicht ausprobiert werden.

APRSdroid ist eine mächtige Software. Mit der vorgestellten Konfiguration kann man mit einfachen Mitteln und ohne TNC APRS-QRV werden.

APRSbeacon

Mit der Windows-Software ARPSbeacon können bis zu 3 APRS Positions Beacons verwaltet werden. APRSbeacon kann nur senden! Die Positionsbeacons können mit einem Zeitintervall oder manuell abgesetzt werden. Ich verwende den Software TNC AGW Packer Engine (AGWPE.zip).

Definition APRSbeacon, % vor Home wird durch HHMM ersetzt
Anzeige in aprs.fi

Anzeige in openaprs.net, Zeitangabe falsch

Problem:
Positionen können nur mittels Click auf die Karte gesetzt werden. Die Felder Latitude, Longitude und Beacon Header können nicht editiert werden. Ein passender Kartenausschnitt kann gemäss Help in APRSbeacon selbst erstellt werden. Möglich ist auch diese Lösung:

Lösung:
Zu jeder Karte (z.B: BL.jpg) gehört eine File mit Koordinaten zu dieser Karte (BL.inf) sowie ein File mit den Daten der Positionsbeacons (BL.odb). Das File .odb kann editiert und die Koordinaten manuell eingegeben werden. Diese Koordinaten sind im LORAN Format.

Koordinaten bestimmen & in LORAN Format umrechnen und in .odb-File einfügen
LORAN-Format: ggmm.hhN/ggdmm.hhE (g=Grad, m=Minute, h=Hundertstel; Latitude: N=Nord, S=Süd / Longitude: W=West, E=Ost)

--> Programm APRSbeacon beenden
--> .odb-File editieren
--> Google Maps starten
--> Position auswählen, rechte Maustaste
--> 'Was ist hier?' auswählen
--> Koordinate wird im Google Suchfeld angezeigt
--> Converter starten
--> copy Lat(1. Zahl) aus Google Suchfeld
--> Lat im Feld 'Decimal Degrees' eingeben, 'Convert'
--> 'DM.m' copy
--> paste nach 'Latitude=' (.odb-File)
--> copy Lon (2. Zahl) aus Google Suchfeld
--> Lon im Feld 'Decimal Degrees' eingeben, 'Convert'
--> 'DM.m' copy --> paste nach 'Longitude=' (.odb-File)
--> Koordinaten gemäss LORAN Format editieren (siehe Beispiel)
--> .odb-File speichern
--> Programm APRSbeacon starten

Beispiel
Googlemaps, 'Belchenflue' suchen: 47.363508,7.81055;
nach Converter: Latitude=47 21.81048, Longitude=7 48.633;
editieren: 47 21.81048 -> 47.21.81N; 7 48.633 -> 007.48.63E (Achtung: Grad bei Longitude immer 3-stellig!)

Positionsbeacon HB9EYZ-2 'Lenk' wird irgendwo auf Map angezeigt. Lat/Lon sind massgebend.

Link Collection

Helge, SA7SKY, stellt die wichtigsten APRS PDFs inklusive der "Bibel" APRS101.pdf in seiner Sammlung. zur Verfügung (siehe "Documents").


5.10.2023 / 01:26