Gps-problemen TomTom worden veroorzaakt door 'schrikkeljaarbug'

Het probleem met TomTom-apparatuur die geen of een slecht gps-signaal kan ontvangen, wordt veroorzaakt door een 'schrikkeljaar-bug'. Een fix is er nog niet, hoewel een reset van het apparaat het probleem tijdelijk kan verhelpen.

TomTom-gebruikers hebben sinds zaterdag 31 maart geen of een slechte gps-ontvangst. TomTom zegt de 'hoofdoorzaak' voor die problemen inmiddels te hebben gevonden. Er zit een bug in de manier waarop de software met een schrikkeljaar omgaat.

"We werken keihard aan een oplossing", zegt TomTom-woordvoerder Wouter Glaser. "Meer kan ik op dit moment niet zeggen." Op zijn site geeft TomTom aan later op dinsdag met meer informatie te komen, maar of er dan al een software-update is, is nog niet bekend. Volgens TomTom hebben klanten aangegeven dat een reset van het apparaat het probleem tijdelijk kan verhelpen.

Wat het probleem precies is, is onduidelijk. Gps-navigatie leunt op tijd; op basis van de vertraging van het signaal van verschillende navigatiesatellieten, wordt de positie van een gebruiker bepaald. Wanneer de tijdafhandeling van een apparaat verstoord is, ligt het dus voor de hand dat het apparaat in de war kan raken. Het jaar 2012 is een schrikkeljaar; maart is de eerste maand volgend op de schrikkelmaand februari en wellicht ging er daardoor op 31 maart iets fout.

Reacties (93)

[jj71]

Op het eerste gezicht denk je: dom, blijkbaar wordt die software niet goed getest.

Maar het systeem waar ik aan werk bleek ook een winter/zomertijd bug te bevatten. We hebben een batch job die 's nachts om 2:30 uur draait. Maar het tijdstip 25/03/2012, 02:30 bestaat niet, want de klok springt dan van 01:59 naar 03:00.

Dus crash, een exception toen het systeem probeerde op dat niet-bestaande tijdstip een job te schedulen. We hadden hiervoor wel een test. Maar het probleem was dat deze bug alleen optrad als je de software op de dag van de winter-naar-zomertijd overgang had opgestart. Als je het bijvoorbeeld op de 24e had opgestart was het geen probleem. Toevallig moest het systeem op de 25e opnieuw gestart worden en toen merkten we het probleem op...

Het blijft gewoon lastig en dingen kunnen altijd subtieler zijn dan je op het eerste gezicht zou denken.

[Reactie gewijzigd door jj71 op 23 juli 2024 09:26]

[edebee]

Sorry hoor maar iedere ict'er ( programmeur / tester) houdt toch rekening met het schikkeljaar in zowel programeren als testspecificaties. TOMTOM zit toch allang genoeg op de markt dat het niet de eerste keer is dat er een schrikkeljaar voorbij komt

[dennizzz]

Zo'n situatie is lastig te testen hé. Je kunt wel je TOMTOM op 29 feb zetten, maar om dat ook met de satellieten te doen is vrij lastig. En waarschijnlijk veranderd er het nodige tussen twee schrikkeljaren in en zat die code er 4 jaar geleden nog niet.

[The Van]

Mag dan wel lastig te testen zijn, maar "de" schrikkelbug stamt al uit 2000.
Een jaar is een schrikkeljaar, als het jaartal deelbaar is door 4. Tenzij het deelbaar is door 100, dan is het geen schrikkeljaar. Tenzij het deelbaar is door 400, dan juist is het weer wel een schrikkeljaar.
Tenzij het deelbaar is door 1000 - dan is het GEEN schrikkeljaar. Sinds de uitvinding van computers en de in sommige systemen idiote manier van datum/tijdbepaling (het aantal seconden sinds 00:00 op 1-jan-1970) is dat pas 1 keer voorgekomen: in 2000!

Het had m.i. dus niet mogen voorkomen, het algoritme was sinds 2000 weer eens in zijn geheel onder de aandacht gebracht (veel programmeurs hielden er na de eerste uitzondering mee op).

