Re: Timing Info

[Matthew Shepherd <mashephe@indiana.edu>]

Hi Fernando,

On Jan 28, 2008, at 9:28 AM, Fernando J. Barbosa wrote:

> My understanding from reading the note is that the peak sample,  
> which is critical to do the fitting of the leading edge of a pulse,  
> is obtained prior to "degrading" the data for 8 or 10-bit and 250  
> MSPS - a priori knowledge of the peak is required. The remainder of  
> the technique is very nice, though.

The peak time is obtained prior to degrading the data (in addition to  
the 50% time).  This is only done so that one can compare the  
extracted peak time and 50% time to the "true" values to obtain  
resolutions on each (presented in Table 1).  These true values are not  
used in the algorithm; however, the peak (degraded) sample is.

Richard raised another interesting question related to the fADC  
operation.  At what level is high-frequency noise integrated out in  
the samples?  When the fADC measure the voltage at a particular time  
is it integrating charge over some small time window (less than the  
sampling period) that depends on some input capacitance?  What is this  
characteristic time scale?  If it is very short, then one criticism of  
this note is that it averages over the entire sampling interval, which  
will wash out high frequency noise, before down-sampling the pulse.

> For random pulses, we agree that the sampling of the actual peak may  
> be off by as much as 4 ns. I contend that it will be hard to get the  
> timing resolution you need. There is also the question of how to  
> implement any algorithm on-board. LUTs are compact (=fast). One of  
> the fADC250's on-board FPGAs includes a Power PC core which we don't  
> use but it may be slow for any kind of computationally intensive  
> algorithm.

I agree that this implementation issue is an important one that needs  
to be addressed and we will develop a test setup to examine this.  At  
the same time we will naturally have to investigate the issue of  
resolution again.  I should point out though that tests of the  
resolution like this using actual hardware are also susceptible to  
their own systematic errors, most notably a good understanding of the  
resolution of the reference time.

We likely won't get to this until later this spring, but will  
certainly keep in touch as work progresses.

-Matt