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. cheers David _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
