<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Sorry that I missed the discussion on Friday, it sounds like it was interesting. One<div>note on the 20KHz number that Lubomir mentioned. That is the expected rate off</div><div>level-1 at 10**7 photons per second. If we get to 10**8, then it will be at least 10</div><div>times this (hence the need for level 3 triggering). This may impact your ability to </div><div>wait for things - Curtis<br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div><div>---------</div><div>Curtis A. Meyer<span class="Apple-tab-span" style="white-space: pre; "> </span>MCS Associate Dean for Faculty and Graduate Affairs</div><div>Wean: (412) 268-2745<span class="Apple-tab-span" style="white-space: pre; "> </span>Professor of Physics</div><div>Doherty: (412) 268-3090<span class="Apple-tab-span" style="white-space: pre; "> </span>Carnegie Mellon University</div><div>Fax: (412) 681-0648<span class="Apple-tab-span" style="white-space: pre; "> </span>Pittsburgh, PA 15213</div><div><a href="mailto:curtis.meyer@cmu.edu">curtis.meyer@cmu.edu</a><span class="Apple-tab-span" style="white-space: pre; "> </span>http://www.curtismeyer.com/</div></div><div><br></div></span><br class="Apple-interchange-newline">
</div>
<br><div><div>On Sep 23, 2013, at 9:58 AM, Beni Zihlmann <<a href="mailto:zihlmann@jlab.org">zihlmann@jlab.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi All,<br>I would like to clarify one point. Since I read out the modules on an <br>event by event basis for each trigger the cpu(frontend) has to be <br>interrupted by the trigger<br>to read out the ADCs. It will take time for the cpu to react on this <br>interrupt. I do not know how much but certainly many micro seconds. That <br>is the reason I do<br>not need to delay the trigger for the ADCs too much. I do not recall how <br>much it is I will have to go back and measure it. I will let you know <br>then then result.<br>So by the time the actual readout command is executed by the roc the <br>data has safely arrived at the ADCs.<br><br>cheers,<br>Beni<br><br><br><blockquote type="cite"><br>Hi Matt,<br><br>That was exactly the question Beni was asking when he started working <br>on the DAQ for the cluster counting. Then he got it working right away <br>without changing the timing of the trigger, as it was for the standard <br>FDC readout. This means we were reading data from the fADCs that <br>arrives up to 20 microseconds after the trigger. Beni can give you <br>details about how and why does it work.<br><br>Of course this is a simplified DAQ and there will be other limitations <br>for the full GlueX DAQ. Naively I would think that if the maximal <br>trigger rate is 20kHz (as I remember this is the official number) the <br>readout rate should be the same, i.e. 50 microseconds per event which <br>is 5 times more than the cluster counting time window. In any case I <br>agree such a readout would be different from the rest of the detectors <br>and we need to talk to the experts.<br><br>Lubomir<br><br><br><br><br><br>On Sat, 21 Sep 2013, Matthew Shepherd wrote:<br><br><blockquote type="cite"><br>Hi Lubomir,<br><br> After thinking about it more, I don't think I phrased my question in <br></blockquote>the clearest way regarding the DAQ and cluster counting.<br><blockquote type="cite"><br> You showed that you need to count ionization clusters that arrive over <br></blockquote>a period of something 10 - 12 microseconds after the primary track.<br><blockquote type="cite"><br> I think our trigger typically arrives 2-3 microseconds after the event. <br></blockquote>For all subsystems this means they must look back into their buffer <br>some fixed time and readout the event. (In many subsystems the <br>trigger can't arrive much later or else the data is lost.)<br><blockquote type="cite"><br>For the cluster counting scheme this means that you need retrieve data <br></blockquote>from 2-3 microseconds before the trigger and up to 10 microseconds <br>after the trigger. I don't understand the intricacies of the <br>electronics or trigger, but does the fact that you won't have <br>completely recorded an event until almost 10 microseconds after the <br>trigger is sent to the crates cause a problem? (Presumably in that <br>10 microseconds there is a decent probability that another trigger <br>will arrive as well.)<br><blockquote type="cite"><br>Maybe there is not a problem, but this seems to be a readout scheme <br></blockquote>that is somehow fundamentally different from other subsystems.<br><blockquote type="cite"><br>Matt<br><br>---------------------------------------------------------------------<br>Matthew Shepherd, Associate Professor<br>Department of Physics, Indiana University, Swain West 265<br>727 East Third Street, Bloomington, IN 47405<br><br>Office Phone: +1 812 856 5808<br><br><br>_______________________________________________<br>Halld-pid-upgrade mailing list<br><a href="mailto:Halld-pid-upgrade@jlab.org">Halld-pid-upgrade@jlab.org</a><br>https://mailman.jlab.org/mailman/listinfo/halld-pid-upgrade<br><br></blockquote></blockquote><br>_______________________________________________<br>Halld-pid-upgrade mailing list<br><a href="mailto:Halld-pid-upgrade@jlab.org">Halld-pid-upgrade@jlab.org</a><br>https://mailman.jlab.org/mailman/listinfo/halld-pid-upgrade<br></blockquote></div><br></div></body></html>