Raspberry Pi • View topic

by **aquarat** » Mon Aug 27, 2012 4:02 pm

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).

by **Paul Kennedy** » Mon Aug 27, 2012 4:04 pm

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....

by **aquarat** » Mon Aug 27, 2012 4:07 pm

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.

by **aquarat** » Mon Aug 27, 2012 8:53 pm

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.

by **aquarat** » Mon Aug 27, 2012 10:00 pm

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 ?

by **Paul Kennedy** » Tue Aug 28, 2012 1:19 am

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.

by **aquarat** » Tue Aug 28, 2012 7:46 am

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.

by **aquarat** » Tue Aug 28, 2012 9:01 am

Pic : (hosted on a pi)

by **Paul Kennedy** » Tue Aug 28, 2012 9:33 am

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

by **aquarat** » Tue Aug 28, 2012 9:48 am

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'

by **Paul Kennedy** » Tue Aug 28, 2012 9:54 am

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?

by **aquarat** » Tue Aug 28, 2012 10:19 am

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

by **Paul Kennedy** » Tue Aug 28, 2012 11:06 am

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?

by **aquarat** » Tue Aug 28, 2012 12:31 pm

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 ?

by **Paul Kennedy** » Tue Aug 28, 2012 12:55 pm

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.

by **aquarat** » Tue Aug 28, 2012 4:41 pm

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).

by **aquarat** » Tue Aug 28, 2012 10:39 pm

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.

by **Paul Kennedy** » Wed Aug 29, 2012 1:13 am

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 :cry:

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.

by **aquarat** » Wed Aug 29, 2012 9:25 am

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).

by **Paul Kennedy** » Wed Aug 29, 2012 10:40 am

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.

by **Paul Kennedy** » Wed Aug 29, 2012 11:23 am

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

by **aquarat** » Wed Aug 29, 2012 11:36 am

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.

by **Paul Kennedy** » Wed Aug 29, 2012 4:14 pm

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

by **aquarat** » Wed Aug 29, 2012 7:51 pm

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.

by **Paul Kennedy** » Fri Aug 31, 2012 4:32 pm

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.

NTP PPS

Who is online