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

Yo Bob!

On Sun, 20 May 2018 19:26:33 -0400
Bob kb8tq kb8tq@n1k.org wrote:

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 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
gem@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

On Sun, May 20, 2018 9:06 pm, Gary E. Miller wrote:

No, it can be used for real time, that is how GPSDO control loops back out
the effects of sawtooth error so it does not add additional unnecessary
noise into the control loops for the clean up oscillator.

--
Chris Caudle

Yo Chris!

On Sun, 20 May 2018 21:18:02 -0500
"Chris Caudle" chris@chriscaudle.org wrote:

I do not see the keyword 'sawtooth' in the u-blox 8 doc.  Can I buy a clue?

RGDS
GARY

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@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

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

Yo Bob!

On Sun, 20 May 2018 22:53:37 -0400
Bob kb8tq kb8tq@n1k.org 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.

Yeah, which does me no good real time.

Not seeing it by default.

RGDS
GARY

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@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

At 09:23 PM 5/20/2018, Gary E. Miller wrote:

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

On Sun, May 20, 2018 9:23 pm, Gary E. Miller wrote:

Sawtooth is what it looks like when you plot the quantization error of the
PPS output, the documentation will just refer to it as quantization error.

Referencing this doc (not sure it is the exact match for your model)
https://www.u-blox.com/sites/default/files/products/documents/u-blox8-M8_ReceiverDescrProtSpec_%28UBX-13003221%29_Public.pdf

18.1 Introduction
u-blox receivers include a time pulse function providing clock pulses with
configurable duration and frequency.
The time pulse function can be configured using the UBX-CFG-TP5 message.
The UBX-TIM-TP
message provides time information for the next pulse, time source and the
quantization error of the output pin

The UBX-TIM-TP message is described in:
32.21.8.1 Time Pulse Timedata
byte offset 8, name: qErr unit: ps
Quantization error of time pulse (not supported for the FTS product variant).

I believe that means  you ready byte offset 8 of that message, and it
tells you how many picoseconds the next PPS output is expected to be early
or late compared to the nominally correct location of the PPS pulse.
Inject that offset into the math for your software implemented PLL and you
can cancel out that noise caused by the GPS clock used to generate the PPS
being asynchronous to the GPS satellite clocks.

This document has some nice graphs of sawtooth shaped quantization errors,
just search for sawtooth:
https://ivscc.gsfc.nasa.gov/meetings/tow2011/Hambly.Sem.pdf

--
Chris Caudle

Hi

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.

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

Hi!

From: "Bob kb8tq" kb8tq@n1k.org

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

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

From: "Bob kb8tq" kb8tq@n1k.org

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

Hi

Ok so they changed that from the earlier parts. Time marches on.

Bob

Yo Chris!

On Mon, 21 May 2018 08:23:27 -0500
"Chris Caudle" chris@chriscaudle.org wrote:

Notice the: not supported for the FTS product

So, not on the NEO-M8T

RGDS
GARY

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@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

Yo Oleg!

On Mon, 21 May 2018 18:05:08 +0300
Oleg Skydan olegskydan@gmail.com wrote:

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
gem@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

Yo Bob!

On Mon, 21 May 2018 10:39:33 -0400
Bob kb8tq kb8tq@n1k.org wrote:

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
gem@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

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

Yo Bob!

On Mon, 21 May 2018 13:41:08 -0400
Bob kb8tq kb8tq@n1k.org wrote:

Yes.  One follows the other.

RGDS
GARY

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@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

Yo Scott!

On Sun, 20 May 2018 22:03:49 -0500
Scott Newell newell+timenuts@n5tnl.com wrote:

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
gem@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

Hi

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

At 12:57 PM 5/21/2018, Gary E. Miller wrote:

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

Yo Bob!

On Mon, 21 May 2018 14:00:41 -0400
Bob kb8tq kb8tq@n1k.org wrote:

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
gem@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

Yo Scott!

On Mon, 21 May 2018 13:08:06 -0500
Scott Newell newell+timenuts@n5tnl.com wrote:

I stand corrected.  I do see UBX-TIM-TP:

Class: TIM(0xd) ID: TP(0x1), len: 0x10
tow:1519310.000000000 qErr:-0.000000048400 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.000000000 qErr:-0.000000101900 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
gem@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

Gary E. Miller writes:

Except when it doesn't and then the ability to survive on fewer
visible/good satellites without going into holdover is most welcome.

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.

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

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

Hi

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

On Mon, May 21, 2018 1:19 pm, Gary E. Miller wrote:

Have the PPS driver accept the correction before logging the PPS timestamp.

--
Chris Caudle

On Mon, May 21, 2018 1:52 pm, Chris Caudle wrote:

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

On May 21, 2018, at 11:19, Gary E. Miller gem@rellim.com wrote:

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.

Yo Chris!

On Mon, 21 May 2018 13:55:23 -0500
"Chris Caudle" chris@chriscaudle.org wrote:

I look forward to your patch!

RGDS
GARY

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@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

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, chris@chriscaudle.org writes:

 
On Mon, May 21, 2018 1:52 pm, Chris Caudle wrote:

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.

On Mon, May 21, 2018 2:23 pm, Gary E. Miller wrote:

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

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