Mange GPS-mottakere vil trolig begynne å feile i april

[Harald Brombach (digi.no)]

En epoke er snart over.

Mange GPS-mottakere vil trolig begynne å feile i april

[Ziff]

Bygger man fremdeles systemer som vil feile på denne måten? Plass til å lagre data er ikke noe problem lenger, men programmeringsjobben har vel oftere skylda. Håper at dette er langt mindre problem om 5, 10, 20 eller 30 år fordi systemer varer ofte lenger enn man har regnet med.

[del_diablo]

Uke 2048 i april?

Nice

[G0RJS955]

Bygger man fremdeles systemer som vil feile på denne måten? Plass til å lagre data er ikke noe problem lenger, men programmeringsjobben har vel oftere skylda. Håper at dette er langt mindre problem om 5, 10, 20 eller 30 år fordi systemer varer ofte lenger enn man har regnet med.

 

Joda, jeg ser mange systemer som setter av bare 2 siffer for årstallet, så et nytt rollover-problem for GPS er bare å forvente. Jeg var endel involvert i Y2K-rydding, og husker første GPS-rollover. dDet meste gikk greit, bortsett fra bilnavigasjonssystem brukt i Japan. I et land der en ikke baserer seg på gatenavn, ble det ganske månelyst.

 

Vi er nå mindre enn 20 år fra Unix rollover, og forberedelsene er ennå ikke over der. Vi har mye spenning foran oss.

[Ziff]

Hehe det var jo lovende...

 

Vi klarer å benytte kvantefysikk til enorme fremskritt for alt fra AI til forbrukerelektronikk, men vi klarer ikke planlegge relativt få år frem i tid 

[oskaremil]

Bygger man fremdeles systemer som vil feile på denne måten? Plass til å lagre data er ikke noe problem lenger, men programmeringsjobben har vel oftere skylda. Håper at dette er langt mindre problem om 5, 10, 20 eller 30 år fordi systemer varer ofte lenger enn man har regnet med.

 

Fact: Plass til å lagre data er ikke et problem

But: å overføre minst mulig data raskest mulig fra en satellit flere hundre meter oppe i luften for å gi en nær realtime nøyaktig posisjon på et element som beveger seg i en ikke regemessig linje (bilen din) i hastigheter opp til 1000 km / t (et fly) krever at man ikke overfører mere data enn overhodet nødvendig

[Simen1]

Det var nå uansett pessimistisk av utviklerne å tro at GPS-systemet ikke hadde nubbsjans til å bli mer enn 19,7 år gammelt. Jeg synes de burde spandert 12-16 bit der i stedet for 10. Da hadde det tatt 78-1261 år før det hadde blit noe problem.

Endret 15. februar 2019 av Simen1

[Bjarne Nilsson]

Det var nå uansett pessimistisk av utviklerne å tro at GPS-systemet ikke hadde nubbsjans til å bli mer enn 19,7 år gammelt. Jeg synes de burde spandert 12-16 bit der i stedet for 10. Da hadde det tatt 78-1261 år før det hadde blit noe problem.

 

Vel Etter som ikke absolutt alle gps mottakere slutter. Fungere ser det jo ut som det er tatt høyde for i signslene du mottar, men at produsentene av motakete har valgt å gjøre en bilig løsning for p tjene litt mer/enhet og garantere et nytt salg om noen år etter prod dato. Kipt er det men sånn erre bare håper galileo mottakere har litt strengere krav slik at vi unngår sakne problem om 19 År

[ChrZZ]

 

Bygger man fremdeles systemer som vil feile på denne måten? Plass til å lagre data er ikke noe problem lenger, men programmeringsjobben har vel oftere skylda. Håper at dette er langt mindre problem om 5, 10, 20 eller 30 år fordi systemer varer ofte lenger enn man har regnet med.

 

Joda, jeg ser mange systemer som setter av bare 2 siffer for årstallet, så et nytt rollover-problem for GPS er bare å forvente. Jeg var endel involvert i Y2K-rydding, og husker første GPS-rollover. dDet meste gikk greit, bortsett fra bilnavigasjonssystem brukt i Japan. I et land der en ikke baserer seg på gatenavn, ble det ganske månelyst.

 

