mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik GPS week rollover


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Andreas M. (andreas_m62)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Heute ist ja der Termin für das GPS week rollover.
Dabei wird ein neues Datumsformat eingeführt.
Das kann bei verschiedenen Navigationssystemen
zu Fehlfunktionen führen.

Deshalb bietet zum Beispiel TomTom ein Softwareupdate
selbst für seine nicht mehr gesupporteden Geräte an.
Böse Zungen lästern schon, es wäre besser,
heute nicht mit dem Flugzeug zu fliegen.
Hat schon jemand Auswirkungen auf die Funktionen der Navis
festgestellt?

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas M. schrieb:
> Heute ist ja der Termin für das GPS week rollover.
> Dabei wird ein neues Datumsformat eingeführt.

Ja und? Da schmeißt du zwei Dinge in einen Topf.
Wochenzählerüberlauf und GPS Modernisierung sind zwei verschiedene 
Dinge.

Warum betreffen die neuen Massagetypen die alten Empfänger?

Die neuen,  zusätzlichen Messagtypen CNAV und MNAV verwenden statt des 
alten 10 Bit Wochenzählers eine 13 Bit Wochenzähler - so weit, so gut. 
Für Empfänger, die den (bisherige) NAV Massagetyp verwenden, ändert sich 
erstmal gar nichts. Das neu Format ist für den operationellen Betrieb 
aber noch gar nicht freigegeben (Current Status: Pre-Operational) und es 
wird noch davon abgeraten, es für kritischen Anwendungen einzusetzen.
https://www.gps.gov/systems/gps/modernization/cnav/

Mit dem neuen Wochenzählerformat in den neuen Messagtypen ist das Week 
Rollover Thema allerdings nur verschoben, aber nicht gelöst. Statt grob 
alle 19.6 Jahre müssen die Empfänger dann alle 157 Jahre aufpassen.

> Das kann bei verschiedenen Navigationssystemen zu Fehlfunktionen führen.

Nur, wenn sie schlampig programmiert sind. Das Week-Rollover Thema ist 
seit der Entwicklung vom GPS in den 70er Jahren des vorigen Jahrhunderts 
bekannt und spezifiziert. Sobald der Empfänger ganz grob das Datum kennt 
(auf ein paar Jahre genau), kann er sich ausrechnen, in welchem 
Wochenzählerfenster er sich befindet. Bei Empfängern die den 21. August 
1999 gut überstanden haben, sind die Chancen ausgesprochen groß, dass es 
auch diesmal geklappt hat.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:

> Ja und? Da schmeißt du zwei Dinge in einen Topf.
> Wochenzählerüberlauf und GPS Modernisierung sind zwei verschiedene
> Dinge.

Im konkreten Fall nicht. Da wurde tatsächlich beides miteinander 
verknüpft. Der ohnehin anstehende wrap-around wurde zum Anlass genommen, 
den Wochenzähler von 10 auf 13 Bit zu erweitern.

Autor: Wegstaben V. (wegstabenverbuchsler)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
c-hater schrieb:
> Der ohnehin anstehende wrap-around wurde zum Anlass genommen,
> den Wochenzähler von 10 auf 13 Bit zu erweitern.

das mit den 10 bzw. 13 bit erinnert mich ein bischen an dem Gehampel mit 
Festplatten-Kapazitäten unter DOS bzw. Windows.

Wieso kann man denn da nicht gleich einen "gescheiten" Datentyp bzw. 
Datenbreite nehmen, z.B. 16 Bit?

Autor: Nikolaus S. (Firma: Golden Delicious Computers) (hns)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Wegstaben V. schrieb:
> c-hater schrieb:
>> Der ohnehin anstehende wrap-around wurde zum Anlass genommen,
>> den Wochenzähler von 10 auf 13 Bit zu erweitern.
>
> das mit den 10 bzw. 13 bit erinnert mich ein bischen an dem Gehampel mit
> Festplatten-Kapazitäten unter DOS bzw. Windows.
>
> Wieso kann man denn da nicht gleich einen "gescheiten" Datentyp bzw.
> Datenbreite nehmen, z.B. 16 Bit?

Die Antwort ist die gleiche wie auf diese Frage:

Warum hat Intel nicht gleich als erstes einen 64-Bit-Prozessor 
entwickelt (sondern den 4004)?

Autor: Michael M. (Firma: DO7TLA) (do7tla)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie sieht das bei Smartphones aus?
Müssen da die Hersteller auch Updates bereitstellen oder ist das bereits 
mit den Letzten Update integriert worden?

