WWVB cont’d

[Saturday 1/11, Monday 1/13, Wednesday 1/15: 3.2 miles each]

I’ve been doing some more with my homebrew “atomic” clock that I started while we were living in Iowa.

There are multiple steps in the process and my hardware/firmware solution I think is running ok for the lower level parts but not so good for the upper level parts. I realized that I could read the low level results using the serial port output and then work on the higher level algorithm in an easier environment.

So I hooked the thing up to a raspberry pi that is otherwise not very busy and I have been working on it a bit.

The low level processing results in one character for each 1-second clock tick. There are three options: 0,1, and M. The low level output is a stream of those three characters.

I was already printing that out, but my firmware also prints some debugging text. So my raspberry pi program has to strip out the extraneous stuff.

The next thing to accomplish is to locate the beginning and ending of a 1-minute data string. The data has a number of non-changing markers embedded in it. I wrote a routine to score marker string against the incoming data to look for good match. I discovered that when the signal is strong I will get a 95-100% match on the marker string. And that helps me locate the 1-minute strings within the data stream.

After that I can start looking for the data itself. It is very rare to have a 100% correct decoding. So I’m going to try to combine multiple readings to make a running estimate of what should be coming next.

Here is the marker string. It repeats every minute and you may notice that the start/end of the minute is marked by two consecutive M’s.

Here is some of the data coming in while the signal is strong. You can see the structured nature of it just by the diagonal shapes. If my screen had been set up at the correct width, the diagonals would show up as vertical lines. Do you see the diagonals with doubled M’s? (in that top line you can see a full string from MM to MM)

Here you can see the diagonals slowly erode into just noise. The signal seems to be best right after sunset and right before dawn.

The arriving data is scored against the marker string at each character position.

Here is some output from my matching program. Each line represents one minute, each little “..” is a single second. The high match scores appear to be finding the position of the 1-minute segments in a reliable way during good signal periods. The yellow highlighted scores line up vertically on the same character as the start( or end?)point of the cycle. (The number shows the scoring value using the most recently arrived 60 characters with 36 being the highest score). The decoded time and date (green and purple highlighting formatted hh:mm day year ) shows the hour decoding steadily at 10 and the year being 25 The day was the 13th and you can see the 3 is pretty regular but the 1 is a bit more elusive. I’ve noted what I think the minutes are doing. The 18 and 21,22 I believe are the correct values. The 10:20 line shows 10:60.. the zero came through but the 2 was not clear.

So you can see how using multiple lines and some logic you can infer a value from less than perfect decodings and some knowledge of the things that don’t change very often, like year. I have more work to do to get that logic figured out.

Even with perfect decoding of the markers (score 36!) there still will be errors in the data.

Also, I think there will be multiple stages with some wider searching before we reach a “lock” state. And that implies some measure of confidence in our current understanding. Once we get into lock there could be stronger reliance on the next expected values.

There are mathematical tools that I think might help, like Kalman filters(?) but I don’t really know much about this kind of thing, so I am piecing it together on my own right now. Maybe I will come back to that.

I’m really encouraged to see my low-level decoding is working rather well!