[Halld-pid-upgrade] Cluster Counting and DAQ

[Curtis A. Meyer]

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

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