"D2A-DECODER"
Decoder wandelt D-STAR-Navigationsdaten zur Auswertung mit z.B.
UI-VIEW oder APRSDROID
Stand: 26.
März 2012
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
"APRSDROID"
VORTRAG UND VIDEO
E-Mail
contact via: