[LinuxPPS] time compensation

[Paul]

Hmm, delay in the attenna cable? Your GPS unit will just think it is in
a different point in space. 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 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.