DCF77 Very Simple Clock, microcontroller stuk?

Op zondag 20 april 2025 14:26:24 schreef Hubie:
[...]
Huh..? Als ze nu bij DCF de stekker eruit trekken ligt heel het O.V. in DL en NL plat.Hoezo nostalgie?

Huh huh? Dus de DCF-service is een single point of failure, en eentje waarop men dan nog geeneens beheer of controle heeft?

Op zondag 20 april 2025 15:52:20 schreef Paulinha_B:
[...]

Huh huh? Dus de DCF-service is een single point of failure, en eentje waarop men dan nog geeneens beheer of controle heeft?

Op zondag 20 april 2025 15:09:24 schreef fotoopa:
Ik zie dat er hier nog 2 van die Conrad DCF77 modules liggen. Ik weet dat ze toen heel goed werkten. De ferriet staaf moest je wel goed uitlijnen om een stabiel werkend signaal te hebben. Een eenvoudige truck was om de staaf te verdraaien tot het minimum signaal. Dat was dan de richting van het DCF77 signaal. Als je de staaf daarna 90 graden verdaaide zou je dan het beste ontvangst hebben.

Een kompas is nog simpeler...

Op zondag 20 april 2025 15:17:21 schreef RAAF12:
Volgens de beschrijving werkt de klok ook zonder DCF signaal.

