[time-nuts] Antenna cable delay compensation

[Mark Sims]

A related question is:  Do you use positive or negative numbers to set the 
antenna cable delay value?  Again, most GPS receiver documentation does not 
say.I think that I've only seen it explicitly mentioned in the Trimble 
documentation and the Oscilloquartz Star-4 documentation.

Also there is the question of does the receiver time message come out before or 
after the 1PPS and what is the message offset time from the 1PPS?   Again, 
rarely documented by the receiver manufacturer.   Lady Heather can measure 
those (if the operating system clock is accurately set)  Heather uses the 
message time offset to adjust the displayed time or get the audible "tick 
clock" aligned to true time.  

Heather has a table of typical message offsets for the supported receivers, but 
measuring and setting the value for your receiver/computer/serial port can 
improve things.
___
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

[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] Sawtooth correction: next or previous PPS

[Bob kb8tq]

Hi

> On May 21, 2018, at 9:13 PM, Hal Murray  wrote:
> 
> 
> hol...@hotmail.com said:
>> 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... 
> 
> Has anybody asked the manufacturers?

At least in the framework of Furuno and myself … yes. Not via email but face to 
face
with their head of design engineering. 

> 
> This should be easy to see if you record the PPS offset referenced to a good 
> clock and compare that to the reported offset.  

The real simple answer is that you have four cases. Pulse before vs pulse after 
plus
adds or subtracts. That’s not so may that you can’t just try it and see. It 
turns out to 
be very obvious when you get the right one. 

Bob


> If the frequency is stable 
> and you are getting a sawtooth (rather than a bridge) then a point on a 
> corrected graph next to the jump in the sawtooth will look good if you have 
> it right or be off by a clock cycle if you have it wrong.
> 
> 
> hol...@hotmail.com said:
>> "After" seems to be the most common answer.  That makes hardware/delay line
>> compensation rather tricky.  ...
> 
> The slides from Tom Clark and Rick Hambly's VLBI talk (page 29) show a before 
> setup.
>  http://www.gpstime.com/files/TOW/tow-time2015.pdf
> 
> You said "most common".  That implies there are both types.  (or 
> documentation errors)  We should make a list of which GPS modules do it which 
> way.
> 
> 
> -- 
> 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.

___
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] Sawtooth correction: next or previous PPS

[Hal Murray]

hol...@hotmail.com said:
> 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... 

Has anybody asked the manufacturers?

This should be easy to see if you record the PPS offset referenced to a good 
clock and compare that to the reported offset.  If the frequency is stable 
and you are getting a sawtooth (rather than a bridge) then a point on a 
corrected graph next to the jump in the sawtooth will look good if you have 
it right or be off by a clock cycle if you have it wrong.


hol...@hotmail.com said:
> "After" seems to be the most common answer.  That makes hardware/delay line
> compensation rather tricky.  ...

The slides from Tom Clark and Rick Hambly's VLBI talk (page 29) show a before 
setup.
  http://www.gpstime.com/files/TOW/tow-time2015.pdf

You said "most common".  That implies there are both types.  (or 
documentation errors)  We should make a list of which GPS modules do it which 
way.


-- 
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.

[time-nuts] A Request to the List

[John Ackermann N8UR]

TVB is traveling and not on-line as much as usual, so in his absence I'm 
going to ask everyone to please consider his request a couple of weeks 
ago to think before you post.


Please keep in mind that time-nuts isn't a chat room, and that every 
message doesn't require an individual response.  It's much better to 
have one thoughtful post than a dozen written on the fly.


Remember that 1800 "new message" flags go up each time you post.

Thanks,
John
___
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.

[time-nuts] NEO-M8N vs. NEO-M8T

[Mark Sims]

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-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] Improving ocxo temp control

[Azelio Boriani]

First, be sure not to measure your  HP52132A stability with the OCXO.
What is your reference source?

