beta-tester
Posts: 1302
Joined: Fri Jan 04, 2013 1:57 pm
Location: de_DE

[FIXED]: RPi as high precise NTP Server with GPS/PPS dev

Thu Mar 17, 2016 5:23 pm

MOVED from Troubleshooting to Advanced user:

hi,
i have a RPi that i want to use as a high precise NTP server (Stratum1) for a local network, where no connection to the external internet is.
that means i have no connection to any external NTP server.

to have my RPi running as an Stratum One server i use a GPS receiver that also provides a PPS (an high precise pulse per second signal).
the GPS does not have a battery to buffer the RTC of the GPS device (so after power off, everything boots from cold start).

i followed the descriptions here (Quick start NTP on the Raspberry Pi) and here (The Raspberry Pi as a Stratum-1 NTP Server).

i connected everything to the RPi correctly (RX, TX, PPS->GPIO 18).

everything seems to work fine as long the RPi is connected to the network with connection to external internet...
but if i use the RPi in a local network without a connection to external internet, then the RPi isn't able to get the correct time, that is should get from the GPS device.
can somebody tell me, there i made a mistake, and what i have to do to get my NTP Server running correctly with using the GPS time and its precise PPS signal in an isolated local network environment?

so i guess the GPS time never was used correctly to get the time.
in principe, the GPS is working, and PPS is working, the kernel is PPS enabled, NTP is PPS enabled, as you can see on the status messages below.

i use the official Raspbian Jessie Lite image (2016-02-26-raspbian-jessie-lite.img)

Code: Select all

[email protected]:~ $ uname -a
Linux myStratum1 4.1.18+ #846 Thu Feb 25 14:11:56 GMT 2016 armv6l GNU/Linux
without internet connection!

Code: Select all

[email protected]:~ $ ntpstat
unsynchronised
   polling server every 8 s

Code: Select all

[email protected]:~ $ ntpq -crv -pn
associd=0 status=c016 leap_alarm, sync_unspec, 1 event, restart,
version="ntpd [email protected] Wed Mar  9 21:01:11 UTC 2016 (1)",
processor="armv6l", system="Linux/4.1.18+", leap=11, stratum=16,
precision=-18, rootdelay=0.000, rootdisp=12.570, refid=INIT,
reftime=00000000.00000000  Thu, Feb  7 2036  7:28:16.000,
clock=da8b23f9.95c7cb10  Wed, Mar  9 2016 23:36:41.585, peer=0, tc=3,
mintc=3, offset=0.000000, frequency=0.000, sys_jitter=0.000000,
clk_jitter=0.004, clk_wander=0.000
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.22.0    .PPS.            0 l    -   16    0    0.000    0.000   0.000
 127.127.28.0    .NMEA.           3 l    -   16    0    0.000    0.000   0.000

Code: Select all

[email protected]:~ $ dmesg | grep pps
[    3.096409] pps_core: LinuxPPS API ver. 1 registered
[    3.096417] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <[email protected]>
[    3.111760] pps pps0: new PPS source pps.-1
[    3.111855] pps pps0: Registered IRQ 412 as PPS source
[   64.919550] pps_ldisc: PPS line discipline registered
[   64.923106] pps pps1: new PPS source ttyAMA0
[   64.923236] pps pps1: source "/dev/ttyAMA0" added

Code: Select all

[email protected]:~ $ cgps -s
+-------------------------------------------++---------------------------------+
|    Time:       2016-03-10T06:29:00.000Z   ||PRN:   Elev:  Azim:  SNR:  Used: |
|    Latitude:    xx.xxxxxx x               ||  xx    xx    xxx    xx      Y   |
|    Longitude:   xx.xxxxxx x               ||  xx    xx    xxx    xx      Y   |
|    Altitude:   xxxx.x ft                  ||  xx    xx    xxx    xx      Y   |
|    Speed:      0.0 mph                    ||  xx    xx    xxx    xx      Y   |
|    Heading:    0.0 deg (true)             ||  xx    xx    xxx    xx      Y   |
|    Climb:      0.0 ft/min                 ||  xx    xx    xxx    xx      Y   |
|    Status:     3D FIX (2 secs)            ||  xx    xx    xxx    xx      Y   |
|    Longitude Err:   +/- x ft              ||  xx    xx    xxx    xx      Y   |
|    Latitude Err:    +/- x ft              ||  xx    xx    xxx    xx      Y   |
|    Altitude Err:    +/- xx ft             ||  xx    xx    xxx    xx      Y   |
|    Course Err:      n/a                   ||  xx    xx    xxx    xx      N   |
|    Speed Err:       +/- xx mph            ||  xx    xx    xxx    xx      N   |
|    Time offset:     -27774.290            ||                                 |
|    Grid Square:     xxxxxx                ||                                 |
+-------------------------------------------++---------------------------------+
cgps: caught signal 2

Code: Select all

[email protected]:~ $ sudo ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1457568421.095922675, sequence: 6277 - clear  0.000000000, sequence: 0
source 0 - assert 1457568422.095938675, sequence: 6278 - clear  0.000000000, sequence: 0
source 0 - assert 1457568423.095954675, sequence: 6279 - clear  0.000000000, sequence: 0
source 0 - assert 1457568424.095974675, sequence: 6280 - clear  0.000000000, sequence: 0
source 0 - assert 1457568425.095990675, sequence: 6281 - clear  0.000000000, sequence: 0
^C
here all the configuration files i use:

Code: Select all

[email protected]:~ $ cat /boot/cmdline.txt
dwc_otg.lpm_enable=0  console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

Code: Select all

