Hacker News Reader

Comment by rkangel | Hacker News Reader

I'm still unclear why they need the MAC on top of the GNSS reception. I can understand if it's just to provide holdover in event of GNSS signal loss, but they seem to be saying that it provides better precision when you've got both.

View on HN

For anyone wondering, MAC = Miniature Atomic Clock. From the vendor product page:

> Microchip’s next-generation MAC-SA5X miniaturized rubidium atomic clock produces a stable time and frequency reference that maintains a high degree of synchronization to a reference clock, such as a GNSS-derived signal, despite static g-forces or other factors. Its combination of low monthly drift rate, short-term stability and stability during temperature changes allow the device to maintain precise frequency and timing requirements during extended periods of holdover during GNSS outages or for applications where large rack-mount clocks are not possible.

* https://www.microsemi.com/product-directory/embedded-clocks-...

Article by some folks from the manufacturer giving details on the capabilities (with graphs and such):

* https://www.gpsworld.com/new-miniature-atomic-clock-aids-pos...

Generally: if accurate positioning, navigation, and timing (PNT)—especially timing—is important in your infrastructure, then you need to plan for GNSS outages.

> In the event of the GNSS signal loss, we need to make sure the time drift (aka holdover) of the atomic-backed Time Card stays within 1 microsecond per 24 hours. Here is a graph showing the holdover of the atomic clock (SA.53s) over a 24-hour interval. As you can see, the PPS drift stays within 300 nanoseconds, which is within the atomic clock spec.

* Article.

That’s a good question. GNSS gives you a 1 pulse per second signal. It is often with 20ns of accuracy. Now you need to interpolate nanoseconds between consecutive 1pps pulses. This is where a high stability oscillator is needed. You can certainly use an OCXO for the fraction of the cost of a MAC. We went for the MAC because of the importance of the role that the device plays in our datacenter

Although clock holdover might seem like a pointless feature - GPS outages are very unusual* - what holdover is mostly for is giving you time to respond if someone clumsily knocks your antenna over, or crushes your coax cable, or it gets damage that makes it fill with water, or something like that.

A lot of the demand for high-precision clocks is for cell phone base stations, where there's no guarantee there'll be someone on hand to make repairs promptly.

* They happen occasionally, of course.

Various militaries do regular GPS jamming exercises

https://www.ofcom.org.uk/spectrum/information/gps-jamming-ex...

https://www.navcen.uscg.gov/?pageName=gpsServiceInterruption...

GPS spoofing is also a thing. Here's a paper where they are able to spoof time while letting the receiver think it hasn't moved (much, within error bars): https://ieeexplore.ieee.org/document/6451170

That paper is in context of power grid equipment, but the GPS attack generalizes.

In downtown mountain view I saw brief GPS outages a couple times a week, presumably due to people driving around with GPS jammers (e.g. to knock out GPS tracking of their own cars).

The GPS can easily wobble by 50ns back and forth as the constellation changes. That's a lot! And, it is not random on a short time scale.

Folks often think "Oh, +/- 50ns, 20ns RMS, easy to filter...", but that's totally wrong.

The GPS will report -30ns from stable for minutes on end, then slew to +10ns, then -5ns, etc. Any high-precision oscillator (such as for radar) that's being jerked around like that isn't going to be as stable as high performance needs.

Even for just handoff of handsets at 2.2-2.3GHz, having the radio network (aka cell towers) all locked to an oven-controlled oscillator that was aligned-to, but far smoother-than, GPS, made a huge difference.

Now, improvements to GPS/GNSS that track 12 satellites instead of 6, and across multiple constellations, can result in more stable radio-based time. But then you get into urban canyons, and can only see 5 instead of 12, and you're right back into the jumpy situation.

If I read correctly:

GNSS PPS is more jittery but does not drift. The MAC has 1000x less jitter but drifts. You can cleverly combine them with statistics and magic to get the best of both worlds.

From what I remember of textbook discussions of atomic clocks, stabilizing drifting oscillators is also in part how normal, old (50+ years) atomic clocks work as well, isn’t it? You have a fiddly and unreasonably high-frequency reference, you slave a relatively garden-variety standard like an environmentally controlled piezoelectric crystal to it, and then feed your periodic signals, counters, etc. off that.

Yes. Surprisingly, atomic clocks have high jitter compared to ovenized quartz oscillators. Every atomic clock package is outputting its signal from a quartz oscillator that is disciplined by the atomic oscillator.

Phase-locked loops[0] are not magic ;)

Also I imagine they are using a bog standard Kalman filter[1].

0. https://en.wikipedia.org/wiki/Phase-locked_loop

1. https://en.wikipedia.org/wiki/Kalman_filter

I've implemented this (using GPS PPS to discipline a clock) using regular old PI control loops. I just make the loop damped enough to filter out the GPS PPS jitter and you're good.

Its more about stability in between the PPS from the GPS.

having the MAC means that the 10mhz reference signal is going to almost always be 10mhz, and in any given second contain 10million pulses[1].

However if you're just relying on GPS's PPS and a standard quartz oscillator, then the 10mhz reference is going to wobble about.

[1] this isn't really true, but illustrates the point of stability.

You use a jittery GPS PPS signal to discipline a highly stable primary clock through a very "slow" filter. The GPS PPS might have an RMS period jitter of say 10-20 nanoseconds, but the drift will be 0.

Then, you can use that disciplined primary clock to provide actual time for timestamping, etc.

I think they mean better precision during holdover because they model any inaccuracy of the rubidium clock while GNSS is up in order to compensate the local clock when GNSS isn't working.

Reply on news.ycombinator.com