Comparing samples from clean and noisy environment
I have a highly accurate time source in the form of a Motorola VP Oncore GPS which emits a short pulse every second which is within microseconds of UTC and hence can use this pulse as a reliable indicator of phase.
I set up a small program that synchronises to the GPS 1PPS pulse and then records samples every 1mS for the following second. Each sample is then placed in a bucket of 11mS and the majority high or low is used to produce a 1 or a 0. (11 is a good number as it is odd, i.e. there is never any doubt about whether high or low is in the majority, and it divides the second into a good number of samples).
Below is a sample shown for just the initial second, the minute marker, for several minutes in a ‘medium’ real-world noisy environment on the edge of my desk (where I would like my clock to reside) and then lastly two samples from a ‘quieter’ environment near the window.
The numbers of the right hand side are, total samples, number of hi in first 50 buckets (555 samples), number of hi in last 50 buckets (555 samples), and three numbers indicating the population of 3 buckets in each of the estimated mid-points for the 0-100mS, 100-200mS and 200-300mS pulses.
It is noteworthy that at the start of each sample is a quiet period of around 17mS. My distance from the transmitter translates into only a couple of mS so this delay must be due to the lock-up time on the phase locked loop of the receiver. I think it is fair to say that observations so far suggest the PLL takes around 20mS to lock and around 50mS to unlock.
Analysis of the mean and deviation of the sample suggests that the minute mark may be recoverable with very limited confidence level.
A closer look at second 59
Continuing on our investigation with the second that precedes the minute marker which we always know will be A=0,B=0
Here we really see the effect of the noise with the external RF interference knocking the PLL out of sync and producing spurious streams of erroneous data.
Statistical analysis here shows that averaging across signals would not produce the correct result, the noise has overwhelmed the receiver.
Final reflections on noise
The receiver module I am using does the majority of the work for us, it receives the 60kHz CW signal and using a tone decoder/phase lock loop of some kind translates this to a logic output (and helpful inverts it). The receiver works very well in ‘quiet’ environments but in realistic noise environments around my computer (the location I would like my clock) it cannot cope with the PLL losing lock and producing highly spurious outputs.
Once you know the accurate time (slightly against the spirit of trying to decode the signal in the first place) it is possible to generate the local signal prediction (especially if you gloss over the details of leap seconds and day light saving changes) in which case the problem would reduce to one of calculating phase only but even this seems to be challenging in the RFI environments I was considering.
Spectral analysis suggests a noise peak at 144.5Hz so a low pass filter might help but statistically from the samples I have taken it would still not give a good level of confidence with the signal.
Therefore it seems that rather than any further signal processing in the noisy environment I need to relocate my receiver to a quieter location or seek an alternative time source. It should be noted that even in a quiet location there will be some spurious noise but this should be easily eliminated by averaging… more of that later.
And finally a look at what we get when we do find a quiet spot
It’s a bit disappointing to conclude that signal processing won’t really help us recover a signal in the presence of real-world noise but if you accept that fact and relocate the receiver a metre or so away to a quieter spot the receiver module (here) does a great job on its own.