Autor: ic_cus (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wenn der GPS-Receiver nach ICD-200 korrekt implementiert wurde, darf es 
keine Probleme geben.

Autor: Wegstaben V. (wegstabenverbuchsler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nikolaus S. schrieb:
> Die Antwort ist die gleiche wie auf diese Frage:
>
> Warum hat Intel nicht gleich als erstes einen 64-Bit-Prozessor
> entwickelt (sondern den 4004)?

naja, "16 bit" ist ja nun keine exotische Größe bei Prozessoren, 
insbesondere bei (so vermute ich) recht hochperformanten Prozesoren oder 
Rechenwerken, welche für GPS verwendet werden. Da halte ich eher 10 oder 
13 bit für etwas exotischer, weil das erst mal maskiert werden muss.

Und das man bei GPS "von Anfang an" nicht wusste, dass das System länger 
als 19 Jahre in Betrieb sein wird, kann ich mir nicht vorstellen.

Welchen Mehr-Gewinn etc. an Robustheit bringt es denn rein, wenn man 
solche  Designs wählt, welche doch offensichtlich irgendwann in eine 
"Stress-Situation" kommen?

Selbst heute gibt es noch (neue!) Applikationen, welche nicht mit 
4-stelligen Jahreszahlen rechnen [*1] (oder zumindest darstellen), 
sondern dann lieber irgendwelche Offsets reinrechnen, und krude 
Rechen-Kuststückchen machen. Selbst Unix-Time ist heutzutage in der 
Lage, 64 Bit Zeitstempel zu verwenden, um nicht auf das "Jahr2038" 
Problem reinzufallen.

[*1] erklär mir jemand mal: Auf meinem Personalausweis ist das 
Gültigkeits-Datum 4-stellig, aber das Ausstellungs-Datum 2-stellig. 
WOZU?

Ich erwarte ja keine 5-stelligen Jahreszahlen, um jenseits vom Jahr 9999 
zu rechnen, 4-stellig sollte aber durchaus möglich sein. Wir haben 
heutzutage verflixt noch mal nicht das Jahr "19", sondern das Jahr 2019. 
Im Jahr 19 rannte Jesus noch in Badelatschen durch Jerusalem...

Das mit den "Festplatten" bei DOS/Windows bezog sich ja nicht nur auf 
der physikalischen Platten-Kapazität (CHS versus LBA-Adressierung), 
sondern auch auf der Dateisystem-Nutzung (FAT12, FAT16, FAT32, ...)

Dem Vernehmen nach ist das mit den Festplatten bei Apple direkt "von 
Anfang an" auf 16 bit (später 32 bit) Adressierung ausgelegt gewesen. In 
weiser Voraussicht, das es vielleicht doch mal etwas größere Platten 
gibt.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Wegstaben V. schrieb:
> naja, "16 bit" ist ja nun keine exotische Größe bei Prozessoren,

Nur ist die Datenübertragung bei GPS mit 50 Bits pro Sekunde nicht 
sonderlich schnell und einige Information wiederholen sich alle 30 
Sekunden. Bei solchen Randbedingungen neigt man möglicherweise zu 
Datensparsamkeit.

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Der ohnehin anstehende wrap-around wurde zum Anlass genommen,
> den Wochenzähler von 10 auf 13 Bit zu erweitern.

Der CNAV Datensatz mit dem 13 Bit Wochenzähler wird seit dem 28. April 
2014 ausgesendet. So neu ist das nun nicht.
http://archive.defense.gov/Releases/Release.aspx?ReleaseID=16666

Vielleicht hast du mal eine vernünftige Primärquelle.

Autor: ic_cus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wegstaben V. schrieb:
> Und das man bei GPS "von Anfang an" nicht wusste, dass das System länger
> als 19 Jahre in Betrieb sein wird, kann ich mir nicht vorstellen.

Die Datenübertragung ist beschränkt und die Festlegung einer Epoche mit 
~20 Jahren war wohl ein guter technischer Kompromiss damals. Das alles 
ist in der GPS Interface Spezifikation genau beschrieben und ein Wechsel 
der Epoche darf für einen Interface-konformen GPS-Receiver kein Problem 
darstellen. Der Epochen-Wechsel ist daher keine "Stress Situation", 
sondern schlicht und einfach Teil der normalen GPS-Spezifikation.

Stress Situation erzeugt der Rollover nur für schlecht implementierte 
Receiver.

Vergleiche dazu auch das Memorandum des us-amerikanischen Department for 
Homeland Security 
(https://ics-cert.us-cert.gov/sites/default/files/documents/Memorandum_on_GPS_2019.pdf)

> GPS devices with a poorly implemented GPS Time-to-UTC conversion algorithm > may 
provide incorrect UTC following a WN rollover.  Additionally, some GPS > devices 
that calculate the WN value from a device-specific date rather than > the start of 
the current GPS Time Epoch may provide incorrect UTC at some  > other 
device-specific date.

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wegstaben V. schrieb:
> Und das man bei GPS "von Anfang an" nicht wusste, dass das System länger
> als 19 Jahre in Betrieb sein wird, kann ich mir nicht vorstellen.

Jeder Mensch hat heutzutage immer irgendetwas Kalenderähnliches in 
Reichweite, um die aktuelle Jahreszahl ausreichend genau, i.e. auf +/-9 
Jahre, zu bestimmen. Selbst Dantès in seiner Zelle hätte das noch 
ausreichend genau hin bekommen.

Warum soll das GPS diese redundanten Daten dauernd an die Nutzer 
verbreiten.

Autor: Wolfgang S. (ws01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas M. schrieb:

> Hat schon jemand Auswirkungen auf die Funktionen der Navis
> festgestellt?

Ich habe keine erwartet und es sind auch keine sichtbar geworden. Man 
hat aber schon Pferde kotzen gesehen, vor der Apotheke, deswegen hatte 
ich meine Sammlung an Geräten heute morgen mal kurz eingeschaltet und 
nacheinander durchprobiert.

Das älteste noch funktionsfähige Navi hier ist ein Garmin 60 CSx, das 
ich Anfang 2008 kaufte und seither i.W. beim Radfahren benutzt habe, bis 
es dann Jahre später durch ein 64s ersetzt wurde und das 60CSx als 
Reserve - und wegen seiner teuren, verdongelten IGN-Karten - in den 
Schrank wanderte.

Beide Geräte fanden heute morgen nach dem Einschalten sofort einen Fix 
und zeigten das korrekte Datum und die korrekte Uhrzeit, das 64s wie zu 
erwarten schneller als das 60CSx.

Stichwort "kotzene Pferde":

https://blog.fosketts.net/2019/04/06/gps-time-rollover-failures-keep-happening-but-theyre-almost-done/

>I recently bought a 2008 Mercedes-Benz S-Class with just such a system. Around 
October 21, 2018, all models with Mercedes’ COMMAND NTG3 infotainment system 
decided it was actually June, 2003. And the incorrectly-converted GPS signal 
continues to reset the date accordingly at every opportunity. As of today, my car 
thinks it’s August 21, 2003.

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wolfgang S. schrieb:
> 
https://blog.fosketts.net/2019/04/06/gps-time-rollover-failures-keep-happening-but-theyre-almost-done/
>
>>I recently bought a 2008 Mercedes-Benz S-Class with just such a system.
> Around October 21, 2018, all models with Mercedes’ COMMAND NTG3
> infotainment system decided it was actually June, 2003.
> ...
Das ist wohl das Resultat einer ausgefeilten Qualitätskontrolle. ;-(
Sei froh, dass es kein MCAS ist, bei dem die FMEA des Herstellers und 
die Zulassungbehörde gnadenlos versagt haben.

Autor: Manfred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas M. schrieb:
> Heute ist ja der Termin für das GPS week rollover.

Mein Transonic-7000T (Navigon) hat 2007 nur 315 Euro gekostet. Dank 
pfiffiger Bastler ist da seit Jahren Navigon MN8 drauf, es hat heute 
nach Kaltstart klaglos seine Position gefunden. Die Uhrzeit stimmt, ob 
es irgendwo intern ein Datum hat, habe ich nicht gesucht.

Google nach "gps week rollover" findet jede Menge, die zum Großteil 
voneinandder abschreiben, z.B.:
https://www.netzwelt.de/gps/170367-gps-week-rollover-viele-navis-ab-heute-mehr-funktionieren.html

Auch diese komische Münchner Versicherung, die angeblich ein Club der 
Autofahrer sein will, hat Listen.

Was mein Auto von 2018 macht, werde ich Montag anschauen, laut Listen 
ist der Hersteller nicht betroffen.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael M. schrieb:
> Wie sieht das bei Smartphones aus?

Ein Nokia C5-00 von 2011, also noch nicht einmal ein Smartphone, hat 
ebenfalls keine Probleme.

: Bearbeitet durch User
Autor: Wegstaben V. (wegstabenverbuchsler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas M. schrieb:
> Deshalb bietet zum Beispiel TomTom ein Softwareupdate
> selbst für seine nicht mehr gesupporteden Geräte an.

wenn doch dieses week rollover eine "normale" Funktion auch von 
Altergeräten ist, wieso gibt es denn dann z.B. von TomTom ein 
Software-Update? Was ist dort in den TomTom Geräten nicht enthalten, was 
ein Update bedingt?

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gute Hersteller von Timinggeräten haben das schon vor langer Zeit 
erkannt und sind seit langem vorbereitet.

https://www.meinberg.de/german/faq/faq_47.htm
https://kb.meinbergglobal.com/kb/time_sync/gnss_systems/gps_week_number_rollover

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus schrieb:
> Gute Hersteller von Timinggeräten haben das schon vor langer Zeit
> erkannt und sind seit langem vorbereitet.

Wenn ein Hersteller die 1024 Wochen seit dem 21. August 1999 (letztes 
Week Rollover) nicht genutzt hat, um seine Software auf Vordermann zu 
bringen, kann ich das nur als Schlamperei bezeichnen.

GPS Empfänger, die damit nicht zurecht kommen, sollte man wegen 
verdeckter Mängel zurück geben.

Autor: Wollvieh W. (wollvieh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei mir ist jetzt mein Tomtom One von ca. 2007 abgekackt.

Zuletzt am Tag vor dem Rollover benutzt, dann am Tag danach. Ins Auto 
gestiegen, eingeschaltet, losgefahren. Nach ein paar 100m korrekte 
Position (braucht immer etwas der alte Gaul.) Nach 10 km Auto 
abgestellt, Navi ausgeschaltet. Eine Stunde später zurückgekommen, Navi 
eingeschaltet, "Warte auf GPS-Signal." Hat es bis zuhause gewartet. 
Reset und so brachte nichts.

Daheim aufgeschraubt, Akku raus, gewartet. Akku wieder rein, 
angeschaltet, auf den Balkon gelegt. Nach kurzer Zeit Position korrekt, 
Uhrzeit hat sich wieder gestellt. Auf einen Fußmarsch ausgeführt, alles 
gut, teilweise sogar die Gehgeschwindigkeit korrekt angezeigt (bei sehr 
geringen Geschwindigkeiten spinnt es gerne, weil es die wohl aufgrund 
der Glättung der Empfangsungenauigkeiten verschluckt.)

Am nächsten Tag wieder ins Auto gehängt, Anzeige 0:00 Uhr, "warte auf 
GPS-Signal." Laut Infoseite 0 Satelliten. Flach unter die 
Windschutzscheibe gelegt, nach 5 Stunden immer noch nichts und immer 
noch 0:00 Uhr. Wobei ich es für einen besseren Empfang wohl lieber aufs 
Display gelegt hätte.

Hat jemand eine Ahnung, was da spinnt? Es hat ja immerhin zweimal nach 
dem Rollover funktioniert, einmal wohl noch mit gecacheten Daten, aber 
beim 2. Mal von komplett stromlos.

Wie funktionieren diese sagenhaften Almanach-Daten (ist das der 
Sport-Almanach von "Zurück in die Zukunft?" ;)
Warum lügt mich das Ding an und sagt 0 Satelliten, obwohl sich an dem 
Auto und der Landschaft drumrum nichts geändert hat? Sind vielleicht 
gerade die falschen Satelliten am Firmament geprangt, von denen noch 
irgendwelche Daten fehlen? Aber nach 5 Stunden?

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wolfgang schrieb:
> GPS Empfänger, die damit nicht zurecht kommen, sollte man wegen
> verdeckter Mängel zurück geben.

Flugzeuge auch: "At least 15 Boeing 787 Dreamliners are grounded in 
China due to a glitch with the GPS system. A rollover of the week 
counting this weekend has led to a bug in the GPS system, and carriers 
are choosing not to fly until the fault is fixed."

https://simpleflying.com/boeing-787-china-grounding/

Ob es wohl nur die chinesischen Exemplare betrifft?

: Bearbeitet durch User
Autor: Norbert der Navigator (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wollvieh W. schrieb:
> Bei mir ist jetzt mein Tomtom One von ca. 2007 abgekackt.

> Hat jemand eine Ahnung, was da spinnt?

Obwohl mein TomTom (2008) schon lange nicht mehr bei mir weilt, schickt 
mir TomTom regelmäßig Emails. In der letzten war die Rede, daß das 
TomTom nicht mehr kompatibel sei und man sich nach neuer Hardware 
umschauen soll.

Autor: Andreas M. (andreas_m62)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Norbert der Navigator schrieb:
> Obwohl mein TomTom (2008) schon lange nicht mehr bei mir weilt, schickt
> mir TomTom regelmäßig Emails. In der letzten war die Rede, daß das
> TomTom nicht mehr kompatibel sei und man sich nach neuer Hardware
> umschauen soll.

Für ältere TomToms gibt es keine aktuellen Karten mehr zu kaufen.
Aber man kann es trotzdem weiter benutzen.
Die Map-Korrekturen werden noch übertragen,
wenn man das TomTom mit dem TomTom-Server verbindet.
Und das Quick-Fix für die Satelliten wird auch aktualisiert.
Das "week rollover update" habe ich so noch auf zwei alte
TT ONE IQ Route draufgedudelt bekommen.

Nur die Karten sind eben jetzt etwas älter.
Eine ist v825.xxxx und eine v835.xxxx.
Da fährt man ab und zu mal auf dem Display "über die Wiese".

Die neuen TomToms haben jetzt ein lebenslanges kostenloses Kartenupdate.
Schade, dass TomTom das Kartenmaterial für die älteren NAVIs
nicht mehr weiter supportet.
Man hätte wenigsten zum Schluß noch kostenlos eine letzte aktuelle Karte
gucken lassen können.

Autor: Harald W. (wilhelms)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wegstaben V. schrieb:

> Wieso kann man denn da nicht gleich einen "gescheiten" Datentyp bzw.
> Datenbreite nehmen, z.B. 16 Bit?

...und was macht man dann nach 5460 Jahren,
wenn dieser auch überläuft? :-)

Autor: Harald W. (wilhelms)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Udo S. (urschmitt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vieleicht hilft es ja jemand:

Mein Tomtom Start 25 hat sich gestern aufgehängt, als ich die Software 
aktualisieren wollte. Es hat sich nicht mal mehr mit dem Computer 
verbunden.

Erst nach einem Reset (Ein/Aus Taster 20-30sec. drücken bis Startton 
ertönt) hat es sich gefangen und ich konnte den Software-Update machen. 
Danach hat es funktioniert.

Autor: John (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Harald W. schrieb:
> ...und was macht man dann nach 5460 Jahren,
> wenn dieser auch überläuft? :-)

Nach 5460 Jahren wäre ein 16-Bit Wochenzähler bereits drei mal 
übergelaufen.
2^16 Wochen sind 1256 Jahre.

Autor: John (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
*vier mal

Autor: Harald W. (wilhelms)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
John schrieb:

>> ...und was macht man dann nach 5460 Jahren,
>> wenn dieser auch überläuft? :-)
>
> Nach 5460 Jahren wäre ein 16-Bit Wochenzähler bereits drei mal
> übergelaufen.
> 2^16 Wochen sind 1256 Jahre.

Gut, ich hatte schnell im Kopf gerechnet. Wahrscheinlich ist
dieser inzwischen feheranfälliger als ich geglaubt habe. :-)

Autor: Wollvieh W. (wollvieh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas M. schrieb:

> Für ältere TomToms gibt es keine aktuellen Karten mehr zu kaufen.
> Aber man kann es trotzdem weiter benutzen.
> Die Map-Korrekturen werden noch übertragen,
> wenn man das TomTom mit dem TomTom-Server verbindet.
> Und das Quick-Fix für die Satelliten wird auch aktualisiert.
> Das "week rollover update" habe ich so noch auf zwei alte
> TT ONE IQ Route draufgedudelt bekommen.
...
> Die neuen TomToms haben jetzt ein lebenslanges kostenloses Kartenupdate.
> Schade, dass TomTom das Kartenmaterial für die älteren NAVIs
> nicht mehr weiter supportet.
> Man hätte wenigsten zum Schluß noch kostenlos eine letzte aktuelle Karte
> gucken lassen können.

Es gibt eine ganze Seite von Tomtom, welche Geräte man wegwerfen muß. 
https://www.tomtom.com/en_gb/obsolete-products/
Die Erklärung, daß es am größeren Datenvolumen liegt, ist zwar süß:
"As an illustration, in 2010 a map for Europe was 1.6GB, and today it is 
6.5GB."
... aber letztlich unzutreffend, da vermutlich Daten für neuere Geräte 
enthalten sind (10 Spuren metergenau an einer Innenstadtkreuzung, 
womöglich noch Rad- und Gehwegpositionen), die für das alte Gerät (zwei 
sich kreuzende Striche mit Stützpunkten alle 100 m ) nicht nötig sind.

Vermutlich lassen sich die modernen Daten nicht trivial runterrechnen, 
und so müßte man seinen Saustall von ein paar Dutzend inkompatiblen 
Kartenformaten bei jeder Änderung nachführen.

Mich hat die 10 Jahre alte Karte nie gestört. 1% Fehler wird man schon 
in der ersten Woche nach der Aktualisierung haben, weil irgendjemand ein 
paar Einbahnstraßen umgedreht hat. Und mehr als 10% Fehler werden es nie 
werden, außer man fährt nach Hiroshima oder Dresden vor/nach den 
Bombenabwürfen.

Ich hab 7.16x als Softwareversion, es gibt noch ein paar Hundertstel 
neuer zum Runterladen. Und eine Version 8.x, die nur auf Englisch 
beschrieben wird. In keiner steht aber etwas von GPS Rollover drin, so 
daß ich nicht glaube, daß das hilft.

Und da ich nie bei Tomtom angemeldet war, wird mein Navi nicht gerade 
jetzt noch mit Tomtom reden wollen (andersherum noch weniger.)

Autor: Andreas M. (andreas_m62)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Trotzdem hätte TomTom für die alten Geräte wenigstens noch
die letzte lauffähige (Deutschland)Kartenversion aufspielen können.

Alle folgenden Geräte haben ja ab jetzt auch eine
kostenlose lebenslange Updatemöglichkeit.

Autor: Volker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wollvieh schrieb:

> Bei mir ist jetzt mein Tomtom One von ca. 2007 abgekackt.

Interessant. Ein 12 Jahre altes GPS-Modul (EM-406A mit SiRF starIII)
macht bei mir jetzt ähnliche Zicken. Das Datum scheint allerdings
korrekt zu sein.

Autor: Jacko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine Astro-Uhr mit ATMega8 und einem ETEK EB-85A hat mir gestern
abend den 24. August 99 angezeigt. Geografische Position war OK.

Aus Zeit und Position wird das Julianische Datum, die Polkorrektur
und die lokale Sternzeit errechnet: Unbrauchbarer Mist.
Heute im Netz gestöbert: Roll-Over-Problem.

Da ich die GPS-Telegramme vom EB-85A selbst auswerte, war es
für mich kein großes Ding, die Datumsangabe vom GPS um +20 Jahre,
-137 Tage und (!!!) -4 Sekunden zu korrigieren. Alles OK, so
kann das die nächsten (max. 19) Jahre weiter spielen...

Aber den Fehler von exakt 4 Sekunden kann ich mir nicht erklären.
Bis vor einer Woche zeigte diese GPS-Uhr immer die gleiche Sekunde,
wie mein DCF-Empfänger.

13 Schaltsekunden gab es in den 1024 Wochen von Jan 1980 bis
Aug 1999. Weitere 5 Schaltsekunden gab es in den 1024 Wochen von
Aug 1999 bis Apr 2019. - Woher kommen die 4 Sekunden???

Hier hatten sich ja schon einige GPS-Kenner gemeldet, für die
"wrap-around" und "10 auf 13 Bit" pillepalle sind. Die haben
bestimmt eine Erklärung!   (?)

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
> GPS Empfänger, die damit nicht zurecht kommen, sollte man wegen
> verdeckter Mängel zurück geben.

Mein altes Magellan 300 werde ich wohl nicht zurückgeben können :), das 
fühlte sich auf den 26. August 1999 zurück versetzt (nachdem es endlich 
genügend Satelliten gefunden hatte). Aber das Teil habe ich 1999 bereits 
gebraucht gekauft … aufgehangen hat es sich jedoch zumindest nicht, und 
die Uhrzeit selbst stimmte.

Das reichlich 10 Jahre alte GPSmap60 hat jedenfalls keine Probleme – 
obwohl es noch nie ein Firmware Upgrade gesehen hat.

Autor: Kommandozeile vor dem Frühstück für Alle! (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das hier vorliegende Garmin GP 12 rennt zwar noch und zeigt die korrekte 
Position, meldet als Datum aber 1999-08-26 :-( leider auch in den NMEA 
Telegramme.
$ stty --file=/dev/ttyS0 4800
$ while read   line < /dev/ttyS0
> do
>    rmc=$(echo "$line" | grep 'GPRMC' )
>    [[ "" == "$rmc" ]]  ||  \
>    (  
>       echo "UTC   host: $(date --utc --iso=s)"
>       echo "      GP-12: ${rmc}"
>    )
> done
UTC   host: 2019-04-11T07:49:24+00:00
      GP-12: $GPRMC,074923,A,47??.???,N,008??.???,E,000.0,019.0,260899,000.2,E*7F
UTC   host: 2019-04-11T07:49:26+00:00
      GP-12: $GPRMC,074925,A,47??.???,N,008??.???,E,000.0,019.0,260899,000.2,E*7B
UTC   host: 2019-04-11T07:49:28+00:00
      GP-12: $GPRMC,074927,A,47??.???,N,008??.???,E,000.0,019.0,260899,000.2,E*77
UTC   host: 2019-04-11T07:49:30+00:00
      GP-12: $GPRMC,074930,A,47??.???,N,008??.???,E,000.0,019.0,260899,000.2,E*76
^C

Seine FW ist v4.55 und im Netz finde ich Dateien mit v4.60: kennt hier 
Jemand eine moeglichkeit die FW auf das GP-12 aufzuspielen OHNE 
DOS/Windows?

(wobei ich nicht erwarte dass sich dabei was am WN-Rollover aendert...)

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kommandozeile vor dem Frühstück für Alle! schrieb:
> das hier vorliegende Garmin GP 12 rennt zwar noch und zeigt die korrekte
> Position, meldet als Datum aber 1999-08-26

Also das gleiche wie bei meinem Uralt-Magellan 300.

Allerdings hat sich allein im Bereich der Sensitivität der Chipsätze 
inzwischen so viel getan, dass ich das alte Magellan ohnehin nicht mehr 
ernsthaft in Betracht ziehen würde. Ich weiß nicht, wie lange es gestern 
nacht für den ersten Fix nach dem Einschalten gebraucht hat, ich habe es 
dann über Nacht laufen lassen.

Autor: Wollvieh W. (wollvieh)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Andreas M. schrieb:
> Trotzdem hätte TomTom für die alten Geräte wenigstens noch
> die letzte lauffähige (Deutschland)Kartenversion aufspielen können.
>
> Alle folgenden Geräte haben ja ab jetzt auch eine
> kostenlose lebenslange Updatemöglichkeit.

Präziser ist es so, daß die Updates für die "Lifetime" kostenlos sind. 
Und "Lifetime" ist nur solange Tomtom Updates anbietet. Danach ist sie 
rum. Kann also für alle etwas älteren Geräte schon morgen passieren. Was 
ich fast genauso frech finde wie die von Tomtom absichtlich eingebaute 
Selbstzerstörung mit Datum. Wo wäre das Problem, zu jedem Gerät einen 
Stichtag in 20 oder besser 40 Jahren anzugeben, so wie es ja selbst 
Microsoft für seine Windows-Versionen schafft. Ok, die sind meist schon 
nach 5 Jahren kaputt.

Ist so ähnlich wie die "Lifetime-Füllung" bei BMW-Automatik-Getrieben in 
einstigen 150000-DM-Autos: Man kann die Ölfüllung nicht wechseln und 
nach 100-150.000 km ist die "Lifetime" um und das Getriebe geht kaputt. 
(Der Getriebehersteller bietet dennoch eine 600 Euro teure Prozedur an, 
die 5 Stunden dauert. Bei BMW gibt es eine ich glaube nur halb so teure 
Prozedur, bei der dafür auch nur ein Drittel des Öls ausgetauscht wird.)

Autor: Wollvieh W. (wollvieh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe das Gerät jetzt nochmal zu Fuß durch die Stadt ausgeführt. Es 
zeigt 8 Satelliten an und die Position stimmt. Bei den Satellitendetails 
wird die korrekte UTC-Zeit angezeigt. Wenn ich es ins Auto hänge, 
bleiben 5 der 8 Satelliten übrig, immer noch genug um zu funktionieren.

Aber wenn ich "Zeit synchronisieren" ausführe, wird das dauernde 0:00 
Uhr im Einstellbildschirm in die aktuelle Zeit verwandelt, sogar mit 
korrekten +2. Nach Bestätigen und Verlassen der Einstellungen ist die 
Zeit wieder dauerhaft 0:00.

Tomtom hat also tatsächlich vorsätzlich eine Selbstzerstörung eingebaut, 
obwohl das GPS-Modul die korrekten Daten liefert. Was für Drecksäcke!

Welche Navis von anderen Firmen sind denn noch eingermaßen gut? Ich 
denke dabei an ein Gebrauchtgerät, das durchaus 10 Jahre alt sein darf. 
Die SCDB-Blitzerdaten sollten draufpassen. :) Sonst würde ich halt ein 
etwas neueres altes Tomtom nehmen, aber ich bin da sehr eigen, wenn mich 
jemand verarscht.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Wollvieh W. schrieb:
> Welche Navis von anderen Firmen sind denn noch eingermaßen gut?

Handy benutzen willst du nicht?

Autor: Manfred (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wollvieh W. schrieb:
> Ich denke dabei an ein Gebrauchtgerät,

Alles, was mit Navigon MN8 läuft.

Da ist leider Support-Ende, von der Konkurrenz aufgekauft. Es gab im 
Dezember 2018 ein Update Q2/2019 und soll letztmalig Ende 2019 ein 
Kartenupdate geben.

Autor: ACDC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mein Falk Fahrradnavi hat es erwischt.
Zeigt 2099-08-28 als Datum.
Update gibt es nicht mehr, da Insolvent.

Autor: Andreas M. (andreas_m62)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe noch ein TT One mit 512 MB RAM geupdated,
welches von der Firmware 7.xxx auf 8.010 verbessert wurde.
Leider ist nur eine "D-A-CH"-Karte nit der v705.xxxx drauf.
Aber sonst läuft es problemlos.

: Bearbeitet durch User
Autor: Mani (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mein Gatmin GPS12XL zeigt die korrekte Position, Uhrzeit und Datum an.

Autor: John (Gast)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Mein „Solmeta Geotagger Pro 2“ zeigt das falsche Datum an.

Nennt sich „Pro“, war nicht billig und die Firmware ist schlampig 
programmiert. Ein Firmwareupdate gibt es bis jetzt nicht.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal so als blöde Frage:

Liegt das Problem an der Firmware des GPS-Chipsatzes oder dem Programm, 
was die Daten vom GPS-Chip interpretiert?

Autor: Wolfgang (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
S. R. schrieb:
> Liegt das Problem an der Firmware des GPS-Chipsatzes oder dem Programm,
> was die Daten vom GPS-Chip interpretiert?

Welches Problem?
Die meisten GPS Empfänger geben u.a. Datum und Uhrzeit im NMEA0183 
Format raus (GPRMC Sentence).

Autor: Wegstaben V. (wegstabenverbuchsler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Welches Problem?

Das Problem, das Datum und Uhrzeit "falsch" dargestellt werden.

Wolfgang schrieb:
> Die meisten GPS Empfänger geben u.a. Datum und Uhrzeit im NMEA0183
> Format raus

Und was heißtr das genau? Können die deswegen das Datum/Uhrzeit NICHT 
richtig darstellen, oder woran liegts?

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Welches Problem?

Die Fehler aufgrund des GPS Rollovers.

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wegstaben V. schrieb:
> Und was heißtr das genau? Können die deswegen das Datum/Uhrzeit NICHT
> richtig darstellen, oder woran liegts?

Sie TUN es nicht, sondern liegen um 1024 Wochen falsch
$GPRMC,160905,A, ... ,290899,000.3,W*67
                      ^^^^^^

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das heißt, dass der Fehler in der Firmware des GPS-Chipsatzes liegt und 
nicht im Code des verarbeitenden Programms. Habe ich das richtig 
verstanden?

Autor: ??? (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Der Fehler liegt in der Aswertesoftware. Der Chipsatz liefert nur die 
Wochennummer. Die ist nun erstmals übergelaufen. Das muss die Auswertung 
eben berücksichtigen. Passenderweise hat man nun das Datenformat 
geändert. so dass in 19 Jahren das Problem dann den Chipsatz betreffen 
kann. Dann gibts nämlich plötzlich Wochennummern die zu groß sind und 
nur von neuer Chipsatz Firmware korrekt behandelt werden können.
Das kann aber auch gut gehen. Das weiss man nivht...

Autor: J-H V. (artabanos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
John schrieb:
> Mein „Solmeta Geotagger Pro 2“ zeigt das falsche Datum an.
>
> Nennt sich „Pro“, war nicht billig und die Firmware ist schlampig
> programmiert. Ein Firmwareupdate gibt es bis jetzt nicht.

Ich besitze das selbe Gerät in der Version für Nikon (Firmware 2.3 / 
Hardware-Version 3.0).

Mein Gerät funktioniert einwandfrei. Ich habe testweise gerade bis zum 
GPS-Fix gewartet, doch es zeigt immer noch das richtige Datum an.

Autor: Jacko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bitte, labert keinen Quatsch:

Das falsche Datum kommt vom GPS-Chip. Woher sonst???

Die schlechten GPS-Cips schicken uns nach 1999, die guten
nicht - aber dann hat es selbst schlechte Auswertungs-Software
schwer, mit dem falschen Datum zu arbeiten....

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jacko schrieb:
> Bitte, labert keinen Quatsch:

Wer eigentlich?

> Das falsche Datum kommt vom GPS-Chip. Woher sonst???

Von der Firmware.

Der „GPS-Chip“ empfängt (und korreliert / dekodiert) das GPS-Signal.

Der Rest ist Firmware.  Ganz viel davon.  Darin steckt das A&O bei GPS.

> Die schlechten GPS-Cips schicken uns nach 1999

2099, wie du weiter oben lesen kannst.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
>> Das falsche Datum kommt vom GPS-Chip. Woher sonst???
> Von der Firmware.

Welche Firmware?

Die, die zum GPS-Chipsatz gehört (also in einem PNA der Teil, der NMEA 
mit dem Hauptprozessor spricht) oder die Navigationssoftware selbst?

Oder beide?

Autor: John (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
J-H V. schrieb:
> Ich besitze das selbe Gerät in der Version für Nikon (Firmware 2.3 /
> Hardware-Version 3.0).
>
> Mein Gerät funktioniert einwandfrei.

Mein Geotagger ist auch Hardware-Version 3.0, aber Firmware 2.0.

Auf der Download-Seite von Solmeta wird aber kein entsprechendes Update 
zum Download angeboten.
Vor eine Woche habe ich eine Mail an Solmeta geschrieben, aber noch 
keine Antwort erhalten.

Autor: Manfred (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
S. R. schrieb:
> Welche Firmware?

Man darf raten. Ich habe ein Mobilnavi von 2007, was von Navigon bereits 
seit Jahren nicht mehr mit Updates (MN7) versorgt wird. Pfiffige Bastler 
haben die Software (MN8) neuerer Geräte so modifziert, dass diese auf 
der alten Hardware läuft.

Wenn ich mir da die Steuerdateien ansehe, spricht die Navigon-SW per 
serieller Schnittstelle mit dem GPS-Modul, man darf also vermuten , 
dass die Updates nichts mit dem Empfang der Position zu tun haben. 
Schaue ich mir die Updates an, sehe ich dort nur aktualisierte Karten.

Ein mir detailliert bekanntes Personensicherungsgerät mit GPS nutzt 
Module von µblox und liest per seriellem Interface dessen NMEA-Daten, 
auch da hat der Hersteller keinen Zugriff zur eigentlichen 
Positionsauswertung. Ob ein Update der µblox-Module möglich wäre, weiß 
ich nicht - egal, die Geräte haben kein Problem.

Hier klebt noch eine Navilock GPS-Maus mit serieller Schnittstelle, in 
dessen Innenleben ein Sony cxd2951 werkelt. Die liefert NMEA-Daten, ich 
kann aber Befehle senden, welche dieser ich haben will. Wenn ich viel 
Langeweile habe, klemme ich die Maus mal an und gucke.

Also, ich sehe hier viel Freiraum für Spekualtionen, für eine 
qualifizierte Beurteilung müsste man alle Komponenten und die Software 
kennen!

Autor: J-H V. (artabanos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
John schrieb:
> Mein Geotagger ist auch Hardware-Version 3.0, aber Firmware 2.0.
>
> Auf der Download-Seite von Solmeta wird aber kein entsprechendes Update
> zum Download angeboten.

Ich habe den Geotagger 2013 gekauft. Da war die Version 2.3 schon drauf.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Jeder Mensch hat heutzutage immer irgendetwas Kalenderähnliches in
> Reichweite, um die aktuelle Jahreszahl ausreichend genau, i.e. auf +/-9
> Jahre, zu bestimmen. Selbst Dantès in seiner Zelle hätte das noch
> ausreichend genau hin bekommen.
>
> Warum soll das GPS diese redundanten Daten dauernd an die Nutzer
> verbreiten.

Es verbreitet sie nicht an die Nutzer, sondern an die GPS-Empfänger. Für 
sie ist das GPS-System der Kalender, den sie in Reichweite haben.

Harald W. schrieb:
> Gut, ich hatte schnell im Kopf gerechnet. Wahrscheinlich ist
> dieser inzwischen feheranfälliger als ich geglaubt habe. :-)

Wahrscheinlich ist da auch ein Zähler übergelaufen ;-)

??? schrieb:
> Der Chipsatz liefert nur die Wochennummer. Die ist nun erstmals
> übergelaufen.

Nein, sie ist zum zweiten mal übergelaufen. Der erste Überlauf war 1999.

Autor: Bauform B. (bauformb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manfred schrieb:
> Ein mir detailliert bekanntes Personensicherungsgerät mit GPS nutzt
> Module von µblox und liest per seriellem Interface dessen NMEA-Daten,
> auch da hat der Hersteller keinen Zugriff zur eigentlichen
> Positionsauswertung. Ob ein Update der µblox-Module möglich wäre, weiß
> ich nicht

Manche ulbox-Module haben Flash und können neue Firmware bekommen, 
andere nicht. Das, und wie das Datum im NMEA-Satz zustande kommt, ist 
bei ublox relativ gut dokumentiert.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Jörg W. schrieb:
>>> Das falsche Datum kommt vom GPS-Chip. Woher sonst???
>> Von der Firmware.
>
> Welche Firmware?
>
> Die, die zum GPS-Chipsatz gehört

Just diese.

Ist halt ziemlich viel Software bei dem ganzen Verfahren.

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Wolfgang schrieb:
>>…
>> Warum soll das GPS diese redundanten Daten dauernd an die Nutzer
>> verbreiten.
>
> Es verbreitet sie nicht an die Nutzer, sondern an die GPS-Empfänger. Für
> sie ist das GPS-System der Kalender, den sie in Reichweite haben.

Der GPS-Empfänger braucht das Datum nicht. Der ist mit seiner GPS-Woche 
sehr zufrieden.
Datumsausgabe, Zonenzeit und eingerechnete Schaltsekunden sind eine 
Aufbereitung für vom GPS gefütterte Anwendungen und den Menschen, der an 
der UTC bzw. Zonenzeit haben möchte.

Leider gibt es IMHO beim NMEA-Format keine Ausgabe der GPS 
Woche/Schaltsekundenzahl, um das reale Datum selber in der Anwendung zu 
rechnen.

Autor: Manfred (Gast)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Leider gibt es IMHO beim NMEA-Format keine Ausgabe der GPS
> Woche/Schaltsekundenzahl, um das reale Datum selber in der Anwendung zu
> rechnen.

Eine GPS-Maus "Navilock NL-208P", die ist um 15 Jahre alt, habe ich 
heute mal ans Terminalprogramm gehängt und geguckt, Position und Datum 
stimmen.

Wie das (Tages-)Datum zustande kommt, ist mir nicht ganz klar, aber laut 
NMEA soll es als Datensatz fertig geliefert werden, wozu also selbst 
berechnen?

Was aber auffällt, dass die Uhrzeit 4 Sekunden daneben ist und ich im 
NMEA kein Datenfeld mit der Anzahl der Schaltsekunden finde. Würden sie 
garnicht berücksichtigt, müsste der Versatz 27 Sekunden betragen, so 
viele Schaktsekunden gab es inzwischen. Ich vermute also, dass der 
GPS-Chipsatz in seiner Firmware eine Tabelle hat und die Schaltsekunden 
nach Datum selbst addiert.

Es bleibt also: Solange man nicht Zugriff zu allen Softwarekomponenten 
hat, kann es laufen, nicht laufen oder nicht anständig laufen.

Autor: Wegstaben V. (wegstabenverbuchsler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was für Auswirkungen hat denn (zusammen gefasst) bei den verschiedenen 
Navis der "Week rollover"?

Sieht da nur das Datum "blöd" aus, oder gibt es tatsächliche 
grundsäzliche Fehlfunktionen (von komplett blockieren bis hin zu 
Positions-Abweichungen)?

: Bearbeitet durch User
Autor: Manfred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wegstaben V. schrieb:
> was für Auswirkungen

Falls Google bei Dir defekt ist, wiederhole die Frage bitte am 
19.04.2019.

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manfred schrieb:
> Wolfgang schrieb:
>> Leider gibt es IMHO beim NMEA-Format keine Ausgabe der GPS
>> Woche/Schaltsekundenzahl, um das reale Datum selber in der Anwendung zu
>> rechnen.
>
> Eine GPS-Maus "Navilock NL-208P", die ist um 15 Jahre alt, habe ich
> heute mal ans Terminalprogramm gehängt und geguckt, Position und Datum
> stimmen.

Glück gehabt. Bei mir haben es zwei nicht geschafft :-(

> Wie das (Tages-)Datum zustande kommt, ist mir nicht ganz klar, aber laut
> NMEA soll es als Datensatz fertig geliefert werden, wozu also selbst
> berechnen?

Das Datum wird berechnet aus der GPS-Woche, dem GPS-Sekundenzähler, der 
Anzahl der UTC Schaltsekunden seit Januar 1980 und einem Offset, der 
sich mit jedem GPS Wochenzählerüberlauf um 1024 Wochen erhöhen muss. 
Wenn letzterer das nicht tut, hätte dein GPS heute den 30. Aug 1999 
angezeigt.

Und genau das ist etlichen älteren, schlampig programmierten GPS 
Empfängern passiert, z.B. Garmin 45 und zumindest auch der Deutschen 
Bahn in Regionalzügen, die anscheinend die Zeit aus einem GPS Empfänger 
holen.

Schöne Grüße nach Heiningen

Autor: minight (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

verstehe ich das richtig das GPS nur die Anzahl der Wochen seit 
Zeitpunkt xxx ausgibt und sich jede FW daraus selbst das Jahr berechnen 
muss?

Jens

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manfred schrieb:
> Was aber auffällt, dass die Uhrzeit 4 Sekunden daneben ist und ich im
> NMEA kein Datenfeld mit der Anzahl der Schaltsekunden finde. Würden sie
> garnicht berücksichtigt, müsste der Versatz 27 Sekunden betragen, so
> viele Schaktsekunden gab es inzwischen. Ich vermute also, dass der
> GPS-Chipsatz in seiner Firmware eine Tabelle hat und die Schaltsekunden
> nach Datum selbst addiert.

Im NMEA Datenfeld tauchen die Schaltsekunden nicht mehr auf, weil sie 
bei der Umrechnung von GPS-Woche/GPS-Sekunden auf UTC bereits 
berücksichtigt wurden.

27 Schaltsekunden wurden seit der Neudefinition der Sekunde im Jahre 
1972 eingeschoben. GPS zählt aber erst ab 6. Januar 1980. Zwischen 1980 
und 2019 waren es genau 18 Schaltsekunden. Eine Tabelle kann es im 
GPS-Chipsatz nicht geben, weil der Firmware Hersteller nicht in die 
Zukunft gucken kann.

Die Schaltsekunden werden nach Bedarf eingefügt und das hängt von den 
Eiereien der Erddrehung ab. Die aktuelle Zahl wird von den 
GPS-Satelliten an die Empfänger übertragen.
https://de.wikipedia.org/wiki/Schaltsekunde#Praktische_Durchf%C3%BChrung

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
minight schrieb:
> verstehe ich das richtig das GPS nur die Anzahl der Wochen seit
> Zeitpunkt xxx ausgibt und sich jede FW daraus selbst das Jahr berechnen
> muss?

Nicht nur das Jahr sondern auch Monat und Tag. Das aktuelle Problem 
einiger Empfänger ist, dass sich der Wert für xxx alle 1024 Wochen 
ändert und die das wegen schlechter Programmierung nicht richtig auf die 
Reihe gekriegt haben (bisherige UTC-Werte für xxx:  6. Januar 1980, 21. 
August 1999 und 6. April 2019)

Autor: minight (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Wolfgang:

Das der Wochenzähler mit seinen 10 Bit breite nun einmal übergelaufen 
ist verstehe ich.

Aber was sendet GPS eigentlich um das Datum ermitteln zu können?
Die Wochenzahl reicht da ja nicht.
Jens

Autor: Manfred (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Glück gehabt. Bei mir haben es zwei nicht geschafft :-(

Ja, ein Abflug der GPS-Maus hätte nicht gestört, da ich diese eh nicht 
einsetze. Sind mir mal zugelaufen, willst' eine haben?

Ärgerlich wäre ein Ausfall des Mobil-Navigon gewesen. Ich habe zwar ein 
Festeinbau-Navi im Auto, aber das Navigon liegt gerne verdeckt im Wagen 
und sagt mir interessante Punkte an.

>> Wie das (Tages-)Datum zustande kommt, ist mir nicht ganz klar,
> Das Datum wird berechnet aus der GPS-Woche, dem GPS-Sekundenzähler, der
> Anzahl der UTC Schaltsekunden seit Januar 1980 und einem Offset, der
> sich mit jedem GPS Wochenzählerüberlauf um 1024 Wochen erhöhen muss.
> Wenn letzterer das nicht tut, hätte dein GPS heute den 30. Aug 1999
> angezeigt.

Das klingt ja nach Gebastel. Aber gut, zum Zeitpunkt der Erschaffung von 
GPS waren Rechenleistung und Speicher erheblich teurer als heutzutage.

> Und genau das ist etlichen älteren, schlampig programmierten GPS
> Empfängern passiert, z.B. Garmin 45 und zumindest auch der Deutschen
> Bahn in Regionalzügen, die anscheinend die Zeit aus einem GPS Empfänger
> holen.

Musst Du unbedingt die Schublade der Vorbehalte bedienen, bei der Bahn 
hätte man es ja erwarten dürfen?

Angeblich hat es auch einige Tetra-Funksysteme erwischt, aber das halten 
die Anbieter natürlich unter der Decke des Schweigens.

> Schöne Grüße nach Heiningen
:-)

Autor: Manfred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
> 27 Schaltsekunden wurden seit der Neudefinition der Sekunde im Jahre
> 1972 eingeschoben. GPS zählt aber erst ab 6. Januar 1980. Zwischen 1980
> und 2019 waren es genau 18 Schaltsekunden. Eine Tabelle kann es im
> GPS-Chipsatz nicht geben, weil der Firmware Hersteller nicht in die
> Zukunft gucken kann.

Gut, keine integrierte Glaskugel, nachvollziehbar.

Jetzt gucken wir mal auf den Beitrag vom 10.04.:
Jacko schrieb:
> Aber den Fehler von exakt 4 Sekunden kann ich mir nicht erklären.
> Bis vor einer Woche zeigte diese GPS-Uhr immer die gleiche Sekunde,
> wie mein DCF-Empfänger.

Und auch ich habe 4 Sekunden Zeitversatz an der Navilock-Maus, ohne mir 
diese erklären zu können.

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manfred schrieb:
> Und auch ich habe 4 Sekunden Zeitversatz an der Navilock-Maus, ohne mir
> diese erklären zu können.

Datum ok und trotzdem der Zeitversatz ist merkwürdig.

Hier habe ich einen betagten GPS-Datenlogger-USB-Stick ("Polaris") der 
ebenfalls 4s vor geht, aber den Datumssprung nicht hinbekommen hat.
$GPRMC,220850.923,A, ... ,000.0,005.6,300899,,,A*6F
http://polaris-gps.com/6.html

Autor: Wolfgang (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Manfred schrieb:
> Sind mir mal zugelaufen, willst' eine haben?
Danke, habe auch noch ...

> Das klingt ja nach Gebastel. Aber gut, zum Zeitpunkt der Erschaffung von
> GPS waren Rechenleistung und Speicher erheblich teurer als heutzutage.

Na ja, Problem ist nicht Rechenleistung und Speicher, sondern 
Übertagungsrate und Zeitdefinition. GPS läuft mit Atomuhr schön 
gleichmäßig durch, während UTC zwar ebenfalls mit Atomuhr tickt, aber 
immer wieder zusätzlich die Schaltsekunden aufgedrückt bekommt, damit 
die Uhrzeit zur Erddrehung angepasst. Mit der Woche als Basis ist GPS 
auch die Schaltjahre los, ganz zu schweigen von erratischen Monatslängen 
(bestimmt durch den Stolz römischer Kaiser). Der ganze Zirkus mit dem 
Datum interessieren nur die Erdenbürger, hat aber nicht mit globaler 
Positionsbestimmung zu tun und ist eine Zusatzdienstleistung.

Autor: michael_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum ist das Datum wichtig?
Braucht man das am Navi?

Ich habe jetzt zwei getestet.
12 und 15 Jahre alt. Die lenken mich ordentlich die Straßen lang.
Die sie kennen :-)

Autor: ACDC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
michael_ schrieb:
> Warum ist das Datum wichtig?
> Braucht man das am Navi?

Wichtig nicht.
Ein Luxusproblem an das ich mich gewöhnt habe.
Alle Tracks werden automatisch gespeichert mit Datum und Uhrzeit.
So muss ich nix von Hand eintippen.

Autor: Manfred (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Der ganze Zirkus mit dem
> Datum interessieren nur die Erdenbürger, hat aber nicht mit globaler
> Positionsbestimmung zu tun und ist eine Zusatzdienstleistung.

Jou! Mein Navigon zeigt übrigens kein Datum an, bei einem Mobilnavi 
sehe ich auch keine Notwendigkeit dafür.

Manfred schrieb:
> Und auch ich habe 4 Sekunden Zeitversatz an der Navilock-Maus, ohne mir
> diese erklären zu können.

Im Internet finden sich Hinweise, dass die Uhrzeit erst nach längerer 
Laufzeit passen soll, leider ohne Hinweise auf die konkret verbauten 
Chipsätze. Ich habe heute die Navilock-Maus über mehrere Stunden 
betrieben und gucke da, der Zeitversatz liegt unterhalb meiner 
Ablesegenauigkeit.

Dann habe ich noch ein stationäres Gerät mit Motorola-Empfänger 
angeschaut, nach Start zeigt es das Jahr 2004 an. Zeit passt, Position 
passt, Höhenangabe 148m eher nicht. Das Ding ist aber zickig, unter 5 
Satelliten liefert es keinen Fix.

Wer sehen will, welche Satelliten gerade zu empfangen sind:
https://in-the-sky.org/satmap_radar.php?town=2945024

Oben auswählen "Satellites above your horizon" und dann ganz unten 
"Change location"

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manfred schrieb:
> Mein Navigon zeigt übrigens kein Datum an, bei einem Mobilnavi
> sehe ich auch keine Notwendigkeit dafür.

Wenn ich mich recht entsinne, konnte man sich das Datum in irgendeinem 
Untermenü mit technischen Infos anzeigen lassen. Meins ist aber schon 
länger außer Betrieb.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.