APRS4R
von Michael (DO5MC): Konzept und Software
und Oliver (DL1LJ): Konzept und Visualisierung
Kurzübersicht:
APRS -IGATE/Digipeater (APRS4R) und Visualisierung der APRS-Daten (APRS4WEB) mit einem WLAN-Router.
Projektstatus:
Der Status im Projektfortschritt von APRS4R kann mit einem Tracker auf der Entwicklerseite von Michael verfolgt werden.
Aktuell:
- 20.04.2007: Die Router laufen nun im Dauerbetrieb sehr stabil. Es werden verschiedene TNC unterstützt. Ein integrierter Webserver ermöglicht nunmerhr eine Kartenansicht mittels APRS4WEB auf jedem gängigen Browser. Schließlich wird auch bei Einsatz der Huger Wetterstation (WMR 928) der Versand von APRS-Wetterbaken ermöglicht.
- 30.03.2007:Derzeit wird an einem Problem mit dem Treiber der seriellen Schnittstelle (USB/Seriell-Adapter) zur Integration der Wetterstation WS2300 gearbeitet.
- 15.03.2007: Neben der Anbindung an das TH-D7 wird nunmehr auch die Verwendung mit einem TNC2 erprobt. Ebenso ist nun auch ein lokaler Server für die Verwendung von APRS-Client-Software includiert.
- 01.03.2007: Die Fortschritte der Visualisierungskomponente (Google-Maps-Overlay) von APRS4WEB können hier eingesehen werden.
- 03.10.2006: Unsere Präsentation für das 4. APRS-Treffen bei DB0HOR kann hier heruntergeladen werden.
- 27.01.2007: In Karlsruhe hat das APRS4R-Treffen stattgefunden. Die zukünftigen Betatester von APRS4R (DL7FAT,DD1WT,DO3NSW) die Freunde von APRS-Karlsruhe (DO5MC,DF4IAN,DG5LAT,DL1LJ) und INTERMAR (DL0IMA) haben sich in Karlsruhe getroffen und die Möglichkeiten einer weiteren kooperativen Zusammenarbeit und zu technischen Details von APRS4R erörtert. Näheres zu den Inhalten des Treffens demnächst hier.
Motivation:
Eines der Ziele des APRS besteht darin, Positions- oder Wettermeldungen über das WWW weiterzuleiten. Anbieter wie www.findu.com werten diese Meldungen sodann aus und bereiten sie Graphisch auf. Somit ist die Positionsverfolgung auf unterlegten Landkarten, aber auch die Ausgabe von Wetterstatistiken mittels eines gängigen "Browsers" möglich. Das Sammel der Daten auf zentralen Servern (APRS-IS) wie www.third.aprs.net erscheint auch deshalb sinnhaft, da schon eine Pfadadressierung von größer WIDE3-3 zu einer solch übermäßigen Mehrfachaussendung durch sich überlappende Digis führen kann, dass eine quasi Selbstblockade der Aussendung die Folge ist. Somit gilt es die knappen Reccourcen (nur eine Frequenz, 144.800 Mhz) bestmöglich zu nutzen.
Einen Paradigmenwechsel deuten insofern Überlegungen an, eine Veränderung der Netzinfrastruktur vorzunehmen.
- Anstatt eine geringe Anzahl großräumig strahlender WIDE-Digipeater einzusetzen, sollen dichte Cluster aus weniger exponierten Startionen gebildet und eine HF-Vernetzung durch sog. Interlinks geschaffen werden.
- Nach dem New n-N -Paradigma von WB4APRsoll zukünftig nur noch WIDE n-N von Digipeatern unterstützt werden (TRACE entfällt)
- und stattsdessen das WIDE "traceable" gemacht werden.
- Zudem soll im Rahmen des Paradigmenwechsels u.A. aus Gründen der Simplifizierung zukünftig eine Adressierung mittels RELAY unterbleiben und sog. "Fill-In-Digipeater" auf das Alias Wide 1-1 umgestellt werden.
- ebenso ist eine Modifizierung überlanger Pfade durch die Digipeater vorgesehen. Die APRS-Gruppe Karlsruhe unterstützt diese Vorschläge vollinhaltlich.
Als Erweiterung machen wir noch folgende Vorschläge:
- Eine ebenfalls sinnvolle Lösung des Problemes überlanger Pfade könnte auch in einem dichteren Netz von IGates bestehen. Ist eine hinreichende Anzahl von IGates eingerichtet, entfällt die Notwendigkeit von langen HF-Pfaden. IGates empfangen APRS-Packete in ihrem Umfeld und leiten diese an die Server des APRS-IS weiter. Im Zeitalter der "Flatrate", wegen der geringen Datenvolumina, mit geringem Kostenaufwand zu realisieren.
- Wegen des technisch- experimentellen Charakter unseres Funkdienstes muss im Rahmen der Pfadmodifikationen auch die Möglichkeit des experimentellen Regelbruchs bestehen. Deshalb schlagen wir in Modifikation des New n-N -Paradigma die Verwendung einer generischen Adresse (z.B. "RFONLY) vor, bei der eine Pfadmodifikation unterbleibt und eine RF-Aussendung auch über große Entfernungen ermöglicht wird.
APRS4R als technische Lösung:
Um die Vorschläge von WB4APR und unsere eigenen Überlegungen zu realisieren wollten wir einen WLAN-Router (geringer Stromverbrauch) unter OpenWRT verwenden. Leider erfüllte keine der uns bekannten Implementierungen den vollständigen erforderlichen Funktionsumfang auf. Insofern wurde eine Eigenentwicklung angestrebt, welche sich durch modularen Aufbau, den veränderten Gegebenheiten anpassen kann und zugleich eine Basis für weitere Erprobungen darstellt. Die Implemntierung soll im Dialog mit den zukünftigen Nutzern geschehen.
Software: Der Router wird mit der Software APRS4R unter OpenWRT versehen und subtituiert dann die APRS-IGate und Digipeater-Software auf einem PC. Details des Projektfortschrittes und die Dokumentation der einzelnen Implementierunsschritte können im Tracker (s.u.) vom Entwickler (DO5MC) ersehen werden. Dort finden sich auch die jeweils aktuellen Scourcen zum Download. Die Roadmap spiegelt den Implementierungsfahrplan der einzelnen Software-Versionen. Zukünftig ist im Rahmen der Konsolidierung der Aktivitäten auch die Integration des Wettermoduls ws.con von Joachim (DF4IAN) geplant.
Hardware: Derzeit werden als TRX das Kenwood TH-D7 und das TM-D700 unterstützt. Eine Erweiterung auf die Verwendung eines TNC2 im KISS-Modus ist geplant. Nach erfolgreicher Umsetzung auf einem modifizierten Linksys-Router wird zukünftig der "ASUS WL-500g Premium" wegen der flexibleren USB-Unterstütung als Referenzhardware Verwendung finden.
Grundkonzeption:

Projektfortschritt:
Links (Spezifikationen):
OpenWRT
Links zu WRT und HamRadio
Raw KISS/AX.25 to ASCII File Converter
The KISS TNC: A simple Host-to-TNC communications protocol
APRS-IS Paths
IGate Configuration
Gating Criteria
Third-Party Packets
Queries
Q Construct
Q Algorithm
Validation