tlhackque
Posts: 25
Joined: Sun Jan 27, 2013 5:28 pm

Re: NTP PPS

Sun Feb 03, 2013 2:24 pm

I looked at the tech specs for the "Adafruit Ultimate GPS Breakout - 66 channel w/10 Hz updates - Version 3".

It does appear that the default signalling rate is 9600. So use mode 17.

Also, I saw that one of the tutorials for the device said to connect the device to +5V. DON'T DO THAT.

The tech specs say it's a 3.3V part; absolute max of 4.3V. Worse, the IO's of the GPS will drive to +5V - and the RPi can't tolerate that. (I reported this on the site.)

Be very sure you're using 3.3V.

ntPI
Posts: 17
Joined: Tue Jan 29, 2013 2:39 pm

Re: NTP PPS

Sun Feb 03, 2013 2:31 pm

tlhackque wrote: 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.
Thanks tlhackque!

What I quoted above is exactly what fixed it. I should know better than to follow How-to's verbatim. There are always exceptions. It was late, I was tired :P

According to aquarat's post, he is using the same GPS module I am but I don't recall he ever said his was v3 where mine is.

In short, mode 17 is what I needed as this is running at 9600.

For those of you who that follow after with this GPS, if you want to reduce the sentences to just $GPRMC, the following command works.

Code: Select all

/bin/echo -e '$PMTK314,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*29\r\n' > /dev/ttyAMA0
If you don't have a battery (I do not, the solder pads on mine popped off), just add the above to /etc/rc.local

Now we're looking A LOT better. Now it's time (pun intended) to let it settle and see where I'm at in 48 hours.

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+tick.usno.navy. .IRIG.           1 u   39   64   17   64.152   -1.853   0.924
+ntp.okstate.edu .USNO.           1 u   36   64   17   48.746   -0.688   0.114
+navobs1.wustl.e .GPS.            1 u   36   64   17   50.449   -4.668   0.474
-tick.uh.edu     .GPS.            1 u   35   64   17   58.305    3.853   0.595
oGPS_NMEA(0)     .GPPS.           0 l    8    8  377    0.000   -0.787   0.070
And my, complete, ntp.conf, maybe it'll help someone googling...

Code: Select all

driftfile /var/log/ntpstats/ntp.drift
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

# Sanity Servers
server tick.usno.navy.mil
server ntp.okstate.edu
server navobs1.wustl.edu
server tick.uh.edu

restrict default nomodify noquery
restrict 127.0.0.1
restrict 10.1.1.0 mask 255.255.255.0 nomodify

server 127.127.20.0 mode 17 minpoll 3 iburst true prefer #use $GPRMC only!
fudge 127.127.20.0 flag1 1 time2 0.350 refid GPPS

ntPI
Posts: 17
Joined: Tue Jan 29, 2013 2:39 pm

Re: NTP PPS

Sun Feb 03, 2013 2:38 pm

tlhackque wrote:I looked at the tech specs for the "Adafruit Ultimate GPS Breakout - 66 channel w/10 Hz updates - Version 3".

It does appear that the default signalling rate is 9600. So use mode 17.

Also, I saw that one of the tutorials for the device said to connect the device to +5V. DON'T DO THAT.

The tech specs say it's a 3.3V part; absolute max of 4.3V. Worse, the IO's of the GPS will drive to +5V - and the RPi can't tolerate that. (I reported this on the site.)

Be very sure you're using 3.3V.
Yep, I used 3.3v for VIN.

ntPI
Posts: 17
Joined: Tue Jan 29, 2013 2:39 pm

Re: NTP PPS

Sun Feb 03, 2013 2:49 pm

One last note.

If you use:

Code: Select all

/bin/echo -e '$PMTK314,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*29\r\n' > /dev/ttyAMA0
I suggest you restart ntp after issuing that command. Mine started acting funny, offset starting going negative incrementally in my case when I didn't.

