[Halld-pid-upgrade] Cluster Counting and DAQ

[Alexander Somov]

Hi,

FDC triggers can be delayed by several  microseconds on TIs
in the FDC crates, for instance (or on the TS ), i.e.,  you
will read out FDC crates with some constant delay.

One can revisit the pile up per channel for the 5-10 usec window
size. I've done some studies long time ago (I think that we should
be able to handle  5*10^7 flux, but it's worth checking).

Cheers,
        Alex









On Sun, 22 Sep 2013, Lubomir Pentchev wrote:

>
> 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
>