På søndag risikerer GPS-udstyr at hoppe knap 20 år tilbage i tiden

Illustration: BigStock

1.024 uger. Så meget risikerer elektronisk udstyr i både, biler, robotter og militære radarsystemer at rejse tilbage i tiden natten mellem lørdag og søndag. I hvert fald hvis udstyret synkroniserer tiden med det lille baggrundsprogrammet GPSd.

Det er et lille serviceprogram, der kører i baggrunden på forskellige styresystemer, og sørger for at hente og oversætte tidsangivelser fra GPS og andre GNSS-systemer, samt det globale AIS-systemer til positionering af skibe. På den måde kan operativsystemer synkroniseres med de præcise atomure, der sidder i GPS-satellitterne.

En forholdsvis simpel programmeringsfejl, som første gang blev opdaget for to år siden, betyder at datostemplet i meget mobilt udstyr vil give problemer i weekenden, hvis ikke udstyret har været igennem en softwareopdatering inden for de seneste måneder.

GPSd er et open source-program. På programmets kodeside skriver udviklerne bag GPSd.

»GPSD findes overalt i indlejrede mobile systemer. Det understøtter kortservices på Androidtelefoner. Det bruges på droner, undervandsrobotter, førerløse køretøjer. Det er i stigende grad udbredt i bemandede fly, maritime navigationssystemer og militære køretøjer.«

GPSd kan bruges i både Android, Linux og macOS.

Læs også: Østjysk motorvej plages af radiostøj: GPS-jammere er hovedmistænkt

Y2K for GPS

Udfordringen med datoformater i positioneringssystemer er langt fra nyt, og problemet er kendt som GPS Week Number Roll-over. Det skyldes, at GPS-systemet holder styr på ugenumrene med udgangspunkt i antallet af uger siden 5. januar 1980.

Ugenummeret er lagret i en værdi, som er begrænset til 10 bit, og kan dermed kun repræsentere værdier fra 0-1023. Tælleren skal altså sættes tilbage til, nul når man går ind i den 1.024 uge. Det skete første gang 6. april 21. august 1999, og igen 6. april 2019. Næste gang den udfordring opstår er i 2038.

Men en menneskelig fejl betyder, at det lille GPSd-program tror, at det er tid til at nulstille ugenummeret, når datoen skifter fra 23. oktober til 24. oktober, og så sættes ugenummeret 1024 uger tilbage, altså marts 2002.

Læs også: GPS-modtagernes Y2K rammer til april

Maritimt udstyr truet

Udstyr der sendes tilbage til 2002, mister formentlig GPS-signalet eller modtager ikke noget GPS-signal overhovedet. Hvis enheden ikke har noget tidspunkt at forholde sig til, kan den ikke beregne, hvor lang tid det tager at komme frem til målet.

Som Stephen Williams, der har opdaget fejlen i GPSd, beskriver det:

»Jeg har en fornemmelse af, at der vil opstå nogle interessante øjeblikke i de tidlige morgentimer, når en del af verdens stratum 1 NTP ( servere, der bruger GPSD, red.) tager den lange vej tilbage til 2002.«

Det er ikke alle enheder, der benytter GPSd som vil blive påvirket. Hvis udstyret er opdateret inden for de senere måneder, er fejlen fikset, og hvis udstyret er af ældre dato - før version 3.19 - vil man ikke løbe ind i problemer, fordi versionerne før ikke indeholder fejlen.

GPSd er open source software og opdateres blandt andet af pensionisten Gary Miller. Han har fortalt det britiske medie The Register, at han fortsætter med at vedligeholde GPSd, da det er sjovere end bare at løse sudokuer dagen lang.

sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først

GPS er blevet opdateret med et nyt L2C signal der løser problemet med ugenummer:

"The GPS week number is now represented as 13 bits, or 8192 weeks, and only repeats every 157.0 years, meaning the next return to zero won't occur until the year 2137. This is longer compared to the L1 NAV message's use of a 10-bit week number, which returns to zero every 19.6 years"

Dertil kommer at de fleste GPS modtagere også kan modtage Galileo, BeiDou og Glonass. Der er altså rigeligt med måder at modtage den fulde dato i stedet for at benytte et hack på legacy signalet.

  • 9
  • 0

