[subexp-daq] UCESB - follow-up question on CAEN V767

[Weber, Guenter Dr.]

Dear Håkan,


for our purposes, more than a handful of hits is unlikely (this could only be caused by triggering in the noise, which is fine to cause trouble). I just wanted to be sure, that my understanding is correct.



Best greetings

Günter



________________________________
Von: subexp-daq <subexp-daq-bounces at lists.chalmers.se> im Auftrag von Håkan T Johansson <f96hajo at chalmers.se>
Gesendet: Montag, 29. April 2024 10:53:05
An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.
Betreff: Re: [subexp-daq] UCESB - follow-up question on CAEN V767


Dear Günter,

our description of the issue is to the point!

This is indeed a problem with ucesb and multi-entry data sources.

Using one long list would indeed solve the initial problem, but then the
functionality to map unpack channels to detector channels no longer work.

The data structures would need some serious rethinking to solve this
problem in a satisfactory manner.  We are actually having quite serious
issues with this also in larger setups, where there are too many of these
crazy-sized arrays...

Ucesb will at least give an error for events which overflow the number
of entries per channel.

How many hits would you normally expect in a channel when the experiment
configuration is reasonable?

Cheers,
Håkan



On Mon, 29 Apr 2024, Weber, Guenter Dr. wrote:

>
> Dear friends,
>
>
> one thing I don't understand yet:
>
>
>   MEMBER(DATA24 data[VME_CAEN_V767x_NUM_CH] ZERO_SUPPRESS_MULTI(128));
>
>
> This generate a 2D array with 64 x 128 fields, right? I just copied the code from the V1n90 module. But in the
> manual of V767, I did not find a restriction on how many hits for each channel can be stored. The only
> limitation I came accross is right on the first page: the FIFO buffer is 32k words deep. 32.000 hits sounds like
> a crazy amount to me, but ok.
>
>
> Would it be better to put the data into a list of unspecified length, coding the channel number with higher bits
> that are not used by the hit time? Otherwise we have a problem if (in a very hypothetic case) the 129th hit for
> a given channel appears in the data.
>
>
>
>
>
> Best greetings
>
> Günter
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chalmers.se/pipermail/subexp-daq/attachments/20240429/aeb223ee/attachment.html>