Plug as an NTP stratum-1 server

[MarkF]

I'm thinking I can use a plug for (among other things) a Network Time Protocol (NTP) stratum-1 server.

To do this, I'll use a Garmin 18 LVC/OEM GPS connected to the second serial port as the stratum-0 device.  "Second serial port?", you ask.  Yes, the one that can be routed out the SDIO pins.  I should be able to hack together a cable from the SDIO port and change the kernel to use two pins as the second serial port (TX/RX) and a GPIO as an input (for the pulse per second (PPS) signal).  Then, I should "only" need to put together a bread board with a MAX3232 (plus capacitors), a USB connector (for 5V power), a connector to the SDIO port cable and a connector to the GPS cable.

The GPS and 5V side of the MAX3232 will be powered by the USB connection (I'll use a powered hub) and the TX/RX/PPS signals will level shift through the MAX part.

Considering my day job is writing SOFTWARE, does anyone see a problem with this logic?

By the way, this is not a new idea.  There are write-ups for doing this on other little linux computers elsewhere on the net.  The key, I think, is a second REAL (not USB) serial port and the PPS signal.

Please don't ask why I want to do this.  I have a wife that will be happy to ask that question.

[DamonHD]

Hi,

I have a stratum-2 server running happily on the plug providing public time service.

I used to have a Trimble GPS receiver as my clock, then I discovered the Galleon radio clocks that cost maybe £30 and with a bit of care my code (built on others') in xntpd (V3) was able to get to within 30ms of atomic time even given its 300 baud connection.  All it needs is indeed a serial connection, but serial via USB should be fine at that speed!  No PPS needed.

Though my code seems to have been broken in xntpd V4 it could probably be fixed quicker than you could do the soldering.  I really ought to do it myself and have the Galleon sitting above my laptop now, unused.

Interested in that as a solution?

Rgds

Damon

[MarkF]

Thanks for the suggestion and offer! 

I'm in the US so I don't think the radio clock solution will work here, will it?  I think I need a WWVB or GPS solution.  I think, given a choice, I'd like to use a cheap, readily available, GPS (with PPS) as it could be highly accurate.  Also, if I'm successful, this may be an interesting project for people in other locations as well.

Most of this is very new to me so please correct me if my understanding is wrong.

[MarkF]

I just ordered some of the parts for this.

I'm going to do this in two phases -

Phase 1:
NEMA time strings and PPS though a Prolific USB->Serial adapter.  I want to see if the offset and jitter on the PPS signal is big enough when routed through USB to warrant doing phase 2b or if I can get away with phase 2a.  I'm also going to change the NTP NEMA driver to have it do the PPS detection on the same usb/serial port (PPS attached to DCD, CTS or DSR) like the shared memory driver.

Phase 2a:
If PPS offset and jitter are small enough through USB, change this to use two readily available parts.  The Garmin 18 LVC/OEM GPS and the FTDI TTL-232R USB - TTL Level Serial Converter cable or FTDI TTL-232R-PCB USB - TTL Level Serial Converter board.  These may not be the lowest cost solutions but they may be the easiest.   I really wish Garmin's (or any other quality GPS vendor's) USB solution would bring PPS out as one of the RS232 signals or have an option to enable something like this.

Phase 2b:
If PPS offset or jitter are too big through USB, enable the second serial port replacing the SDIO port.

[fragfutter]

out of curiousity, running as stratum 2 or 3 via ntpd is not sufficient enough for you? Or is it because you can do it?

[DamonHD]

Running as stratum-1 means that you can provide a better public service and provide another independent 'top' node in the NTP network...

So why not?  B^>

Rgds

Damon

[MarkF]

Three reasons:

1) I want to see if I can.

2) If you look at the time server pools at http://support.ntp.org/bin/view/Servers/NTPPoolServers you will see that there are regions of the world that are not served directly for what ever reasons.  After pricing Time Servers on the web, I believe price may be one reason.  If the price of a stratum-1 server was << $200 (US), this might change.

3) See 1.

[notjeff]

I just recently setup my sheevaplug as a stratum-1 NTP server.

I used a USB Earthmate LT-40 GPS (bundled with Delorme Street & Trips) along with kernel 2.6.32.1 on Debian Squeeze.

After some tweaking I was able to get a fairly accurate time out of the GPS for use with ntpd.  Most of the tweaking centered around determining the correct offset, in the case of my setup: -0.235.  The jitter was usually between 1 and 3 ms, either close or better than the other startum-1 servers I was querying. (I don't normally query stratum-1 servers directly, but did so in this case in order to determine the proper offset for my GPS.)

The only problem I ran into was that the constant polling of the GPS kept the CPU in C0 state instead of C1 and averaged around 350 wakeups per second instead of the usual 5 per second.  A problem for me as I'm trying to make the Sheevaplug as low power as possible.

Here are the relevant lines from my ntp.conf in case they help:
server 127.127.28.0 minpoll 4 maxpoll 4
fudge 127.127.28.0 time1 -0.235 refid GPS

[DamonHD]

NTP, even with a radio clock, shouldn't need to poll/wakeup that often.  I managed to use a 30 baud radio clock where it couldn't muster that many interrupts if it tried!

Rgds

Damon

[MarkF]

notjeff -

Thanks for the info.  Every little bit helps.

Does the LT-40 provide a PPS or is the lack of a PPS why you were polling the GPS so much?

[notjeff]

I haven't had the chance to figure out what is causing all the wakeups.  ntpd is only polling shared memory every 16 seconds so I don't think ntpd is the cause.

The large number of wakeups happen immediately after launching gpsd.  (I'm not passing any special options to gpsd, just "gpsd /dev/ttyUSB0")  According to powertop the top causes for wakeups are:

  46.3% (236.3)   USB device  1-1 : DeLorme USB Earthmate       (DeLorme Publishing)
  45.8% (233.3)       <interrupt> : ehci_hcd:usb1
   2.9% ( 15.0)       <interrupt> : orion_tick
   2.1% ( 10.7)     <kernel core> : hrtimer_start (tick_sched_timer)
   1.5% (  7.7)     <kernel core> : cypress_read_int_callback (delayed_work_timer_fn)

At this point I'm not sure if the above is from gpsd polling the GPS too rapidly, or if it is a result of the amount of output coming down from the GPS.  I have not seen a way to tell gpsd how frequently to I will try to dig down further when I have time.


MarkF -

The GPS chip used in the LT-40 may provide a PPS (I haven't looked at the actual specs), but as far as I can tell any PPS is not available over the LT-40's USB connection.  (What little research I have done on PPS seems to suggest that it can't be done over USB because it requires a dedicated pin.)

[MarkF]

I would ASSUME that, in it's standard form or standard "mode", the LT-40 provides a lot more information than just the time of day.  After all, it is designed to be part of a positioning system, not a clock.

Having said that, unless you can tell the LT-40 to only produce time strings, you may be seeing a large amount of time spent retrieving data that won't be used for the ntp function.  As you probably know, latitude, longitude, height, rate of change of each of those and possibly others are standard outputs of most GPS units.

The Garmin GPS unit I'm getting can be programmed to output only the strings I require so I'm hoping to minimize the time the plug spends gathering data that will be thrown away.  I'm going to wire the PPS signal to either the DCD or CTS signal of the serial port which should allow me to see the PPS transitions using the standard serial driver.  My biggest concern is whether the USB->serial software stack will cause too much jitter on the PPS signal and render it useless.

I should get most of the hardware to test this in the next few days.  However, with the holiday Friday and a house full of relatives, I probably won't get to put it together for a couple of weeks.