Men det hjælper ikke så meget hvis alt hvad man har er en ældre modtager som ellers virker fint.

Næste gang er i 2038, det vil sige om 17 år. Til den tid er der en god chance for at langt de fleste modtagere, der er i brug, har implementeret det nye GPS signal eller kan bruge et af de alternative GNSS.

Der er også en mulighed for at de på et tidspunkt slukker eller ændre legacy signalet. Der er ingen garanti for at din Garmin eTrex kan fungere til evig tid.

  • 4
  • 0

Næste gang er i 2038, det vil sige om 17 år.

For GPS-modtagere sker det vistnok rullende. Det har i hvert fald været berettet tidligere her på ing.dk, at fejlen indtræder på vidt forskellige tidspunkter for forskellige fabrikater/modeller.

Årsagen er også ret let at ræsonnere sig frem til:

Hvis man sælger en GPS-modtager nogle få år før det næste skift, gider man jo ikke have brok fra samtlige ejere, når skiftet kommer. Især ikke hvis det er i garantiperioden.

Så derfor er jeg ret overbevist om, at der i modtagernes firmware er lagt en simpel if-sætning ind, så hvis tælleren står på mindre end X uger, regnes der med eet nulpunkt for tidsregningen, og hvis tælleren er over X uger, regnes der med et andet nulpunkt.

Hvis man så bringer sådan en modtager på markedet, når tælleren står på 950 uger, kan man sætte X i firmwaren til f.eks. 900 uger. (Et hvilket som helst tal, der er mindre end 950 og tilstrækkeligt større end 0 vil opfylde formålet.) Den vil flyve rent igennem det første skift uden fejl, men 900 uger efter skiftet - eller 124 uger før næste skift - vil den begynde at fejle.

  • 3
  • 0

En GPS modtager har (normalt) et indbygget ur af armbåndsur-kvalitet, som benyttes til at slå op i tabellen over satellitpositioner for at finde de synlige. Når blot 3-4 benyttes i beregningen, så kan position og nøjagtig tid beregnes. Det er en hot-start, som er hurtig i modsætning til en cold-start, hvor "himlen" afsøges for alle mulige satellitter før de bedste udvælges til brug for beregningen.

Som bekendt (?) sker beregningen ved at løse 4 ligninger med 4 ubekendte baseret på signalernes tidsforskel (teknisk set faseforskel) fra satellitterne. Dertil et antal korrektioner hvortil blandt andet benyttes signaler i to forskellige frekvensbånd, som påvirkes forskelligt af atmosfæren.

Mig bekendt sendes fra satellitterne OGSÅ et tidssignal, som ikke er helt præcist og korrigeret for transmissionstid, men som kan have gode anvendelser i forskelligt udstyr hvor fuld tidspræcision (og dermed synkronisering) ikke er et krav. Som jeg forstår det, at det DETTE tidssignal som attiklen egentlig handler om.

P.S.: Jeg finder min gamle Garmin foretrex 201 frem. Idag OK position og tid (efter flere årss pasivitet i en skuffe).

  • 7
  • 0

Mig bekendt sendes fra satellitterne OGSÅ et tidssignal, som ikke er helt præcist og korrigeret for transmissionstid

Det sendes som en del af nav data som worst case tager 12-13 minutter at få downloaded. Det er derudover en tid som er defineret ud fra det omtalte uge system, idet man skal lægge uge nummer sammen med tids koden for at få præcis tid. Det kan GPS'ens position sw sikkert godt hitte rede i (på nyere GPS systemer?) men om det gælder for alle er lidt svært at overskue.

Det er vel næppe heller et problem på glonass og galileo, så hvad 3-band receivere lige gør kræver vist indgående kendskab til hver modtagers SW...

  • 0
  • 0

Jeg kan ikke lide du taler om "præcis tid". Principielt, og det gælder for alle positionssystemerne, så løses 4 ligninger, hvilket blandt andet giver en præcis tid. (Dette har så vist sig at have ganske mange anvendelser - i tillæg til den oprindelige position.).