On Mon, May 21, 2018 at 7:12 PM, Bob kb8tq  wrote:
> Hi
>
> There are a lot of reasons an OCXO drifts. Temperature control is rarely the 
> issue.
> More likely you are looking at the drift / wander characteristics of the 
> crystal ( and
> components) in the OCXO. The simple answer is to leave it on for a while ( 
> like weeks)
> to allow things to settle out a bit.
>
> The paper that Rick tossed up last week is a pretty good one in terms of 
> temperature
> control issues in an OCXO and what the issues are.
>
> This all assumes you are in a fairly benign environment. If you have lots of 
> drafts, put a
> cardboard box over the unit to shield it. If you room temperature is all over 
> the place, then
> there are a lot of ways to get to ~ 1 or 2C sort of stability in a lab. What 
> you do depends
> a *lot* on what your situation is.
>
> =
>
> So, assuming you *do* want to improve the temperature control:
>
> First you need to take out what’s in there now. If it’s wandering around get 
> rid of it. This
> involves tearing apart the OCXO.
>
> Now take a look at Rick’s paper and redesign the thermal enclosure. Get the 
> heater placement
> and sensor placement right and feed that into a simple controller.
>
> Run some tests over temperature and check out the data. It’s likely your 
> first guess at things
> is not going to be correct.
>
> Try to optimize the heat sources and sensors and re-test the result. 
> Everything interacts so
> this is not a quick process.
>
> Once you are reasonably happy with where things are, start looking at a more 
> fancy controller.
> A simple approach would be feeding thermistor voltage into some 24 bit ADC’s 
> and then
> processing the result with an MCU.
>
> Ok so that’s all a bit much.
>
> =
>
> What happens if you mess with the OCXO from the outside of the package?
>
> You change the heat loss out of the package. This increases the thermal gain. 
> ( less power
> to increase the oven temperature by 1 C ). Assuming the original circuit was 
> balanced
> out, you have made things worse rather than better.
>
> Ok so you do an enclosure with a fan it it so the heat loss doesn’t get less.
>
> You now have more heat loss and the same issue applies. In addition the fan 
> and it’s
> nonsense probably haven’t done the poor little OCXO any good.
>
> When one designs a double oven, the inner oven is optimized for performance 
> *with*
> the outer oven present. Equally, the outer oven is optimized for performance 
> with the
> heat load (and dynamics) of the inner oven.
>
> =
>
> Assuming you still want to head down this road, temperature controllers are 
> no different
> than any control loop. The first place to start is a textbook on control 
> loops and control
> theory. The basics of what a loop does and the terminology are what you are 
> after. Anything
> advanced will assume you understand this part first.
>
> Next up are temperature sensors. Simple answer here is that a glass bead 
> thermistor is
> the way to go. For heat, transistors are the normal go-to device. The 
> controls loop takes
> in the thermistor output and spits out a voltage to change the current 
> through the transistor.
>
> If you have the money for software licenses, the next stop is some good 
> mechanical CAD
> that will feed into thermal modeling. From that you can work out a proper 
> heat flow and
> gradient design. Assuming that is a bit to expensive, you are back to trial 
> and error. There
> are no “just duplicate this” designs that I know of.
>
> Once you have the structure, sensors, heaters, and control you toss it into a 
> temperature
> test chamber. That may be something fancy or something you put together. You 
> run the
> gizmo over temperature and observe what it does. You then optimize the P,I,D 
> coefficients
> in your control loop. Indeed you may not have all of them or you may have an 
> extra one.
>
> ===
>
> Of course one could simply shop for a $20 OCXO on eBay. Even if you have to 
> buy a
> dozen before you find a good one, it’s still cheaper / faster / easier / more 
> likely to succeed
> than all the nonsense above. If this is a commercial design for a product you 
> are going
> to sell, that does not work very well. The same fundamental answer applies. 
> If you need
> better performance, shop for a better oscillator.
>
>
> Lots of fun 
>
>
>
>> On May 21, 2018, at 12:23 PM, Club-Internet Clemgill 
>>  wrote:
>>
>> Thanks for your interesting replies.
>> What I am actually trying to do is the following:
>> I bough a small ocxo (size of half a ping-pong ball) that performs well 
>> (Abracon / AOCJY3_B 10Mhz)
>> Reaching about 5*10E-11 kind of MDEV at low point ("kind of"… because a I 
>> use an HP52132a as input to Timelab)
>> But it’s frequency is slowly drifting with time, with a quasi linear slope.
>> I wondered 

Re: [time-nuts] time-nuts Digest, Vol 166, Issue 44

[Dan Kemppainen]

Mark,

Ditto this. On 6T's and M8T's both.

The 6T's do have an odd issue once in a while, right at the roll over 
limit from +10.whatever nS to -10.whatever nS, sometimes the sawtooth 
value comes in with the wrong sign.


We were playing with the 6T's in a GPSDO, against a good crystal it 
stuck out really well in the graph. A software check in the GPSDO looks 
for this and fixes it. Seemed like it happened about once a week to once 
a month type timeframe.