tlhackque
Posts: 25
Joined: Sun Jan 27, 2013 5:28 pm

Re: NTP PPS

Sun Feb 03, 2013 4:27 pm

Please read my whole previous post (and this one). Your config is not one I'd hold up as a good one for others to emulate. (Maybe you have specific reasons for ignoring the advice, but in that case you need to document them. People tend to blindly follow 'working' recipes.)

* setting true is a bad idea. It says 'believe this clock even if it appears to be insane'. You don't want to do that. The only reason for this would be if the NMEA time has large jitter & is the only souce. In that case, the PPS could be discarded by the selection/clustering algorithms. But true is probably a worse cure than the disease. If you are using the correct edge for PPS and are configured for a single sentence from the GPS, this situation should not occur. If you inherited this setting from your Garmin refclock, check that clock - you may be on the wrong edge, or have too many sentences configured for the configured serial line rate. Or, if you're using a USB to serial adapter, there can be issues.

* iburst is not for reference clocks. (http://www.eecis.udel.edu/~mills/ntp/html/assoc.html
There are two burst options where a single poll event triggers a burst. They should be used only with the server and pool commands, but not with reference clock drivers nor symmetric mode peers.
* Setting the poll interval for reference clocks is also not wise (same page):
The poll interval should not be modified for reference clocks
On the other hand, for your sanity servers, iburst is probably a good idea.

You don't have to use the low stratum reference clocks -
pool (your geo).ntp.org iburst preempt
is more neighborly - and won't impact your accuracy or startup time.

"The offset went funny after " (changing the sentences output) - that would indicate that the GPRMC wasn't the first sentence output (it usually is), and that you either weren't locked to PPS at the time, or that the length difference was more than 400 msec - ~500 chars at 9600bps. The PPS edge is associated with the end of the line containing the selected sentence. In any case, you need to readjust time2 after that change. (If GPRMC was first, you wouldn't.)

There is a lot of useful information on dave's site (quoted above) and on the http://support.ntp.org wiki. Anyone trying to replicate our results should refer to those authoritative sources.

Google turns up a lot of foklore / examples provided without context that can mislead...

ntPI
Posts: 17
Joined: Tue Jan 29, 2013 2:39 pm

Re: NTP PPS

Sun Feb 03, 2013 10:03 pm

I agree with most of what you posted except for my sanity clocks. Bear in mind that my ntp.conf was only posted for reference while troubleshooting (can't edit a post after so long it appears).

As far as the sanity clocks, I'm in the pool so I'd rather drop a stratum if I have troubles with the gps. I don't know what would happen if I became an ntppool consumer while trying to serve time in it. May cause a chicken and egg issue.

For reference (in case no one reads docs):

My current LINUX, not in the pool yet, ntp.conf:

Code: Select all

driftfile /var/log/ntpstats/ntp.drift
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

# Sanity Servers
server tick.usno.navy.mil iburst
server ntp.okstate.edu iburst
server navobs1.wustl.edu iburst
server tick.uh.edu iburst

restrict default nomodify noquery
restrict 127.0.0.1
restrict 10.1.1.0 mask 255.255.255.0 nomodify

server 127.127.20.0 mode 17 minpoll 3 prefer #use $GPRMC only!
fudge 127.127.20.0 flag1 1 time2 0.350 refid GPPS
My current BSD, in the pool, ntp.conf:

Code: Select all

epoch# cat /etc/ntp.conf
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

# Sanity Servers
server tick.usno.navy.mil
server ntp.okstate.edu
server navobs1.wustl.edu
server tick.uh.edu

# Garmin GPS 18 LVC
server  127.127.20.1    mode 0  minpoll 4 maxpoll 4   prefer
fudge   127.127.20.1    flag1 1  flag3 1 refid PPS

# By default we don't want eveyone to be able to query and modify
# the server. This is different from serving out NTP time to clients.
# Default set to nomodify noquery for everyone.
restrict default nomodify noquery
# Give localhost full access.
restrict 127.0.0.1
# Give subnet full access except modify.
restrict 10.1.1.0 mask 255.255.255.0 nomodify

technion
Posts: 238
Joined: Sun Dec 02, 2012 9:49 am

Re: NTP PPS

Sun Feb 03, 2013 11:48 pm

tlhackque wrote:I looked at the tech specs for the "Adafruit Ultimate GPS Breakout - 66 channel w/10 Hz updates - Version 3".

The tech specs say it's a 3.3V part; absolute max of 4.3V. Worse, the IO's of the GPS will drive to +5V - and the RPi can't tolerate that. (I reported this on the site.)

Be very sure you're using 3.3V.
Whilst that's true for the MTK3339 chipset itself, the breakout board provides differing details. Quoting from here:
http://learn.adafruit.com/downloads/pdf ... te-gps.pdf
Best of all, we added all the extra goodies you could ever want: a ultra-low dropout 3.3V
regulator so you can power it with 3.3-5VDC in, 5V level safe inputs
Mine's been online nearly two months using the 5V in. Looking at that range, I'm imagining either input would be fine.

tlhackque
Posts: 25
Joined: Sun Jan 27, 2013 5:28 pm

Re: NTP PPS

Mon Feb 04, 2013 2:57 am

Technicon - I didn't find the module manual when I looked for data on that GPS. Thanks for the pointer. You're correct that it says a 5V->3V LDO regulator is on-board. The extra conversion will consume some power, but not cause damage. Sorry for the false alarm.

ntPi - there is nothing special about servers in the pool. No special reason to worry about dependency ('chicken and egg') loops. NTP knows to avoid them (the reference ID is used for this - it's not just cosmetic.) If you happen to draw a server from the pool that used your server as its reference, that server will be ignored.

The only difference is in the pool itself - DNS is used to offer a different set of servers for each lookup. The NTP pool statement (with preempt) tells NTP to draw a set of servers; if after a while some don't work out, they're dropped & (usually) another set selected. (The details vary by version -- see the official NTP documentation & wiki.) But from an availablility/accuracy point of view, they're fine references.

Your PPS source, if it's sane, will be your reference because of its stratum, delay & dispersion. The offset will converge to the pool sources, which is close enough to validate the NMEA second and allow PPS to lock. And that makes you a stratum 1 server. If it fails - say a solar flare interrupts the PPS - , your server's stratum will drop to 1+ the selected pool source, and its time will eventually drift; any clients will detect this and do the right thing. And when the problem is corrected, NTP will do the right thing. Stratum is not a 'quality' or 'prestige' metric; it's one component of what goes into your server's accuracy. And although errors can accumulate as you get further from a reference clock, what really matters is accuracy as perceived by each client. Network effects usually dominate.

This gets a bit different if you peer with other sources - but I don't think USNO is going to peer with your GPS. If you peer, you generally want to do so with others at the same stratum, who use different reference sources, and are geographically close (in the network sense.)

The official documentation is rather thick reading, but it's worth doing if you're serious about providing good time. This is an area where intuition is often wrong. And unless you're very serious, the defaults will serve better than applying intuition/folklore to the configuration parameters. Lower strata are not necessarily 'better'; neither is more frequent polling. NTP is a bunch of filters and a feedback loop. A high stratum reference with low delay/dispersion will do better than a distant low stratum reference where the delay/dispersion vary. Consistency in a reference is more important that absolute values.

The official NTP website, support wiki and the time-nuts mailing list will can answer more questions.

At this point, I'm going to leave you to them. I'm glad you established communication with your GPS module and hope that you'll end up with an optimal configuration.

ntPI
Posts: 17
Joined: Tue Jan 29, 2013 2:39 pm

Re: NTP PPS

Wed Feb 06, 2013 8:03 pm

tlhackque wrote: ntPi - there is nothing special about servers in the pool. No special reason to worry about dependency ('chicken and egg') loops. NTP knows to avoid them (the reference ID is used for this - it's not just cosmetic.) If you happen to draw a server from the pool that used your server as its reference, that server will be ignored.
Thanks tlhackque, but I'm worried about the other direction. I am serving time in the pool. I'd rather drop stratum by syncing to another clock and still be able to serve time out.

Anyway, second GPS clock will be online this weekend for sanity/redundancy.

skavoovie5
Posts: 6
Joined: Wed Jan 16, 2013 6:33 am

Re: NTP PPS

Thu Feb 14, 2013 7:10 am

For those who are or will be using the Adafruit Ultimate GPS Module, yes, the module does safely power off of 5V or 3.3V, however I suggest running off 3.3V from the RasPi to the module's 3.3V pin.

I ran my setup for about 10 days via the 5V power GPIO connected to the GPS module's VIN pin, and observed jitter and offset.

I then switched it over to the 3.3V power GPIO pin and the 3.3V PIN on the GPS module and thus far have been running that for just over 24 hours. The difference is significant -- running via the 3.3V power has resulted in NTPd reporting far greater accuracy:.

Code: Select all

$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oGPS_NMEA(0)     .GPPS.           0 l    7    8  377    0.000   -0.001   0.001

Wondering if the accuracy difference is excess heat generated when powering via 5V. Others have demonstrated that heat can drastically affect accuracy.

technion
Posts: 238
Joined: Sun Dec 02, 2012 9:49 am

Re: NTP PPS

Fri Feb 15, 2013 11:28 am

Interesting.
Were you inside a box or sealed room or anything?

Code: Select all

pi@raspberrypi /media/linux $ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oGPS_NMEA(0)     .GPS.            0 l    3    8  377    0.000   -0.002   0.002
I'm running off the 5V rail and the above is typical for me. But then my pi is sitting in the open.

I'm still considering heat sinks to improve it further.

ntPI
Posts: 17
Joined: Tue Jan 29, 2013 2:39 pm

Re: NTP PPS

Fri Feb 15, 2013 4:52 pm

My final update.

I have two of these running, peered, using the adafruit v3 breakout.

First, the required pic link.
http://gallery.kulish.com/main.php?g2_itemId=5456

Code: Select all

root@hcpi001:~# ntpq -p | grep NMEA
oGPS_NMEA(0)     .GPS1.           0 l    4    8  377    0.000    0.000   0.001
root@hcpi002:~# ntpq -p | grep NMEA
oGPS_NMEA(0)     .GPS2.           0 l    3    8  377    0.000    0.000   0.001
NTP is running as a non-root user.

skavoovie5
Posts: 6
Joined: Wed Jan 16, 2013 6:33 am

Re: NTP PPS

Fri Feb 15, 2013 8:38 pm

technion wrote:Interesting.
Were you inside a box or sealed room or anything?

I'm running off the 5V rail and the above is typical for me. But then my pi is sitting in the open.

I'm still considering heat sinks to improve it further.

Yes -- the RasPi in question is a 512MB B inside a case. I purchased heatsinks but have not yet applied them.

User avatar
aquarat
Posts: 73
Joined: Thu Jul 26, 2012 2:32 pm
Location: Cape Town, South Africa

Re: NTP PPS

Mon May 20, 2013 3:53 pm

My Raspberry Pi running this NTP configuration has been up 250 days :D .
EOF

NiJen
Posts: 1
Joined: Fri May 24, 2013 9:55 am

Re: NTP PPS

Mon May 27, 2013 5:57 am

I have a question. I think there must be the "PPSSIGNAL" set in the statusbyte from the output from the ntptime. It stand there http://www.ntp.org/ntpfaq/NTP-s-config- ... PPS-VERIFY, but i have only the following statusbyte set.
status 0x2007 (PLL,PPSFREQ,PPSTIME,NANO),.

The ppstest work fine.

Here is some output:

Code: Select all

 ntpq -p; ntptime
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oGPS_NMEA(0)     .GPS.            0 l    3   64  377    0.000   -0.012   0.003
ntp_gettime() returns code 0 (OK)
  time d54d7397.645baf54  Mon, May 27 2013  5:54:31.392, (.392024051),
  maximum error 2500 us, estimated error 0 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset -11.518 us, frequency -43.075 ppm, interval 1 s,
  maximum error 2500 us, estimated error 0 us,
  status 0x2007 (PLL,PPSFREQ,PPSTIME,NANO),
  time constant 6, precision 0.001 us, tolerance 500 ppm,
and my config:

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 /home/pi/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


server 127.127.20.0 mode 17 prefer
fudge 127.127.20.0 time2 0.496 flag1 1 flag3 1

#server 127.127.22.0
#fudge 127.127.22.0 flag3 1
#pps /dev/pps0 assert hardpps#
# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example

# 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


# 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 servers 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

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.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
So what make i wrong that the Statusbyte is not set.

flok
Posts: 19
Joined: Thu Dec 13, 2012 9:46 am
Location: Gouda
Contact: ICQ Website

Re: NTP PPS

Mon Jun 17, 2013 7:52 pm

Hi,

Because some people (yes, me) consider cross-compiling (hunting for missing include files, what git repo do I need if I also want f2fs included, etc) to much of a hassle, I wrote a program which lets you sync using NTP and a PPS souce entirely from userspace. No kernel changes required at all.
Yes, it is not as accurate as via the kernel PPS driver but after a day the jitter dropped below 10us on my rpi (with an adafruit gps).
Link: http://vanheusden.com/time/rpi_gpio_ntp/

krusher
Posts: 34
Joined: Thu Oct 10, 2013 1:55 am

Re: NTP PPS

Thu Oct 10, 2013 2:11 am

I just joined to say thanks for this thread and the tutorial. I received all of my parts for this project today, and have to catch up on all of the postings this weekend before putting it together. This is a fraction of the cost of a commercial NTP server, and will be fun to build as well.

I also picked up the cable (adafruit 851) and external GPS antenna (adafruit 960) along with the old-style box so that I can drill a small hole and optionally use an external antenna (which I'm doing). Hopefully the GPS v3 will still fit in the box with a small standoff. I'm soldering on the male/female 'extension' wires (# 826) since the female/female ends were sold out. I probably didn't need 6" wires, but better too long than too short I suppose.

I also see some posts about using the 3.3Vout from the Pi to power the Vin of the GPS and not the 5V. Noted. I'm not sure which pin that is yet, but I'll find it shortly. Instead of using a backup battery, I'm getting a 4F (Farad!) supercap to plug into Vbat instead. If the 4F doesn't fit, I may need to downsize to a 1F. A 1F probably would have been enough. These are cheap on the 'bay.

I'll start reading tomorrow; I have to catch up on a few other things yet tonight.

tlhackque
Posts: 25
Joined: Sun Jan 27, 2013 5:28 pm

Re: NTP PPS

Thu Oct 10, 2013 11:02 am

It turns out that the gps module has an on-board regulator for 3.3V, so you can power it from 5V (at the cost of some conversion loss).

Wrt. Vbat - presumably you know this, but for the casual reader: a supercap isn't a drop-in replacement for a battery.

A charging circuit is required - typically a constant current source. In this case, limited by what can be taken from the RPi.

This is probably 1/2 dozen components, including another regulator IC.

When you've validated and characterized your design, you might post it here for the benefit of others.

krusher
Posts: 34
Joined: Thu Oct 10, 2013 1:55 am

Re: NTP PPS

Fri Oct 11, 2013 2:50 am

Ok thanks tlhackque, I did catch up on these pages and read that there is a regulator--so no damage done but less heat generated dropping .3V of course. That will be preferred as I'm trying to fit this all in one box.

Yep on the supercap--I don't know how much current the Pi can source at 3.3V or what the inrush current is on this small (in size) supercap. The specs I found say a maximum of 200mA, but I will test that myself. i.e. this isn't a Maxwell supercap that needs a constant current charging circuit; *I think*. The 1F cap might have been a better choice (less inrush) but I'll find that our shortly. This is part 2 however; I'll add it later and will say if that was a good idea or not. :)

tlhackque
Posts: 25
Joined: Sun Jan 27, 2013 5:28 pm

Re: NTP PPS

Fri Oct 11, 2013 9:55 am

You may be underestimating the challenges.

See http://www.raspberrypi-spy.co.uk/2012/0 ... -and-pins/, which says:
Power Pins

The header provides 5V on Pin 2 and 3.3V on Pin 1. The 3.3V supply is limited to 50mA. The 5V supply draws current directly from your microUSB supply so can use whatever is left over after the board has taken its share. A 1A power supply could supply up to 300mA once the board has drawn 700mA.
So you don't have 200 mA. Besides that, you need to worry about decoupling - especially for high current uses. This doesn't look like one - but you need to be sure that power-on time constants don't break the RPi reset circuitry. The RPi probably doesn't provide excess bulk capacitance.

A supercap looks like a dead short when discharged. Any inrush spec is going to be a function of the device's ESR & voltage. Measuring a single part would be tricky - and not adequate to produce a reliable circuit. (Parts age; you don't know where yours is in the distribution.) I wouldn't rely on that; I don't have direct experience with the device, but from what I've read, I don't expect it will like that treatment. Minimally, you probably want something like a diode from the charging voltage, plus a current-limiting resistor, plus a zener to clamp the applied voltage. Plus some decoupling. By the time you're done with the discretes, you're better off with a regulator - which also limits the input draw.

The good news is that the load on Vbat is only ~7uA at 3V (see the GPS module's datasheet at http://www.adafruit.com/datasheets/Glob ... et-V0A.pdf). No max is specified, but it's unlikely to be more than 2x. And when power is on, should be 0.

Vbat is only holding up some RAM on the module - probably SRAM. And an NTP server is probably powered-up continuously except when mains power fails.

So while a supercap is attractive in that it doesn't require maintenance, a battery should last about its shelf life.

Other useful information on the GPIO pins is at http://www.mosaic-industries.com/embedd ... ifications

Hope this helps.

krusher
Posts: 34
Joined: Thu Oct 10, 2013 1:55 am

Re: NTP PPS

Sun Oct 13, 2013 3:56 am

Err, ya I think I'll go with the battery after that info above and an experiment tonight. :) Thanks for the link; that's helpful for any Pi project really.

I hooked up the supercap with a 1 ohm resistor and put the scope on a single-sweep trigger. I'm seeing 376mV inrush on it pretty reliably which =376mA, and time to find a battery. I thought I'd be good for 200mA and this is almost double. So...

Onto the Pi project tomorrow; I'm going to assemble the case tonight so I can see where to mount my external GPS antenna connector. I flashed my SDHC a few days ago so this should go quick once I stop coming up with crazy ideas lol.

krusher
Posts: 34
Joined: Thu Oct 10, 2013 1:55 am

Re: NTP PPS

Mon Oct 14, 2013 1:27 am

I made some good progress today and will return Tuesday when I should report it working.

I figured out a way to mount the GPS inside the original adafruit box just above the RAM. The original box is better in this respect because you can drill holes easily in the individual pieces. The new version might work, but I don't have one to check it.
1. Take a .4" standoff and put the screw in slightly farther than the thickness of the circuit board
2. Fill the other end with 5m epoxy gel to the top and let dry 24h. I used a hobby syringe (it has a curved plastic tip)
3. Find a small screw that fits through the hole opposite the external GPS connector
4. Drill out the epoxy with a bit slightly smaller than your screw. I had to go through all of this trouble because the GPS board's mounting hole is smaller than the standard circuit board's hole
5. My standoff's screw (from the bottom of the board) fits snugly but makes its own threads and stops. The hole I'm using on the Pi is the one right under the raspberry symbol (and copyright)
6. Hand-tighten the standoff, and mount the GPS on top with the screw

For the GPS board, I soldered the wires on directly from underneath and will add in the battery before plugging in the jumpers (I had to remove the black plastic ends with a pick--they add too much height to close the box as-is).

If you want to add an external GPS connector like I did, this worked out good as follows:
1. Lightly center-punch the clear space inside the curved part of the letter "a" in the first letter of "adafruit" on the same panel as the flash card and power
2. Use a drill press and progressively increase your drills until you get to 1/4". Please use a drill vice as a precaution; just before the drill made it through the plastic it would grab every time. I wouldn't free-hand this
3. The cable runs towards the back of the case (by the USB ports) and curves around 270 degrees clockwise until it becomes straight and plugs into the GPS's on-board connection. I'd form that end piece as straight as possible and make sure it's not rotated before plugging it in. That connector is scary tiny
4. Alternatively, if you don't feel like drilling a hole you can sneak the wire through the slot for the ribbon cable before closing it up. But, you'll have to be sure to secure the cable inside the box so it can't move

I'm working tomorrow so not much will get done other than drilling that hole though the epoxy and assembling it all; I'm off on Tuesday and will have some time to do the software portion. Hopefully I can just telnet to it after checking my router for the IP address and the login is simple. I haven't looked up how to access it yet. :)

Hope that helps if someone else wants to make a super-compact unit as well...

krusher
Posts: 34
Joined: Thu Oct 10, 2013 1:55 am

Re: NTP PPS

Mon Oct 14, 2013 1:34 am

Also, does anyone have an estimate on how many simultaneous requests the Pi could handle at once before it starts affecting accuracy? I'm looking to get 1ms or better if possible with 10ms worst-case. I saw one of you had 20us (micro) so 1ms should be an easy goal. (Oh my on that 20us!)

krusher
Posts: 34
Joined: Thu Oct 10, 2013 1:55 am

Re: NTP PPS

Wed Oct 16, 2013 4:08 am

I think I'm making some progress here...I can't put the plastic lid on top of the pi because the .4" (~10mm; so it might be metric) standoff puts the GPS a little too high. Tape works for now. :)

Anyway, I went from this:

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 GPS_NMEA(0)     .GPS.            0 l  160   64    0    0.000    0.000   0.004
To this...

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*GPS_NMEA(0)     .GPS.            0 l   11   64    1    0.000    0.278   0.004
And then eventually this...

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oGPS_NMEA(0)     .GPS.            0 l   28   64    7    0.000    0.716   0.340
Need to get to bed; will let this run overnight now.

Maybe I missed it, but what is the fudge factor of 0.496 for?

I would have started sooner tonight but found a nail in my car tire. This 'kind of' makes up for it (a little)...

Thanks

krusher
Posts: 34
Joined: Thu Oct 10, 2013 1:55 am

Re: NTP PPS

Wed Oct 16, 2013 4:18 am

Ok last email for tonight sorry :)

The other question I have is how to verify that this is actually accurate...

When I switch between my server and 0.us.pool.ntp.org quickly, I get almost a 1-second correction factor between the two. 979ms, 982ms, etc. This is using the Symmetricom utility. So I'm not sure what is up with that...maybe I just need to wait a day or something...

Code: Select all

00:14:56 Oct 16: Offset -001ms  (0.us.pool.ntp.org, 67.212.118.60)
00:15:11 Oct 16: Offset -979ms  (192.168.33.123, 192.168.33.123)
And now the command yields this:

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
xGPS_NMEA(0)     .GPS.            0 l   11   64  377    0.000  -970.05   6.315

Return to “Other projects”