Re: [ntp:questions] GPS-PPS, standalone server. NTP

[William Unruh]

On 2017-07-06, Fida Hasan  wrote:
>
>> 
>> You mean that the fluctuation in theoffset if 1.6us. YOu have no way of
>> knowing what the actual offset is, or do you have an independent clock?
>> Ie, ntp could be adding 100ms to the time and you would not know it. 
>> (Not that that would be likely but 2 or 3 usec could be likely)
>> 
>
> Thanks William! You are right. NTP adjustment and mitigation loops play a 
> role in this part.
> I made a straightforward experiment with two Rpi that are sync with two 
> individual GPS with an offset of 1.6 micro (that what NTP shows) each. In P2P 
> mode I connected them through ethernet cable and gave one's address in 
> other's ntp.conf as a server while the node was sync with PPS-GPS in either 
> circumstance. Primarily I found their offset shows 20 microseconds!
> It is interesting because theoretically, we know that gps is highly accurate 
> in ns level. Due to some hardware jitters, there might have some additional 
> offsets but they should not be larger like that.
> I observed some experiments have been conducted in hardware level through a 
> direct connection with signal measurement instruments like the oscilloscope. 
> Those result shows the offsets between two gps receivers are around 100 ns! 
> So, the receiver I am using right now, I compared them using oscilloscope and 
> found similar offsets (100 ns). But they are as high as 20 micro in my RPi.


The gps delivers a pps pulse to its output with an delay of something
like 10-100 ns. Then the gps raises the PPS line, which is almost
certainly not terminated properly so the pulse has an indetermnate rise
time. Then the gpio triggers an interrupt at some point on that rise and
it takes a while for the computer to page out what it is now doing and
start he interrupt service routine. It then has to read out the time
from the kernel. All of that takes time, time which is not accounted
for. Basically the system says that the pps pulse occured when the clock
is read out, which is of the order of a microsecond after the gps
delivered the pps pulse to its output. To really get say 100ns
precision, you need to compensate for all of those delays. They all have
jitter as well (jitter which only increases the time delay, not
decreases it-- eg the interrupts happen to be masked when the pulse
actually comes in, the computer is busy in an non-interrruptable
routine, etc.  Ie to get into the ns regime you have to work hard on all
those delays, and you will not get it from a RPi.
Note that timing gps receivers will have a compensation for internal
delays ( which apparently tend to look like staircases) which it can
tell the computer about well after they have occured. So you can
compensate for them after the fact.
(PS it would be nice if youput line breaks ito your posts).
>
> So, along with NTP some other jitters are there. Now, my question, wheather 
> it is possible to command NTP to stop adjustment only say to fix the GPS PPS 
> with the system clock. If it is possible then I can understand how accurately 
> Rpi can produce GPS PPS signal!
>
>
>> 
>> The shm drive is one way. Another is the pps driver
>> 
>> Make sure that you have the 
>> timepps.h header file somewhere. You have to find it somewhere .
>> If you have it, and you make chrony, it woill be built witht eh PPS API
>> driver.
>> Then before starting chrony and assuming you have the pps fed into the
>> the serial port /dev/ttyS0, do
>> modprobe pps-ldisc
>> ldattach 18 /dev/ttyS0
>> 
>> Then in chrony.conf put
>> refclock PPS /dev/pps0
>> 
>> and you should be set up.
>
> I followed your guide and tried with Chrony. Very unfortunately I can not 
> develop Chrony in my system.
> Problems are:
>
> 1 If I install Chrony from repository (apt-get install chrony), I cant 
> interface it with PPS API, and I even don't find 'chronyd' daemon in my 
> system.
>
> 2. While trying to install manually 
> (https://chrony.tuxfamily.org/doc/3.1/installation.html), it gives make error!
>
> Completely stuck! 
>
>

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] GPS-PPS, standalone server. NTP

[William Unruh]

On 2017-06-21, Fida Hasan  wrote:
> On Thursday, June 15, 2017 at 2:58:07 AM UTC+10, Hans Mayer wrote:
>> Hi Fida, 
>> 
>> > However, did you ever tried to achieve 1-microsecond accuracy in your used 
>> > refid (in your case with driver 28 which NTP uses)? My primary goal is to 
>> > attain 1-microsecond accuracy bond where I can see 3 milliseconds offset 
>> > with .GPS refid.
>> 
>> Definitely not. 
>> With driver 22  I am in the +- 10 usec range. With driver 28 in millisecond 
>> range. 
>> 
>> See my blog.
>> http://blog.mayer.tv/2017/06/14/ntp-driver-22-versus-28.html
>> 
>> I assume driver 20 is very similar to 28. Both are reading serial data. 
>> 
>> I don't know if 1-microsecond is a easy goal. I am using a very cheap 
>> hardware. It's running on a BananaPI. All together about 150 EUR. With a 
>> good hardware it's maybe possible. 
>> 
>> But why do you need this ? Is it just your ambition. This I could 
>> understand. 
>> 
>> 
>> // Hans
>
> Hi Hans,
>
> I have made a stand-alone server using the only driver 20, means no other 
> servers were associated, no internet connection at all. 
> In user mode, I recorded the maximum offset as 6 microseconds. But in kernel 
> mode, the result is much better. I run the system over three days, and the 
> maximum offset comes 1.60 microseconds. From the statistical recorded data, I 
> found the average is 1.03 microseconds.
>

You mean that the fluctuation in theoffset if 1.6us. YOu have no way of
knowing what the actual offset is, or do you have an independent clock?
Ie, ntp could be adding 100ms to the time and you would not know it. 
(Not that that would be likely but 2 or 3 usec could be likely)


> Regards,
> Fida
>

> N.B. I am trying to use chrony as I found some references in favor of it. But 
> still unable to feed the GPS in it.

The shm drive is one way. Another is the pps driver

Make sure that you have the 
timepps.h header file somewhere. You have to find it somewhere .
If you have it, and you make chrony, it woill be built witht eh PPS API
driver.
Then before starting chrony and assuming you have the pps fed into the
the serial port /dev/ttyS0, do
modprobe pps-ldisc
ldattach 18 /dev/ttyS0

Then in chrony.conf put
refclock PPS /dev/pps0

and you should be set up. 


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] GPS-PPS, standalone server. NTP

[Miroslav Lichvar]

On Tue, Jun 20, 2017 at 06:13:14AM -0700, Fida Hasan wrote:
> From this point onward, if I set up ntp, it get fix with the drivers and 
> working fine. However, according to the instruction here:
> http://catb.org/gpsd/gpsd-time-service-howto.html#_feeding_chrony_from_gpsd
> 
> 3. I installed chrony and gpsd into my system. And always ensured that Chrony 
> is Running before gpsd.
> 
> 
> allow 0/0
> 
> refclock SHM 1 refid GPS precision 1e-1 offset 0. delay 0.2
> refclock SOCK /tmp/chrony.ttyS0.sock refid PPSS
> 
> But I don't get any result. It is sure that chrony does not get feed from 
> GPSD. 

With the pps-gpio module gpsd doesn't know that /dev/pps0 is related
to /dev/ttyS0. You might need to start gpsd with both devices
specified on the command line. I'm not sure since what version that is
supported.

If that doesn't work and chrony was compiled with PPS support, you
could use gpsd just for the message-based samples provided in SHM 0
and use the PPS device directly. For example:

refclock PPS /dev/pps0 poll 2 lock NMEA refid GPS
refclock SHM 0 offset 0.5 delay 0.2 refid NMEA noselect

-- 
Miroslav Lichvar
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] GPS-PPS, standalone server. NTP

[girino66]

Le mardi 20 juin 2017 15:13:16 UTC+2, Fida Hasan a écrit :
> > That command gives all details:
> > ntpq -c rv -c pe -c cv -c kern -c as
> > 
> > associd=0 status=041d leap_none, sync_uhf_radio, 1 event, kern,
> > version="ntpd 4.2.8p10@1.3728 Tue May 16 04:35:53 UTC 2017 (1)",
> > processor="armv7l", system="Linux/3.10.104-KPPS", leap=00, stratum=1,
> > precision=-24, rootdelay=0.000, rootdisp=1.195, refid=GPS,
> > reftime=dceaa6d4.0b6f4fcb  Tue, Jun 13 2017 20:00:52.044,
> > clock=dceaa6e1.471ffbf5  Tue, Jun 13 2017 20:01:05.277, peer=46420, tc=5,
> > mintc=3, offset=-0.94, frequency=2.094, sys_jitter=0.60,
> > clk_jitter=0.001, clk_wander=0.002
> >  remote   refid  st t when poll reach   delay   offset  
> > jitter
> > ==
> > +192.168.0.111   .GPS.1 s   21   32  3770.630   -0.008   
> > 0.009
> > +192.168.0.112   .GPS.1 s5   32  3770.4490.058   
> > 0.011
> >  192.168.0.115   192.168.0.1072 s   24   32  3770.6400.006   
> > 0.024
> > oGPS_NMEA(0) .GPS.0 l   13   32  3770.0000.000   
> > 0.000
> > associd=0 status= no events, clk_unspec,
> > device="NMEA GPS Clock",
> > timecode="$GPRMC,180104,A,.,_,_.,_,000.0,224.0,130617,001.8,E*__",
> > poll=21509, noreply=0, badformat=0, baddata=0, fudgetime2=550.000,
> > stratum=0, refid=GPS, flags=13
> > associd=0 status=041d leap_none, sync_uhf_radio, 1 event, kern,
> > pll offset:0
> > pll frequency: 2.09364
> > maximum error: 0.0075
> > estimated error:   0
> > kernel status: pll ppsfreq ppstime ppssignal nano
> > pll time constant: 5
> > precision: 1e-06
> > frequency tolerance:   500
> > pps frequency: 2.09375
> > pps stability: 0.00802612
> > pps jitter:0.001
> > calibration interval   256
> > calibration cycles:12684
> > jitter exceeded:   26092
> > stability exceeded:0
> > calibration errors:0
> > 
> > ind assid status  conf reach auth condition  last_event cnt
> > ===
> >   1 46417  f4fd   yes   yes   ok  candidate 15
> >   2 46418  f43d   yes   yes   ok  candidate  3
> >   3 46419  f01d   yes   yes   ok reject  1
> >   4 46420  971a   yes   yes  none  pps.peersys_peer  1
> > 
> > As you can see the result is quite good and stable
> > Best,
> > Jean-Michel.
> 
> 
> 
> 
> Hi Jean-Michel,
> Splendid work. I was just taking sometimes to complete my experiment with my 
> existing system (Rpi-3, GPS HAT (Uputronics)).
> 
> You know, my result is not bad if I run the system in kernel mode.
> I have used driver 20 and in the stand-alone mood, means no other servers 
> were associated, no internet connection at all.
> In user mode I recorded the maximum offset as 6 microseconds. But in kernel 
> mode I run the system over three days, and the maximum offset comes 1.60 
> microseconds. From the statistical recorded data, I found the average is 1.03 
> microseconds. 
> 
> I am very interested in going further. I have in mind to try your suggested 
> system with Odroid. You have tested with OdroidC1+, where OdroidC2 is the 
> latest version of it. So, can you please share some points to clear my 
> understanding because I literally have no experiences working with this 
> particular SBC system.
> 1. Do I need to use OdriodC1+, or OdriodC2+ would be okay?(as I found Rpi3 
> and others have differences so all of their setting does not mutually works 
> therefore troubleshooting is difficult.)
> 2. Did you use Linux/or Android as OS?
> 3. I believe this Odroid is likea clone of Rpi, means, their GPIO Pin 
> configuration is same. So, the Rpi HAT like uputronics provides should fit 
> with it?
> 
> 
> You are very resourceful. Thank you very much for all of your valuable 
> sharing. This time, I am trying to build with chrony. I have got some 
> references that chrony does better in regard to offsets. I was just wondering 
> if you have any experiences working with chrony!
> 
> While trying with chrony I still unable to fix gpsd with it therefore no GPS 
> and PPS output is observed.
> So,
> 
> 1. I made the necessary configurations:
>a) In the boot configuration file (/boot/conf.txt) I stop Linux putting 
> serial console by removing 'console=serial0,115200' 
>b) I load pps-gpio to kernel module (sudo sh -c "echo pps-gpio >> 
> /etc/modules"
>c) Told to use GPIO18 as the PPS input by inputting 
> "dtoverlay=pps-gpio,gpiopin=18" into config.txt file.
>d) I added this three additional command to the config.txt file, 
> "core_frequency=300" "force_turbo=1" and "enable_uart=1".
>  2. I installed 'picocom' and 'pps-tools' to see whether my GPS and PPS are 
> from the receiver is functioning?
> a) 'picocom -b 9600 -f n /dev/ttyS0' commands start to show output from 
> 

