[LinuxPPS] time compensation

[Bernhard Schiffner]

Am Sonntag, 6. Juni 2010, 21:03:01 schrieb clemens at dwf.com:
> > Sorry I disagree completely, but I think subsequent posts have shown
> > that 'coax' delay is not significant in the scheme of things.
> 
> Let me explain the logic as I see it.
> 
> The important point (that is the point where the position is computed, or
> the time reckoned) is the antenna.
> 
> This is where the variable length paths from the several satellites is
> combined. Now you can have zero, or miles of cable from that point on, and
> it will do nothing but delay the signal, it will not change the time
> differences from the various satellites.  It is the combined signal that
> is important, and not the delay in the cable,- you could record the
> signals as they come into the antenna and play them back later and you
> would still get the same time.  The cable delay then is just that, if you
> had a mile of cable, you would expect to receive the signals later than if
> you had the receiver right at the antenna.  So with a reasonable amount of
> cable you are computing the time AT THE ANTENNA, but then must
> compensate for the fact that you saw this signal at a later time due
> to the length of the cable.
> 
> Hope that helps.

That's a perfect explanation. Thanks!

The receiver calculates the position / time for the phase center of the 
antenna.
It does this at a  (3/2c)*(lenght of cable antenna - receiver) shifted time.
It reports this to the pps-handling device.
There it arrives  (3/2c)*(lenght of cable receiver-PC) later.

Total delay will be 4,5ns/m cable, calculated from antenna center to serial 
port. 

Plus saw-tooth + converter-time
Max. saw-tooth time depends from receivers internal quartz usually 10MHz, 
means 100ns.
Converter-time is "big" (200-2000ns) but measureable and quasi constant.

-------

So let's assume you have calculated and added your delays, measured converter 
time, averaged your saw-tooth: this results in an accuracy estimated to be 
within 10 ns (serial port CD-pin).

10 ns means  about 3m uncertainity in position. I'am quite sure that in the 
position your receiver reports, you see differences bigger by at least factor 
10. (Caused mostly by a suboptimal position of your antenna)

This means there is nothing worth to do about delays, if your antenna has not 
a top quality position (top of roof, 2PI visible sky (semisphere), no close 
reflectors). 

The insertion of the precise position of the antenna into the receiver, and 
the selection of a reference-clock mode (sometimes possible) doesn`t magically 
correct poor receiving conditions.

-------

All these are peanuts compared to the "timeconsuming" monster the standard PC-
hardware is.
1.) Delays of 5.000 to 50.000 ns due to coverters, busses, interrupt-chain,  
taskswitchting, timer-readout (rdtsc is one of the most complex microcoded 
instructions in a modern CPU!) Not to mention the "SMI-Special".
2.) No oberservations are possible. You must trust everything the PC and it 
software (ntpd!) reports.

Far better: some architecture (ARM comes to mind) where GPIO is directly 
useable for getting signals/interrupts and doing some type of monitoring too. 
Here the fiddling with nasty details (like cable delays :-) ) makes a lot more 
sense.


Bernhard