Vi er nå mindre enn 20 år fra Unix rollover, og forberedelsene er ennå ikke over der. Vi har mye spenning foran oss.

Jeg har selv tenkt en del på unix time rollover som kommer jeg også, men hvor mye vil du anta i dag er berørt av dette (er vel 32bit only?) og hvor mye vil gjelde i 2038?

[G0RJS955]

Fact: Plass til å lagre data er ikke et problem

But: å overføre minst mulig data raskest mulig fra en satellit flere hundre meter oppe i luften for å gi en nær realtime nøyaktig posisjon på et element som beveger seg i en ikke regemessig linje (bilen din) i hastigheter opp til 1000 km / t (et fly) krever at man ikke overfører mere data enn overhodet nødvendig

Flere hundrede meter opp i luften må være dagens underdrivelse, det er 20000 km ut i verdensrommet.

Videre sender satellittene ut flere signaler, et klokkesignal i sanntid, og datarammer med lav bitrate med bl.a. kalender og ephemeris. Om en hadde lagt på noen bit til, måtte en bruke litt lengre tid på oppstart, men ikke ekstremt mye. Det går mye skjult trafikk i datarammene, men mye kan en hente ned via alternativer som A-GPS. 

 

Artikkelen er uklar på detaljene, men jeg mistenker det er på L5-båndet at den utvidede kalenderinformasjonen ligger, og bare ytterst få sivile mottakere finnes, deriblant en Broadcom-chip som er å finne i Huawei P20, og muligens nyeste chipset fra Qualcomm. Besynderlig nok omtales ikke L5 i omtalen av nye mobiltelefoner, nå¨r dette tross alt er en vesentlig nyhet.

[Yitzak]

Når dette Y2K "problemet" var nært forestående, brukte Norge og mange andre land milliarder på å unngå "katastrofen". Med noen få Unntak, dvs noen få fattige land i Afrika, (Som Nigeria) men absolutt ingenting skjedde i de landene som IKKE hadde gjort noen "forberedelser" på 2000 problematikken. Ingen problemer, skader, katastrofer, eller andre ting som var forutsett "kunne skje".

 

En skal bare se at dette er atter et svindelopplegg tilsvarende Y2K ??

[G0RJS955]

Jeg har selv tenkt en del på unix time rollover som kommer jeg også, men hvor mye vil du anta i dag er berørt av dette (er vel 32bit only?) og hvor mye vil gjelde i 2038?

Unix-maskiner av forskjellig slag er i mye infrastruktur som telefonsentraler, routere, radarsystemer (på skip, i fly, i bakkeinstallasjoner), militært og industrielt utstyr med mer. Der du ser en VME-hylle, er det store sjangser for at det kjører en Unix-variant, eller et sanntidssystem med Unix-kompatibel klokke. Jeg har vært med på mange slike prosjekter, og det er mye mer av dette enn folk aner.

 

I embedded-verdenen er ting gjerne plassbegrenset, så 32-bit er vanlig, selv om 64-bit kommer. Slike systemer er basert på plattormer som er garantert å være i produksjon i 20 år med ytterligere kanskje 10 år med reservedeler og service, så mye av dette er i utgansgpunktet gammelt, og i en del tilfeller er de rett og slett blitt glemt. Jeg har hørt historier om servere som ble igjen da partisjonsvegger ble blyttet, og ble stående igjen i et avlukke uten vinduer eller dører, og bare gikk og gikk. Jeg hørte dette av en sysadmin som fikk i oppgave å finne maskinen, men måtte gi opp og istedet slå av serveren permanent via nett.

[OlaML]

Det er ikke vanskelig å kode dingsen til å lese uketallet riktig, men det kan hende at de dingsene som ikke er kodet slik er veldig enkle dingser laget i få versjoner. Kanskje forskningsutstyr, merking av hval o.l.?

[Simen1]

Apropos uketall, hvorfor i all verden bruker de uketall i det hele tatt? Er det ikke bedre å bruke f.eks årstall? 8 bit burde holdt i lange baner da.