[email protected]:~ $ cat /boot/config.txt
# /boot/config.txt
init_uart_baud=9600
dtoverlay=pps-gpio,gpiopin=18

Code: Select all

[email protected]:~ $ cat /etc/modules
# /etc/modules: kernel modules to load at boot time.
pps-gpio

Code: Select all

[email protected]:~ $ cat /etc/default/gpsd
# /etc/default/gpsd
# Default settings for gpsd.
# change the options.
START_DAEMON="true"
GPSD_OPTIONS="-n"
DEVICES="/dev/ttyAMA0"
USBAUTO="false"
GPSD_SOCKET="/var/run/gpsd.sock"

Code: Select all

[email protected]:~ $ cat /etc/ntp.conf
# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift

# Kernel-mode PPS ref-clock for the precise seconds
server 127.127.22.0 minpoll 4 maxpoll 4 prefer
fudge 127.127.22.0 refid PPS stratum 0

# Server from shared memory provided by gpsd
server 127.127.28.0 minpoll 4 maxpoll 4
fudge 127.127.28.0 refid NMEA stratum 3 time1 0.510

# pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool: <http://www.pool.ntp.org/join.html>
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

restrict 127.0.0.1
restrict ::1
the install steps i did:

Code: Select all

[email protected]:~ $ sudo apt-get -y install gpsd gpsd-clients
[email protected]:~ $ sudo apt-get -y install pps-tools

[email protected]:~ $ sudo apt-get -y install minicom ntpstat

[email protected]:~ $ sudo service ntp stop
[email protected]:~ $ sudo apt-mark hold ntp
[email protected]:~ $ mkdir -p ~/ntp
[email protected]:~ $ cd ~/ntp
[email protected]:~ $ sudo apt-get install libcap-dev
[email protected]:~ $ wget http://archive.ntp.org/ntp4/ntp-4.2/ntp-4.2.8p6.tar.gz
[email protected]:~ $ tar xvfz ntp-4.2.8p6.tar.gz
[email protected]:~ $ cd ntp-4.2.8p6/
[email protected]:~ $ ./configure --enable-linuxcaps
[email protected]:~ $ make
[email protected]:~ $ sudo make install
[email protected]:~ $ sudo cp /usr/local/bin/ntp* /usr/bin/  && sudo cp /usr/local/sbin/ntp* /usr/sbin/
[email protected]:~ $ sudo service ntp start




EDIT few days later:
one step forwards, one steps backwards...

i found out, that the ntpd driver 28 for the virtual ip 127.127.28.0 starts to work only, when i connect a gpsd client to the gpsd once.
once that is done the time via NMEA (the gps data strings) acts as time source for ntp.
and also the ntp driver 22 for PPS virtual ip 127.127.28.0 starts to get being active from the view of ntp
(the /dev/pps0 is served by the kernel and is actively working all the time, only ntp takes notice of PPS after a gps client was connected to gpsd first)
the strange thing is, that the gpsd should start automatically, even without a connected gps-client
that what the documentation is telling...

Code: Select all

# /etc/default/gpsd
START_DAEMON="true"
GPSD_OPTIONS="-n"
that's what the options are being for

to auto start the gpsd, i use as WORKAROUND an additional entry gpspipe -r -n 1 & in the /etc/rc.local file, just before the exit 0

Code: Select all

# /etc/rc.local
...
gpspipe -r -n 1 &
exit 0
that will connect a gps client for exactly one NMEA output and then it disconnect itself gracely from the gpsd. but gpsd keeps active in the background and serves ntp with proper gps data.
anyhow, that works now... this was the step forwards. :D

that's, what i get now, after the RPi is booted up without a internet connection

Code: Select all

[email protected]:~ $ ntpq -crv -pn
associd=0 status=0418 leap_none, sync_uhf_radio, 1 event, no_sys_peer,
version="ntpd [email protected] Wed Mar  9 21:01:11 UTC 2016 (1)",
processor="armv6l", system="Linux/4.1.18+", leap=00, stratum=4,
precision=-19, rootdelay=0.000, rootdisp=1964.960, refid=SHM(0),
reftime=da903eb0.37b57464  Sun, Mar 13 2016 19:32:00.217,
clock=da903eb6.6399f39e  Sun, Mar 13 2016 19:32:06.389, peer=60741, tc=4,
mintc=3, offset=22.803398, frequency=-15.352, sys_jitter=0.000000,
clk_jitter=15.239, clk_wander=0.000
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
x127.127.22.0    .PPS.            0 l    5   16    3    0.000  -71.439  13.025
*127.127.28.0    .NMEA.           3 l    6   16    7    0.000   22.803  20.441
but now i realize an other problems, to running my ntp statum 1 server

the NMEA gps data are not very accurate in sync by nature of gps NMEA string handling.
(the strings arrives not very syncroniusly via serial port and there are many additional gps data where its amount depends on how many satelites are in view and the baud rate of serial connection).
so its jitter can be up to 500ms in average it is something around 300 ms.
that is good enough, to set the local date time to a correct value, but is far away to be very accurate as it should for a stratum1 ntp server.

the problem is now. the ntp keeps to stay at the NMEA source and does never switck to the very precise PPS clock source.

how can i force ntp to use the high precise PPS source, after ntp was taking the NMEA data to setup the date time.
it is written in the documentation, that the PPS is taking in account only in cases. that a "normal" time sounrce was reached - because a PPS itself serves only a signal, not a date time. but a date time source is the NMEA. so the minimum requirements are given to take the PPS in account.
but ntp ignores the PPS. (it is marked as "x" = "falsetick" and is never be used)
and the ntp service gives only the very inaccurate synced time of NMEA.

Code: Select all

