Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T

[MLewis]

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

[Denny Page]

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

[Achim Gratz]

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

[Bob kb8tq]

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

[Chris Caudle]

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

[Peter Vince]

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

[Hal Murray]

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

[Bob kb8tq]

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

[ew via time-nuts]

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

[Gary E. Miller]

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

[Gary E. Miller]

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

[Gary E. Miller]

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

[Gregory Maxwell]

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

[Chris Caudle]

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

[Chris Caudle]

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

[Bob kb8tq]

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

[Gary E. Miller]

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

[Peter Vince]

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

[Gary E. Miller]

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

[Scott Newell]

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

[Bob kb8tq]

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

[Gary E. Miller]

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

[Gary E. Miller]

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

[Gary E. Miller]

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

[Bob kb8tq]

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

[Gary E. Miller]

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

[Gary E. Miller]

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

[Bob kb8tq]

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

[Oleg Skydan]

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

[Bob kb8tq]

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

[Oleg Skydan]

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

[Bob kb8tq]

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

[Bob kb8tq]

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

[ew via time-nuts]

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

[Hal Murray]

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

[Gary E. Miller]

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

[Scott Newell]

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

[Gary E. Miller]

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

[Bob kb8tq]

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

[Gary E. Miller]

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

[Gary E. Miller]

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

[Gary E. Miller]

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

[Hal Murray]

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

[Bob kb8tq]

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

[Bob kb8tq]

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.