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.
Yes, I used to have two Cesium standards in my basement, and that allowed me to make FreeBSD the first kernel which could be wrangled to nano-seconds.
These days timekeeping is much more routine and standard hardware, but even if you miss out on LORAN-C and time-by-telephone and leap-seconds, it can still be lots of fun.
Once you get into it, you can look at the log files, call the remote site, and tell them that somebody left the door to the server room open again.
How ?
A temperature difference of 1°C more or less translates to a 1PPM shift (one microsecond per second) in the kind of crystals used for modern motherboard
clock chains.
Most air-con systems will oscillate a couple of degrees with approx 20minute period (gentlemen: Tune your PLLs), so a sudden 5 PPM excursion is either a broken air-con or a door left open.
One of the most amazing feats of applied time-nuttery was Steven J. Murdochs work on fingerprinting the timezone of remote servers, based on their TCP sequences numbers.
(Amongst other things, he found out that a lot of Tor nodes were most probably located in north-eastern USA.)
There's a lot of interesting stuff in the time-nut world. There's a fun mailing list at https://time-nuts.febo.narkive.com/ and Jeff Geerling has been doing a lot of stuff with clocks lately on YouTube. An interesting intro project is to set up a GPSDO and track the long-term aging of an OXCO or Rubidium standard (many of which are surplused out of telecom applications for somewhat reasonable prices on eBay).
Don't be surprised if over shorter time spans your OXCO is more stable than the GPSDO (and the Rubidium standard will almost certainly be more stable over the mid term as well, you'd have to do a fairly long run to see any measurable deviation at all).
I presume you mean in a vacuum. You could have only gotten that particular answer if you had redefined the meter as well in a fairly substantial way and I suspect a lot of people would have been upset if you attempted that.
Exactly. The definition of the meter was originally derived from the circumference of the Earth and the second is (now) defined as a specific number of vibrations of a particular state of a particular atom. If you want to change the meter to make the speed of light in vacuum a nice round number then you'll end up affecting pretty much all of the derived units upsetting the whole SI system.
And in the end it doesn't matter. You should just use the right number, which is arbitrary and landed on 7500 m/second and change short of being 'perfect' but it would have been an incredible coincidence if it did.
The reason that didn't happen is because the speed of light was one of the harder numbers to pin down and the first estimates and later refinements happened much later than the definition of the meter. And to complete the circle: the meter is now defined as a fraction of the speed of light! This has the interesting property that even though we may get better measurements for various constants the fixed ratio means that SI as a whole remains standing.
Thank you! I've had the idea of aquiring an atomic clock in the back of my head for a while now and I'm glad to see there's a like-minded community out there. I'm not even sure what I'd do with it except measure time dilation effects.
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.
[1] https://en.wikipedia.org/wiki/Allan_variance
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.
(Card carrying time-nuts member here.)
Yes, I used to have two Cesium standards in my basement, and that allowed me to make FreeBSD the first kernel which could be wrangled to nano-seconds.
These days timekeeping is much more routine and standard hardware, but even if you miss out on LORAN-C and time-by-telephone and leap-seconds, it can still be lots of fun.
Once you get into it, you can look at the log files, call the remote site, and tell them that somebody left the door to the server room open again.
How ?
A temperature difference of 1°C more or less translates to a 1PPM shift (one microsecond per second) in the kind of crystals used for modern motherboard clock chains.
Most air-con systems will oscillate a couple of degrees with approx 20minute period (gentlemen: Tune your PLLs), so a sudden 5 PPM excursion is either a broken air-con or a door left open.
One of the most amazing feats of applied time-nuttery was Steven J. Murdochs work on fingerprinting the timezone of remote servers, based on their TCP sequences numbers.
(Amongst other things, he found out that a lot of Tor nodes were most probably located in north-eastern USA.)
https://dl.acm.org/doi/10.1145/1180405.1180410
Hey Poul,
That's been a loooong time, nice to see you turn up here. Hope you're doing fine.
My own favorite story of time keeping is this one:
https://www.nist.gov/news-events/news/2010/09/nist-pair-alum...
The list archive link seems to 404, but this one works: https://febo.com/pipermail/time-nuts_lists.febo.com/
There's a lot of interesting stuff in the time-nut world. There's a fun mailing list at https://time-nuts.febo.narkive.com/ and Jeff Geerling has been doing a lot of stuff with clocks lately on YouTube. An interesting intro project is to set up a GPSDO and track the long-term aging of an OXCO or Rubidium standard (many of which are surplused out of telecom applications for somewhat reasonable prices on eBay).
Also vaguely related, the precision clock kit by Mitxela - https://mitxela.com/shop/clock4
Then there's the EFOS3 Hydrogen Maser by https://www.efos3.com/
There is a very deep rabbithole in here.
Don't be surprised if over shorter time spans your OXCO is more stable than the GPSDO (and the Rubidium standard will almost certainly be more stable over the mid term as well, you'd have to do a fairly long run to see any measurable deviation at all).
My big question is why didn’t we just say the speed of light is exactly 300,000 meters per seconds when we redefined the foot.
Speed of light in what?
I presume you mean in a vacuum. You could have only gotten that particular answer if you had redefined the meter as well in a fairly substantial way and I suspect a lot of people would have been upset if you attempted that.
Might as well use Planck units then.
https://en.wikipedia.org/wiki/Planck_units
Because then the distance between earth's pole and equator would no longer be 10,000 km.
Exactly. The definition of the meter was originally derived from the circumference of the Earth and the second is (now) defined as a specific number of vibrations of a particular state of a particular atom. If you want to change the meter to make the speed of light in vacuum a nice round number then you'll end up affecting pretty much all of the derived units upsetting the whole SI system.
And in the end it doesn't matter. You should just use the right number, which is arbitrary and landed on 7500 m/second and change short of being 'perfect' but it would have been an incredible coincidence if it did.
The reason that didn't happen is because the speed of light was one of the harder numbers to pin down and the first estimates and later refinements happened much later than the definition of the meter. And to complete the circle: the meter is now defined as a fraction of the speed of light! This has the interesting property that even though we may get better measurements for various constants the fixed ratio means that SI as a whole remains standing.
Thank you! I've had the idea of aquiring an atomic clock in the back of my head for a while now and I'm glad to see there's a like-minded community out there. I'm not even sure what I'd do with it except measure time dilation effects.
I can recommend Rubidium clocks from decommissioned cell towers. $150 for a refurbished one. Beware seller rep as usual.
SSL error when loading this site?
They got stuck in time ;) Port 80 exclusively.
this already is a 20yo site or so. why the hype today?
Historical material is always welcome on HN! We try to optiize for intellectual curiosity, not novelty.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
maybe I don't understand hackernews well enough than?... I thought it was about news
It's not a formal "news outlet". You can see what's on-topic at the top of the guidelines: https://news.ycombinator.com/newsguidelines.html
Unless you were already well acquainted with the time-nuts universe, this is news...
Is this going around in other places today, or does posting something to HN qualify as "hype"?
With the recent abolition of the leap second, this is as good a time as any.
It was just the correct time.
I mean, time really is a tough nut to crack.
When is it time to run a world class time reference in your basement?
For time nuts, it's always time...
If you don't get it, then, you just don't get it...
There was this hilarious picture of a guy with a full sized atomic clock strapped to his arm. Ultra precise wristwatch. Just in case.