[time-nuts] No State Of The Art Counter

[Magnus Danielson]

On 07/01/11 23:45, Tijd Dingen wrote:
>
>
> --- On Thu, 1/6/11, Magnus Danielson<magnus at rubidium.dyndns.org>  wrote:
>
>> From: Magnus Danielson<magnus at rubidium.dyndns.org>
>> Subject: Re: [time-nuts] No State Of The Art Counter
>> To: "Discussion of precise time and frequency measurement"<time-nuts at febo.com>
>> Date: Thursday, January 6, 2011, 10:05 PM
>> On 01/06/2011 08:02 PM, Tijd Dingen
>> wrote:
>>> To whom it may concerns,
>>>
>>> Currently I am building a DIY frequency counter. Since
>> this is my first serious counter project I am trying to keep
>> things simple, hence It Will Not Be State Of The Art. Maybe
>> a not-too-difficult hobby level counter will be of interest
>> to some, so I'd thought I'd post here...
>>>
>>> The architecture in a couple of bulletpoints:
>>> - fpga based as much as possible to keep the parts
>> count down
>>> - coarse counters running at max 200 MHz for now
>>> - interpolation is done using TDC's. The TDC's look
>> suspiciously much like tapped delay lines and are
>> implemented inside the fpga, using mainly the carry chains.
>>> - 10000 continuous time stamps per second
>>> - 500 ps timestamp resolution. And with resolution I
>> mean the smallest resolvable thingy (related to bin size),
>> not precision nor accuracy.
>>
>> 500 ps single-shot resolution is what you probably want to
>> say.
>
>
> Something like that yes. :)
>
>
>> How will the input side work? How will you handle input
>> signals of various kinds? In particular sine of various
>> amplitudes and frequencies. Slew-rate can be a limiting
>> factor as white noise will convert into jitter if hitting a
>> straight comparator. Choice of trigger point can be done to
>> achieve lowest jitter, so just AC-blocking and trigger on
>> the 0V may not be the best solution if shape is not well
>> known. Noise of input stage comes into play.
>
>
> I am glad you asked. :) This is still one big To Be Determined at this point.
>
> As you say, the choice of trigger point has a large impact on jitter. Do you have any suggestions on how to achieve this? Either for the situation where the signal shape is well known or not so well known.
>
> ...

Well, you do have comparators and programmable trigger level. There is 
no magic to that side. But do care about bandwidth. It might be needed 
to actually not use a comparator up-front but rather let there be one or 
two stages of gain, where the first one DC-shifts the signal with the 
trigger level. This way you gain yourself to a higher slew-rate. This is 
really what Collins-style ZCD do. The trick is to balance the gain and 
noise-bandwidths such that you get optimum slew-rate bandwidth for 
lowest added noise.

>>> The timestamps are transmitted over usb to the pc for
>>> number crunching. The idea is to do some curve fitting to
>>> get a frequency estimate, computate Allan Deviation, and do
>>> the obligatory plots. With regard to Allan Deviation, as
>>> long as I make sure the measurements have zero dead time, I
>>> can compute Allan Deviation using the raw time stamps,
>>> right?
>
>
>> Yes. Make sure time-stamps has a format such that software
>> can do time-wrapping extension.
>
> Will do!
>
> regards,
> Fred
>
>
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.