> To get around this, you can use the TSC's frequency counter output which > gives 14 or 15 digit measurements. However, you need software to > manually poll for the fcounter data, and you can't get precise tau from > it since the updates don't seem to happen synchronously. I ended up > writing a perl script that grabs and logs the fcounter data every 10 > seconds by default, and that has worked well.
My guess is that their phase-difference output is a filtered version of the full-bandwidth phase data generated for the PN display, as opposed to being generated by running the raw I/Q data through a separate filter path and doing the atan() operations at the final ENBW. These strategies yield similar but not quite identical results. Any frequency calculations based on sending the full-bandwidth phase data through the ENBW filter will be off-kilter. It's true that their frequency counter display seems to be correct in all cases, though -- if I'm right about the problem with the phase/freq difference displays, they must be using a separate, correct filter path to drive the frequency count chart. Since TimeLab's frequency chart relies solely on the phase data stream, it is vulnerable to the same error that you're talking about. I don't attempt to correct the data by reading the frequency counter or anything like that, so yes, that's something to watch out for. It caused me some head-scratching. Fortunately the error doesn't seem to be severe enough to distort the phase-difference trace visibly, or to affect the ADEV and other plots. It's only an issue if you need accurate frequency readings. > John, could you expand on your comment about the ethernet connection? I > have seen random instances where the TSC seems to lose its TCP/IP > settings, but so far it's never happened during a measurement run, so > has been annoying but manageable. When I first wrote the code for Tom's 5120A, I noticed that the TCP connection would sometimes get really sluggish, and occasionally be dropped altogether. Later TSC firmware allowed the data rate to be slowed down to 1, 10, or 100 readings per second instead of 1000, and I imagine that fixes the problem entirely. However, the TimeLab driver is still hardwired to assume the data is coming in at 1000 samples/second. -- john Miles Design LLC _______________________________________________ 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.