<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:14pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Dear <span>Håkan,</span></p>
<p><span><br>
</span></p>
<p><span>thank you for the quick reply.</span></p>
<p><span><br>
</span></p>
<p><span>The SIS3316 modules are digitizers which we not only want to use for recording pulses from the detector (trigger type 1), but also for monitoring the baseline behaviour of the signal (trigger type 2). For type 1 we look into the metadata of each SIS3316 channel
and only read out the 2^14 samples of the detector signal trace if there is a pulse (indicated by the flag in the metadata). For type 2 we would like to avoid this selection and readout all the traces.</span></p>
<p><span><br>
</span></p>
<p><span><br>
</span></p>
<p><span>Best greetings</span></p>
<p><span>Günter</span></p>
<p><span><br>
</span></p>
<p><span><br>
</span></p>
<p><br>
</p>
<div id="x_Signature">
<div style="font-family:Tahoma; font-size:13px">
<div style="font-family:Tahoma; font-size:13px"><font size="2" style="font-family:Tahoma"><span style="font-size:10pt">----------------<br>
<br>
Günter Weber<br>
<br>
Helmholtz-Institut Jena<br>
Fröbelstieg 3<br>
07743 Jena<br>
Germany<br>
Phone: +49-3641-947605<br>
<a href="http://www.hi-jena.de" id="LPNoLP"><font size="2">www.hi-jena.de</font></a><br>
<br>
GSI Helmholtzzentrum für Schwerionenforschung<br>
Planckstrasse 1<br>
64291 Darmstadt<br>
Germany<br>
</span></font><a href="http://www.gsi.de" id="LPNoLP"><font size="2" style="font-family:Tahoma"><span style="font-size:10pt"><font size="2">www.gsi.de</font></span></font></a></div>
</div>
</div>
</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> Dienstag, 8. April 2025 11:23:07<br>
<b>An:</b> Discuss use of Nurdlib, TRLO II, drasi and UCESB.<br>
<b>Betreff:</b> Re: [subexp-daq] dropping of data to analysis that cannot keep up</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText"><br>
Dear Günter,<br>
<br>
nice to hear from you!<br>
<br>
The f_user function would get the trigger, so you should see it at least <br>
there.<br>
<br>
How to get that into nurdlib I think is a question for Hans...<br>
<br>
Curiosity: in what way do you want to do a different readout depending on <br>
the trigger that happened?<br>
<br>
<br>
I also think the SIS3316 code modifications you had have been merged.<br>
<br>
Could you please try the current version and see if that works?<br>
<br>
Best regards,<br>
Håkan<br>
<br>
<br>
<br>
<br>
<br>
On Tue, 8 Apr 2025, Weber, Guenter Dr. wrote:<br>
<br>
> <br>
> Dear friends,<br>
> <br>
> <br>
> sorry for coming up with a very basic question: How can I define different<br>
> trigger types and make the readout procedure of a specific module dependent<br>
> on the type of trigger?<br>
> <br>
> <br>
> Example:<br>
> <br>
> I have two different trigger types, 1 and 2. To let the DAQ know, which type<br>
> of trigger I have, they are plugged to the input channels 1 and 2 of our<br>
> VOLUM4B. Now I would like to know in the readout of the SIS3316 module,<br>
> which type triggered the current event. How do I do this?<br>
> <br>
> <br>
> <br>
> Thank you very much!<br>
> <br>
> <br>
> <br>
> <br>
> Best greetings from Jena<br>
> <br>
> Günter<br>
> <br>
> <br>
> <br>
> P.S. As I got distracted by some hardware issues in the lab, we did not have<br>
> a proper hand-over of our modifications of the SIS3316 code in Nurdlib. Did<br>
> you in the meantime took over these modifications into the main branch or<br>
> how is the situation?<br>
> <br>
> <br>
> <br>
> ____________________________________________________________________________<br>
> Von: subexp-daq <subexp-daq-bounces@lists.chalmers.se> im Auftrag von Håkan<br>
> T Johansson <f96hajo@chalmers.se><br>
> Gesendet: Sonntag, 16. Februar 2025 11:33:35<br>
> An: Bajzek, Martin<br>
> Cc: Hubbard, Nicolas James Dr.; subexp-daq@lists.chalmers.se<br>
> Betreff: [subexp-daq] dropping of data to analysis that cannot keep up <br>
> <br>
> Hi,<br>
> <br>
> when the point of DAQ being faster than online is reached, we face the<br>
> issue of somehow dropping old data.<br>
> <br>
> Left with default settings, ucesb is not really helpful. Old data will<br>
> pile up in the '--server' until that is full, and only then dropped. If<br>
> the server is configured with a large amount of memory for buffers<br>
> ('--server' option 'size='), this can be significant. This leads to<br>
> online analysis lagging reality, loosing the 'online' feeling and useful<br>
> rapid feedback of changing conditions...<br>
> <br>
> There is a 'dropold=N' (seconds) option which will not serve buffers to<br>
> the client older than the specified time. It may be reasonable to set<br>
> this to at most two times the spill length, if the beam has a pulse<br>
> structure. Otherwise a few seconds ought to be enough.<br>
> <br>
> <br>
> A dry-run demo (3 instances), using the 'mbuffer' program to limit rates:<br>
> <br>
> ---<br>
> <br>
> # Generate data (at 10 MB/s):<br>
> <br>
> file_input/empty_file --lmd \<br>
> | mbuffer -r 10M -q \<br>
> | empty/empty --file=- --server=trans,size=1G<br>
> <br>
> # Serve the data, with dropold (can be removed):<br>
> <br>
> empty/empty --trans=localhost --server=trans:8000,size=1G,dropold=10s<br>
> <br>
> # 'Analysis' (at 1 MB/s).<br>
> # Look at the data (buffer times)<br>
> # Note: dd is used here to strip the 16-byte transport protocol startup<br>
> # message.<br>
> <br>
> nc localhost 8000 \<br>
> | mbuffer -r 1M -q \<br>
> | dd bs=16 skip=1 \<br>
> | empty/empty --file=- --print-buffer<br>
> <br>
> ---<br>
> <br>
> Note: the buffer times only relates to the middle server, not the original<br>
> data generation. But in this case is good enough to show the difference.<br>
> If 'dropold' is not used in the middle instance, then the last instance<br>
> (doing --print-buffer) will be seen to lag further and further.<br>
> <br>
> <br>
> Cheers,<br>
> Håkan<br>
> <br>
></div>
</span></font>
</body>
</html>