Discussion:
✘NEO-M8N vs. NEO-M8T
Add Reply
Bob kb8tq
2018-05-21 18:00:41 UTC
Reply
Permalink
Raw Message
Hi
Yo Bob!
On Mon, 21 May 2018 13:41:08 -0400
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
Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Bob kb8tq
2018-05-21 17:13:21 UTC
Reply
Permalink
Raw Message
Hi

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

Bob
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
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Peter Vince
2018-05-21 18:14:19 UTC
Reply
Permalink
Raw Message
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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Mark Sims
2018-05-21 16:09:38 UTC
Reply
Permalink
Raw Message
Lady Heather can configure the various time pulse / PPS outputs on the Ublox receivers. (P keyboard menu) If the receiver supports sawtooth data, the current sawtooth value will be shown at the top of the screen (second column). It can also be shown in the plot area (GD will toggle the sawtooth graph... it is off by default since it tends to be noisy looking mess). Ublox receivers may power up speaking NMEA. If you start Heather up with the /rxu command, it will put it into Ublox binary mode.

The Thunderbolt has no sawtooth error since the GPS RF chain is locked to the OCXO. If the OCXO is too far off freq the Thunderbolt will not be able to track satellites.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Gary E. Miller
2018-05-21 17:54:38 UTC
Reply
Permalink
Raw Message
Yo Hal!

On Sun, 20 May 2018 20:22:46 -0700
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.
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
***@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
Bob kb8tq
2018-05-21 19:56:25 UTC
Reply
Permalink
Raw Message
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
Gregory!
On Mon, 21 May 2018 19:06:17 +0000
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
Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
MLewis
2018-05-22 01:51:26 UTC
Reply
Permalink
Raw Message
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
Gregory!
On Mon, 21 May 2018 19:06:17 +0000
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
Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Chris Caudle
2018-05-21 18:52:43 UTC
Reply
Permalink
Raw Message
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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Gary E. Miller
2018-05-21 19:23:10 UTC
Reply
Permalink
Raw Message
Yo Chris!

On Mon, 21 May 2018 13:55:23 -0500
Post by Chris Caudle
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
***@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
Chris Caudle
2018-05-21 21:11:10 UTC
Reply
Permalink
Raw Message
Post by Gary E. Miller
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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Bob kb8tq
2018-05-21 22:06:16 UTC
Reply
Permalink
Raw Message
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
Post by Chris Caudle
Post by Gary E. Miller
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
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
ew via time-nuts
2018-05-21 13:00:27 UTC
Reply
Permalink
Raw Message
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-***@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, ***@rellim.com writes:

 
Yo Mark!

On Mon, 21 May 2018 03:04:23 +0000
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
***@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-***@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-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Gary E. Miller
2018-05-21 18:08:30 UTC
Reply
Permalink
Raw Message
Yo Bob!

On Mon, 21 May 2018 14:00:41 -0400
Post by Bob kb8tq
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
***@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
Bob kb8tq
2018-05-21 18:48:16 UTC
Reply
Permalink
Raw Message
Hi
Yo Bob!
On Mon, 21 May 2018 14:00:41 -0400
Post by Bob kb8tq
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
Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Gary E. Miller
2018-05-21 02:15:45 UTC
Reply
Permalink
Raw Message
Mark!

On Mon, 21 May 2018 00:22:17 +0000
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
***@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
Mark Sims
2018-05-21 01:20:23 UTC
Reply
Permalink
Raw Message
Most of the post-processing services use reference stations that are surveyed and verified to mm level accuracy. The 13 reference stations used by AUSPOS were uncertainties all less than 4/4/8 mm. Unfortuenatly some of the baselines were rather long.

My antenna is swimming in multi-path and other signal killers. A two story house < 25 feet to the west, tall trees, antenna on a terrace surrounded by low-ish walls with 10 foot columns in the corners, stainless steel gates, etc. Heather suggests an elevation mask of around 40 degrees.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Gary E. Miller
2018-05-21 03:11:06 UTC
Reply
Permalink
Raw Message
Time-Nute!

I'm not sure why my antenna, and skyview, is of such interest. My
NEP-M8N vs NEO-M8T ADEV plot was generated using the same antenna
throush a 3dB splitter. So the relative quality of the M8N and the M8T
is the interesting part.

For full disclocure, attached is a 24 polar plot of the sky view from
the test antenna. Looks pretty good to me.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
***@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
Chris Caudle
2018-05-21 13:23:27 UTC
Reply
Permalink
Raw Message
I do not see the keyword 'sawtooth' in the u-blox 8 doc. Can I buy a
clue?
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


_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Gary E. Miller
2018-05-21 17:28:38 UTC
Reply
Permalink
Raw Message
Yo Chris!

On Mon, 21 May 2018 08:23:27 -0500
Post by Chris Caudle
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).
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
***@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
2018-05-21 17:31:05 UTC
Reply
Permalink
Raw Message
Yo Oleg!

On Mon, 21 May 2018 18:05:08 +0300
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
***@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
Bob kb8tq
2018-05-21 15:05:02 UTC
Reply
Permalink
Raw Message
Hi
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
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Bob kb8tq
2018-05-21 00:45:24 UTC
Reply
Permalink
Raw Message
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
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).
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Gary E. Miller
2018-05-21 02:21:30 UTC
Reply
Permalink
Raw Message
Hal!

On Sun, 20 May 2018 18:42:36 -0700
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
***@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
2018-05-21 03:11:50 UTC
Reply
Permalink
Raw Message
Yo Mark!

On Mon, 21 May 2018 03:04:23 +0000
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
***@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
Mark Sims
2018-05-21 20:24:47 UTC
Reply
Permalink
Raw Message
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.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Peter Vince
2018-05-21 21:08:14 UTC
Reply
Permalink
Raw Message
Post by Mark Sims
One thing to look out for when messing with sawtooth messages is the
question of does the message come
Post by Mark Sims
out before or after the PPS pulse... good look finding the answer in the
receiver documentation...
Post by Mark Sims
"After" seems to be the most common answer. That makes hardware/delay
line compensation rather tricky.
Post by Mark Sims
Sometimes you can use the antenna cable delay / pps offset commands to
shift the pulse before the true
Post by Mark Sims
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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Achim Gratz
2018-05-21 18:41:23 UTC
Reply
Permalink
Raw Message
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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Denny Page
2018-05-21 19:15:06 UTC
Reply
Permalink
Raw Message
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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Loading...