> 1. Can someone tell me the meaning and significance of the "Timing > Outputs" numbers in the lower left corner of the TBolt monitor > window? (Mine right now is showing plus 3.75 ns and plus 0.01 ppb). > The TBolt manual does not describe these, although on one page it > lists them as "estimates of UTC/GPS offsets." Do these numbers show > the difference between my receiver outputs and the time being kept by > my present satellites? Or is it the difference between my receiver > outputs and master gps time (somewhere)? Neither of these?
They're basically what the manual says -- estimates of the current oscillator performance versus what the Thunderbolt thinks the satellites are telling it. > The use > of two decimal places on nanoseconds implies great accuracy. Is this > obtained in practice? My ppb on 10 MHz usually lies between plus 0.1 > and minus 0.1, often hanging around 0.01 or 0.02. I have not so far > put in any compensation for cable delay. To be meaningful, the reported data should ideally be filtered with a time constant close to the VCO disciplining time constant, which you can do in Lady Heather but not TBoltMon. If not, it will seem artificially noisy. Without filtering I don't think I'd pay much attention to the LSD (1E-11) and possibly the next one (1E-10). > If the TBolt "knows" what these differences are, why doesn't it just > factor them into its outputs? Or does it? This is basically what happens, but it has to be done through the VCO control loop's filter, which is a lowpass function (integrator) whose time constant is typically 100 to 1000 seconds. You can't get good clean timing data from GPS satellites at timescales much shorter than that; the performance of your local OCXO will always be better. You can set your disciplining time constant to 1 second and let the Thunderbolt try to jerk the OCXO around as needed to zero out the reported PPS and/or frequency error... but the actual result, if measured independently at the Thunderbolt's 1-pps and 10 MHz outputs, will be fairly noisy. The situation is basically that of a PLL with a very good VCO (your OCXO) and a noisy reference (the GPS signal). Such cases call for long loop time constants. > 2. What is a reasonable expectation of TBolt accuracy (at any given > time that I use it for measurement) for the 10 MHz relative to NIS? > How accurate would it be, say, 90 percent of the time? (Looking for > just an experienced guesstimate here). This sort of question can't be answered without specifying the timescale, which is why you commonly see people discussing Allan deviation and other graph-friendly representations. If you gather statistics once a day, the answer is "very accurate indeed," down in the parts per 1E14, thanks to GPS. At shorter timescales the accuracy will be worse, again because of the compromise between GPS S/N ratio and your local OCXO's stability. Tom's pages at http://www.leapsecond.com/pages/gpsdo/ and http://www.leapsecond.com/pages/tbolt-8d/ are _extremely_ informative in this regard. > 3. What format do I use to put in pps nanoseconds compensation for > cable delay (I use about 19 feet of RG-58U). I understand this > should be a negative number. Not sure, never used this feature. If you aren't trying to synchronize your 1-PPS output with other stations, there's not much point. > 4. Does anyone know a way to force the 5335A counter to display > another decimal place in frequency measurements? I am getting to > 0.001 Hz by using the "mean of 100 counts" function on the counter, > but I think the counter has at least one more digit available which I > would like to use when accuracy justifies it (e.g. when using the > TBolt as an external time source). Unfortunately you can't even do that. :( The counter's jitter and resolution limits will dominate the performance of a GPSDO at timescales < 100 seconds or so. Averaging isn't as informative as you might think, because you don't know if the noise being averaged out is drift from the DUT, phase noise from the DUT, quantization artifacts from the counter, jitter from the counter, or all of the above. (Hint: it's pretty much all from the counter in this case.) The best conventional time-interval counters have resolution+jitter floors in the 20-50 ps neighborhood. So stability measurements at 1-second intervals can't be made below 20-50 parts per trillion with these counters.... and traditional "frequency counters" are much worse. Meanwhile, a Thunderbolt-class GPSDO will normally be accurate to better than 10 parts per trillion at 1-second timescales (again, see Tom's pages). Characterizing the stability of these sources requires specialized hardware (which can be primarily digital or analog-based.) Even with a better timing analyzer, you'll eventually find that your LPRO is noisier than the Thunderbolt at shorter timescales as well. Use of a microwave synthesizer and counter, as in the document TomD mentioned, isn't likely to be beneficial, because what's the first thing the microwave counter is going to do with a 40 GHz signal? Divide it by 4000 or so, undoing the multiplicative effect of the synthesizer. One figure of merit for frequency counters is "digits per second," which is a way of stating its usable resolution in a way that's independent of the displayed frequency. Given the same 1-second gate time, a hypothetical microwave frequency counter that displays 11 digits per second can resolve 100 Hz at 10 GHz or 0.0001 Hz at 10 MHz. You're getting the same amount of information from the counter either way, at the same rate. > Any comments and suggestions appreciated Run away while you still can? :-P -- john, KE5FX _______________________________________________ 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.
