[time-nuts] Continuous timestamping reciprocal counter question

Tijd Dingen tijddingen at yahoo.com
Fri May 13 14:56:04 UTC 2011


The counters of the continuous timestamping variety I've read about all mention taking the Nth edge of the input signal. For example:

http://www.spectracomcorp.com/Support/HowCanWeHelpYou/Library/tabid/59/Default.aspx?EntryId=450&Command=Core_Download

In "Picture 5" on page 5 you see a bunch of data points that roughly describe a straight line. Cycle number (of the input signal) on the x-axis, timestamps on the y-axis. Now the question is this:

Will it also work when you get the timestamp of every almost-but-not-quite Nth edge? I'd say yes, but who knows...

To clarify ... when I say "timestamp of edge N", I mean "the time stamp of the positive going edge of the Nth cycle of the input signal". But the former is a bit shorter. ;)

Assume an input signal of 30 MHz. Say you decide to get every 100th edge of this signal, then you would end up with 300k timestamps every second. These timestamps will define a straight line with positive slope. Find the slope, and you have the frequency. And now for the "what if"....

What if the implementation does not always allow for getting the exact Nth edge. What the implementation allows however is to /aim/ for to getting numero 100, 200, 300, 400, and being sure that you are off by a maximum of 1 in either direction. So aim for 100, and you could get 99, 100 or 101. And you can also guarantee that you KNOW about it. So you still know precisely which cycle every time stamp corresponds to.

As far as I can see that places no limit on the accuracy of the calculated frequency, but I could be wrong... Does anyone know of any limitations in this regard?

Taking this one step further ... instead of accidentally being one off every now and then, you could also introduce some randomness on purpose. So you have these 2 different approaches:

Aim for integer multiple:
- try to get edge 0, 100, 200, 300, 400, 500, 600, ...
- actually get edge 0, 100, 200, 299, 399, 500, 601, ...

Aim for some random distibution on purpose:
- try to get edge 0, 103, 181, 287, 381, 497, 614, ...
- actually get edge 0, 104, 181, 287, 382, 497, 613, ...

To calculate the frequency from these time stamps you have to do some slop fitting. If you use a least squares matrix approach for that I could see how the more random distribution could help prevent singularities.

The only reason I can see now to really try harder to always get the exact Nth edge is for numerical solving. As in, should you choose a solver that only operates optimally for equidistant samples.

Any thoughts?

regards,
Fred




More information about the time-nuts mailing list