ublox refclock
Hello, How or when will the ublox refclock be added to ntpsec? Kind regards, Udo from ntp.hackers: Begin forwarded message: Date: Fri, 10 Aug 2018 13:03:19 +0200 From: Lukas Senger To: hack...@lists.ntp.org Subject: [ntp:hackers] u-blox reference clock driver Hi, I've been writing a reference driver for u-blox GPS receivers as part of my master's thesis and thought ntp hackers might be interested in it. Additionally to normal PPS operation this driver can make use of the u-blox's "Timemark" functionality. It does this by enabling the PPSAPI echo, which generates an echo pulse right after receiving a PPS pulse. This echo is connected to EXTINT0 on the u-blox, where it is timestamped. So now I have the PPS timestamp as a local time and the timemark as the receiver time to calculate an offset. The cool thing about this is, that the offset does not include the local interrupt latency anymore, which leads to less jitter. Here's the driver: https://gitlab.cs.fau.de/luksen/ntp-ubx/blob/ubx/ntpd/refclock_ubx.c The echo/timemark feature requires kernel patches on Linux (with gpio pins) and FreeBSD (parallel port). It's probably easiest to test on a Raspberry Pi with the Linux patch and via GPIO pins. Linux patch: https://gitlab.cs.fau.de/snippets/28 FreeBSD patch: https://gitlab.cs.fau.de/snippets/29 I originally tried to send this message some time ago but it seems like there were some problems with the mailing list. By now the thesis is finished and you can find it here: https://wwwcip.informatik.uni-erlangen.de/~in18otin/thesis.pdf --Lukas ___ hackers mailing list hack...@lists.ntp.org http://lists.ntp.org/listinfo/hackers ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
ublox refclock
>> Is there any point to it without the matching kernel driver? > >Has anybody tried asking for the "echo" from user space? > >That is: > grab time > raise modem signal > grab time > read timestamp over serial port > >If you precede that with > grab time > lower modem signal >I think that will warm up most of the cache. Another interesting experiment >would be to see how much of a difference that makes. The trimble driver already uses user-space for its time mark output (the HW_poll function). It works quite well: on my test machine (50ns precision, ovenized oscilator) a Praecis Cf has a jitter of less than 30ns, even with a 40k packets-per-second load. I don't remember pre-fetching a timestamp making much of a difference when I was testing changes to the driver. HW_poll does not echo a PPS input, so its alignment to the top of the second is arbitrary. Attached is an ntpvis summary csv of a run I just finished on my test machine while unloaded. Unit0 is a Praecis Cf with usermode timemark, and unit1 is a Palisade using the timemark kernel module I am developing. I am making another run now with the Palisade using the usermode timemark for comparison. Currently my kernel module has the same arbitrary-alignment problem as ntpsec's HW_poll, so it's not quite ready for general use. trimble-lkm-summary.csv Description: Binary data ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
Hello, 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) Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
On 11/24/19 2:23 AM, Udo van den Heuvel via devel wrote: > I cam across this ublox ntpsec refclock: > https://gitlab.com/trv-n/ntpsec-ublox That's certainly interesting. I'd personally be interested, from a hobby/curiosity* perspective, in such a driver if it automated various configuration steps to optimize timing. At the low end of complexity, that might be setting "stationary mode". In the middle might be disabling SBAS, etc. (as recommended by ublox for timing). At the high end, that might be doing something with timing mode: e.g. if the position is unknown, do a survey-in, then save the position to a file, at (ntpd && GPS receiver) restart, load the fixed position back into the GPS receiver. Of course, if gpsd did the same, that'd work for me too. A series of gpsctl commands in a script would also work. * Whether this actually matters for NTP accuracy is questionable. From what Gary has said, it probably doesn't matter. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
Udo van den Heuvel via devel : > 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) Thank you very much for bringing this to our attention. The M8T is an interesting chip in a product line a couple of our principals like and use. Not only is it a strong candidate for inclusion as a supported driver, I'd be hard-put to think of a stronger one. I have filed an issue on its tracker titled "Work should be merged to upstream". In it I encourage the developer to introduce himself on this list so we can discuss what would be required to integrate. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
On 24-11-2019 14:18, Eric S. Raymond wrote: > Udo van den Heuvel via devel : >> I cam across this ublox ntpsec refclock: >> https://gitlab.com/trv-n/ntpsec-ublox >> Would it be usable for incorporation in the ntpsec tree? (...) > > I have filed an issue on its tracker titled "Work should be merged to > upstream". In it I encourage the developer to introduce himself on this > list so we can discuss what would be required to integrate. Thanks! I have an M8N on order, would that be compatible enough to this driver? If so: I could help test etc. Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
Udo van den Heuvel : > I have an M8N on order, would that be compatible enough to this driver? > If so: I could help test etc. That can't hurt - they speak the same protocol - but the big deal with the T variant os a stationary mode you don't have. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
On 24-11-2019 15:01, Eric S. Raymond wrote: > Udo van den Heuvel : >> I have an M8N on order, would that be compatible enough to this driver? >> If so: I could help test etc. > > That can't hurt - they speak the same protocol - but the big deal with > the T variant os a stationary mode you don't have. Ah, OK. The M8N was cheap so perhaps a fake; I can try to identify this when it comes in. As it was cheap the loss would not be big. As it appears I need a (real) M8T: What M8T board, cabling etc would I need to buy to interface to RS232? Would e.g. https://www.gnss.store/12-gnss-gps-modules be reputable enough? Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
On Sun, Nov 24, 2019, 6:08 AM Udo van den Heuvel via devel wrote: > On 24-11-2019 15:01, Eric S. Raymond wrote: > > Udo van den Heuvel : > >> I have an M8N on order, would that be compatible enough to this driver? > >> If so: I could help test etc. > > > > That can't hurt - they speak the same protocol - but the big deal with > > the T variant os a stationary mode you don't have. > > Ah, OK. > The M8N was cheap so perhaps a fake; I can try to identify this when it > comes in. > > As it was cheap the loss would not be big. > > As it appears I need a (real) M8T: > What M8T board, cabling etc would I need to buy to interface to RS232? > Would e.g. https://www.gnss.store/12-gnss-gps-modules be reputable enough? > I do not suppose this would be anything like issue 499. > ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
On 24-11-2019 15:11, James Browning via devel wrote: > I do not suppose this would be anything like issue 499. Different code. (?) 'straight' clock, no kernel issues identified (yet). Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
Udo van den Heuvel : > On 24-11-2019 15:01, Eric S. Raymond wrote: > > Udo van den Heuvel : > >> I have an M8N on order, would that be compatible enough to this driver? > >> If so: I could help test etc. > > > > That can't hurt - they speak the same protocol - but the big deal with > > the T variant os a stationary mode you don't have. > > Ah, OK. > The M8N was cheap so perhaps a fake; I can try to identify this when it > comes in. Not necessarily a fake; the 8N is the normal variant (without stationary mode) and less expensive. I suspect it's the same hardware with a different firmware load - they price-discriminate because they think the customers for stationary mode will pay more. > As it appears I need a (real) M8T: > What M8T board, cabling etc would I need to buy to interface to RS232? > Would e.g. https://www.gnss.store/12-gnss-gps-modules be reputable enough? Alas, I don't know. In the past the 8T was expensive and difficult to find; I haven't worked with one. I guess you get to be forward scout on this one. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
Eric S. Raymond via devel writes: > Not necessarily a fake; the 8N is the normal variant (without > stationary mode) and less expensive. I suspect it's the same hardware > with a different firmware load - they price-discriminate because > they think the customers for stationary mode will pay more. Different firmware and smaller too, IIRC. But more pertinent to the pricing is the fact that the uBlox T variants are all paired with much better oscillators. Some of the extra features available on T models likely require extra testing in production as well (testing is often more expensive than the actual hardware). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
Yo Udo! On Sun, 24 Nov 2019 15:08:05 +0100 Udo van den Heuvel via devel wrote: > On 24-11-2019 15:01, Eric S. Raymond wrote: > > Udo van den Heuvel : > >> I have an M8N on order, would that be compatible enough to this > >> driver? If so: I could help test etc. > > > > That can't hurt - they speak the same protocol - but the big deal > > with the T variant os a stationary mode you don't have. > > Ah, OK. > The M8N was cheap so perhaps a fake; I can try to identify this when > it comes in. If it speaks u-blox protocol it is almost certainly from u-blox. That said, there are many GPS sold as "replacement for NEO-M8N" that are not u-blox. And sometimes cheaper/older u-blox remarked as newer more expensive ones. UBX-MON-VER will answer those issues. > As it appears I need a (real) M8T: Really? For me to tell the performance between a NEO-M8N and a NEO-M8T requires me to use a TAPR PICC and/or my Rb clock. > What M8T board, cabling etc would I need to buy to interface to RS232? So many to choose from. If you are only using RS-232 to read the PPS then the M8T is way overkill. Both the NEO-M8N and NEO-M8T are very temperature sensitive. To see the added performance of the M8T over the M8N you need a very stable ambient temperature. With ntpviz I can easily see the heat go on and off in my house. Even when the GPS is in a room with NO connection to my house ducts. I, and others, have built single oven, and double oven, enclosures to remove the temp dependency. > Would e.g. https://www.gnss.store/12-gnss-gps-modules be reputable > enough? Dunno about their reputation. Their price on the u-blox 9's seem OK, but their older stuff is way over priced. See the discussion eariler this month where I recommended parts to Richard Laager. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpvwScZjU4pb.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
Yo Richard! On Sun, 24 Nov 2019 03:44:57 -0600 Richard Laager via devel wrote: > On 11/24/19 2:23 AM, Udo van den Heuvel via devel wrote: > > I cam across this ublox ntpsec refclock: > > https://gitlab.com/trv-n/ntpsec-ublox > > That's certainly interesting. I'd personally be interested, from a > hobby/curiosity* perspective, in such a driver if it automated various > configuration steps to optimize timing. The new u-blox 9 series added almost 1,000 new configuration options. So sorta hard to come up with one-size-fits-all configuration. > Of course, if gpsd did the same, that'd work for me too. A series of > gpsctl commands in a script would also work. Many people put ubxtool in a script to configure their GNSS receiver as they desire. Examples are in the doc. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpJeC6EEkyAL.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
Yo Udo! On Sun, 24 Nov 2019 09:23:19 +0100 Udo van den Heuvel via devel 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. 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. 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. 4) It does not look at qErr, which combined with KPPS, might eventually, theoretically, lead to better time. When CPU time quantization gets better. In summary, not an improvement on current u-blox best practice. Maybe, eventually, an improvement, with some work (configuration, KPPS, etc.). RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpjZDgvhko7G.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
Gary E. Miller via devel : > 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. > > 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. > > 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. > > 4) It does not look at qErr, which combined with KPPS, might eventually, > theoretically, lead to better time. When CPU time quantization gets better. > > In summary, not an improvement on current u-blox best practice. Maybe, > eventually, an improvement, with some work (configuration, KPPS, etc.). So there is nothing you recommend be merged at this time? -- http://www.catb.org/~esr/";>Eric S. Raymond signature.asc Description: PGP signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
Yo Eric! On Mon, 25 Nov 2019 08:18:21 -0500 "Eric S. Raymond" wrote: > Gary E. Miller via devel : > > I just took a quick look at refclock_ubx.c > > > > An interesting start, [...] > So there is nothing you recommend be merged at this time? I sorta wish NTPsec had a staging area like the Linux kernel does. There is value to a small and clean u-blox driver fully integrated into NTPsec. But without KPPS it is inferior at timekeeping. If the guy that wrote it wanted to work on it under the NTPsec umbrella that would be good. A little guidance and the guy that wrote that could be very useful to NTPsec. Without that guy, or someone interested in being that guy. I'd pass on that driver. I'm not personally interested in upgrading that software to have the smarts that gpsd already does about the u-blox and KPPS. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpHoV6qwHOK5.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
Gary E. Miller via devel writes: > If the guy that wrote it wanted to work on it under the NTPsec umbrella > that would be good. A little guidance and the guy that wrote that could > be very useful to NTPsec. "The guy that wrote" it has last participated on this list over a year ago in this very thread. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
Gary E. Miller via devel : > > So there is nothing you recommend be merged at this time? > > I sorta wish NTPsec had a staging area like the Linux kernel does. > > There is value to a small and clean u-blox driver fully integrated > into NTPsec. But without KPPS it is inferior at timekeeping. > > If the guy that wrote it wanted to work on it under the NTPsec umbrella > that would be good. A little guidance and the guy that wrote that could > be very useful to NTPsec. > > Without that guy, or someone interested in being that guy. I'd pass on > that driver. I'm not personally interested in upgrading that software to > have the smarts that gpsd already does about the u-blox and KPPS. I left an issue on his tracker about merging to upstream. If he responds I will try to bring him into the fold. If he does not, from what you say there os not much loss hrere. -- http://www.catb.org/~esr/";>Eric S. Raymond signature.asc Description: PGP signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
RE: ublox refclock
Eric S. Raymond esr at thyrsus.com : >Gary E. Miller via devel : >> > So there is nothing you recommend be merged at this time? >> >> I sorta wish NTPsec had a staging area like the Linux kernel does. >> >> There is value to a small and clean u-blox driver fully integrated >> into NTPsec. But without KPPS it is inferior at timekeeping. >> >> If the guy that wrote it wanted to work on it under the NTPsec umbrella >> that would be good. A little guidance and the guy that wrote that could >> be very useful to NTPsec. >> >> Without that guy, or someone interested in being that guy. I'd pass on >> that driver. I'm not personally interested in upgrading that software to >> have the smarts that gpsd already does about the u-blox and KPPS. > >I left an issue on his tracker about merging to upstream. If he responds >I will try to bring him into the fold. If he does not, from what you say there >os not much loss hrere. >-- > http://www.catb.org/~esr/";>Eric S. Raymond Thanks for the interest in the driver. It's the same one I posted in issue 499: https://gitlab.com/NTPsec/ntpsec/issues/499#note_133458690 I have been busy with my day job this year, but I will have some free time starting next month. I'll update my fork to the latest upstream this weekend. I have also tested the driver with a ZED-F9T for a few months now (with the new version posted on issue 499), and the performance is even better than what I reported on the issue 499 thread with the M8T -- And the F9T did not show any of the strange issues that I reported having with the M8T. I will attach some ntpvis plots of the F9T to the issue 499 thread. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
RE: ublox refclock
>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 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
Re: ublox refclock
Yo Trevor! On Wed, 27 Nov 2019 01:31:52 -0500 "Trevor N. via devel" wrote: > >Gary E. Miller gem at rellim.com wrote > > Thank you for the comments, I have replies for each point: Talk is cheap, yet time consuming, and proves nothing. Send this list some ntpviz output showing this driver adds value, otherwise this discussion is a waste. If you can prove added value then getting it ready to include will just require the obvious grunt work. I have a driveway to shovel and hours to drive, so my answers will have to wait. I hope to see nice plots when I return. But one point worth noting: > From testing on a fast machine with the oncore driver, I have seen > average jitter values of under 200ns Which is aweful. If you can't get it under 50 ns don't bother. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpPaOpRlQ4jV.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
On Fri, 29 Nov 2019 21:18:50 -0500, you wrote: >On Wed, 27 Nov 2019 22:08:48 -0500, Trevor N. >wrote: >... >>I have already begun collecting F9T data with gpsd-3.19 (kernel PPS >>enabled) through shm on the latest ntpsec. I'll post 1-day output as >>soon as it's available. >> >The results attached indicate a problem with my setup. Every 2 to 3 >hours a one-second offset appears on SHM(1). There could be several >problems, so I made a few changes at once to return to collecting data >as soon as possible: I didn't notice the post on the User's list which mentioned this problem: >>> > On Wed, 4 Sep 2019 17:09:04 +0100 >>> > shouldbe q931 via users wrote: >>> > >>> > > I saw something odd in ntpviz, which is that the server offset and >>> > > server jitter on SHM(1) goes to 1 second. I thought it would be >>> > > prudent to check another ntpviz, and https://pi3.rellim.com/day/ >>> > > shows similar. I'm still showing the same issue after the changes I made, so I'll try from the gitlab master version. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
Yo Trevor! On Sat, 30 Nov 2019 00:13:18 -0500 "Trevor N. via devel" wrote: > >>I have already begun collecting F9T data with gpsd-3.19 (kernel PPS > >The results attached indicate a problem with my setup. Every 2 to 3 > >hours a one-second offset appears on SHM(1). Known bug in 3.19. The major time refactor fixed it, dunno exactly why. Try git head. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpxLgcyc83L6.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
Yo Trevor! On Fri, 29 Nov 2019 21:18:50 -0500 "Trevor N. via devel" wrote: > * The F9T was not in its factory configuration, so I restored its > default configuration. I then disabled all systems besides GPS, > increased the mask angle to 20 degrees, and disabled NMEA output. This is why I have asked for you to document your config procedure. This whould be easy with a few ubxtool commands. My experiments with the mask angle have led me to just let the u-blox pick the best brids with the default setting. > * The module's PPS offset was -100ms; changed to +0.1ms > > Collection has been restarted. That sounds like you were on the wrong edge. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgp8OKTb3RJOd.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
Yo Udo! On Fri, 28 Sep 2018 06:11:55 +0200 Udo van den Heuvel via devel wrote: > How or when will the ublox refclock be added to ntpsec? Is there any point to it without the matching kernel driver? RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgp2fSYQR5no0.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
> Is there any point to it without the matching kernel driver? Has anybody tried asking for the "echo" from user space? That is: grab time raise modem signal grab time read timestamp over serial port If you precede that with grab time lower modem signal I think that will warm up most of the cache. Another interesting experiment would be to see how much of a difference that makes. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
Gary, On 28/09/2018 08:49, Gary E. Miller via devel wrote: On Fri, 28 Sep 2018 06:11:55 +0200 Udo van den Heuvel via devel wrote: How or when will the ublox refclock be added to ntpsec? Is there any point to it without the matching kernel driver? Tom added echo functionality to the LPT PPS client. (not yet in the kernel but we can test...) So if we can have ublox data via USB, we can have PPS/ECHO via LPT. Else, we have to enable some NMEA messages on the ublox and do similar with NMEA and PPS clocks. Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
Yo Udo! On Fri, 28 Sep 2018 11:38:46 +0200 Udo van den Heuvel wrote: > > Is there any point to it without the matching kernel driver? > > Tom added echo functionality to the LPT PPS client. (not yet in the > kernel but we can test...) Maybe you can test, I have no way to test. > So if we can have ublox data via USB, we can have PPS/ECHO via LPT. I'm lost, what does USB have to do with anything? > Else, we have to enable some NMEA messages on the ublox and do > similar with NMEA and PPS clocks. I'm still lost... But that is not a problem. Go forth, test, code, repeat. When it works for you, and the PPS patches are in the kernel, tell us how it works and we'll patch ntpd. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpPtLpUF8_9z.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
On 28/09/2018 20:34, Gary E. Miller via devel wrote: Is there any point to it without the matching kernel driver? Tom added echo functionality to the LPT PPS client. (not yet in the kernel but we can test...) Maybe you can test, I have no way to test. So if we can have ublox data via USB, we can have PPS/ECHO via LPT. I'm lost, what does USB have to do with anything? The ublox module https://www.csgshop.com/product.php?id_product=240 has USB via e.g. this breakout board https://www.csgshop.com/product.php?id_product=239; USB provides power and data connection. Else, we have to enable some NMEA messages on the ublox and do similar with NMEA and PPS clocks. I'm still lost... But that is not a problem. Go forth, test, code, repeat. When it works for you, and the PPS patches are in the kernel, tell us how it works and we'll patch ntpd. OK great news! Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
Yo Udo! On Sat, 29 Sep 2018 05:38:43 +0200 Udo van den Heuvel wrote: > > I'm lost, what does USB have to do with anything? > > The ublox module https://www.csgshop.com/product.php?id_product=240 > has USB via e.g. this breakout board > https://www.csgshop.com/product.php?id_product=239; USB provides > power and data connection. How do you get the PPS into the host? PPS over USB is hardly good to 1 millisecond. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgphXDYJ1GjA7.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
On 29/09/2018 05:45, Gary E. Miller via devel wrote: How do you get the PPS into the host? PPS over USB is hardly good to 1 millisecond. LPT. Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
