"D2A-DECODER"
Decoder wandelt D-STAR-Navigationsdaten 
zur Auswertung mit z.B. UI-VIEW oder APRSDROID
Stand: 22. April 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%2Fd2a.htm
BTW: better translations would be appreciated

ACHTUNG:  Hinweise zur Verwendung von Platinen der ersten Serie finden sich hier: http://www.kh-gps.de/d2a_alt.htm  


Abb. 1  Musteraufbau der Anordnung zur Auswertung von D-STAR-Navigationsdaten mithilfe von APRSDROID
PS: Im Bild ist noch die ursprüngliche Version des D2A-Boards zu sehen.

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 Auswertbarkeit unter APRSDROID zu ermöglichen. Dazu sollte eine geeignete BASCOM-Firmware unter Verwendung eines ATMEGA8-Prozessors verwendet werden.  Das Hardwareschaltbild des entsprechend realisierten Protokoll-Converters zeigt Abb.3., während die zugehörige Firmware ( HEX-File ) demnächst auf dieser Seite bereitgestellt werden wird. 


Abb. 3   D2A-Decoder zur Wandlung von NMEA-/GPS-A-Protokollen in das APRS-Kiss-Format

Ü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. Dabei zeigte es sich, dass von den ICOM-Geräten nur dann Ausgangssignale bereitgestellt wurden, wenn auch am Dateneingang ein RS-232-Ruhepegel ( ca. -5 bis -15V ) angelegt wurde. Das ist z.B. automatisch der Fall, wenn hier auch noch eine GPS-Maus mit seriellem RS-232-Ausgang angeschlossen ist. Wird ein solches Signal hier nicht zugeführt, so kann die benötigte Spannung auch vom RS232-Ausgang "U1", Pin 7 abgenommen werden. Pegelwandler "U1" setzt die Eingangssignale auf den zur Steuerung des Atmega-Prozessors "U2" benötigten TTL-Pegel um.
Die Brücken "JP1" und "JP2" ermöglichen das Herstellen besonderer Betriebszustände für den Testbetrieb, wobei "JP1" für den Normalbetrieb geöffnet bleibt, während "JP2" zu schliessen ist.
Zur Anpassung an das jeweils benutzte Funkgerät kann via Schalter "S1" zwischen den Eingangsdatenraten 9600bps ( S1: "offen" ) und 4800bps ( S1: "geschlossen" ) gewählt werden.
Ü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 den wichtigsten der 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 ).
Während Diode "LED1" nach jeder erfolgreichen Protokolleinlesung einmal kurz aufleuchtet, signalisiert "LED2" solche Datensätze, die den Prüfsummencheck nicht bestanden haben.
Die vom Prozessor an seinem Pin3 mit 19200bps bereitgestellten Ausgangsdaten werden einem Bluetoothmodul "BTM-222" [8] zugeführt. Dabei ist die Brücke "JP3" geschlossen und "JP4" geöffnet zu halten. Bei einer eventuell einmal erforderlich werdenden Änderung der Konfigurationseinstellungen des Bluetooth-Moduls besteht aber die Möglichkeit, Brücke "J3" aufzutrennen und damit die Verbindung vom Prozessorausgang zu unterbrechen. Da im vorliegenden Fall mit den werksseitig bereits voreingestellten ( Default- ) Parametern ( Slave-Mode und Baudrate: 19200bps ) gearbeitet wird, sind irgendwelche Einstellungsänderungen am Funkmodul aber normalerweise nicht erforderlich.
Im Grundmenü des ANDROID-Gerätes ist allerdings einmalig eine Paarung mit dem BT-Modul herzustellen. Nach einem Suchlauf erscheint es dort unter dem defaultmäßigen Namen "Serial Adapter" und sollte anschliessend auch im entsprechenden Menü von APRSDROID gelistet sein. Nach seiner Anwahl erlaubt es den späteren BT-Verbindungsaufbau. Das erfolgt allerdings erst, wenn unter APRSDROID auch die Tracking-Funktion aktiviert wurde ( siehe weiter unten ).
Zur Signalisation dieses Zustandes wird "LED4", die bis dahin nur ständig blinkte, anschliessend dauerhaft leuchten und ist somit ein wichtiger Indikator für die Kontrolle der Bluetoothverbindung. "LED3" wird dagegen immer nur während des Eintreffens von Daten kurz aufleuchten und ist nach inzwischen gewonnenen Erfahrungen auch verzichtbar.
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. ICP-Anschluss ermöglicht ein sogenanntes "In Circuit Programming" des eingesetzten Prozessors


