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

David Lord snews at lordynet.org
Thu Jun 11 14:52:29 UTC 2009

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.

Anyway getting better than 100us on Garmin vs better than 700ms
with BR304 is a big enough step up already. Really all I need is
that all pcs keep same time and several ms from utc is ok.
Problem with ntp via broadband is sometimes a large download or
build gives >100ms difference between servers and I expect
feeding pps to each server will solve that problem.



More information about the questions mailing list