<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15">
<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 Hans and <span>Håkan</span>,</p>
<p><br>
</p>
<p>thank you very much for the detailed explanation. Now I have two remaining questions:</p>
<p><br>
</p>
<p>1) To tell the second DAQ system to also put a timestamp in the output LMD data, we would need to create r3bfuser.cfg with the wr_id entry, right?</p>
<p>(I am surprised that r3bfuser.cfg does not need to exist. I imagine a user getting crazy over changes made in his r3dfuser.cfg not having any effect on the DAQ, before realizing that there is a typo in the filename.)</p>
<p>And then also tell the VULOM in main.cfg to produce the timestamp (i.e. basicly copy the settings from the first DAQ system).</p>
<p><br>
</p>
<p>2a) Why does in our first DAQ system the address of the TRIVA not need to be set?</p>
<p><br>
</p>
<p><font face="Calibri,Helvetica,sans-serif" size="4" color="black" style="font-family:Calibri,Helvetica,sans-serif,serif,"EmojiFont""><span id="x_divtagdefaultwrapper" style="font-size:14pt"><font size="2"><span style="font-size:10pt">--triva=master,fctime=10,ctime=50
\</span></font></span></font><br>
</p>
<p><br>
</p>
<p>versus<br>
</p>
<p><br>
</p>
<p><font face="Calibri,Helvetica,sans-serif" size="4" color="black" style="font-family:Calibri,Helvetica,sans-serif,serif,"EmojiFont""><span id="x_divtagdefaultwrapper" style="font-size:14pt"><font size="2"><span style="font-size:10pt">--triva=master,@0x02,fctime=10,ctime=300
\</span></font></span></font><br>
</p>
<p><br>
</p>
<p>2b) What are fctime (fast clear time) and ctime (conversion time) actually doing?
<br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>Thanks a lot!</p>
<p><br>
</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> Mittwoch, 17. April 2024 10:16:41<br>
<b>An:</b> Discuss use of Nurdlib, TRLO II, drasi and UCESB.<br>
<b>Cc:</b> Weber, Guenter Dr.<br>
<b>Betreff:</b> Re: [subexp-daq] Question on DRASI and R3BFUSER</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText"><br>
On Wed, 17 Apr 2024, Hans Toshihide Törnqvist wrote:<br>
<br>
> I would love to find a way to clean this up, but the gist is:<br>
><br>
> - nurdlib reads out and verifies module data and does not know how to <br>
> present them to the outside world.<br>
><br>
> - r3bfuser provides the glue between the nurdlib module data and the DAQ <br>
> backend.<br>
><br>
> This way nurdlib is not married to MBS or drasi and could be used by <br>
> "any" such code. It will read e.g. timestamps from a vulom or vetar in <br>
> single- or multi-even mode or whatever and dump that straight into an <br>
> event buffer, no further processing done (well, timestamps must be saved <br>
> in big-endian form). Nurdlib has no idea about how the DAQ backend needs <br>
> the timestamp to be presented. The config in main.cfg for the trlo ii <br>
> modules tells nurdlib that we expect and want to read out timestamps for <br>
> every trigger, which is not something we always want from such a module. <br>
> The vetar only delivers timestamps so that is not configurable.<br>
><br>
> So, r3bfuser has to convert the raw data from nurdlib to something the <br>
> backend understands. MBS/drasi expects a unique timestamp ID for every <br>
> timestamped system which is what one sets in r3bfuser.cfg. The code then <br>
> asks nurdlib for a timestamping module (I think there's a <br>
> priority-selection, like try first vetar then vulom then tridi...),<br>
<br>
I think a scary part here is that r3bfuser auto-finds a module to provide <br>
the time. It would perhaps be possible to encourage to user to specify <br>
which (kind of) source (vetar, vulom, tridi...) one would like to use for <br>
the special formatting into the DAQ-readable location, and if not <br>
available, it errors out. There could also be an option 'auto' for the <br>
lazy, who then get to keep both pieces when it breaks (or rather - be <br>
confused as to which timestamp source is used).<br>
<br>
> and <br>
> for every event gets the region in the event buffer with the raw data <br>
> from the module. It takes the first 64-bit number and creates the first <br>
> 10/1 sub-event with the configured timestamp ID,<br>
<br>
This is the 'wr_id' specified in the r3bfuser.cfg.<br>
<br>
> error bits, the <br>
> formatted timestamp etc. The behaviour of this part can be defined in <br>
> many ways, which is why it's not done in the simple built-in f-user in <br>
> nurdlib but confined to the external r3bfuser.<br>
><br>
> I'm open to suggestions on how to simplify this without making the code <br>
> sentient :)<br>
><br>
>> To make the situation more puzzling (to us), in the second system that <br>
>> is now finally running again, we don't have a r3bfuser.cfg at all. Here <br>
>> the command to start the DAQ looks like this:<br>
>> <br>
>> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi \<br>
>> --triva=master,@0x02,fctime=10,ctime=300 \<br>
>> --log-no-rate-limit \<br>
>> --server=stream:8003 \<br>
>> --server=drasi,dest=lyserv:7000 \<br>
>> --buf=size=200Mi \<br>
>> --max-ev-size=0x100000 \<br>
>> --eb=lyserv:7000 \<br>
>> --subev=crate=0,type=88,subtype=8800,control=0,procid=12 \<br>
>> "$@"<br>
>> <br>
>> Is the "@0x02" in this command replacing the r3bfuser.cfg? If yes, 0x2 <br>
>> instead of 0x200 tells us that there is no timestamp, yes?<br>
><br>
> No, the @0x02 is the short-hand address for the trigger module (triva), <br>
> and really means "address = 0x02 << 24 = 0x02000000". Drasi needs to <br>
> know which module to talk to to know there are accepted triggers, to <br>
> release deadtime etc.<br>
><br>
> Best regards,<br>
> Hans<br>
<br>
Cheers,<br>
Håkan<br>
<br>
<br>
><br>
>> Ok, so the bottom line is, that we basicly don't understand this <br>
>> timestamp thing :-)<br>
>> <br>
>> Could you give us a hint?<br>
>> <br>
>> Thank you so much!<br>
>> <br>
>> Best greetings<br>
>> <br>
>> Günter<br>
>> <br>
>> <br>
>> <br>
>> <br>
>> <br>
> -- <br>
> subexp-daq mailing list<br>
> subexp-daq@lists.chalmers.se<br>
> <a href="https://lists.chalmers.se/mailman/listinfo/subexp-daq">https://lists.chalmers.se/mailman/listinfo/subexp-daq</a><br>
></div>
</span></font>
</body>
</html>