[email protected]:~ $ ntpstat
synchronised to UHF radio at stratum 4
   time correct to within 365 ms
   polling server every 16 s
(that's my NMEA source)

how can i force ntp to use the high precise PPS in case there is no internet connection? :x :?:
it should be like (as it is, when i have an internet connection and my local PPS is in use):

Code: Select all

[email protected]:~ $ ntpstat
synchronised to atomic clock at stratum 1
   time correct to within 0 ms
   polling server every 16 s
(that's my local PPS source)
Last edited by beta-tester on Fri Mar 18, 2016 8:25 am, edited 1 time in total.
{ I only give negative feedback }
RPi B (256MB), B (512MB), B+, ZeroW; 2B; 3B, 3B+; 4B (4GB)

FM81
Posts: 518
Joined: Wed Apr 17, 2013 4:33 pm

Re: Trouble: RPi as high precise NTP Server with GPS/PPS dev

Thu Mar 17, 2016 6:44 pm

... but if i use the RPi in a local network without a connection to external internet, then the RPi isn't able to get the correct time, that is should get from the GPS device.
From the middle of your first linked page:

Code: Select all

Amend this line to add a trailing "prefer":

    server 0.debian.pool.ntp.org iburst prefer

Note: you must add a preferred server or PPS doesn’t work.
Means: Isolated network = no additional prefered server possible = PPS will not work

Greetings, FM_81
A: What does the command 'cat /dev/urandom', can you tell me please?
B: Yeah, that's very simple: It feeds your cat with radioactive material!

beta-tester
Posts: 1302
Joined: Fri Jan 04, 2013 1:57 pm
Location: de_DE

Re: Trouble: RPi as high precise NTP Server with GPS/PPS dev

Fri Mar 18, 2016 4:56 am

FM81 wrote:
... but if i use the RPi in a local network without a connection to external internet, then the RPi isn't able to get the correct time, that is should get from the GPS device.
From the middle of your first linked page:

Code: Select all

Amend this line to add a trailing "prefer":

    server 0.debian.pool.ntp.org iburst prefer

Note: you must add a preferred server or PPS doesn’t work.
Means: Isolated network = no additional prefered server possible = PPS will not work

Greetings, FM_81
thanks, but i thought using the "NMEA" as fallback in case there is no internet will serve the minimum requirements

Code: Select all

# Server from shared memory provided by gpsd
server 127.127.28.0 minpoll 4 maxpoll 4
fudge 127.127.28.0 refid NMEA stratum 3 time1 0.510
the NMEA will be used now (with the workaround by starting gpsd via rc.local), the PPS is giving non-null values as well now.
but PPS is still never be used for timekeeping.

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
x127.127.22.0    .PPS.            0 l    5   16    3    0.000  -71.439  13.025
*127.127.28.0    .NMEA.           3 l    6   16    7    0.000   22.803  20.441
the x in front of the PPS means that ntp detect that PPS as falseticked.
(compared to the jittery NMEA it is true, because NMEA has a big jitter)

do you know how to tweak ntp to let ntp see PPS more accurate and NMEA as less accurate?
can i use time1, time2 or other flags to achieve that?

it makes me crasy/despair to know i have the hardware to get a precise clock, but the software i get not working as expected... :evil: :roll:
{ I only give negative feedback }
RPi B (256MB), B (512MB), B+, ZeroW; 2B; 3B, 3B+; 4B (4GB)

beta-tester
Posts: 1302
Joined: Fri Jan 04, 2013 1:57 pm
Location: de_DE

Re: Trouble: RPi as high precise NTP Server with GPS/PPS dev

Fri Mar 18, 2016 8:16 am

i think i got it working, without any internet network connection.

reading further documentations i found following sentences:
- PPS believed only if prefer peer correct and within 128 ms
(https://www.eecis.udel.edu/~mills/datab ... recise.pdf)
- Step threshold (128 ms): ignore if offset exceeds until stepout.
(https://www.eecis.udel.edu/~mills/datab ... /clock.pdf)

in combination with the man ntp documentation i changed my /etc/ntp.conf file like folowing...
(maybe the step limits are now way too wide and sloppy
0.5 is the absolute worsed limit, 0.128ms is default, but the NMEA is out of the 0.128 limit i guess, but within 0.4)

Code: Select all

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

# https://www.eecis.udel.edu/~mills/database/brief/precise/precise.pdf
# - PPS believed only if prefer peer correct and within 128 ms
tinker  step 0.4  stepback 0.4  stepfwd 0.4

# /dev/pps(0..3): Kernel-mode PPS ref-clock for the precise seconds
server 127.127.22.0  minpoll 4  maxpoll 4
fudge 127.127.22.0  refid PPS  stratum 0  flag3 1  flag4 1

# gpsd: GPS NMEA serial data reference
server 127.127.28.0  minpoll 4  maxpoll 4 prefer
fudge 127.127.28.0  refid NMEA  stratum 3  time1 0.510


# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

#
driftfile /var/lib/ntp/ntp.drift
logfile /var/log/ntp.log

# Enable this if you want statistics to be logged.
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
now if i boot my RPi Statum 1 NTP server,
is takes the NMEA data to initially sync to date timer of GPS,
few seconds later the PPS get be activated and the ntpd takes PPS into account... and starts to sync to PPS as wanted :mrgreen:

Code: Select all

synchronised to atomic clock at stratum 1
   time correct to within 1 ms
   polling server every 16 s
sync to atomic clock (my PPS)

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
o127.127.22.0    .PPS.            0 l   15   16  377    0.000   -0.024   0.003
*127.127.28.0    .NMEA.           3 l   15   16  377    0.000  -54.385  30.985
watch the "o" in front of 127.127.22.0 PPS. isn't it beautyful... :mrgreen:
{ I only give negative feedback }
RPi B (256MB), B (512MB), B+, ZeroW; 2B; 3B, 3B+; 4B (4GB)

beta-tester
Posts: 1302
Joined: Fri Jan 04, 2013 1:57 pm
Location: de_DE

Re: Trouble: RPi as high precise NTP Server with GPS/PPS dev

Fri Mar 18, 2016 8:38 am

FM81 wrote:From the middle of your first linked page:

Code: Select all

Amend this line to add a trailing "prefer":

    server 0.debian.pool.ntp.org iburst prefer

Note: you must add a preferred server or PPS doesn’t work.
Means: Isolated network = no additional prefered server possible = PPS will not work

Greetings, FM_81
hmm stupid me... without ´the tinker shit it works as well. :roll:
i only took you sugestions to put the prefer option to the NMEA time source, that alone will be the trick.

thank you for the hint.
(and i thought i was using all those combinations already :roll: )

so my ntp.conf file has simply that content:

Code: Select all

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

# /dev/pps(0..3): Kernel-mode PPS ref-clock for the precise seconds
server 127.127.22.0  minpoll 4  maxpoll 4
fudge 127.127.22.0  refid PPS  stratum 0  flag3 1  flag4 1

# gpsd: GPS NMEA serial data reference
server 127.127.28.0  minpoll 4  maxpoll 4 prefer
fudge 127.127.28.0  refid NMEA  stratum 3  time1 0.510

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

#
driftfile /var/lib/ntp/ntp.drift
logfile /var/log/ntp.log

# Enable this if you want statistics to be logged.
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
{ I only give negative feedback }
RPi B (256MB), B (512MB), B+, ZeroW; 2B; 3B, 3B+; 4B (4GB)

amorphys
Posts: 2
Joined: Tue Aug 16, 2016 9:00 am

Re: [FIXED]: RPi as high precise NTP Server with GPS/PPS dev

Fri Sep 16, 2016 11:24 am

Hi,
good tutorial i was having same scenario like in your post and because of you i was able to fixed.

but right now i find another issue that is seems to affect the working gps-time-server with less than 10 satellites connected the visible can vary from 13 ~ 15 is that ntp does not start to use time from gpsd
Did you observe something similar ? during your setup i have now a location that does not work well i have fix with 9, 10 satellite but is not sync
ntpstat
unsynchronised
polling server every 8 s

same like before

i repeat myself it was worked well in a location but in one particular location does not work :(
Do you have some tips what to check ?
Attachments
Capture.PNG
Capture.PNG (40.71 KiB) Viewed 16861 times
1.PNG
1.PNG (41.34 KiB) Viewed 16861 times
Capture.PNG
Capture.PNG (40.71 KiB) Viewed 16861 times

beta-tester
Posts: 1302
Joined: Fri Jan 04, 2013 1:57 pm
Location: de_DE

Re: [FIXED]: RPi as high precise NTP Server with GPS/PPS dev

Sat Sep 17, 2016 6:50 pm

hi amorphys,

no, i not observed that till now. (* see the comment at the end)

at home, i have have the gps antenna on the window, but i am at base level and there is a balcony above the window and surrounded of other higher.
at that position i can be happy, if i get 7 satallites used for "3d fix" and even then i have maximum 2 of then makred as green and mostely they are yellow and red all the time. but i always get PPS signal as soon i get a 3d fix.

Code: Select all

┌───────────────────────────────────────────┐┌─────────────────────────────────┐
│    Time:       2016-09-17T.............   ││PRN:   Elev:  Azim:  SNR:  Used: │
│    Latitude:    ...........               ││ ...    ..    ...    19      Y   │
│    Longitude:   ...........               ││ ...    ..    ...    00      Y   │
│    Altitude:   ...... ft                  ││ ...    ..    ...    34      Y   │
│    Speed:      0.3 mph                    ││ ...    ..    ...    15      Y   │
│    Heading:    90.7 deg (true)            ││ ...    ..    ...    34      Y   │
│    Climb:      0.0 ft/min                 ││ ...    ..    ...    13      Y   │
│    Status:     3D FIX (13 secs)           ││ ...    ..    ...    00      N   │
│    Longitude Err:   +/- 52 ft             ││ ...    ..    ...    18      N   │
│    Latitude Err:    +/- 67 ft             ││ ...    ..    ...    00      N   │
│    Altitude Err:    +/- 64 ft             ││ ...    ..    ...    21      N   │
│    Course Err:      n/a                   ││ ...    ..    ...    16      N   │
│    Speed Err:       +/- 91 mph            ││ ...    ..    ...    00      N   │
│    Time offset:     0.520                 ││ ...    00    000    00      N   │
│    Grid Square:     ......                ││                                 │
└───────────────────────────────────────────┘└─────────────────────────────────┘

Code: Select all

watch -n4 sh -c "ntpstat; ntpq -p -crv;"

Every 4.0s: sh -c ntpstat; ntpq -p -crv;                                                                                          Sat Sep 17 18:41:55 2016

synchronised to atomic clock at stratum 1
   time correct to within 1 ms
   polling server every 8 s
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oPPS(0)          .PPS.            0 l    5    8  377    0.000    0.024   0.011
*SHM(0)          .NMEA.           0 l    6    8  377    0.000   43.913  12.588
associd=0 status=0115 leap_none, sync_pps, 1 event, clock_sync,
version="ntpd [email protected] Sat Sep 17 21:08:30 UTC 2016 (1)",
processor="armv6l", system="Linux/4.4.13+", leap=00, stratum=1,
precision=-19, rootdelay=0.000, rootdisp=1.060, refid=PPS,
reftime=db880cee.fed0a371  Sat, Sep 17 2016 18:41:50.995,
clock=db880cf3.a1cbf457  Sat, Sep 17 2016 18:41:55.632, peer=64400, tc=3,
mintc=3, offset=0.023907, frequency=-19.019, sys_jitter=0.010965,
clk_jitter=0.008, clk_wander=0.012
(offset and jitter are high, because i just powered on the system again after a two months down time - only for you)

maybe it helps to add a battery to your gps, if it has that option. (it will buffer the RTC and the satallite table - so after powerup, it does not need to do a cold start)
i have a battery on my gps, so it will speed up covering the satellites.
possible the ntp deamon will give up (time out), before the gps get a 3d fix.

your picture shows, you definitely have a "3d fix". so you should get a PPS from the GPS device at that time.
you can try to restart the ntpd after the gps is giving the PPS signal.

ps: here is the script i made and used to setup my pps gps stratum one server...
https://github.com/beta-tester/RPi-GPS-PPS-StratumOne

(comment at the end :) )
are you sure, your scenario was working at one location?
i can see at your picture, that you are using an older version of ntpd (4.2.7p*). did you compiled an older version or did you "apt-get upgrade" the compiled ntpd by accident?
(before or after compiling and replacing the ntpd with your newest "customized" version, you should mark the ntpd to hold, to prevent apt-get upgrade to replace the compiled customized ntpd version)

Code: Select all

sudo apt-mark hold ntp
or are you using a RPi3, where you have to disable bluetooth to be able to use the serial at GPIO?
{ I only give negative feedback }
RPi B (256MB), B (512MB), B+, ZeroW; 2B; 3B, 3B+; 4B (4GB)

amorphys
Posts: 2
Joined: Tue Aug 16, 2016 9:00 am

Re: [FIXED]: RPi as high precise NTP Server with GPS/PPS dev

Mon Sep 19, 2016 6:24 am

Hi,
thanks for your quick reply :).

I fixed the problem and here is how :
1.yes i put this old version of ntp from begining i changed now to the new one :)
2.was working well in my location with this version tested etc
3.I observed the log
cat /var/log/syslog
and here it was my answer was so simple :)
i put even a picture for this so my time on raspy was to big the difference so .....
4.i did update manual the pi date time etc and after stop and restart ntp here it was see picture of syslog after update
And now everything is work as should be :)
Many thanks for help me out to figure out
Attachments
syslog_after_update.gif
syslog_after_update.gif (22.13 KiB) Viewed 16706 times
syslog.png
syslog.png (62.67 KiB) Viewed 16706 times

