Welcome to dcf77 Discussions!

[udoklein]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[JohnHaine]

Morning all! I am looking at using the dcf77_xtal library for an application where it will provide a time source to synchronise a pendulum clock. The clock used to sync itself to a telegraph time pulse but that has been unavailable for decades, and the mechanism that adjusted the pendulum rate is now not functioning. The actual time is displayed on an electromechanical slave clock stepping every 30s, from a counter implemented on an Arduino Due. We have provided a GPS time source that has a DCF77-format current loop output and I wish to decode this to provide accurate time in the Arduino. The Arduino will also handle counting the pendulum swings and driving the dial, inserting or deleting occasional corrections of an integral number of seconds.

My question relates to the internal working of the library. I plan to monitor the pendulum sensor input by digital reads and reacting to negative edges by triggering actions to supply an impulse to the pendulum and increment the counter, as well as comparing "pendulum time" with dcf time.

Are there potential interactions between my code and the library that I need to be aware of? For example, I will not use any delay() statements that would block the processor, but are there other issues?

I intend to use the millis() function in my code - can I assume that the dcf library does not interfere with this?

The "official" DCF77 signal format uses the first 16 bits for civil warnings, but the GPS time source uses them for other purposes which are irrelevant to my application. It does provide Z1 and Z2. Can I assume that the library code also ignores the first 16 bits?

I'm sure there are other things I should have asked! Help on the above would be much appreciated.

John Haine.

[udoklein]

The library ignores these bits. However I wonder why you want to combine my library with a GPS time source. This is absolute overkill. The GPS time source will provide a signal that should have no noise. So any of the simpler DCF libraries will do (and with significantly less resource consumption).

If it interferes with your other stuff? it depends. It should not interfere with millis. But if you want to know for sure you have to look into the code: https://github.com/udoklein/dcf77/blob/master/dcf77.cpp#L1905. For ARM based versions it hooks into systick for the atmegas it leverages OCR2A.

[JohnHaine]

Another question if I may: I need to check the installation of the time code receiver and it would be helpful to have a decoder to do this. I plan to use a Nano for this for convenience as the Due processor on the clock is keeping the clock going. I am not sure if the Nanos that I have use a crystal or a resonator, but for test purposes I just want to make sure the right signals are coming out of the cables, precision is not needed. Though you warn in the documentation that an Xtal equipped Arduino is needed for precision, should the decoder at least work if only a resonator is used please?

[udoklein]

I wrote that it requires a crystal because it needs a crystal. Simpler decoders that are not based on statistics get away with a resonator. Again you might want to look for a different DCF library.

Actually I wonder why you don't use the GPS output directly. This would reduce your system complexity a lot.

[JohnHaine]

Thanks Udo. We already have the GPS device mounted on the building but it has a DCF77-encoded data interface on a current loop output that can drive a long cable. We couldn't use DCF77 RF signals inside the building because it is heavily shielded with reinforced concrete and "radio controlled" clocks don't work very well.

But I take your point about using a simpler DCF library, as far as I know there is only one other: https://github.com/thijse/Arduino-DCF77. Are you aware of any others please?

[udoklein]

I think the thisje very is quite popular. So it should be OK. I did not want to use it because I have a noisy signal but in your case this should not be an issue.

Another thing: do you really need the time or only the ticks? If you really have GPS locked DCF77 signal extracting perfectly synced 1s ticks is trivial.

[JohnHaine]

Hello Udo, just resurrecting this thread after nearly a year as I have another small issue.

We have been using the DCF Generator code very successfully to exercise the Thijse decoder - it's taken a long time to get to this point for various non technical reasons I won't bore you with! Anyway we are now at the point where we need to test that the code correctly deals with dst changes, and it appears that the decoder does not explicitly signal these so we need to infer them from time changes. Please could you confirm if your generator code can produce a time signal sequence to do this and give me a hint as to how to program the encoder appropriately (or if I have missed it point me at the right place in the documentation)?

Many thanks, John.

[udoklein]

Hi John,