HVIS et klokkeslet sendes fra en satellit, så vil modtageren ALTID have en fejl svarende til transmissionstiden (distance) til satellitten - og den afhænger så af den specifikke satellits position i transmissionsøjeblikket. Sikkert under 0,2 sekund. Det er helt godt nok til mange, mange anvendelser, og modtageren behøver derfor blot modtage eet signal, og ikke 4 for at løse ligningerne. Det er så måske minutter hurtigere end en fuld løsning af ligningerne.

  • 2
  • 0

En GPS modtager har (normalt) et indbygget ur af armbåndsur-kvalitet, som benyttes til at slå op i tabellen over satellitpositioner for at finde de synlige. Når blot 3-4 benyttes i beregningen, så kan position og nøjagtig tid beregnes. Det er en hot-start, som er hurtig i modsætning til en cold-start, hvor "himlen" afsøges for alle mulige satellitter før de bedste udvælges til brug for beregningen.

Moderne modtagere har nok processeringskraft til at søge efter samtlige satelitter på samme tid, i praksis ved at køre FFT på signalet. Efter at have dekodet den første pakke fra en satelit tager det 30 sekunder at modtage "ephemeris" som er præcise oplysninger om satelittens bane. Det tager 12 minutter at modtage "almanac" som blandt andet indeholder en atmosfærisk model, der bruges til at forbedre nøjagtigheden.

Ældre modtagere skulle bruge almanac for at få lock på satelitterne. I en kold start situation skulle den derfor først finde lock på en enkelt satelit uden almanac, hvilket kunne tage noget tid. Herefter downloade almanac fra denne ene satellit. Først herefter kunne man slå op i almanac og få hurtig lock på de øvrige satelitter. Det er derfor vi husker det, som at det i gamle dage kunne tage en rum tid at få GPS lock første gang. En almanac er gyldig i op til 2 uger og bliver typisk gemt i gps modtageren, så det ikke tager så lang tid næste gang.

Moderne modtagere kan derimod have lock efter kun 30 sekunder, også i en kold start situation. Positionen bliver mere nøjagtig efter 12 minutter når den også har en atmosfærisk model. Jeg ved dog ikke om man kan hente almanac hurtigere ved at downloade fra flere satelitter samtidig.

Meget moderne modtagere, de såkaldte dual frekvens modtagere med support for L2C signalet, kan dog få en endnu mere præcis position med det samme og behøver ikke den atmosfæriske model.

  • 6
  • 0

Mig bekendt sendes fra satellitterne OGSÅ et tidssignal, som ikke er helt præcist og korrigeret for transmissionstid, men som kan have gode anvendelser i forskelligt udstyr hvor fuld tidspræcision (og dermed synkronisering) ikke er et krav. Som jeg forstår det, at det DETTE tidssignal som attiklen egentlig handler om.

Artiklen omhandler et program som bruges til at synkronisere NTP servere, det vil sige tidsservere på internettet. Disse har en typisk precision på et millisekundt. Ugenummer sendes hvert 6. sekundt fra satelitterne og er en del af det primære signal der bruges til navigation.

Men bemærk at vi ikke er nær en dato hvor ugenummer resetter til 0. Det sker først om 17 år. Mon ikke sagen er at omtalte program har et indbygget forskudt nulpunkt for ugenumre, i stil med det du foreslår?

Man skal måske også bemærke at der ikke er et mere præcist tidssignal. Det fungere ved at satelitten sender et 6 sekunder langt signal, der sendes med 50 bits per sekundt, og dette signal indeholder den eksakte tid på starten af næste periode, inklusiv ugenummer, timenummer, sekundtnummer etc. En periode starter altid eksakt, så der er ikke nogen grund til at angive en masse nuller i tiden. Du starter bare dit ur præcis når du detekterer første bit i næste periode. Dvs i praksis faselåser du en internt frekvensgenerator til GPS satelitternes signal.

  • 3
  • 0

Men bemærk at vi ikke er nær en dato hvor ugenummer resetter til 0. Det sker først om 17 år. Mon ikke sagen er at omtalte program har et indbygget forskudt nulpunkt for ugenumre, i stil med det du foreslår?

Idet artiklen advarer om et problem ved overgangen fra 23. oktober til 24. oktober, lyder det mest som om der er en fejl hvor cifrene "1023" bliver genkendt i et felt der faktisk indeholder MMDD af en dekodet dato, i stedet for et 4-cifret ugenummerfelt ...