Abb. 4   Datenanschluss von ICOM-D-STAR-Geräten

Wenn Positionsdaten empfangener Stationen auch auf  Karten dargestellt werden sollten, war dazu bei früheren Programmversionen von APRSDROID immer auch eine Internetverbindung erforderlich,  Dabei wurde auf das von GOOGLE bereitgestellte Kartenmaterial zurückgegriffen. Alternativ hierzu gibt es aber auch eine Versionen von APRSDROID, bei der 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: zoombare OSM-Karte                     Abb.9 Kartenanzeige nach Aufruf von http://www.aprs.fi

Durch weiteres Berühren des oberen Fensters lässt sich der hinter jedem Eintrag abgelegte Standort auch auf einer z.B. OSM-Karte visualisieren ( Abb.8 ) oder wenn eine Online-Verbindung besteht auch die entsprechende Seite von www.aprs.fi aufrufen ( Abb.9 ). Dabei sind weitgehende Zoommöglichkeiten möglich so dass sich z.B. auch in Fahrt befindliche Mobilstation 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" ( betrieben im KISS-Mode ) zum Einsatz kommen. Wird der D2A-Decoder in der unten noch näher zu beschreibenden Version mit ARDUINO-Boards aufgebaut, dann ist eine Verbindung zwischen PC und Decoder besonders einfach via USB realisierbar. Ansonsten bleibt noch die Möglichkeit der Nutzung von Bluetooth-Funk. Manche PC's sind dazu bereits von Haus aus mit einer Bluetooth-Funktionalität ausgerüstet. Alternativ lässt sich aber auch ein über eine 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 das  BTM-222-Modul unseres D2A-Decoders erkannt werden und den Aufbau einer seriellen Verbindung gestatten. Eventuell 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    Musteraufbau unter Verwendung des überarbeiteten Platinenlayouts
( Abbildungen zur Darstellung in Originalgrösse anklicken
)


Abb. 13 Platinenlayout
WICHTIG: Zuerst müssen die Drahtbrücken unterhalb des ATMEGA-Prozessors und des 6pol. ICP-Wannensteckers installiert werden.

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 [18].
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 Softwareplattform 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 "JAVA", 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.




Abb. 14 und 15 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.14 und 15 ) abgedeckt werden. Was noch fehlt ist auf dem aufsteckbaren "Proto Shield" unterzubringen. Das Schaltbild der zusätzlich benötigten Komponenten zeigt Abb. 16.  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. 16  Shield-Zusatzbeschaltung für den D2A-Decoder

Abb.17 zeigt ein Muster dieser Decoderversion. 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],[17]. Die dabei zu verwendende Beschaltung kann hier eingesehen werden.


Abb. 17  D2A-Decoder mit ARDUINO-Boards in der geöffneten ARDUINO-Box

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.:
Wird zur Übertragung von Daten unterschiedlicher Icon-Symbole der in Tabelle1 erwähnte Buchstabencode genutzt, so ist dieser im Anschluss an das Komma vierstellig ( einschliesslich angefügter Leerstellen ) einzufügen ( siehe Tabelle 2 ).

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:



NACHBAU

Das HEX-File der in den ATMEGA8-Prozessor gemäss Abb.3 zu ladenden Firmware kann hier heruntergeladen werden. Wer sich für das File der ARDUINO-Hardwareversion mit dem ATMEGA328P interessiert, der sollte mir eine E-Mail schicken ( Adresse siehe unten ). Ansonsten sind auf privater Basis und in begrenztem Umfang auch Platinen ( gem. Abb. 11-13 ), sowie programmierte Prozessoren erhältlich. Standardbauteile, sowie unprogrammierte ATMEGA-Prozessoren, Quarze und auch die 3.3V-Spannungsregler "TS2950 CT33" gibt es z.B. bei Fa. Reichelt. Eine mögliche Bezugsquelle für die verwendeten BLUETOOTH-Moduln BTM-222 ist hier genannt: [19]

WICHTIG für die Platinenbestückung:
Zuerst müssen die Drahtbrücken unterhalb des ATMEGA-Prozessors und des 6pol. ICP-Wannensteckers installiert werden ( siehe Abb.13).


LINKLISTE

Siehe zum Thema: D-Star Reflectoren und DTMF-Steuerung auch: http://www.kh-gps.de/dtmf2d.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.ulrichradig.de/home/index.php/projekte/bluetooth-dongle-fuer-den-mikrocontroller 
[18] http://www.watterott.com/de/Arduino?x17283=10944eced33fc473d69dc5c88ab737ac
[19] http://rf-store.com/index.php?pv=store&cat=BLUETOOTH

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