[time-nuts] No State Of The Art Counter

[Tijd Dingen]

--- 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.

...

> > 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