<div dir="ltr">Hi All,<div><br></div><div>I can partially answer one of these questions. I have noticed many times that some events from the previous run are read out in the next run so this is not a recent problem. I talked with Bob about this some time ago but we never tracked down the issue. For some reason the buffer sometimes stores some events until the next run and then dumps them, but I don't know why this happens or how to fix it.</div><div><br></div><div>Scott</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 9, 2017 at 4:26 PM, R. Evan McClellan <span dir="ltr"><<a href="mailto:randallm@jlab.org" target="_blank">randallm@jlab.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi all,<br>
<br>
Carlos and I ran another small set of tests. This time, we used an 'always on' LED to generate random hits on all PMTs. (The trigger rate was at ~10kHz for all tests)<br>
<br>
The conclusions are roughly the same:<br>
<br>
1- Somewhere around 100 kHz, we start missing ~50% of the events.<br>
2- At ~350 kHz and above, the raw data starts corrupting (missing Event Headers and Trigger Time words)<br>
3- Even for much lower rate (~10Hz), we noticed that the events at the end of the last block (after the final trigger), which should be empty, often have hits in signal channels.<br>
<br>
<br>
I would summarize our current status as five questions (two for Bob, two for Ben, and one in general):<br>
<br>
Bob:<br>
1- ROC 9 is sometimes very slow (lots of "waiting for ROC9" in CODA). It is usually fixed by rebooting. Is this a common issue? Is there a known fix?<br>
2- Occasionally, the last Block of a run will go missing, and then apparently get read out with the next run. Have you seen this before?<br>
<br>
Ben:<br>
1- How are hits showing up in the 'empty' events at the end of the last block of a run?<br>
2- What causes the Event Header and Trigger Time words to go missing at high rate? Can we alter the firmware to make the readout format immune to high signal rates?<br>
<br>
General:<br>
1- What is our actually rate requirement for the GRINCH DAQ? (I have previously heard 1MHz per channel. It's pretty clear that the VETROC could not handle that...)<br>
<br>
Cheers,<br>
Evan<br>
<br>
<br>
<br>
R. Evan McClellan, PhD<br>
Hall A Postdoctoral Fellow<br>
Jefferson Lab<br>
______________________________<wbr>_________________<br>
Vetroc_daq_sbs mailing list<br>
<a href="mailto:Vetroc_daq_sbs@jlab.org">Vetroc_daq_sbs@jlab.org</a><br>
<a href="https://mailman.jlab.org/mailman/listinfo/vetroc_daq_sbs" rel="noreferrer" target="_blank">https://mailman.jlab.org/<wbr>mailman/listinfo/vetroc_daq_<wbr>sbs</a><br>
</blockquote></div><br></div>