Schrikkelseconde

[Benm]

Daarin heb je gelijk, maar het vliegwiel geeft een duidelijke indicatie dat de energie is opgeslagen in draaiende delen, of dat centrales, aangesluiten verbruikers etc zijn doet er voor het brede inzicht denk ik niet zoveel toe.

Wonderlijk is dat het Lidl-wekkertje hardnekkig circa 1/4 sec voorloopt op een vergelijkbaar DCF77-wekkertje van de Hema, ook na herhaaldelijk uitgeschakeld te zijn door de batterijen te verwijderen. Als hij synchroniseert na een dag zonder batterijen vertoont hij weer die 1/4 seconde voorsprong. Er zit in de elektronica lijkt me niet zoveel wat 1/4 seconde vertraging oplevert. Misschien is de ontvanger van het Hema wekkertje opzettelijk extreem smalbandig om minder last te hebben van ruis en stoorsignalen. Hoe smalbandiger des te meer vertraging.

Hoe bandbreedte zou bijdragen aan vertraging zie ik niet direct in. Zelfs als ze een filter gebruiken dat in totaal een faseverschuiving van 360 graden heeft op 77 kHz zou je daardoor niet meer dan 14 microseconden mislopen.

Ik vermoed dat die kwart seconde afwijking gewoon een implementatiefout is, wellicht acceptabel geacht door de fabrikant gezien de resolutie van het display een volle seconde is. Overigens vraag ik me dat wel af welk van de twee klopt: als je het vergelijkt met een NTP gesynchroniseerde klok als time.gov, welk van de twee zit er dan qua seconde-ovegang het dichtste bij?

Overigens is het ook een afweging dat het bij 1 keer per dag synchroniseren niets meer uitmaakt: de nauwkeurigheid van het kirstal dat het de rest van de dag bepaalt is normaliter 20 ppm, genoeg om anderhalve seconde per dag te verliezen of te winnen.

[jkien]

Hoe bandbreedte zou bijdragen aan vertraging zie ik niet direct in. Zelfs als ze een filter gebruiken dat in totaal een faseverschuiving van 360 graden heeft op 77 kHz zou je daardoor niet meer dan 14 microseconden mislopen.

 

Als er op de DCF77-draaggolf rechthoekige pulsen gemoduleerd zijn d.m.v. amplitudemodulatie dan vervormt het bandfilter die rechthoekige pulsen tot vertraagde pulsen met scheve flanken.
Volgens dit artikel over de nauwkeurigheid van tijdmeting met DCF77 resulteert dit bij consumentenklokjes vanwege een smalbandig filter in een onnauwkeurigheid tot 0.15 s. Bij industriele klokjes is het een factor 10 nauwkeuriger, dus tot 0.015 s.  "Narrowband reception and accuracy exclude each other".

 

Overigens vraag ik me dat wel af welk van de twee klopt: als je het vergelijkt met een NTP gesynchroniseerde klok als time.gov, welk van de twee zit er dan qua seconde-ovegang het dichtste bij?

 
De tijd van time.gov blijkt halverwege tussen beide DCF77-wekkertijden in te zitten. De DCF77-wekker van de Hema klopt waarschijnlijk, want hij loopt precies gelijk met drie andere DCF77-klokjes (alle verschillend).

[Benm]

Het hangt er inderdaad wel vanaf hoe smalbandig je filtert, en of je het een of 2 keer doet. Ik weet niet hoe sterk het signaal precies is, als het nodig is zou je de bandbreedte terug kunnen brengen tot ca 5 Hz om het verschil tussen korte en lange pulsen nog net te kunnen zijn, en dan kom je wel aan 0.15s vertraging als je er niet voor zou compenseren.

Waarom je het niet zou compenseren is overigens een raadsel gezien die vertraging door filtering compleet voorspelbaar is en je processor gewoon weet dat het altijd ca 0.15 seconden achter loopt. Op zich klopt de opmerking over smalbandigheid en nauwkeurigheid wel, maar in dit geval zit er een voorspelbaarheid aan waardoor je er minder last van hebt (veronderstelt dat je een goede frequentiestandaard hebt).

Voor 'industrieel' gebruikt zijn er meerdere otpties. Een breedbandiger ontvanger kan, maar er wordt ook informatie gestuurd middels fasemodulatie. Die klokjes voor thuis zien daar niets van, maar ik denk eigenlijk wel dat dat de weg is om het nauwkeuriger te krijgen.

Maar hoe het ook zit: voor een klok met seconde resolutie maakt het niets uit, je zit er nooit een vol cijfer naast. Interessant is overigens wel dat die wekkers het verschillende oplossen op sub-seconde resolutie en het blijkbaar allemaal niet helemaal goed krijgen.

[heerlen1987]

Zal ik de tags of naam van het topic even veranderen in klokkenleer?

[jkien]

Het is gebeurd, de schrikkelseconde van 2015 werd een half uur geleden toegepast op de UTC-tijd.
 

Een DCF77-klok zal tijdens de schrikkelseconde misschien 01:59:60 laten zien.

 
Het DCF77-klokje van Lidl heeft de schrikkelseconde helaas niet correct zichtbaar gemaakt. De wekker telde 01:59:58, 01:59:59, 02:00:00, en elke stand duurde gewoon 1 seconde. Daarna liep het klokje dus 1 seconde voor, maar een knipperend antennesymbooltje wees erop dat het klokje op zoek ging naar het DCF radiosignaal om te synchroniseren.
 
De schrikkelseconde was wel zichtbaar als 01:59:60 op nist.gov en leapsecond.com.
 
1 2 3

[Benm]

Slechte implementatie in dat klokje dan, de schrikkelseconde wordt wel aangekondigd in het dcf77 signaal. Anderzijds kan ik me voorstellen dat men dit gewoon niet implementeert gezien de afwijking op een dag groter is dan 1 seconde wanneer de hele dag op quartz vertrouwd wordt en slechts eenmaal synchronisatie plaatsvindt.

Overigens is er wel een valide reden om die synchronisatie niet al te vaak te doen: het kost flink wat batterijvermogen, en je zit ook met propagatiecondities van het RF signaal waardoor het snachts beter te doen is dan overdag.

[jkien]

Slechte implementatie in dat klokje dan, de schrikkelseconde wordt wel aangekondigd in het dcf77 signaal.

 
De implementatie is niet zo heel slecht. De wekker reageerde snel, want het antennesymbooltje ging na de schrikkelseconde meteen knipperen, wat betekent dat de wekker naar het radiosignaal zocht om te synchroniseren. Dat de klok 1 seconde voorliep zal slechts een paar minuten hebben geduurd.