Heh, I bet this isn’t about what you thought the title suggested :)
I’ve been spending a couple of hours today, trying to get a DCF77 time code receiver working on the new ookRelay2.pde sketch. There’s a dcf77demo.pde sketch in the Ports library, which actually does all the hard work of decoding that pulse train.
It’s fairly tricky code, and I tend to throw in lots of tricky hacks (silly me, I know):
To use this, dcf77poll() has to be called often in loop(), like so:
(lots of #ifdef’s in there now, to make the sketch more configurable)
The weird thing is that this all worked fine in the previous incarnation of the OOK relay.
This timing code is far less critical than the 433/868 MHz OOK decoding, by the way. Pulses come in once a second, and all it needs to do is disambiguate short and long pulses. Easy stuff for an ATmega.
Except today… well, I don’t know why, but I can’t make any sense out of what’s happening. Been debugging with a few prints to the serial port via LEDs, but no luck. I’ve switched prototype setups, redone it all from scratch, changed DCF77 receivers… nada. Worst of all, there’s no pattern.
It’s probably the wrong moon phase, or somethin’ – I’ll revisit this some other time (soon).