Radio controlled clock, the hard way

scurrier

Hello all,

So, I just finished making a clock using the PPDB. I noticed that the accuracy of the clock leaves something to be desired even though I've been told it is in spec (4 min/month fast estimate). Which got me to thinking... wouldn't it be cool to make it a radio controlled clock? I am talking about syncing the clock periodically to the signal from WWVB, the atomic clock broadcast from Colorado.

Sure, there are chips out there that let you simply hook up an antenna and they do they work for you. But this is a project! I want to do it myself the hard way! Problem is, I am a mechanical engineer and I don't know where to begin to interface an antenna or antenna circuit to the Propeller. My best guess would be that I need to get an antenna designed for receiving 60 kHz signals (which the broadcast uses), design some kind of analog band-pass filter centered on 60 kHz, figure out how high of Q to design the circuit for, and then figure out a way to translate the broadcast's pulse width modulation to logical 0's and 1's for the propeller to read.

Or, maybe I should find a way to make the antenna circuit give me an analog signal that could be put through an ADC into the propeller? I bet that if I could just do this, I could very easily get this thing working, at least at night when the signal is supposedly very strong. I have had a course or two in digital signal processing, so I think this would be my preference if possible.

Any ideas? I could use any advice, even just a "google this subject" push in a possible direction.

Thanks,
Shaun

Phil Pilgrim (PhiPi)

See this thread:

http://forums.parallax.com/showthread.php?t=105674&highlight=hook+antenna

I failed with the WWV reception, though, since I'm outside their stated fringe area. Hopefully, you will have better luck! Please let us know how it works out.

-Phil

andrewsi

I'm actually in the middle of doing exactly this project myself. I got a C-Max module from Sparkfun, which does a lovely job of receiving the WWVB signal and puts out (your choice) of high or low pulses directly to an input pin, no pullups or pulldowns required. The wiring is completely trivial.

The code, on the other hand, is growing more complex every day.

What I have working:
- Good radio reception pretty much anytime after sundown in the Seattle area.
- Modifications to the Servo pulse-width module on the OBEX that set up a counter to accumulate while the signal is low, and write the encountered pulse width durations to global memory.
- A routine that decodes the pulse widths (within a certain threshold) into MARK, 0, or 1 bits, or signal an error if the pulse width strays too far from the defined lengths of 200, 500, or 800ms. Since the 60khz carrier doesn't go "off" instantaneously, the signaled beginning of a pulse from the radio module can stray a good +/-15ms or so from the expected "exact" beginning from pulse to pulse, if you treat the second Mark as authoritative.
- A routine that waits for the double-Mark that signals the top of a minute.
- Collection of a minute's worth of pulses after synchronizing to the beginning of the frame into two LONGs.
- Decoding of a full frame to the date/time in GMT, and setting the RTCEmulator to the correct time and date, including a program-defined correction from GMT to local time zone, as well as (testing this weekend!) handling of a changeover from DST to Standard or vice versa.
- Modifications to the Propeller_RTCEmulator module that allow you to pass in the CNT at the time the negative-going edge of the second-in-a-row MARK was received, indicating the top of a minute, determine the correction factor between what the clock thinks the beginning of a second is and what was determined from the radio, and to synchronize the running seconds to that new count.
- Serial LCD output of the time in the RTCEmulator.

What remains to be done:
- Bit-averaging or Kalman filter or something to try to improve accuracy of ongoing full frames of data in the event of random bit errors (which are reasonably common.) This is a tricky bit that I haven't quite cracked yet, like how to know when a frame is "good enough" to be safe for updating the RTC.
- Periodic resync to the top of a minute.
- Syncing to the WWVB DUT correction factor in tenths of a second to get true UTC.
- Accounting for leap seconds properly if they should occur.
- Prettier display
- Code cleanup.
- Hardware button interface for setting things like GMT offset, observe DST, etc.

This is my first Propeller project. Been working on it a little at a time nights after work for about the last 2 weeks. :-)

Andy

David B

I did something similar a long time ago, except that I decoded the bit pulses from the 100 Hz tone that's transmitted on the WWV shortwave broadcasts. That was back on my powerful new Tandy 286 PC, way before propeller days.

It was absolutely amazing to watch it synchronize to the bit pattern and display the time from a signal that would sometimes degrade into pure static from an audio perspective.

I think that the getting the analog radio receiver part itself working to the point of emitting a strong enough signal to work with will be a non-trivial part of this project (although if you wait a little while, Phil will probably produce a pure-propeller WWVB receiver!)

Using the shortwave WWV signal might be a little easier way to get started because you can hear the audio to verify that a strong signal is being received. Once you've detected the pulses, the decoding would be pretty much the same as decoding the 60 kHz signal. If you didn't want to make your own receiver, it's pretty easy to get an inexpensive shortwave receiver, or alternatively, there are dedicated WWV receiver boards available for not too much money.

You can even download a few minutes of WWV broadcast in WAV form from somewhere on the internet if you want some dependable audio to test on.

You could probably use the Goertzel algorithm on the propeller to detect the 100 Hz tone, but after that it would be your challenge to build the decoded time out of the noise and interference.

andrewsi

I guess the question is, which part of the project interests you most: Building the antenna and a circuit to demodulate the carrier signal into pulses, or writing the code on the propeller to read the pulses and build the clock from it?

In my case, it's definitely the latter. The chip receives the radio signal and demodulates it, but the signal can be noisy and the local environment has a lot to do with that. An external hard drive about 5 feet away seems to generate enough electrical noise to ruin the signal when it's actively writing, even at night. Anyway, after my last couple weeks writing the code, I really think there is much more "work" to do in interpreting the signal than there is in building the radio receiver itself, or at least, that's the part I found interesting.

andrewsi

Oh, and it's also fairly easy to determine the noisiness of the signal, at least using the C-Max receiver I got from sparkfun, in the following way:

A perfect noiseless WWVB signal will have a train of pulses where the leading edge is exactly 1 second apart (+/- maybe 30ms due to the non-instant carrier decay I mentioned earlier). When there's noise in the signal, you tend to get short pulses at irregular intervals where there shouldn't be one at all. This has the effect of shortening true signal pulses that should be longer (if you think about it, getting reliable MARKs is the most difficult and 0's are the least difficult), as well as adding in new leading edges that shouldn't be there at all.

So you just keep a running average of the leading-edge to leading-edge duration. When it deviates significantly from 1000ms in either direction, you have a noisier signal, when it stays nice and close to that figure, you have a strong one and good reception.

I'm putting together a few custom characters for my serial LCD to display signal strength based on this algorithm.