Re: [ntp:questions] GPS-PPS, standalone server. NTP

[Fida Hasan]

On Wednesday, June 14, 2017 at 5:37:04 AM UTC+10, David Lord wrote:
> Fida Hasan wrote:
> > On Thursday, June 8, 2017 at 6:37:04 AM UTC+10, David Lord wrote:
> >> :
> >>> Le mardi 6 juin 2017 15:28:27 UTC+2, David Taylor a écrit :
>  On 06/06/2017 13:11,  wrote:
>  []
> > Some GPS will continue to deliver a PPS signal even if the lock is 
> > lost. I'm thinking particularly about the Garmin 18xLVC where it is 
> > clearly indicated in the documentation (4.4.1): 'After the initial 
> > position fix has been calculated, the PPS signal is generated and 
> > continues until the unit is powered down.'
> >
> > With the use of that 'kind of' GPS, ntpd will continue to provide time 
> > service.
>  As I understand it, NTP will only continue to provide a service if it 
>  has other "time-of-day" sources available.  Should the NMEA output (as 
>  the only time-of-day source) become invalid, NTP would reject it, and 
>  gradually ramp itself up to stratum-16 so as to become invalid as a 
>  server to its clients.
> 
>  [1 - I'm unsure off the top of my head what NTP checks to know whether 
>  NMEA is valid or not.
>  2 - I wonder what the drift in the GPS 18x LVC is when unlocked?]
> 
>  -- 
>  Cheers,
>  David
>  Web: http://www.satsignal.eu
> >>> At least on my 'Garmin', when a fix is not valid the position is not 
> >>> given but the time message remain available. The GPS internal clock 
> >>> continue to work.
> >>>
> >>> One question is to know how stable and precise can be the internal clock 
> >>> of a 18xLVC GPS model? I don't have yet the answer but if it's comparable 
> >>> with the one in a Raspberry or Odroid chip then I'm an happy man for some 
> >>> hours:)
> >> Hi
> >>
> >> NMEA from my 18xLVC was +/- 300ms so I used fudge stratum so that
> >> it didn't affect time accuracy if PPS wasn't available. Sometimes
> >> there was an inversion layer preventing good GPS reception. The
> >> LVC was swapped out to be replaced by a SURE which was still
> >> reliable when the PC went down in March this year an has not yet
> >> been replaced.
> >>
> >> from my ntp.conf:
> >> server 127.127.20.2 mode 18 prefer
> >> fudge 127.127.20.2 stratum 7 time2 0.407 flag1 0 refid GPSb
> >> server 127.127.22.2 minpoll 4 maxpoll 4
> >> fudge 127.127.22.2 flag2 0 flag3 1 refid PPSb
> >>
> >>
> >> David
> > 
> > Hi David,
> > I was just wondering to know the accuracy you have achieved through driver 
> > 20? Did it turned down to 1-miro or around it?
> > 
> > Regards,
> > Fida
> 
> Hi
> 
> with the two gps I've tried, driver 20 is only accurate
> enough for numbering the second, say +/- 400ms for my LVC
> and maybe +/- 100ms for the Sure.
> 
> Combined with driver 22 I had accuracy down to few us,
> mostly better than 1us.
> 
> If you have other internet sources use of driver 20 isn't
> essential.
> 
> 
> David

Hi David,
Combined with 22, in 20 I have also got 1 micro offset (maximum 1.60 micro) in 
kernel mode. But in user mode it is more than 5 micro or above.
Cheers!

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] GPS-PPS, standalone server. NTP

[Fida Hasan]

 
> That command gives all details:
> ntpq -c rv -c pe -c cv -c kern -c as
> 
> associd=0 status=041d leap_none, sync_uhf_radio, 1 event, kern,
> version="ntpd 4.2.8p10@1.3728 Tue May 16 04:35:53 UTC 2017 (1)",
> processor="armv7l", system="Linux/3.10.104-KPPS", leap=00, stratum=1,
> precision=-24, rootdelay=0.000, rootdisp=1.195, refid=GPS,
> reftime=dceaa6d4.0b6f4fcb  Tue, Jun 13 2017 20:00:52.044,
> clock=dceaa6e1.471ffbf5  Tue, Jun 13 2017 20:01:05.277, peer=46420, tc=5,
> mintc=3, offset=-0.94, frequency=2.094, sys_jitter=0.60,
> clk_jitter=0.001, clk_wander=0.002
>  remote   refid  st t when poll reach   delay   offset  jitter
> ==
> +192.168.0.111   .GPS.1 s   21   32  3770.630   -0.008   0.009
> +192.168.0.112   .GPS.1 s5   32  3770.4490.058   0.011
>  192.168.0.115   192.168.0.1072 s   24   32  3770.6400.006   0.024
> oGPS_NMEA(0) .GPS.0 l   13   32  3770.0000.000   0.000
> associd=0 status= no events, clk_unspec,
> device="NMEA GPS Clock",
> timecode="$GPRMC,180104,A,.,_,_.,_,000.0,224.0,130617,001.8,E*__",
> poll=21509, noreply=0, badformat=0, baddata=0, fudgetime2=550.000,
> stratum=0, refid=GPS, flags=13
> associd=0 status=041d leap_none, sync_uhf_radio, 1 event, kern,
> pll offset:0
> pll frequency: 2.09364
> maximum error: 0.0075
> estimated error:   0
> kernel status: pll ppsfreq ppstime ppssignal nano
> pll time constant: 5
> precision: 1e-06
> frequency tolerance:   500
> pps frequency: 2.09375
> pps stability: 0.00802612
> pps jitter:0.001
> calibration interval   256
> calibration cycles:12684
> jitter exceeded:   26092
> stability exceeded:0
> calibration errors:0
> 
> ind assid status  conf reach auth condition  last_event cnt
> ===
>   1 46417  f4fd   yes   yes   ok  candidate 15
>   2 46418  f43d   yes   yes   ok  candidate  3
>   3 46419  f01d   yes   yes   ok reject  1
>   4 46420  971a   yes   yes  none  pps.peersys_peer  1
> 
> As you can see the result is quite good and stable
> Best,
> Jean-Michel.




