Re: Testing the goodness of my GPSDO
With the Viavi PNT boxes, the goal is to meet various telecom specs
including long-term holdover, which is why the higher-end units are equipped
with a miniature rubidium standard. Great for holdover, but its
disciplining time constant is very long, something like 1000-2000 seconds or
so, and the AtomiChron service will massively outperform it while the signal
is present.
Attached is a screenshot comparing my own observed performance of the
PNT-6200 series GPSDO with the rubidium standard. Points of interest:
-
Short-term stability of the PNT box is not great by time-nuts standards,
regardless of whether AtomiChron is enabled or not. The miniature Rb module
is responsible for at least some of this (not sure how much offhand.) -
Longer-term stability is quite good with normal GPS (magenta trace), and
even better with AtomiChron (blue trace). But notice the breakpoint in the
blue trace near t=2000 seconds -- this is due to the intersection of the Rb
flywheel oscillator's stability with that of the AtomiChron service. The Rb
is winning the fight. In fact, its influence is actively harming the
stability of AtomiChron at all taus longer than 100 seconds or so. -
How do we know this? The green mask line is from the Sparkfun literature
at https://docs.sparkfun.com/SparkFun_GNSSDO/atomichron/#performance . It
shows even worse short-term performance, thanks to the cheaper TCXO. But at
the same time, the Sparkfun unit does a much better job taking advantage of
AtomiChron beyond t=100 seconds. By t=1 day, it's 10x better than the
much-pricier Viavi GPSDO.
If the Viavi PNT box didn't have the rubidium module, its short-term ADEV
would still be better than the Sparkfun box, and its long-term ADEV would at
least be closer. (There is probably a way to adjust the loop time constant
for the Rb version to work around this degradation but I'm not that familiar
with it myself.) At the same time, though, if the GPS signal were to go
away entirely, the Viavi PNT-62xx would remain safely in spec for hours,
while the Sparkfun unit would presumably drift rapidly. Horses for courses.
Srihari has no problem measuring his short- and medium-term stability, as
he's using some of the all-time greatest crystal oscillators as references.
But beyond a few thousand seconds he has no way to know how well his setup
is really performing, which is why a maser or an AtomiChron-based GPSDO is
needed.
And yes, he could clean up the output of the SparkFun unit very nicely with
one of those 8607 crystal oscillators. He could lock it with a time
constant of about 1 hour, so that it would improve the short-term stability
greatly while inheriting the long-term stability from the AtomiChron
service. This would also improve the phase noise, of course, at least near
1 Hz. The phase noise of an 8600-series OCXO is decent but nothing special
at wideband offsets.
-- john
From: Alex Denner adenner@sarissacap.com
Why is it best to have the "lowest-grade holdover oscillator available"? I
would think it would be best to try to match the oscillator holdover to the
time constant of the disciplining. Is that wrong? I notice SparkFun has a
TXCO....is that better than an OCXO for use with AtomiChron? What would
that do to the phase noise? Would it then make sense to put the output of
the AtomiChron into a low phase noise OXCO to improve the short term
performance or does that not make sense?
John,
Thank you for such an interesting and informative response. I have become enthralled with time and frequency generation and measurement. I have constructed a few relatively primitive GNSSDO's using both Rb and OXCO oscillators. I have played around with PI controllers as well as Kalman filters (which I believe to be superior). In the process I have learned a bit and made lots of mistakes. However, I have found---I am clearly just learning--- it seems one can get a very good combination of stability and phase noise with a GNSS disciplined Rb (I have had great luck with SRS PRS10 but I have only tried a few) and then a clean up oscillator. Is this combination the best or are there better arrangements?
I implemented a very simple Kalman filter to do disciplining rather than the typical PI controller or PLL, however, I have found that the particular disciplining algorithm seems to be much less important than the time constant chosen (and its gain if applicable). You are much more knowledgeable than me, is this generally true? As you understand, I'm sure better than I do, it is very easy for the output to be worsened if the servos are competing with each other. And, It seems it's very much an art to finding the right time constants or Kalman filter parameters to use on each servo. From my primitive investigations so far, I think I have found actual production GPSDO's where the servos do compete to the detriment of stability.
With the Viavi PNT boxes, the goal is to meet various telecom specs
including long-term holdover, which is why the higher-end units are equipped
with a miniature rubidium standard. Great for holdover, but its
disciplining time constant is very long, something like 1000-2000 seconds or
so, and the AtomiChron service will massively outperform it while the signal
is present.
Jackson Labs produced a high quality GNSS disclinped Rb with OCXO a few years ago. I believe that it was mostly Microchip components. Why wouldn't they apply the AtomiChron technology to those? It would seem that would be an awesome product. Are those boxes not telecom rated?
- Short-term stability of the PNT box is not great by time-nuts standards,
regardless of whether AtomiChron is enabled or not. The miniature Rb module
is responsible for at least some of this (not sure how much offhand.)
Again, you are far more expert than I, but I agree it must be partly the mini-Rb...why not use a better one or an OCXO for cleanup? I understand cost is important, but I would assume the AtomiChron feature would be added to the best instruments.
- Longer-term stability is quite good with normal GPS (magenta trace), and
even better with AtomiChron (blue trace). But notice the breakpoint in the
blue trace near t=2000 seconds -- this is due to the intersection of the Rb
flywheel oscillator's stability with that of the AtomiChron service. The Rb
is winning the fight. In fact, its influence is actively harming the
stability of AtomiChron at all taus longer than 100 seconds or so.
This plot is fascinating!! Thank you.
It would seem a better algorithm would could mitigate this issue, no?
- How do we know this? The green mask line is from the Sparkfun literature
at https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.sparkfun.com%2FSparkFun_GNSSDO%2Fatomichron%2F%23performance&data=05%7C02%7Cadenner%40sarissacap.com%7Caf6135d7c10a4be04fd208de7a8c16bf%7C0986ad13b1c44a95a5949ab87e8fce68%7C0%7C0%7C639082939285176734%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=AZMvjQlAV6T98NASx4zG5lypMsiVqzgzyiVf33BqHy4%3D&reserved=0https://docs.sparkfun.com/SparkFun_GNSSDO/atomichron/#performance . It
shows even worse short-term performance, thanks to the cheaper TCXO. But at
the same time, the Sparkfun unit does a much better job taking advantage of
AtomiChron beyond t=100 seconds. By t=1 day, it's 10x better than the
much-pricier Viavi GPSDO.
Thank you for the explanation. Why wouldn't SparkFun use a cheap OCXO with a short time constant? Wouldn't that improve the short term stability without hurting the long term stability by much? It wouldn't cost that much more to implement an OCXO...they could even have two models if they felt it hurt their margins...
And yes, he could clean up the output of the SparkFun unit very nicely with
one of those 8607 crystal oscillators. He could lock it with a time
constant of about 1 hour, so that it would improve the short-term stability
greatly while inheriting the long-term stability from the AtomiChron
service. This would also improve the phase noise, of course, at least near
1 Hz. The phase noise of an 8600-series OCXO is decent but nothing special
at wideband offsets.
What would you recommend as a good, obtainable OXCO to clean up the stability and phase noise of the SparkFun? I never heard of AtomiChron before this conversation and it seems it really can improve long term stability. Why is not deployed in GNSSDO's that optimize its performance such as GNSS--Rb--OXCO or whatever configuration is best?
Thank you,
Alex
From: Alex Denner adenner@sarissacap.com
Why is it best to have the "lowest-grade holdover oscillator available"? I
would think it would be best to try to match the oscillator holdover to the
time constant of the disciplining. Is that wrong? I notice SparkFun has a
TXCO....is that better than an OCXO for use with AtomiChron? What would
that do to the phase noise? Would it then make sense to put the output of
the AtomiChron into a low phase noise OXCO to improve the short term
performance or does that not make sense?
IMPORTANT NOTICE: This e-mail is intended only for the named recipient (s) above. It may contain confidential information or information that is privileged or that constitutes attorney work product. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail and/or any attachment (s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and delete the message and any attachment(s) from your system. This email does not constitute an offer or solicitation for the purpose or sale of securities. Any such offer or solicitation may only be made to qualified purchasers by means of the delivery of a confidential private placement memorandum, which contains important information about the terms and risks of an investment in funds managed by Sarissa Capital Management LP, and other documents associated with any such investment, each of which should be reviewed in its entirety prior to any investment. No investment decision should be made in reliance on this email. Any performance results contained in this email are estimates and unaudited. The funds managed by Sarissa Capital Management LP may no longer hold any of the securities underlying these results and may have subsequently acquired additional securities not reflected in any of these results. Past performance is not a guarantee of, and may not be indicative of, future results. Thank you.
There's only so much a given filter algorithm can do for a GPSDO in
steady-state operation. Kalman and related filters are mainly for holdover,
which is when influences such as aging and tempco of the flywheel oscillator
actually matter. Meanwhile, while locked, it doesn't matter why the
flywheel is drifting, it gets steered the same way towards the same target.
The primary knobs to turn are time constant and damping, and everything else
is of secondary importance at best.
JLT's low-noise Rb GPSDO is about the best in the business with regard to
the compromise between short-term and long-term stability with conventional
GPS reception. They use similar Rb standards as the newer PNT-62xx
hardware, but with a secondary OCXO to clean up the Rb. However, the
receiver chips they were designed with do not support AtomiChron, so they
would require a complete hardware overhaul.
If I were designing a GPSDO myself, it would look a lot like the JLT LN Rb,
but the loop would use a much shorter time constant when AtomiChron service
is active. That's the trick that the PNT-62xx unfortunately misses from a
time-nuts perspective. From the perspective of its intended customer base
it works great, so they have little incentive to keep tinkering with it.
Including a secondary OCXO when the market requirements don't call for it
would have been right out.
As for the SparkPNT, it's already somewhat expensive for a GPSDO sold at
retail, and that's before you consider the AtomiChron subscription. I think
it's a great piece of hardware - especially given that it's 100%
open-source! -- and I would buy one myself without a second thought if I
didn't have a homebrew solution. But at the same time I do think it was a
marketing faux pas not to use an OCXO. The right part for that box, at that
price point, would have been a MEMS OCXO. It would have improved
performance between t=1s and t=10s and satisfied the connoisseurs.
-- john
From: Alex Denner adenner@sarissacap.com
Sent: Friday, March 6, 2026 12:37 AM
.
Thank you for such an interesting and informative response. I have become
enthralled with time and frequency generation and measurement. I have
constructed a few relatively primitive GNSSDO's using both Rb and OXCO
oscillators. I have played around with PI controllers as well as Kalman
filters (which I believe to be superior). In the process I have learned a
bit and made lots of mistakes. However, I have found---I am clearly just
learning--- it seems one can get a very good combination of stability and
phase noise with a GNSS disciplined Rb (I have had great luck with SRS PRS10
but I have only tried a few) and then a clean up oscillator. Is this
combination the best or are there better arrangements?
.
With the Viavi PNT boxes, the goal is to meet various telecom specs
including long-term holdover, which is why the higher-end units are equipped
with a miniature rubidium standard. Great for holdover, but its
disciplining time constant is very long, something like 1000-2000 seconds or
so, and the AtomiChron service will massively outperform it while the signal
is present.
Hi
If AtomiCron starts at 1 ns at 1 second, it will be at 1x10^-12 at 1K seconds and
1x10^-13 at 10K seconds.
A typical telecom Rb starts out around 1x10^-11 at 1 second and goes down as
square root of tau. It’s at ~1x10^-12 at 100 seconds and might (but probably does
not) hit 1x10^-13 at 10K seconds (= it hits floor just a bit before this).
As noted in recent posts, OCXO’s with floors in the 1x10^-12 (many examples) to
1x10^-13 (few examples) do exist. Some examples hold their floor numbers out to
1K seconds after enough time on power / in stable environments.
What you care about is the intercept between the two sets of numbers. Yes, what
you actually care about is the phase noise intercept rather than the ADEV. What
we have to work with in this region is ADEV … sorry about that.
The intercept will be out at or beyond 1K seconds with AtomiCron turned on. With
it turned off it probably is past 10K seconds. For an ideal case, your control loop’s
noise bandwidth would be in this vicinity.
Bob
True, a good PRS10 will get into the low 13s at t=1000s. But the miniature modules used by the Viavi hardware are several times worse than that, so it's a bummer to see them affecting an AtomiChron-disciplined loop at t=1000s.
The best results I've seen for AtomiChron are from Ole R.'s BVA-based GPSDO, which seems to cross over near 2E-13 @ t=100s. If you were to draw an imaginary extension back to t=1s, the ADEV there would be somewhere around 1E-11. The "1ns" figure is about how much it might wander around per day (usually better than that.)
Ole was able to achieve about 3.5E-14 at t=1000 seconds. I have never managed to do better than 6 or 7E-14, but that is probably limited by the available references. Ole is also better at building GPSDOs than I am. 😊 I continue to hope Tom will put an antenna up one of these days, so we can see what's really possible in this geographical area.
Essentially, AtomiChron matches a good 5065A near t=1000s, beats the best telecom Rb I've seen (a Symmetricom XPro) by about 2x at t=100s, and is never less than ~30x better than the miniature Rb clocks from Safran or Microchip. There is no danger that an ADEV trace from a telecom Rb will intercept AtomiChron at any tau beyond t=200s, where the SparkPNT crosses the best trace I have from an XPro.
TL,DR: when locking to AtomiChron, you do not want to use a 1000-second loop with anything worse than one of Corby's trick 5065As.
-- john
-----Original Message-----
From: Bob kb8tq via time-nuts time-nuts@lists.febo.com
Sent: Friday, March 6, 2026 12:21 PM
If AtomiCron starts at 1 ns at 1 second, it will be at 1x10^-12 at 1K seconds and
1x10^-13 at 10K seconds.A typical telecom Rb starts out around 1x10^-11 at 1 second and goes down as square root of tau. It’s at ~1x10^-12 at 100 seconds and might (but probably does
not) hit 1x10^-13 at 10K seconds (= it hits floor just a bit before this). ...