[Vetroc_daq_sbs] VETROC testing status and open questions
Scott Barcus
skbarcus at email.wm.edu
Thu Feb 9 16:34:01 EST 2017
Hi All,
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.
Scott
On Thu, Feb 9, 2017 at 4:26 PM, R. Evan McClellan <randallm at jlab.org> wrote:
>
> Hi all,
>
> 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)
>
> The conclusions are roughly the same:
>
> 1- Somewhere around 100 kHz, we start missing ~50% of the events.
> 2- At ~350 kHz and above, the raw data starts corrupting (missing Event
> Headers and Trigger Time words)
> 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.
>
>
> I would summarize our current status as five questions (two for Bob, two
> for Ben, and one in general):
>
> Bob:
> 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?
> 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?
>
> Ben:
> 1- How are hits showing up in the 'empty' events at the end of the last
> block of a run?
> 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?
>
> General:
> 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...)
>
> Cheers,
> Evan
>
>
>
> R. Evan McClellan, PhD
> Hall A Postdoctoral Fellow
> Jefferson Lab
> _______________________________________________
> Vetroc_daq_sbs mailing list
> Vetroc_daq_sbs at jlab.org
> https://mailman.jlab.org/mailman/listinfo/vetroc_daq_sbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/vetroc_daq_sbs/attachments/20170209/fb856a30/attachment.html>
More information about the Vetroc_daq_sbs
mailing list