Hi Jean-Michel,
Splendid work. I was just taking sometimes to complete my experiment with my 
existing system (Rpi-3, GPS HAT (Uputronics)).

You know, my result is not bad if I run the system in kernel mode.
I have used driver 20 and in the stand-alone mood, means no other servers were 
associated, no internet connection at all.
In user mode I recorded the maximum offset as 6 microseconds. But in kernel 
mode I run the system over three days, and the maximum offset comes 1.60 
microseconds. From the statistical recorded data, I found the average is 1.03 
microseconds. 

I am very interested in going further. I have in mind to try your suggested 
system with Odroid. You have tested with OdroidC1+, where OdroidC2 is the 
latest version of it. So, can you please share some points to clear my 
understanding because I literally have no experiences working with this 
particular SBC system.
1. Do I need to use OdriodC1+, or OdriodC2+ would be okay?(as I found Rpi3 and 
others have differences so all of their setting does not mutually works 
therefore troubleshooting is difficult.)
2. Did you use Linux/or Android as OS?
3. I believe this Odroid is likea clone of Rpi, means, their GPIO Pin 
configuration is same. So, the Rpi HAT like uputronics provides should fit with 
it?


You are very resourceful. Thank you very much for all of your valuable sharing. 
This time, I am trying to build with chrony. I have got some references that 
chrony does better in regard to offsets. I was just wondering if you have any 
experiences working with chrony!

While trying with chrony I still unable to fix gpsd with it therefore no GPS 
and PPS output is observed.
So,

1. I made the necessary configurations:
   a) In the boot configuration file (/boot/conf.txt) I stop Linux putting 
serial console by removing 'console=serial0,115200' 
   b) I load pps-gpio to kernel module (sudo sh -c "echo pps-gpio >> 
/etc/modules"
   c) Told to use GPIO18 as the PPS input by inputting 
"dtoverlay=pps-gpio,gpiopin=18" into config.txt file.
   d) I added this three additional command to the config.txt file, 
"core_frequency=300" "force_turbo=1" and "enable_uart=1".
 2. I installed 'picocom' and 'pps-tools' to see whether my GPS and PPS are 
from the receiver is functioning?
a) 'picocom -b 9600 -f n /dev/ttyS0' commands start to show output from GPS 
module that essentially starts with $GPRMC
b) 'ppstest /dev/pps0' command also executes successfully showing, 'ok 
found 1 sources (s) bla bla
-means, both GPS and PPS of the receiver are interfaced and active 
with the system.

>From this point onward, if I set up 

Re: [ntp:questions] GPS-PPS, standalone server. NTP

[girino66]

Le mercredi 14 juin 2017 18:58:07 UTC+2, Hans Mayer a écrit :
> Hi Fida, 
> 
> > However, did you ever tried to achieve 1-microsecond accuracy in your used 
> > refid (in your case with driver 28 which NTP uses)? My primary goal is to 
> > attain 1-microsecond accuracy bond where I can see 3 milliseconds offset 
> > with .GPS refid.
> 
> Definitely not. 
> With driver 22  I am in the +- 10 usec range. With driver 28 in millisecond 
> range. 
> 
> See my blog.
> http://blog.mayer.tv/2017/06/14/ntp-driver-22-versus-28.html
> 
> I assume driver 20 is very similar to 28. Both are reading serial data. 
> 
> I don't know if 1-microsecond is a easy goal. I am using a very cheap 
> hardware. It's running on a BananaPI. All together about 150 EUR. With a good 
> hardware it's maybe possible. 
> 
> But why do you need this ? Is it just your ambition. This I could understand. 
> 
> 
> // Hans

Hi Hans,

Driver 20 is very different from driver 28.

Driver 28 receives data from a shared memory space shared with another process. 
It does nothing else. The structure of the memory segment is described in the 
NTP documentation: 
https://www.eecis.udel.edu/~mills/ntp/html/drivers/driver28.html
Data can comes from any kind of program that is able to fill the structure 
shared in memory. It is common to see driver 28 in association with GPSD 
program because driver 28 is enabled by default in usual distributions like 
'Raspbian'.

Driver 20 receives data from a serial port and is able to decode some NMEA 
sequences. That driver is also able to manage directly a PPS signal as driver 
22 do and because of that it is also able to be as precise as driver 20 is.
https://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html
Unfortunately its use is possible after a recompilation of ntpd with correct 
options to enable it. It fully works only on Unix like systems, the 'Windows' 
implementation is not complete.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] GPS-PPS, standalone server. NTP

[Hans Mayer]

Hi Fida, 

> However, did you ever tried to achieve 1-microsecond accuracy in your used 
> refid (in your case with driver 28 which NTP uses)? My primary goal is to 
> attain 1-microsecond accuracy bond where I can see 3 milliseconds offset with 
> .GPS refid.

Definitely not. 
With driver 22  I am in the +- 10 usec range. With driver 28 in millisecond 
range. 