[nebrewfoz]

Når dette Y2K "problemet" var nært forestående, brukte Norge og mange andre land milliarder på å unngå "katastrofen". Med noen få Unntak, dvs noen få fattige land i Afrika, (Som Nigeria) men absolutt ingenting skjedde i de landene som IKKE hadde gjort noen "forberedelser" på 2000 problematikken. Ingen problemer, skader, katastrofer, eller andre ting som var forutsett "kunne skje".

 

Kan det tenkes at de fleste sentraliserte datasystemer i fattige land brukte SW som var utviklet i vestlige land, og at alle brukerne dermed nøt godt av den Y2K-jobben som ble gjort i vesten?

 

Jeg vet om små bedrifter som testet sine systemer ved å stille klokken fram til 31/12-99 23:59 og se hva som skjedde når de passerte 00:00. Noen systemer stoppet, andre trasket videre som om ingenting hadde hendt.

For noen av systemene som stoppet, var løsningen å slå dem av før 23:59 og vente med å slå dem på igjen til etter midnatt. For andre systemer - spesielt de som regnet tidsdifferanser - måtte det SW-endringer til.

 

Å tro at det dreide seg om svindel er på nivå med å hevde at jorda er flat.

[nebrewfoz]

Apropos uketall, hvorfor i all verden bruker de uketall i det hele tatt? Er det ikke bedre å bruke f.eks årstall? 8 bit burde holdt i lange baner da.

 

Kanskje det har noe med efemeridene eller almanakken å gjøre? Der vil jo "uke" gi høyere oppløsning enn "år".

(Det er 20 år siden jeg jobbet litt med GPS og jeg husker ikke detaljene lenger.)

 

Men husk at GPS ble utviklet på 1970-tallet; eller "70-tallet" som vi sa da, i god tro på at 2 desimal-siffer var tilstrekkelig til å beskrive årstall, og 640KB RAM var mer enn nok for de fleste, som IBM sa da deres første PC ble lansert. (Den kunne max ha 64KB på hovedkortet og utvides til totalt 256KB med 3 ekspansjonskort ...) [OK, PC'en ble lansert i 1981, men poenget står.]

[MortenL]

Men.... Var kloden så forskjellig for 2048 uker siden? Hva kan skje? At GPS'en tror den er i 1978 og viser feil klokke?

[nebrewfoz]

Men.... Var kloden så forskjellig for 2048 uker siden? Hva kan skje? At GPS'en tror den er i 1978 og viser feil klokke?

 

Hvis du har feil klokke, så får du feil posisjon på kjøpet.

GPS gir deg - samtidig - 3 posisjonskoordinater og 1 tidskoordinat.

 

Det er derfor GPS-mottakeren må motta signaler fra minst 4 GPS-satelitter for å kunne gi deg tid & sted.

(Mange datasystemer bruker GPS ene og alene som en tidsreferanse.)

[MortenL]

Hvis du har feil klokke, så får du feil posisjon på kjøpet.

GPS gir deg - samtidig - 3 posisjonskoordinater og 1 tidskoordinat.

 

Det er derfor GPS-mottakeren må motta signaler fra minst 4 GPS-satelitter for å kunne gi deg tid & sted.

(Mange datasystemer bruker GPS ene og alene som en tidsreferanse.)

Jeg antar at mottakeren gjør samme regne feil på alle tidene fra alle klokkene og at den "tror" den er tilbake i 1978.. Stemmer ikke dette? Den har ikke bruk for lokaltid.

[nebrewfoz]

Jeg antar at mottakeren gjør samme regne feil på alle tidene fra alle klokkene og at den "tror" den er tilbake i 1978.. Stemmer ikke dette?

 

Riktig.

Uten noe tilleggsinformasjon (- f.eks. produksjonsdato eller dato for siste firmware-oppdatering i mottakeren -), så klarer ikke mottakeren å bestemme hvilken uke den er i. Og når det går for lang tid siden siste FW-oppdatering (som det gjerne gjør med gamle duppeditter), så har man det gående.