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").