Probleme und Lösungen beim RandMcNally Streetfinder GPS für PalmIII:

Ein bißchen Werbung mag gestattet sein ...
 

Der RandMcNally Streetfinder für PalmIII war das erste kommerziell erhältliche Ansteck-GPS-Modul für Palms, ich habe es zum ersten Mal auf der Cebit 2000 gesehen. Leider kam zeitgleich der PalmIIIc heraus, der wegen seines längeren Gehäuses mechanisch nicht mehr an den Streetfinder passte. Damit war das Gerät mehr oder weniger sofort ein Auslaufmodell und kam in Deutschland eigentlich nie richtig in den Handel.

Vor einiger Zeit dann gab es vom Hersteller neue Empfänger, die mit allen Palms kompatibel sein sollten, und RandMcNally hat eine Zeit lang die Streetfinder Empfänger für PalmIII und PalmV (baugleich Magellan PalmV Companion) sehr billig als Restposten verkauft.
Darüber sind auch viele Geräte nach Deutschland gelangt und kommen jetzt hier zum Einsatz.

RandMcNally hat den Streetfinder in Verbindung mit der Streetfinder Deluxe 2000 Kartensoftware verkauft, die aber nur US Kartenmaterial enthält und auch nicht durch anderes Kartenmaterial erweitert werden kann.

Der Streetfinder liefert NMEA Daten an den Palm und ist somit prinzipiell mit jeder GPS Software für den Palm kompatibel.
Das im Streetfinder verwendete ZODIAC/Jupiter OEM Board (Rockwell/Conexant) ist sogar ausgeprochen umfangreich mit Konfigurationsmöglichkeiten ausgestattet.

Ich bin in der Vergangenheit immer wieder per Email auf Probleme mit dem Streetfinder angesprochen worden, und daher habe ich mich entschlossen, die mir bekannten Facts mal hier auf dieser Seite zusammen zu fassen. Diese Probleme treten ausschließlich mit dem Streetfinder für den PalmIII auf, der Streetfinder für den PalmV (baugleich Magellan PalmV Companion) verwendet einen ganz anderen GPS Chipsatz und hat nach meinem derzeitigen Wissensstand keine derartigen Probleme. Aber auch der Companion/Streetfinder V hat (wie jeder GPS Empfänger) natürlich prinzipiell mit dem Kaltstartproblem zu tun, wenn er längere Zeit nicht mehr benutzt worden ist oder die Batterien längere Zeit leer waren. Auch dann kann es sehr lange dauern, bis der Empfänger eine erste Position ermittelt. Da muss man einfach Geduld haben.

' Mein Streetfinder geht nicht mehr!'

Leider kommt es offensichtlich öfters vor, daß der Streetfinder in einen scheinbar merkwürdigen Zustand gerät und einfach nicht mehr funktionieren will. Hierfür kann es mehrere Gründe geben. Um zuverlässig herauszufinden, worin das Problem liegt, muß man sich etwas Zeit nehmen und diszipliniert alle Möglichkeiten durchspielen.Außerdem lernt man nebenher einiges über die Funktion des GPS Systems.



Das Init Problem:

In der Mehrzahl der Fälle ist das Problem darauf zurückzuführen, daß der Benutzer über die Software DigiMap oder PowerRoute den Menüpunkt 'GPS Init' ausgeführt hat. Das führt dazu, daß der Palm einen Konfigurationsstring an den Empfänger sendet, der ihn instruiert, nur noch $GPRMC und $GPGSV msgs auszusenden. Viele GPS Programme funktionieren damit aber nicht mehr.
Ich habe Harald Körtge dieses Problem mitgeteilt und gehe davon aus, daß er das in zukünftigen DigiMap Versionen ändert.

Der Empfänger ist also keinesfalls dann defekt, sondern muss lediglich wieder auf den vollen msg Satz zurückkonfiguriert werden. Das geht über NMEA Initmsgs, die in der Rockwell/CONEXANT 'Zodiac Serial Data Interface' Spezifikation dokumentiert sind.
Hierfür gibt es allerdings zur Zeit keine einfache Palm Software, man muß die Initstrings manuell über ein sog. Terminal Programm an den Empfänger schicken. Ich benutze dafür TermPilot, aber auch alle anderen Terminalprogramme für den Palm sollten funktionieren. Wichtig ist, daß das Terminal auf die richtigen Betriebsparameter konfiguriert wird. Das ist 4800,8,N,1, kein Xoff/XOn, kein RTS/CTS/Hardwarehandshake, <Return> muß CR+LF senden.

Nachfolgend wird das Problem und die Lösung detailliert beschrieben, am besten installiert man GPSPilot Compass ( http://www.gpspilot.com ), und ein Terminal (z.B. TermPilot) auf dem Palm und setzt sich mit dem Streetfinder in freies Gelände. Falls man Schwierigkeiten mit dem Akku vermutet, testet man das Ganze im Auto und versorgt den Streetfinder aus dem KFZ-Netz.

Zunächst mal sollte man sicherstellen, daß der Empfänger überhaupt funktioniert, also keinen Hardwaredefekt hat. Dafür benutzt man ein Terminalprogramm, z.B. TermPilot. Nach der oben geschilderten Konfiguration auf 4800,8,N,1 sollte nach dem Öffnen der Schnittstelle ('Online'/'Dial'/'LogIn') sowas in der Art hier auf dem Display erscheinen (die genauen Zahlen sind nicht so wichtig, nur das Muster, bzw. daß überhaupt etwas erscheint):

$GPRMC,000022,V,3648.4541,S,17444.4931,E,0.000,0.0,290697,19.5,E*42
$PRWIZCH,16,0,16,0,16,0,17,0,16,0,17,0,16,0,16,0,17,0,16,0,16,0,16,0*4C
$GPGGA,,,,,,0,00,,,,,,,*66
$GPGSA,,,,,,*42
...

Wie man sieht, enthält jede Zeile einen sog. NMEA msg identifier, z.B. $GPRMC, und dahinter Position und andere Daten.
Erscheint im Terminal garnichts, ist der Empfänger defekt oder der Akku leer. Dann sollte man noch versuchen, den Empfänger über das Netzteil oder den 12V KFZ Adapter in Betrieb zu nehmen, eventuell ist nur der Akku oder die Ladeelektronik defekt.

Im Auslieferungszustand liefert der Streetfinder solche NMEA Strings an den Palm bzw. die GPS Anwendung (zur Deutung kann man sich meine NMEA FAQ anschauen):

Ohne gültigen GPS Fix, also direkt nach dem Einschalten:

$GPRMC,000022,V,3648.4541,S,17444.4931,E,0.000,0.0,290697,19.5,E*42
$PRWIZCH,16,0,16,0,16,0,17,0,16,0,17,0,16,0,16,0,17,0,16,0,16,0,16,0*4C
$GPGGA,,,,,,0,00,,,,,,,*66
$GPGSA,,,,,,*42
$GPRMC,000023,V,3648.4541,S,17444.4931,E,0.000,0.0,290697,19.5,E*43
$PRWIZCH,16,0,16,0,16,0,17,0,16,0,17,0,16,0,16,0,17,0,16,0,16,0,16,0*4C
$GPGGA,,,,,,0,00,,,,,,,*66
$GPGSA,,,,,,*42
...

Mit gültigem GPS Fix:

$GPGSA,A,3,06,25,24,30,05,17,,,,,,,1.65,1.02,1.30*06
$GPGSV,3,1,12,06,86,135,41,30,56,108,41,25,51,280,35,24,21,040,34*77
$GPGSV,3,2,12,05,20,111,39,17,17,170,38,22,11,291,00,29,07,239,00*74
$GPGSV,3,3,12,01,07,339,00,10,06,084,33,15,04,183,33,14,03,226,00*74
$GPRMC,133925,A,5058.7486,N,00647.0651,E,0.000,0.0,080102,0.6,W*64
$GPGGA,133926,5058.7486,N,00647.0651,E,1,06,1.02,72.5,M,47.6,M,,*4C
$GPGSA,A,3,06,25,24,30,05,17,,,,,,,1.65,1.02,1.30*06
...

Wählt man in DigiMap oder PowerRoute 'GPS Init', dann schickt der Palm folgende Inits an den Empfänger:

$PRWIINIT,V,,,,,,,,,,,T,132338,080102
$PRWIILOG,???,V,,,
$PRWIILOG,RMC,A,T,1,0
$PRWIILOG,GSV,A,T,1,0

Das erste initialisiert Datum, Uhrzeit (und ggfs. Position), und ist nützlich für einen schnelleren ersten Positions-Fix beim Receiver Kaltstart.
Die nächsten $PRWIILOG Strings schalten aber alle NMEA msgs außer $GPRMC und $GPGSV ab!
Mit RMC/GSV only Initialisierung durch DigiMap oder PowerRoute zeigt der Empfänger aber nur noch:

$GPRMC,235948,V,5058.7435,N,00647.0557,E,0.000,0.0,280697,1.0,W*7E
$GPRMC,235949,V,5058.7435,N,00647.0557,E,0.000,0.0,280697,1.0,W*7F
$GPRMC,235950,V,5058.7435,N,00647.0557,E,0.000,0.0,280697,1.0,W*77
...

oder

$GPRMC,144949,V,5058.7824,N,00647.1505,E,0.000,0.0,080102,0.6,W*7E
$GPGSV,3,1,10,06,57,071,41,17,49,161,39,25,42,233,35,22,41,297,*76
$GPGSV,3,2,10,15,36,181,40,30,25,126,39,10,19,056,33,01,09,312,*7D
$GPGSV,3,3,10,13,05,344,00,03,04,257,00*7B
$GPRMC,144950,V,5058.7826,N,00647.1505,E,0.000,0.0,080102,0.6,W*74
...

Viele GPS Programme werten aber die $GPGSA und $GPGGA msgtypes aus und funktionieren dann nicht mehr.
Ich habe Harald Körtge dieses Problem mitgeteilt und gehe davon aus, daß er das in zukünftigen DigiMap Versionen ändert.

Abhilfe:
Zeigt der Streetfinder nach dem Einschalten nur $GPRMC msgs an, sollte man zunächst einmal abwarten, bis der Empfänger eine gültige GPS Position ermittelt hat. Siehe dazu auch weiter unten den Abschnitt zur Initialisierung. Man kann durchaus auch noch einmal den Punkt 'GPS Init' in DigiMap oder PowerRoute verwenden, weil der Empfänger so ggfs. auch eine richtige Uhrzeit und Datum verpasst bekommt., was die Zeit bis zum ersten Fix reduzieren sollte. Danach sollte man aber die Finger davon lassen!

Normalerweise sollten spätestens nach Ermittlung einer Position (das 'V' in der $GPRMC message wechselt zu 'A') auomatisch die $GPGSV, $GPGGA, etc. msgs erscheinen. Passiert dies nicht, sind offenbar die anderen NMEA msgs wie oben beschrieben deaktiviert worden. Man kann die verschiedenen msgtypes einzeln wieder reaktivieren, indem man mit einem Terminalprogramm Initsequenzen an den Empfänger schickt.
Die vollständige Erklärung kann man der ZODIAC Serial Data Spec entnehmen, ich gebe hier nur die nötigen Strings wieder. Vereinfacht gesagt schaltet jeder dieser Inits die im String bezeichnete msgtype auf sekündliche Ausgabe:

$PRWIILOG,GGA,A,T,1,0
$PRWIILOG,GSV,A,T,1,0
$PRWIILOG,GSA,A,T,1,0
$PRWIILOG,RMC,A,T,1,0

Jede Zeile muß mit CR+LF abgeschlossen werden (kann z.B. in TermPilot für das RETURN Verhalten konfiguriert werden). Ohne CR+LF werden die Inits nicht übernommen und es ändert sich nichts.
Hat der Empfänger bereits einen gültigen Fix, tauchen nach diesen Initstrings sofort die zusätzlichen msgtypes auf. Man kann dann sofort zu seiner bevorzugten GPS Software wechseln und prüfen, ob sie jetzt funktioniert.
Mit allen aktivierten NMEA msgs wie oben beschrieben funktioniert übrigens die Software für den PalmV GPS Companion von Magellan (Downloadbereich bei hhtp://www.magellangps.com) hervorragend auch mit dem Streetfinder III - und sie ist kostenlos (solange bis jemand bei Magellan es bemerkt, fürchte ich ...). Die Initfunktion der Companion Software funktioniert allerdings leider nicht mit dem Streetfinder III, die ist wohl speziell auf den Magellan Chipsatz zugeschnitten, auch stimmt die Akkuanzeige nicht, aber beides kann man wohl verkraften.

TIP: Will man seiner GPS Software etwas Mühe beim Dekodieren der GPS Daten ersparen, kann man mit den beschrieben Inits auch gezielt nur die msgtypes aktivieren, die die betreffende Software auswertet, oder man schaltet nicht benötigte msgtypes auf ein etwas längeres Intervall, z.B. 5 Sekunden.



Das Problem mit der Uhr:

Ein weiteres Problem ist, daß offensichtlich einige oder alle Streetfinder Probleme mit dem Erhalt der Uhrzeit bzw. des Datums haben. Alle mir bekannten Streetfinder starten nach dem Einschalten mit einem Datum im Jahr 1997, während der Empfänger die letzte gültige Position (ist an der RMC msg erkennbar) durchaus gespeichert hat. Manche Empfänger zeigen auch schonmal ein Datum im Jahr 2021 an.
Eine einigermaßen korrekte Uhrzeit und Datum (das Datum ist wichtiger) ist bei allen GPS Empfängern nötig, um nach dem Einschalten eine erste Schätzung der Satellitenpositionen auf Basis der sog. Almanachdaten vornehmen zu können. Bei falschem Datum stimmen die Almanach Daten nicht mit der tatsächlichen Konstellation überein, der Empfänger sucht sich tot, und die Zeit bis zu einer ersten Positionsausgabe kann dann sehr lange dauern, durchaus im Bereich 30-60min, je nach Umständen. In einem bewegten Fahrzeug kann ein Kaltstart noch längern dauern, weil sich durch die ständige Standortänderung des Empfängers ständig neue Konstellationen ergeben, teilweise eingelesene Almanachdaten verworfen und neu gesucht werden müssen, etc. pp.
Wer sich darüber nicht bewusst ist, keine weiteren Hintergrundinformationen zu diesem Problem hat und keine zusätzlichen Tools zur Analyse einsetzen kann, denkt natürlich zuerst an einen Defekt, wenn z.B. DigiMap nach 10-20 Minuten immer noch keine Position anzeigt. Man checkt sinnvollerweise zuerst mal wie oben beschrieben mit einem Terminalprogramm, ob der Streetfinder überhaupt Daten liefert. Am besten schließt man den Streetfinder dann an eine externe 12V Versorgung an, befestigt ihn an einem Fenster mit brauchbarer Himmelssicht, und lässt ihn mal eine Stunde unbeaufsichtigt laufen.
In den meisten Fällen dürfte er auch ohne weitere Initialisierungsmaßnahmen nach dieser Zeit eine Position ermittelt und seine Almanachdaten aktualisiert haben.

Diese Zeit kann verkürzt werden, wenn man dem Empfänger Uhrzeit und aktuelle Position per Initialisierung mitteilt. Genau dafür ist eigentlich der Punkt 'GPS Init' in PowerRoute/DigiMap vorgesehen.Auch die Software 'GPS Pilot Compass' (http://www.gpspilot.com) hat eine solche Initialisierungsoption (hierfür wählt man einen zuvor abgelegten Punkt aus der Points Datenbank aus). Allerdings scheint diese in den mir bekannten Versionen nicht immer mit dem Streetfinder III zu funktionieren - unmittelbar nach der Inistialisierung zeigt der Empfänger jedenfalls öfters falsche Startkoordinaten an, lediglich Datum und Uhrzeit scheinen korrekt gesetzt zu sein. Mit falschen Startkoordinaten hilft das aber wenig. Am besten legt man, wenn der Empfänger einmal eine korrekte Position ermittelt hat, einen neuen Personal Point mit der aktuellen Position in der COMPASS Datenbank ab. Damit kann man dann den Empfänger immer wieder initialisieren. In der Regel reicht es, wenn man zur Initialisierung eine Koordinate innerhalb von Deutschland verwendet. Je genauer die tatsächliche Position mit der Initposition übereinstimmt, desto schneller erhält der Empfänger einen Fix.

Alles in allem ist das Initialisierungsverhalten der Streetfinder offensichtlich nicht ganz reproduzierbar, womöglich gibt es da auch Serienstreuungen.
Da die Streetfinder die letzte ermittelte Position speichern, sollte es für eine Schnellinitialisierung eigentlich reichen,  Uhrzeit und Datum im Empfänger zu setzen, der Einfachheit halber auf die gerade im Palm gültigen Daten ( abzüglich Zeitzonenoffset, also in Deutschland -1h bzw -2h bei Sommerzeit). Die GPS UTC entspricht vereinfacht gesagt GMT.

TIP: Bei externer Versorgung schaltet sich der Streetfinder nicht autmatisch beim Schließen der Schnittstelle, Beenden der GPS Anwendung, oder Entnehmen des Palms ab wie beim Akkubetrieb, sondern läuft einfach weiter. Dies kann man sich z.B. im Auto zunutze machen, indem man den Streetfinder dauerhaft mit der KFZ Versorgung verbindet. Dadurch hat der Empfänger ständig gültige Positionsdaten (soweit die Empfangsbedingungen das zulassen), ein Init ist nicht nötig, und man kann nach dem Anstecken des Palms sofort mit einer gültigen GPS Position starten.



Carsten Kurz, Januar 2002