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

[Håkan T Johansson]

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
> 
> 
> 
> 
>