[Thumbgps-devel] PPS over USB Serial can work

Fri Mar 16 23:17:59 EDT 2012

I decided to try a practical experiment, to prove one way or another if USB serial PPS on a consumer router can work, and how well.

Short summary: it works, jitter is at the 300 µs level.

Ingredients:

Garmin GPS 18x LVC.  I used this simply because I had a local supplier, and it comes in a waterproof enclosure in case I had to put the antenna outside.  Turns out I don't need to do that.

Sparkfun FL232RL breakout board. http://www.sparkfun.com/products/718

A WNDR3700v2, which I am also using as my edge router at home, running openwrt trunk from a couple of weeks ago.

ntpd and gpsd

Method:

Most of what I did here followed the instructions at http://www.rjsystems.nl/en/2100-ntpd-garmin-gps-18-lvc-gpsd.php

So, I wired the breakout for 5V serial levels, and wired the GPS to the serial side using the pinout above.

It turns out that the GPS 18x LVC uses RS232 (inverted) polarity for its data signals, and the FT232RL defaults to TTL polarity for data lines, so I had to download FTDI's FT_PROG reprogrammer (for Windows, sadly) and reverse the serial line polarity.  This got the NMEA going.  Note that the FT232RL also defaults to inverted polarity on the flow control lines, so I eventually had to change those back to default to get PPS working.  FT_PROG can also set the USB product and vendor IDs, and for a production device the command line version would be used during manufacturing to set all this up appropriately.

The GPS 18x outputs its NMEA sentences after the matching PPS, and centered between pulses.  They're variable length, so the NMEA jitter is considerable.  I've configured my NTP with a noselect on the NMEA, so that I can see what it is doing but it will not contribute to the clock.  gpsd will still use the NMEA to disambiguate the PPS signal.

I set the GPS for factory standard sentence output, at 19200 baud, and a PPS pulse width of 150 ms using

$PGRMO,,4
$PGRMC,,,,,,,,,,5,,2,6,

(note that you have to send those sentences using CRLF line endings).

I found that this GPS has excellent reception, simply placing it on floor just inside a full-height window gets a solid lock on at least six satellites, often as many as nine, with only a little sky view and most of that obscured by foliage (it helps that the house has a cement tile roof and wooden frame, I'm sure).

After a long evening of experimentation and finding suitable fudge factors, I ended up with this ntp.conf:

restrict default nomodify notrap

restrict 127.0.0.1
restrict 192.168.1.0 mask 255.255.255.0
restrict fe80:: mask ffc0::

driftfile  /etc/ntp.drift

pool openwrt.pool.ntp.org iburst
pool nz.pool.ntp.org iburst
server ntp.snap.net.nz iburst
server 2.us.pool.ntp.org iburst

enable calibrate

# GPSD NMEA+PPS
server 127.127.28.0 minpoll 4 noselect
fudge  127.127.28.0 stratum 1 time1 0.5437 time2 410 refid NMEA
server 127.127.28.1 minpoll 4 prefer true
fudge  127.127.28.1 stratum 1 flag3 1 time2 0.600 refid PPS

And these flags for gpsd:

gpsd -b -G -n -P /var/run/gpsd.pid -S 2947

Proof of the pudding:

$ ntpq -np 192.168.1.1
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-202.89.49.65    203.109.135.194  3 u   61   64  377   22.885   -0.678  15.869
+203.97.109.165  .PPSa.           1 u   54   64  377   18.069   -0.606   2.431
+203.99.128.34   131.203.16.6     2 u   55   64  377   12.114    0.428   0.383
-202.37.101.1    91.189.94.4      3 u   57   64  377    4.255    0.797   0.446
-2001:4f8:fff7:1 69.25.96.13      2 u   48   64  377  158.527    2.141   0.128
 127.127.28.0    .NMEA.           1 l   14   16  377    0.000  -20.338  12.376
*127.127.28.1    .PPS.            1 l   13   16  377    0.000   -0.120   0.256

I have not adjusted in any offset for USB latency in the PPS signal, as I don't know what a suitable value would be.  Although looking at that data, 500 µs may be about right.

However, the real point here is the jitter; it varies a bit, but is almost always under 300 µs.

It also seems that the WNDR3700 has a reasonable clock, the drift value converged to 6.789 PPM.

I've attached a couple of photos of the breakout.  The red wire on the top side jumpers the board for 5V IO, I'm not sure it is necessary given the solder jumper just above it on the left side.

Cheers all, project is feasible :-)

Andrew

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/thumbgps-devel/attachments/20120317/3a1702a8/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IMG_0489.jpeg
Type: image/jpg
Size: 106494 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/thumbgps-devel/attachments/20120317/3a1702a8/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IMG_0490.jpeg
Type: image/jpg
Size: 71320 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/thumbgps-devel/attachments/20120317/3a1702a8/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2330 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/thumbgps-devel/attachments/20120317/3a1702a8/attachment-0002.bin>