Have you noticed this in your hardware?

Dan


On 5/21/2018 3:21 PM, time-nuts-requ...@febo.com wrote:

Message: 10
Date: Mon, 21 May 2018 19:21:25 +
From: Mark Sims
To:"time-nuts@febo.com"  
Subject: [time-nuts] NEO-M8N vs. NEO-M8T
Message-ID:



Content-Type: text/plain; charset="iso-8859-1"

It looks like you have slipped a decimal point somewhere (also that "ps" label 
is wrong).   I have an M8N running here and the report sawtooth errors are all within a ± 
10 ns span.   (and LEA-5T is ± 5ns).

___
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] Motorola GPS Antenna?

[Gregory Beat]

I grew up downstate — NE of Quincy, IL and the Motorola TV mfg. operations at 
Quincy closed before the Franklin Park (North) plant.  While there were 
assurances that Panasonic would continue operations at Quincy, local officials 
were caught “off guard” with decision to close a Motorola plant that was less 
than 15 years old.  
My high school electronics instructor (former Motorola) came to new vocational 
wing of high school (1970) as a result of those layoffs and closings.

greg
==
Since timing is everything to TimeNuts ….. :)

The Motorola TV plant ( known as the Franklin Park North plant, not to be 
confused with Franklin Park South where they made …. errr ….. oscillators ) to 
Panasonic in 1974. 

The whole transaction came as quite a shock to the people involved. The guy 
running
the division was very much caught off guard….. He happened to be presenting to 
a group of us the day after the announcement ….

The Panasonic cell tower timing antenna shows up under a *lot* of different 
labels. They do indeed sell it under the Panasonic brand name as well. It is 
regarded as reasonably bullet proof in terms of blocking cell tower RFI.

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] NEO-M8N vs. NEO-M8T

[Mark Sims]

Yes, the Ublox sends ps... whatever software that is processing the message is 
scaling it wrong.  And labeling it wrong...  qErr:-0.00105210 ps... that 
aint' right... no way... no how..
___
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.

[time-nuts] NEO-M8N vs. NEO-M8T

[Mark Sims]

It looks like you have slipped a decimal point somewhere (also that "ps" label 
is wrong).   I have an M8N running here and the report sawtooth errors are all 
within a +/- 10 ns span.   (and LEA-5T is +/- 5ns).

---

> 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.___
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] Motorola GPS Antenna?

[Bob kb8tq]

Hi

Since timing is everything to TimeNuts ….. :)

The Motorola TV plant ( known as the Franklin Park North plant, not to be 
confused with Franklin Park South where they made
…. errr ….. oscillators ) to Panasonic in 1974. The whole transaction came as 
quite a shock to the people involved. The guy running
the division was very much caught off guard….. He happened to be presenting to 
a group of us the day after the announcement ….

The Panasonic cell tower timing antenna shows up under a *lot* of different 
labels. They do indeed sell it under the Panasonic brand
name as well. It is regarded as reasonably bullet proof in terms of blocking 
cell tower RFI.

Bob

> On May 21, 2018, at 2:56 PM, Gregory Beat  wrote:
> 
> Motorola has worked with Matsushita Electric Industrial Co., Ltd (now known 
> as Panasonic Corporation) since 1960s.  Motorola sold their television 
> division to Matsushita in 1970.
> —
> I believe that Motorola and Panasonic jointly developed this GPS antenna. 
> While Motorola exited the GPS receiver business over a decade ago, Panasonic 
> continued to OEM the VIC-100 antenna.
> 
> Synergy has a product page and data sheet for the Panasonic VIC-100 antenna.
> http://www.synergy-gps.com/index.php?option=com_content=view=139=114
> 
> greg, w9gb
> 
> Sent from iPhone 6s
> ___
> 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

[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] Motorola GPS Antenna?

[Gregory Beat]

Motorola has worked with Matsushita Electric Industrial Co., Ltd (now known as 
Panasonic Corporation) since 1960s.  Motorola sold their television division to 
Matsushita in 1970.
—
I believe that Motorola and Panasonic jointly developed this GPS antenna. While 
Motorola exited the GPS receiver business over a decade ago, Panasonic 
continued to OEM the VIC-100 antenna.

Synergy has a product page and data sheet for the Panasonic VIC-100 antenna.
http://www.synergy-gps.com/index.php?option=com_content=view=139=114

greg, w9gb

Sent from iPhone 6s
___
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

[Gary E. Miller]

