[ntp:questions] NMEA ref.clock better than my ISP's timeserver?

David Lord snews at lordynet.org
Sat Jun 13 11:00:16 UTC 2009

David Lord wrote:
> David J Taylor wrote:
>> David Lord wrote:
>>> I'm intending buffering the pps to give 75r output to coax with
>>> another converter back to ttl at the server. The NMEA should manage
>>> the distance over twisted pair at 4800 baud.
>> []
>>> I'd rather have the option for two way in case the Garmin needs to be
>>> set to a different mode. I have a reel of utp I think should do.
>>> I'll have some sort of fan-out box to get a pps signal to each of
>>> servers that are powered up continuously.
>>> I've now seen an error in ntp log and suspect pps isn't enabled in
>>> kernel by default (NetBSD-5). I'll check tomorrow.
>>> Cheers
>>> David
>> David, if you have UTP cable, I think that's four twisted pairs, so I 
>> would just use one pair per signal (TX, RX, PPS)  and the remaining 
>> pair as an earth/+5V.  Unless you have a noisy electrical environment, 
>> I think that will be fine over 30m.  Screened would be better, if you 
>> have it. Fan-out would be nice - I've used two RS-232 input in 
>> parallel fed from one GPS 18 without problems.
> I'll scope pps down utp but doubt the pps will keep its rising
> edge. I'm having a box with indicator led and 5V regulator at end
> of the stock Garmin cable and coax + utp from that box downstairs.
> One pair will have +9V/0V to the regulator. It's a long while
> since I ran an rs232 cable downstairs but remember I had problems
> with higher data rates and 38400 bps being unreliable but 9600 bps
> just ok. That was also full rs232 levels rather than ttl.
>> I thought the offset figures you were quoting were for Windows - 
>> "between -74us and +62us".  For a PPS signal on a FreeBSD system I 
>> would expect much better.  I recall needing both the NMEA and the ATOM 
>> driver configured.  Oh, yes, I vaguely recall having to compile the 
>> kernel as well.  It was a few years ago....
>>  http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm
> NetBSD-5 sources are from March 1, so pre NetBSD-5.0. I'll update
> to 5.0 off peak tonight and compile a new kernel. The last kernel
> compiled in March for a different pc includes "options PPS_SYNC"
> whereas that option doesn't appear in "GENERIC" or "std.i386" so
> as GPS with pps option enabled drifting further and ntpd throwing
> out more errors I think I can take it pps isn't working.
> Meanwhile I've removed the pps flag and restarted ntp.

I'm happy with very limited results so far so bringing the
PC back downstairs.

Garmin GPS18X-LVC
PC Mini-ITX ME6000 600MHz C3

NMEA string without PPS

# ntp.conf
fudge stratum 12 time2 0
fudge stratum 1

Over 6hrs (= 12 data points)
Offset:         Max     Avg     87%     50%
(us)            130      73     104      61

PPS enabled Kernel

# ntp.conf
fudge stratum 12 time2 0
server mode 1
fudge stratum 1 flag3 1

Over 17hrs (= 34 data points)
Offset:         Max     Avg     87%     50%
(us)             12     4.2       7       3

These are stats for past 24hrs of servers getting time from
internet. There's been no problems with load or temperature
otherwise Max would have hit its 12ms cutoff for graphing.

PC K6X400 NetBSD-3
                 Max             Average         Current
+offset:        3562 us         370 us          416 us
-offset:        2445 us         417 us          0 us

PC ME6000G NetBSD-4
                 Max             Average         Current
+offset:        2114 us         520 us          559 us
-offset:        4715 us         456 us          0 us

P4X2400C	NetBSD-4
                 Max             Average         Current
+offset:        1702 us         528 us          541 us
-offset:        2055 us         119 us          0 us

More information about the questions mailing list