Det undrer mig mere at selvom fejlen skulle være blevet opdaget for to år siden, skal programmet være opdateret "inden for de senere måneder" for at have en rettelse.

  • 1
  • 1

Så kan jeg pakke sekstanten ned igen, og fortsat bruge det gratis kortplotterprogram OpenCPN sammen med GNSS- antennen til under en hund...

  • 4
  • 0

Idet artiklen advarer om et problem ved overgangen fra 23. oktober til 24. oktober, lyder det mest som om der er en fejl hvor cifrene "1023" bliver genkendt i et felt der faktisk indeholder MMDD af en dekodet dato, i stedet for et 4-cifret ugenummerfelt ...

Af nysgerrighed fandt jeg den patch der fikser problemet. Dette er koden som er fikset:

/* sanity check week number, GPS epoch, against leap seconds * Does not work well with regressions because the leap_sconds * could be from the receiver, or from BUILD_LEAPSECONDS. */

if (0 < session->context->leap_seconds && 19 > session->context->leap_seconds && 2180 < week) {

    /* assume leap second = 19 by 31 Dec 2022    
    so week > 2180 is way in the future, do not allow it */  

    week -= 1024;  

    GPSD_LOG(LOG_WARN, &session->context->errout,    
             "GPS week confusion. Adjusted week %u for leap %d\n",    
             week, session->context->leap_seconds);  

}  

Vi er netop skiftet fra GPS uge nummer 2180 til 2181. Ovenstående kode antager at når vi kommer til uge 2181 så har vi mindst 19 skudsekunder. Hvis ikke, så trækker vi uden begrundelse 1024 uger fra datoen. Problemet er så at vi nu er i uge 2181 og der er kun 18 skudsekunder.

Bortset fra ovenstående "sanity check der går galt" så er strategien i programmet at beregne "rollover" fra computerens interne ur på tidspunktet da programmet blev startet.

Jeg kan i øvrigt konstatere at GPS'en i min bil ikke havde problemer her i morges :-)

  • 2
  • 0

Artiklen omhandler et program som bruges til at synkronisere NTP servere, det vil sige tidsservere på internettet. Disse har en typisk precision på et millisekundt. Ugenummer sendes hvert 6. sekundt fra satelitterne og er en del af det primære signal der bruges til navigation.

Når man arbejder med financielle transaktioner skal visse ting registreres med microsekund præcision (krav fra myndighederne). Der bruger man også normalt GPS signalet fordi det gør alle andre og så opstår der ikke issues omkring hvis GLONASS eller en af de andre er ude af sync.

  • 0
  • 0

Der bruger man også normalt GPS signalet fordi det gør alle andre og så opstår der ikke issues omkring hvis GLONASS eller en af de andre er ude af sync.

Jeg modsiger dig ikke, men GPS er baseret på en amerikansk tidsstandard. Galileo er baseret på den europæiske tidsstandard. Skulle der opstå en forskel, så er det ved lov Galileo der er den korrekte?

En anden ting er at Galileo er blevet lovpligtet i mobiltelefoner fra næste år og allerede er lovpligtigt i biler (til E112 funktionen).

I USA er det kun GPS der er lovligt at bruge. Galileo har dog efter ansøgning fået lov til at blive brugt af civile der ikke arbejder for staten.

I Rusland er Glonass lovpligtigt. Alle solgte GNSS enheder skal supportere Glonass.

I Kina er BeiDuo lovpligt. Alle solgte GNSS enheder skal supportere BeiDuo.

Det er derfor at stort set alle GNSS enheder, herunder specielt dem i mobiltelefoner, i praksis supportere alle fire systemer. Ellers er der en eller flere verdensdele hvor de ikke kan sælges.

Fun fact: I USA er det ulovligt at modtage andre signaler end GPS og Galileo. Din mobiltelefon deaktiverer derfor modtagelse af de andre systemer hvis du tager derover. Som følge heraf har de dårligere signal end vi har i vores verdensdel. Her i Danmark kan din GNSS modtager bruge alle fire systemer samtidig og udnytte det til at udregne en mere præcis position, til hurtigere at få lock og til at fungere under forhold hvor kun få satelitter er synlige.

  • 7
  • 0

