[time-nuts] Re: Use of dual frequency GPS for NTP server and other purposes

[Bob kb8tq]

Hi

> On Oct 4, 2022, at 8:33 PM, Tim Lister <listertim at gmail.com> wrote:
> 
> On Tue, Oct 4, 2022 at 4:57 PM Bob kb8tq <kb8tq at n1k.org> wrote:
>> 
>> Hi
>> 
>> The main issue with using the output of a GPS receiver directly is
>> dropouts. They can be caused by a variety of things. When the GPS
>> “goes away” you loose all timing information.  Do these various things
>> ( jamming, birds, lightning, …..) impact you? If they do, depending on
>> just how the loss of timing impacts you, you do or don’t have a problem.
>> 
>> Into an NTP server, the impact will still be there. How great an impact
>> it is depends a *lot* on what the next level source going into the server
>> is. The commercial NTP gizmos tend to have things like OCXO’s or Rb
>> standards in them. That gives them a bit better performance than a
>> typical DIY computer based NTP server.
> 
> Yes they would definitely impact us. I neglected to mention that we
> have the rubidium oscillator option as backup in these units to
> provide holdover. Mostly to provide insurance/holdover for the case
> that weather takes out the antenna to give time to ship a replacement
> out from HQ in CA to whichever site was affected. Given that one of
> the time servers provides the IRIG-B signal for the 400 Hz control
> loop for the drives for a ~20 ton 2-meter diameter telescope, I'm not
> keen on a homebrew Raspberry Pi solution however much I like them for
> my own time-nut home use...

So indeed, having timing drop out is not a good thing ….

> 
>> 
>> If you *do* go with a dual freq GPS, you can do a very good job of working
>> out the location of your antenna. With some effort that can improve the
>> net timing accuracy. If post processing timing correction is ok in this
>> case, that also is a lot easier / more accurate with a full set of dual freq
>> GPS data to correct against.
> 
> A "real time" (latency ~<30 minutes) measure of the PWV would be
> helpful for scheduling/optimization of observations but there's also
> likely to be value in an improved value for use during later analysis
> at timescale >12 hours. Haven't done enough reading around of the
> literature on determining PWV from GPS to get a sense of where the
> error budget and improvements lie. I'm assuming something like a 48
> hour initial survey and having that post processed by e.g. the NRCan
> PPP service after the final GPS orbits are available would likely be a
> benefit but unclear how having a proper geodetic phase center vs a
> $200 bullet L1/L2/L5 antenna matters. Similarly it's not clear to me
> how much improvement in the water vapor determination comes from the
> increasingly precise (but increasingly delayed) GPS orbit products -
> it may be e.g. the Ultra Rapids are Good Enough.

For about $100 ( delivered ) you can get a “pretty good” Chinese multi
band antenna. It’s not as good as fancy $2,000 antenna, but it’s way
better than a hockey puck. With that and a week’s data into NRCan 
(it’s free ….. ) you can be pretty sure of your location to < 10 CM. That’s
good enough to “not matter” for timing. 

>> 
>> So, when it works, you might be down into the < 10 ns range. When that
>> bird sits on that antenna …. microseconds …. takes a nap … milliseconds ….
> 
> We're not an optical observatory so not in the pulsars & masers
> category. Driving demand on accuracy for us is normally very close,
> fast moving Near Earth Objects which can move at several hundred
> arcseconds/minute. If we don't want the timing uncertainty to degrade
> the position accuracy by more than the star catalog does, then we need
> timing precision in the ~1-10ms range. Determining diameters from
> occultations of stars by Kuiper Belt Objects, which have a transverse
> velocity of ~15 km/s, leads to similar requirements.

The advantages of all this stuff ( single band vs multi band ) are in the < 100 ns
range. If you do a good job on the single frequency stuff ( sawtooth correction ….)
the improvement is < 20 ns.  There is a footnote down somewhere that mentions
some sort of “99.9% of the time” stuff. There are unusual solar events that can 
push things well above the 20 ns range. 

Yes, there are other factors. There is another chunk for GPS <-> UTC. There also 
is a chunk for antenna / cable delays and the like. This stuff impacts both approaches. 
Normally that all should be < 100 ns. The delay part should be stable to < 20 ns in 
a typical setup. 

>> 
>> Lots of tradeoffs.
> 
> As always, tempered often by a lack of funds.

Somehow money always matters :) 

Bob

> 
> Tim
> 
>> 
>> Bob
>>