[Halld-pid-upgrade] Cluster Counting and DAQ

[Lubomir Pentchev]

Hi Curtis,

Yes, I agree, all these are valid questions about the DAQ and trigger rate 
and they need to be discussed with the experts. However, on the detector 
side we also can do something depending on what is the limitation coming 
from the DAQ. We have tried so far two gas mixtures Ar/CO2 40/60 and 60/40 
corresponding to ~20 and ~10 microseconds maximum drift time and of course 
we have used the fADC125 for the readout. If we have to, we can go down to 
say 5 microseconds and use fADC250, which was assumed in the original 
proposal at the GlueX Upgrade Meeting last year. Actually f250 is more 
than a factor of two better in resolving the clusters because f125 does 
additional integration of the input pulse to ~40ns rise time. This means 
we can go even below 5 microseconds if we have to.

On another note, in the present schedule of the Collaboration Meeting 
there's no time slot for the cluster counting. We asked for 20 min, but I 
can see that the schedule is very tight. If this is the case, I can just 
put a few  slides at the end of my FDC talk about the test with the 
modified cells.

Lubomir



On Mon, 23 Sep 2013, Curtis A. Meyer wrote:

> Sorry that I missed the discussion on Friday,  it sounds like it was 
interesting. One
> note on the  20KHz number that Lubomir mentioned. That is the expected 
rate off
> level-1 at  10**7 photons per second. If we get to 10**8, then it will 
be at least 10
> times this  (hence the need for level 3 triggering). This may impact 
your ability to
> wait for things - Curtis
> ---------
> Curtis A. Meyer			MCS Associate Dean for Faculty and Graduate Affairs
> Wean:    (412) 268-2745	Professor of Physics
> Doherty: (412) 268-3090	Carnegie Mellon University
> Fax:         (412) 681-0648	Pittsburgh, PA 15213
> curtis.meyer at cmu.edu	http://www.curtismeyer.com/
>
>
>
> On Sep 23, 2013, at 9:58 AM, Beni Zihlmann <zihlmann at jlab.org> wrote:
>
>> 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
>>>>
>>
>> _______________________________________________
>> Halld-pid-upgrade mailing list
>> Halld-pid-upgrade at jlab.org
>> https://mailman.jlab.org/mailman/listinfo/halld-pid-upgrade
>
>