I am using this library to decode a DCF77 pulse stream from a reference source and it works well. However I can't work out from the documentation whether it handles the IH / CET / CEST bits and how to interface to them if it is possible. Can anyone advise please? I gather the library is no longer maintained and I can't find a way to contact the author.
DCF77 is not RTC. Antenna receive a 77,5kHz signal. there is on start of each second short volume level lowering. 100ms = "0", 200ms = "1". the receiver device collect complete message out of 59 bits and take needed information, like: time, date, DST, weather(decoder chip needed). You see there is nothing about time zone. it is correct lokal time. and Weather.
Thanks for swift reply. I'm very familiar with how DCF77 works. There are 3 bits carrying "DST" information - LH (sorry not IH) which is set for the hour prior to the change; CET which indicates that "winter time" is being carried; and "CEST" which indicates summer time. No time zone data as by definition the time is Central European. My question was whether the LH, CET and CEST bits are accessible on an API on this particular library. If not then I have to infer when a DST change happens by tracking the time across hour boundaries.
why not looking into source files?
That may be the next step but just wondering if any knows the answer first.
Can you give a link to the antenna and the module that you used ?
Which Arduino board do you use ?
How far away are you from the transmitter ?
The author has the code no longer on his personal website, and the code is 7 years old on Github: https://github.com/thijse/Arduino-DCF77
Someone asked about the DST, but no solution: https://github.com/thijse/Arduino-DCF77/issues/22
There are 13 forks. Maybe one of them has the DST.
I have a clock that runs on the DCF77 signal. I'm at about 450 km distance. It shows an indication for the summertime (we call it "summertime" and "wintertime" in the Netherlands). I never got it working with an Arduino.
The variables CEST and CET are named here:
You'd have to insert DST_announce (or whatever you want to call it) after prefix and reduce prefix to 16.
struct DCF77Buffer {
//unsigned long long prefix :21;
unsigned long long prefix :17;
unsigned long long CEST :1; // CEST
unsigned long long CET :1; // CET
unsigned long long unused :2; // unused bits
unsigned long long Min :7; // minutes
unsigned long long P1 :1; // parity minutes
unsigned long long Hour :6; // hours
unsigned long long P2 :1; // parity hours
unsigned long long Day :6; // day
unsigned long long Weekday :3; // day of week
unsigned long long Month :5; // month
unsigned long long Year :8; // year (5 -> 2005)
unsigned long long P3 :1; // parity
};
You just have to hack this method to get hold of the variables:
bool DCF77::processBuffer(void)
There is already an example of testing CEST and CET:
if (rx_buffer->CEST != rx_buffer->CET) . . .
The DCF77
class seems to provide a public method that tells whether summertime is in effect.
Many thanks for these suggestions, I'll study them carefully.
Just to close this off, for my application since the DST changes are applied on last Sunday of October (-1 hr) and March (+1 hr), and the library gives time, day of week, and full date, it is trivial to work out when to apply the shift without any other assistance from the library.
Thanks to everyone for the suggestions.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.