w00dw0rm
Posts: 12
Joined: Mon Sep 19, 2016 10:43 am

Re: [FIXED]: RPi as high precise NTP Server with GPS/PPS dev

Mon Sep 19, 2016 11:53 am

Hi - im interested in your output of ntptime. does it say PPSSIGNAL anywhere?
Thanks

SpiraMirabilis
Posts: 4
Joined: Tue Sep 20, 2016 4:05 am

Re: [FIXED]: RPi as high precise NTP Server with GPS/PPS dev

Tue Sep 20, 2016 4:06 am

Keep in mind that GPS Time is slightly off from Universal Coordinated Time.

User avatar
DougieLawson
Posts: 36832
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website Twitter

Re: [FIXED]: RPi as high precise NTP Server with GPS/PPS dev

Tue Sep 20, 2016 8:41 am

I never knew that GPS didn't play nicely with the 17 leap seconds inserted into UTC since they set their clocks.

http://leapsecond.com/java/gpsclock.htm
Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

Any DMs sent on Twitter will be answered next month.

This is a doctor free zone.

SpiraMirabilis
Posts: 4
Joined: Tue Sep 20, 2016 4:05 am

Re: [FIXED]: RPi as high precise NTP Server with GPS/PPS dev

Wed Sep 21, 2016 12:30 am

