Exacte tijd verkrijgen via gps

Als je hem steeds reset, loop je het risico dat dit langer dan een microseconde duurt en je een afwijking introduceert.

Enig idee hoe lachwekkend dit klinkt? (het gaat over gelijkzetten van een klok...)

GPS tijd loopt 17 seconden achter 18 seconden voor op UTC tijd, dus als het om uitlezen van exacte tijd gaat, dan moet je die corrigeren.
En bij het invoeren van een nieuwe schrikkelseconde weer opnieuw aanpassen.

Op 16 april 2022 17:56:21 schreef rob040:
GPS tijd loopt 17 seconden achter op UTC tijd, dus als het om uitlezen van exacte tijd gaat, dan moet je die corrigeren.
En bij het invoeren van een nieuwe schrikkelseconde weer opnieuw aanpassen.

Wat een gedoe!DCF doet het vanzelf..

Met DCF77 heb je het dag/nacht effect (reflectie E laag ). Dus dat moet je ook uitmiddelen met een lange tijd constante! En de AM modulatie uit limmeten.

Op 16 april 2022 18:11:33 schreef mel:
[...]Wat een gedoe!DCF doet het vanzelf..

In 80% van het huis doet DCF het niet (meer). Dubbele beglazing vervangen door extra isolerende beglazing en de problemen zijn begonnen. In een recent huis werkt GSM amper. Voor DCF vrees ik daar het ergste. Mijn sync is nooit lang genoeg om de meteotime deftig door te krijgen voor 3 dagen. Meestal lukt zelfs een dag niet.

Op 16 april 2022 17:25:56 schreef Arco:
[...]
Enig idee hoe lachwekkend dit klinkt? (het gaat over gelijkzetten van een klok...)

Het klinkt lachwekkend, maar ik geef rew helemaal gelijk. Of resetten lukt gegarandeerd binnen een klokpuls van 1 uS. Bovendien, waarom zou je resetten? Je microcontroller kan toch wel rekenen?

Niet van mijzelf, maar ik heb een tijdje geleden een video time inserter nagebouwd en de firmware vertaald naar engels; https://github.com/AartSchipper/smopiVTI

Daar zit alles in om GPS tijd +PPS binnen te halen, het kristal te kalibreren en zo dus een redelijk goede lokale tijdlijn te maken.
Ik kan het niet echt testen, maar het geheel is binnen 1 video frame gelijk aan DCF, de PPS led en lijkt beter dan een professionele time inserter welke serieel de GPS data binnen haalt. Voor mijn verslag van bouw en test zie:

Het maken van de time inserter.pdf

Als locatie / een nauwkeurigheid totaan ms niet nodig is en de antenne kan binnnen 45 graden juist (vooral niet precies fout) gericht worden is DCF binnen veel beter en betrouwbaarder.
Gedoe met storingen was imo vooral iets van voor:
https://github.com/udoklein/dcf77

Maar geloof mij vooral niet, ervaar het zelf eens

[[ aub verwijderen ]]

[Bericht gewijzigd door big_fat_mama op 16 april 2022 19:38:54 (95%)

[[ aub verwijderen, excuus hoor, ik ben even aan het knoeien ]]

[Bericht gewijzigd door big_fat_mama op 16 april 2022 19:41:33 (90%)

Op 16 april 2022 17:56:21 schreef rob040:
GPS tijd loopt 17 seconden achter op UTC tijd, dus als het om uitlezen van exacte tijd gaat, dan moet je die corrigeren.
En bij het invoeren van een nieuwe schrikkelseconde weer opnieuw aanpassen.

Daar geloof ik geen reet van.
Zou dat aub kunnen onderbouwd worden? ik weet meer dan één professionale omgeving waar ntp gebruikt wordt om de logs van diverse netwerkcomponenten te vergelijken, om te zien waar een mogelijk probleem zich is beginnen te ontwikkelen. Dat gaat hem om milliseconden.

Op 16 april 2022 17:56:21 schreef rob040:
GPS tijd loopt 17 seconden achter op UTC tijd

• 18 seconden vóór op UTC (na 2016), niet 17 seconden achter.
• Dit verschil wordt in de gps-ontvanger al verrekend; er komt UTC uit.

Toen ik voor het eerst met gps te maken had, was het verschil nul. Schrikkelseconden werden echter niet in rekening gebracht, zodat het verschil opliep. Maar al vrij vroeg werd dit verschil wél in rekening gebracht.
'Inwendig' loopt het gps-systeem inderdaad nu voor, maar de uitgevoerde tijd is UTC.

Op 16 april 2022 19:25:20 schreef Aart:
Als locatie niet nodig is en de antenne kan binnnen 45 graden juist (vooral niet precies fout) gericht worden is DCF binnen veel beter en betrouwbaarder.
Gedoe met storingen was imo vooral iets van voor:
https://github.com/udoklein/dcf77

Maar geloof mij vooral niet, ervaar het zelf eens

Nou, ik geloof je wel. Ik heb met die library gespeeld, dat is een geniaal stuk software.

Zie ook:
https://blog.blinkenlight.net/experiments/dcf77/

@FET: Dank voor de correctie.
Ik wist niet dat het tegenwoordig gecompenseerd/omgerekend wordt. Is dat futureproof?

'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.