Hello,

i'm quite new to ntpd / gpsd softwares and have a few questions :

I'm feeding NTPD with ZDA frame from a tcp connection rather than serial
line. Is there a way to have driver 20 working with such setup ? I've
not been able to make it so far.
Driver 28 (SHM) is working good (no /dev/gps0 device)  Would there be
any interest of having driver 20 vs driver 28 ? I guess there could be a
way to make a /dev/gps0 fed from socat or nc or something like that...

As for driver 28, I still I don't understand the difference between mode
0 and mode 1 for it. Could someone give further details ?

When used together with a PPS, does it make a difference to have the ZDA
frame coming with relatively low serial jitter or with (somewhat higher
jitter from the network). My naive understanding is that this should not
make any difference, is that right ?

I found the flag to use rising vs falling edge for PPS detection, is
there a way to deal with sequence order : frame then PPS vs. PPS then
frame that can change from a receiver to another ? Would setting the 22
driver offset to  ~ -1 / ~ 0 / ~ +1 (not sure which to use as writing
this) do the job ?

If I want to compensate for antenna cable delay and PPS line cable delay, which way should the offset be added for each case ?

For a serial or network fed gpsd, what is the best way to calibrate for
the time1 offset value for SHM or generic NMEA drivers ?

Best regards,

Mathieu

On 14/10/2016 18:01, mathieu.peyrega@gmail.com wrote:
>
>
> Hello,
>
> i'm quite new to ntpd / gpsd softwares and have a few questions :
[]
> If I want to compensate for antenna cable delay and PPS line cable delay, which way should the offset be added for each case ?
>
> For a serial or network fed gpsd, what is the best way to calibrate for
> the time1 offset value for SHM or generic NMEA drivers ?
>
> Best regards,
>
> Mathieu

Mathieu,

I can't help much, but I would ask what sort of accuracy you want to 
achieve.  I am thinking that antenna cable and PPS cable delay will be 
negligible in many circumstances.

For the rough offset of the NMEA drivers, simply use either your PPS 
source, or possibly a good Internet source, and see what the offset 
shows in the output from "ntpq -pn".  In my experience, Internet offsets 
can be a few milliseconds, NMEA offsets several hundred milliseconds.

-- 
Cheers,
David
Web: http://www.satsignal.eu

Le vendredi 14 octobre 2016 19:01:48 UTC+2, mathieu...@gmail.com a =C3=A9cr=
it=C2=A0:
> Hello,
>=20
> i'm quite new to ntpd / gpsd softwares and have a few questions :
>=20
> I'm feeding NTPD with ZDA frame from a tcp connection rather than serial
> line. Is there a way to have driver 20 working with such setup ? I've
> not been able to make it so far.
> Driver 28 (SHM) is working good (no /dev/gps0 device)  Would there be
> any interest of having driver 20 vs driver 28 ? I guess there could be a
> way to make a /dev/gps0 fed from socat or nc or something like that...
>=20
> As for driver 28, I still I don't understand the difference between mode
> 0 and mode 1 for it. Could someone give further details ?
>=20
> When used together with a PPS, does it make a difference to have the ZDA
> frame coming with relatively low serial jitter or with (somewhat higher
> jitter from the network). My naive understanding is that this should not
> make any difference, is that right ?
>=20
> I found the flag to use rising vs falling edge for PPS detection, is
> there a way to deal with sequence order : frame then PPS vs. PPS then
> frame that can change from a receiver to another ? Would setting the 22
> driver offset to  ~ -1 / ~ 0 / ~ +1 (not sure which to use as writing
> this) do the job ?
>=20
> If I want to compensate for antenna cable delay and PPS line cable delay,=
 which way should the offset be added for each case ?
>=20
> For a serial or network fed gpsd, what is the best way to calibrate for
> the time1 offset value for SHM or generic NMEA drivers ?
>=20
> Best regards,
>=20
> Mathieu