See my blog.
http://blog.mayer.tv/2017/06/14/ntp-driver-22-versus-28.html

I assume driver 20 is very similar to 28. Both are reading serial data. 

I don't know if 1-microsecond is a easy goal. I am using a very cheap hardware. 
It's running on a BananaPI. All together about 150 EUR. With a good hardware 
it's maybe possible. 

But why do you need this ? Is it just your ambition. This I could understand. 


// Hans


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] GPS-PPS, standalone server. NTP

[girino66]

Le mardi 13 juin 2017 21:37:04 UTC+2, David Lord a écrit :
> Fida Hasan wrote:
> > On Thursday, June 8, 2017 at 6:37:04 AM UTC+10, David Lord wrote:
> >> :
> >>> Le mardi 6 juin 2017 15:28:27 UTC+2, David Taylor a écrit :
>  On 06/06/2017 13:11,  wrote:
>  []
> > Some GPS will continue to deliver a PPS signal even if the lock is 
> > lost. I'm thinking particularly about the Garmin 18xLVC where it is 
> > clearly indicated in the documentation (4.4.1): 'After the initial 
> > position fix has been calculated, the PPS signal is generated and 
> > continues until the unit is powered down.'
> >
> > With the use of that 'kind of' GPS, ntpd will continue to provide time 
> > service.
>  As I understand it, NTP will only continue to provide a service if it 
>  has other "time-of-day" sources available.  Should the NMEA output (as 
>  the only time-of-day source) become invalid, NTP would reject it, and 
>  gradually ramp itself up to stratum-16 so as to become invalid as a 
>  server to its clients.
> 
>  [1 - I'm unsure off the top of my head what NTP checks to know whether 
>  NMEA is valid or not.
>  2 - I wonder what the drift in the GPS 18x LVC is when unlocked?]
> 
>  -- 
>  Cheers,
>  David
>  Web: http://www.satsignal.eu
> >>> At least on my 'Garmin', when a fix is not valid the position is not 
> >>> given but the time message remain available. The GPS internal clock 
> >>> continue to work.
> >>>
> >>> One question is to know how stable and precise can be the internal clock 
> >>> of a 18xLVC GPS model? I don't have yet the answer but if it's comparable 
> >>> with the one in a Raspberry or Odroid chip then I'm an happy man for some 
> >>> hours:)
> >> Hi
> >>
> >> NMEA from my 18xLVC was +/- 300ms so I used fudge stratum so that
> >> it didn't affect time accuracy if PPS wasn't available. Sometimes
> >> there was an inversion layer preventing good GPS reception. The
> >> LVC was swapped out to be replaced by a SURE which was still
> >> reliable when the PC went down in March this year an has not yet
> >> been replaced.
> >>
> >> from my ntp.conf:
> >> server 127.127.20.2 mode 18 prefer
> >> fudge 127.127.20.2 stratum 7 time2 0.407 flag1 0 refid GPSb
> >> server 127.127.22.2 minpoll 4 maxpoll 4
> >> fudge 127.127.22.2 flag2 0 flag3 1 refid PPSb
> >>
> >>
> >> David
> > 
> > Hi David,
> > I was just wondering to know the accuracy you have achieved through driver 
> > 20? Did it turned down to 1-miro or around it?
> > 
> > Regards,
> > Fida
> 
> Hi
> 
> with the two gps I've tried, driver 20 is only accurate
> enough for numbering the second, say +/- 400ms for my LVC
> and maybe +/- 100ms for the Sure.
> 
> Combined with driver 22 I had accuracy down to few us,
> mostly better than 1us.
> 
> If you have other internet sources use of driver 20 isn't
> essential.
> 
> 
> David

Hi David,

I clearly don't agree with what you said about driver 20.

Driver 20 with flags 1 and eventually 3 enabled can be as accurate as driver 22 
is. The reason is simple; it's because driver 20 is a merge between NMEA 
messages and the PPS API.

It is also clearly indicated in the documentation and it works, at least under 
linux.

Jean-Michel.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] GPS-PPS, standalone server. NTP

[David Lord]

Fida Hasan wrote:

On Thursday, June 8, 2017 at 6:37:04 AM UTC+10, David Lord wrote:

:

Le mardi 6 juin 2017 15:28:27 UTC+2, David Taylor a écrit :

On 06/06/2017 13:11,  wrote:
[]

Some GPS will continue to deliver a PPS signal even if the lock is lost. I'm 
thinking particularly about the Garmin 18xLVC where it is clearly indicated in 
the documentation (4.4.1): 'After the initial position fix has been calculated, 
the PPS signal is generated and continues until the unit is powered down.'

With the use of that 'kind of' GPS, ntpd will continue to provide time service.
As I understand it, NTP will only continue to provide a service if it 
has other "time-of-day" sources available.  Should the NMEA output (as 
the only time-of-day source) become invalid, NTP would reject it, and 
gradually ramp itself up to stratum-16 so as to become invalid as a 
server to its clients.


[1 - I'm unsure off the top of my head what NTP checks to know whether 
NMEA is valid or not.

2 - I wonder what the drift in the GPS 18x LVC is when unlocked?]

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

At least on my 'Garmin', when a fix is not valid the position is not given but 
the time message remain available. The GPS internal clock continue to work.

One question is to know how stable and precise can be the internal clock of a 
18xLVC GPS model? I don't have yet the answer but if it's comparable with the 
one in a Raspberry or Odroid chip then I'm an happy man for some hours:)

Hi

NMEA from my 18xLVC was +/- 300ms so I used fudge stratum so that
it didn't affect time accuracy if PPS wasn't available. Sometimes
there was an inversion layer preventing good GPS reception. The
LVC was swapped out to be replaced by a SURE which was still
reliable when the PC went down in March this year an has not yet
been replaced.

from my ntp.conf:
server 127.127.20.2 mode 18 prefer
fudge 127.127.20.2 stratum 7 time2 0.407 flag1 0 refid GPSb
server 127.127.22.2 minpoll 4 maxpoll 4
fudge 127.127.22.2 flag2 0 flag3 1 refid PPSb