Yo Chris!

On Mon, 21 May 2018 08:23:27 -0500
"Chris Caudle"  wrote:

> 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).

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


pgpVdk9FAD2pc.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] Improving ocxo temp control

[Bob kb8tq]

Hi

There are a lot of reasons an OCXO drifts. Temperature control is rarely the 
issue. 
More likely you are looking at the drift / wander characteristics of the 
crystal ( and 
components) in the OCXO. The simple answer is to leave it on for a while ( like 
weeks)
to allow things to settle out a bit. 

The paper that Rick tossed up last week is a pretty good one in terms of 
temperature
control issues in an OCXO and what the issues are. 

This all assumes you are in a fairly benign environment. If you have lots of 
drafts, put a 
cardboard box over the unit to shield it. If you room temperature is all over 
the place, then
there are a lot of ways to get to ~ 1 or 2C sort of stability in a lab. What 
you do depends
a *lot* on what your situation is.

=

So, assuming you *do* want to improve the temperature control:

First you need to take out what’s in there now. If it’s wandering around get 
rid of it. This
involves tearing apart the OCXO.

Now take a look at Rick’s paper and redesign the thermal enclosure. Get the 
heater placement
and sensor placement right and feed that into a simple controller. 

Run some tests over temperature and check out the data. It’s likely your first 
guess at things 
is not going to be correct.

Try to optimize the heat sources and sensors and re-test the result. Everything 
interacts so
this is not a quick process.

Once you are reasonably happy with where things are, start looking at a more 
fancy controller.
A simple approach would be feeding thermistor voltage into some 24 bit ADC’s 
and then
processing the result with an MCU. 

Ok so that’s all a bit much.

=

What happens if you mess with the OCXO from the outside of the package? 

You change the heat loss out of the package. This increases the thermal gain. ( 
less power
to increase the oven temperature by 1 C ). Assuming the original circuit was 
balanced 
out, you have made things worse rather than better. 

Ok so you do an enclosure with a fan it it so the heat loss doesn’t get less. 

You now have more heat loss and the same issue applies. In addition the fan and 
it’s
nonsense probably haven’t done the poor little OCXO any good.

When one designs a double oven, the inner oven is optimized for performance 
*with* 
the outer oven present. Equally, the outer oven is optimized for performance 
with the
heat load (and dynamics) of the inner oven. 

=

Assuming you still want to head down this road, temperature controllers are no 
different 
than any control loop. The first place to start is a textbook on control loops 
and control 
theory. The basics of what a loop does and the terminology are what you are 
after. Anything
advanced will assume you understand this part first. 

Next up are temperature sensors. Simple answer here is that a glass bead 
thermistor is
the way to go. For heat, transistors are the normal go-to device. The controls 
loop takes
in the thermistor output and spits out a voltage to change the current through 
the transistor.

If you have the money for software licenses, the next stop is some good 
mechanical CAD
that will feed into thermal modeling. From that you can work out a proper heat 
flow and
gradient design. Assuming that is a bit to expensive, you are back to trial and 
error. There 
are no “just duplicate this” designs that I know of. 

Once you have the structure, sensors, heaters, and control you toss it into a 
temperature 
test chamber. That may be something fancy or something you put together. You 
run the
gizmo over temperature and observe what it does. You then optimize the P,I,D 
coefficients
in your control loop. Indeed you may not have all of them or you may have an 
extra one. 

===

Of course one could simply shop for a $20 OCXO on eBay. Even if you have to buy 
a
dozen before you find a good one, it’s still cheaper / faster / easier / more 
likely to succeed 
than all the nonsense above. If this is a commercial design for a product you 
are going 
to sell, that does not work very well. The same fundamental answer applies. If 
you need
better performance, shop for a better oscillator. 


Lots of fun 



> On May 21, 2018, at 12:23 PM, Club-Internet Clemgill 
>  wrote:
> 
> Thanks for your interesting replies.
> What I am actually trying to do is the following: 
> I bough a small ocxo (size of half a ping-pong ball) that performs well 
> (Abracon / AOCJY3_B 10Mhz)
> Reaching about 5*10E-11 kind of MDEV at low point ("kind of"… because a I use 
> an HP52132a as input to Timelab)
> But it’s frequency is slowly drifting with time, with a quasi linear slope. 
> I wondered if placing it in a third ovenized enclosure could improve things. 
> I tried a few experiments but seems that the temp needs to be very accurately 
> controlled. 
> Any similar experience ? 
> Could you suggest papers describing high performance analog or digital 
> controllers ? 
> Thx, 
> Gilles.
> 
> 
>> Le 19 mai 2018 à 16:09, Bob kb8tq  a 

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] Improving ocxo temp control

