[time-nuts] FTS4060 Saga

Tom Van Baak tvb at leapsecond.com
Wed May 17 22:03:31 EDT 2006

> A problem that shows up every now and then is that the standard 
> deviation on a 500 second average is above 10 ns (typical is 9 ns).  For 
> example here is some data all this morning (17 May 06):
> Time Interval (ps)   time       sigma
> 975803               04:49:20     9
> 969817               04:57:40    98
> 919359               05:06:00   240
> 838596               05:14:20   349
> 957634               05:22:40   150
> 979542               05:31:00     9

I typically see a 9 ns sdev for an M12 at 300 second
averages so your system is working correctly part of
the time.

> I have a couple of ideas of what might be causing this.  One is that 
> there were no satellites to track and the crystal in the M12+T drifted, 

Check your M12 logs for satellites tracked and see if
the high sdev points correlate with a dip in visibility.

> but think this is almost impossible since the elevation mask now is at 
> 20 degrees.  The other is multipath.  Is there any information on how 

If you are experiencing multipath it will likely re-occur
in 12 hour patterns.

> multipath effects the M12+T?  I would think that in 0-D mode and 
> tracking only one satellite then multipath would be a factor, but if 
> tracking a bunch of satellites then multipath on one of them would not 
> be a factor. 
> Since I'm logging the sigma when I see this I just toss the data.  
> Notice that for the 3 points where sigma is 9 ns the TI looks like:
> 975803
> 979542
> 976696
> 976590
> Where the spread is under 5 ns which is good.
> I would like to know what's causing this.  Any thoughts?

Check your raw (unaveraged data) to see if the high
sdev is due to just one bogus point or if the signal is
in fact generally noisier for that 500 second average.

Are you sure it's not your counter again? Do you have
another counter you can try for a day?

As a personal note, I log most everything at 1 Hz but
often use 300 second averages in calculations. Disk
space is cheap and when you have to go back to look
at old data to solve problems it's easier to spot then
when you have the raw measurement data instead of
just the averages. Also it's a good idea to log all your
GPS data; again for this same debugging purpose.


More information about the time-nuts mailing list