Yes, sir. For the GPS constellation, precise time is only really needed from one SV to another, of course, not from what we'd refer to as objective time or UTC. Implementing leap-seconds would be a net negative in terms of GPS accuracy.

w00dw0rm
Posts: 12
Joined: Mon Sep 19, 2016 10:43 am

Re: [FIXED]: RPi as high precise NTP Server with GPS/PPS dev

Wed Sep 21, 2016 7:56 am

Hey all and beta-tester - im trying to figure out if it is essential for ntptime to reflect PPS:

"The first thing you should look at is the status (0x2107 in our case). The magic words in parentheses explain the meaning of the individual bits. The important bit for now is PPSSIGNAL. That bit is set directly by the operating system and says a PPS signal has been detected."

from

http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm

as per ntptime output.

mine does not, it just says PPL and USYNC ( or PPL and NANO i think).

beta-tester
Posts: 1302
Joined: Fri Jan 04, 2013 1:57 pm
Location: de_DE

Re: [FIXED]: RPi as high precise NTP Server with GPS/PPS dev

Wed Sep 21, 2016 3:52 pm

w00dw0rm wrote:Hey all and beta-tester - im trying to figure out if it is essential for ntptime to reflect PPS:

"The first thing you should look at is the status (0x2107 in our case). The magic words in parentheses explain the meaning of the individual bits. The important bit for now is PPSSIGNAL. That bit is set directly by the operating system and says a PPS signal has been detected."

from

http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm

as per ntptime output.

