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?
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.
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.
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?
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)?
Wie sieht das bei Smartphones aus? Müssen da die Hersteller auch Updates bereitstellen oder ist das bereits mit den Letzten Update integriert worden?
Wenn der GPS-Receiver nach ICD-200 korrekt implementiert wurde, darf es keine Probleme geben.
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
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.
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.
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.
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.
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.
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.
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.
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
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?
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
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.
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
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
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.
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.
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? :-)
Wolfgang S. schrieb: > Stichwort "kotzene Pferde": http://www.lindermanns-tierwelt.de/wussten-sie-schon-dass-pferde-nicht-kotzen-konnen/ :-)
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.
Angehängte Dateien:
-
Jahre.png
72 KB
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.
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. :-)
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.)
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.
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.
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! (?)
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.
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.
1 | $ stty --file=/dev/ttyS0 4800 |
2 | $ while read line < /dev/ttyS0 |
3 | > do |
4 | > rmc=$(echo "$line" | grep 'GPRMC' ) |
5 | > [[ "" == "$rmc" ]] || \ |
6 | > ( |
7 | > echo "UTC host: $(date --utc --iso=s)" |
8 | > echo " GP-12: ${rmc}"
|
9 | > ) |
10 | > done |
11 | UTC host: 2019-04-11T07:49:24+00:00 |
12 | GP-12: $GPRMC,074923,A,47??.???,N,008??.???,E,000.0,019.0,260899,000.2,E*7F |
13 | UTC host: 2019-04-11T07:49:26+00:00 |
14 | GP-12: $GPRMC,074925,A,47??.???,N,008??.???,E,000.0,019.0,260899,000.2,E*7B |
15 | UTC host: 2019-04-11T07:49:28+00:00 |
16 | GP-12: $GPRMC,074927,A,47??.???,N,008??.???,E,000.0,019.0,260899,000.2,E*77 |
17 | UTC host: 2019-04-11T07:49:30+00:00 |
18 | GP-12: $GPRMC,074930,A,47??.???,N,008??.???,E,000.0,019.0,260899,000.2,E*76 |
19 | ^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...)
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.
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.)
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.
Wollvieh W. schrieb: > Welche Navis von anderen Firmen sind denn noch eingermaßen gut? Handy benutzen willst du nicht?
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.
Mein Falk Fahrradnavi hat es erwischt. Zeigt 2099-08-28 als Datum. Update gibt es nicht mehr, da Insolvent.
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
Angehängte Dateien:
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.
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?
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).
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?
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
1 | $GPRMC,160905,A, ... ,290899,000.3,W*67 |
2 | ^^^^^^ |
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?
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...
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.
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....
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.
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?
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.
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!
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.
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.
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.
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.
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.
Angehängte Dateien:
-
Navigon_Navilock_02_mark.jpg
29 KB -
Navilock_ht_mark.png
24 KB
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.
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
Wegstaben V. schrieb: > was für Auswirkungen Falls Google bei Dir defekt ist, wiederhole die Frage bitte am 19.04.2019.
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
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
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
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)
@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
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 :-)
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.
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.
1 | $GPRMC,220850.923,A, ... ,000.0,005.6,300899,,,A*6F |
http://polaris-gps.com/6.html
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.
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 :-)
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.
Angehängte Dateien:
-
Versatz.png
35 KB -
Taref_20190416.png
14 KB
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"
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.
Hi Gemeinde, ich wollte hier gerade eine Anfrage 'reinstellen, ob jemand weiß, ob das Week rollover bei einem nicht darauf vorbereiteten Empfänger auch die Positionsbestimmung zunichte machen kann. Aber es kommt ganz anders... Ich habe hier nämlich eine ältere GPS-Maus BU-303 (von Navilock?), die seit Jahren in der Schublade bleiben mußte, weil seit Win10 der Hersteller (Prolific) den Support für den USB-Seriell-Wandler eingestellt hat (zutreffender ausgedrückt: das Produkt gezielt unbrauchbar gemacht hat). Am letzten Wochenende habe ich die Maus aber mal an einen Raspi angeschlossen, wo sie problemlos eingebunden wurde und NMEA-Daten liefert. Leider aber gab es mehrere Tage lang keinen Fix (die Maus lag mindestens anderthalb Tage am Stück draußen auf dem Fensterbrett und hat dort fast die halbe Hemisphäre nach Süden zum freien Empfang). Das Datum wurde als 2022-irgendwas angezeigt, die Zeit war auch ungültig. Ich hatte gpsmon (aus dem gis-gps-Paket) gestartet und heute vormittag mal testweise auf das Binärprotokoll des SiRF-II-Chips umgeschaltet. Das Datum wurde hier als 1906 oder so angezeigt (bzw. unten zwischen den Rohdaten-Zeilen als "negativ" bewertet). Als ich jedoch vom Einkaufen zurück war und auf NMEA zurückschaltete, hatte das Teil nach kurzer Zeit wieder einen Fix und das korrekte Datum, hurra! Und mittlerweile ist auch der HDOP-Wert wieder im normalen Bereich. Wollte das nur mal mit Euch teilen :-) Kann das so lange gedauert haben, bis die Almanach-Daten (nach mehreren Jahren in der Schublade) wieder up-to-date waren? Die jeweils empfangenen Satelliten wurden vor dem Fix z. B. alle mit Azimut=0 und verschiedenen Elevationswerten angezeigt. Frohe Ostern
hrool schrieb: > Kann das so lange gedauert haben, bis die Almanach-Daten (nach mehreren > Jahren in der Schublade) wieder up-to-date waren? Ja, das dauert. Wenn jetzt noch die Pufferbatterie leer ist nach all den Jahren, dann kann es auch sein, das es bei jedem Start so lange dauert. Miss sie am besten mal nach. TomTom GO710 spielt hier gut (obwohls noch die alte Version mit MicroDrive ist). Becker 'Traffic Assist Highspeed' mit Win CE 4.2 funktioniert auch richtig.
Angehängte Dateien:
-
Prolific_USB-Serial.png
94 KB
hrool schrieb: > Ich habe hier nämlich eine ältere GPS-Maus BU-303 (von Navilock?), die > seit Jahren in der Schublade bleiben mußte, weil seit Win10 der > Hersteller (Prolific) den Support für den USB-Seriell-Wandler > eingestellt hat Warum sollte Prolific sich verpflichtet fühlen, schlechte Nachahmer zu unterstützen? Aber deswegen muss die GPS-Maus noch lange nicht in der Schublade bleiben. Es reicht doch, wenn du unter Win10 einen funktionsfähigen Treiber lädst. (Nach Win10 Aktualisierung muss man das wiederholen)
Wolfgang schrieb: > Warum sollte Prolific sich verpflichtet fühlen, > schlechte Nachahmer zu unterstützen? Das war FTDI mit der "ich mach euch den Chip kaputt"-Nummer. Prolific hat einfach nur den Treibersupport für alte Chips eingestellt.
S. R. schrieb: > Das war FTDI mit der "ich mach euch den Chip kaputt"-Nummer. Sorry, das habe ich wohl verwechselt. > Prolific hat einfach nur den Treibersupport für alte Chips eingestellt. Zum Glück ist das meinen diversen Prolifc-Wandlern (z.B. von Navilock NL-303P GPS-Maus) dank des 2011-er Treibers auch unter Win10 egal. Der Standardtreiber (3.8.12.0), den Win10 derzeit bei jedem Update versucht unterzuschieben, tut's nicht (gelbes Ausrufezeichen im Gerätemanager), mit dem alten (3.4.25.218) läuft alles prima.
S. R. schrieb: > Prolific hat einfach nur den Treibersupport für alte Chips eingestellt. Eben die Nachahmer waren der Grund für die Einstellung des Supports: "Please be warned that counterfeit/fake PL-2303HX Rev A (or PL-2303HXA) USB-to-Serial Controller ICs using Prolific's trademark logo, product name, and drivers are being sold in the China market." So im PL2303 Windows Driver User’s Manual zum Driver Installer v1.16.0
>Warum sollte Prolific sich verpflichtet fühlen, schlechte Nachahmer zu >unterstützen? Der PL1203 (oder wie auch immer der hieß) in meinem BU-303 ist lt. Prolific-Testprogramm echt, nur nicht die aktuelle Version, zu der sich Prolific noch verpflichtet fühlt. Man muss sich vergegenwärtigen, dass die Firma mehr Grips in die Frage gesteckt hat, wie etwas existierendes kaputtgemacht werden kann, anstatt dass alles reibungslos weiterhin funktioniert. Gibt es irgendetwas neues von Prolific? Nein, da sind nur noch Anwälte und BWLer. Die "neuen" Chipvarianten von Prolific machen genau nichts besser als die Vorgänger, sie liefern nur die technische Basis für Euthanasie am fremden Eigentum. Herrjeh, USB-Seriell-Wandler sind doch nun wirklich keine Rocket science. >Das war FTDI mit der "ich mach euch den Chip kaputt"-Nummer. Prolific und FTDI sind beide mit dieser Masche verhaltensauffällig geworden. Hatte FTDI nicht versucht, zurückzurudern? Prolific jedenfalls nicht. Jetzt macht halt WCH.cn das Geschäft. Einzige Hürde für den geneigten User: auf der komplett chinesischsprachigen Website den Treiber-Download-Link erkennen. >Der Standardtreiber (3.8.12.0), den Win10 derzeit bei jedem Update >versucht unterzuschieben, tut's nicht (gelbes Ausrufezeichen Das ist doch extrem lästig und reichlich indiskutabel. Autovergleich: nach jedem Tankstellenbesuch die Radmuttern wechseln müssen. Ich achte darauf, dass mir möglichst nur noch CH34x ins Haus kommen - Prolific jedenfalls nicht.
hrool schrieb: > Prolific und FTDI sind beide mit dieser Masche verhaltensauffällig > geworden. Was FTDI da abgezogen hat, sollte ein Grund sein, diesen Hersteller zu meiden, ich würde es Computersabotage nennen. > Jetzt macht halt WCH.cn das Geschäft. Einzige Hürde für den geneigten > User: auf der komplett chinesischsprachigen Website den > Treiber-Download-Link erkennen. Den CH340 kenne ich vom Chinuino, die Treibersuche hat mich 2015 eine Weile beschäftigt. UNO, Nano und CH340-TTL-Adapter laufen aber durchweg einwandfrei. Neben den Mikrocontrollerchen habe ich mehrere RS232-Adapter mit dem, mir gefällt, dass die keine Seriennummer haben. Also egal, welche Komponente ich an den PC klemme, der CH340 erscheint immer unter COM4, wie ich es bei der Erstinstallation festgelegt habe. Ich habe die letzten Tage meinen GPS-Kram bespielt, auch die Navilock NL-208P, welche eine serielle Schnittstelle hat. An einem CH340 kann ich sie per Terminalsoftware lesen / steuern. Das von Navilock per CD mitgelieferte Programm GPSinfoPC.exe Ver. 1.1 von Mai 2004 behauptet aber hartnäckig, am COM sei nichts angeschlossen. An einem PC mit legacy-COM oder mit FTDI-Adapter funktioniert es. Schade, ein Hinweis, dass es irgendwelche Inkompatibilitäten gibt.
hrool schrieb: > Leider aber gab es mehrere Tage lang keinen Fix (die Maus lag > mindestens anderthalb Tage am Stück draußen auf dem Fensterbrett und hat > dort fast die halbe Hemisphäre nach Süden zum freien Empfang). Deine 303 kenne ich nicht. Meine 208 (Sony cxd-2951) will mindestens vier Satelliten sehen, bevor sie ein Fix liefert! Das ist eigentlich Mist, weil der GPS-Standard weltweit nur mindestens drei sichtbare SAT definiert. In $GPRMC sind zwar Uhrzeit und Datum sinnvoll, aber der Status "A" (valid) wechselt auf "V" zurück, sobald nur drei Sat sichtbar sind. Auch nach mehreren Stunden auf der Fensterbank kam kein Fix, raus mit besserer Rundumsicht dann aber ja. Ich hatte weiter vorne einen Link zu in-the-sky.org gepostet, damit kann man recht gut abschätzen, welche GPS-SAT sichtbar sein könnten. Welche SAT gerade empfangen werden, kann man aus dem Signal-to-noise ratio in $GPGSV ermitteln. > Kann das so lange gedauert haben, bis die Almanach-Daten (nach mehreren > Jahren in der Schublade) wieder up-to-date waren? Nein, gemäß Standard soll ein Fix nach maximal 12 oder 15 Minuten erfolgen - freie Sicht vorausgesetzt. An den Daten $GPGSV kannst Du sehen, wie sich der Almanach füllt - da stehen SAT-Nummern drin, die aktuell noch nicht empfangen werden, es in naher Zunkunft aber könnten. Das ist nicht wirklich simpel, mit Systemtests und Diskussionen mit der Entwicklung habe ich verdammt viele Stunden verbracht. Ohne diesen Hintergrund hätte ich mich damit vermutlich nicht befasst, reichte ja, dass mein Mobilnavi gut funktioniert.
Manfred schrieb: > Das ist eigentlich Mist, weil der GPS-Standard weltweit nur mindestens > drei sichtbare SAT definiert. Das hat nichts mit GPS-Standard zu tun, sondern ist ein Naturgesetz. Solange der Empfänger im 3D-Modus läuft, muss er 4 unbekannte Größen bestimmen (x,y,z,t). Dafür braucht er nun mal 4 Messgrößen, nämlich die Pseudolaufzeiten zu 4 Satelliten. > Nein, gemäß Standard soll ein Fix nach maximal 12 oder 15 Minuten > erfolgen Das ist die Zeit für die störungsfreie Übertragung der Almanachdaten. Erst wenn der Empfänger die zusammen hat, kann er sich an die Berechnung vom Fix machen.
Wolfgang schrieb: > Das ist die Zeit für die störungsfreie Übertragung der Almanachdaten. > Erst wenn der Empfänger die zusammen hat, kann er sich an die Berechnung > vom Fix machen. So isses. Man muss sich dabei auch immer wieder mal klarmachen, wie schwach die GPS Signale eigentlich sind. Der Bereich um die benutzten Sendefrequenzen sollte zwar einigermassen störungsfrei sein, aber es ist trotzdem eine technische Meisterleistung, die mit den kleinen Patchantennen zu empfangen. Da können sich in Zeiten, in denen wir munter mit LTE, GSM, UMTS und wasauchimmer rumfunken, immer mal wieder Störungen des GPS Signals einschleichen. Gerade die erste Oberwelle des LTE Spektrums liegt verdammt nahe der GPS Signale.
:
Bearbeitet durch User
Ich habe ein paar GPS-Module (Fastrax UP500/UP501, Skytrak ST22) in Betrieb. Datum ist falsch. Gibt es eine einfache Methode in meiner Software die 1024 Wochen zu addieren? Irgendwelche Quellcode-Schnipsel? Gruss Harry
Crazy H. schrieb: > Gibt es eine einfache Methode in meiner Software die 1024 Wochen > zu addieren? Ja, einfach 7168 Tage zum angezeigten Datum dazu rechnen. > Irgendwelche Quellcode-Schnipsel? Jede Datumsbibliothek, die z.B. mit modifiziertem Julianischen Datum umgehen kann, kriegt das hin.
Statusmeldung/Frage: Auf meinem chinesischen Autoradio mit WinCE ist ein IGO Primo (IGO-9) drauf. Das Radio läuft mit WIN-CE Als Datum wird am 27.04.2019 angezeit: 11.09.2099 Die Uhrzeit stimmt. --> Weis jemand mehr zum IGO, z.B. welche verson wieder richtig funktioniert?
:
Bearbeitet durch User
Hallo Forengemeinde. Habe ein TomTom One XL. Dieses hat natürlich dieses Problem mit dem Datum. Wenn das Navi noch nicht einloggt ist, so zeigt es die korrekte Uhrzeit an. Hat es Connect mit GPS zeigt er 0:00 an. Ich habe zumindest 'grob' nach dem Update auf der Webseite gesucht, bin aber nicht fündig geworden. Weiß jemand wo ich dieses Update finde? Auch habe ich mit der Software - Home Probleme, da diese den Updateserver nicht findet. Da fehlt ein 'Paket'. iIst aber frisch auf XP installiert. Weiß hier jemand ne Lösung?
ACDC schrieb: > Mein Falk Fahrradnavi hat es erwischt. > Zeigt 2099-08-28 als Datum. > Update gibt es nicht mehr, da Insolvent. Jetzt gab es doch ein Update und das Datum ist wieder richtig :D
@Thomas S. Das Update für das TomTom One XL bekommst du nur über die Software TomTom Home 2, welche man bei TomTom downloaden kann. Saubere Installation vorausgesetzt. http://de.support.tomtom.com/app/answers/detail/a_id/9057/~/installieren-von-tomtom-home
:
Bearbeitet durch User
Wie mache ich denn ein OneXL-Update unter Linux? Auf der TomTom-Homepage steht nur was von "PC", aber die scheinen zu glauben, dass PC ein Synonym für "Windows" ist. Hat jemand eine Idee?
Pragmatischer Weg: jemanden suchen, der ein Windows hat und bei dem du es machen kannst. Aufwändiger, etwas nachhaltiger: VMware (Player oder Workstation, letzteres ist kostenpflichtig) installieren und USB-Gerät durchreichen, darin Windows laufen lassen. Damit habe ich bislang alle Firmware-Upgrades auf irgendwelchen Geräten durch bekommen. Sisyphos-Weg: beim Hersteller beschweren und darauf bestehen, dass es mehr als nur Windows auf der Welt gibt …
:
Bearbeitet durch Moderator
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.