Arne Johannessen wrote:
> Ulrich G. Kliegis said:
>>
>> Solange kein Client muckt, laß ich das Ding erstmal arbeiten.
>
> Mein steinaltes Magellan NAV 5000 hatte das gleiche Problem, lieferte
> aber trotzdem bis zum Ende eine einwandfreie Position.
Gucken wir doch a) in die Geometrie, b) in die NMEA-Datenformate:
Die Positionsbestimmung benötigt Zeitdifferenzen, die in Entfernunungs-
differenzen umgerechnet werden und dann (eigentlich - meist wird ein
iteratives Verfahren angewendet) Schnittmengen von Rotationshyperboloiden
berechnen.
Ein konstanter Offset der Zeit bei allen Beteiligten (in diesem Falle:
allen Satelliten durch die Kodierung und der internen Darstellung im
Empfänger) ist da unschädlich. Setzt natürlich voraus, dass die Satelliten
alle Zeitinformationen mit diesem Offset versehen, z.B. die für deren
Positionsberechnung nötigen Bahndaten.
Es käme Empfängerseitig also nur darauf an, die berechnete Zeit für die
Anzeige mit einem passenden Offset zu versehen. Die Firmwareversion wird
z.B. ein Wertefenster definieren - 0 <= Zeitcode <= nnn: nach dem
bekannten Datum des Nulldurchgangs, nnn < Zeitcode < 1024 : vorher.
Das muss nicht mit N == 0 / 1024 Wochen übereinstimmen, kann es
sinnvollerweise auch nicht, wenn es erst beim Kunden im Einsatz als
Firmwareupdate eingespielt wird. (Praktisch also "vor Erstellungszeitpunkt
der Firmware: 1024 Wochen addieren, denn das Gerät wird kaum in der Zeit
rückwärts reisen".)
Da es sich um ganze Wochen, also auch ganze Tage handelt, ist das
falsche Datum auch unerheblich für NMEA 0183-Telegramme - zumindest
GLL und GNS enthalten nur eine UTC ohne Datumsteil.
WIMRE, ist der Offset zwischen GPS-Atomuhrzeit und UTC-Sekunden doch
im Satellitensignal explizit kodiert?
-is
--
A medium apple... weighs 182 grams, yields 95 kcal, and contains no
caffeine, thus making it unsuitable for sysadmins. - Brian Kantor