NTP PPS


286 posts   Page 8 of 12   1 ... 5, 6, 7, 8, 9, 10, 11, 12
by Meniscus » Sun Nov 18, 2012 4:56 am
Hello,

I have a USB GPS that I need to be running in a binary mode most of the time. The RPI will usually be connected to the net and I don't have a problem with it getting the second from the net and the GPS also has a 1PPS which produces a 4ms pulse, the rising edge of which is precisely synchronized to the second change. I want to use that to set the kernel discipline (on the RPI, using GPIO.) The GPS has an external antenna connection. This is currently working on a HP thin client, using a serial port and USB at the same time. I don't see any reason that wouldn't work on the RPI, EXCEPT that the difference between the two setups is that the HP has a battery RTC and the RPI does not. The HP setup draws around 10 watts which is usually nothing but when its on batteries I want to use less. Recently we've had some issues with power reliability causing net outages. I want my setup to be able to continue working for as long as a week when the power goes down on batteries. Does that lack of an RTC cause problems?
Posts: 1
Joined: Sun Nov 18, 2012 4:01 am
by darkorb » Thu Nov 22, 2012 11:57 am
abbadabbatech wrote:
aquarat wrote:Pic : (hosted on a pi)
Image

Wondered if you did a technote on or would share the pin connection from pi to ultimate gps and maybe a code example of pulling data?

Thanks

I too would be interested in this :)
Posts: 1
Joined: Thu Nov 22, 2012 11:24 am
by clubcsl » Thu Nov 22, 2012 2:52 pm
darkorb wrote:
abbadabbatech wrote:
aquarat wrote:Pic : (hosted on a pi)
Image

Wondered if you did a technote on or would share the pin connection from pi to ultimate gps and maybe a code example of pulling data?

Thanks

I too would be interested in this :)


I am interested too in this
Posts: 4
Joined: Sun Sep 23, 2012 6:54 pm
by aquarat » Thu Nov 22, 2012 8:48 pm
Just for those who are asking about a guide / technote / tutorial : I made a post/tutorial on how to duplicate my setup on page 5 of this thread.
EOF
User avatar
Posts: 73
Joined: Thu Jul 26, 2012 2:32 pm
Location: Cape Town, South Africa
by audrummer15 » Thu Nov 29, 2012 4:03 pm
Hi,

I have been trying to get my adafruit ultimate gps set up with my raspberry pi. I need to read the NMEA strings from the gps using some kind of code (assumed I'd be writing C for this one). However, I'm not THAT comfortable with Linux, and a little confused. I have my pi wired to my gps correctly, yet, I'm not sure my Pi see's the gps. Am I correct in assuming that I should see the gps in this command, and that /dev/pts/0 is not it?
Code: Select all
root@raspberrypi:/home/pi# tty
/dev/pts/0
root@raspberrypi:/home/pi#

If so, what do I need to do to make my Pi see the gps. Once I can see it (as a tty device) I'm almost positive I can write the code to communicate with it. Will I have to do the kernel recompilation with the pps support as mentioned earlier in the thread? Thanks in advance!
Posts: 5
Joined: Thu Nov 29, 2012 3:52 pm
by audrummer15 » Thu Nov 29, 2012 6:15 pm
By the time this post was approved, I had already figured it out. It was a mixture of ttyAMA0 being held by the terminal from a boot process, as well as my hardware guy wiring the tx and rx lines backwards :lol: . Anyways, now I am getting the NMEA sentences via cat command as well as minicom and a c program I wrote. Good stuff guys!
Posts: 5
Joined: Thu Nov 29, 2012 3:52 pm
by technion » Tue Jan 01, 2013 9:27 pm
Hey guys,

I ues my own kernel in order to get some unrelated modules.

I compiled a kernel earlier using the latest 3.2.27+ and the GPIO patch applied with several offsets, and some kernel files claimed to be "already patched".

It did however, work.

I'm looking to try the 3.6.x kernel now that it seems to have a few relevant fixes to me, so naturally my question is whether the existing GPIO patch works with this branch?
Posts: 230
Joined: Sun Dec 02, 2012 9:49 am
by skavoovie5 » Wed Jan 16, 2013 8:58 am
Does anyone know if Paul Kennedy ever posted his code for the monitoring pages he has (had?) in place?

His github repo (https://github.com/secondthoughts) has no real commits to it, and his dynamic IP server ( http://secondthoughts.no-ip.org/ ) has not been online for the past couple days.

If nothing else, does anyone have a screenshot of his monitoring tool output that I could use as possible inspiration to write my own?

Thanks!
Posts: 6
Joined: Wed Jan 16, 2013 6:33 am
by skavoovie5 » Tue Jan 22, 2013 12:34 pm
For anyone else besides me that is coming late to this thread, a great place to start is davidk's blog post:

http://open.konspyre.org/blog/2012/10/18/raspberry-pi-time-server/

which covers the setup of a RasPi + Adafruit GPS end to end, including some background on NTP for those who are not familiar with it, as well as providing links to an already-compiled kernel if you want to get up and running with as little effort as possible.

He is using Adafruit's Occidentalis Linux distro (http://learn.adafruit.com/adafruit-raspberry-pi-educational-linux-distro/overview), which is a fork of Raspbian "with hardware SPI, I2C, one wire, and WiFi support" for a number of RasPi-compatible USB wifi adapters, and a few other tweaks (that should be standard IMHO) such as enabling SSHd out of the box and auto-generating SSHd keys.
Posts: 6
Joined: Wed Jan 16, 2013 6:33 am
by tlhackque » Sun Jan 27, 2013 5:45 pm
Ah, soo close...

I used the provided kernel (Wow, it's 2x the size of the distribution) and decided it was easier to jumper my GPIO to pin 24 than to rebuild. (It's a bit confusing - https://github.com/davidk/adafruit-rasp ... -linux-pps says pin 23, but the patch and kernel name are 24. 24 is correct - perhaps the github title could change.)

ppstest is happy.
Code: Select all
source 0 - assert 1359307266.309482240, sequence: 2570 - clear  0.000000000, sequence: 0
source 0 - assert 1359307267.309531315, sequence: 2571 - clear  0.000000000, sequence: 0
source 0 - assert 1359307268.309578463, sequence: 2572 - clear  0.000000000, sequence: 0
source 0 - assert 1359307269.309627395, sequence: 2573 - clear  0.000000000, sequence: 0

There's only one thing. I'm using a garmin18xlvc, which sends the PPS pulse as rs232. Level converters invert. So pps is using the uncontrolled (falling) edge, which isn't ideal.

Would it be too greedy to ask if the GPIO config could be a boot command line option, or perhaps if the GPIO could be a loadable module that took parameters for pin # and assertion level?

FWIW, I didn't pick pin 24 because its altfunction is the GPIO UART, which I thought might be useful sometime. I'd picked pin 4, which didn't seem as likely to be used, and was near the other pins so I could use a short header.

Anyhow, if the pin number was configurable, everyone could pick what they need.

Likewise the assertion level - I know the Garmin devices are quite popular with the NTP crowd.

In any case, thanks for your efforts - what's been done has saved me a lot of work.
Posts: 24
Joined: Sun Jan 27, 2013 5:28 pm
by skavoovie5 » Mon Jan 28, 2013 1:13 am
tlhackque wrote:Ah, soo close...
There's only one thing. I'm using a garmin18xlvc, which sends the PPS pulse as rs232. Level converters invert. So pps is using the uncontrolled (falling) edge, which isn't ideal.


Have you attempted to reconfigure the edge of the PPS signal that your NTPd instance is using?

As per the GPS_NMEA driver documentation page:
Code: Select all
flag2 0 | 1
    If PPS signal processing is enabled, capture the pulse on the rising edge if 0 (default); capture on the falling edge if 1.


http://www.eecis.udel.edu/~mills/ntp/ht ... ver20.html
Posts: 6
Joined: Wed Jan 16, 2013 6:33 am
by tlhackque » Mon Jan 28, 2013 1:49 am
Thanks for the suggestion. Yes, I read the NMEA driver documentation.

I believe that ntp option requires the GPIO pin to be setup with .capture_clear=true; the patch says
both assert_falling_edge and capture_clear are both false.

'.capture_clear' tells the PPS kernel to deliver deassertion (logically falling edge) events.

'.assert_falling_edge' should tell the GPIO to do whatever the CPU needs to do to consider the falling edge to be the assertion. In some CPUs, this is a register bit that inverts the incoming signal. In others, a bit doesn't invert the signal, but interrupts on the falling edge. In unfortunate designs, neither happens and software has to poll for the falling edge. I'm not sure what the situation is with this chip.

Sorry about the terminology; electrically voltage level and logical meaning vary, and the language is confusing. 'assert' means the signal is in the state that means 'true', not the resting state. In positive logic, that's a high voltage & what software sees as a '1'. In negative logic, a high voltage is what software sees as a 0; the true state is low. And most hardware mixes these. For example, simple memory chips generally use high = 1 = true for the data wires, but low = asserted for chip select.

ppstest confirms that no 'clear' events are sent from the gpio pin to the PPS kernel.

So telling ntpd to ask for the falling edge will cause it to see no events.

I believe that .assert_falling_edge will cause the GPIO to watch for the falling edge; capture clear can be left false as NTP doesn't need both edges. But I'm not 100% sure; the documentation for GPIO is a bit hard to follow. If the config were easily modified, I'd experiment.

The rising edge sent from the GPS unit is precisely timed. The falling edge is not. The inversion in the interface means that what the GPIO pin sees as rising is what the GPS sent falling. Hence NTP is sampling the uncontrolled edge, which is the true time reference delayed by the width of the pulse.

A fudge of the pulse width allows sync, but the jitter is out of spec. Watching the proper edge is the right answer, which is why I made the request.

The only other practical answer requires re-inverting the signal in the interface. This requires another chip, and adds delay. A software fix is strongly preferred.
Posts: 24
Joined: Sun Jan 27, 2013 5:28 pm
by ntPI » Wed Jan 30, 2013 12:44 am
chrisprt wrote:As promised, I've attached the pps.patch file which should aid anyone who plans to recompile the kernel with PPS support. Download the latest raspberry pi kernel, apply this patch from the linux directory, and then go through the normal compilation process. Make sure to enable all the relevant PPS driver modules in the menuconfig pre-build.

Also, this patch targets GPIO pin 24 for pulse syncing. If you'd like to change that to a different pin, just search the patch for "gpio_pin" and change it accordingly.


Chris (and everyone in thread),

I would like to thank you for the kernel image, modules and patch first. And I'd also like to say its been YEARS since I've patched/compiled a kernel. You can probably see where this is heading, I've run into a problem :)

I downloaded the rpi-3.2.27 source and tried to apply the patch you had linked on page 5 of this thread.

root@hcpi002:/usr/local/src/linux-rpi-3.2.27# patch -p1 < ../pps.patch
patching file arch/arm/mach-bcm2708/bcm2708.c
Hunk #1 succeeded at 58 (offset -2 lines).
Hunk #2 succeeded at 426 (offset 50 lines).
Hunk #3 succeeded at 703 with fuzz 2 (offset 104 lines).
patching file drivers/pps/clients/Kconfig
Hunk #1 succeeded at 56 with fuzz 2 (offset 27 lines).
patching file drivers/pps/clients/Makefile
patching file drivers/pps/clients/pps-ktimer.c
patching file drivers/pps/clients/pps_parport.c
patching file drivers/pps/kapi.c
Hunk #1 succeeded at 76 with fuzz 1 (offset 24 lines).
Hunk #2 FAILED at 88.
Hunk #3 succeeded at 148 with fuzz 2 (offset 32 lines).
1 out of 3 hunks FAILED -- saving rejects to file drivers/pps/kapi.c.rej

Hunk 2 never seems to apply correctly and looking at line 88 of the patch it seems to involve ktimer:

- * The echo function
- */
-
-static void pps_ktimer_echo(struct pps_device *pps, int event, void *data)
-{
- dev_info(pps->dev, "echo %s %s\n",
- event & PPS_CAPTUREASSERT ? "assert" : "",
- event & PPS_CAPTURECLEAR ? "clear" : "");
-}
-
-/*

Line 88 is the line ABOVE "dev_info".

Any help appreciated as I re-acclimate myself to compiling kernels.

Thanks!
Posts: 17
Joined: Tue Jan 29, 2013 2:39 pm
by tlhackque » Wed Jan 30, 2013 1:29 am
I also have tried this.

The latest kernel has the PPS stuff - so only the first bit of the patch - that adds the GPIO pin to the board config - is required. The rest is not. Don't 'reverse' or 'apply' those sections. Best to just remove them.

Took overnight to cross-compile - even on a pretty reasonable server, but it did produce a bootable kernel, and I got the assertion level I need.

Unfortunately, I haven't gotten the firmware and the kernel to talk yet. There's a version skew someplace, but the errors are quite unhelpful.

Anyhow, I get a very reasonable offset/jitter now:

Code: Select all
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
o127.127.20.0    .GPPS.           0 l   39   64  377    0.000    0.022   0.004
Posts: 24
Joined: Sun Jan 27, 2013 5:28 pm
by ntPI » Wed Jan 30, 2013 1:50 am
By latest are you talking the 3.6.x tree?

Anyway, thats not a bad offset. By comparison, here is my BSD+GPS clocks offset:

Code: Select all
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*GPS_NMEA(1)     .PPS.            0 l    6   16  377    0.000    0.001   0.002

Posts: 17
Joined: Tue Jan 29, 2013 2:39 pm
by tlhackque » Wed Jan 30, 2013 3:32 am
Sorry, 'latest' 3.2 ==> 3.2.27 has PPS. Wasn't quite adventurous enough to go to 3.6.

Wouldn't be surprised to see the offset and jitter go down when the RPi has had a few days to stabilize.
Posts: 24
Joined: Sun Jan 27, 2013 5:28 pm
by ntPI » Wed Jan 30, 2013 3:40 am
tlhackque wrote:Sorry, 'latest' 3.2 ==> 3.2.27 has PPS. Wasn't quite adventurous enough to go to 3.6.

Wouldn't be surprised to see the offset and jitter go down when the RPi has had a few days to stabilize.


I agree on your assessment of the jitter (specially if the room temp is somewhat constant). The jitter/offset I posted is from a GPS mounted outside staying around 40F and an old desktop in a room that is a constant 65F that's run since the blizzard 28 days ago.

As far as the kernel version, I went ahead and started to compile the 3.6.x version. I applied the patch to /usr/local/src/linux-rpi-3.6.y/arch/arm/mach-bcm2708/bcm2708.c, zcat /proc/config.gz > .config, then did a make menuconfig to enable the PPS pieces. Started the compile, will post my results sometime tomorrow... hopefully :D
Posts: 17
Joined: Tue Jan 29, 2013 2:39 pm
by ntPI » Wed Jan 30, 2013 4:57 pm
make[4]: *** [drivers/net/wireless/hostap/hostap_80211_rx.o] Error 1
make[3]: *** [drivers/net/wireless/hostap] Error 2
make[2]: *** [drivers/net/wireless] Error 2
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2

I found some google results stating it may be an issue with zip and filesize corrupting things so I used git to get the tree and will try again today.
Posts: 17
Joined: Tue Jan 29, 2013 2:39 pm
by ntPI » Thu Jan 31, 2013 10:57 pm
Well I think it worked :)

I went ahead and compiled the 3.6.11 kernel for this project.
It appears to be about twice the size as the default kernel (5M instead of 2.5M roughly)

If anyone is interested, I can tarball it and make it available for download.
No guarantees it'll work though, but it does boot and the pps module appears to load correctly.

Code: Select all
root@hcpi002:~# uname -a
Linux hcpi002 3.6.11-pps-01312013+ #2 PREEMPT Thu Jan 31 14:42:56 CST 2013 armv6l GNU/Linux

root@hcpi002:~# modprobe pps-gpio

root@hcpi002:~# lsmod
Module                  Size  Used by
iptable_filter          1485  0
ip_tables              11386  1 iptable_filter
x_tables               16890  2 ip_tables,iptable_filter
pps_gpio                2124  0
pps_core                7254  1 pps_gpio
nfsd                  229333  2
snd_bcm2835            12939  0
snd_pcm                78130  1 snd_bcm2835
snd_page_alloc          5129  1 snd_pcm
snd_timer              19946  1 snd_pcm
snd                    58506  3 snd_bcm2835,snd_timer,snd_pcm
evdev                   9454  2

root@hcpi002:~# dmesg | grep pps
[    0.000000] Linux version 3.6.11-pps-01312013+ (root@hcpi002) (gcc version 4.6.3 (Debian 4.6.3-14+rpi1) ) #2 PREEMPT Thu Jan 31 14:42:56 CST 2013
[    1.854533] usb usb1: Manufacturer: Linux 3.6.11-pps-01312013+ dwc_otg_hcd
[  204.500028] pps_core: LinuxPPS API ver. 1 registered
[  204.500056] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[  204.503525] pps pps0: new PPS source pps-gpio.-1
[  204.503589] pps pps0: Registered IRQ 194 as PPS source


I'll get the GPS soldered and wired up this weekend and do some testing.
Posts: 17
Joined: Tue Jan 29, 2013 2:39 pm
by tlhackque » Fri Feb 01, 2013 3:12 am
The kernel I built from 2.27 didn't double in size.

Code: Select all
-rwxr-xr-x 1 root root 2733016 Jan 28 07:02 kernel.img
-rwxr-xr-x 1 root root 2695192 Oct 28 13:40 kernel.img.orig

Still no solution to the firmware compatibility issue, though. No impact that I've seen on my use of the board.

Code: Select all
 vcgencmd version
VCHI initialization failed

Offset and jitter are coming down as expected, but they do go up a bit under load. Still, it's not bad for under $100.

Code: Select all
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
o127.127.20.0    .GPPS.           0 l   25   64  377    0.000    0.006   0.003

Here's the hardware hack I did - I used parts on-hand. You may not have the tools to solder directly to SOIC pins; compsys does have a version of the board with CTS/RTS that would avoid that.

Hint: configure the GPS before attaching the interface. You'll be happy with a PPS pulse width < 100 msec (I used 80), and be sure to enable only ONE NMEA sentence ($GPRMC is prefered). If your inital offset is about the pulse width, you have the PPS pulse inverted. ppstest /dev/pps0 is a useful diagnostic.

Note that I configured the GPIO inverted. Sorry I had to scale down the images to fit the forum size limits.

Oh, and my GPS is outside; RPi, of course isn't.

Slide1.PNG
Hardware hack
Slide1.PNG (54.15 KiB) Viewed 1711 times
Slide2.PNG
Slide2.PNG (63 KiB) Viewed 1711 times


Good luck.
Posts: 24
Joined: Sun Jan 27, 2013 5:28 pm
by ntPI » Fri Feb 01, 2013 3:32 am
What GPS are you using?
Posts: 17
Joined: Tue Jan 29, 2013 2:39 pm
by tlhackque » Fri Feb 01, 2013 3:42 am
Er, if you read the slide... you'd see it's a Garmin GPS18x-LVC

You?
Posts: 24
Joined: Sun Jan 27, 2013 5:28 pm
by ntPI » Sat Feb 02, 2013 4:30 pm
tlhackque wrote:Er, if you read the slide... you'd see it's a Garmin GPS18x-LVC

You?


On by BSD box its a 18 LVC from Garmin.
On the pi, I opted for an Ultimate GPS Breakout v3 from Adafruit.
https://www.adafruit.com/products/746
Posts: 17
Joined: Tue Jan 29, 2013 2:39 pm
by ntPI » Sun Feb 03, 2013 5:20 am
aquarat wrote:Firstly, buy a GPS with a TTL UART for NMEA and a PPS output on 3.3V : http://adafruit.com/products/746 .
You might also want to buy a u.FL adaptor and GPS antenna.

Prepare a new Raspberry Pi with a Raspbian SD card installation.
Boot the Pi and prepare it to your liking (set up networking, ssh, etc.)
Download the following :
modules.tar.gz
and
kernel.tar.gz
The above tar.gz files were provided by chrisrpt. They contain custom compiled modules and a kernel image which support PPS on one of the Pi's GPIO pins (GPIO23).


Basically, I ended up following aquarat's how-to from page 5 (short snippit above).

PPS and NMEA sentences seem to all be working, but ntp isn't communicating with the GPS at all. I am certain it's something silly I am missing, bear in mind that I normally do this on BSD servers :lol:

Anyway, to the troubleshooting...

dmesg pps related info seems to look good:
Code: Select all
[    0.000000] Linux version 3.2.27-pps-g965b922-dirty (root@bt) (gcc version 4.6.2 (Ubuntu/Linaro 4.6.2-14ubuntu2~ppa1) ) #1 PREEMPT Sat Sep 22 16:30:50 EDT 2012
[    1.232816] usb usb1: Manufacturer: Linux 3.2.27-pps-g965b922-dirty dwc_otg_hcd
[    7.888924] pps_core: LinuxPPS API ver. 1 registered
[    7.890598] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    7.902884] pps pps0: new PPS source pps-gpio.-1
[    7.904803] pps pps0: Registered IRQ 194 as PPS source


nmea sentences look good:
Code: Select all
root@hcpi002:~# cat /dev/ttyAMA0
$PGTOP,11,2*6E

$GPGGA,050941.000,4141.9641,N,09327.4492,W,2,12,0.72,297.4,M,-31.8,M,0000,0000*53

$GPGSA,A,3,19,13,28,08,07,06,16,03,11,26,23,01,1.29,0.72,1.07*02

$GPRMC,050941.000,A,4141.9641,N,09327.4492,W,0.03,0.00,030213,,,D*7E

$GPVTG,0.00,T,,M,0.03,N,0.05,K,D*3E


pps looks good:
Code: Select all
root@hcpi002:~# 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 1359868261.022496916, sequence: 1034 - clear  0.000000000, sequence: 0
source 0 - assert 1359868262.022529163, sequence: 1035 - clear  0.000000000, sequence: 0


I think the dev links are correct:
Code: Select all
root@hcpi002:~# ls -l /dev/ | grep pps
lrwxrwxrwx 1 root root           4 Feb  2 22:53 gpspps0 -> pps0
crwxrwxrwt 1 root tty     251,   0 Feb  2 22:53 pps0
root@hcpi002:~# ls -l /dev/ | grep gps
lrwxrwxrwx 1 root root           7 Dec 31  1969 gps0 -> ttyAMA0
lrwxrwxrwx 1 root root           4 Feb  2 22:53 gpspps0 -> pps0


And finally, the ntp.conf piece:
Code: Select all
server 127.127.20.0 mode 24 minpoll 3 iburst true prefer #use ZDA only!
fudge 127.127.20.0 flag1 1 time2 0.350


Relevant ntpq output:
Code: Select all
GPS_NMEA(0)     .GPS.            0 l    -    8    0    0.000    0.000   0.000


It never seems to communicate with the gps. Any help appreciated.
Posts: 17
Joined: Tue Jan 29, 2013 2:39 pm
by tlhackque » Sun Feb 03, 2013 12:40 pm
Getting it talking looks simple (mode is set wrong), but I have more than one observation.

    What speed is the GPS UART running at? stty -F /dev/gps0 should say what your line defaults to without NTP running.

    You programmed NTP to use 9600 (Note: bits 4-6 are a value, not a bitmask); the default for NMEA GPSs is 4800.

    You programmed the driver to look for $GPZDA or $GPZDG, but your GPS is not outputing either of those sentences. $GPRMC is what you want. If 4800, use mode 1. 9600 mode 17.

    Better, if your GPS allows, tell it to output ONLY $GPRMC. The extra sentences add work to the RPi, and add nothing to time. They may add some jitter. (Of course if you want to debug satellites in view, etc, you can turn more on.)

    You should reconsider setting true - better to grab some other servers from the pools. NTP will select the PPS source as long as it's sane. But if it's not, true will send an insane value.

    burst and iburst are not recommended for reference clocks.

    Did you rebuild ntp? The ntp in the distribution doesn't have PPS support.

    Check /var/log/syslog.
Here is my complete ntp.conf - I've removed the low bits of ipv6 addresses as I don't care to publish them. Otherwise, it's complete. (Yes, I should have preempt on the pool servers.)

I fussed with time2 to get the fastest initial sync. Easiest way is to set the GPS noselect, lock on to some other servers, look at PPSTEST's offset, and use that for time2.

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

driftfile /var/lib/ntp/ntp.drift


# 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

# GPS - unit 0 (symlink /dev/gps0 => /dev/tty...
#
# mode 1 - just process $GPMRC (16=9600,32=19.2,48=38.4,65=57.6,80=115.2) 128
#          Use slowest speed that holds all data in 1 sec.
#
# time1 = PPS time offset calibration 0.0 (cable delays, etc)
# time2 = Offet due to ASCII sentence (PPS ^----ASCII<cr><lf> <---End 4800 is ~600 msec
# stratum = 0
# refid = .GPS.
# flag1 = 1 for pps
# flag2 = 1 for pps deassertion
# flag3 = 1 use kernel PPS (vs. NTP adj PPS)
# flag4 = 1 remove location from timecode
#
server 127.127.20.0 mode 1  prefer
fudge  127.127.20.0 time1 0.000 time2 0.643 refid GPPS flag1 1 flag2 0 flag4 1

# Allow peer and query from peers

restrict 192.168.20.148 kod nomodify notrap
restrict 192.168.148.10 kod nomodify notrap
restrict 192.168.148.136 kod nomodify notrap

restrict -6 2001: kod nomodify notrap
restrict -6 2001:kod nomodify notrap
restrict -6 2001:kod nomodify notrap

peer 192.168.208.148
peer 192.168.148.10
peer 192.168.148.136
peer 2001:
peer 2001:
peer 2001:

pool 2.us.pool.ntp.org iburst
pool 2.us.pool.ntp.org iburst

# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details.  The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
# might also be helpful.
#
# Note that "restrict" applies to both peers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

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

# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust


# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
#broadcast 192.168.123.255

# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines.  Please do this only if you trust everybody on the network!
#disable auth
#broadcastclient


And, in case it's helpful, here's the rest of my configuration:

Code: Select all
lrwxrwxrwx 1 root root 7 Dec 31  1969 /dev/gps0 -> ttyAMA0
lrwxrwxrwx 1 root root 4 Jan 31 14:37 /dev/gpspps0 -> pps0
crw-rw---T 1 root dialout 204, 64 Feb  3 07:15 /dev/ttyAMA0
crw-rw---T 1 root dialout 251, 0 Jan 31 14:37 /dev/pps0


Code: Select all
stty -F /dev/gps0
speed 4800 baud; line = 0;
intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>; eof = <undef>; start = <undef>; stop = <undef>; susp = <undef>;
rprnt = <undef>; werase = <undef>; lnext = <undef>; flush = <undef>;
ignbrk -brkint -imaxbel
-opost -onlcr
-isig -iexten -echo -echoe -echok -echoctl -echoke


Code: Select all
ntpq -c ass

ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 30570  973a   yes   yes  none  pps.peer    sys_peer  3
  2 30571  9024   yes   yes  none    reject   reachable  2
[...truncated]
 ntpq -c "cv 30570"
associd=30570 status=0000 , no events, clk_unspec,
device="NMEA GPS Clock",
timecode="$GPRMC,122111,A,____.____,N,_____.____,W,000.0,253.4,030213,014.6,W*__",
poll=2661, noreply=0, badformat=0, baddata=0, fudgetime1=0.000,
stratum=0, refid=GPPS, flags=9


Code: Select all
ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
o127.127.20.0    .GPPS.           0 l   16   64  377    0.000    0.009   0.002
 192.168.208.148 192.168.148.43   2 u   36   64  377    1.196    0.010   0.070
 192.168.148.10  192.168.148.43   2 u   43   64  376    0.674    0.006   2.042
+192.168.148.136 146.51.136.107   2 u    8   64  377    0.505    0.064   0.024
 2001:: 192.168.148.43   2 u  185 1024    0    0.000    0.000   0.000
 2001: .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 2001:: 146.51.136.107   2 u   13   64  377    0.672    0.112   0.141
-2001:470:d821:: 216.218.254.202  2 u   16   64  377   94.970    4.163   2.865
+2001:4f8:fff7:1 66.220.9.122     2 u   57   64  357  119.841   -0.178   9.585
-2600:3c03::2e:3 64.90.182.55     2 u   26   64  377   44.771   11.459   0.098
-2600:3c01::2:21 127.67.113.92    2 u    4   64  377  112.395   -4.006   0.940
-216.66.0.142    130.207.244.240  2 u   22   64  377   39.787    1.557   0.444
+64.95.243.61    192.5.41.209     2 u    9   64  377   44.961   -0.081   0.040
-173.244.211.10  204.42.158.152   2 u    9   64  377   99.274    2.818   0.530
-206.225.93.63   148.167.132.200  3 u   28   64  377   82.505   -1.095   0.367


Code: Select all
 cat /etc/udev/rules.d/80-gps-for-ntp.rules
KERNEL=="ttyAMA0", SUBSYSTEM=="tty", DRIVER=="", SYMLINK+="gps0", GROUP="dialout", MODE="0660"
# Symlink /dev/pps0 to /dev/gpspps0
KERNEL=="pps0", SUBSYSTEM=="pps", DRIVER=="", SYMLINK+="gpspps0", GROUP="dialout", MODE="0660"
Posts: 24
Joined: Sun Jan 27, 2013 5:28 pm