ublox refclock

[Trevor N.]

>Gary E. Miller gem at rellim.com wrote

Thank you for the comments, I have replies for each point:

>Yo Udo!
>
>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:
>> https://gitlab.com/trv-n/ntpsec-ublox
>> 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
modern modules.

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