[aprssig] gpsd and ntpd

Andrew Rich vk4tec at tech-software.net
Fri Mar 15 18:57:27 EDT 2013


Perfect - thank you !

----- Original Message ----- 
From: "Alex Carver" <kf4lvz at yahoo.com>
To: <aprssig at tapr.org>
Sent: Saturday, March 16, 2013 7:29 AM
Subject: Re: [aprssig] gpsd and ntpd


> Message: 18

> Date: Fri, 15 Mar 2013 09:19:50 -0500
> From: Joe Bennett <aprs at ka3nam.com>
> To: TAPR APRS Mailing List <aprssig at tapr.org>
> Subject: Re: [aprssig] gpsd and ntpd
> Message-ID: <51432E06.6000407 at ka3nam.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Yes, GPSD manages the GPS and NTP uses a shared memory resource to
> integrate with GPSD. Without any decent testing, I'll grant that there
> has to be some indeterministic processing time involved, but it can
> certainly keep things well under 1 ms. Some others on the net have
> claimed the configuration can keep things under 100 us but I personally
> have not seen that (it may be the hardware I'm using). Typically 500 us
> to 1000 us... Can't get that with NTP alone... Good enough for me and
> what I need to do with it...
>
> Other than searching the net and finding the multitude of ways that
> others have tried, I have a doc that I can share that shows how I did it
> via Ubuntu server 10.04. I'll see if I get some time to post it on the
> web...

I use it on my internal time server and get better than 100 us timekeeping. 
There are multiple options available depending on the configuration.

First, ntpd can read NMEA strings directly from the GPS so technically gpsd 
isn't required if the receiver is sending out NMEA. The PPS signal is 
attached somewhere else (on the raspberry it's going to be one of the GPIO 
pins but on a normal machine it's the DCD line of the serial port where the 
GPS is attached).

You configure the NMEA driver using the type 20 reference clock:

server 127.127.20.n (n is the serial port number starting from zero to match 
/dev/gpsn which would be symlinked to the serial port)

Normally the NMEA driver looks at DCD to find the PPS pulse and use it but 
that won't work on the raspberry pi.

Using gpsd makes it possible to use SiRF based receivers. Timing is a bit 
more accurate when using the SiRF data because more messages are available 
and the data rate is faster (sometimes up to 115kBaud instead of 9600 Baud 
for NMEA). The data arrives in ntpd by the shared memory clock Type 28. 
There are two shared memory segments available, 0 and 1. Zero contains the 
time, one contains a PPS timestamp if gpsd can detect the PPS pulse (it 
won't find it on the raspberry because it's looking for PPS on DCD not a 
GPIO).

Configuration of ntpd then becomes:

server 127.127.28.0
server 127.127.28.1 (if the PPS is going to be used from gpsd).

There's a third clock type 22 that is just PPS. You have a symlink from 
/dev/ppsn to the location of the PPS signal and then add the driver:

server 127.127.22.n (again note the n to match /dev/ppsn)

Now ntpd will directly use the PPS signal and collect timestamps from any 
other servers. You can use gpsd or direct NMEA and still use the PPS driver 
which is how you can get the PPS into ntpd on the raspberry pi (since it 
comes in via another port).

_______________________________________________
aprssig mailing list
aprssig at tapr.org
http://www.tapr.org/mailman/listinfo/aprssig


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 2641/6155 - Release Date: 03/07/13
Internal Virus Database is out of date.





More information about the aprssig mailing list