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
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%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 APRSDROIDPS: 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.
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.
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.
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"
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
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.
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 ).
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.
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 ) |
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).
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
[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
[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:
