NTP PPS

[aquarat]

The results from your new config :

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
xGPS_NMEA(0)     .GPS.            0 l    7    8    3    0.000   -0.438   0.057
xPPS(0)          .PPS.            0 l    6    8    3    0.000   -0.415   0.047

I tried setting minpoll to 1 a while back it in the debugging output it said 3 was the minimum (just out of interest).

[Paul Kennedy]

btw what version of ntp are you running? i saw some chatter about a custom build above.

looks like you are getting close now. i would have thought it would have kicked in by now, so something must be up.

i would keep the polling fast.


there are a couple more things to chase down if it does not settle.

1. what NMEA sentences is your gps unit using?
2. do you have a drift file?
3. if you run ntpd in user land, you can set a -d2 option which is a very verbose debug output. it might well assist.

sleep time for me. back tomorrow....

[aquarat]

I compiled :
ntpd 4.2.6p5
ntpd 4.2.6p5@1.2349 Fri Aug 24 17:26:25 UTC 2012 (1)
This seems like a good time to switch to IRC . I've been meaning to give the rasp irc channel a try... using a client running on a Pi of course.

I've just started compiling 4.2.6p3 with --enable-all-clocks --enable-ATOM and --enable-NMEA.

[aquarat]

The result of installing and running ntpd 4.2.6p3 :

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
xGPS_NMEA(0)     .GPS.            0 l    -    8  377    0.000    0.644   0.048
xPPS(0)          .PPS.            0 l    7    8  377    0.000    0.656   0.039

NTPd selects the NMEA source so long as the PPS isn't detected/isn't initialised. As soon as PPS's values in ntpq -p are populated both source get an 'x'.

I'll give the current dev version of ntpd a try.

[aquarat]

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
xGPS_NMEA(0)     .GPS.            0 l    1    8   17    0.000   -4.269   2.552
xPPS(0)          .PPS.            0 l    8    8    7    0.000   -5.375   1.827

ntp-dev-4.2.7p295 does the same thing.

This is the debugging output :

Code: Select all

ntpd -gdn
27 Aug 23:57:49 ntpd[29180]: ntpd 4.2.7p295@1.2483-o Mon Aug 27 21:41:49 UTC 2012 (1): Starting
27 Aug 23:57:49 ntpd[29180]: proto: precision = 1.999 usec (-19)
27 Aug 23:57:49 ntpd[29180]: minpoll: provided value (1) is out of range [3-255])
Finished Parsing!!
move_fd: estimated max descriptors: 1024, initial socket boundary: 16
27 Aug 23:57:49 ntpd[29180]: Listen and drop on 0 v4wildcard 0.0.0.0:123
27 Aug 23:57:49 ntpd[29180]: Listen normally on 1 lo 127.0.0.1:123
restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00003000 flags 00000001
27 Aug 23:57:49 ntpd[29180]: Listen normally on 2 eth0 10.0.0.21:123
restrict: op 1 addr 10.0.0.21 mask 255.255.255.255 mflags 00003000 flags 00000001
27 Aug 23:57:49 ntpd[29180]: peers refreshed
27 Aug 23:57:49 ntpd[29180]: Listening on routing socket on fd #19 for interface updates
restrict: op 1 addr 0.0.0.0 mask 0.0.0.0 mflags 00000000 flags 000005d0
27 Aug 23:57:49 ntpd[29180]: restrict: ignoring line 66, mask '::' unusable.
restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00000000 flags 00000000
restrict: op 1 addr ::1 mask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff mflags 00000000 flags 00000000
key_expire: at 0 associd 56584
peer_clear: at 0 next 1 associd 56584 refid INIT
refclock_setup fd 5 modem status: 0x26
refclock_ioctl: fd 5 flags 0x1
event at 0 GPS_NMEA(0) 8011 81 mobilize assoc 56584
newpeer: 127.0.0.1->127.127.20.0 mode 3 vers 4 poll 3 3 flags 0x129 0x1 ttl 16 key 00000000
key_expire: at 0 associd 56585
peer_clear: at 0 next 2 associd 56585 refid INIT
event at 0 PPS(0) 8011 81 mobilize assoc 56585
newpeer: 127.0.0.1->127.127.22.0 mode 3 vers 4 poll 3 3 flags 0x9 0x1 ttl 0 key 00000000
event at 0 0.0.0.0 c01d 0d kern kernel time sync enabled
event at 0 0.0.0.0 c012 02 freq_set kernel -51.679 PPM
event at 0 0.0.0.0 c016 06 restart
GPS_NMEA(0) gpsread: 14 '$PGTOP,11,2*6E'
GPS_NMEA(0) gpsread: 72 '$GPGGA,215749.000,3350.9291,S,01840.0259,E,1,10,0.87,111.4,M,32.7,M,,*75'
GPS_NMEA(0) processing 72 bytes, timecode '$GPGGA,215749.000,3350.9291,S,01840.0259,E,1,10,0.87,111.4,M,32.7,M,,*75'
GPS_NMEA(0) effective timecode: 2012-08-27 21:57:49
GPS_NMEA(0) using '$GPGGA,215749.000,3350.9291,S,01840.0259,E,1,10,0.87,111.4,M,32.7,M,,*75'
GPS_NMEA(0) gpsread: 60 '$GPGSA,A,3,03,19,06,11,16,07,23,13,01,08,,,1.21,0.87,0.84*04'
GPS_NMEA(0) gpsread: 68 '$GPGSV,4,1,13,19,76,139,15,07,66,222,31,11,45,018,21,03,44,136,29*78'
GPS_NMEA(0) gpsread: 68 '$GPGSV,4,2,13,13,37,311,17,06,29,134,25,08,26,221,27,16,23,106,17*7D'
GPS_NMEA(0) gpsread: 66 '$GPGSV,4,3,13,01,22,013,21,23,18,343,18,28,02,262,,30,02,088,19*7E'
GPS_NMEA(0) gpsread: 22 '$GPGSV,4,4,13,49,,,*76'
GPS_NMEA(0) gpsread: 33 '$GPZDA,215749.000,27,08,2012,,*56'
GPS_NMEA(0) processing 33 bytes, timecode '$GPZDA,215749.000,27,08,2012,,*56'
GPS_NMEA(0) effective timecode: 2012-08-27 21:57:49
select() returned -1: Interrupted system call
refclock_transmit: at 1 127.127.20.0
refclock_receive: at 1 127.127.20.0
event at 1 GPS_NMEA(0) 8024 84 reachable
refclock_sample: n 1 offset -0.000806 disp 0.000000 jitter 0.000002
filegen  2 3555093470
clock_filter: n 1 off -0.000806 del 0.000000 dsp 7.937501 jit 0.000002
select: combine offset -0.000806500 jitter 0.000001907
event at 1 GPS_NMEA(0) 903a 8a sys_peer
clock_update: at 1 sample 1 associd 56584
event at 1 0.0.0.0 c415 05 clock_sync
filegen  2 3555093470
local_clock: offset -0.000806500 jit 0.000285146 freq -51.679 stab 0.000 poll 3
filegen  2 3555093470
auth_agekeys: at 1 keys 0 expired 0
GPS_NMEA(0) gpsread: 14 '$PGTOP,11,2*6E'
GPS_NMEA(0) gpsread: 72 '$GPGGA,215750.000,3350.9290,S,01840.0259,E,1,10,0.89,111.4,M,32.7,M,,*72'
GPS_NMEA(0) processing 72 bytes, timecode '$GPGGA,215750.000,3350.9290,S,01840.0259,E,1,10,0.89,111.4,M,32.7,M,,*72'
GPS_NMEA(0) effective timecode: 2012-08-27 21:57:50
GPS_NMEA(0) using '$GPGGA,215750.000,3350.9290,S,01840.0259,E,1,10,0.89,111.4,M,32.7,M,,*72'
^C27 Aug 23:57:50 ntpd[29180]: ntpd exiting on signal 2 (Interrupt)
event at 1 0.0.0.0 041d 0d kern kernel time sync disabled

Later on this gets repeated quite a lot :

Code: Select all

GPS_NMEA(0) effective timecode: 2012-08-27 21:58:59
select() returned -1: Interrupted system call
refclock_transmit: at 26 127.127.22.0
refclock_receive: at 26 127.127.22.0
refclock_sample: n 8 offset -0.000514 disp 0.000000 jitter 0.000012
filegen  2 3555093540
clock_filter: n 4 off -0.000514 del 0.000000 dsp 0.937595 jit 0.000285

The interrupted system call could be something ?

[Paul Kennedy]

Hi,
thanks for the debug dump. This helps. I can see your GPS is talking multiple sentences.

At present, I see GGA, GSV, ZDA, PGTOP being output.

I believe the NMEA clock driver only holds the current sentence in memory. As you have not told NTP to decode any specific message, it is probably rotating through them and getting confused.

1. To make life simple, I would go to your GPS, and disable all sentences other than 1 - preferably ZDA. I have found this really helps on our windows boxes.

http://www.eecis.udel.edu/~mills/ntp/ht ... ver20.html

2. You then need to change your ntp.conf mode directive to match ZDA, thus:

Code: Select all

server 127.127.20.0 mode 19 minpoll 3 maxpoll 3 iburst prefer #use ZDA only!
fudge 127.127.20.0 flag1 1 time2 0.400

server 127.127.22.0 minpoll 1 
fudge 127.127.22.0 flag1 1 flag3 1

Making the NMEA feed as simple as possible will help us nail this down.

BTW, I have been here before...
https://lists.ntp.org/pipermail/bugs/20 ... 09405.html

I really need to get hold of a GPS so I can match your excellent progress.

[aquarat]

I disconnected the GPS while ntpd was running, reconfigured the GPS (using an x86 win32 exe) and connected it again. All sentences were disabled except ZDA and PGTOP (which the software won't let me disable). Hopefully it'll stay like this :

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
xGPS_NMEA(0)     .GPS.            0 l    1    8   17    0.000    0.081   0.013
*PPS(0)          .PPS.            0 l    7    8  377    0.000    0.075   0.028
+10.0.0.8        .PPS.            1 u   55   64  377    0.505   -0.046   0.092

*/me restarts ntpd*

This is the result after running for 2 minutes with mode 16:

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
xGPS_NMEA(0)     .GPS.            0 l    3    8  377    0.000    0.008   0.129
xPPS(0)          .PPS.            0 l    2    8  377    0.000    0.007   0.128
 10.0.0.8        .PPS.            1 u    1   64    3    0.510   -0.036   0.296

and mode 19 :

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 GPS_NMEA(0)     .GPS.            0 l    -    8    0    0.000    0.000   0.000
 PPS(0)          .PPS.            0 l    7    8    1    0.000   -0.128   0.002
*10.0.0.8        .PPS.            1 u   10   64   17    0.496   -0.148   0.051

The ntp debugging output for mode 19 :

Code: Select all

GPS_NMEA(0) gpsread: 33 '$GPZDA,074315.000,28,08,2012,,*51'
select() returned -1: Interrupted system call
refclock_transmit: at 90 127.127.22.0
GPS_NMEA(0) gpsread: 14 '$PGTOP,11,2*6E'
GPS_NMEA(0) gpsread: 33 '$GPZDA,074316.000,28,08,2012,,*52'
select() returned -1: Interrupted system call
GPS_NMEA(0) gpsread: 14 '$PGTOP,11,2*6E'
GPS_NMEA(0) gpsread: 33 '$GPZDA,074317.000,28,08,2012,,*53'
select() returned -1: Interrupted system call
GPS_NMEA(0) gpsread: 14 '$PGTOP,11,2*6E'
GPS_NMEA(0) gpsread: 33 '$GPZDA,074318.000,28,08,2012,,*5C'
select() returned -1: Interrupted system call
GPS_NMEA(0) gpsread: 14 '$PGTOP,11,2*6E'
GPS_NMEA(0) gpsread: 33 '$GPZDA,074319.000,28,08,2012,,*5D'
select() returned -1: Interrupted system call
GPS_NMEA(0) gpsread: 14 '$PGTOP,11,2*6E'
GPS_NMEA(0) gpsread: 33 '$GPZDA,074320.000,28,08,2012,,*57'

Thanks for your help so far .

RE GPS; I bought 5 of the Adafruit units... I've only connected one up until now and it has been amazing (particularly re-use of the ttyAMA0 pins without an adaptor). It's just a pitty the configuration utility is an x86 win32 programme. I'm thinking of using one linked to a Pi for driving statistics (a fancy GPS logger). mmm I'll upload a pic shortly.

[aquarat]

Pic : (hosted on a pi)

[Paul Kennedy]

Hi, my bad. I gave the the incorrect bit field. This snippet is from our standard conf file...

Code: Select all

####RS232 BASED REFERENCE CLOCKS####################################
#The mode field is a bitwise value which is the combination of DATAGRAM+BAUD
#e.g. if you have a DATAGRAM=ZDA, BAUD=38400 the mode is 8+48 so you need to specify 'mode 56'
#DATAGRAM: RMC=1, GGA=2, GLL=4, ZDA=8
#BAUD: 4800=0, 9600=16, 19200=32, 38400=48, 57600=64, 115200=80
#server 127.127.20.1 mode 56
#fudge 127.127.20.1 flag1 1 time2 0.123 

so you need this...

Code: Select all

server 127.127.20.0 mode 24 minpoll 3 maxpoll 3 iburst prefer #use ZDA only!
fudge 127.127.20.0 flag1 1 time2 0.400

server 127.127.22.0 minpoll 1 
fudge 127.127.22.0 flag1 1 flag3 1

I am still a little nervous with the $PGTOP sentences, but there is not much you can do right now.

I note you have recompiled ntp. check the sources for refclock_nmea.c and make sure if mentions ZDA. Early versions of NTP only supported RMC.

http://opensource.apple.com/source/ntp/ ... ock_nmea.c

The photo of you unit is inspiring me to get hold of my GPS. Good stuff

[aquarat]

Just tried, both PPS and GPS are marked with an x (false ticker?).

The debugging output indicates something has changed :

Code: Select all

GPS_NMEA(0) gpsread: 33 '$GPZDA,094800.000,28,08,2012,,*50'
GPS_NMEA(0) processing 33 bytes, timecode '$GPZDA,094800.000,28,08,2012,,*50'
GPS_NMEA(0) effective timecode: 2012-08-28 09:48:00
GPS_NMEA(0) using '$GPZDA,094800.000,28,08,2012,,*50'

[Paul Kennedy]

Good. It looks like it is now taking hold of the ZDA. You are really close. I need to think why on earth it is not happy. Maybe remove the fudge 0.400?

[aquarat]

Done @ remove fudge... now I'm getting confused :

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
xGPS_NMEA(0)     .GPS.            0 l    7    8  377    0.000  902.809 484.651
xPPS(0)          .PPS.            0 l    6    8  377    0.000   -0.024   0.022
 10.0.0.8        .PPS.            1 u   40   64    7    0.468  1001.72   0.088

[Paul Kennedy]

Hi
this is ok. We are now getting a better idea of the difference between the NMEA sentence and the PPS pulse. If there is a big difference, NTP will reject both refclocks (due to ambiguity). Therefore, you now need to figure out what the actual difference is. When they line up, NTP will be in a happy place.

(search for 'difference' here...)
http://support.ntp.org/bin/view/Support ... ARefclocks

There are many ways to accomplish this. I mentioned 1 in an earlier post. Here are 2 more ways we have used...

1. Ask the GPS manufacturer when the ZDA sentence is shipped relative to PPS
2. Get a 2 channel oscilloscope, hook 1 channel to the PPS, and the other to the RS232 line. You will be able to line them up in the scope and measure the difference. It is pretty easy to do and gives you a cast iron visual inspection.

for now, I would start increasing the fudge in steps of 0.1. I am pretty sure it will kick in.

Q:how did you manage to drop an image into the forum?

[aquarat]

That's a fantastic idea @ Oscilloscope, I'll give it a try a little later (just got a digital Oscilloscope recently and have enjoyed using it on other projects... I used to use an analog oscilloscope before that).

I have noticed that sometimes NTPd shows the offsets between the PPS and NMEA as only a few ms apart but sometimes the offset is much larger... eg. a second. Perhaps the NMEA and PPS signals are very close together but the PPS sometimes falls into the previous second ?

[Paul Kennedy]

Hi, yes, that is exactly what is happening. It is not sure who to believe right now. Scoping will remove an unknown form the dilemma.

good luck.

[aquarat]

Hi Paul

Here are some screenshots of the PPS (yellow) vs the NMEA (blue 9600bps).


and


I haven't worked out how to offset two inputs on this oscilloscope... I haven't read the manual (todo list ).

And to answer your question from earlier I insert images into my posts by first putting them on a webserver (a Pi) and then linking to the image using the [i.mg][/i.mg] tags (without the fullstops).

[aquarat]

Based on what I saw on the oscilloscope I fudged time2 on the GPS by -0.650. It seems this is the wrong direction, but the results are still interesting :

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
xGPS_NMEA(0)     .GPS.            0 l    8    8  377    0.000    0.026   3.353
xPPS(0)          .PPS.            0 l    7    8  377    0.000    0.026   0.002
 10.0.0.8        .PPS.            1 u    7   64    7    0.489  1000.00   0.035

The PPS and NMEA are almost exactly aligned and together they're exactly 1 second off from 10.0.0.8 (GPS+OCXO).

I watched ntpq -p; shortly after startup ntp selected the NMEA source over 10.0.0.8... but as soon as the PPS became available ntp marked both the PPS and NMEA as falsetickers.

Fudging the NMEA source by time2 0.350 (1000-650ms) gives this result :

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*GPS_NMEA(0)     .GPS.            0 l    1    8   17    0.000  -42.863  46.319
+PPS(0)          .PPS.            0 l   23    8    4    0.000    0.071   0.002
 10.0.0.8        .PPS.            1 u   31   64    1    0.503  -33.958   0.002

Is it working?!? ... I'll wait a bit... and now (about 3 minutes later) :

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
xGPS_NMEA(0)     .GPS.            0 l    -    8  377    0.000  -33.391   1.749
xPPS(0)          .PPS.            0 l    6    8  377    0.000  -33.307   2.115
 10.0.0.8        .PPS.            1 u    4   64    7    0.486  -33.441   3.883

And another three minutes :

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*GPS_NMEA(0)     .GPS.            0 l    1    8  377    0.000   37.157   7.739
+PPS(0)          .PPS.            0 l    7    8  377    0.000   36.274   7.915
+10.0.0.8        .PPS.            1 u   23   64  177    0.483  -20.318  29.629

And another three minutes (I moved the GPS slightly closer to the roof for a better signal) :

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
xGPS_NMEA(0)     .GPS.            0 l    4    8  377    0.000   63.857   7.949
xPPS(0)          .PPS.            0 l    2    8  377    0.000   64.298   7.745
x10.0.0.8        .PPS.            1 u   10   64  377    0.483  -20.318  48.989

I think the issue now is that the GPS doesn't have great view of the sky and as a result it's PPS probably waivers. Currently both the NMEA and PPS are 70ms off from 10.0.0.8's time. I'll leave it overnight and see what happens.

[Paul Kennedy]

ok. thanks for the tip on the images. I will do likewise.

A few things to try and nail this...

1. It looks like you have a server on your LAN at 10.0.0.8 I would make it update quicker so you can debug faster. I would dalos make it no select so we can focus on the NMEA + PPS (my guess is you will shutdown the 10.0.0.8 eventually)

Code: Select all

server 10.0.0.8 minpoll 3 maxpoll 3 iburst noselect

2. I re-read the PPS help page, and your fudge factors might be causing you grief. Check out the help at: http://www.eecis.udel.edu/~mills/ntp/ht ... ver22.html
you can remove flag1 and I would flip flag3 as follows:

Code: Select all

server 127.127.20.0 mode 24 minpoll 3 maxpoll 3 iburst prefer #use ZDA only!
fudge 127.127.20.0 flag1 1 time2 0.350

server 127.127.22.0 minpoll 3 maxpoll 3 
fudge 127.127.22.0  flag3 0

server 10.0.0.8 minpoll 3 maxpoll 3 iburst noselect #set to monitor only.

3. The images of the scope are interesting. It would appear the PPS pulse has quite a long duration (it looks like 50 millisecs). GPS units I am familiar with are just a few microseconds in duration (which sometimes causes problems with RS232 interfacing as the uart chip fails to pick it up)

4. The scope indicates the RS232 data consumes almost the entire second. It would be good to remove the $PGTOP sentence. I would chase up adafruit on this.

5. As an alternative approach (for debug purposes), you could use the 10.0.0.8 to get the seconds...

Code: Select all

#skip the NMEA output for now...
#server 127.127.20.0 mode 24 minpoll 3 maxpoll 3 iburst prefer #use ZDA only!
#fudge 127.127.20.0 flag1 1 time2 0.350

server 127.127.22.0 minpoll 3 maxpoll 3 
fudge 127.127.22.0  flag3 0

server 10.0.0.8 minpoll 3 maxpoll 3 iburst 

sureelectronics 'lost' my order, so I am more than a week away from getting hold of a GPS I now expose the results of ntpq in my pi web 'advanced' page at: http://secondthoughts.no-ip.org. It is kind of nice to see the quality in a web page.

[aquarat]

It's quite strange, this is what's output per second :

Code: Select all

$PGTOP,11,2*6E
$GPZDA,085126.000,29,08,2012,,*5C

The GPS software indicates that only about 5% of the bandwidth is in use. 49 characters are present, so 392 bits / 9600 bits = ~4%

Your website's very cool, it's nice the way you explain everything and the page layout is minimalist but pleasing.

Unfortunately the additional tweaks you've suggested haven't changed anything :/ . It's my plan that the Pi will eventually replace 10.0.0.8 (although .8 will still be around I'll turn it off part of the time).

[Paul Kennedy]

Hmm,
To make more progress, I really need to get a gps hooked up to my pi, so right now there is not much more I can do. If my sure GPS works out of the box, we can then figure why you have trouble.

Thanks for the feedback on the web page. I will tinker some more in the evenings, but it pretty much fits with my original requirement.

[Paul Kennedy]

hi, one more thing to try...
I note both NMEA and PPS appear as stratum0 devices. NTP may be getting confused as they are not co-incident, and both claim to be excellent. maybe set the nmea to a lower stratum, eg 2?

worth a quick try

[aquarat]

Yes it's very strange. I've tried fudging the NMEA source to stratum 3... both sources are still makred with an 'x' I'm going to try the ntp IRC channel on FreeNode.

[Paul Kennedy]

Fair enough. Dont forget to post if you get it solved!
Tonight, I made a small experimental page to plot the differences between the reference clocks with the aim of trying to better understand their relationships. I plot the offset, jitter and delays.
I am hosting it on my pi at:
http://secondthoughts.no-ip.org/page-peerstats.php

[aquarat]

I've just bought a Motorola Oncore UT+ GPS... I'm going to give that a quick try.

Your new graphs page is super cool by the way, well done.

[Paul Kennedy]

Hi,
One of the 2 gps units turned up tonight. unfortunately it was the USB dongle from globalsat...

http://www.globalsat.co.uk/product_page ... ND100S.htm

1. Plug it into the USB port in the pi.
2.make sure it works...

Code: Select all

stty -F /dev/ttyUSB0 ispeed 4800 && cat < /dev/ttyUSB0
$GPGLL,3152.2928,S,11545.2270,E,160855.000,A,A*4C
$GPGSA,A,3,29,27,25,14,02,04,,,,,,,2.6,1.1,2.4*3A
$GPRMC,160855.000,A,3152.2928,S,11545.2270,E,0.00,,310812,,,A*6C
$GPGGA,160856.000,3152.2928,S,11545.2270,E,1,05,1.3,9.8,M,-29.5,M,,0000*6F
$GPGLL,3152.2928,S,11545.2270,E,160856.000,A,A*4F
$GPGSA,A,3,29,27,14,02,04,,,,,,,,3.0,1.3,2.8*34
$GPGSV,3,1,10,12,60,154,,09,49,020,,29,48,288,27,02,46,105,35*7B
$GPGSV,3,2,10,25,44,220,,27,31,024,30,14,22,260,24,04,15,135,31*7E
$GPGSV,3,3,10,05,,055,,31,,217,22*7B
$GPRMC,160856.000,A,3152.2928,S,11545.2270,E,0.00,,310812,,,A*6F
$GPGGA,160857.000,3152.2928,S,11545.2270,E,1,05,1.3,9.8,M,-29.5,M,,0000*6E