Jeg modsiger dig ikke, men GPS er baseret på en amerikansk tidsstandard. Galileo er baseret på den europæiske tidsstandard. Skulle der opstå en forskel, så er det ved lov Galileo der er den korrekte?

Man må bruge den tidskilde man har lyst - i det strammeste setup må der være en forskel i forhold til UTC på 0.1ms. Men man skal registrere med en præcision på 1 μs. Hele ideen er at man skal kunne genskabe en sekvens af events på et site. Men når det er på tværs af sites så giver det naturligvis ingen mening med den præcision.

  • 2
  • 0

Skulle der opstå en forskel, så er det ved lov Galileo der er den korrekte?

Det afhænger hvilken del af virkeligheden du tilhører f.eks. er jeg ret sikker på at militæret i hele NATO bruger GPS også i EU.

Bortset fra det så kan vi jo altid tillempe fly løsningen (vi abstraherer lige fra Boeing som havde valgt at glemme den): læse tiden fra GPS, Galileo og Glonass og den som afviger er den som er forkert - de er alle tre styret af atomure bare på forsk. kontinenter så præcisionen er i orden (i alle tre).

  • 1
  • 0

Jeg nævnte i min #9 min gamle Garmin foretrex 201 fra 2008.

Ved opstart lørdag 23/10 - intet problem - selvom den havde været slukket længe. Ved opstart mandag 25/10 kunne den indledningsvis ikke finde satellitterne ("Er du inde ?"). Efter en rum tid var alt OK (position og tid). Det lignede en kold-start - men det er bare gæt. Ved opsrat tirsdag 26/10 så det "normalt" ud (men det er jo ikke noget jeg normalt måler tiden for).

Min bil-navigator (Garmin fra 2011) startede upåklageligt.

Jeg har ikke opdateret de nævnte apparater i flere år.

  • 0
  • 0

Off topic, men aligevel:

I en helt anden forbindelse er jeg blevet advaret om en tidsforskel mellem UTC og GPS-tid på 17 sekunder, hvorfor "UTC-tiden" skulle benyttes til kapsejlads.

Ringer det klokker for nogen, eller er det en "and" ?

  • 0
  • 0

I en helt anden forbindelse er jeg blevet advaret om en tidsforskel mellem UTC og GPS-tid på 17 sekunder, hvorfor "UTC-tiden" skulle benyttes til kapsejlads.

Ringer det klokker for nogen, eller er det en "and" ?

GPS sender tiden uden skudsekunder hvor UTC er med skudsekunder. Forskellen er pt. 18 sekunder. GPS udsender dog også information om hvor mange skudsekunder der er til UTC, så de fleste GPS enheder kan godt vise korrekt UTC tid.

Læs mere her: https://da.wikipedia.org/wiki/Skudsekund

  • 0
  • 0

Tak for svar og forklaring. Også at tallet "cirka 17" har en forklaring.

Men det rejser unægteligt spørgsmål: - mon der i kortplottere (det sædvanlige navn for "en GPS i en båd") er en option for at vise sand UTC tid>< GPS tid ?

  • mon forskellige kortplottere viser forskelligt ? (den ene eller den anden tid ?).

  • eller vil forskellige kortplottere vise forskelligt (måske grundet forkert setup?) ?

  • mon "gamle" sejlere som endnu øver sig med sekstant er opmærksom på dette ? (den nævnte tidsdifference er langt udover de andre fejl som kan opstå).

Udover de radio-tidssignaler som findes, så er det jo ret svært at få en bare sekund-nøjagtig tidsreference. DR er jo næppe god nok - med mindre de faktisk har korrigeret for deres digitale forsinkelser når de sender Rådhus-slaget. Som de fleste med fibernet eller internet TV ved, så er dise billeder ikke i sync med radio eller luftbåren TV fra sendemast.

  • 0
  • 0

Min mobil (Telmore) er altid inde for +/- 1/2 sek. Et billigt ur nykalibreret på Frankfurtsenderen er det normalt også.

  • 0
  • 0
Bidrag med din viden – log ind og deltag i debatten