[time-nuts] an interesting problem

jimlux jimlux at earthlink.net
Sat Feb 5 16:30:44 UTC 2011


On 2/5/11 8:11 AM, Magnus Danielson wrote:
> On 05/02/11 16:25, jimlux wrote:
>> Here's an interesting problem..
>>
>> I've got a system at work with an internal clock oscillator that I want
>> to get some statistics on, but there's no direct visibility for the
>> oscillator, nor do I have a convenient test point that I can probe.
>>
>> I can divide it down by an arbitrary number to generate pulses which I
>> then send out via SpaceWire timecodes. SpaceWire is a fast point to
>> point digital data link and it has a special capability that essentially
>> has a "tick in" signal at one end and a "tick out" signal at the other
>> end. The latency between tick in and tick out is random, but bounded and
>> discrete. the link runs at a clock rate derived from the same
>> oscillator, and you have to wait until the current character being sent
>> has been clocked out before you can send the special "timecode" token.
>>
>> THat is, I can detect the "tick out" pulse and it has a random N*[0-14]
>> clock delay (distributed more towards 0 than 14) from when the "tick in"
>> (which is synchronous with the clock I want to measure). N is the ratio
>> between my clock and the data rate on the wire ( 7, in this case, so the
>> time step is about 100ns)
>>
>> So, by making measurements of the time when the "tick out" appears (or
>> time between tick_out pulses) can I somehow "take out" the random
>> variability of the link.
>>
>> It seems, since the clock isn't *terrible* that I could, for instance,
>> accumulate statistics, and throw out the ones that have more than 0
>> clock latency (which is probably a few 10s of percent of the ticks.. I
>> haven't looked yet). Or, given that the interval between ticks is one of
>> 28 or 29 discrete values (plus the underlying clock variance), if the
>> clock variance on a given pulse is <<clock rate, the
>> histogram/probability distribution of times would look like a bunch of
>> little humps, each with variance =clock variance.
>
> What you can do is you generate your tick clock at any division greater
> than 7*14 (if I understood the timing correctly). Say you divide your
> clock with 200 (about 3 us period if I got it right). Then you would get
> about half the period between your ticks would have random delay and the
> rest is silent.

yes, I'll probably use a divisor of 66 million to get 1pps ticks.

>
> You then make TI measurements against some suitable clock. From that you
> should then be able to rebuild your baseline time difference, detect the
> random delay of 7x[0-14] and once you done that re-stamp those with the
> suitable time and you now have a new time-series which all seems to be
> experiencing the random delay of 0. From then on just do the ADEV or
> whatever you want to do according to standard processing.


That's sort of what I was thinking.. all dependent on whether the 
variance is small enough to determine the N

>
>> or, is a real oscillator going to have an instantaneous variance that is
>> comparable to or greater than 1 clock pulse?
>
> No, probably not unless you got a seriously bad design, which you would
> probably know by now anyway. For short time-spans, deterministic noise
> (such as your random buffer delay) and white noise will dominate.

To the lab.. (well, on Monday..)



More information about the time-nuts mailing list