[ntp:questions] GPX18x LVC 3.50 firmware - high serial delay problem workround

unruh unruh at wormhole.physics.ubc.ca
Sat Jan 15 02:23:39 UTC 2011


On 2011-01-14, Chris Albertson <albertson.chris at gmail.com> wrote:
> On Fri, Jan 14, 2011 at 1:30 PM, unruh <unruh at wormhole.physics.ubc.ca> wrote:
>> On 2011-01-14, Chris Albertson <albertson.chris at gmail.com> wrote:
>>>> When the software (any software) only receives a PPS signal and a
>>>> serial message conveying the absolute time, but it does not know how
>>>> much the serial message is offset from the true time, how should it
>>>> determine the true time?
>>>
>>>>From a configuration file that describes the relationship between the
>>> PPS and text message.
>>
>> How in the world does whoever set up that config file know that
>> difference? The program can use the same algorithm you do to determine
>> that.
>
> The only way to know is to compare to another reference assumed to be
> correct.  Pool NTP servers would be accurate enough for that.    The
> GPSes (Motorola Oncore) I use have a related "problem" in that they
> allow the pulse to be adjust so that it happens before the UTC second
> or any time during the second.  So I actually have a choice.  But how
> to set it and know it is right?

??? That would make the pps totally useless. If it does not occur on the
UTC second, it is pointless. 
>
> What you'd do is adjust the timing until it was a best match to the
> other reference clocks you have or lacking that to a set of pool NTP
> servers
Since  you are using the pool as your time source, just use them. This
device adds nothing in that case. 
I am assuming, as with the GPS18. that the unit emits a PPS pulse
exactly on the seconds transition of UTC time. Then the nmea sentences
come after that telling you which second it was that that pulse gave the
exact time to.

The shmslp driver does something similar. It uses some other source to
get the seconds right and then hands over to the PPS to get the
nanoseconds right. But it uses only the PPS pulse, not the serial nmea
data. It thus requires you to have another source of time. However with
something like the GPS18 it delivers both the nanoseconds via that PPS
AND the seconds via the nmea sentence. Of course that only works if you
know which second that PPS pulse refers to. The specs of the GPS18 say
that it is the previous pulse that that nmea timestamp refers to . But
if it takes 2 sec say to deliver the nmea sentence, then the "previous"
pps pulse is the wrong one. So the sentence MUST start less than 1 sec
after the pulse. If it does not, it is broken and is not working
according to spec. I have never had trouble with teh GPS18, but they are
refering to the GPS 18x, the newer version. 

>
> I think what this proves is that setting up a Stratum One NTP server
> requires that you have access to multiple clocks in your lab.  eBay
> makes this very inexpensive now.  Many people have three or more
> clocks and test equipmnt so that they can be compared.  Lacking this,
> it is just a gues if your server has corect time
>
> Could this be automated?  Maybe, to some degree.  The reference clock
> driver would need to have a "survey mode" setting where it would run
> for many hours and compare it's own time to others.  NTP does this
> already, almost,  what it lacks is a way to capture the measured
> offset and fold it back to a config file.
>
>
>
>
>




More information about the questions mailing list