EU DNS: 86.54.11.100
De referentietijd daarvan is ook een precieze atoomklok.
Wat heb je al geprobeerd te zoeken?
Dat wil wel eens verlopen als de interne clock niet precies goed is (ervaring) want het wordt niet elke seconde gesynchroniseerdMar.tin schreef op zondag 23 juli 2017 @ 15:38:
Waarom niet gewoon via internet synchroniseren? Dit zit standaard in alle grote OSsen
Wat heb je al geprobeerd te zoeken?
doe maar eens
w32tm /stripchart /computer:pool.ntp.org
in de command line
ontopic:
Zoek naar een dcf reciever
https://www.google.nl/sea...UQsAQIXw&biw=1047&bih=513
[ Voor 18% gewijzigd door Fish op 23-07-2017 15:49 ]
Hoe de ontvanger heet zal afhangen van wat je wilt ontvangen. Duh. De twee externe signalen die kunt ontvangen zijn DCF77 en GSP.
Als je kunt solderen: elektor en conrad hebben bouwpakketten voor DCF77-ontvangers. Die hang je aan de serieele poort van een PC en daar draai je dan NTP op. Die leest en interpreteert het DCF-signaal en houdt de tijd bij.
GPS kun je ontvangen met een (duh again) GPS-ontvanger en dezelfde NTP software. Die leest dan via USB het ontvangen GPS-signaal uit, en dat bevat een hele nauwkeurige tijd.
I don't like facts. They have a liberal bias.
Maar dan verander je de interval toch gewoon? Elke seconde synchroniseren heeft niet zoveel zin natuurlijk.Fish schreef op zondag 23 juli 2017 @ 15:45:
[...]
Dat wil wel eens verlopen als de interne clock niet precies goed is (ervaring) want het wordt niet elke seconde gesynchroniseerd
doe maar eens
w32tm /stripchart /computer:pool.ntp.org
in de command line
ontopic:
Zoek naar een dcf reciever
https://www.google.nl/sea...UQsAQIXw&biw=1047&bih=513
Heb je liever vooraf, of achteraf, dat ik zeg dat ik geen flauw idee heb wat ik doe?
Verwijderd
Klopt helemaal, al heb je ook GPS-ontvangers die een PPS-signaal afgeven en gewoon via een seriële poort te gebruiken zijn, dat geeft minder latency dan een USB-poort. Eigenlijk is een USB-poort voor exacte timing redelijk waardeloos zelfs, dan kun je net zo goed via de NTP pool sychroniseren.burne schreef op zondag 23 juli 2017 @ 15:50:
GPS kun je ontvangen met een (duh again) GPS-ontvanger en dezelfde NTP software. Die leest dan via USB het ontvangen GPS-signaal uit, en dat bevat een hele nauwkeurige tijd.
Maar als je nu iets op zou willen zetten, zou ik gewoon een Raspberry Pi met een GPS PPS ontvanger nemen, dan heb je een heel leuk setje voor je hele huis. Kijk bijvoorbeeld hier eens.
De GPS-ontvanger (nou ja, de antenne natuurlijk) moet wel een beetje vrij zicht op de hemel hebben (bij een raam of onder een normaal dak van een schuur of zo is prima), maar dat is met een DCF-77 ontvanger niet veel anders.
Zoiets zoek je dus? Voor een gedeelte wat niet met internet is verbonden deed ik hem gebruiken. Wilde wel de actuele tijd hebben daar.
usb polling is standaard onder windows 125 hz aka 8ms (tenzij je het naar 1000hz forceert je randapparatuur dat ondersteund)Verwijderd schreef op zondag 23 juli 2017 @ 15:56:
[...]
Klopt helemaal, al heb je ook GPS-ontvangers die een PPS-signaal afgeven en gewoon via een seriële poort te gebruiken zijn, dat geeft minder latency dan een USB-poort. Eigenlijk is een USB-poort voor exacte timing redelijk waardeloos zelfs, dan kun je net zo goed via de NTP pool sychroniseren.
Maar als je nu iets op zou willen zetten, zou ik gewoon een Raspberry Pi met een GPS PPS ontvanger nemen, dan heb je een heel leuk setje voor je hele huis. Kijk bijvoorbeeld hier eens.
De GPS-ontvanger (nou ja, de antenne natuurlijk) moet wel een beetje vrij zicht op de hemel hebben (bij een raam of onder een normaal dak van een schuur of zo is prima), maar dat is met een DCF-77 ontvanger niet veel anders.
Serieel is naturlijk ook niet altijd snel. helemaal op 1200 bauud niet. dus het hangt van het een en ander af
Verwijderd
Voor GPS-ontvangers spreek je over precisies in µs of zelfs ns, niet in ms. Dat gaat perfect met PPS signalen over serieel.Fish schreef op zondag 23 juli 2017 @ 16:09:
[...]
usb polling is standaard onder windows 125 hz aka 8ms (tenzij je het naar 1000hz forceert je randapparatuur dat ondersteund)
Serieel is naturlijk ook niet altijd snel. helemaal op 1200 bauud niet. dus het hangt van het een en ander af
Let erop dat niet zozeer de snelheid van overdracht belangrijk is, maar de nauwkeurigheid en natuurlijk ook een afwezigheid van jitter. Dat lukt gewoon niet als je het over µs hebt met USB, daar zijn die drivers ook niet op geschreven.
Uiteraard geldt het hele verhaal niet als je genoeg hebt aan een nauwkeurigheid van milliseconden.
Dat komt omdat je geen oven or rubidium oscillator in je computer hebt. Die heb overigens ook helemaal niet nodig voor je computer thuis.Fish schreef op zondag 23 juli 2017 @ 15:45:
[...]
Dat wil wel eens verlopen als de interne clock niet precies goed is (ervaring) want het wordt niet elke seconde gesynchroniseerd
DCF77 kan je ook niet elke seconde synchroniseren, één bericht van DCF77 duurt een minuut, en met een beetje pech zit je meerdere minuten te wachten op een intact bericht.
Als je echt zo ontzettend fanatiek de absolute tijd wilt bijhouden moet je een oven oscillator of een rubidium oscillator scoren op eBay en daar een klok aan vast knopen. Daarna gebruik je GPS om hem te kalibreren.
Heb je liever vooraf, of achteraf, dat ik zeg dat ik geen flauw idee heb wat ik doe?
Nou, eigenlijk is dat met DCF-77 wel heel anders. GPS zit op hoge frequenties (boven 1 GHz) die flink gedempt worden door de meeste bouwmaterialen, dus je hebt inderdaad vrij zicht of een hele gevoelige ontvanger nodig.Verwijderd schreef op zondag 23 juli 2017 @ 15:56:
[...]
De GPS-ontvanger (nou ja, de antenne natuurlijk) moet wel een beetje vrij zicht op de hemel hebben (bij een raam of onder een normaal dak van een schuur of zo is prima), maar dat is met een DCF-77 ontvanger niet veel anders.
DCF-77 zit op een ontzettend lage frequentie (77,5 kHz) die overal doorheen komt, tenzij je in een bunker onder de grond woont.
Een beetje tijd-ontvanger stuurt de tijd-info niet alleen over de data-lijnen, maar stuurt ook een 1PPS signaal over de controle-lijnen over. De interrupt die dat genereert is al een heel stuk beter.Fish schreef op zondag 23 juli 2017 @ 16:09:
[...]
usb polling is standaard onder windows 125 hz aka 8ms (tenzij je het naar 1000hz forceert je randapparatuur dat ondersteund)
Serieel is naturlijk ook niet altijd snel. helemaal op 1200 bauud niet. dus het hangt van het een en ander af
De volledige tijd-info wordt inderdaad eenmaal per minuut verzonden, maar als je die eenmaal hebt ontvangen kun je wel alle individuele tijd-pulsjes (iedere seconde) gebruiken een 1PPS signaal mee te genereren. Zie bijvoorbeel de C51 klok van Meinberg (niet meer in de handel, maar wel een relatief simpele DCF-77 ontvanger die precies dit doet).jeroen3 schreef op zondag 23 juli 2017 @ 16:49:
[...]
DCF77 kan je ook niet elke seconde synchroniseren, één bericht van DCF77 duurt een minuut, en met een beetje pech zit je meerdere minuten te wachten op een intact bericht.
Eh, ja... Windows heeft een ontzettend crappy NTP implementatie. Ik geloof dat er maar ééns per week of zo gepolled wordt en ook geen drift correction plaatsvindt, waardoor je makkelijk enkele seconden (!!) afwijking kunt hebben.Fish schreef op zondag 23 juli 2017 @ 15:45:
[...]
Dat wil wel eens verlopen als de interne clock niet precies goed is (ervaring) want het wordt niet elke seconde gesynchroniseerd
doe maar eens
w32tm /stripchart /computer:pool.ntp.org
in de command line
Op een linux systeem heb je normaalgesproken (na een paar uur syncrhonisate) echt niet meer dan één of enkele milliseconden jitter. Op windows moet je afaik externe applicaties gebruiken om fatsoenlijke resultaten te behalen maar dan zul je ook op zoiets uitkomen. Ik kan nauwelijks een toepassing bedenken die zó tijdkritisch is dat dat niet nauwkeurig genoeg zou zijn.
[ Voor 6% gewijzigd door mcDavid op 23-07-2017 22:43 ]
Ik heb wel eens een meetaplicatie (saas) beheerd waar die paar seconde Jitter tamlijk onwenselijk wasmcDavid schreef op zondag 23 juli 2017 @ 22:38:
[...]
Eh, ja... Windows heeft een ontzettend crappy NTP implementatie. Ik geloof dat er maar ééns per week of zo gepolled wordt en ook geen drift correction plaatsvindt, waardoor je makkelijk enkele seconden (!!) afwijking kunt hebben.
Op een linux systeem heb je normaalgesproken (na een paar uur syncrhonisate) echt niet meer dan één of enkele milliseconden jitter. Op windows moet je afaik externe applicaties gebruiken om fatsoenlijke resultaten te behalen maar dan zul je ook op zoiets uitkomen. Ik kan nauwelijks een toepassing bedenken die zó tijdkritisch is dat dat niet nauwkeurig genoeg zou zijn.
Dan zet je de sync toch op elk uur?mcDavid schreef op zondag 23 juli 2017 @ 22:38:
[...]
Eh, ja... Windows heeft een ontzettend crappy NTP implementatie. Ik geloof dat er maar ééns per week of zo gepolled wordt en ook geen drift correction plaatsvindt, waardoor je makkelijk enkele seconden (!!) afwijking kunt hebben.
Op een linux systeem heb je normaalgesproken (na een paar uur syncrhonisate) echt niet meer dan één of enkele milliseconden jitter. Op windows moet je afaik externe applicaties gebruiken om fatsoenlijke resultaten te behalen maar dan zul je ook op zoiets uitkomen. Ik kan nauwelijks een toepassing bedenken die zó tijdkritisch is dat dat niet nauwkeurig genoeg zou zijn.
Heb je liever vooraf, of achteraf, dat ik zeg dat ik geen flauw idee heb wat ik doe?
p.s. mijn ervaring met ntp op een VM draaien geeft wel een afwijking.
As you may already have guessed, following the instructions may break your system and you are on your own to fix it again.
Een USB atoomklok heeft in principe weinig met Netwerken te maken. Daarnaast mis ik toch wel wat info in je topic.
Zoals al door verschillende reageerders aangegeven kun je prima je tijd laten syncen via NTP.
Tijd voor een nieuwe sig..
Dit topic is gesloten.
![]()