[Pool] GPS without PPS, was Re: Score is drop in cycles

Jeff Woolsey jlw at jlw.com
Fri Feb 21 20:17:28 UTC 2014


On 02/21/14 01:52, Rob Janssen wrote:
> Jeff Woolsey wrote:
>> On 02/20/14 12:21, Timothy Oefelein wrote:
>>>
>>> One of the these days I'd like to get the hardware to run my own 
>>> Stratum 1 server, which would make the whole finding peers process 
>>> moot. :)
>>
>> Not necessarily.  Trust but verify your local reference clock against 
>> other servers out there.  For example, I'm currently seeing about 
>> 60ms of jitter/offset in the SHM refclock from gpsd managing a SiRF 
>> II device.  (It was 10 seconds off before I fixed gpsd not to request 
>> messages it's ignoring anyway.).  It's USB, but still I'd expect only 
>> 1-2ms of offset/jitter, which is fine for my purposes:
>
> Using serial messages as a timesync (other than for determining the 
> time in seconds) is no good.
> There is no good lock between the timing of the serial messages 
> relative to the real time value in them.
> And when there is other traffic on the line, this becomes even more 
> apparent.
> (not a 10 second difference though, you must have other issues!)
> Serial message sources wandering around 60ms relative to the correct 
> time are quite common.  Can be even more!
>
> To have any value from a local GPS receiver, you need to use PPS.
> This was easy in the days of RS232.   I have a GPS module on a real 
> RS232 port (not USB) with PPS connected to DCD and timesync via gpsd.
> It shows 0.001 in the jitter column.  It would be even better with a 
> newer kernel that supports PPS in the kernel so it does not have to be 
> handled in the gpsd user process.
>
> But GPS with only serial and no PPS - forget it.   External sources on 
> a good internet connection will be better.
>
> Rob
>

What we have here is an excellent example of the adage that all 
generalizations are false.  I am quite aware that PPS is necessary for 
near-microsecond accuracy.  It does bother me a bit, though, that some 
such NTP servers out there have no other sources listed.

My objective was, and still is, to see how well I can do with no 
additional outlay of funds, using GPS units that I already had about the 
place or were purchased for other reasons.  These are all consumer units 
and do not have accessible PPS.

The SHM/gpsd setup I mentioned earlier is on a Raspberry Pi (Xmas gift) 
using a Pharos 360 (SiRF II) on a Prolific serial-USB converter (both 
from Microsoft Streets and Trips 2006, which came free from an estate).  
gpsd puts it in SiRF binary mode instead of NMEA. (NTP doesn't have a 
SiRF driver.) The initial 10-second offset was suspected to be 
leap-second related (but it should be 16 seconds now).  I managed to 
eliminate it by adding code to gpsd to actually deselect a SiRF message 
type that the comments said was being ignored.  Now it wanders ~60ms and 
I wonder if there's some issue with the SHM stuff. Old Pharos firmware 
has certain problems and omissions (no UTC time, or PPS offset, for 
example) in binary mode (paradoxically, NMEA here reports UTC to 
millisecond precision (and no 10-second offset)) which may account for 
this. gpsd advises against reflashing a SiRF. This is not my pool server.

Another example:  A Garmin GPS V on a Keyspan USB serial port on a 
PowerBook G4 running ntp.  GPSy claimed that the device time was 0ms 
behind the host.  Hmmm.  Very interesting.  I gave it to ntp with the 
generic NMEA driver and set the flag to use only the RMC sentence, and 
got a consistent ~250ms offset.  Fudged that and it's actually fairly 
reasonable, in the 5ms offset region.  Better than I expected from 
NMEA.  More about Garmins later. This also is not my pool server.

Quite some time ago I found an NTP refclock driver for the DeLorme 
Tripmate, so I bought one on closeout.  (Later I got another through 
freecycle, but it's deaf.)  The driver switches this unit to Rockwell 
Zodiac (IIRC) binary mode. With a fudge value of 1.000 seconds, NTP is 
consistently under 1ms of offset, the limiting factor here being the 
real serial port strobe/sawtooth effect.  That is about as good as a 
real serial port at 9600bps can get.  This is my pool server.

A similar long time ago (before the pool) I ran across an NTP refclock 
driver for handheld Garmin GPS units.  The driver puts them in GRMN 
binary mode, not NMEA.  For a particular model with specific firmware 
versions, there is an oscillator offset counter to query which allows 
NTP to achieve sub-millisecond accuracy.  There may be other models that 
work too, otherwise you only get sub-second accuracy.  Again, the serial 
port is the limiting factor.  None of the Garmins I had at the time had 
this counter available, alas.  But the GPS V I mentioned was a later 
acquisition and has not yet been tested, along with a 276C which I 
actually use to navigate.  The driver author had his NTP server 
available, and I did see those sub-millisecond offsets.

===

Pretty much all of the GPS units I mentioned can be had for under $50 
these days, as can some purpose-built bare timing receiver boards 
(Encore, Jupiter, etc.).  Tiny GPS boards for tiny microcontrollers are 
similarly inexpensive, including a couple for the Raspberry Pi.  All of 
these have PPS available, and maybe someday I'll stick one on my Pi, 
along with a WiFi dongle and solar power...

-- 
Jeff Woolsey {woolsey,jlw}@{jlw,jxh}.com first.last@{gmail,jlw}.com
Spum bad keming.
Nature abhors a straight antenna, a clean lens, and unused storage capacity.
"Delete! Delete! OK!" -Dr. Bronner on disk space management
"Card sorting, Joel." -me, re Solitaire



More information about the pool mailing list