Alle DCF klokken lopen zonder signaal gewoon door...
(ze worden meestal maar 1x per dag gesynchroniseerd. Als dat mislukt loopt 'ie zonder sync door)

Op zondag 20 april 2025 15:52:20 schreef Paulinha_B:
[...]

Huh huh? Dus de DCF-service is een single point of failure, en eentje waarop men dan nog geeneens beheer of controle heeft?

't Maakt weinig uit of de zender een paar daagjes uitvalt, klok loopt dan hooguit een seconde ofzo asynchroon door...
(voor backup bij uitval kun je op Anthorn omschakelen (meeste ontvangers kunnen die ook ontvangen)

Op zondag 20 april 2025 10:48:12 schreef KGE:
Alle moderne Unix/Linux varianten gebruiken inmiddels een groter dan 32 bits getal voor de secondes sinds 1970 dus denk dat het net zo'n microdebacle wordt als het Y2K probleem..

Er zullen heus een paar apps uitknallen:

#include <stdio.h> 
#include <stdlib.h>
#include <time.h> 

int main ()
{
  int t; 
  t = time (NULL);
  if (t < 0) {
     perror ("Error getting time\n");
     exit (1);
  } else {
     printf ("We're currently %d seconds since jan first 1970!\n", t);
     printf ("(sizeof (t) = %ld.)\n", sizeof(t));
  }
  exit (0);
}

programma's als deze zullen dus falen. En die kan je vandaag nog steeds schrijven. (Voorbeeld: Bovenstaande schreef ik vandaag. )

Op zondag 20 april 2025 14:17:01 schreef Hans 007:
Nou, het is hier echt gezellig geworden!

Dank voor de serieuze antwoorden:

Ik heb geen probes, scope o.i.d. Omdat de klok wel gewoon z'n test programma afwerkt en reageert op het DCF77 signaal, kan ik verder niks zien;
Een andere voeding maakt niets uit. Het signaal is, zoals ik al schreef, strak en stabiel: elke seconde een duidelijke knipper, elke minuut 2 seconden geen knipper. Heel regelmatig, geen vaag geknipper e.d.

Als de klok wel ontvangt, maar niet twee keer een goede datastream (qua tijd en datum bij elkaar passend), dan wordt dat genegeerd.
(meestal een bitje omgevallen door storing)

Daarom worden de klokken ook 's nachts gesynchroniseerd: dan is er minder storing te verwachten.

Op zondag 20 april 2025 14:17:01 schreef Hans 007:
Omdat de klok wel gewoon z'n test programma afwerkt en reageert op het DCF77 signaal, kan ik verder niks zien;

Dan loopt er dus toch een oscillator om die PIC zijn programma te laten lopen. En afaik heeft de 16F628 geen automatische omschakeling naar de interne klok als de externe kristaloscillator faalt (zoals de 16F887). Dus ik denk dat de kristaloscillator gewoon loopt. (weet dat eigenlijk vrij zeker).

Komt dat knippersignaal daadwerkelijk bij de PIC aan of zit daar nog iets tussen (en zit dat toevallig los)?

Of, gewoon 2 stappen terug: Krijgt de PIC netjes voeding, is de voedingsspanning stabiel?

Nee, die knipper zit in het pic programma, die geeft aan dat ie een goed signaal ontvangt. Ik heb die klok al heel erg lang, ik weet hoe ie zou moeten werken. Het programma werkt zo te zien normaal (bijv. de test routine als de pic start en het reageren op de dcf77 pulsen). Alleen na 2 minuten laat ie niet de dcf tijd zien.
Antenne is goed uitgericht, ik heb nog een DCF klok waarin een arduino het dcf77 signaal verwerkt, en die doet het prima.
Ja, de voedingsspanning is goed, ik heb diverse 12 volt adapters getest.

De PIC16F628 werkt toch niet op 12V?
De voedingsspanning van de PIC moet schoon zijn.
Meest waarschijnlijke fout is een printbreuk of een slechte soldering. Door trillingen tijdens transport komen dat soort fouten aan het licht.

die geeft aan dat ie een goed signaal ontvangt.

Zoals ik het lees dat ie signaal ontvangt .... maar niet dat het een goed signaal is... en als ie een uur lang geen goed signaal ontvangt knippert ie gewoon verder in storingmode.
Zet de klok eens gewoon buiten... als je in een super geisoleerd huis zit is het alu dampscherm een kooi van faraday waar niks in of uit gaat... en de ene dcf klok/ontvanger is de andere niet.

Ik heb hier zo'n ding

het is eigenlijk een NTP server die door DCF gestuurd wordt..Werkt feilloos.Er zit een losse antenne bij.Nu woon ik ook tegen de Duitse grens aan, dat scheelt ook..

Op zondag 20 april 2025 16:02:58 schreef rew:
programma's als deze zullen dus falen. En die kan je vandaag nog steeds schrijven. (Voorbeeld: Bovenstaande schreef ik vandaag. )

Je moet voor t een long gebruiken ipv een int... en dan %ld in je printf. Nog beter is om t als int_64t te declareren zodat je zeker weet dat het een 64 bits getal is.

Je kunt ook nog steeds code schrijven die maar twee getallen voor het jaar gebruikt.. Eigen schuld etc..

Er zijn ook nog genoeg apparaten waar oude klok chips in zitten met maar 2 digits voor het jaartal.

Tegen de tijd dat ze DCF77 uitschakelen kun je altijd nog zelf een simpel projectje opzetten met een microcontroller/processor welke via NTP de tijd ophaalt en via AM weer uitzendt.

Volgens mij heeft Elektuur ook al eens zo'n zendertje gepubliceerd voor test doeleinden.

https://www.elektormagazine.nl/labs/dcf77-signal-generator

Als je klok gewoon loopt, vanaf een foute tijd weleenswaar, kun je ook checken of die tijd relatief klopt. gewoon 1 min wachten en kijken of de klok verspringt op het juiste moment.
Dan weet je of het Xtal van de PIC goed is en niet op de helft of 1/3 oid loopt.

Over die 2038 date: En zijn nog genoeg 32-bit embedded systemen (vooral ARM) en worden nu ook nog gemaakt die het probleem hebben en helaas is de time counter dan ook 32 bits. Het enige wat je dan kunt doen is ipv een long een unsigned long gebruiken dan kun je weer effe vooruit.
Ook RTC chips zijn er nog genoeg in apparaten die niet meer van de tijd zijn.

Zoals beloofd heb ik de scope even verbonden met zo een oude module. Ik heb 5V gebruikt voor de voeding. De uitgang is open collector, je moet er een pullup weerstandje bijvoegen. Die kan je indien nodig aan de 3V3 powerline leggen. De meeste chips zijn nu enkel 3V3. Voor de scope meting heb ik 10k naar de 5V gebruikt.
De scope geef een volldige 60 sec cyclus weer. Je kunt zo de pulsje smal of breed zien. De korte zijn 0 level, de lange zijn 1 level.
Hierbij zie je een foto van de opname waarbij ik de data heb bijgezet.

dcf77-20250421 by Frans, on Flickr

De foto is een UHD beeld en klickbaar voor het origineele. Daar zie je dan nog beter de details. Op de ingesloten foto zie je de DCF77 module zoals die vroeger te koop was.
Ik woon in westvlaanderen, dat is wat verder van de zender. Ik moet de antenne vrij juist uitrichten om hier naast mijn computer voldoende signaal te hebben.
Hoe je dan verder de data verwerkt is jouw keuze. Op Wikipedia kun je de beschrijving vinden van de bitjes.

Op maandag 21 april 2025 10:24:27 schreef KGE:
Tegen de tijd dat ze DCF77 uitschakelen kun je altijd nog zelf een simpel projectje opzetten met een microcontroller/processor welke via NTP de tijd ophaalt en via AM weer uitzendt.

Volgens mij heeft Elektuur ook al eens zo'n zendertje gepubliceerd voor test doeleinden.

https://www.elektormagazine.nl/labs/dcf77-signal-generator

Waarom zou men DCF77 willen uitschakelen? Ik vind het erg handig zo'n autonome, volledig snoerloze klok. Een keer in de 4 jaar 2 batterijen vervangen, that's all.

Op maandag 21 april 2025 13:05:55 schreef fotoopa:
Zoals beloofd heb ik de scope even verbonden met zo een oude module.

Frans aka Fotoopa, dank!

Op maandag 21 april 2025 13:55:03 schreef RAAF12:
[...]

Waarom zou men DCF77 willen uitschakelen? Ik vind het erg handig zo'n autonome, volledig snoerloze klok. Een keer in de 4 jaar 2 batterijen vervangen, that's all. [bijlage]

Van de website:

DCF77 broadcasts in 24-h operation. Temporal availability of the DCF77 emission of annually 99.7% is guaranteed as part of the existing contractual regulation (not counting events due to force majeur), whose duration currently is until the end of 2031.

Hoogstwaarschijnlijk wordt deze dan gewoon weer verlengd maar ja niets is meer zeker tegenwoordig

Al wie zo gehecht is aan DCF moet maar hopen dat de groene jongens en meisjes niet beginnen mekkeren over het (nodeloze?) energieverbruik, voor 2031.

Op zondag 20 april 2025 21:06:02 schreef Hans 007:
Nee, die knipper zit in het pic programma, die geeft aan dat ie een goed signaal ontvangt.

Ah. Dan zou je het signaal uit de DCF-77 module ook even (via een transistortje) een led kunnen laten aansturen, of op de 'scope bekijken, om te zien of het inderdaad correct binnenkomt.

[[...]
Alle DCF klokken lopen zonder signaal gewoon door...
(ze worden meestal maar 1x per dag gesynchroniseerd. Als dat mislukt loopt 'ie zonder sync door)

[...]
't Maakt weinig uit of de zender een paar daagjes uitvalt, klok loopt dan hooguit een seconde ofzo asynchroon door...
(voor backup bij uitval kun je op Anthorn omschakelen (meeste ontvangers kunnen die ook ontvangen)

Ik heb destijds een DCF klok gebouwd uit RB, Het was een applicatie van Siemens bij de introductie van de 8035 processor met ingebouwde E-prom, die overigens bij mij wegens ontbreken van het origineel een 8035 + losse Eprom heeft. (RB1983 nr 10. Gecorrigeerde versie uit RB1980 nr 9)
De klok wordt gesynchroniseerd, als een volledige cyclus van een minuut correct ontvangen is. De software zet dan de decimale punten van de led displays aan. Zodra door storing of wat dan ook de data niet meer correct is, gaan deze uit en loopt de klok op het Kristal
Verder. Gebruikt dus telkens de laatste minuut om de tijd te triggeren.

Meeste DCF klokken ontvangen minimaal twee dataframes, om te controleren of de ontvangen data klopt...
(als alles goed ontvangen is, moet er 1 minuut tussen beide dataframes in zitten...)

Op zondag 20 april 2025 15:52:20 schreef Paulinha_B:
[...]

Huh huh? Dus de DCF-service is een single point of failure, en eentje waarop men dan nog geeneens beheer of controle heeft?

Heb jij controle over de NTS of GPS infrastructuur? DCF heeft 2 zenders. Bit 15 geeft aan dat de reserve antenne in gebruik is. DCF wordt nog steeds beheerd door Physikalisch-Technische Bundesanstalt (PTB). Een overheidsinstelling net als het BIPT in België. Mocht er geen behoefte meer zijn voor DCF of MSF, dan waren die al lang uit de lucht.

Mijn Junghans wekker doet het al >35 jaar perfect. Ook op vakantie. Ik hoef geen WiFi te zoeken om te synchroniseren. De synchronisatie gebeurt elk uur en toch houdt die het meer dan 2 jaar uit op 1 AA batterij.

In de caravan had ik een klokje gemaakt op NTP basis. Meer geen sync dan wel. Heb het omgebouwd naar GPS.

Meinberg bouwt nog steeds industriële DCF toepassingen. Zou er dan toch nog een markt voor zijn?

Op zondag 20 april 2025 10:57:18 schreef Arco:
De Windows kalender is wat dat betreft iets logischer, die start op 1-1-1601. (omdat de Gregoriaanse kalender in 400 jaars blokken is opgedeeld)

Dan heeft Microsoft dit toch niet doorgetrokken naar Excel. Daar start de kalender op 1 januari 1900.

Op maandag 21 april 2025 16:49:17 schreef buckfast_beekeeper:
[...]

Heb jij controle over de NTS of GPS infrastructuur?

NTP wordt dan ook aangeboden door talloze bronnen - daarvan mag er gerust al eens eentje uitvallen. Kijk maar eens welke ntp servers mijn machine thans raadpleegt:

-ntp-public-1.om 193.190.230.65   2 u  174 1024  377   49.446   -0.968   0.828
 ntp-public-2.om 193.190.230.65   2 u   6h 1024    0   50.698   +0.098   0.000
+time.cloudflare 10.195.8.4       3 u   99 1024  377    7.605   -0.768   0.629
-smtp-in1.aqea.n 194.117.47.44    3 u  688 1024   17   15.625   +0.275   0.089
-ntp3.leitecastr 193.79.237.14    2 u   87 1024  377   15.342   +0.291   0.602
*ntp.rnl.tecnico 193.147.107.33   2 u   73 1024  377   15.104   -0.261   0.895
-ntp1.tecnico.ul 56.99.239.27     2 u 118m 1024  300   14.669   +0.317   0.786
-ntp2.leitecastr 193.79.237.14    2 u  622 1024  177   14.970   +0.308   0.567
+ntp04.oal.ul.pt 85.199.214.98    2 u  158 1024  357   15.284   -0.096   0.568

Die zullen niet zo gauw allemaal tegelijk uitvallen. Natuurlijk kan het www als dusdanig uitvallen, bv. door een probleem bij mijn provider - in dat geval is het exacte uur het laatste van mijn bekommernissen!
En als ik een GNSS-ontvanger had met ntp dan zou zelfs dat geen kwaad kunnen, tenzij tegelijkertijd alle GPS- en alle Glonasssatellieten uitvallen. In een oorlogssituatie zou dat kunnen voorkomen, maar ook dan steekt het voor mij op geen seconde.

Op maandag 21 april 2025 17:02:03 schreef Paulinha_B:
[...]
Kijk maar eens welke ntp servers mijn machine thans raadpleegt:

Ik gebruik gewoon pool.ntp.org, nog nooit problemen gehad...

Om NTP te kunnen gebruiken moet niet alleen de server in de lucht zijn, ook het/jouw internet moet werken én je hebt om te beginnen stroom nodig om dat te kunnen gebruiken.