> 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 -- [email protected] > 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 _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
