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

David Lord snews at lordynet.org
Fri Jun 12 10:16:06 UTC 2009


Unruh wrote:
> David Lord <snews at lordynet.org> writes:
> 
>> David J Taylor wrote:
>>> David J Taylor wrote:
>>> []
>>>> I might be inclined to go for a screened
>>>> cable if you need a 30m run, but thin 3-core mains cable /might/
>>>> suffice.
> 
>> 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.
> 
> The nmea is virtually useless for accurate timing. The main thing that
> the unit gives you is the PPS. You have to makes sure you do not degrade
> it. 

Accepted, the uncertainty from rs232 at 4800 baud limits timing
to around +/- 100us which is what I'm seeing.

I need the NMEA for the time information though, don't I?

I don't have any network connection to this pc.


> 
>>> I'm not sure whether the NMEA driver attempts to send anything /to/ the 
> 
> Which NMEA driver? 

Type 20, and from driver20.html it does appear the driver outputs
a request if there is no sentence input from the gps.

>>> GPS device.  If not, three lines might to (ground, TX from GPS, PPS), 
>>> otherwise four lines are required.  If you want to take USB power from 
>>> the server (as I now do), it's five lines minimum.
> 
>> 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.
> 
> Run the PPS to say gpsd or shmpps and then use ntp to use it to
> discipline the clock. PUtting the PPS into the kenrel has no advantages
> as far as I can see. 

I'll be trying shm driver for MSF and DCF but have no experience
of its use whereas the ppsapi is already there if that kernel
option is selected.

I've now rebooted with new kernel compiled with pps and had a
string of messages in ntp.log that seem to indicate pps status
changes, rather than the error messages I had before.

After 30 minutes offset has gone from > 20ms to 4us but doesn't
appear to be getting closer than that.


David




More information about the questions mailing list