[Halld-pid-upgrade] Cluster Counting and DAQ

Mon Sep 23 11:13:46 EDT 2013

The other issue that should be addressed is how pile up affects your ability to do PID.   If you need to record a 10 mu s window and the hadronic rate is hundreds of kHz or even pushing 1 MHz (if I remember the numbers correctly 10^8 would something like 500 kHz but these predictions have large uncertainties) then you'll have multiple hadronic events in your recorded time window.

Now, maybe this doesn't affect you due to occupancy still being low, etc, but I think it's worthy of at least addressing it.

Mike

On Sep 23, 2013, at 11:03 AM, "Curtis A. Meyer" <cmeyer at cmu.edu<mailto:cmeyer at cmu.edu>>
 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<mailto:curtis.meyer at cmu.edu> http://www.curtismeyer.com/

On Sep 23, 2013, at 9:58 AM, Beni Zihlmann <zihlmann at jlab.org<mailto: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<mailto: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<mailto: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<mailto:Halld-pid-upgrade at jlab.org>
https://mailman.jlab.org/mailman/listinfo/halld-pid-upgrade

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.jlab.org/pipermail/halld-pid-upgrade/attachments/20130923/1d76937c/attachment-0001.html 