[time-nuts] Limitations of Allan Variance applied to frequency divided signal?

Magnus Danielson magnus at rubidium.dyndns.org
Sun May 15 21:31:18 UTC 2011


Hi Fred,

On 05/15/2011 10:01 PM, Tijd Dingen wrote:
> Check. That is what I understood the "Overlapped variable tau estimators"
> bit on wikipedia to be about. Same raw data, smarter processing.

Indeed.

>>  Notice that you need to adjust your data for cycle-slips. If you don't
>>  do that you will get a significant performance hit with typical several
>>  decades higher ADEV curve than expected.
>
> "Adjust for cycle-slips"... You mean the following ... ?
>
> Your processing back-end receives a series of timestamps from the
> timestamper.
> The timestamper claims "this is the timestamp for cycle number XYZ. No,
> really!".
> However you notice that given the distribution of all the other
> (cycle_no, time)
> pairs this would be hard to believe. If however you would assume add +1
> to that
> "claimed" cycle number, then it would perfectly. So you adjust the cycle
> number
> by one, under the assumption that /somewhere/ 1 cycle got lost.
> Somewhere being
> a PLL cycle slip, an fpga counter missing a count, etc...
>
> That sort of adjustment I take it? If yes, then understood. If not, I'm
> afraid
> I don't follow. :)

Consider that your time-base and your measurement signal is 1E-10 away 
from each other in the case I gave, let's assume 10 MHz clocks. This 
means that their phases will shift 1E-10*1E7 = 1E-3 degrees of a cycle 
every second, so after 1000 seconds it will have shifted a full cycle, 
somewhere in that data there will be a 99.9 ns to 0.0 ns (or vice-versa) 
transition. This is not since the counter missed a cycle, but since the 
signals actually beats against each other. Now, if you would take that 
time-series and do an ADEV on it you will get a surprise. If you correct 
it such that you extend the curve with +100 ns or -100 ns (i.e. add or 
subtract a cycle, but expressed as a time shift) you will get a more 
correct TI curve which you will get your expected results from.

>>  Do you mean to say that your low resolution time-stamping rate is 400
>>  MS/s and high resolution time-stamping rate is 20 MS/s?
>
> That is what I mean to say. There are still design issues with both modes,
> so could become better, could become worse. Knowing how reality works,
> probably worse. ;-> But those numbers are roughly it yes.

Great, now we speak the same language on that aspect.

> At the current stage: 200 MS/s at the lower resolution is easy. 400 MS/s
> is trickier.
>
> The reason: 400 MHz is the full tap sampling speed, and I can barely keep
> up with the data. The data is from a 192 tap delay line incidentally.
> Active length is typically about 130 taps, but I have to design worst case.
> Or rather best case, because needing all those taps to fit a 2.5 ns cycle
> would be really good news. ;) But hey, we can always hope for fast silicon
> right?

See what a little fiddling with temperature and core voltage can do for 
you :)

> Anyways, the first 5 pipeline stages right after the taps work at 400 MHz.
> The second part (as it happens also 5 stages) works at 200 MHz. If only
> for the simple reason that the block ram in a spartan-6 has a max frequency
> of about 280 MHz. So the 200 MHz pipeline processes 2 timestamps in
> parallel.
>
> For this part of the processing I have spent more design effort on the
> modules
> that are responsible for the high resolution timestamps. So low resolution,
> 200 MS/s == done. 400 Ms/s == working on it. :P

I guess you learn by doing, right? :)

>>  It is perfectly respectable to skip a number of cycles, but the number
>>  of cycles must be known. One way is to have an event-counter which is
>>  sampled, or you always provide samples at a fixed distance
>>  event-counter-wise such that the event-counter can be rebuilt
>>  afterwards. The later method save data, but have the draw-back that your
>>  observation period becomes dependent on the frequency of the signal
>>  which may or may not be what you want, depending on your application.
>
> What I have now is an event counter which is sampled.

Great.

>>  Recall, you will have to store and process this flood of data. For
>>  higher tau plots you will wade in sufficiently high amounts of data
>>  anyway, so dropping high frequency data to achieve a more manageable
>>  data rate in order to be able to store and process the longer tau data
>>  is needed.
>
> Heh, "store and process this flood of data" is the reason why I'm at
> revision numero 3 for the frigging taps processor. :P But oh well,
> good for my pipeline design skills.

Definitively. It's a learning process to unroll things which one 
understands well in sequential processing but all of a sudden needs to 
do in parallel.

>>  For most of the ADEV plots on stability, starting at 100 ms or 1 s is
>>  perfectly useful, so a measurement rate of 10 S/s is acceptable.
>
> Well, that would be too easy. Where's the fun in that?

True, where's the fun in that :)

>>  For high speed things like startup burps etc. you have a different
>>  requirement race. A counter capable of doing both will be great, but
>>  they usually don't do it.
>
> Check. For me the main purpose of this thing is:
> 1 - learn new things
> 2 - be able to measure frequency with accuracy comparable to current
> commercial counters
> 3 - monitor frequency stability

All good goals. Don't let me get in the way of them... :)

> Anyways, for now the mandate is to be able to spit out as many
> timestamps as I can get away
> with, and then figure out fun ways to process them. ;)

Also interesting. I'm considering similar projects. Don't have a 
spartan-6 lying around on a board so I will have to do with less. Got 
some spartan-3E boards which should suffice for some initial experience.

Cheers,
Magnus




More information about the Time-nuts_lists.febo.com mailing list