[ntp:questions] NMEA ref.clock better than my ISP's timeserver?
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.
> 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....
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