this week I have very little time to take care of details. So I will answer more detailed on Sunday or next week. Till then, can you give me the exact details of what you are using or maybe even share your source code?

In general the encoder should generate the proper sequence. If it does not I consider this a bug and I will fix it. It would be helpful to know exactly what you are using such that I can reproduce the bug as easily as possible.

Best regards,
Udo

[brettoliver]

Hi John. Not sure if this will help or not but I built UDO's generator with and a DCF77 analyzer including weather data some time back. You may find some parts useful? http://www.brettoliver.org.uk/DCF77_Signal_Generator_Analyzer/DCF77_Signal_Generator.htm

[brettoliver]

Hi
I like to watch the clocks advance/retard so trigger the clocks with a single button click. It should be very simple to automate the function using the DST change warning in the DCF77 signal. Here is my dial clock with a 30second movement fitted. Again a single button click sets winter and summer time. http://www.brettoliver.org.uk/Digital_Dial_Clock/Digital_Dial_Clock.htm

[JohnHaine]

Thanks - however it isn't clear whether the DST change warning is made available in the decoder that I'm using - I will check again though. So need to infer that a change has been made by comparing the decoded times before and after looking for anomalous hour shifts.

[JohnHaine]

Hello again Brett. Well this has been a long saga. Turns out that the DCF77 decoder we were using (not Udo's) doesn't work so the work was temporarily shelved. I've now picked it up again and written a much simpler decoder just for the bits we need, basically just dealing with DST shifts and clock setting. I'm now testing that with your DCF generator. Am I correct that if one wants to program a summer time change I have to send a complete program string and this will trigger a restart of the sequence please? What would be ideal is to just input a command that changes the Z1 and Z2 bits next time round without interrupting the pulse sequence.

[brettoliver]

Hi John so sorry for the late reply. I am retired now but seem to be busier than ever!.
As far as I remember the whole string has to be sent and it needs to be sent in the hour before DST (set the time in the code for 01:00 to 01:59) or it won't work.

[brettoliver]

Hi John.
I'll reply to you email here as there may be others who can help.
You asked " I think I can see in my highly simplified decoder that the generator starts a new "frame" immediately, and when it reaches the 17th second the bit is set to 1 to schedule a summer time change. I would assume that the bit will stay set to 1 until winter time arrives, is that not correct? From my decoder it looks like the bit is set only in that frame then reverts back to 0 in subsequent ones. From my reading of the spec in Wikipedia the bit should be set "while summer time is in effect"

Does the generator set the actual summer time from the start of the next frame, or, in this example, wait until the frame 4 minutes later as the hour rolls over?"

From my experiments with the generator and research on the DCF77 code bit 16 is set an hour before time change. Bit 17 then remains set during summertime. The generator as far as I remember sets the time change at 01:00 or or 02:00 (can't remember which time as I am on GMT and it may default to CET).

Looking at my winter and summer test videos http://www.brettoliver.org.uk/Master_Clock_MK2/Master_Clock_MK2.htm#sumvid the summertime change happens at 01:00 GMT 02:00 CET. The wintertime change happens at 02:00 GMT+1 (Summertime) 03:00 CEST.

[JohnHaine]

Thanks for the quick reply Udo! I am using your DCF Generator code with mods you suggested so that it outputs a DCF77-encoded pulse stream to emulate what we get from the GPS time receiver. That is, we get a logic pulse signal very like that which comes from a DCF RF receiver. This is just for development convenience so we aren't tied to the location of the actual GPS for development. Our code decodes the stream and synchronises our mechanical clock and needs to account for DST changes. So there's no bug as such, I would just like the encoder to be able to generate the pulse sequence that DCF does when DST is introduced or removed (spring forward/fall back). If this is possible with your code as it stands it would just be useful to have a suggestion of where to start.

[udoklein]

Can you refer me to some repo or paste the code? "Generator code with mods" is somewhat unspecific. I can read code better than textual descriptions.

[JohnHaine]

Thanks Udo, will do this evening. Sent from Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Udo Klein ***@***.***> Sent: Tuesday, June 20, 2023 11:45:39 AM To: udoklein/dcf77 ***@***.***> Cc: John Haine ***@***.***>; Comment ***@***.***> Subject: Re: [udoklein/dcf77] Welcome to dcf77 Discussions! (Discussion #41) Can you refer me to some repo or paste the code? "Generator code with mods" is somewhat unspecific. I can read code better than textual descriptions. — Reply to this email directly, view it on GitHub<#41 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQ4DX5ZDKKX25L36VBWA4LXMF5NHANCNFSM4XHLZMLQ>. You are receiving this because you commented.Message ID: ***@***.***>

[JohnHaine]

DCF77_generator_jlh.zip

Hi Udo, attached is the file. After some advice from you, it has lines 915 and 921 added to drive D13 high and low and somewhere the carrier output is disabled I think.

[udoklein]

According to the code in autoset_control_bits it calls autoset_timezone_change_scheduled. So I am pretty much sure that it should indicate if a time zone change (aka winter / summer time change) is going to happen.

[JohnHaine]

Thanks Udo, that's helpful.

[JohnHaine]

Just an update and another question if I may. After some thought I decided that, as the DCF77 encoded time source we have has the option of either providing UTC or CET/CEST, it was actually easier to have it in UTC mode and control the DST changes based on date - i.e. forward 1 hour on last Sunday in March and back last Sunday in October. I need now to test the code - I have the generator working and my decoder decoding. What I now need to do is to check that it operates correctly at the appropriate dates and times.

So the question please. If I set the time and date on the generator using the command line s23.07.12 01:00:00 for example, how long should it be before this is reflected in the encoded output?

[udoklein]

The DCF77 protocoll takes 60 seconds (+/- leap second) for one complete cycle. Thus in the best case the encoded output will reflect your change immediately and in the worst case it will reflect it after 61 seconds.

[JohnHaine]

OK, thanks Udo.

[JohnHaine]

Hello Brett, Many thanks for this – I think therefore I wasn’t waiting nearly long enough to see the change. I’ll have another look. Interesting and useful video. In our application the DCF77 decoder is driving a Gents Pulsynetic dial every 30s. The clock is located outside a lecture theatre and the area is pretty well empty on Sundays when the time changes take place, so rather than drive the clock forward I have decided to simply stop pulsing for 11 hours for the BST change and 1 hour for GMT. The wonders of modular arithmetic… Best regards, John. From: brettoliver ***@***.***> Sent: Sunday, June 30, 2024 6:32 AM To: udoklein/dcf77 ***@***.***> Cc: John Haine ***@***.***>; Comment ***@***.***> Subject: Re: [udoklein/dcf77] Welcome to dcf77 Discussions! (Discussion #41) Hi John. I'll reply to you email here as there may be others who can help. You asked " I think I can see in my highly simplified decoder that the generator starts a new "frame" immediately, and when it reaches the 17th second the bit is set to 1 to schedule a summer time change. I would assume that the bit will stay set to 1 until winter time arrives, is that not correct? From my decoder it looks like the bit is set only in that frame then reverts back to 0 in subsequent ones. From my reading of the spec in Wikipedia the bit should be set "while summer time is in effect" Does the generator set the actual summer time from the start of the next frame, or, in this example, wait until the frame 4 minutes later as the hour rolls over?" From my experiments with the generator and research on the DCF77 code bit 16 is set an hour before time change. Bit 17 then remains set during summertime. The generator as far as I remember sets the time change at 01:00 or or 02:00 (can't remember which time as I am on GMT and it may default to CET). Looking at my winter and summer test videos http://www.brettoliver.org.uk/Master_Clock_MK2/Master_Clock_MK2.htm#sumvid the summertime change happens at 01:00 GMT 02:00 CET. The wintertime change happens at 02:00 GMT+1 (Summertime) 03:00 CEST. — Reply to this email directly, view it on GitHub<#41 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQ4DX7DGEXKHDRH2XMW3K3ZJ6J5LAVCNFSM6AAAAABJYRCRRGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TSMJVGAYTI>. You are receiving this because you commented.Message ID: ***@***.******@***.***>>