"D2A-DECODER"
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 radios
Here 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.

Glücklicherweise entwickelt Georg, DO1GL sein Programm nun aber offenbar doch weiter. So entdeckte ich unlängst eine neu hinzugekommene Verbindungsmöglichkeit. Dabei handelt es sich um die Zusammenschaltbarkeit auch mit TNC's. Hierbei war der KISS-Modus zu benutzen und die Adaption hatte über eine Bluetoothverbindung zu erfolgen. Damit ergaben sich neue Möglichkeiten der APRSDROID-Nutzung und das ohne den Zwang zur unbedingten Verwendung öffentlicher Mobilfunknetze samt teurer Daten-Flatrate. Stattdessen konnte mit dem Programm nun auch wieder klassischer Amateurfunkbetrieb durchgeführt werden! Eingeschränkt ist das Ganze allerdings dadurch, dass bluetoothtaugliche TNC's nahezu völlig vom internationalen Markt verschwunden sind. Alternativ lassen sich aber auch kisstaugliche TNC's, wie z.B. TinyTak4 und TNC-X, mithilfe eines externen Adapters zu einer bluetooothtauglichen Anordnung erweitern. Mich interessierte an der ganzen Sache aber sowieso ein anderer Aspekt. Es ging mir hierbei um den vom APRSDROID-Programm benutzten Protokolltyp "APRS-KISS". Dabei wurde die Idee geboren, die von D-STAR-Geräten an ihrer seriellen Datenschnittstelle bereitgestellten, von empfangenen Stationen stammenden und  im NMEA- oder GPS-A-Format übertragenen Navigationsdaten nach "KISS" zu wandeln, um damit auch eine Nutzbarkeit unter APRSDROID zu ermöglichen. Dazu sollte eine geeignete BASCOM-Firmware unter Verwendung eines ATMEGA8-Prozessors verwendet werden. Das Hardwareschaltbild des daraufhin realisierten Protokoll-Converters zeigt Abb.3.


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


  VERWENDUNG DES D2A-DECODERS
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

PLATINE FÜR DEN AUFBAU EINES D2A-DECODERS

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.

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.

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.

ICOM "ID-31A/E"
Menüeinstellungen zur Nutzung empfangener Navigationdaten
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":

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 )     

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:



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
[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

"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: