[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
mailing list