So, I originally posted this a while back when I was hip-deep in nano-second level time measurement and learning every day how little I knew about this field. We all take for granted that there are a billion nano seconds in a second and that in theory you can count those one-by-one if you have a precise enough oscillator but to actually have stability good enough to track the effects of sub-cycle changes to radio signals (phase changes) is not all that simple. Especially when the measurements themselves run over a day or more.
I eventually got it all to work 'in the lab' but nowhere near stable or accurate enough for a real life application. This was all done at very low radio frequencies with super low radiated power (under the license limits) and that of course complicated matters greatly.
The big game changer was to get hold of an atomic clock that I could run locally. That takes the sting out of synchronizing with external sources (such synchronization usually involves a PLL and while the long term stability is amazing over the short term it usually is quite terrible [1]) and using a relatively affordable SDR I was finally able to do this with enough precision to be able to differentiate between the ground conducted signal and the 'airwave' for one of the EU atomic clocks (DCF-77). It was really neat to see the effect of the day/night cycle on the propagation of the signal (exactly as predicted) as validation.
Once you do get measurement down to nanoseconds, you quickly realize how 'bad' so many clocks you thought were good actually are. Lots of GPS modules with massive sawtooth behavior. Over a day they may be within tens of ns. But over a minute, a lot worse!
Yes, but over a decade they are ridiculously precise.
And that's precisely the problem: when you need very short term stability that nicely couples into longer term stability you have your work cut out for you.
Another downside of this kind of project is that to collect the data you are always looking at a minimum of 24 hours or so of sample time and at high enough rates that really adds up. Suddenly you need media that are never going to hiccup during long sequential writes and it turns out that's not a simple problem either. Before long you'll be messing around with the buffering deep inside of GNU Radio (which is amazing piece of software by the way).
But: when it finally works it is extremely satisfying. To see a clock driving a frequency counter and a non-derived clock that lists 9 zeros with a 100 second sampling window is pretty cool.
Yup. I’ve known the guys at Meinberg since around 2003, when I started helping out with the NTP Public Support Project for NTP.org.
They are very well aware of both the short-term and long-term effects that they have to compensate for. And getting that both smooth and accurate down to the nanosecond level is particularly hard.
They are not the only vendor of Stratum-1 NTP time servers (on the AWS EC2-Chronos team, we called them Primary Time Appliances), but I think they are one of the best. If not the best. And a friend and former co-worker of mine from EC2-Chronos is now working there.
Fascinating stuff all this. I just had a very practical problem to solve so my interest was purely accidental but I have deep respect for the people that make such an outwardly simple thing the focus of their career to the point that they can contribute in a meaningful way to the field itself. Half the world (or more) does not recognize the degree to which we casually rely on incredibly precise timekeeping and how much of an achievement it is. More so because it is so invisible. What I've also found is that everybody in this domain is incredibly friendly and willing to share advice and knowledge.
(also a time-nuts lurker, who’d occasionally worked on related things)
The actual atomic frequency you’re locking to in an atomic standard is an obnoxious frequency in the GHz Range. For example Cs is 9,192,631,770 Hz. To get a 10 MHz reference frequency out of that requires a very high quality quartz oscillator and a PLL loop, so there’s a PLL right off the bat.
Yes, that's true, my Rubidium clock has one too. But it is a lot more stable than whatever is in the typical GPSDO which hunts like mad. If I compare my very best (and very precious) OCXO with the GPSDO and the Rubidium then the GPSDO is all over the place in the short term.
The long term stability is much better than a typical GPSDO, for sure. I was just making a somewhat pedantic statement of what’s in the atomic clock box.
I eventually got it all to work 'in the lab' but nowhere near stable or accurate enough for a real life application. This was all done at very low radio frequencies with super low radiated power (under the license limits) and that of course complicated matters greatly.
The big game changer was to get hold of an atomic clock that I could run locally. That takes the sting out of synchronizing with external sources (such synchronization usually involves a PLL and while the long term stability is amazing over the short term it usually is quite terrible [1]) and using a relatively affordable SDR I was finally able to do this with enough precision to be able to differentiate between the ground conducted signal and the 'airwave' for one of the EU atomic clocks (DCF-77). It was really neat to see the effect of the day/night cycle on the propagation of the signal (exactly as predicted) as validation.
[1] https://en.wikipedia.org/wiki/Allan_variance