Er zijn trouwens nog een paar uitzonderingen, maar die zijn niet onder een wetmatigheid te vangen: de jaren 4000, 6000, 7200, 8400, 9200 en 10000 zouden GEEN schrikkeljaren moeten zijn.

[rob12424]

2000 is mileniumprobleem TomTom heeft Linux. Leuke feitjes maar Unix en Linux werken met timestamps en dus anders als alle andere osen zoals windows (macosx weet ik niet) dus die bug die jij noemt is hierop bijna zeker niet van toepassing!

[Anoniem: 364437]

Mileniumprobleem had niets met Windows te maken en was net zo goed met programma's onder andere OSen en Windows gebruikt intern ook timestamps.

[the___butcher]

Hoe kom je erbij dat jaartallen die deelbaar zijn door 1000 geen schrikkeljaar zijn? In 2000 hadden we gewoon een 29 februari hoor.
Zie ook http://en.wikipedia.org/wiki/Leap_year.

[Anoniem: 120539]

Elke 4 jaar. Behalve eeuwwisselingen, dan niet. Behalve als de eeuwwisseling deelbaar is door 400, dan weer wel. (2000 was dus zo'n bijzonder geval)

[mjtdevries]

Dat zou je denken, maar ik heb al ontelbare bugs langs zien komen die te maken hebben met schrikkeljaren, zomertijd wintertijd etc etc.

En bij grote bedrijven: Nortel, Cisco, Microsoft, IBM, Apple en ga zo maar door.

[TDeK]

Sorry hoor maar iedere ict'er ( programmeur / tester) houdt toch rekening met het schikkeljaar in zowel programeren als testspecificaties.

Mijn backup is ook misgegaan, omdat deze op 25-03-2012 om 2:00u een backup wilde draaien. Het duurde even voordat ik doorhad dat dat tijdstip helemaal niet bestaat ivm het automatisch aanpassen van de systeemklok.
Conclusie: je kunt niet alles testen of weten, aangezien er soms situaties optreden die je niet had verwacht (denk bijvoorbeeld aan de Apple bug in hun wekker).

[Reactie gewijzigd door TDeK op 23 juli 2024 09:26]

[MBV]

Het gaat vermoedelijk om de nieuwe reeks, NAV3, met de nieuwe MyTomtom software (opvolger van Home). En die reeks is er nog geen 4 jaar

[cire]

Tja, bij de meeste fouten is het achteraf makkelijk roepen dat je er toch "gewoon" rekening mee had moeten houden. In de praktijk blijkt dat toch allemaal een stuk ingewikkelder te zijn.

Bedrijven zijn commercieel en willen binnen bepaalde tijd en geld iets opleveren. Bij voorkeur natuurlijk zonder kwaliteitsverlies

[Dennahz]

En welke types hebben hier precies last van? is dit sinds een bepaalde update van de software?

Netjes dat ze hier zo duidelijk mee naar buiten komen en de schuld op zich nemen

[TDeK]

Het lijkt erop dat het stukje software, dat aan de hand van de datetime bepaald welke satellieten er op locatie X aan het firmament staan, niet meer klopt door deze schrikkelbug. Dan is je TomTom in feite aan het luisteren op kanalen waar hij GPS sats verwacht, terwijl er op dat moment andere sats staan.
Dit truukje doet TomTom overigens omdat je anders minimaal 30 seconden moet wachten op een (klassieke) GPS fix, omdat dat de ID interval van het GPS signaal is. De nieuwe modules (die wel sneller een fix krijgen) maken gebruik van een nieuwer deel van het GPS signaal, L1C als ik me niet vergis.

[MBV]

Ik hoorde of las gisteren dat het alleen om NAV3-producten, de producten die met MyTomtom werken, ging. En dat het inderdaad iets te maken leek te hebben met de Ephemeris-data (wat Rick2910 uitlegt). Dan zou het probleem alleen mogen optreden als je een nieuwe tomtom (bijv. Go1000) aan je PC hangt om een update binnen te krijgen.

Het zou wel erg raar zijn dat het alleen bij MyTomtom gebruik fout gaat: via GPRS wordt datzelfde bestand ook binnen gehaald, en mijn Go1000 met Live heeft nergens last van.

[Anoniem: 120539]

Toevallig gebruik ik sinds vrijdag een TomTom Blue&Me Live 2. (Is volgens mij een 1000 variant i.s.m. de Fiat Group) Deze heeft het probleem wel.
Ik was dus vooralsnog niet echt te spreken over mijn eerste ervaringen met een TomTom product; nu is duidelijk waarom.
Zullen ze vast hard mee aan het werk zijn bij TomTom, dus ik verwacht zeer binnenkort wel een fix te ontvangen.
Ben benieuwd!

[Anoniem: 251679]

Er zijn meer systemen die een dergelijke bug bevatte. Op de XENTA-betaalterminals in de winkels staat sinds dit weekend de tijd een uur verkeerd.
Dit wordt veroorzaakt door de combinatie schrikkeljaar en winter>zomertijd.
Exacte details van het problmeen ken ik niet, maar sommige dingen moet je gewoon tegen aan lopen. Als je die wil testen moet je de afweging risico vs kosten gaan maken.

[SinergyX]

Dat iets een uur achter/voor gaat lopen, zal mij bar weinig interesseren (mijn auto-klok gaat ook niet mee met winter/zomertijd), die betreffende kassa's zullen wel gewoon blijven werken. Tomtom in dit geval werkt gewoon helemaal niet meer.

Gister nog geprobeerd dat ding aan de updater te hangen, 'de verbinding met uw tomtom is verbroken'.. Ik sta echt op het punt om gewoon weer een XL te halen die op de oude Home werkt ipv dat rampstukje software dat MyTomTom heet.

Een beetje software zou toch gewoon rekening moeten houden met zulke 'problemen', het hoeft het niet te ondervangen, maar een simpele 'fix' zou toch wel gewoon mogelijk moeten zijn? (zie PSN op 29 februari, of Nokia update).

[Reactie gewijzigd door SinergyX op 23 juli 2024 09:26]

[Anoniem: 440278]

In het geval van de kassas is het ook onhandig omdat het volgens mij dan zo is dat als jij pint dat er een andere tijd op jouw bankafschrift komt.

[Anoniem: 21956]

Niet helemaal waar. Het klopt dat de Xenta terminals niet volledig volgens schema de display tijd hebben aangepast. Liep de tijd op de terminals sinds dit weekend toevallig een uur voor? Dan is de kans groot dat de tijd tussen ingaan zomertijd en afgelopen weekend handmatig de tijd is aangepast.

Overigens werd op de pin bon (zowel via de kassa als rechtstreeks via de Xenta's ) wel direct na het ingaan van de zomertijd de juiste tijd genoteerd.

[Reactie gewijzigd door Anoniem: 21956 op 23 juli 2024 09:26]

[Technomania]

Vreemd dat die bug niet in 2008/2004 naar voren is gekomen.

Het siert TomTom dat ze openheid geven alhoewel ik dit wel slordig vind. Je zou zeggen dat programmeurs na de "milleniumbug" rekening houden met afwijkende data

[Big Womly]

Zo vreemd is dat niet. Tussen 2008 en 2012 zitten 4 jaar. Gedurende die 4 jaar is er permanent aan de software gesleuteld. Bug fixes, optimalisaties, uitbreidingen, ...
Hierdoor kan het zijn dat de toenmalige code aangepast moest worden en waardoor de bug er is ingeslopen

[FreshMaker]

Tja, en in 2008 hebben ze het concept schrikkeljaar uitgevonden ?

dus nee, het is wel degelijk vreemd, aangezien elke digitale klok rekening dient te houden met het schrikkeljaar

[Loller1]

Dat een digitale klok er rekening mee houd, wil nog niet zeggen dat het achterliggende programma dat ook doet.

[MSalters]

Niet alleen de TomTom software. Ook de GPS chip en de software daarvan is compleet vervangen (was SiRF, is nu GlobalLocate).

[burgt]

De bug treed dan ook alleen op op de laatste generatie PND's, die waren er nog niet in 2008

[Anoniem: 309700]

Ben benieuwd of ze hiervoor ook voor de oudere tomtom's update's gaan uitbrengen. Zo heb ik nog een oude tomtom in de auto liggen. Wordt sporadisch gebruikt, alleen als mijn tel leeg is. Maar zou toch wel fijn zijn als de GPS het gewoon doet.
Overigens vind ik dit wel een erg slordige fout, zeker voor een bedrijf als tomtom. Dit soort dingen moet je toch van tevoren simuleren.

[Iblies]

TomTom is als bedrijf niet zo heel oud en ze hebben verschillende producten van scratch opgebouwd. Dat je daarmee niet alles mee kunt controleren is een reële optie.

Dergelijke problemen moeten wel een signaal zijn maar andere bedrijven. Apple's verslaping hebben ze nu gehad, de schrikkelbug,
ik ga er van uit dat bedrijven mogelijke scenario's allemaal doornemen en dat ze voorlopig geen storingen krijgen tgv tijdinterpretaties.

[analog_]

Van scratch door een linux kernel te compileren in 1991 ofzo.

[MSalters]

Ben benieuwd of ze hiervoor ook voor de oudere tomtom's update's gaan uitbrengen. ... zou toch wel fijn zijn als de GPS het gewoon doet.

Niet nodig; de oude apparaten hebben het probleem niet.

[Ireyon]

Dit wisten ze 4 jaar geleden toch ook dat er schrikkeljaren zijn? En TomTom gaat al wat langer mee dan 4 jaar..

[LoekVe]

Voor de NAV3 apparaten (de nieuwere apparaten van TomTom: TomTom GO 8xx / 100x / 20xx / Via en Start 20 Series) is 2012 de eerste keer dat ze een schrikkeljaar 'meemaken'. Het zijn dan ook enkel deze modellen die last van dit probleem hebben. De oudere modellen hebben nergens last van omdat die software inderdaad al veel langer bestaat en de 'schrikkeljaarbug' niet hebben.

[g4wx3]

eerste keer dat ik een dergelijke bug tegenkwam was in 2004 op een echte compaq pentium 1 ook eind maart.

oneinidige kalenders maken is eigenlijk heel moeilijk, als je oneindig vooruit of achteruit wilt kunnen gaan, zoveel kleine uitzonderingen, 300 jaar geleden zijn er bijvoorbeeld in de herfst zomaar 20 dagen geschrapt geweest.

Het zou makkelijker worden als we naast ons huidige kalendersysteem ook alvast een makkelijke nieuwe kalender gebruiken. Over 25 jaar is het probleem voor goed en altijd de wereld uit

[moreasy]

"300 jaar geleden zijn er bijvoorbeeld in de herfst zomaar 20 dagen geschrapt geweest.
"
Cool, heb je een linkje ofzo?

[The Van]

Jawel: http://nl.wikipedia.org/w..._de_gregoriaanse_kalender

Ook leuk: tot nog niet zo heel lang geleden (eind 19e eeuw?) werd nog Deventer tijd gehanteerd - 20 minuten later dan Amsterdam

[cire]

Volgens mij is bij het bouwen van het spoorwegnet de tijd binnen Nederland gelijkgetrokken. Daarvoor had elke plaats/gebied zijn "eigen" tijd.

[Pablo]

ik heb hier gelukkig geen last van.
wel dat mijn live service geen verbinding kan maken , zoals file meldingen en mobiele filters.
erg hinderlijk aangezien je daar voor betaald

[Anoniem: 452494]

Dit heb ik vaker meegemaakt, ook met de PS3 was er ook hetzelfde probleem eerst, PSN werkte niet voor 1 dag door schrikkeljaar.

Kan het zijn dat de systeem niet rekening hield met schrikkeljaar en daardoor 1 april gaf i.p.v. 31 maart? Dus 1 dag eerder begonnen met maart.