Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Having a linux box (Pi) dedicated as a time server should mean you have consistent delays? To offload time server requests so they don't affect disciplining response/timing, would it be worthwhile having one Pi dedicated to being disciplined by the GPS, then have that pi discipline a second Pi that handles time server requests? PPS-Client measures the delay of a Pi GPIO port and over time adjusts the PPS to compensate. I'd think PPS-Client could be modified to process the sawtooth. And possibly to adjust for the delays in writing to system time? The M8T's two EXTINT (External Interrupt) pins keep nagging me that the resulting timestamp (Timemark UBX-TIM-TM2 message) suggests that such a GNSS chip timestamp (not the iTOW value) should be able to be used to advantage, say to measure the net delays in getting a PPS to discipline system time. - Would the difference between a timestamp of Linux system time and a chip-internal timestamp provide a meaningful and worthwhile adjustment, to system time or to the incoming PPS? - Would successive pairs of timestamps provide the net delay in writing such a corrected system time, allowing for a further refined correction? - Should such a correction be an absolute adjustment based on the pair delta, or should a period of deltas be smoothed and applied over time? - Would/could such a correction (measuring and adjusting based on the end result of system time) provide a superior result in system time than a sawtooth corrected PPS triggering a write to system time? Michael On 21/05/2018 3:21 PM, Gary E. Miller wrote: Gregory! On Mon, 21 May 2018 19:06:17 + Gregory Maxwell wrote: My best guess is that the magnitude of sawtooth error is just not large enough to matter for typical applications of linux PPS. No need to guess. I recently posted that the RasPi 3B granularity is 52 nano Seconds and the PPS offset reported by UBX-TP is double that! So, clearly it matters. I'll do more data logging to get harder numbers. 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 ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] NEO-M8N vs. NEO-M8T
On May 21, 2018, at 11:19, Gary E. Miller wrote: > Now, how to I tell the Linux kernel to apply that correction? I honestly don’t understand how this would be used in a meaningful way via the Linux kernel. The nanoseconds of correction for the PPS signal seems a small nit compared with the microseconds of error introduced by the kernel’s interrupt handling. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Gary E. Miller writes: > Which I always thought was pointless, that only works for a fixed > antenna. Any GPS in a fixed position lab will have a good rooftop > antenna with clear skyview. Except when it doesn't and then the ability to survive on fewer visible/good satellites without going into holdover is most welcome. > Except that requires a post process step, so not useful for real time. No, you can very much use it to inform a consumer of the PPS in realtime about the sub-quantization phase shift and have the PLL take this error refinement into account. > I just looked at the 'U-blox 8 Receiver Description' and it makes no > mention of sawtooh anything. Is that in a different doc? No, it's in there, look for the UBX-TIM series of messages, specifically TOS and TP. However, it talks about offsets of the time pulse, not a sawtooth. But there's a more specific description for series 6 timing receivers, most if not all of which will be applicable to your series 8 module as well: https://www.u-blox.com/sites/default/files/products/documents/Timing_AppNote_(GPS.G6-X-11007).pdf > I'll also test Surevey-In mode to see how much that helps. _Any_ error in the surveyed position will show up as timing error that also depends on the GPS constellation. I think Lady Heather provides a special plot to map these deviations to the GPS sky tracks. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] NEO-M8N vs. NEO-M8T
Hi Simple answer on any GPSDO is always “that depends”. The sawtooth correction improves the PPS into the device by at least an order of magnitude on most GPS modules. Less noise in pretty much always equates to less noise out. It also takes care of hanging bridges ( sawtooth stuck to one side) that will pass through just about any control loop. The Furuno GT-87 parts are a bit of an exception to the rule. They only improve by about 3 to 5X when sawtooth correction is applied. Yes that’s looking at a 1 second measure. As you get out to 100,000 seconds things get a bit muddier. You also are down in the parts in 10^-13 ( or lower) range so it may or may not be that big a deal. With most designs, the emphasis is on “how fast can I cross over to GPS?”. Once you get crossed over, the oscillator (or other flywheel) in your GPSDO really does not matter. Getting that done at 100 seconds vs 1,000 *is* a big deal. Bob > On May 21, 2018, at 5:11 PM, Chris Caudle wrote: > > On Mon, May 21, 2018 2:23 pm, Gary E. Miller wrote: >> I look forward to your patch! > > My GPSDO doesn't have sawtooth error, so limited interest for me. > > How much does one of those u-blox modules cost? > > How would you tell if it made the gpsd performance better? I think that > question came up a couple of weeks ago, most of the ways to check time > stability involve hardware test equipment logging electrical signals, and > there isn't a good way to get an electrical signal generated cleanly from > the gpsd software clock. > > Is there a way to have a timestamp log from another instance of a PPS > driver (another meaning the first instance is the one in use by ntpd)? So > you could have a PPS driver log timestamps from a really high quality > input signal, such that any variation in the timestamps was due to the > clock variation and not from the input signal, and then see if the > variation in timestamps was less after adding sawtooth correction to gpsd. > That's the only idea I can up up with off the top of my head to check > whether such a patch would actually improve the clock estimate noticeably. > In essence this is like trying to build a GPSDO without being able to see > the output of the oscillator directly, so the normal approach to measuring > stability with TICC, counters, phase noise analyzers, etc. doesn't really > work. > > -- > Chris Caudle > > > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] NEO-M8N vs. NEO-M8T
On Mon, May 21, 2018 2:23 pm, Gary E. Miller wrote: > I look forward to your patch! My GPSDO doesn't have sawtooth error, so limited interest for me. How much does one of those u-blox modules cost? How would you tell if it made the gpsd performance better? I think that question came up a couple of weeks ago, most of the ways to check time stability involve hardware test equipment logging electrical signals, and there isn't a good way to get an electrical signal generated cleanly from the gpsd software clock. Is there a way to have a timestamp log from another instance of a PPS driver (another meaning the first instance is the one in use by ntpd)? So you could have a PPS driver log timestamps from a really high quality input signal, such that any variation in the timestamps was due to the clock variation and not from the input signal, and then see if the variation in timestamps was less after adding sawtooth correction to gpsd. That's the only idea I can up up with off the top of my head to check whether such a patch would actually improve the clock estimate noticeably. In essence this is like trying to build a GPSDO without being able to see the output of the oscillator directly, so the normal approach to measuring stability with TICC, counters, phase noise analyzers, etc. doesn't really work. -- Chris Caudle ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] NEO-M8N vs. NEO-M8T
On 21 May 2018 at 21:24, Mark Sims wrote: > > One thing to look out for when messing with sawtooth messages is the question of does the message come > out before or after the PPS pulse... good look finding the answer in the receiver documentation... > > "After" seems to be the most common answer. That makes hardware/delay line compensation rather tricky. > Sometimes you can use the antenna cable delay / pps offset commands to shift the pulse before the true > position (assuming that they support negative offsets) and use a longer delay line to add the tweak back in. In the protocol specification for the Furuno GT-87 ( from, for example: https://www.marutsu.co.jp/contents/shop/marutsu/ds/GT-87ProtocolSpecifications.pdf ) the sawtooth correction figure is given in the CRX message, at the top of page 30 of that document says the figure given refers to the second before last (t-1) ! Peter ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] NEO-M8N vs. NEO-M8T
See Marks recent message about whether the offset applies to the next or previous PPS. For the rest of this, I'll assume next since it's simpler to describe. We can discuss the other/harder case if you agree that the rest of this makes sense. g...@rellim.com said: > Your concept of 'real time' does not match mine. The correction message arrives before the PPS. What's not real-time about that? You don't need any data from the future. > Also, how does that get me to the gola of a good PPS to feed into the Linux > PPS kernel module? I doubt Linux would accept a patch to put gpsd, and > more, into the kernel to read GPS and adjust the PPS. You don't fix the PPS, you fix the software processing the PPS to use the offset. Assuming you are using gpsd, you fix the serial side of gpsd to save the offset and the PPS side uses that offset to correct the PPS offset and then pass the corrected value to ntpd rather than the raw value. Linux/ntpd actually has two modes of PPS processing. The normal mode is that ntpd tells the kernel how to adjust the drift and offset. In that case, the gpsd processing described above would work. There is another mode where the PLL is done in the kernal and ntpd sits off to the side and watches, mostly doing a sanity check. This option, NTP_PPS, is not included in most kernels since it conflicts with NO_HZ_COMMON which saves power. I haven't checked the code. ntpd has a refclock config option for the offset. If that works for the kernel PLL, then the latest sawtooth correction could be passed in each second. If that doesn't work yet, it would be a small kernel mod to fix. Another option would build some hardware to apply the correction. See Mark's recent message and/or the archives. There are chips that do the adjustable delays. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Hi Backing up a bit …. If this is all about a system that can quantize to 52 ns at best … your ADEV plot shows everything *well* below that at all offsets you display. If you assume a +/- 1 LSB sort of quantization, you are out to 104 ns. That’s 10X anything on the plot. You would very much need to dig into just how the i/o structure on the device actually handles asynchronous inputs to be sure of what it really is doing. There are a lot of “debounce / re-synch” sort of structures that get pasted into devices these days. Bob > On May 21, 2018, at 3:21 PM, Gary E. Miller wrote: > > Gregory! > > On Mon, 21 May 2018 19:06:17 + > Gregory Maxwell wrote: > >> My best guess is that the magnitude of sawtooth error is just not >> large enough to matter for typical applications of linux PPS. > > No need to guess. I recently posted that the RasPi 3B granularity is > 52 nano Seconds and the PPS offset reported by UBX-TP is double that! > > So, clearly it matters. > > I'll do more data logging to get harder numbers. > > 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 > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] NEO-M8N vs. NEO-M8T
Richard McCorkle on his own GPSDO design had a separate PIC keep track of the saw tooth information from a M12 ad and subtract during the filter time constant and transferd the sum to the filter for processing. Bert Kehren In a message dated 5/21/2018 2:55:44 PM Eastern Standard Time, ch...@chriscaudle.org writes: On Mon, May 21, 2018 1:52 pm, Chris Caudle wrote: > On Mon, May 21, 2018 1:19 pm, Gary E. Miller wrote: >> Now, how to I tell the Linux kernel to apply that correction? > > Have the PPS driver accept the correction before logging the PPS > timestamp. Or just have the PPS driver log the raw timestamp, then have the PLL engine in ntpd incorporate the corrections into the math of the control loop. Presumably ntpd will be getting the information passed in from gpsd, so the clock control daemon should have the correction information in plenty of time before the next PPS pulse gets logged. -- Chris Caudle ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] NEO-M8N vs. NEO-M8T
Yo Mark! On Mon, 21 May 2018 19:21:25 + Mark Sims wrote: > It looks like you have slipped a decimal point somewhere (also that > "ps" label is wrong). Yes, seemed 10x too high to me too. But the doc for UBX-TIM-TP clearly says 'ps'. UBX-TIM-TP: qErr ps Quantization error of time pulse (not supported for the FTS product variant). Here is another data point, with the raw data so you can check the decode: Class: TIM(0xd) ID: TP(0x1), len: 0x10 payload: f0fb5509e7d6d2070a00 tow:1566300.0 qErr:-0.00105210 ps, week:2002 flags:0xa refInfo:0x0 is GPS, UTC available Sure looks like 105 nano seconds to me. If I'm wrong I'd love to know where. > I have an M8N running here and the report > sawtooth errors are all within a +/- 10 ns span. (and LEA-5T is +/- > 5ns). Many things could explain the difference. We seem to only differ by 5x or 10x. Also, my ADEV plot clearly showed the NEO-M8N adev was better than the NEO-M8T adev at tau=0, so your observations match mine. Right now I'm doing a survey-in. Then I'll grab a days worth of TICC data. After that I'll go back and get long term standard deviations for qErr in Stationary and Survey-in modes. That, of course, will take days. 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 pgpy6EpQTaJpb.pgp Description: OpenPGP digital signature ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] NEO-M8N vs. NEO-M8T
Yo Chris! On Mon, 21 May 2018 13:55:23 -0500 "Chris Caudle" wrote: > On Mon, May 21, 2018 1:52 pm, Chris Caudle wrote: > > On Mon, May 21, 2018 1:19 pm, Gary E. Miller wrote: > >> Now, how to I tell the Linux kernel to apply that correction? > > > > Have the PPS driver accept the correction before logging the PPS > > timestamp. > > Or just have the PPS driver log the raw timestamp, then have the PLL > engine in ntpd incorporate the corrections into the math of the > control loop. Presumably ntpd will be getting the information passed > in from gpsd, so the clock control daemon should have the correction > information in plenty of time before the next PPS pulse gets logged. I look forward to your patch! 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 pgpiFYVgSKpnB.pgp Description: OpenPGP digital signature ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Gregory! On Mon, 21 May 2018 19:06:17 + Gregory Maxwell wrote: > My best guess is that the magnitude of sawtooth error is just not > large enough to matter for typical applications of linux PPS. No need to guess. I recently posted that the RasPi 3B granularity is 52 nano Seconds and the PPS offset reported by UBX-TP is double that! So, clearly it matters. I'll do more data logging to get harder numbers. 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 pgpRzSV8XavdG.pgp Description: OpenPGP digital signature ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
On Mon, May 21, 2018 at 5:54 PM, Gary E. Miller wrote: > Also, how does that get me to the gola of a good PPS to feed into the > Linux PPS kernel module? I doubt Linux would accept a patch to put > gpsd, and more, into the kernel to read GPS and adjust the PPS. Considering that sawtooth error is something found in virtually every GPS receiver I've previously been somewhat surprised that the linux PPS stuff did not have support for it. My best guess is that the magnitude of sawtooth error is just not large enough to matter for typical applications of linux PPS. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] NEO-M8N vs. NEO-M8T
On Mon, May 21, 2018 1:52 pm, Chris Caudle wrote: > On Mon, May 21, 2018 1:19 pm, Gary E. Miller wrote: >> Now, how to I tell the Linux kernel to apply that correction? > > Have the PPS driver accept the correction before logging the PPS > timestamp. Or just have the PPS driver log the raw timestamp, then have the PLL engine in ntpd incorporate the corrections into the math of the control loop. Presumably ntpd will be getting the information passed in from gpsd, so the clock control daemon should have the correction information in plenty of time before the next PPS pulse gets logged. -- Chris Caudle ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] NEO-M8N vs. NEO-M8T
On Mon, May 21, 2018 1:19 pm, Gary E. Miller wrote: > Now, how to I tell the Linux kernel to apply that correction? Have the PPS driver accept the correction before logging the PPS timestamp. -- Chris Caudle ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Hi > On May 21, 2018, at 2:08 PM, Gary E. Miller wrote: > > Yo Bob! > > On Mon, 21 May 2018 14:00:41 -0400 > Bob kb8tq wrote: > Ok, are you trying to hold close to UTC or simply have a second that is as close to 1 second as possible? >>> >>> Yes. One follows the other. >> >> Not really, you can have a source of seconds that are all within 0.1 >> ns of the right length but are offset from UTC by 200 ns. ( stable >> but not accurate) >> >> You can have a series of seconds that are all within 10 ns of UTC, >> but one may be 20 ns to short and the next is 20 ns to long. >> ( accurate but not stable ) >> >> So, which of the two is more important? > > UTC is most important (to me), but if one has perfect UTC, then one also > has perfect seconds. Except that you are doing a design. That involves tradeoffs. Pre-processing a thing message that comes in 800 ms before a pulse does not sound like a big deal to me. In your design it apparently *is* a big deal. If you indeed want very tight UTC, that involves very similar sorts of things. There are a *lot* of delays to be worked out. The offsets between GPS time and UTC need to be downloaded and summed into the servo as well. A GPSDO ( or anything that works like one) will have accurate second to second timing. In a very general sense, it does not care about a time offset. A fixed delay of 100 ns is no different than a fixed delay of 200 ns as far as it’s output or it’s function. So, no, it’s not a drop dead simple choice. Bob > > 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 > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] NEO-M8N vs. NEO-M8T
Yo Scott! On Mon, 21 May 2018 13:08:06 -0500 Scott Newell wrote: > >The NEO-M8T is an FTS product. > > Are you sure about that? I thought the M8T was timing, and the M8F > was FTS. Please check your firmware version string against the table > on page 8. I stand corrected. I do see UBX-TIM-TP: Class: TIM(0xd) ID: TP(0x1), len: 0x10 tow:1519310.0 qErr:-0.00048400 ps, week:2002 flags:0xa refInfo:0x0 is GPS, UTC available Which says the next PPS is going to be -48.4 nano seconds out. Similar to the 52 nano seconds quantization error of a RasPi 3B. Here is another one, -101 nano seconds out: Class: TIM(0xd) ID: TP(0x1), len: 0x10 tow:1522360.0 qErr:-0.00101900 ps, week:2002 flags:0xa refInfo:0x0 is GPS, UTC available That is more than double my quantizaation error! Now, how to I tell the Linux kernel to apply that correction? 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 pgpKCL0vRvDzZ.pgp Description: OpenPGP digital signature ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Hi Gary, It sounds like you need some special hardware that corrects the pulse timing before feeding it out. Richard Hambley's CNS-II did exactly that, using a programmable delay-line - see: https://www.cnssys.com/cnssys.php I seem to remember discussion about that in the Time-Nuts archives. I have one, and it is excellent (and Richard was very helpful), but was "only" accurate to a nanosecond or two - excellent then, but you can now get that natively from the Furuno. But if you were willing to build some hardware and use that principle on the Furuno, with (a lot of!) care you should be able to get a very stable and accurate output signal. Peter ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Yo Bob! On Mon, 21 May 2018 14:00:41 -0400 Bob kb8tq wrote: > >> Ok, are you trying to hold close to UTC or simply have a second > >> that is as close to 1 second as possible? > > > > Yes. One follows the other. > > Not really, you can have a source of seconds that are all within 0.1 > ns of the right length but are offset from UTC by 200 ns. ( stable > but not accurate) > > You can have a series of seconds that are all within 10 ns of UTC, > but one may be 20 ns to short and the next is 20 ns to long. > ( accurate but not stable ) > > So, which of the two is more important? UTC is most important (to me), but if one has perfect UTC, then one also has perfect seconds. 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 pgp8XPhkHfA2F.pgp Description: OpenPGP digital signature ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] NEO-M8N vs. NEO-M8T
At 12:57 PM 5/21/2018, Gary E. Miller wrote: As the manual says: "Quantization error of time pulse (not supported for the FTS product variant)." The NEO-M8T is an FTS product. Are you sure about that? I thought the M8T was timing, and the M8F was FTS. Please check your firmware version string against the table on page 8. I'm sorry, but I don't have any ublox 8 variants handy to test with. (Just a 6T and 7N. I'm nearly certain I've seen the quant error message from the 6T, maybe the 7N as well.) -- newell N5TNL ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Hi > On May 21, 2018, at 1:44 PM, Gary E. Miller wrote: > > Yo Bob! > > On Mon, 21 May 2018 13:41:08 -0400 > Bob kb8tq wrote: > >> Ok, are you trying to hold close to UTC or simply have a second that >> is as close to 1 second as possible? > > Yes. One follows the other. Not really, you can have a source of seconds that are all within 0.1 ns of the right length but are offset from UTC by 200 ns. ( stable but not accurate) You can have a series of seconds that are all within 10 ns of UTC, but one may be 20 ns to short and the next is 20 ns to long. ( accurate but not stable ) So, which of the two is more important? Bob > > 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 > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] NEO-M8N vs. NEO-M8T
Yo Scott! On Sun, 20 May 2018 22:03:49 -0500 Scott Newell wrote: > At 09:23 PM 5/20/2018, Gary E. Miller wrote: > > >I do not see the keyword 'sawtooth' in the u-blox 8 doc. Can I buy > >a clue? > > UBX-TIM-TP, "Time Pulse Timedata". Look for "Quantization error of > time pulse". I'm seeing this on page 359 of the ublox 8 receiver > description/protocol spec book. As the manual says: "Quantization error of time pulse (not supported for the FTS product variant)." The NEO-M8T is an FTS product. So not on the NEO-M8T. 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 pgpGk1JeWvazK.pgp Description: OpenPGP digital signature ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Yo Hal! On Sun, 20 May 2018 20:22:46 -0700 Hal Murray wrote: > g...@rellim.com said: > > Yeah, which does me zero good real time. I'm putting the PPS into > > a TICC. My TICC has not way to accept real time corrections. So > > that does me no good, except as a post processing step. > > Yes, but that post processing step can be done in real time. > Assuming you are writing the TICC data to a log file: > Read the TICC data. > Read the sawtooth info. > Apply the sawtooth correction. > Write out the updated TICC data. Your concept of 'real time' does not match mine. Also, how does that get me to the gola of a good PPS to feed into the Linux PPS kernel module? I doubt Linux would accept a patch to put gpsd, and more, into the kernel to read GPS and adjust the PPS. 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 pgpYPohJ7hec_.pgp Description: OpenPGP digital signature ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Yo Bob! On Mon, 21 May 2018 13:41:08 -0400 Bob kb8tq wrote: > Ok, are you trying to hold close to UTC or simply have a second that > is as close to 1 second as possible? Yes. One follows the other. 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 pgpczGhZvqeLC.pgp Description: OpenPGP digital signature ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Hi Ok, are you trying to hold close to UTC or simply have a second that is as close to 1 second as possible? Bob > On May 21, 2018, at 1:33 PM, Gary E. Miller wrote: > > Yo Bob! > > On Mon, 21 May 2018 10:39:33 -0400 > Bob kb8tq wrote: > >>> Yeah, which does me zero good real time. I'm putting the PPS into a >>> TICC. My TICC has not way to accept real time corrections. So that >>> does me no good, except as a post processing step. >>> >> >> You have a *something* to read the TICC output it does not just do it >> all on it’s own. > > Yes, but by then it is not real time. My real goal is to improve > Linux time. I'm not holding my breath for a kernel module that > takes the corrections. Someday. > > 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 > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Yo Bob! On Mon, 21 May 2018 10:39:33 -0400 Bob kb8tq wrote: > > Yeah, which does me zero good real time. I'm putting the PPS into a > > TICC. My TICC has not way to accept real time corrections. So that > > does me no good, except as a post processing step. > > > > You have a *something* to read the TICC output it does not just do it > all on it’s own. Yes, but by then it is not real time. My real goal is to improve Linux time. I'm not holding my breath for a kernel module that takes the corrections. Someday. 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 pgplB8NWTwgfN.pgp Description: OpenPGP digital signature ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Yo Oleg! On Mon, 21 May 2018 18:05:08 +0300 Oleg Skydan wrote: > You can use uBlox u-center software to enable and disable messages > you need, the configuration can be saved. I have not done Windows since the year 2000. Not restarting now. 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 pgpSX7YICfJKI.pgp Description: OpenPGP digital signature ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Hi Ok so they changed that from the earlier parts. Time marches on. Bob > On May 21, 2018, at 1:08 PM, Oleg Skydan wrote: > > > From: "Bob kb8tq" >> You have always been able to poll the time offset message on any of the uBlox >> modules. Getting that message to auto repeat was the traditional issue on >> there >> earlier products. A serial dump would tell you if u-center is getting the >> information >> by polling or not. > > Thanks for the information. I have checked the console dump (of the NEO-6M > module), it does not poll for TIM-TP, the message is sent automatically > (after enabling in u-center). > > Oleg > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
From: "Bob kb8tq" You have always been able to poll the time offset message on any of the uBlox modules. Getting that message to auto repeat was the traditional issue on there earlier products. A serial dump would tell you if u-center is getting the information by polling or not. Thanks for the information. I have checked the console dump (of the NEO-6M module), it does not poll for TIM-TP, the message is sent automatically (after enabling in u-center). Oleg ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Hi You have always been able to poll the time offset message on any of the uBlox modules. Getting that message to auto repeat was the traditional issue on there earlier products. A serial dump would tell you if u-center is getting the information by polling or not. Bob > On May 21, 2018, at 11:05 AM, Oleg Skydan wrote: > > Hi! > > From: "Bob kb8tq" >> Not by default You go through the 390 pages of their manual and eventually >> find the bits to turn this and that on. When you do, those magic bits will >> enable >> the data on a T version and will not enable it on a non-T version. At least >> that’s >> the way it’s worked since the LEA-4T … > > You can use uBlox u-center software to enable and disable messages you need, > the configuration can be saved. > > It looks like the NEO-M8N (non timing one) module should provide sawtooth > correction data (at least the manual does not say that TIM-TP message is > available on timing modules only). I was able to enable TIM-TP message on the > older NEO-6M. You can test if it works with the help of u-center. > > Best! > Oleg > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Hi! From: "Bob kb8tq" Not by default You go through the 390 pages of their manual and eventually find the bits to turn this and that on. When you do, those magic bits will enable the data on a T version and will not enable it on a non-T version. At least that’s the way it’s worked since the LEA-4T … You can use uBlox u-center software to enable and disable messages you need, the configuration can be saved. It looks like the NEO-M8N (non timing one) module should provide sawtooth correction data (at least the manual does not say that TIM-TP message is available on timing modules only). I was able to enable TIM-TP message on the older NEO-6M. You can test if it works with the help of u-center. Best! Oleg ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Hi > On May 20, 2018, at 11:49 PM, Mark Sims wrote: > > I think what Gary really wants is a GPS receiver with the most stable PPS > output available. Unfortunately that’s not how any of these devices are designed to be used. They all ( including the Furuno ) have a sawtooth issue. It’s just how the fundamental process inside them works. > That is probably the Furuno GT-8736... 1.7 nsec sawtooth error. Typical PPS > span is +/- 4 nsec. Also, the Trimble Thunderbolt has 0 sawtooth error. The TBolt is a GPSDO, which is a very different beast. It takes the “sawtooth" error it measures and shoves it into the control loop for the OCXO. The net result is a zero average error vs GPS. That’s how all phase lock based GPSDO’s do things. The tradeoff is the magic word “average” that snuck in there. Depending on the control loop parameters ( and a few other things ) the time out of the GPSDO may be off from GPS time by quite a bit. If “time right now” is what you are after ( this is TimeNuts after all ), a GPSDO may not be the ideal answer …. If “time right now” is the goal, the real time clock corrections you can grab on the internet may well be part of the total solution. Bob > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Hi > On May 20, 2018, at 10:58 PM, Gary E. Miller wrote: > > Yo Bob! > > On Sun, 20 May 2018 22:53:37 -0400 > Bob kb8tq wrote: > >> If you look at the section under “timing (page 79)” in the uBlox >> manual you will find all the fun stuff that makes the T different. >> One of the timing messages includes the time offset between the pps >> output and the real GPS time solution. Page 351 and after are the >> time related commands. The stuff back around page 358 looks like it’s >> got the sawtooth data in it. > > Yeah, which does me zero good real time. I'm putting the PPS into a > TICC. My TICC has not way to accept real time corrections. So that > does me no good, except as a post processing step. > You have a *something* to read the TICC output it does not just do it all on it’s own. The same something at the same time gets the same data on the same pulse to correct it. That’s real time. That device does the math for the correction and presents it instantaneously. That is very much real time. >> Bottom line is that with the sawtooth correction applied, you can get >> down to below 1x10^-9 at one second on your plot. > > Yeah, which does me no good real time. > >> The T version will >> automatically output the magic message with the data in it. > > Not seeing it by default. Not by default You go through the 390 pages of their manual and eventually find the bits to turn this and that on. When you do, those magic bits will enable the data on a T version and will not enable it on a non-T version. At least that’s the way it’s worked since the LEA-4T … Bob > 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 > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Should say 1.7 nsec we also plan to use the GCLK output for what I call a GPS PLL we have done it successfully with low cost u-blox with E-11 frequency results. Bert Kehren In a message dated 5/21/2018 7:49:20 AM Eastern Standard Time, time-nuts@febo.com writes: Our answer was real time correction, see attached, just received boards for Furuno BT-87, with a specification of 1.7 msec. saw tooth, we do not plan on any additional processing.We have experience with Ublox up to 7 but have spend no time on 8, waited on availability of the 87. Digi Key wants $ 100 but found them half that price in Germany. Has any body found a lower price in the US? Bert Kehren In a message dated 5/20/2018 11:12:05 PM Eastern Standard Time, g...@rellim.com writes: Yo Mark! On Mon, 21 May 2018 03:04:23 + Mark Sims wrote: > The sawtooth value is in the 0x0D-0x01 (TIM-TP) message. Third > value, called qErr. 32-bit dword. In picoseconds. How do I feed that into my TICC in real time? 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 ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
g...@rellim.com said: > Yeah, which does me zero good real time. I'm putting the PPS into a TICC. > My TICC has not way to accept real time corrections. So that does me no > good, except as a post processing step. Yes, but that post processing step can be done in real time. Assuming you are writing the TICC data to a log file: Read the TICC data. Read the sawtooth info. Apply the sawtooth correction. Write out the updated TICC data. I'd actually write out the raw TICC and sawtooth info and do the correction later on but the above recipe will drop into your current work flow for making your graphs. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Yo Mark! On Mon, 21 May 2018 03:04:23 + Mark Sims wrote: > The sawtooth value is in the 0x0D-0x01 (TIM-TP) message. Third > value, called qErr. 32-bit dword. In picoseconds. How do I feed that into my TICC in real time? 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 pgpqJWMKvIZOe.pgp Description: OpenPGP digital signature ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] NEO-M8N vs. NEO-M8T
At 09:23 PM 5/20/2018, Gary E. Miller wrote: I do not see the keyword 'sawtooth' in the u-blox 8 doc. Can I buy a clue? UBX-TIM-TP, "Time Pulse Timedata". Look for "Quantization error of time pulse". I'm seeing this on page 359 of the ublox 8 receiver description/protocol spec book. -- newell N5TNL ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Yo Bob! On Sun, 20 May 2018 22:53:37 -0400 Bob kb8tq wrote: > If you look at the section under “timing (page 79)” in the uBlox > manual you will find all the fun stuff that makes the T different. > One of the timing messages includes the time offset between the pps > output and the real GPS time solution. Page 351 and after are the > time related commands. The stuff back around page 358 looks like it’s > got the sawtooth data in it. Yeah, which does me zero good real time. I'm putting the PPS into a TICC. My TICC has not way to accept real time corrections. So that does me no good, except as a post processing step. > Bottom line is that with the sawtooth correction applied, you can get > down to below 1x10^-9 at one second on your plot. Yeah, which does me no good real time. > The T version will > automatically output the magic message with the data in it. Not seeing it by default. 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 ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Hi Ok, let’s back up a bit. The market for “timing” GPS modules is in GPSDO’s and similar devices. Your local network hub or cell tower is very much in a fixed location. They don’t put them in backpacks. Survey in and position lock is how it’s done, The sawtooth is the error between the arbitrary ( locked to the TCXO) PPS edge and the “real time” of the PPS edge. The reason it is commonly called sawtooth is the shape of the data that comes out went plotted vs time. The sawtooth can get into a problem known as a hanging bridge when the “tooth” reverses in mid transition. If you look at the section under “timing (page 79)” in the uBlox manual you will find all the fun stuff that makes the T different. One of the timing messages includes the time offset between the pps output and the real GPS time solution. Page 351 and after are the time related commands. The stuff back around page 358 looks like it’s got the sawtooth data in it. Using the sawtooth information involves running it into either a control loop ( the normal case in a GPSDO ) or into some sort of controlled delay line ( far less common ). You need the information every second to feed into the loop along with your measured phase information. There are tons of information about all of this in the archives. There are also a lot of posts that probably will do a more in depth job of bringing you up to speed on all the various terms and issues. Bottom line is that with the sawtooth correction applied, you can get down to below 1x10^-9 at one second on your plot. The T version will automatically output the magic message with the data in it. Bob > On May 20, 2018, at 10:06 PM, Gary E. Miller wrote: > > Yo Bob! > > On Sun, 20 May 2018 19:26:33 -0400 > Bob kb8tq wrote: > >> The “big deal” features on the T series are the ability to do single >> satellite timing > > Which I always thought was pointless, that only works for a fixed > antenna. Any GPS in a fixed position lab will have a good rooftop > antenna with clear skyview. > >> and the auto output of the sawtooth correction >> information. Cranking sawtooth correction into your data will move >> the line down most of the way to the “JL” line. > > Except that requires a post process step, so not useful for real time. > > I just looked at the 'U-blox 8 Receiver Description' and it makes no > mention of sawtooh anything. Is that in a different doc? > > I'll also test Surevey-In mode to see how much that helps. > > 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 > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Hal! On Sun, 20 May 2018 18:42:36 -0700 Hal Murray wrote: > g...@rellim.com said: > > The results were disappointing. See attached. For 8x the price > > all I see is a slightly flatter ADEV curve. > > What were you expecting? I was expecting better, not almost the same. 8x price difference for almost nothing. I woulda hped for 5x better. > How good is your antenna? Very good, roof mounts. And the JL GPSDO I coompared it to was using the same antenna on a splitter. > Can you insert an attenuator and compare them again? Yeah, on my long term TODO list. For now low 50's to high 40s' SNR should be good. I have a good skyview, mostly down to the horizon. > It would also be interesting to see the NEO-M8N with good vs bad antenna. So many experiments, so little time. > It would be interesting to see how well the RINEX location compares > with the surveyed location and/or if using the RINEX location > improves the timing output. I'm working on using the NEO-M8T Survey-In mode now. RINEX later. 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 pgpnvfTWaDCTt.pgp Description: OpenPGP digital signature ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Mark! On Mon, 21 May 2018 00:22:17 + Mark Sims wrote: > The main significant difference between the M8N and M8T is the fact > that the M8T can output raw data (and sawtooth). The hardware is > the same so there should not be much difference PPS wise between the > two. Yes, the raw data is nice, but I see nothing about 'sawtooth' in the 'U-blox 8 Receiver Description'. Do they use a different term? The hardware difference is replacing the XO with a TCXO. > I have Lady Heather's RINEX writer working pretty well. I look forward to trying that! > GLONASS and GALILEO have not yet been tested with the M8T... gpsd works with those fine. GLONASS is no help. GALILEO can help a bit. 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 pgpVEU7i9K1Xg.pgp Description: OpenPGP digital signature ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Yo Bob! On Sun, 20 May 2018 19:26:33 -0400 Bob kb8tq wrote: > The “big deal” features on the T series are the ability to do single > satellite timing Which I always thought was pointless, that only works for a fixed antenna. Any GPS in a fixed position lab will have a good rooftop antenna with clear skyview. > and the auto output of the sawtooth correction > information. Cranking sawtooth correction into your data will move > the line down most of the way to the “JL” line. Except that requires a post process step, so not useful for real time. I just looked at the 'U-blox 8 Receiver Description' and it makes no mention of sawtooh anything. Is that in a different doc? I'll also test Surevey-In mode to see how much that helps. 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 pgpvM3yOyehTU.pgp Description: OpenPGP digital signature ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
g...@rellim.com said: > The results were disappointing. See attached. For 8x the price all I see > is a slightly flatter ADEV curve. What were you expecting? How good is your antenna? Can you insert an attenuator and compare them again? It would also be interesting to see the NEO-M8N with good vs bad antenna. As Bob suggests, it will be interesting to see what happens after you apply sawtooth correction. g...@rellim.com said: > The M8T also support raw data, so I can try to use it for RINEX files. It would be interesting to see how well the RINEX location compares with the surveyed location and/or if using the RINEX location improves the timing output. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Hi Just as a reference point, one can get 0.006/0.006/0.012 sort of errors with a fairly rotten antenna and 24 hours of data from a 2004 era L1 / L2 receiver. One key consideration is that the error bars on the “estimated locations” of the reference stations are close to those numbers. Bob > On May 20, 2018, at 8:22 PM, Mark Sims wrote: > > The main significant difference between the M8N and M8T is the fact that the > M8T can output raw data (and sawtooth). The hardware is the same so there > should not be much difference PPS wise between the two. > > I have Lady Heather's RINEX writer working pretty well. Tested with the > LEA-4T/5T/6T, the Furuno GT87, the NVS-08, and the Ashtech Z12 (with L1 and > L2 data). It supports GPS/SBAS/GLONASS/GALILEO (with hooks for future > BEIDOU) observations). GLONASS and GALILEO have not yet been tested with the > M8T... I'm still waiting for the M8T to arrive. It currently outputs RINEX > 2.11 format with some hooks for future v3.03 support. > > L1 only results with 24 hours of observations and "ultra rapid" orbits yield > error estimates in lat/lon/alt of around 0.15/0.15/0.3 meters pk-pk. With 2 > hours of data the errors are around twice that. L1/L2 with the Z12 were > 31/40/88 mm (antenna is in a TERRIBLE location). > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Hi The “big deal” features on the T series are the ability to do single satellite timing and the auto output of the sawtooth correction information. Cranking sawtooth correction into your data will move the line down most of the way to the “JL” line. Bob > On May 20, 2018, at 7:03 PM, Gary E. Miller wrote: > > Time-nuts! > > I have heard for a long time to use the u-blox Time Sync products, instead > of the basic GPS products, for precisin time. > > So I ordered a NEO-M8T and compared it against a plain NEO-M8N. Tests > done using a TAPR-TICC and a JL GPSDO for reference. All tests using the > same antenna and 12 hours of data. > > The results were disappointing. See attached. For 8x the price all I > see is a slightly flatter ADEV curve. > > The M8T also support raw data, so I can try to use it for RINEX files. > > 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 > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.