Exacte tijd verkrijgen via gps

'Inwendig' loopt het gps-systeem inderdaad nu voor

Waarde heer @FET, betreft dit dan enkel GPS, of ook Galileo, Beidoe, Glonass, ... ?

En maakt het eigenlijk iets uit voor de NMEA of pseudo-NMEA info die ik uit mijn cheapo USB-ontvangertje betrek, vanwege al die diverse bronnen?

Ik ken het geval eigenlijk alleen uit de begintijd. Je zou bijna zeggen dat de vroege ontwerpers niet aan die schrikkelseconde hadden gedacht, hoewel er toen al enkele waren geweest. Let wel: voor de plaatsbepaling is het onbelangrijk welke tijd er wordt gepresenteerd; inwendig wordt het eigen stelsel gebruikt.
Ergens in de jaren tachtig kregen we van Furuno een rondschrijven over het verschil - er waren toen drie seconden tussengeslopen -, en dat er een software update (op Eproms, per post!, zelf naar behoefte kopieren svp) zou volgen, zodat hun ontvanger daarna UTC zou tonen (en eventueel uitvoeren, maar onze klanten hadden nog geen pc - die was er nog niet).
Daarna is er bij ons in de praktijk eigenlijk niet echt meer over gesproken, want het probleem was opgelost.

Voor andere clubs kan ik niet spreken. En andere constellaties gebruiken natuurlijk intern andere tijdsystemen. Alleen het GPS-satellietsysteem gebruikt intern GPS-tijd.
Maar ik kan me niet voorstellen dat de ontvangers iets anders dan UTC tijd uitvoeren.

Op 16 april 2022 20:05:45 schreef rob040:
@FET: Dank voor de correctie.
Ik wist niet dat het tegenwoordig gecompenseerd/omgerekend wordt. Is dat futureproof?

Zo lang onze Amerikaanse militaire broeders GPS niet terug in 'oorlogsmodus' plaatsen zal het wel los lopen. Gaan ze terug naar oorlogsmodus is de plaatsbepaling ook niet meer 100% accuraat.

... en dan nog is er meer dan gps. Gelukkig maar.

Op 16 april 2022 20:41:40 schreef buckfast_beekeeper:
[...]

Zo lang onze Amerikaanse militaire broeders GPS niet terug in 'oorlogsmodus' plaatsen zal het wel los lopen. Gaan ze terug naar oorlogsmodus is de plaatsbepaling ook niet meer 100% accuraat.

Die "oorlog-modus" had nut toen je een militaire ontvanger voor zeg 2000 euro kocht en een commerciele "veel goedkoper" voor 1000. Dan kunnen ze zonder pardon gewoon overal waar nodig zo'n militaire plaatsen die de codes weet en kan gebruiken.

Maar in de golfoorlog kwamen ze er achter dat het veel efficienter was om voor iedere militaire van 2000 tientallen commerciele te kopen en niet zomaar alleen op tactische plekken, maar bij iedere militair zo'n apparaat te stallen. En dan heb je er zelf meer last van dan nut.

Dat inzicht hebben ze nu, dus ik denk niet dat het nog aangaat.

Ook het originele doel: "We willen niet dat de russen een kruisraket door een raam in het witte huis kunnen dirigeren op basis van GPS.... " dat heeft geen zin meer: Die navigeert dan gewoon op beidou of glonass.

Bovendien, zélfs als SA (de opzettelijke 'verslechtering') een rechtstreekse fout in de UTC-uitgifte had veroorzaakt, zou die tijdfout maar maximaal iets van 100 of 200 nanoseconden geweest zijn. Dat gaat al gauw verloren in de flanksteilheid van je RS232-signaal.

Op 16 april 2022 20:41:40 schreef buckfast_beekeeper:
Zo lang onze Amerikaanse militaire broeders GPS niet terug in 'oorlogsmodus' plaatsen zal het wel los lopen. Gaan ze terug naar oorlogsmodus is de plaatsbepaling ook niet meer 100% accuraat.

Je zult eerder merken dat de "bevrijders" uit je buurland^* GPS proberen te storen (wat lokaal vrij goed werkt, een sateliet op 20000km hoogte is binnen 100km makkelijk te overstemmen).

Uiteraard hebben ze daar zelf ook last van, dus wellicht dat een Glonass ontvanger dan weer wel werkt.

^*Dit is geen verborgen NL vs B dreigement

Op 16 april 2022 17:11:05 schreef rew:
Die module die jij gevonden hebt, die heeft gewoon een pps seconde output. Of het de opgaande of neergaande flank is weet ik niet, maar die zal toch binnen een microseconde op de hele secondes vallen. Dan kan je op je microcontroller klok gewoon de volgende 999 ms extrapoleren.