mine does not, it just says PPL and USYNC ( or PPL and NANO i think).
is that a question?
if your GPS gives a PPS signal to the GPIO
and your kernel is setted up to use that PPS
and your ntpd is useing that PPS (you have to compile the ntpd newly by yourself - the normal one from the raspbian isn't able to use PPS as long as i know),
only then you will get a clock_sync via PPS after a while.
that PPS signal is essential for a stratum1 server.
everything else is less precise and can not be called stratum1 anymore.
stratum15 is the lowest precise clock server (e.g. if you only use the NMEA data of the gps device)
i mean to remember my that the time server needs two different time sources as minimum to get the lock to trust its time.
in my case (NMEA + PPS), if you don't have a GPS, you need two timeservers via internet or a DCF77 (its time data + its PPS) as reliable time source.
if the time server does not get a lock, then it is a free running clock free running in its frequency drift...
stratum16 = totally unsynced clock
{ I only give negative feedback }
RPi B (256MB), B (512MB), B+, ZeroW; 2B; 3B, 3B+; 4B (4GB)

w00dw0rm
Posts: 12
Joined: Mon Sep 19, 2016 10:43 am

Re: [FIXED]: RPi as high precise NTP Server with GPS/PPS dev

Mon Sep 26, 2016 8:45 am

Hi beta-tester,

Thanks for the explanation..

in my case,
yes I have PPS connected to GPIO
I think I set kernel to use PPS
I compiled ntp.

Let me re-phrase the question in my mind - because I want to ensure I did everything correctly by checking the status my pi:

is it important that the output of ntptime to contain something like:
status 0x2107 (PLL,PPSFREQ,PPSTIME,PPSSIGNAL,NANO)?
( as explained in section 6.2.4.2.1. of this: http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm )

because my output contains this:
status 0x2001 (PLL,NANO),

I would be interested in what your ntptime output is like, to compare against.

Thanks a lot.

beta-tester
Posts: 1302
Joined: Fri Jan 04, 2013 1:57 pm
Location: de_DE

Re: [FIXED]: RPi as high precise NTP Server with GPS/PPS dev

Wed Sep 28, 2016 8:27 pm

w00dw0rm wrote:...is it important that the output of ntptime to contain something like:
status 0x2107 (PLL,PPSFREQ,PPSTIME,PPSSIGNAL,NANO)?
( as explained in section 6.2.4.2.1. of this: http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm )

because my output contains this:
status 0x2001 (PLL,NANO),

I would be interested in what your ntptime output is like, to compare against.

Thanks a lot.
hmmm... that's interesting...
i did not used ntptime, but now, and you are right, i also get "only" (PLL,NANO).
see below the output of ntptime, ntpstat and ntpq first just after restart the service, then some second later, and then after a long while.

Code: Select all

StratumOne:~ $ sudo service ntp restart



StratumOne:~ $ ntptime; ntpstat; ntpq -p -crv;
ntp_gettime() returns code 0 (OK)
  time db96437a.7c460ed8  Wed, Sep 28 2016 13:26:18.485, (.485444178),
  maximum error 1016 us, estimated error 16 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 0.000 us, frequency -19.460 ppm, interval 1 s,
  maximum error 1016 us, estimated error 16 us,
  status 0x2001 (PLL,NANO),
  time constant 3, precision 0.001 us, tolerance 500 ppm,
  
unsynchronised
   polling server every 8 s
   
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 PPS(0)          .PPS.            0 l    -    8    0    0.000    0.000   0.000
 SHM(0)          .NMEA.           0 l    -    8    0    0.000    0.000   0.002
associd=0 status=c016 leap_alarm, sync_unspec, 1 event, restart,
version="ntpd [email protected] Sat Sep 17 21:08:30 UTC 2016 (1)",
processor="armv6l", system="Linux/4.4.13+", leap=11, stratum=16,
precision=-19, rootdelay=0.000, rootdisp=0.015, refid=INIT,
reftime=00000000.00000000  Thu, Feb  7 2036  6:28:16.000,
clock=db96437a.9b25a89f  Wed, Sep 28 2016 13:26:18.606, peer=0, tc=3,
mintc=3, offset=0.000000, frequency=-19.460, sys_jitter=0.000000,
clk_jitter=0.002, clk_wander=0.000



StratumOne:~ $ ntptime; ntpstat; ntpq -p -crv;
ntp_gettime() returns code 0 (OK)
  time db96437f.f63f4668  Wed, Sep 28 2016 13:26:23.961, (.961903795),
  maximum error 3516 us, estimated error 16 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 0.000 us, frequency -19.460 ppm, interval 1 s,
  maximum error 3516 us, estimated error 16 us,
  status 0x2001 (PLL,NANO),
  time constant 3, precision 0.001 us, tolerance 500 ppm,
  
synchronised to UHF radio at stratum 1
   time correct to within 7977 ms
   polling server every 8 s
   
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 PPS(0)          .PPS.            0 l    -    8    0    0.000    0.000   0.000
*SHM(0)          .NMEA.           0 l    6    8    1    0.000  -38.888   0.002
associd=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync,
version="ntpd [email protected] Sat Sep 17 21:08:30 UTC 2016 (1)",
processor="armv6l", system="Linux/4.4.13+", leap=00, stratum=1,
precision=-19, rootdelay=0.000, rootdisp=7977.279, refid=NMEA,
reftime=db96437a.a3bd2e76  Wed, Sep 28 2016 13:26:18.639,
clock=db964380.127d6c1e  Wed, Sep 28 2016 13:26:24.072, peer=30289, tc=3,
mintc=3, offset=-38.887758, frequency=-19.460, sys_jitter=0.001907,
clk_jitter=13.749, clk_wander=0.000



StratumOne:~ $ ntptime; ntpstat; ntpq -p -crv;
ntp_gettime() returns code 0 (OK)
  time db96a25c.407e6b40  Wed, Sep 28 2016 20:11:08.251, (.251929298),
  maximum error 2500 us, estimated error 2 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset -1.363 us, frequency -19.673 ppm, interval 1 s,
  maximum error 2500 us, estimated error 2 us,
  status 0x2001 (PLL,NANO),
  time constant 3, precision 0.001 us, tolerance 500 ppm,
  
synchronised to atomic clock at stratum 1
   time correct to within 1 ms
   polling server every 8 s
   
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oPPS(0)          .PPS.            0 l    3    8  377    0.000   -0.002   0.003
*SHM(0)          .NMEA.           0 l    2    8  377    0.000    6.240  25.342
associd=0 status=0115 leap_none, sync_pps, 1 event, clock_sync,
version="ntpd [email protected] Sat Sep 17 21:08:30 UTC 2016 (1)",
processor="armv6l", system="Linux/4.4.13+", leap=00, stratum=1,
precision=-19, rootdelay=0.000, rootdisp=1.030, refid=PPS,
reftime=db96a259.a3bb7612  Wed, Sep 28 2016 20:11:05.639,
clock=db96a25c.5bff8d29  Wed, Sep 28 2016 20:11:08.359, peer=30288, tc=3,
mintc=3, offset=-0.001500, frequency=-19.673, sys_jitter=0.003223,
clk_jitter=0.003, clk_wander=0.001
but the thing with ntptime is, that you can manipulate the status. i didn't found a proper description what values are allowed to set (see here), but i was able to "destroy" the status to 0x0.

maybe the kernel is not setting up that status in a proper way, or there is maybe a flag to set in the ntp.config or ntptime is not supported.
ppstest, ntpstat and ntpq suggests, that PPS is used, only ntptime is showing something different.
{ I only give negative feedback }
RPi B (256MB), B (512MB), B+, ZeroW; 2B; 3B, 3B+; 4B (4GB)

w00dw0rm
Posts: 12
Joined: Mon Sep 19, 2016 10:43 am

Re: [FIXED]: RPi as high precise NTP Server with GPS/PPS dev

Thu Sep 29, 2016 10:21 am

Yes I get very similar results:

Code: Select all

sudo service ntp restart

ntptime; ntpstat; ntpq -p -crv;

ntp_gettime() returns code 0 (OK)
  time db97605f.00925788  Thu, Sep 29 2016  9:41:51.002, (.002233705),
  maximum error 516 us, estimated error 16 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 0.000 us, frequency -9.143 ppm, interval 1 s,
  maximum error 516 us, estimated error 16 us,
  status 0x2001 (PLL,NANO),
  time constant 3, precision 0.001 us, tolerance 500 ppm,
unsynchronised
   polling server every 8 s
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 PPS(0)          .kPPS.           0 l    -   16    0    0.000    0.000   0.000
 SHM(0)          .SHM.            0 l    -   16    0    0.000    0.000   0.001
associd=0 status=c016 leap_alarm, sync_unspec, 1 event, restart,
version="ntpd [email protected] Wed Sep 14 12:18:16 UTC 2016 (1)",
processor="armv7l", system="Linux/4.4.20-v7+", leap=11, stratum=16,
precision=-20, rootdelay=0.000, rootdisp=0.015, refid=INIT,
reftime=00000000.00000000  Thu, Feb  7 2036  6:28:16.000,
clock=db97605f.11f11315  Thu, Sep 29 2016  9:41:51.070, peer=0, tc=3,
mintc=3, offset=0.000000, frequency=-9.143, sys_jitter=0.000000,
clk_jitter=0.001, clk_wander=0.000


ntptime; ntpstat; ntpq -p -crv;
ntp_gettime() returns code 0 (OK)
  time db97606a.5705b7d0  Thu, Sep 29 2016  9:42:02.339, (.339931032),
  maximum error 6516 us, estimated error 16 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 0.000 us, frequency -9.143 ppm, interval 1 s,
  maximum error 6516 us, estimated error 16 us,
  status 0x2001 (PLL,NANO),
  time constant 3, precision 0.001 us, tolerance 500 ppm,
synchronised to UHF radio at stratum 1
   time correct to within 7941 ms
   polling server every 16 s
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 PPS(0)          .kPPS.           0 l    -   16    0    0.000    0.000   0.000
*SHM(0)          .SHM.            0 l   11   16    1    0.000    3.279   0.001
associd=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync,
version="ntpd [email protected] Wed Sep 14 12:18:16 UTC 2016 (1)",
processor="armv7l", system="Linux/4.4.20-v7+", leap=00, stratum=1,
precision=-20, rootdelay=0.000, rootdisp=7941.272, refid=SHM,
reftime=db97605f.8b917308  Thu, Sep 29 2016  9:41:51.545,
clock=db97606a.5fe43e07  Thu, Sep 29 2016  9:42:02.374, peer=15607, tc=4,
mintc=3, offset=3.279228, frequency=-9.143, sys_jitter=0.000954,
clk_jitter=1.159, clk_wander=0.000

 
ntptime; ntpstat; ntpq -p -crv;
ntp_gettime() returns code 0 (OK)
  time db976129.a1318764  Thu, Sep 29 2016  9:45:13.629, (.629662440),
  maximum error 6500 us, estimated error 1053 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 11.760 us, frequency -9.567 ppm, interval 1 s,
  maximum error 6500 us, estimated error 1053 us,
  status 0x2001 (PLL,NANO),
  time constant 4, precision 0.001 us, tolerance 500 ppm,
synchronised to atomic clock at stratum 1
   time correct to within 1 ms
   polling server every 16 s
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oPPS(0)          .kPPS.           0 l   11   16  377    0.000    0.014   0.137
*SHM(0)          .SHM.            0 l   10   16  377    0.000    3.030   0.525
associd=0 status=0115 leap_none, sync_pps, 1 event, clock_sync,
version="ntpd [email protected] Wed Sep 14 12:18:16 UTC 2016 (1)",
processor="armv7l", system="Linux/4.4.20-v7+", leap=00, stratum=1,
precision=-20, rootdelay=0.000, rootdisp=1.165, refid=kPPS,
reftime=db97611e.8b91c49b  Thu, Sep 29 2016  9:45:02.545,
clock=db976129.b2224e3e  Thu, Sep 29 2016  9:45:13.695, peer=15606, tc=4,
mintc=3, offset=0.013985, frequency=-9.567, sys_jitter=0.136663,
clk_jitter=1.054, clk_wander=0.079
and I agree completely about:
ppstest, ntpstat and ntpq suggests, that PPS is used, only ntptime is showing something different.
But something still niggles at me about this PPS.... probably because I am at the cliff edge of my abilities in linux here.

By the way, it appears ntpdc (as suggested as an alternative to ntptime in https://www.eecis.udel.edu/~mills/ntp/html/ntptime.html ) is no longer working: http://lists.ntp.org/pipermail/question ... 37145.html so I found the ntpq -c [command] alternatives like:

Code: Select all

$ ntpq -c kerninfo
associd=0 status=0115 leap_none, sync_pps, 1 event, clock_sync,
pll offset:            -0.01559
pll frequency:         -8.54549
maximum error:         0.0075
estimated error:       9.6e-05
kernel status:         pll nano
pll time constant:     4
precision:             1e-06
frequency tolerance:   500
pps frequency:         0
pps stability:         0
pps jitter:            0
calibration interval   0
calibration cycles:    0
jitter exceeded:       0
stability exceeded:    0
calibration errors:    0
[email protected]:~ $
and it is bizzare that the ntpq -c kerninfo claims to not know about PPS, even though ntpq -p clearly does!

Maybe there are 2 PPS modes, from the hint in http://doc.ntp.org/4.2.4/ntpq.html
"o pps.peer
The peer has been declared the system peer and lends its variables to thesystem variables. However, the actual system synchronization is derived from a pulse-per-second (PPS) signal, either indirectly via the PPS reference clock driver or directly via kernel interface. "

and maybe the ntpd -c -kerninfo (or ntptime) refers to the kernel interface, and what we have working is the PPS reference clock?
I wonder if there is any difference in accuracy..
Ta

beta-tester
Posts: 1302
Joined: Fri Jan 04, 2013 1:57 pm
Location: de_DE

Re: [FIXED]: RPi as high precise NTP Server with GPS/PPS dev

Sat Oct 01, 2016 12:52 pm

hmm...
the raspbian kernel is compiled with the settings:

Code: Select all

StratumOne:~ $ sudo modprobe configs
StratumOne:~ $ zcat /proc/config.gz | grep PPS
# PPS support
CONFIG_PPS=m
# CONFIG_PPS_DEBUG is not set
# PPS clients support
# CONFIG_PPS_CLIENT_KTIMER is not set
CONFIG_PPS_CLIENT_LDISC=m
CONFIG_PPS_CLIENT_GPIO=m
# PPS generators support
where =m means, that this options are included as modules.
and all modules are used

Code: Select all

StratumOne:~ $ lsmod | grep pps
pps_ldisc               2389  2
pps_gpio                2993  1
pps_core                8756  4 pps_ldisc,pps_gpio
not sure how to read that correctly (http://lxr.linux.no/linux/drivers/pps/Kconfig), but the raspbian kernel is also compiled with "CONFIG_NO_HZ=y", maybe this will prevent the kernel to discipline itself by PPS. (maybe that kernel or the RPi hardware isn't able to do PPS sync itself)
so the PPS signal is used, but only bypassed to a consumer, if there is any, but the kernel itself isn't using that PPS for any sync.
and therefore the ntpq -c kerninfo is giving only PLL and not PPS in its status.

the kernel is using the clock, but does not sync the clock. ntpd is doing that job for the kernel.
but ntpd is using the PPS signal, provided by the kernel, to sync the time through its ntp sync mechanism.
a PPS is as good as any other internet time, but way more accurate, with way less latency, way more reliable.

there is a comment for the ntp.conf file entry for driver22
The driver normally operates like any other driver and uses the same mitigation algorithms and PLL/FLL clock discipline incorporated in the daemon. If kernel PLL/FLL support is available, the kernel PLL/FLL clock discipline can be used instead. The default behavior is not to use the kernel PPS clock discipline, even if present. This driver incorporates a good deal of signal processing to reduce jitter using the median filter algorithm in the driver. As the result, performance with minpoll configured at 4 (16s) is generally better than the kernel PPS discipline. However, fudge flag 3 can be used to enable the kernel PPS discipline if necessary.
so i read this comment as, that it does not lack in accuracy when using PPS signal only and not the "PPS disciplined kernel time" to sync - from the point of view of ntp - and everything that is using that PPS synced ntp time.

i reached the end of my abilities/knowledge.
i am not a pro in that ntp/pps/linux kernel stuff. i am happy, that my RPi is giving time, and i trust that time.

ps:
w00dw0rm wrote:(..) so I found the ntpq -c [command] alternatives like:

Code: Select all

$ ntpq -c kerninfo
...
thank you that you found out. because i got time out messages with the other ntpdc method.
{ I only give negative feedback }
RPi B (256MB), B (512MB), B+, ZeroW; 2B; 3B, 3B+; 4B (4GB)

Return to “Advanced users”