[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Flash ADC Timing



Hi Matt,

    I am familiar with those documents and I recall that at the time we 
started developing the fADC (~2 years?), I suggested that someone needed 
to take some real data with Paul's single-channel prototype and try 
doing the prescribed fittings, etc. To the best of my knowledge, no one 
in the collaboration has done that.

    Referring to the document, the algorithm relies on finding the exact 
pulse peak and getting the two preceding samples to determine the 50% 
time, for instance. The exact peak was determined from sampling at 2.5 
GHz (400 ps intervals) and fitting the data with a 9th degree 
polynomial. The data was then "degraded" to provide the equivalent of 8 
or 10-bit, 250 MHz (4 ns intervals) sampling. Note that the exact peak 
is critical for the algorithm to provide the quoted resolution, although 
these details are missing from the document.

    The real fADC, and sampling at 250 MHz, will not provide a sample of 
the true pulse peak. I believe that such "fluctuation" will degrade the 
effective resolution considerably. So, I suggest that this needs to be 
checked with a real fADC, perform the algorithm on real raw fADC data 
(offline) and determined the effective resolution that can be achieved 
by this method. Obtaining 400 ps resolution from 4 ns data points and 
from 10 ns pulse rise times seems difficult to me. We actually may have 
to shape (i.e. slow) the pulse to get more samples on the leading edge 
of the pulse. Once the algorithm is well understood, it will need to be 
implemented in a relatively simple/compact manner to fit within the 
resources of the FPGAs or board memory. Eventually, any data that is 
passed up the chain must be balanced with the backplane bandwidth.

    Let me suggest you set up a test with the real 
PMTs/bases/scintillator/fiber/laser and get data with a real fADC, a TDC 
and CFD. We could lend you one fADC-250 to get the raw data. Let me know 
what you decide and how I can help.

Best regards,
Fernando




Matthew Shepherd wrote:
>
> Hi all,
>
> The study I was referring to has been linked to the FCAL page here:
>
> http://www.jlab.org/Hall-D/software/wiki/index.php/FCAL
>
> This work was done about 3 years ago and claims a resolution of about 
> ~160 ps can be achieved.  This is far better than is actually needed 
> to push down backgrounds.  I think Scott had in mind another 
> application:  using the FCAL to determine the event start time.  The 
> algorithm does a transformation of the leading edge of the pulse to 
> determine the start time and depends on having the two samples before 
> the peak on the leading edge.
>
> I believe Paul had planned to implement this in a simple lookup table 
> which would require about 65K of memory on the chip.  Perhaps that 
> could be optimized even more.  It was never investigated in detail 
> mainly because it seemed like something relatively easy to implement.  
> All of these buffers will need some processing -- the drift chambers 
> will also depend on the timing algorithms that are built into the 
> flash ADCs.
>
> -Matt
>
>
begin:vcard
fn:Fernando J. Barbosa
n:Barbosa;Fernando J.
org:Jefferson Lab
adr:Suite #10, 12B3;;12000 Jefferson Ave.;Newport News;VA;23606;USA
tel;work:757-269-7433
version:2.1
end:vcard