[LinuxPPS] time compensation

[Paul]

Can this accuracy be achieved with 'consumer' GPS modules? Or are such
accuracies only available with 'professional' units (you know the things
I mean 19" rack and costing tens of thousands dollars, pound euros?)

On Wed, 2010-06-02 at 17:27 -0600, clemens at dwf.com wrote:
> > 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?
> 
> Yes.
> 
> >  Also do we lose this capability using the kernel consumer?  
> 
> Probably not.
> It would depend on how the kernel consumer is coded.
> But instead of just USING the saw tooth correction in the user-code 
> calculation,
> the ONCORE driver passes this offset to the kernel and lets it do the 
> arithmetic.
> As such it has the corrected timestamp for its own use.
> 
> <snip>
>