APR2VOICE
Sprachausgabe von APRS-Daten
Stand: 1. Juli 2008
VORLÄUFIG, WIRD IN KÜRZE NOCH ERWEITERT
Einleitung:
Ursprünglich von Bob Bruninga, W4BPR entwickelt, ermöglicht das APRS-System uns Funkamateuren die Übertragung von u.a. aktuellen ( GPS- )Positionsdaten. Werden diese Daten beispielsweise durch Aussendung auf der Frequenz 144.8 MHz in das allgemeine APRS-Netz übertragen, so ist zu ihrer Auswertung in vielen Fällen nur ein standardmäßiger Internetzugang erforderlich.
Ein typisches Einsatzgebiet für APRS ergibt sich im Mobilbetrieb. Häufig beschränkt man sich dabei allerdings auf den reinen Sendebetrieb mit Benutzung einer Funkbake zur cyclischen  Positionsdatenübertragung. Speziell bei Fahrzeugeinsätzen würde es häufig aber reizvoll sein, wenn sich auch das aktuelle APRS-Geschehen der Umgebung verfolgen ließe. Einige Industriegeräte erlauben deshalb bereits eine Displayanzeige von Position, sowie  Distanz und Richtung zu empfangenen Gegenstationen. Die häufige Überwachung dieser Anzeigen führt jedoch zu einer nicht unerheblichen Ablenkung des Fahrers vom Verkehrsgeschehen und muss somit unter Sicherheitsaspekten als problematisch angesehen werden. Um an dieser Stelle eine deutliche Verbesserung zu erreichen, entstand der Decoder "APR2VOICE".


Abb.1  Blockschaltbild der Gesamtanordnung für den APRS-Sende- und Empfangsbetrieb

In Verbindung mit APR2VOICE können KENWOOD-APRS-Funkgeräte mit integriertem TNC
oder sonstige FM-Transceiver mit separatem "OpenTracker" verwendet werden.

Wie sein Name vielleicht schon vermuten lässt, verarbeitet der Baustein "APRS2VOICE" ankommende APRS-Informationen und gibt die Ergebnisse als Sprachmessages aus. Diese lassen sich dann von allen Fahrzeuginsassen leicht verfolgen, wobei sich die Ablenkung des Fahrers hierbei auf ein Minimum reduziert. "APR2VOICE" untersucht via Funk empfangene  Datenfiles auf darin enthaltene Positionsdaten. Anschliessend wird zuerst das Rufzeichen der absendenden Station gesprochen. Bei den für diesen Zweck vom Verfasser zusammengestellten Sprachsegmenten wird für die Buchstaben von A-Z  das sog. NATO-Buchstabieralphabet verwendet, aber selbstverständlich hat der Anwender auch die Möglichkeit, hier stattdessen mit eigenen Segmenten arbeiten zu können.
Nachdem die Ansage von aktuellen Breiten- und Längengradangaben an dieser Stelle sehr wenig aussagekräftig sein würde, wurde auf deren Ausgabe verzichtet. Stattdessen werden nur die jeweiligen Werte von Distanz und Heading-Winkel zu empfangenen Gegenstationen gesprochen. Während Distanzwerte unter 1km in der Einheit "Meter" gesprochen werden, erfolgt die Ausgabe größerer Werte in Kilometern bzw. ( Land- ) Meilen. Eine komplette Sprachmessage kann somit z.B. folgendermaßen lauten:

       delta juliet sieben oscar oscar strich neun ist sieben punkt sechs kilometer in drei eins vier grad

  Hier kann eine Sprachprobe gehört werden

Die Berechnung von Distanz und Winkel erfolgt durch Auswertung a.) der via Funk von den Gegenstationen empfangenen und b.) der aktuellen, von einem direkt angeschlossenen GPS-Empfänger stammenden Positionsdaten ( siehe auch Abb.1 ). Dazu ist noch anzumerken, dass hier anstelle mit den aktuellen GPS-Daten bei Bedarf auch mit Fix-Daten gearbeitet werden kann. Der Anwender kann sie im EEPROM-Bereich des verwendeten Prozessors ablegen und benötigt dann keinen zusätzlichen GPS-Empfänger. Verständlicherweise macht diese Möglichkeit aber nur bei stationärem Einsatz des Decoders an einem bekannten Standort Sinn.
Damit nur die wirklich interessierenden Stationsmessages gesprochenen werden, existieren verschiedene Filtermöglichkeiten. So kann z.B. eingestellt werden, dass NUR die Nachrichten von Stationen mit dem SSID-Anhang "-9" ( Mobilstationen ) gesprochen werden. Darüber hinaus lässt sich wählen, wie weit empfangene Gegenstationen entfernt sein dürfen, um noch verarbeitet zu werden. Hierzu sind Maximaldistanzen zwischen 2 und 1000 Kilometern bzw. [Land-] Meilen gem. Tabelle 2 in 8 Stufen schaltbar.
Eine spätere Firmwareversionen soll auch noch die Eingabe  ( und EEPROM-Ablage ) eines frei bestimmbaren Rufzeichens ermöglichen. Damit kann erreicht werden, dass auf Wunsch NUR die von diesem Absender stammenden Messages gesprochen werden.