David


Hi David,
I was just wondering to know the accuracy you have achieved through driver 20? 
Did it turned down to 1-miro or around it?

Regards,
Fida


Hi

with the two gps I've tried, driver 20 is only accurate
enough for numbering the second, say +/- 400ms for my LVC
and maybe +/- 100ms for the Sure.

Combined with driver 22 I had accuracy down to few us,
mostly better than 1us.

If you have other internet sources use of driver 20 isn't
essential.


David





___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] GPS-PPS, standalone server. NTP

[girino66]

Le mardi 13 juin 2017 13:54:25 UTC+2, Fida Hasan a écrit :
> > Hi, 
> > 
> > My 18x is linked with an Odroid C1+ and I use only driver 20 with 0x1 
> > mode enabled to have a better look on NMEA sentences. It's by looking 'ntpq 
> > -c clockvar' results that I discovered the quality of my 18x comparing with 
> > some others 'Adafruit' or basic GPS chips.
> > 
> > from my ntp.conf:
> > server 127.127.20.0 mode 65553 minpoll 5 maxpoll 5 
> > fudge 127.127.20.0 time2 0.550 flag1 1 flag3 1 flag4 1  
> > 
> > Knowing that by default flags are set to 0 I don't explicitly feel the need 
> > to reset them again to 0. 
> > Having only one physical device (GPS) connected I also don't feel the need 
> > to rename the driver with 'refid' option. 
> > 
> > Jean-Michel
> 
> 
> Hi Jean-Michel,
> You came up with so many good information. Thank you so much. Regarding this 
> specific point you did not say how accuracy you got through the driver 20 
> (both with/without internet)?
> In my understanding, Driver 20 gives NMEA sentences and its accuracy suppose 
> to fluctuates in millisecond range! 
> 
> I am very keen to get a stable clock with 1 micro accuracy. Aiming this I 
> have tested many settings.
> According to my achievement, I have got:
> 1. 1 micro accuracy in driver 22! 
> 2. then I compiled the kernel and get nano second level accuracy in driver 
> 22! Though it fluctuates in microsecond range as well, not stable but average 
> I was able to develop around 800ns there.
> 
> But in driver 22, it is just merely a precise tick without time, my system 
> always follows driver 20 (showed asterisk on it *). But still I can't develop 
> microsecond accuracy on it. 
> 
> My question, if I can't develop microsecond accuracy on the usable reference 
> ID, then what's the point of saying GPS is as accurate as microsecond?
> 
> However, I have got a link here,
> https://www.lammertbies.nl/comm/info/GPS-time.html
> According to this site, it uses shared driver 28 (127.127.28.1) to develop 
> achievable accuracy in microsecond range (follow the asterisk).
> 
>   remote   refid  st t when poll reach   delay   offset  jitter
> ==
> +SHM(0)  .GPS.0 l6   16  3770.000   28.775  10.971
> *SHM(1)  .PPS.0 l5   16  3770.000   -0.001   0.002
> 
> 
> However, I haven't able to develop it yet, for some reasons it is not working 
> with my Rpi system! 
> 
> Will appreciate your further comment at this stage.
> Kind Regards,
> Fida

Hi Fida,

There are several possibilities to configure NTP to let it talk to NMEA GPS 
with PPS signal like the Garmin 18x.

Lot of internet examples are using GPSD and SHM drivers to communicate with 
ntpd; it is the easiest way because unfortunately ntpd is not compiled in 
standard with all 'interesting' features... In particular the driver 20 doesn't 
work in standard and a local compilation with '--enable-linuxcaps' option is 
required to fully activate all ntpd features.

As many of us I try to increase at it's best ntpd capabilities and the computer 
hardware used has also a role to play, this is why I switched from Rpi to 
Odroid computers in order to benefit a true Ethernet link. The gain is quite 
important for clients.

As the PPS signal involves directly the hardware I decided to let the kernel 
directly manage the PPS irq. Cannot be better in term of latency.
That last decision requires also a kernel compilation to enable several options 
liked with PPS support and to disable some other options that controls the CPU 
frequency.

At the end I use a small pool of stratum 1 peers composed by some RPIs and one 
OdroidC1+. Only the Odroid uses the Garmin, all peers uses driver 20.

That command gives all details:
ntpq -c rv -c pe -c cv -c kern -c as

associd=0 status=041d leap_none, sync_uhf_radio, 1 event, kern,
version="ntpd 4.2.8p10@1.3728 Tue May 16 04:35:53 UTC 2017 (1)",
processor="armv7l", system="Linux/3.10.104-KPPS", leap=00, stratum=1,
precision=-24, rootdelay=0.000, rootdisp=1.195, refid=GPS,
reftime=dceaa6d4.0b6f4fcb  Tue, Jun 13 2017 20:00:52.044,
clock=dceaa6e1.471ffbf5  Tue, Jun 13 2017 20:01:05.277, peer=46420, tc=5,
mintc=3, offset=-0.94, frequency=2.094, sys_jitter=0.60,
clk_jitter=0.001, clk_wander=0.002
 remote   refid  st t when poll reach   delay   offset  jitter
==
+192.168.0.111   .GPS.1 s   21   32  3770.630   -0.008   0.009
+192.168.0.112   .GPS.1 s5   32  3770.4490.058   0.011
 192.168.0.115   192.168.0.1072 s   24   32  3770.6400.006   0.024
oGPS_NMEA(0) .GPS.0 l   13   32  3770.0000.000   0.000
associd=0 status= no events, clk_unspec,
device="NMEA GPS Clock",
timecode="$GPRMC,180104,A,.,_,_.,_,000.0,224.0,130617,001.8,E*__",

Re: [ntp:questions] GPS-PPS, standalone server. NTP

[Fida Hasan]

