<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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.<div><br></div><div>Short summary: it works, jitter is at the 300 µs level.<br><div><br></div><div><br></div><div>Ingredients:</div><div><br></div><div>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.</div><div><br></div><div>Sparkfun FL232RL breakout board. <a href="http://www.sparkfun.com/products/718">http://www.sparkfun.com/products/718</a></div><div><br></div><div>A WNDR3700v2, which I am also using as my edge router at home, running openwrt trunk from a couple of weeks ago.</div><div><br></div><div>ntpd and gpsd</div><div><br></div><div><br></div><div>Method:</div><div><br></div><div>Most of what I did here followed the instructions at <a href="http://www.rjsystems.nl/en/2100-ntpd-garmin-gps-18-lvc-gpsd.php">http://www.rjsystems.nl/en/2100-ntpd-garmin-gps-18-lvc-gpsd.php</a></div><div><br></div><div>So, I wired the breakout for 5V serial levels, and wired the GPS to the serial side using the pinout above.<br><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I set the GPS for factory standard sentence output, at 19200 baud, and a PPS pulse width of 150 ms using</div><div><br></div><div>$PGRMO,,4</div><div>$PGRMC,,,,,,,,,,5,,2,6,</div><div><br></div><div>(note that you have to send those sentences using CRLF line endings).</div></div><div><br></div><div>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).</div><div><br></div><div>After a long evening of experimentation and finding suitable fudge factors, I ended up with this ntp.conf:</div><div><br></div><div>restrict default nomodify notrap<br><br>restrict 127.0.0.1<br>restrict 192.168.1.0 mask 255.255.255.0<br>restrict fe80:: mask ffc0::<br><br>driftfile /etc/ntp.drift<br><br>pool <a href="http://openwrt.pool.ntp.org">openwrt.pool.ntp.org</a> iburst<br>pool <a href="http://nz.pool.ntp.org">nz.pool.ntp.org</a> iburst<br>server <a href="http://ntp.snap.net.nz">ntp.snap.net.nz</a> iburst<br>server 2.us.pool.ntp.org iburst<br><br>enable calibrate<br><br># GPSD NMEA+PPS<br>server 127.127.28.0 minpoll 4 noselect<br>fudge 127.127.28.0 stratum 1 time1 0.5437 time2 410 refid NMEA<br>server 127.127.28.1 minpoll 4 prefer true<br>fudge 127.127.28.1 stratum 1 flag3 1 time2 0.600 refid PPS</div><div><br></div><div>And these flags for gpsd:</div><div><br></div><div>gpsd -b -G -n -P /var/run/gpsd.pid -S 2947</div><div><br></div><div><br></div><div>Proof of the pudding:</div><div><br></div><div>$ ntpq -np 192.168.1.1<br> remote refid st t when poll reach delay offset jitter<br>==============================================================================<br>-202.89.49.65 203.109.135.194 3 u 61 64 377 22.885 -0.678 15.869<br>+203.97.109.165 .PPSa. 1 u 54 64 377 18.069 -0.606 2.431<br>+203.99.128.34 131.203.16.6 2 u 55 64 377 12.114 0.428 0.383<br>-202.37.101.1 91.189.94.4 3 u 57 64 377 4.255 0.797 0.446<br>-2001:4f8:fff7:1 69.25.96.13 2 u 48 64 377 158.527 2.141 0.128<br> 127.127.28.0 .NMEA. 1 l 14 16 377 0.000 -20.338 12.376<br>*127.127.28.1 .PPS. 1 l 13 16 377 0.000 -0.120 0.256</div><div><br></div><div>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.</div><div><br></div><div>However, the real point here is the jitter; it varies a bit, but is almost always under 300 µs.</div><div><br></div><div>It also seems that the WNDR3700 has a reasonable clock, the drift value converged to 6.789 PPM.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>Cheers all, project is feasible :-)</div><div><br></div><div>Andrew</div><div><br></div><div><br></div><div><img height="640" width="456" apple-width="yes" apple-height="yes" id="d77096c0-15b8-4196-95da-8a78243df57f" src="cid:D6CECCDD-06F2-44A4-A3A8-947506560DAB@lan"><img height="640" width="389" apple-width="yes" apple-height="yes" id="48b5be1a-e570-4282-bd62-2b882aff7131" src="cid:BC5F91A6-986F-414F-A0EA-A5FF77DB8FAA@lan"></div></body></html>