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