On Thursday, June 8, 2017 at 6:37:04 AM UTC+10, David Lord wrote:
> :
> > Le mardi 6 juin 2017 15:28:27 UTC+2, David Taylor a écrit :
> >> On 06/06/2017 13:11,  wrote:
> >> []
> >>> Some GPS will continue to deliver a PPS signal even if the lock is lost. 
> >>> I'm thinking particularly about the Garmin 18xLVC where it is clearly 
> >>> indicated in the documentation (4.4.1): 'After the initial position fix 
> >>> has been calculated, the PPS signal is generated and continues until the 
> >>> unit is powered down.'
> >>>
> >>> With the use of that 'kind of' GPS, ntpd will continue to provide time 
> >>> service.
> >> As I understand it, NTP will only continue to provide a service if it 
> >> has other "time-of-day" sources available.  Should the NMEA output (as 
> >> the only time-of-day source) become invalid, NTP would reject it, and 
> >> gradually ramp itself up to stratum-16 so as to become invalid as a 
> >> server to its clients.
> >>
> >> [1 - I'm unsure off the top of my head what NTP checks to know whether 
> >> NMEA is valid or not.
> >> 2 - I wonder what the drift in the GPS 18x LVC is when unlocked?]
> >>
> >> -- 
> >> Cheers,
> >> David
> >> Web: http://www.satsignal.eu
> > 
> > At least on my 'Garmin', when a fix is not valid the position is not given 
> > but the time message remain available. The GPS internal clock continue to 
> > work.
> > 
> > One question is to know how stable and precise can be the internal clock of 
> > a 18xLVC GPS model? I don't have yet the answer but if it's comparable with 
> > the one in a Raspberry or Odroid chip then I'm an happy man for some hours:)
> 
> Hi
> 
> NMEA from my 18xLVC was +/- 300ms so I used fudge stratum so that
> it didn't affect time accuracy if PPS wasn't available. Sometimes
> there was an inversion layer preventing good GPS reception. The
> LVC was swapped out to be replaced by a SURE which was still
> reliable when the PC went down in March this year an has not yet
> been replaced.
> 
> from my ntp.conf:
> server 127.127.20.2 mode 18 prefer
> fudge 127.127.20.2 stratum 7 time2 0.407 flag1 0 refid GPSb
> server 127.127.22.2 minpoll 4 maxpoll 4
> fudge 127.127.22.2 flag2 0 flag3 1 refid PPSb
> 
> 
> David

Hi David,
I was just wondering to know the accuracy you have achieved through driver 20? 
Did it turned down to 1-miro or around it?

Regards,
Fida

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] GPS-PPS, standalone server. NTP

[Fida Hasan]

On Monday, June 5, 2017 at 3:00:08 AM UTC+10, Hans Mayer wrote:
> > How can I increase the frequency of logging the states? For example, can I 
> > log regularly in every seconds?
> 
> 
> Only for the clockstats. And only for the PPS driver. 
> You have to set flag4 to value 1 
> see my previos posting 
> 
> About the output of "ntpq -pn"
> If it looks like this everything is fine. 
> 
>  remote   refid  st t when poll reach   delay   offset  jitter
> ==
> o127.127.22.0.PPS.0 l   17   32  3770.0000.008   0.009
> *127.127.28.0.GPS.0 l   19   32  3770.000   -3.174   1.947
> 
> In your case it's driver 20 instead of 28
> 
> 
> // Hans

Hi Hans,
Thank you for your great contribution. Appreciate that much.
However, did you ever tried to achieve 1-microsecond accuracy in your used 
refid (in your case with driver 28 which NTP uses)? My primary goal is to 
attain 1-microsecond accuracy bond where I can see 3 milliseconds offset with 
.GPS refid.

Any idea?

Regards.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] GPS-PPS, standalone server. NTP

[Fida Hasan]

> Hi, 
> 
> My 18x is linked with an Odroid C1+ and I use only driver 20 with 0x1 
> mode enabled to have a better look on NMEA sentences. It's by looking 'ntpq 
> -c clockvar' results that I discovered the quality of my 18x comparing with 
> some others 'Adafruit' or basic GPS chips.
> 
> from my ntp.conf:
> server 127.127.20.0 mode 65553 minpoll 5 maxpoll 5 
> fudge 127.127.20.0 time2 0.550 flag1 1 flag3 1 flag4 1  
> 
> Knowing that by default flags are set to 0 I don't explicitly feel the need 
> to reset them again to 0. 
> Having only one physical device (GPS) connected I also don't feel the need to 
> rename the driver with 'refid' option. 
> 
> Jean-Michel


Hi Jean-Michel,
You came up with so many good information. Thank you so much. Regarding this 
specific point you did not say how accuracy you got through the driver 20 (both 
with/without internet)?
In my understanding, Driver 20 gives NMEA sentences and its accuracy suppose to 
fluctuates in millisecond range! 

I am very keen to get a stable clock with 1 micro accuracy. Aiming this I have 
tested many settings.
According to my achievement, I have got:
1. 1 micro accuracy in driver 22! 
2. then I compiled the kernel and get nano second level accuracy in driver 22! 
Though it fluctuates in microsecond range as well, not stable but average I was 
able to develop around 800ns there.

But in driver 22, it is just merely a precise tick without time, my system 
always follows driver 20 (showed asterisk on it *). But still I can't develop 
microsecond accuracy on it. 

My question, if I can't develop microsecond accuracy on the usable reference 
ID, then what's the point of saying GPS is as accurate as microsecond?

However, I have got a link here,
https://www.lammertbies.nl/comm/info/GPS-time.html
According to this site, it uses shared driver 28 (127.127.28.1) to develop 
achievable accuracy in microsecond range (follow the asterisk).

  remote   refid  st t when poll reach   delay   offset  jitter
==
+SHM(0)  .GPS.0 l6   16  3770.000   28.775  10.971
*SHM(1)  .PPS.0 l5   16  3770.000   -0.001   0.002


However, I haven't able to develop it yet, for some reasons it is not working 
with my Rpi system! 

Will appreciate your further comment at this stage.
Kind Regards,
Fida

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] GPS-PPS, standalone server. NTP

[Hans Mayer]

