[LinuxPPS] time compensation

[Paul]

Sorry I disagree completely, but I think subsequent posts have shown
that 'coax' delay is not significant in the scheme of things.
 If you are actually using a remote antenna the GPS unit will work out
where it is based on delays from satellites. Forget about time for now,
but the position will move depending on coaxial delays. Only after it
has done this does it work out the time - correcting for the delays it
has seen (including the coax). So the coax will have no effect on the
time to a first approximation
 Well actually things are not quite so simple because the position
algorithm assumed passage of the radio signal directly from the
satellite, and if your cable goes straight up and the satellite is on
the horizon.... But it is certainly not going to generate a delay of the
velocity factor of the coax multiplied by the length multiplied by c as
has been stated here. In fact it could be an advance, simply because the
position is not exact.
 Of course a GPS18LVC is not an antenna - it is a receiver. So now it
works out it's position correctly and there is a delay in the cable
sending the PPS signal. Unfortunately this cable is neither coax or a
twisted pair, so the only way of working out the delay is by
experimentation.
On Wed, 2010-06-02 at 16:12 +0200, Remco dB wrote:
> On Wednesday 02 June 2010 09:05:47 Paul wrote:
> > 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)
> > 
> 
> The velocity factor for 'normal' coaxes (e.g. with PE dielectricum) is 0.66
> (i.e. vf = 1 / sqrt(Er), with Er = dielectric constant) -> 1/sqrt(2.3) = 0.66 
> for PE dielectricum. (For e.g. PTFE the vf will be 0.69, Er = 2.1).
> 
> This means that your receiver is 1/(0.66) = 1.5 more wavelengths away from the 
> antenna than the length of the coax implies when PE coax is used. 
> 
> With the speed of light being approx. 3E8 m/s, this means that the signal 
> arrives 1/3E8= 3.3 ns later. In the coax this will be 3.3 * 1.5 = 5 ns/m.
> 
> Therefore, for very precise timing, a correction has to be made for the cable 
> length. E.g. with the Oncore driver (Reg :-) one can enter the the DELAY.
> I interpret this delay as: ĺength of the coax in metres * 5 ns and that the 
> Oncore itself (or the driver, #30) corrects this to 'additional delay', due to 
> the fact that a part of the propagation path is within another dielectricum 
> than air. 
> 
> Note that when there are other dielectrica in the atmosphere, e.g. clouds 
> and/or heavy rain, the same theory applies and delay of GPS signals in general 
> occurs (with this method it is possible to derive the total amount of moisture 
> within a vertical column in the atmosphere e.g.). The dielectric constant of 
> water = 80, so the velocity factor is 0.11 (!).
> 
> Milliseconds of delay therefore are not the result of coaxial cabling in my 
> opinion. How the receivers process the GPS signals and 'convert' them to your 
> DCD-pin, is of course another issue. 
> 
> Remco
> 
> 
> _______________________________________________
> 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