[time-nuts] GPS noise reduction

[Richard H McCorkle]

> Richard,
>
> One more thing, maybe I missed this earlier in the thread, but
> can you really call it "sawtooth correction" when you apply a
> receiver reported correction (with 1 ns granularity) to a 1PPS
> signal (with 9 ns RMS or +/- 15 p-p jitter) as coarsely measured
> by a 100 MHz TIC (with 10 ns resolution)?
>
> I haven't done the math, but it seems like it's at least an order
> of magnitude less precise of a correction than the normal case
> where one makes ns or sub-ns measurements and then applies
> a ns-resolution correction in software. This is what both Tac32
> (for Oncore) and Tboltmon (for Thunderbolt) do when you use
> one serial port for the GPS receiver and another serial port for
> a 53131/2 time interval counter.
>
> It just seems the small ns-level corrections from your receiver
> get rather lost in the large 10 ns resolution of your TIC. More
> like a staircase than a sawtooth, perhaps?
>
> /tvb
>
>
>
> _______________________________________________
> 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.
>

Hi Tom,
I agree that better TIC resolution would be a tremendous improvement,
but for a $50 control system in 10 DIP packs this seemed the most cost
effective method. What I am actually doing is scaling the TIC sample
10x to 333ns in a 24-bit result with 33.3ps LSB resolution, accumulating
the scaled 10ns sample counts over the update time while simultaneously
accumulating the 1ns GPS corrections for the same samples in a
separate sawtooth processor and adding the two sets of accumulated
samples at update time. In essence that places the 24-bit LSB weight
at 1ns/30 sec = 33.3ps from the accumulated GPS correction with an
LSB data resolution of 333ps from the accumulated TIC samples. As long
as both accumulated sets are comprised of relatively random variations
the result ends up with fewer spikes and variations than with the
sawtooth correction disabled. I have seen the accumulated GPS counts
exceed +/- 200 counts in 30-seconds during a hanging bridge with a UT+
during initial development so it is definately doing something to
improve the short-term stability of the TIC phase data. Probably with
much less accuracy than using a TIC with better than 1ns sample
resolution as you pointed out but this method is implenented in a single
14-pin PIC for minimal increase in size and cost. The corrected data is
multiplied by 8 and only the top 16 bits are reported giving a
displayed resolution of 1.07ns per count with the full 21-bits of data
in the high bits of a 24-bit value sent to the filter. While you are
correct that the sawtooth variations are indeed probably lost in the
TIC resolution using such a design I did at least try and make sure I
was adding similarly scaled data and it seems to have a significant
effect during a hanging bridge at reducing the error. So can it be
called sawtooth correction or only hanging bridge correction? It still
seems better than no correction at all in this price range.

Thanks,

Richard