Therefore it's more important that all clients are connected to stratum-2 
servers, which take the time from different sources. A failure of a single 
stratum-1 isn't important than.

// Hans 


>>On 04/06/2017 18:48, Hans Mayer wrote: 
>> 
>> ... 
>> For a stratum 1 server I wouldn't define any pool server as "sanity". They 
>> will almost never be used. If PPS fails time will be taken from GPS or SHM 
>> driver. Only if this fails too the next will be taken. 
>> 


> Thus such a failure of NMEA+PPS would be more common than a failure of 
> NMEA or PPS alone. 


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] GPS-PPS, standalone server. NTP

[girino66]

Le mercredi 7 juin 2017 22:37:04 UTC+2, David Lord a écrit :
> girin...@gmail.com wrote:
> > Le mardi 6 juin 2017 15:28:27 UTC+2, David Taylor a écrit :
> >> On 06/06/2017 13:11, girin...@gmail.com wrote:
> >> []
> >>> Some GPS will continue to deliver a PPS signal even if the lock is lost. 
> >>> I'm thinking particularly about the Garmin 18xLVC where it is clearly 
> >>> indicated in the documentation (4.4.1): 'After the initial position fix 
> >>> has been calculated, the PPS signal is generated and continues until the 
> >>> unit is powered down.'
> >>>
> >>> With the use of that 'kind of' GPS, ntpd will continue to provide time 
> >>> service.
> >> As I understand it, NTP will only continue to provide a service if it 
> >> has other "time-of-day" sources available.  Should the NMEA output (as 
> >> the only time-of-day source) become invalid, NTP would reject it, and 
> >> gradually ramp itself up to stratum-16 so as to become invalid as a 
> >> server to its clients.
> >>
> >> [1 - I'm unsure off the top of my head what NTP checks to know whether 
> >> NMEA is valid or not.
> >> 2 - I wonder what the drift in the GPS 18x LVC is when unlocked?]
> >>
> >> -- 
> >> Cheers,
> >> David
> >> Web: http://www.satsignal.eu
> > 
> > At least on my 'Garmin', when a fix is not valid the position is not given 
> > but the time message remain available. The GPS internal clock continue to 
> > work.
> > 
> > One question is to know how stable and precise can be the internal clock of 
> > a 18xLVC GPS model? I don't have yet the answer but if it's comparable with 
> > the one in a Raspberry or Odroid chip then I'm an happy man for some hours:)
> 
> Hi
> 
> NMEA from my 18xLVC was +/- 300ms so I used fudge stratum so that
> it didn't affect time accuracy if PPS wasn't available. Sometimes
> there was an inversion layer preventing good GPS reception. The
> LVC was swapped out to be replaced by a SURE which was still
> reliable when the PC went down in March this year an has not yet
> been replaced.
> 
> from my ntp.conf:
> server 127.127.20.2 mode 18 prefer
> fudge 127.127.20.2 stratum 7 time2 0.407 flag1 0 refid GPSb
> server 127.127.22.2 minpoll 4 maxpoll 4
> fudge 127.127.22.2 flag2 0 flag3 1 refid PPSb
> 
> 
> David

Hi, 

My 18x is linked with an Odroid C1+ and I use only driver 20 with 0x1 mode 
enabled to have a better look on NMEA sentences. It's by looking 'ntpq -c 
clockvar' results that I discovered the quality of my 18x comparing with some 
others 'Adafruit' or basic GPS chips.

from my ntp.conf:
server 127.127.20.0 mode 65553 minpoll 5 maxpoll 5 
fudge 127.127.20.0 time2 0.550 flag1 1 flag3 1 flag4 1  

Knowing that by default flags are set to 0 I don't explicitly feel the need to 
reset them again to 0. 
Having only one physical device (GPS) connected I also don't feel the need to 
rename the driver with 'refid' option. 

Jean-Michel

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] GPS-PPS, standalone server. NTP

[David Taylor]

On 06/06/2017 13:11, girin...@gmail.com wrote:
[]

Some GPS will continue to deliver a PPS signal even if the lock is lost. I'm 
thinking particularly about the Garmin 18xLVC where it is clearly indicated in 
the documentation (4.4.1): 'After the initial position fix has been calculated, 
the PPS signal is generated and continues until the unit is powered down.'

With the use of that 'kind of' GPS, ntpd will continue to provide time service.


As I understand it, NTP will only continue to provide a service if it 
has other "time-of-day" sources available.  Should the NMEA output (as 
the only time-of-day source) become invalid, NTP would reject it, and 
gradually ramp itself up to stratum-16 so as to become invalid as a 
server to its clients.


[1 - I'm unsure off the top of my head what NTP checks to know whether 
NMEA is valid or not.

2 - I wonder what the drift in the GPS 18x LVC is when unlocked?]

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

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] GPS-PPS, standalone server. NTP

[David Taylor]

On 05/06/2017 22:53, Jakob Bohm wrote:
[]

Note that any failure in the GPS/GNSS radio hardware that actually
provides both the PPS pulses and the NMEA messages would be a failure of
both "ntpd sources".

Thus such a failure of NMEA+PPS would be more common than a failure of
NMEA or PPS alone.

 Enjoy
Jakob


.. and one failure experienced here was the presence nearby (RF-wise) of 
a GPS jammer.  All GPS receivers lost lock, PPS and NMEA.  Interesting 
to note which continued to provide an /unlocked/ PPS signal!


The PCs continued to sync with the Internet alone.

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

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] GPS-PPS, standalone server. NTP

[Jakob Bohm]

On 04/06/2017 18:48, Hans Mayer wrote:


...
For a stratum 1 server I wouldn't define any pool server as "sanity". They will 
almost never be used. If PPS fails time will be taken from GPS or SHM driver. Only if 
this fails too the next will be taken.



Note that any failure in the GPS/GNSS radio hardware that actually
provides both the PPS pulses and the NMEA messages would be a failure of
both "ntpd sources".

Thus such a failure of NMEA+PPS would be more common than a failure of
NMEA or PPS alone.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions