Re: Flash ADC Timing

["Fernando J. Barbosa" <barbosa@jlab.org>]

Hi Matt,

    I was concerned because the detector summary table specifies a 
timing resolution of 400 ps for the FCAL. So, I need to update it to 4 
ns. This sort of resolution should be easy to implement.

    I will let you know when I can send you a fADC. You will need to 
have a VME64x crate, though. If you don't have one already, there is 
usually a lead time of a few weeks for delivery at a cost of about $8k - 
$10k.

Best regards,
Fernando



Matthew Shepherd wrote:
>
> Hi Fernando,
>
> I understand the claims in the document are rather optimistic; 
> however, the fact of the matter is that we probably just need timing 
> resolution roughly on the scale of sampling rate to suppress 
> beam-related out of time noise.
>
> If you have a real fADC that is ready for use we're happy to take it 
> and get it setup and running here.  This would serve many purposes -- 
> probably most important at this point is that we could use the real 
> PMT, light guide, base, and fADC that we plan for the actual 
> experiment to readout just one bar and probe the low energy threshold 
> of the calorimeter using cosmic rays (and guidance from simulation).
>
> -Matt
>
>
> On Nov 16, 2007, at 3:01 PM, Fernando J. Barbosa wrote:
>
>> 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
>>>
>>>
>>> <barbosa.vcf>
>
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