Hi,
1- If GPSD is used it will catch the NMEA sentence that will not be anymore=
 availlable for driver 20.=20
2- driver 20 can manage directly the GPS (NMEA + PPS); driver 28 needs the =
use of GPSD to manage the GPS (NMEA + PPS).
3- The use of driver 20 requires an NTP recompilation because the standard =
package is not compile with the right options to use it.
4- With my experience, flag of driver 22 to use rising or falling edge does=
n't work. Always use rising edge.
5- The use of the NMEA sentence without the PPS signal will gives poor resu=
lts. The NMEA sentence is used to obtain the right date and an approximativ=
e time. The PPS signal gives the precision.
6- Don't compensate the cable delay, it is the last significant source of d=
elays.
7- To calibrate a time source you need another time source :)
8- The strait way is to use GPDS with NTP. Results wll be good.
9- To have (small) better results you'll need to recompile NTP and your KER=
NEL. Do it for fun.
Best and good luck,
Jean-Michel

On 2016-10-15, girino66@gmail.com <girino66@gmail.com> wrote:
> Le vendredi 14 octobre 2016 19:01:48 UTC+2, mathieu...@gmail.com a ??crit??:
> 6- Don't compensate the cable delay, it is the last significant source of delays.

Light travels at approximately a foot per nanosecond. How many feet away
is your source? Do you really think that anything in your systen is good
to the nanosecond level, or even 100ns level? It almost certainly is
not. The computer takes time to run an interrupt. The reading of the
clock takes a microsecond or so.

> 7- To calibrate a time source you need another time source :)

No, at least two others. One is good enough only if you know it is far
more accurate than that the one you are calibrating.

> 8- The strait way is to use GPDS with NTP. Results wll be good.
> 9- To have (small) better results you'll need to recompile NTP and your KERNEL. Do it for fun.
> Best and good luck,
> Jean-Michel

Thank for your answers (only the mode 0 vs. mode 1 is still missing)

As for the calbe delay question, I'm actually aware athat the cable propaga=
tion delay is usually quite small.
as for my 30 m (98.4 ft) LMR600 cable feeding the GPS side, the delay is : =
115 ns
http://www.timesmicrowave.com/calculator/?productId=3D65&frequency=3D1575&r=
unLength=3D98.42&mode=3Dcalculate#form
There a a few extra ns for the antenna itself and a GPS splitter.
Everything on that side is not close to 1 us.=20

I'd like to bring synchro in a GPS denied environment so the PPS line itsel=
f may be carried over a much longuer line...

Best regards

Mathieu

Le samedi 15 octobre 2016 10:19:13 UTC+2, William Unruh a =C3=A9crit=C2=A0:
> On 2016-10-15, girino66@gmail.com <girino66@gmail.com> wrote:
> > Le vendredi 14 octobre 2016 19:01:48 UTC+2, mathieu...@gmail.com a ??cr=
it??:
> > 6- Don't compensate the cable delay, it is the last significant source =
of delays.
>=20
> Light travels at approximately a foot per nanosecond. How many feet away
> is your source? Do you really think that anything in your systen is good
> to the nanosecond level, or even 100ns level? It almost certainly is
> not. The computer takes time to run an interrupt. The reading of the
> clock takes a microsecond or so.
>=20
> > 7- To calibrate a time source you need another time source :)
>=20
> No, at least two others. One is good enough only if you know it is far
> more accurate than that the one you are calibrating.
>=20
> > 8- The strait way is to use GPDS with NTP. Results wll be good.
> > 9- To have (small) better results you'll need to recompile NTP and your=
 KERNEL. Do it for fun.
> > Best and good luck,
> > Jean-Michel

On 15/10/16 09:18, William Unruh wrote:
> Light travels at approximately a foot per nanosecond. How many feet away
> is your source? Do you really think that anything in your systen is good

Typical cables have velocity factors of about 2/3rds, so it is more like 
8 inches a nano-second, although still the same order of magnitude.