(Laat een timer op nominaal 1MHz lopen, doe een capture en IRQ op de flank van de pps. Zet de capture weer op scherp en de volgende IRQ weet je hoeveel de afwijking van je kristal is in ppm.

En dus in je counter-waarde heb je direct je aantal microseconden sinds vorige seconde. Afwijking iets van max 20ppm als je een aardig kristal gebruikt. En als je +20ppm meet, dan staat de counter dus steeds op 1000020 als de volgende pps komt. Dan kan je dus de counter waarde van 345678 met 1.00002 corrigeren naar 345671.

Ik zou aanraden: Laat de counter steeds doorlopen. Als je hem steeds reset, loop je het risico dat dit langer dan een microseconde duurt en je een afwijking introduceert. Dus in de IRQ noteer je "huidige beginstand deze seconde" en corrigeert wat je uit het register leest daarmee. Gebruik een 32bit counter.

kan ik ook niet gewoon vanaf deE flank irq op de systick de ms incrementen?
Kan ook nog wel een separate 1mhz counter maken, maar die systick heb ik Owieso al en is 1 ms.
Die pps zit gelukkig op een icp gedesigned maar of ik dat zo kortdag nog werkend krijg. De vraag blijft dan echter nog bij welke seconde die ik via uart krijg deE puls hoort. De eerst volgende of de vorige
Hopelijk kan ik alle onnodoge berichten uitzetten al is er nauwelijks documentatie van deze module.
Zijn ontvangst is zeker ook binnen dik in orde en lekker klein. De toepassing is buiten trouwens

*Dit is geen verborgen NL vs B dreigement

Goeie bak! Je zou ons toch nog niet zo gauw bang maken, hoor

Op 17 april 2022 20:45:26 schreef Stijnos:
[...] kan ik ook niet gewoon vanaf deE flank irq op de systick de ms incrementen?

Tuurlijk kan dat ook. Mijn voorstel is behoorlijk nauwkeurig met de hardware in de STM32 processor. Nauwkeuriger dan je nodig hebt voor weinig extra moeite. Jou voorstel is minder nauwkeurig dan het "eisenpakket" wat ik begrepen had. Maar misschie is het voor jou toch voldoende.

Jou methode gaat vast binnen een paar ms correcte metingen opleveren. Maar 1 of 2 ms afwijking ga je krijgen. Op z'n minst: wat doe je als je interne klok iets sneller loopt dan zou moeten? Je interne klok doet dan iets van 1000.02 systicks per echte seconde. Dus iedere 50 seconden, zul je 1001 systicks in een echte seconde zien. Wat doe je dan? van 09:24:35.999 naar 09:24:35.1000 ? Gewoon een tweede 09:24:35.999 periode? Nu is die ene "ms" ineens 2x langer dan de rest!

Het kan natuurlijk dat dit volkomen "acceptabel" is. Als je max 1x per 5 seconden een event moet timestampen die binnen 5ms nauwkeurig moet zijn... niets aan de hand. Dat je een 1.02 x grotere kans hebt om .999 of .000 in je metingen bestand te vinden... boeit dat?

Ik wilde juist elke sec de uren, minuten en seconden van de gps overnemen. Ik moet het liefst de absolute tijd hebben namelijk dus moet ik hem toch ooit eens overnemen. Ik dacht die pps dan te gebruiken om de ms tussen 2 sec te syncen.

Ja, tuurlijk. Maar dan heb je dus een 0-999 teller en een "het is nu 12:34:56" . En wat voor tijd hang je nu aan je gebeurtenis als de ms teller op 123 staat en de laatste tijd "12:34:56" was? 12:34:56.123 is waarschijnlijk fout. Het is waarschijnlijk 12:34:57.123, omdat het inlezen van de tijd pas na de 123e ms voltooid is.

En ik denk dat de module op 12:34:57.000 begint met versturen: Het is nu 12:34:57 en dat dit pas later klaar is, dat is dan maar zo.

Ik zou dus de volledige tijd in de pps-interrupt bijhouden. Die heeft een aantal dingen als informatie-bron. Enerzijds zijn eigen "vorige tijd" en de "ontvangen tijd-string". Eigenlijk: Als die hetzelfde zijn is het simpel: ophogen en klaar. En de ms -teller op nul zetten. Tja. dan zal je zo nu en dan zien dat er 1001 ms in een seconde hebben gezeten. Als je dat niet zo'n probleem vind, prima, dan is dit voldoende.