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

Re: A proposal for setting a BCAL threshold




Richard and George,

Thanks for the info.  So 32 MHz was maybe a bit optimistic -- let's  
take then 60 MHz.  At 60 MHz, the probability to have 11 or more dark  
pulses in a 100 ns window is 0.04 (less than 5%).  So I will bump the  
threshold up to 11 photoelectrons or about 2.4 MeV.

I propose a 1 MeV threshold coming out of HDGeant.  Then in the BCAL  
response code in DANA I'll introduce some sampling fluctuations and  
make a second cut at 2.4 MeV.

-Matt


On Jun 8, 2007, at 1:12 PM, George Lolos wrote:

> Hi Richard and Matt:
>
> We had a phone conference yesterday with SensL and they have just  
> tested the wafers for the arrays under Phase 1.
> The 820L pixel type has demonstrated the following performance at  
> room temperature:
>
> Voltage above breakdown                         Pure PDE (no cross  
> talk or after pulsing)                DR/pixel                  DR/ 
> Array
>
>           +  
> 1V                                                                     
>     7%                                                   800  
> Hz                  65 MHz
>           +  
> 2V                                                                     
>   11%                                                 1700  
> Hz                137 MHz
>           +  
> 3V                                                                     
>   13%                                                 3200 Hz
>           +  
> 4V                                                                     
>   17%
> At a temperature of +5 C  the dark rates are cut by a factor of  
> 2.6, so without an elaborate or expensive cooling we can bring this  
> down to around 53 MHz at 11% PDE.   These then will be for Phase  
> 1.  For Phase 2, the new Si process they have just implemented has  
> reduced the DR by a factor of just over 2 and they expect to  
> further improve and come down to that of the original Si treatment  
> that does not give good reproducibility of breakdown voltage.   
> Trenching will also reduce cross talk and keep the DR at the 1 P.E.  
> level.
>
> The bottom line is that Richard is correct that at the present time  
> 32 MHz at PDE values larger than have not been achieved.   Are such  
> rates achievable for production?  I believe they are but aiming at  
> a more realistic 50-60 MHz at PDE ~ 10-15% is the wiser route to go.
>
> I hope this helps,
>
> George
>
>
> Richard Jones wrote:
>
>> Matt,
>>
>> The design goal of 32MHz may eventually be achieved, but this is  
>> not demonstrated.  At the last meeting George agreed that 100MHz  
>> is achievable with what he has seen.  I would believe something  
>> more like 150MHz @ 22C from what I have actually seen, but I am  
>> not working with Sensl modules.  This depends a lot on  
>> temperature, but we agreed that we do not want to have to  
>> refrigerate the BCal readout very much.
>>
>> Richard J.
>>
>> Matthew Shepherd wrote:
>>
>>>
>>> Hi All,
>>>
>>> Here's a proposal for setting a BCAL threshold so we can start to  
>>> refine the reconstruction a little bit.
>>>
>>> - take dark rate at 32 MHz (design goal from GlueX-doc-795) and  
>>> assume this is only single PE rate
>>> - for a 100 ns window this means an average of 3.2 pulses per window
>>> - assume the fADC processing just generates a pedestal subtracted  
>>> mean and that dark rate (not electronics noise) dominates the  
>>> pedestal
>>> - let's assume the DAQ can handle 5% occupancy in the BCAL
>>> - if average is 3.2 dark pulses, the probability of having 7 or  
>>> more pulses in a window is 0.04
>>>
>>> --->> set threshold at 7 photoelectrons
>>>
>>> 7 photoelectrons * ( 26 keV_fiber / pe ) / 12% = 1.5 MeV energy  
>>> deposited in cell
>>>
>>> I propose we adjust the threshold to 1.5 MeV (down from 10 MeV)  
>>> and work from there.  Of course this needs further study, and  
>>> validation through whatever bench studies, beam test, etc. etc..   
>>> My main goal is to get around the right order of magnitude so we  
>>> can make another pass at the reconstruction algorithm which will  
>>> behave very differently with this much lower threshold.  Does  
>>> anyone see a serious flaw with this?
>>>
>>> -Matt
>>>
>>
>
>