Decoder wandelt D-STAR-Navigationsdaten zur Auswertung mit z.B. UI-VIEW oder APRSDROID
Stand: 26.
März 2012
Using ANDROID software "APRSDROID"
or PC software like UI-VIEW for decoding navigation data ( NMEA and
GPS-A ) as provided by D-STAR
radiosHere is automatic translation made by Google: http://translate.google.com/translate?hl=en&sl=de&tl=en&u=http%3A%2F%2Fwww.kh-gps.de%2Fser2bt.htm
BTW: better translations would be appreciated
Abb.1 Musteraufbau der Anordnung zur Auswertung von D-STAR-Navigationsdaten mithilfe von APRSDROID
Begonnen hatte es damit, dass ich nach einer geeigneten APRS-Applikation für mein Android Smartphone suchte und dabei auf das tolle Programm APRSDROID [1],[2] von Georg Lukas ( DO1GL ) stiess. Offenbar war das Programm ursprünglich vorwiegend dazu gedacht, eines der öffentlichen Mobilfunknetze zu nutzen, um darüber Datenverbindungen in das weltweite APRS-IS-Netz herstellen zu können ( Nach Meinung mancher Funkamateure hatte das nichts mehr mit Amateurfunk zu tun, so dass der Programmautor auch in zum Teil massiver Weise angegangen wurde und - wenn ich es richtig interpretiere - er das Projekt auch schon aufgeben wollte ). Meine erste Berührung mit dem Programm ging allerdings in die gleiche Richtung. Wie aus Abb.2 ersichtlich ist, war die Zuverlässigkeit der Übertragung von Navigationsdaten in das weltweite APRS-IS-Netz dabei beachtlich zuverlässig. Zum Einsatz kam bei diesem Beispiel ein unterhalb der Frontscheibe meines Fahrzeuges eingeklemmtes SONY-ANDROID-Smartphone, welches Standortdaten via O2-Mobilfunk im Abstand von 10 Minuten in das APRS-Netz übermittelte.
Abb.2
Der hier gezeigte Track ( DJ7OO-10 ) wurde mithilfe der Seite: http://www.aprs.fi ausgewertet.
Abb.3 D2A-Decoder zur Wandlung von NMEA-/GPS-A-Protokollen in das APRS-Kiss-Format ( ursprüngliche Version )
Über den RS232-Eingang werden die von D-STAR-Geräten stammenden Navigationsdaten verarbeitet. Zur Adaption ist lediglich ein handelsüblicher, gemäss Abb.4 belegter 2.5mm-Stereo-Klinkenstecker erforderlich.
Abb.4
Datenanschluss von
ICOM-D-STAR-Geräten
Leider hat sich bei
mir erst nach Entwurf des gemäss Abb.3 erstellten Platinenlayouts
herausgestellt, dass zumindest die bei mir vorhandenen ICOM-Geräte
nur dann Daten
an ihrem Pin "RxD" ( Abb.4 ) ausgaben, wenn auch am Eingangspin "TxD"
eine
negative Spannung anlag. Bei Anschaltung einer Peripherie mit
RS232-Ausgang ( z.B. einem GPS-Empfänger ) ist das
zwar üblicherweise der Fall, aber in sonstigen
Fällen muss hier zur Not eine negative Festspannung im Bereich von
etwa
5-15V angelegt werden.
Abb.
4a -5V-Spannungsinverter für den TxD-Eingang in
Richtung Funkgerät
Auf der Suche nach
einer schnellen
Übergangslösung stiess ich auf den Baustein ICL7660, mit dem
sich sehr
einfach ein
geeigneter Generator aufbauen liess ( Abb.4a ). Den
benötigten Baustein gab es z.B. bei Fa. Reichelt für 57
Cents. Alternativ kann man aber z.B. auch einen bei der gleichen Firma
erhältlichen
5V/5V-Spannungswandlerbaustein mit Potentialtrennung verwenden.
Mit der nächsten Platinenversion wird die Anpassung an
die RS232-Ein- und Ausgangspegel jedoch mithilfe von MAX232-Bausteinen
gemäss Abb. 4b gelöst werden.
Abb.
4b neue Schaltbildversion ( ersetzt Schaltbild Abb.3 )
Zur Anpassung an das jeweils benutzte Funkgerät kann via Schalter "S1" zwischen den Datenraten 9600bps ( S1: "offen" ) und 4800bps ( S1: "geschlossen" ) gewählt werden. Transistor T1 ( alte Version ) bzw. Schaltkreis "U1" ( neue Version ) setzen die Eingangssignale auf den zur Steuerung des Atmega-Prozessors "U2" benötigten TTL-Pegel um. Der Prozessor selbst ist mit der passenden Firmware ( wird hier demnächst bereitgestellt ) zu laden und dient dann der Convertierung ankommender Daten in das benötigte APRS-KISS-Format, wobei die Ausgabedatenrate bei 19200bps liegt.
Über Schalter "S2" kann bestimmt werden, ob eine Signalausgabe nur erfolgen soll, nachdem die Prüfsummenkontrolle für empfangene NMEA- und GPS-A-Protokolle erfolgreich war ( S2: "offen" ) oder ob auf diese Prüfung verzichtet werden soll ( S2: "geschlossen" ). Erforderlich wurde diese Massnahme, weil zeitweilige Übertragungsfehler bei D-Star leider ein grosses Problem darstellen. Nachdem es hierfür erst einmal auch keine Möglichkeit zur Prüfsummenkontrolle gibt, ist davon in erster Linie der NMEA-Mode und hierbei die Rufzeichen- und Textzeile betroffen. Ändern könnte man das nur, in dem man auch ihren Inhalt einem bestimmten Format folgen lassen und eine eigene Prüfsumme zusetzen würde. Mit "D-PRS"gibt es zwar bereits ein solches Format, wobei seine konsequente Nutzung allerdings bedeuten würde, dass auch alle korrekt übertragenen, hierzu aber nicht kompatiblen Zeileninhalte bei der Prüfsummenkontrolle unter den Tisch fallen würden. Daher denke ich, dass wir vorerst damit leben sollten, dass es bei schlechten Funkverbindungen an dieser Stelle zu Fehlauswertungen auf Grund von Übertragungsfehlern kommen kann. Als Kompromiss wird bei den aktuellen Softwareversionen aber immerhin nach gemäss D-PRS-Festlegung eingefügten Icon-Codes gesucht, so dass auf diese Weise zumindest auch die Darstellung verschiedener Symbole möglich wird ( siehe dazu auch weiter unten ).
Durch Schliessen von "S3" lässt sich die Decodierung von NMEA-Protokollen allerdings auch auf Wunsch völlig unterdrücken.
Diode "LED1" wird nach jeder erfolgreichen Protokolleinlesung einmal kurz aufleuchten.
Die vom Prozessor an seinem Pin3 mit 19200bps bereitgestellten Ausgangsdaten werden einem Bluetoothmodul "BTM-222" [8] zugeführt. Um sie ausenden zu können, muss das Modul vorher einmalig als SLAVE deklariert und auf die Datenrate 19200bps eingestellt werden [*]. Im Grundmenü des ANDROID-Gerätes ist ebenfalls einmalig eine Paarung mit dem BT-Modul herzustellen. Danach sollte es auch im entsprechenden Menü von APRSDROID zu finden sein und damit den späteren Aufbau einer BT-Verbindung ermöglichen. Das geschieht allerdings erst, wenn später unter APRSDROID auch die Tracking-Funktion gewählt wurde ( siehe weiter unten ). Zur Signalisation dieses Zustandes wird "LED3", die bis dahin nur ständig blinkete, danach dauerhaft leuchten. Im Gegensatz dazu wird "LED2" bei bestehender BT-Verbindung immer nur für die kurzen Zeitpunkte einer Datenübertragung aufleuchten.
Als Antenne für das Bluetooth-Modul verwende ich ein nur etwa 30mm langes Stück Schaltdraht, was etwa dem Viertel der benutzten Wellenlänge von ca. 12cm entspricht. Nachdem die propagierte Ausgangsleistung des Bluetooth-Moduls "BTM-222" bei +18dbm ( = ca. 65mW ) liegt, können Funkreichweiten von bis zu 100m erwartet werden, wobei das natürlich auch von der technischen Ausstattung der Gegenstelle abhängt.
Der 6pol. ISD-Anschluss ermöglicht ein sogenanntes "In Circuit Programming" des eingesetzten Prozessors
* In Vorbereitung: nähere Angaben hierzu
Wenn Positionsdaten empfangener Stationen auch auf Karten dargestellt werden sollten, war bei früheren Programmversionen von APRSDROID immer auch eine Internetverbindung erforderlich, Dabei wurde auf das von GOOGLE bereitgestellte Kartenmaterial zurückgegriffen. Alternativ dazu gibt es aber auch neuere Versionen von APRSDROID, bei denen stattdessen mit OSM-Karten ( OSM= Open Street Maps ) gearbeitet wird. Der Vorteil dabei ist, dass sich diese Karten länderweise aus dem Internet herunterladen und auf der Speicherkarte des Android-Gerätes ablegen lassen, um anschliessend immer auch Offline zur Verfügung zu stehen. Die Karte von Deutschland hat z.B. eine Größe von etwa 1GB.
Näheres zur Verwendung von OSM-Karten unter APRSDROID findet man hier [3].
AUSWERTUNG VON D-STAR-NAVIGATIONSDATEN
UNTER "APRSDROID"
Abb.5-7 Die wichtigsten Fenster von APRSDROID
Nach
dem Starten des "Tracking-Modes" wird die Bluetoothverbindung mit dem
BTM222-Modul hergestellt. In
der Einstellung "Protokoll"
sollten jetzt die vom
D-STAR-Gerät über den Converter neu eintreffenden Navigationsdaten ( Abb.5 ) sichtbar werden.
Das
Fenster gemaess Abb.6
wird nach Anwahl der Funktion "Hub" sichtbar. Es listet alle seit
Tracking-Start empfangenen ( D-STAR-) Stationen in der Reihenfolge
ihrer Distanz zum Eigenstandort, was die schnelle Übersicht
speziell des APRS-Geschehens im näheren Umfeld sehr erleichtert.
An oberster Stelle der Liste erscheinen die vom Programm generierten, aber im vorliegenden Einsatzfalle ( nachdem APRSDROID hier NUR als Decoder arbeitet ) nicht genutzten Aussendungen.
Bei den einzelnen Einträgen wird jeweils ein APRS-Icon vor den Rufzeichen dargestellt. Bei Aussendungen, die im GPS-A-Mode erfolgen, sind die verschiedenen möglichen Icons ( z.B. Haus, Auto, Fussgänger usw. ) fester Bestandteil des Protokolls und werden somit auch übertragen. Bei Nutzung des NMEA-Modes ist das dagegen nicht der Fall, so dass hier ggf. nur ein Universal-Icon angezeigt wird. Bei Empfang von Stationen, die ihre Zusatzzeile dagegen entsprechend der Regularien nach [15] beschrieben haben, können zumindest die etwa 15 gängigsten Icon-Codes erkannt und ausgewertet werden. Dazu muss der Textteil der Zeile allerdings mit einem zweistelligen, den jeweiligen Icon-Typ bestimmenden Buchstabencode GEFOLGT VON ZWEI LEERSTELLEN beginnen. Details sind Tabelle1 zu entnehmen.
An oberster Stelle der Liste erscheinen die vom Programm generierten, aber im vorliegenden Einsatzfalle ( nachdem APRSDROID hier NUR als Decoder arbeitet ) nicht genutzten Aussendungen.
Bei den einzelnen Einträgen wird jeweils ein APRS-Icon vor den Rufzeichen dargestellt. Bei Aussendungen, die im GPS-A-Mode erfolgen, sind die verschiedenen möglichen Icons ( z.B. Haus, Auto, Fussgänger usw. ) fester Bestandteil des Protokolls und werden somit auch übertragen. Bei Nutzung des NMEA-Modes ist das dagegen nicht der Fall, so dass hier ggf. nur ein Universal-Icon angezeigt wird. Bei Empfang von Stationen, die ihre Zusatzzeile dagegen entsprechend der Regularien nach [15] beschrieben haben, können zumindest die etwa 15 gängigsten Icon-Codes erkannt und ausgewertet werden. Dazu muss der Textteil der Zeile allerdings mit einem zweistelligen, den jeweiligen Icon-Typ bestimmenden Buchstabencode GEFOLGT VON ZWEI LEERSTELLEN beginnen. Details sind Tabelle1 zu entnehmen.
Durch
Berühren
eines Eintrags lässt sich auf Anzeige nur der von zugehörigem
Call
stammenden Daten umschalten. Daraufhin öffnet sich ein Fenster
gemaess Abb.7.
| Symbol |
Buchstabencode |
| Haus |
"BN
" |
| PKW |
"MV
" |
| Ballon |
"PO
" |
| Flugzeug |
"BH
" |
| Motorrad |
"MT
" |
| Fahrrad |
"LB
" |
| LKW |
"LK
" |
| Van |
"LV
" |
| Yacht |
"PY
" |
| Helicopter |
"PX
" |
| Jeep |
"LJ
" |
| Haus
mit Yagi |
"LY
" |
| LKW
gross |
"LU
" |
| Jogger |
"HS
" |
Tabelle
1 Liste der im NMEA-Mode unterstützten Symbole
Abb.8-9
Zoombare Kartendarstellung; hier: OSM-Karten ( Für
Darstellung in Originalgröße anklicken )
Durch weiteres Berühren des oberen Fensters lässt sich der hinter jedem Eintrag abgelegte Standort auch auf einer Karte visualisieren ( Abb.8-9 ). Dabei sind weitgehende Zoommöglichkeiten möglich, so dass sich auf Wunsch auch eine Darstellung bis auf Strassenniveau möglich ist und auch z.B. in Fahrt befindliche Mobilstation sich sehr gut verfolgen lassen.
Durch weiteres Berühren des oberen Fensters lässt sich der hinter jedem Eintrag abgelegte Standort auch auf einer Karte visualisieren ( Abb.8-9 ). Dabei sind weitgehende Zoommöglichkeiten möglich, so dass sich auf Wunsch auch eine Darstellung bis auf Strassenniveau möglich ist und auch z.B. in Fahrt befindliche Mobilstation sich sehr gut verfolgen lassen.
VERWENDUNG DES D2A-DECODERS
IN VERBINDUNG MIT DEM PC-PROGRAMM "UI-VIEW"
IN VERBINDUNG MIT DEM PC-PROGRAMM "UI-VIEW"
Abb.10 Beispiel für Auswertung von D-STAR-Navigationsdaten mithilfe von UI-VIEW
Die vom Decoder bereitgestellten Protokolldaten lassen sich auch am PC auswerten ( Abb. 10 ). Dabei kann z.B. das bekannte Programm "UI-VIEW" zum Einsatz kommen. Während viele PC's bereits von Haus aus mit einem Bluetooth-Modul ausgerüstet sind, lässt sich alternativ aber auch ein über die USB-Schnittstelle ansteckbarer Bluetooth-Stick nutzen. Mithilfe der zugehörigen BT-Software kann daraufhin eine Suche nach potentiellen Gegenstellen gestartet werden. Wenn im Betrieb und in Reichweite befindlich, sollte dabei auch unser BTM-222-Modul erkannt werden, so dass der Aufbau einer seriellen Verbindung zu ihm möglich wird. Dabei auftetende Fragen nach einem Initialisierungscode müssen mit dem Standardwert "1234" beantwortet werden. Nach erfolgtem Verbindungsaufbau sollte die Ordnungszahl der eingerichteten virtuellen Schnittstelle angezeigt werden ( z.B. COM 4 ) . Entsprechend dieser Angabe ist der gleiche COM-Port auch die unter "UI-VIEW" zu wählen. Weiterhin ist in seinem Programmmenü auch der "KISS-Mode" zu selektieren. Darüberhinaus kann es sein, dass es erforderlich sein wird, unter: "SETUP" > "MISCELLANEOUS" bei "Relaxed frame type check" einen Haken zu setzen.
In Vorbereitung: APRS-Variante mit Wandlung von WPL- und PKWDWPL-Protokollen in das APRS-Kiss-Format
Inzwischen wurde
auch ein passendes Platinenlayout entworfen ( Abb.11-12 ). Nachdem die
ersten Musterplatinen eingetroffen sind, ist der Versuchsaufbau zur
Zeit in der
Testphase. Nach Abschluss werden hier auch Sourcecode und HEX-File
herunterladbar
sein. Darüberhinaus ist beabsichtigt, an dieser Stelle auch
bereits programmierte Prozessorern und Platinen auf privater Basis
anzubieten.
Abb.11-12 Abbildungen für Darstellung in Originalgrösse anklicken
Anm. zu Abb.10: Der hier sichtbare "78L05" war bei Fotoerstellung noch fälschlicherweise um 180° verdreht eingebaut.
ALTERNATIV:
D2A-DECODER AUFGEBAUT UNTER VERWENDUNG VON ARDUINO-BOARDS
Zur Vereinfachung des
Nachbaus entstand die Idee der Verwendung von aus der ARDUINO-Familie
stammenden preiswerten Hardwarekomponenten [17].
Hier
zuerst einige allgemeine Angaben zu ARDUINO und seinen Boards:
Bei ARDUINO handelt es sich um eine aus Italien stammende, inzwischen sehr weit verbreitete Hard- und Softwareplatform für Microcontrolleranwendungen. Auch hierbei kommen Prozessoren der ATMEGA-AVR-Serie von Firma ATMEL zum Einsatz. Im Original erfolgt die Programmerstellung dabei üblicherweise in der Sprache "C", aber die erhältliche Hardware lässt sich auch sehr gut für Projekte verwenden, die unter Benutzung einer anderen Programmiersprache, wie z.B. "BASCOM-AVR" erstellt wurden.
Das aktuelle Basisboard ist der "ARDUINO-UNO REV.3" ( Abb.13 und 14 ). Sein Vorgänger war der inzwischen schon legendäre "DUEMILLANOVE" ( ital. = 2009 ).
Darüber hinaus gibt es auch erweitere und abgespeckte Boardversionen, wobei diese aber für unsere Anwendung weniger oder garnicht geeignet sind.
Bei ARDUINO handelt es sich um eine aus Italien stammende, inzwischen sehr weit verbreitete Hard- und Softwareplatform für Microcontrolleranwendungen. Auch hierbei kommen Prozessoren der ATMEGA-AVR-Serie von Firma ATMEL zum Einsatz. Im Original erfolgt die Programmerstellung dabei üblicherweise in der Sprache "C", aber die erhältliche Hardware lässt sich auch sehr gut für Projekte verwenden, die unter Benutzung einer anderen Programmiersprache, wie z.B. "BASCOM-AVR" erstellt wurden.
Das aktuelle Basisboard ist der "ARDUINO-UNO REV.3" ( Abb.13 und 14 ). Sein Vorgänger war der inzwischen schon legendäre "DUEMILLANOVE" ( ital. = 2009 ).
Darüber hinaus gibt es auch erweitere und abgespeckte Boardversionen, wobei diese aber für unsere Anwendung weniger oder garnicht geeignet sind.
| Die wichtigsten Angaben zum Board
"ARDUINO-UNO" und den Shields: * Prozessor: ATMEL "ATMEGA328P" mit Taktrate: 16 MHz * über 6pol. ICP-Anschluss On Board programmierbar * USB-Schnittstelle * Versorgung über USB mit 5V oder über externe Spannung von ca. 7-15V * auf Basisboard steckbare sog. "Shields". Es gibt sie in vielfacher Ausfertigung für die unterschiedlichsten Anwendungen. Hier verwendet: "Proto-Shield Rec.3" ( Abb.13 und 14 ). Es ist vorwiegend in Rastertechnik Rastertechnik aufgebaut und damit universell verwendbar für eigene Zusatzhardware. * Preiswerter ist die Verwendung der auch separat erhältlichen "Proto-Shield PCB's", die dann vom Anwender selbst noch mit geeigneten Steckerleisten zu versehen sind. |
Abb. 13 und 14 Board "ARDUINO-UNO" und "Proto Shield" ( zur Grossdarstellung anklicken )
Wesentliche
Funktionen unseres "DSTAR zu APRS-KISS-Decoders" können bereits
durch das ARDUINO-UNO-Hauptboard ( Abb.13 und 14 ) abgedeckt werden.
Was noch fehlt ist auf dem aufsteckbaren "Proto Shield" unterzubringen.
Das Schaltbild der zusätzlich benötigten Komponenten zeigt
Abb. 15. Sollen die convertierten APRS-KISS-Daten nicht via
Bluetooth auf z.B. ein Smartphone/Tablet übertragen, sondern an
einem PC ausgewertet werden, dann besteht ein grosser Vorteil darin,
dass unser ARDUINO-UNO bereits mit einer USB-Schnittstelle ausgestattet
ist und diese dabei sogar die Spannungsversorgung des Decoders
übernehmen kann. In diesem Fall kann auch der im Schaltbild rot
umrandete Part entfallen.
Abb. 15 Shield-Zusatzbeschaltung für den D2A-Decoder
Abb.16 zeigt ein
Muster dieser Decoderversion ( hier noch ohne das Bluetooth-Modul ).
Ihr Vorteil besteht vorallem in ihrer unkritischen Nachbaubarkeit.
Allenfalls bei Verwendung des Bluetooth-Moduls kommt man um einen Rest
an SMD-Bestückung nicht herum. Hierfür empfiehlt sich die
Verwendung eines kleinen, auf dem Shield zusätzlich
unterzubringenden Boards. Geeignete Platinchen sind z.B. hier
erhältlich [16].
Abb.16 D2A-Decoder mit ARDUINO-Boards in der ARDUINO-Box ( hier: ohne Bluetooth-Modul )
DATENFORMATE DER D-STAR-GERÄTE
Bei
D-Star-Geräten lassen
sich GPS-Navigationsdaten
unter Verwendung von zwei
verschiedenen Formaten aussenden. Nach
entsprechender Einstellung werden diese noch näher zu
beschreibenden
Datenformate im "Low-speed data communications Kanal" der Geräte
übertragen. Nach Funkempfang stehen sie auch an der
seriellen Empfängerschnittstelle wieder zur Verfügung.
Datenaussendungen
können entweder parallel zur Sprachübertragung bei
gedrückter Mikrofontaste oder als automatische Bakenaussendungen
in vorgewählten Zeitintervallen
erfolgen. Nachteilig beim D-STAR-System ist leider das Fehlen jeglicher
Mechanismen zur Erkennung von z.B. auf dem Funkweg auftretenden
Störungen.
1. NMEA-FORMATE
Tabelle 2: Beispiel für NMEA-Formate
Bei der Menüauswahl möglicher NMEA-Formate macht es Sinn, sich auf die zur Übermittlung der wichtigsten Navigationsdaten unbedingt notwendigen Typen zu beschränken, als da sind "GPGGA" und "GPRMC". Obwohl teilweise auch redundante Informationen enthaltend, ist dennoch eine Anwahl beider Protokolle sinnvoll. Der Grund dafür ist, dass einzelne Informationen wie z.B. Höhenwerte oder Bewegungsrichtung und Kurs in nur jeweils einem der beiden Protokolltypen bereitgestellt werden. Am Ende der eigentlichen Protokolle ist immer auch noch eine aus zwei Hex-Zeichen bestehende Prüfsumme zu finden. Sie ermöglicht eine weitgehende Kontrolle der davorstehenden Zeileninhalte und kann somit zur Erkennung von Übertragungsfehlern benutzt werden.
Eine besondere Bewandnis hat es mit der am Ende stehenden Zusatzzeile. An ihrem Beginn steht das Rufzeichen der absenden Station ( ohne SSID ). Dieser Eintrag muss immer achtstellig sein, wobei nicht benötigte Stellen durch Leerzeichen ( ASCII-Char.: 0x20 ) aufzufüllen sind. Vor einem möglichen, frei gestaltbaren Text muss an Position 9 in jedem Fall ein Komma eingefügt sein. Der Nachteil ist, dass diese Zeile keine zusätzliche Prüfsumme enthält, womit auf der Auswertseite auch keine Möglichkeit zur Erkennung eventueller Übertragungsfehler besteht. Alternativ hierzu liesse sich zwar auch eine Gestaltung der Zeile gemäss der in [15] beschriebenen Festlegungen mit angefügter Prüfsumme realisieren. Der damit verbundene Nachteil ( Nicht-Decodierbarkeit aller hierzu nicht kompatiblen Zeileninhalte ) wurde aber schon an anderer Stelle erwähnt.
Anm.: Bei Nutzung des oben erwähnten Buchstabencodes ( gem. Tabelle 1 ) zur Übertragung von Daten unterschiedlicher Icon-Symbole, würden diese anstelle des Wortes "MOBIL" in der Zusatzzeile erscheinen müssen.
1. NMEA-FORMATE
Tabelle 2: Beispiel für NMEA-Formate
Bei der Menüauswahl möglicher NMEA-Formate macht es Sinn, sich auf die zur Übermittlung der wichtigsten Navigationsdaten unbedingt notwendigen Typen zu beschränken, als da sind "GPGGA" und "GPRMC". Obwohl teilweise auch redundante Informationen enthaltend, ist dennoch eine Anwahl beider Protokolle sinnvoll. Der Grund dafür ist, dass einzelne Informationen wie z.B. Höhenwerte oder Bewegungsrichtung und Kurs in nur jeweils einem der beiden Protokolltypen bereitgestellt werden. Am Ende der eigentlichen Protokolle ist immer auch noch eine aus zwei Hex-Zeichen bestehende Prüfsumme zu finden. Sie ermöglicht eine weitgehende Kontrolle der davorstehenden Zeileninhalte und kann somit zur Erkennung von Übertragungsfehlern benutzt werden.
Eine besondere Bewandnis hat es mit der am Ende stehenden Zusatzzeile. An ihrem Beginn steht das Rufzeichen der absenden Station ( ohne SSID ). Dieser Eintrag muss immer achtstellig sein, wobei nicht benötigte Stellen durch Leerzeichen ( ASCII-Char.: 0x20 ) aufzufüllen sind. Vor einem möglichen, frei gestaltbaren Text muss an Position 9 in jedem Fall ein Komma eingefügt sein. Der Nachteil ist, dass diese Zeile keine zusätzliche Prüfsumme enthält, womit auf der Auswertseite auch keine Möglichkeit zur Erkennung eventueller Übertragungsfehler besteht. Alternativ hierzu liesse sich zwar auch eine Gestaltung der Zeile gemäss der in [15] beschriebenen Festlegungen mit angefügter Prüfsumme realisieren. Der damit verbundene Nachteil ( Nicht-Decodierbarkeit aller hierzu nicht kompatiblen Zeileninhalte ) wurde aber schon an anderer Stelle erwähnt.
Anm.: Bei Nutzung des oben erwähnten Buchstabencodes ( gem. Tabelle 1 ) zur Übertragung von Daten unterschiedlicher Icon-Symbole, würden diese anstelle des Wortes "MOBIL" in der Zusatzzeile erscheinen müssen.
2.
GPS-A-FORMAT
Tabelle 3: Beispiel für GPS-A-Format
Alternativ zu den NMEA-Formaten erlauben die meisten D-STAR-Geräte auch eine Positionsdatenausgabe im sogenannten GPS-A-Format. Charakteristisch ist hierbei der Header mit der Zeichenfolge "$$CRC" gefolgt von einer vierstelligen CRC16-Prüfsumme. Nach Kommaabtrennung folgen das Absender-Call und einige auf der Auswertseite nicht unbedingt zu berücksichtigende Daten. Wichtig sind erst wieder die Zeileninhalte im Anschluss an den Doppelpunkt. APRS-Freaks mag auffallen, dass sie völlig identisch mit einem auch bei APRS benutzten Format sind ( und damit eine ggf. zu realisierende Decodierung natürlich stark vereinfachen ). Der Vorteil des GPS-A-Formates besteht darin, dass alle relevanten Navigationsdaten einschliesslich Absender-Call, APRS-Symbol und -tabelle und ggf. auch Geschwindigkeits-, Kurs-, sowie Höhenwerte, sowie zusätzliche Kurztexte in EINER Zeile vereint sind und sich dadurch mithilfe der Prüfsumme immer auch für das Ganze eine wirksame Übertragungsfehlerkontrolle realisieren lässt. Somit ist meines Erachtens diesem Format in der D-STAR-Praxis immer der Vorzug zu geben.
Menüeinstellungen
zur Nutzung empfangener Navigationdaten Tabelle 3: Beispiel für GPS-A-Format
Alternativ zu den NMEA-Formaten erlauben die meisten D-STAR-Geräte auch eine Positionsdatenausgabe im sogenannten GPS-A-Format. Charakteristisch ist hierbei der Header mit der Zeichenfolge "$$CRC" gefolgt von einer vierstelligen CRC16-Prüfsumme. Nach Kommaabtrennung folgen das Absender-Call und einige auf der Auswertseite nicht unbedingt zu berücksichtigende Daten. Wichtig sind erst wieder die Zeileninhalte im Anschluss an den Doppelpunkt. APRS-Freaks mag auffallen, dass sie völlig identisch mit einem auch bei APRS benutzten Format sind ( und damit eine ggf. zu realisierende Decodierung natürlich stark vereinfachen ). Der Vorteil des GPS-A-Formates besteht darin, dass alle relevanten Navigationsdaten einschliesslich Absender-Call, APRS-Symbol und -tabelle und ggf. auch Geschwindigkeits-, Kurs-, sowie Höhenwerte, sowie zusätzliche Kurztexte in EINER Zeile vereint sind und sich dadurch mithilfe der Prüfsumme immer auch für das Ganze eine wirksame Übertragungsfehlerkontrolle realisieren lässt. Somit ist meines Erachtens diesem Format in der D-STAR-Praxis immer der Vorzug zu geben.
ICOM
"ID-31A/E"
im "Low-speed data communication mode"
Um die
von empfangenen Stationen stammenden Navigationsdaten mit dem hier
beschriebenen Converter weiterverarbeiten zu können, muss
dafür Sorge getragen werden, dass sie an der Datenbuchse gem.
Abb.4 auch zur Verfügung stehen. Dazu habe ich das "ID-31" für erste
Versuche erst einmal gemaess den im PDF-File "Advanced Instructions"
enthaltenen Angaben ( Abschnitt 4, Seite 12 ) auf "Low-speed data
communication Mode" gesetzt. Es wird natürlich angestrebt, die
Datenauswertung auch in Verbindung mit der GPS-Sendefunktion nutzen zu
können ( so wie es auch schon z.B. bei den alten
"IC-91E" möglich war ). Ohne dass es bisher schon praktisch
ausprobiert werden konnte, sollte das
auch mit dem ID-31 möglich sein, wobei dabei die in der folgenden
Tabelle unter "3. Einstellung" für "GPS TX MODE" nicht "OFF",
sondern "GPS(DV-G)" zu wählen ist.
Hier aber erst einmal die erforderlichen Einstellungen für einen Betrieb im "Low-speed data communication Mode":
Zusätzlich ist auch noch die
serielle Datenrate zu wählen bzw. nur zu kontrollieren. Das
"ID-31"
und mein Decoder erlauben an dieser Stelle sowohl 4800bps als auch
9600bps, womit nur sichergestellt werden muss, dass die
Datenrateneinstellungen beider Einheiten übereinstimmen:
Hier aber erst einmal die erforderlichen Einstellungen für einen Betrieb im "Low-speed data communication Mode":
| 1. Einstellung GPS SELECT: "OFF" (
anwählbar über: MENÜ > GPS > GPS Set > GPS
Select ) |
| 2. Einstellung GPS OUT: "OFF" ( anwählbar über: MENÜ > GPS > GPSSet > GPS Out ) |
| 3. Einstellung GPS TX MODE: "OFF" ( anwählbar über: MENÜ > GPS > TX Mode ) |
LINKLISTE
Siehe
auch ein ähnliches Projekt, bei dem es um die Auswertung der
von APRS-Geräten bereitgestellten Navigationsdaten geht: http://www.kh-gps.de/wpl2kiss.htm
[1] http://aprsdroid.org/
[2] http://aprsdroid.org/download/
[3] http://aprsdroid.org/osm/
[4] http://twitter.com/aprsdroid
[5] https://github.com/ge0rg/aprsdroid/wiki
[6] https://github.com/ge0rg/aprsdroid/issues/12
[7] http://www.kh-gps.de/aprsdroid.pdf
[8] http://www.kh-gps.de/btm222.htm
[1] http://aprsdroid.org/
[2] http://aprsdroid.org/download/
[3] http://aprsdroid.org/osm/
[4] http://twitter.com/aprsdroid
[5] https://github.com/ge0rg/aprsdroid/wiki
[6] https://github.com/ge0rg/aprsdroid/issues/12
[7] http://www.kh-gps.de/aprsdroid.pdf
[8] http://www.kh-gps.de/btm222.htm
[9] http://www.youtube.com/watch?v=UWkh-7unMlg
[10] http://www.youtube.com/watch?v=MAO3rGFf-Gs
[11] http://www.androlib.com/android.application.org-aprsdroid-app-xEtFt.aspx
[12] http://ok1djo.howto.cz/wordpress/?p=44
[13] http://vk7hse.hobby-site.org/blog/2011/11/tinytrak4-bluetooth/
[14] http://translate.google.com/translate?hl=en&sl=de&tl=en&u=http%3A%2F%2Fwww.kh-gps.de%2Fser2bt.htm ( english translation by google )
[15] http://www.aprs-is.net/DPRSCalc.aspx
[16] http://shop.ulrichradig.de/Leiterplatten/BTM222-Dongle-LP.html
[17] http://www.watterott.com/de/Arduino?x17283=10944eced33fc473d69dc5c88ab737ac
[10] http://www.youtube.com/watch?v=MAO3rGFf-Gs
[11] http://www.androlib.com/android.application.org-aprsdroid-app-xEtFt.aspx
[12] http://ok1djo.howto.cz/wordpress/?p=44
[13] http://vk7hse.hobby-site.org/blog/2011/11/tinytrak4-bluetooth/
[14] http://translate.google.com/translate?hl=en&sl=de&tl=en&u=http%3A%2F%2Fwww.kh-gps.de%2Fser2bt.htm ( english translation by google )
[15] http://www.aprs-is.net/DPRSCalc.aspx
[16] http://shop.ulrichradig.de/Leiterplatten/BTM222-Dongle-LP.html
[17] http://www.watterott.com/de/Arduino?x17283=10944eced33fc473d69dc5c88ab737ac
"APRSDROID"
VORTRAG UND VIDEO
| Nach
erster
Berührung mit "APRSDROID" entstand im Sommer 2011 ein
Vortrag, dessen Folien hier : http://www.kh-gps.de/aprsdroid.pdf eingesehen werden können. Das Video eines Vortrags von John Hansen, W2FS, in dem auch das Programm "APRSDROID" erwähnt wird und das er auf der DCC 2011 gehalten hat, ist hier zu sehen: http://www.youtube.com/watch?v=MAO3rGFf-Gs |
E-Mail contact via:
