trv-n at comcast.net
Wed Nov 27 06:31:52 UTC 2019
>Gary E. Miller gem at rellim.com wrote
Thank you for the comments, I have replies for each point:
>On Sun, 24 Nov 2019 09:23:19 +0100
>Udo van den Heuvel via devel <devel at ntpsec.org> wrote:
>> I cam across this ublox ntpsec refclock:
>> Would it be usable for incorporation in the ntpsec tree?
>> (AFAIK this is a 'straight' refclock; no extra lines needed besides
>> rx/tx and pps)
>I just took a quick look at refclock_ubx.c
>An interesting start, but followup messsages today on the list are
>assuming this driver does things that it does not do.
>1) It does not, ever, config the u-blox. It does not, ever, write to
>the u-blox to query it.
>Configuration is up to the user.
There are so many configuration options, I think it's best to leave it
up to the user. It wouldn't be difficult to send a generic
configuration to the module on driver startup, however.
>2) It decodes UBX-TIM-TM2 (Current time) and UBX-TIM-TIMELS (for the
>leap second). Then does some limited sanity checking.
>It will fail to catch known u-blox time failure modes.
Could you point me towards some documentation for this? I took a look
at the gpsd-3.16 driver but I failed to spot anything obvious. I did
notice some very intermittent oddities with the M8T (as mentioned in
the issue499 thread), but the v0.02 driver was able to ignore the
invalid data. I did not see any problems with the F9T. When testing,
I configured the modules to use only GPS without SBAS. I did see a few
mentions of SBAS timing problems, but the ublox docs do mention it is
not recommended so I've always disabled it.
>3) It does some interesting things with TIO that the comments claim
>improves the time stability. But it does not use KPPS which would
>just work better and simpler.
>Anything that uses KPPS will work much better.
The whole reason for this driver is for an experiment to use only the
module's EXTINT input for timing. I didn't try, but gpsd with shmem
should take care of the case when PPS is desired.
>4) It does not look at qErr, which combined with KPPS, might eventually,
>theoretically, lead to better time. When CPU time quantization gets better.
From testing on a fast machine with the oncore driver, I have seen
average jitter values of under 200ns so it may already be possible to
notice an improvement with sawtooth correction, at least for modules
with slow clock speeds. I may want to do a quick modification of the
oncore driver to test the VP's @@En message. I've seen mention of the
VPs correction values being +-52ns so it should be noticeable.
For the M8T, I don't remember seeing correction values much beyond
10ns just watching in ucenter, so I think we will need to wait a while
longer before correction could make a significant difference with
>In summary, not an improvement on current u-blox best practice. Maybe,
>eventually, an improvement, with some work (configuration, KPPS, etc.).
Even if the driver was fully-featured I'm not sure if anyone would use
it when gpsd has already been in use for so long -- unless its
timemark functionality is needed instead of PPS.
I will set up a test using gpsd and the shm driver as soon as
possible. I just noticed that I've been looking at an old version of
gpsd, so I'll check the newest release over. I also see that there is
a refclock_gpsd driver. I think I may have used gpsd as a refclock
before, but I don't remember using that driver. The gpsd guides I've
seen are using shared memory, so I will start with shm first.
More information about the devel