Abb.2 Schaltbild von "APR2VOICE"


Abb.3  Musterplatine für "APR2VOICE" ( zur Grossdarstellung anklicken )

Technik:
Hauptbestandteil des Decoders "APR2VOICE" ist ein Prozessor "ATMEGA32". Da dieser nur EINEN seriellen UART-Eingang besitzt, aber zwei Eingangssignale verarbeitet werden müssen, erfolgt deren Umschaltung über einen externen, mit einem IC "74HC157" aufgebauten elektronischen Schalter. Gesteuert über den Prozessor-Port "PD6" wird hierbei eine Umschaltung zwischen den vom TNC eintreffenden und den vom angeschlossenen GPS-Empfänger stammenden Signalen vorgenommen. Zur Pegelanpassung beider mit RS232-Pegel erwarteter Eingangssignale wird ein IC "MAX232" verwendet.
Ein serieller RS232-Ausgang dient der Ausgabe von Testdaten ( Datenrate: 4800bps ). Ein Log dieser Daten kann bei evtl. auftretenden Funktionsproblemen hilfreich werden.
Die Sprachausgabe wurde mit einem bei Fa. Conrad erhältlichen Baustein ( Art.-Nr. 234219-62 ) realisiert. Über seinen 8-Bit-Parallebus können bis zu 64 verschiedene Sprachsegmente aufgerufen werden. Sie müssen im WAV-Format vorliegen und werden in der Vorbereitungsphase einmalig zum Sprachbaustein übertragen. Der Aufruf der einzelnen Sprachsegmente erfolgt über den Mikrocontroller-PortC. Ein vom Sprachspeicherbaustein bereitgestellter "Busy-Puls" ( siehe Abb.2 ) ermöglicht es dem uC, die Dauer und vorallem das Ende einer jeden Sprachsegmentausgabe zu erkennen. Dabei wird jeweils ein Prozessor-Interrupt ausgelöst, was die Aneinanderreihung mehrerer Segmente in schnellstmöglicher Folge möglich macht.
Die zur Verarbeitung kommenden aktuellen Positionsdaten stammen von einem angeschlossenen GPS-Empfänger. Dabei werden NMEA-Protokolle des Typs: "RMC" verarbeitet. Nachdem die Ausgabedatenraten der Empfänger nicht immer einheitlich sind, kann die im Prozessor von APR2VOICE abgelegte Firmware sowohl solche mit der Standard-Datenrate 4800bps, als auch mit 9600bps ankommende verarbeiten.

PROZESSOR-PORT
 FUNKTION
PA.0 (S1)
 siehe Tabelle 2
PA.1 (S2)
 siehe Tabelle 2
PA.2 (S3)
 siehe Tabelle 2
PA.3 (S4)
 "H" = decod. alle Stationen
"L" = decod. nur Mobilstn.
( mit SSID: "-9" )
PA.4 (S5)
 "H" = Ref.-Position gemaess
 aktueller GPS-Daten
"L" = Ref.-Position gemaess Fixdaten aus EEPROM
PA.5 (S6) "H" = GPS-Datenrate 4800bps
"L" = GPS-Datenrate 9600bps
PA.6 (S7) "H" = Distanzen in
Kilometern bzw. Metern
"L" = Distanzen in
( Land- ) Meilen
PA.7 (S8) "H" = Betriebsmode
"L" = Konfigurationsmode
Tabelle 1: Funktionen der Schalter S1-S8
"H" = Schalter geöffnet; "L" = Schalter geschlossen

MAXIMALDISTANZ
( Km oder Meilen )
 PA.0
(S1)
 PA.1
(S2)
 PA.2
(S3)
1000
 H
 H
 H
500
 L
H
 H
250
 H
 L
 H
100
 L
 L
 H
50
 H
 H
 L
30
 L
 H
 L
15
 H
 L
 L
2
 L
 L
 L
Tabelle 2 :  Schalter S1-S3 zur Auswahl der Distanzbegrenzung für auszuwertende Daten
"H" = Schalter geöffnet; "L" = Schalter geschlossen