3.Make a symbolic link so the ntp driver can find it

Code: Select all

sudo ln ttyUSB0 gps1

4. Edit the ntp conf thus (I had to apply a fudge as the NMEA data arrives 465 milliseconds late)...

Code: Select all

server 127.127.20.1 mode 1 minpoll 3 maxpoll 4 prefer
fudge 127.127.20.1 time2 0.466 stratum 2 refid NMEA

5. restart ntp

Code: Select all

sudo /etc/init.d/ntp restart

and watch it settle....

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*GPS_NMEA(1)     .NMEA.           2 l   15   16  377    0.000    2.819   3.666
-dns.iinet.net.a 216.218.254.202  2 u    6   16  377   19.997   -1.188   0.938
-time02.syd.optu 193.67.79.202    2 u    5   16  377   81.182   19.442   0.596
-yarrina.connect 130.95.179.80    2 u   12   16  377   61.455    5.985   1.871
+warrane.connect 130.95.179.80    2 u   11   16  377   73.620    3.322   1.842
+elysium.uwa.edu 130.95.179.80    2 u    2   16  377   20.507    5.547   1.187

You can see it live at:
http://secondthoughts.no-ip.org/page-ntpqc.php

I am not all that impressed with the noise level, but then again it is a $20 USB gps. Still, I was wanting to see if it could be useful for work. At this stage, I doubt it. I need to chase up the manufacturers to see if I can change the firmware.

So to summarize, it was pretty simple to get the NMEA hooked up, but the results were less than stellar. At this stage I am getting +/-5 millisecs. Not bad, but nothing outstanding either. However, if I lose the big spikes I sometimes see from the internet servers, I would consider this an improvement.