>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. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