[Club-Internet Clemgill]

Thanks for your interesting replies.
What I am actually trying to do is the following: 
I bough a small ocxo (size of half a ping-pong ball) that performs well 
(Abracon / AOCJY3_B 10Mhz)
Reaching about 5*10E-11 kind of MDEV at low point ("kind of"… because a I use 
an HP52132a as input to Timelab)
But it’s frequency is slowly drifting with time, with a quasi linear slope. 
I wondered if placing it in a third ovenized enclosure could improve things. 
I tried a few experiments but seems that the temp needs to be very accurately 
controlled. 
Any similar experience ? 
Could you suggest papers describing high performance analog or digital 
controllers ? 
Thx, 
Gilles.


> Le 19 mai 2018 à 16:09, Bob kb8tq  a écrit :
> 
> Hi
> 
> One key point about the need for “zero gradient”: 
> 
> Crystals and many other components are quite sensitive to thermal gradients. 
> Very small 
> fractions of a degree (as a gradient ) can have significant impact on the 
> frequency of an 
> oscillator. 
> 
> One of many “interesting things” about fiddling about OCXO’s. 
> 
> The equally frustrating thing about this is that unless you can tease kind 
> paper authors
> into posting things ( thanks Rick !!) the papers are behind pay walls. I 
> pretty much despise
> that practice. Referencing papers that send people off to spend money ….not 
> so much.
> 
> Bob
> 
>> On May 19, 2018, at 12:03 AM, Richard (Rick) Karlquist 
>>  wrote:
>> 
>> In my experience, the oven temperature controller is rarely
>> the determining factor for static oven performance.  This article
>> explains what the real determining factors are:
>> 
>> http://www.karlquist.com/oven.pdf
>> 
>> An analog oven temperature controller will be limited in
>> its dynamics by how much capacitance you are able to
>> design with.  Digital controllers get around this as well
>> as having the capability of double integration for much
>> better transient response.
>> 
>> Rick
>> 
>> On 5/18/2018 11:03 AM, Gilles Clement wrote:
>>> Hi,
>>> I am trying to improve performance of an OCXO.
>>> Could you point me at a good design of a high resolution oven temperature 
>>> controler please ? Preferably analog.
>>> Thx much,
>>> Gilles.
>>> ___
>>> 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] Motorola GPS Antenna?

[Clint Jay]

Is it worth buying for that money if it is?

On Mon, 21 May 2018 5:13 pm Dan Rae,  wrote:

> On 5/21/2018 8:24 AM, Clint Jay wrote:
> > Found on eBay with no further information, can anyone identify?
> >
> >
> https://www.ebay.co.uk/itm/EX-MOD-Motorola-Antenna/323177970249?hash=item4b3ee87a49:g:tHIAAOSwUCZavUAe
> >
> It looks like the standard "Marine" antenna, probably 5v, loads of gain
> (30 dB?), like the one I have up on my roof.  There should be a part
> number under the rubber gasket if you want to ask the seller to have a
> look.
>
> Dan
>
> ___
> 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] Motorola GPS Antenna?

[Dan Rae]

On 5/21/2018 8:24 AM, Clint Jay wrote:

Found on eBay with no further information, can anyone identify?

https://www.ebay.co.uk/itm/EX-MOD-Motorola-Antenna/323177970249?hash=item4b3ee87a49:g:tHIAAOSwUCZavUAe

It looks like the standard "Marine" antenna, probably 5v, loads of gain 
(30 dB?), like the one I have up on my roof.  There should be a part 
number under the rubber gasket if you want to ask the seller to have a look.


Dan

___
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] ✘NEO-M8N vs. NEO-M8T

[Mark Sims]

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-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] Motorola GPS Antenna?

[Clint Jay]

Found on eBay with no further information, can anyone identify?

https://www.ebay.co.uk/itm/EX-MOD-Motorola-Antenna/323177970249?hash=item4b3ee87a49:g:tHIAAOSwUCZavUAe

-- 
Clint. M0UAW IO83

*No trees were harmed in the sending of this mail. However, a large number
of electrons were greatly inconvenienced.*
___
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

[Chris Caudle]

On Sun, May 20, 2018 9:23 pm, Gary E. Miller wrote:
> 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-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.