[Halld-pid-upgrade] Cluster Counting and DAQ

[Beni Zihlmann]

Hi All,
I would like to clarify one point. Since I read out the modules on an 
event by event basis for each trigger the cpu(frontend) has to be 
interrupted by the trigger
to read out the ADCs. It will take time for the cpu to react on this 
interrupt. I do not know how much but certainly many micro seconds. That 
is the reason I do
not need to delay the trigger for the ADCs too much. I do not recall how 
much it is I will have to go back and measure it. I will let you know 
then then result.
So by the time the actual readout command is executed by the roc the 
data has safely arrived at the ADCs.

cheers,
Beni


>
> Hi Matt,
>
> That was exactly the question Beni was asking when he started working 
> on the DAQ for the cluster counting. Then he got it working right away 
> without changing the timing of the trigger, as it was for the standard 
> FDC readout. This means we were reading data from the fADCs that 
> arrives up to 20 microseconds after the trigger. Beni can give you 
> details about how and why does it work.
>
> Of course this is a simplified DAQ and there will be other limitations 
> for the full GlueX DAQ. Naively I would think that if the maximal 
> trigger rate  is 20kHz (as I remember this is the official number) the 
> readout rate should be the same, i.e. 50 microseconds per event which 
> is 5 times more than the cluster counting time window. In any case I 
> agree such a readout would be different from the rest of the detectors 
> and we need to talk to the experts.
>
> Lubomir
>
>
>
>
>
> On Sat, 21 Sep 2013, Matthew Shepherd wrote:
>
>>
>> Hi Lubomir,
>>
>>  After thinking about it more, I don't think I phrased my question in 
> the clearest way regarding the DAQ and cluster counting.
>>
>>  You showed that you need to count ionization clusters that arrive over 
> a period of something 10 - 12 microseconds after the primary track.
>>
>>  I think our trigger typically arrives 2-3 microseconds after the event. 
> For  all subsystems this means they must look back into their buffer 
> some fixed  time and readout the event.  (In many subsystems the 
> trigger can't arrive much later or else the data is lost.)
>>
>> For  the cluster counting scheme this means that you need retrieve data 
> from  2-3 microseconds before the trigger and up to 10 microseconds 
> after the  trigger.  I don't understand the intricacies of the 
> electronics or trigger,  but does the fact that you won't have 
> completely recorded an event  until almost 10 microseconds after the 
> trigger is sent to the crates  cause a problem?  (Presumably in that 
> 10 microseconds there is a decent probability that another trigger 
> will arrive as well.)
>>
>> Maybe  there is not a problem, but this seems to be a readout scheme 
> that is somehow fundamentally different from other subsystems.
>>
>> Matt
>>
>> ---------------------------------------------------------------------
>> Matthew Shepherd, Associate Professor
>> Department of Physics, Indiana University, Swain West 265
>> 727 East Third Street, Bloomington, IN 47405
>>
>> Office Phone:  +1 812 856 5808
>>
>>
>> _______________________________________________
>> Halld-pid-upgrade mailing list
>> Halld-pid-upgrade at jlab.org
>> https://mailman.jlab.org/mailman/listinfo/halld-pid-upgrade
>>