<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size: 14pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, "EmojiFont", "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;">
<p><br>
</p>
<meta content="text/html; charset=UTF-8">
Dear <span>Hċkan</span>,
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:14pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,"EmojiFont","Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<p><br>
</p>
<p>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.</p>
<p><br>
</p>
<p><br>
</p>
<p>Best greetings</p>
<p>Günter<br>
</p>
<p><br>
</p>
<p><br>
</p>
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> subexp-daq <subexp-daq-bounces@lists.chalmers.se> im Auftrag von Hċkan T Johansson <f96hajo@chalmers.se><br>
<b>Gesendet:</b> Montag, 29. April 2024 10:53:05<br>
<b>An:</b> Discuss use of Nurdlib, TRLO II, drasi and UCESB.<br>
<b>Betreff:</b> Re: [subexp-daq] UCESB - follow-up question on CAEN V767</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt">
<div class="PlainText"><br>
Dear Günter,<br>
<br>
our description of the issue is to the point!<br>
<br>
This is indeed a problem with ucesb and multi-entry data sources.<br>
<br>
Using one long list would indeed solve the initial problem, but then the <br>
functionality to map unpack channels to detector channels no longer work.<br>
<br>
The data structures would need some serious rethinking to solve this <br>
problem in a satisfactory manner. We are actually having quite serious <br>
issues with this also in larger setups, where there are too many of these <br>
crazy-sized arrays...<br>
<br>
Ucesb will at least give an error for events which overflow the number <br>
of entries per channel.<br>
<br>
How many hits would you normally expect in a channel when the experiment <br>
configuration is reasonable?<br>
<br>
Cheers,<br>
Hċkan<br>
<br>
<br>
<br>
On Mon, 29 Apr 2024, Weber, Guenter Dr. wrote:<br>
<br>
> <br>
> Dear friends,<br>
> <br>
> <br>
> one thing I don't understand yet:<br>
> <br>
> <br>
> MEMBER(DATA24 data[VME_CAEN_V767x_NUM_CH] ZERO_SUPPRESS_MULTI(128));<br>
> <br>
> <br>
> This generate a 2D array with 64 x 128 fields, right? I just copied the code from the V1n90 module. But in the<br>
> manual of V767, I did not find a restriction on how many hits for each channel can be stored. The only<br>
> limitation I came accross is right on the first page: the FIFO buffer is 32k words deep. 32.000 hits sounds like<br>
> a crazy amount to me, but ok.<br>
> <br>
> <br>
> Would it be better to put the data into a list of unspecified length, coding the channel number with higher bits<br>
> that are not used by the hit time? Otherwise we have a problem if (in a very hypothetic case) the 129th hit for<br>
> a given channel appears in the data.<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> Best greetings<br>
> <br>
> Günter<br>
> <br>
> <br>
> <br>
> <br>
></div>
</span></font></div>
</body>
</html>