[Halld-pid-upgrade] Cluster Counting and DAQ

Michael Williams mwill at mit.edu
Mon Sep 23 19:10:42 EDT 2013 

Ok, great.  I didn't think it'd be an issue but given the long readout time it should be said explicitly.

We did the em study a while back for the gas veto which of course applies for the dirc too.  Something like 2 degree hole works.  The em shouldn't cause the dirc any real problems.  

Sent from my iPhone

On Sep 23, 2013, at 6:03 PM, "Lubomir Pentchev" <pentchev at jlab.org> wrote:

> 
> Hi Mike,
> 
> Actually it is the e.m. background dominating in the region close to the beam and that has been studied by Alex:
> 
> http://argus.phys.uregina.ca/cgi-bin/private/DocDB/ShowDocument?docid=1471
> 
> You can see the rates on the strips (wires have much lower rates) at Figs.13 and 14 as a function of the distance to the beam. For the FDC we have deadened the wires in an area of 3.9cm radius and you can see that the rate on the inner most strip is ~80kHz in case of 10^8 photons/sec. There's a very high probability for another particle to give a signal on the same strip: 55% for 10 microseconds max drift time, and 33% for 5 microseconds. This simply means we have to increase the radius of the FDC "hole": as you can see from Fig.14 the background goes down exponentially so you don't need a lot. There's another tool you can use to reduce the randoms. Each track gives you an unique pattern of ~50 peaks in time BOTH on the strips and wires. Even if you have two track patterns on one strip, you will be able to disentangle them since they will produce different peaks on the different wires.
> 
> Similar random rate estimates have to be done for the other proposed PID detectors, since for example for DIRC they will define the closest position of the inner bar to the beam which in turn defines the DIRC acceptance.
> 
> Lubomir
> 
> 
> On Mon, 23 Sep 2013, Michael Williams wrote:
> 
>> 
>> 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
>> 
>>

More information about the Halld-pid-upgrade mailing list