My DCF77 library now got the capability to literally “look into the future”. Well, sort of. The new function void DCF77_Clock::read_future_time(time_t &now_plus_1s) does the trick.
void read_future_time(time_t &now_plus_1s) {
DCF77::time_data_t current_time;
DCF77_Clock_Controller::read_current_time(current_time);
DCF77_Encoder::advance_second(current_time);
convert_time(current_time, now_plus_1s);
}
But what is so interesting about this capability that I will describe it in a dedicated article? First of all lets have a look at its implementation. It just reads the current time, then pushes it to the DCF77_Encoder to advance the second. Not to hard. But what is it good for? Well, I conceived it while developing a DCF77 time switch. As it turns out my special switch logic consumes some significant CPU load. Thus I could not guarantee that it would switch right at the start of the second. My solution is basically the new function explained above plus some buffering. That is: at the start of the second I will always read the desired target state that was computed during the previous second and output it. Then I will use the read_future_time function to read the time 1s ahead. This gives me almost one second to compute the next output state. Plenty of time even for a complex and CPU heavy algorithm. Once computed I store the result in an intermediate variable for output at the start of the next second.
You might say, yeah, what’s the deal? Who would care about a time switch that is maybe 1/10 of a second to late or jitters some milliseconds? And of course you are right. in 99% of the cases it would not matter. But look at it from the other side: if it matters you will be happy that it works as it should. Since my library offers superior decoding performance I also care about jitter in derived implementations. So this article is supposed as a blueprint on how to get rid of jitter or lag due to heavy CPU load. Or to cite Amy Rand “If it is worth doing, it’s worth overdoing.” 😉
Blinkenlight 