[LinuxPPS] time compensation

[Hal V. Engel]

On Wednesday 02 June 2010 12:05:47 am Paul wrote:
> Hmm, delay in the attenna cable? Your GPS unit will just think it is in
> a different point in space. 

This is true for non-timing specific GPS units.  But timing specific units like 
the Oncore VP, UT, UT+, M12T... are setup to have the antenna position set 
based on a site survey.   This is typically done by averaging the positions 
gathered by the GPS over a several hour period (typically about 10,000 
positions).  This averaged position is perhaps with in 0.5 meters of the 
actual position of the antenna if reception is good at the time of the survey.  
Users that require the most accurate possible timing information (IE. 
astronomers) will typically pay to have a survey crew measure the antenna's 
position.  This surveyed position is then coded into the ntp configuration file 
for the receiver and this position is fed to the receiver by the driver.  By 
also giving the driver an antenna to receiver cable delay, which is also fed 
to the receiver by the driver, the receiver can compensate for the delay.  

One other benefit of having a surveyed antenna position is that the receiver 
can give accurate timing with only one satellite being tracked where as a non-
timing specific GPS needs at least 4 tracked satellites to give accurate time 
data since it also needs to calculate it's position in order to calculate time 
information.

Keep in mind that these timing specific receivers can, if properly setup, put 
out raw PPS signals that are accurate to with in 12 to 50 nanoseconds (newer 
models are more accurate) and the majority of this error is what is known as 
saw tooth error (this is related to the granularity of the oscillator on the 
receiver) for which the receiver can calculate a correction factor with the 
high degree of accuracy. in addition these receivers also feed saw tooth 
correction data to the ntp driver and I think the driver uses this to correct 
for the saw tooth error.  Reg is this correct?  Also do we lose this 
capability using the kernel consumer?  On very recent Oncore timing receivers 
after the saw tooth correction is applied the corrected timing pulse is 
accurate to with in 1 nanosecond if everything is correctly setup (this 
assumes a very accurate antenna position and a very accurate cable delay 
correction).  On older receivers such as the Oncore UT+ units I use the saw 
tooth corrected PPS time is with in perhaps +-10 to 15 nanoseconds of the 
actual epoch. 

As others have pointed out GPS units like the gps18lvc have a PPS that is +-1 
microsecond (IE. 100 to 1000 times the error of the saw tooth correct PPS of 
the Oncore units) and this swamps most other errors such as serial cable and 
port delays.  However serial cable and port delays are constant and it should 
not be too difficult to find info on how long these delays are and apply a close 
to correct correction.  These will typically be on the order of 40 to 60 
nanoseconds depending on the length of your serial cable and the amount of 
latency in the port (typically on the order of 30 nanoseconds).  

The only other source of errors that is significant is the delays introduced by 
the interrupt handler and these errors are highly variable and very difficult to 
quantify.  Unless you have access to some very expensive lab equipment 
anything you do with this is basically a wild guess. 
 
> What is the difference between a delay in
> the ether (I know it doesn't exist) and a delay in the cable? In fact
> the receiver will think it is 10% of the way up the antenna cable
> (velocity factor in coax is more like 90%). The unit corrects for time
> delays from the satellites to it's (assumed) point in space. Cabling
> from there to your computer does create a delay. Incidently the specs on
> some GPS modules are to 1mS (yes thats a milli not a micro second)

On most non-timing GPS units that have a PPS output the PPS is about +-1 
microsecond relative to the epoch.  The millisecond figure that you bring up is 
for the timing of the NMEA message not the PPS.

> 
> On Tue, 2010-06-01 at 16:16 -0600, clemens at dwf.com wrote:
> > > Hello,
> > >
> > > If I am running my gps18lvc via the ttyS0 of an Epia LT 10000 with
> > > LinuxPPS, what delay (cable, irq, etc) do I compensate for?
> >
> > Well, there are several things that you need to compensate for, but they
> > are all smaller than the 1us or so error you can expect in ntp syncing to
> > the pps signal.
> >
> > The important thing/place is your antenna, this is where the signals from
> > the various satellites are combined.  So, if you look up the specs for
> > your cable you will find a velocity factor of mabe 75-80% that of light
> > speed (Im guessing).
> >
> > >From this and its length you can come up with a delay.
> >
> > Ditto, if you look at the documentation for your receiver HOPEFULLY, it
> > will also give a number for a delay.  Add the two.
> >
> > Finally, as you note there is the big question of the delay in IRQ
> > servicing. There is something going on here in Linux that I dont
> > understand.  The last time I looked, the 'noise' in these interrupts
> > (that is plot the time of the timestamp vs the second that it is a
> > timestmap for) was one-sided on my FreeBSD machine.  This is reasonable,
> > since the timestamp can only be delayed by the IRQ delays, and not
> > advanced.  On Linux the noise was symmetric around zero.  I dont
> > understand that, but then I havent looked at it in a long time.  MABE,
> > with recent changes it is now one sided as it should be.
> >
> > In any case, the NTP algorithm SHOULD take care of this, choosing those
> > timestamps that arrive with the lowest delay, so probably nothing to
> > do here except try to get better hardware, so the delays are small
> > to begin with.
> >
> > As for me, with the antenna up on the roof, and I don't know how much
> > coax coming down from it (I have that number somewhere), and an
> > ONCORE receiver, I have delay=65ns in my ntp.oncore.0 file.
> >
> > With the previous PPS implementation (Ulrich) and the machine I was
> > running it on, Im sure I could see time errors  of on the order of 200ns,
> > so this 65ns would have been barely visible.  With the current
> > implementation and machine the error is more like 1us.  Once things
> > stabalize and EVERYTHING gets into the kernel distribution, Im going to
> > have to look at that again.
> 
> _______________________________________________
> LinuxPPS mailing list
> LinuxPPS at ml.enneenne.com
> http://ml.enneenne.com/cgi-bin/mailman/listinfo/linuxpps
> Wiki: http://wiki.enneenne.com/index.php/LinuxPPS_support
>