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

Unruh unruh-spam at physics.ubc.ca
Fri Jun 12 17:09:15 UTC 2009


David Lord <snews at lordynet.org> writes:

>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.

Well, I suppose you could somehow set the thing up to grab the rise time
of the first bit sent along the serial line, but there is no evidence
that the maker of the GPS made even that first bit at all accurate. Ie,
the time when that first bit is sent could well vary by milliseconds.
NMEA was never intended for accurate timeing.


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

Yes, you need it to determine the value of the seconds.


>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