Der anzuschließende TNC bzw. APRS-Tracker muss in der Lage sein, NMEA-Protokolle des Typs: "WPL" ( siehe auch Tabelle 3 ) mit 4800bps bereitzustellen. Das können z.B. alle APRS-tauglichen KENWOOD-Geräte, wie TH-D7, TM-D700 und auch das neue TM-D710, wobei die Signale hierbei an einem normalerweise wenig beachteten Ausgangs-Pin der GPS-Anschlussbuchse zur Verfügung gestellt werden.

$GPWPL,4845.42,N,00824.47,E,DB0TFM-6*3F
Tabelle 3 : Beispiel für den Aufbau eines NMEA-Satzes Typ: "WPL"
( <header>,<latitude>,<n/s>,<longitude>,<e/w>,<ident/callsign>*<checksum> )

Wer kein solches KENWOOD-Gerät besitzt, der kann stattdessen aber auch einen der preisgünstig erhältlichen "OPEN-TRACKER" von Scott Miller, N1VG ( in DL erhältlich bei: www.jaeger-edv.de ) oder einen "TinyTrak4" von  www.byonics.com verwenden. Dabei ergibt sich sogar noch der Vorteil, daß diese Tracker in Verbindung mit ( fast ) jedem handelsüblichen Amateurfunk-FM-Transceiver eingesetzt werden können..

Abb.4  Erster Musteraufbau der APR2VOICE-Decodereinheit  unter Verwendung einer ELEKTOR-Platine und eines "Opentrackers" OT1+ SMT.
 Da der für die Eingangssignalauswahl benötigte elektronische Umschalter bei dieser Platine fehlt,
ist hierbei NUR Betrieb mit fixen Eigenstandorten möglich.
Hier findet man noch weitere Informationen zum benutzten Sprachspeicherbaustein:
http://www.kh-gps.de/speedtalk.htm

Zu der für das erste Muster verwendeten ELEKTOR-Platine und auch zum "OpenTracker" gibt es hier weitere Infos:
http://www.kh-gps.de/lcdtrak.htm
NOCH ETWAS ZUM GUTEN SCHLUSS:

Zum Langzeittesten des APR2VOICE-Decoders benutzte ich auf der Frequenz 144.8MHz empfangene Live-Daten. Dabei kam es aber leider immer wieder vor, dass sich das Empfangsprogramm in unregelmäßigen Zeitabständen aus vorerst unerfindlichen Gründen "aufhängte" und die weitere Verarbeitung von Eingangsdaten unterbrochen wurde. Durch kurzes Betätigen der Programm-Reset-Taste konnte der Decoder dann zwar auch wieder zum Weitermachen veranlasst werden, aber eine endgültige Lösung war das natürlich nicht. Ich versuchte dem Problem auf die Spur zu kommen, in dem ich unterschiedliche Varianten von Teilen der Decodersoftware austestete. Nach jeder Änderung musste das Ergebnis aufs Neue compiliert und zum Mikrocontrollerbaustein übertragen werden, worauf dann immer auch wieder die langwierige Prüfphase mit Auswertung der Live-Daten begann. Wenn dann nach längerem Decoderbetrieb noch kein Fehlverhalten aufgetreten war, hoffte ich den Durchbruch geschafft zu haben, aber danach kam es dann doch immer wieder irgendwann zum Aufhängen des Programmes. Es war zum Verzweifeln. Die gesamte Testphase zog sich mehrere Tage hin, ohne dass ein durchschlagender Erfolg zu verzeichnen war. Immerhin konnte das Problem dabei aber dahingehend eingekreist werden, dass es mit der Auswertung der Absender-Rufzeichen zusammenhängen musste. Deren Aufbau hatte ich auch in Hinblick auf ggf. anhängende SSID's studiert und ging davon aus, dass meine  Software hierbei auch alle denkbaren Varianten erfassen würden. Bei näherer Untersuchung der jeweils zum Programmabsturz führenden APRS-Messages stellte sich dann aber heraus, dass es auf der APRS-Frequenz die in etwa einstündlichem Abstand erfolgenden Aussendungen einer Station gab, die sich des doch etwas sehr eigenwilligen amtlichen Rufzeichens: "Grillfest" bediente, was mein Decoder in der derzeitigen Version nun aber überhaupt nicht mochte. Ohne Probleme wäre es noch verlaufen, wenn man hierbei wenigstens auf die Aussendung von Kleinbuchstaben verzichtet hätte, aber so............
Nach erneuter Softwareänderung kommt der Decoder inzwischen aber auch mit Stationen wie "Grillfest" und ( hoffentlich ) allem was hier ansonsten noch kommen könnte zurecht.