[subexp-daq] Question on DRASI and R3BFUSER

[Hans Toshihide Törnqvist]

Dear Günter,

On 2024-04-16 18:55, Weber, Guenter Dr. wrote:
> Dear friends,
> 
> ...
> 
> In addition there is a file r3bfuser.cfg with a single entry:
> 
> wr_id=0x200
> 
> Moreover, in the main.cfg we have the entry defining the VULOM 
> functionality:
> 
> GSI_VULOM(0x03000000) {
> timestamp = true # needed to get timestamps in the data output
> ecl=0..15
> }
> 
> As I understand, the entry in main.cfg is not enough to activate the 
> VULOM timestamp, but need also the (a bit obsucre looking) entry in the 
> r3bfuser.cfg, right? And both together result in the creation of an 
> additional LMD subevent with hardcoded type=10 where the time stamp 
> information is written.
> 
> Is there a good reason why the VULOM timestamp (and also VETAR2 if 
> available) is not simply written to the subevent defined in the command 
> that starts DRASI? And why is the existence of the timestamp defined in 
> two different files?

I would love to find a way to clean this up, but the gist is:

- nurdlib reads out and verifies module data and does not know how to 
present them to the outside world.

- r3bfuser provides the glue between the nurdlib module data and the DAQ 
backend.

This way nurdlib is not married to MBS or drasi and could be used by 
"any" such code. It will read e.g. timestamps from a vulom or vetar in 
single- or multi-even mode or whatever and dump that straight into an 
event buffer, no further processing done (well, timestamps must be saved 
in big-endian form). Nurdlib has no idea about how the DAQ backend needs 
the timestamp to be presented. The config in main.cfg for the trlo ii 
modules tells nurdlib that we expect and want to read out timestamps for 
every trigger, which is not something we always want from such a module. 
The vetar only delivers timestamps so that is not configurable.

So, r3bfuser has to convert the raw data from nurdlib to something the 
backend understands. MBS/drasi expects a unique timestamp ID for every 
timestamped system which is what one sets in r3bfuser.cfg. The code then 
asks nurdlib for a timestamping module (I think there's a 
priority-selection, like try first vetar then vulom then tridi...), and 
for every event gets the region in the event buffer with the raw data 
from the module. It takes the first 64-bit number and creates the first 
10/1 sub-event with the configured timestamp ID, error bits, the 
formatted timestamp etc. The behaviour of this part can be defined in 
many ways, which is why it's not done in the simple built-in f-user in 
nurdlib but confined to the external r3bfuser.

I'm open to suggestions on how to simplify this without making the code 
sentient :)

> To make the situation more puzzling (to us), in the second system that 
> is now finally running again, we don't have a r3bfuser.cfg at all. Here 
> the command to start the DAQ looks like this:
> 
> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi \
> --triva=master, at 0x02,fctime=10,ctime=300 \
> --log-no-rate-limit \
> --server=stream:8003 \
> --server=drasi,dest=lyserv:7000 \
> --buf=size=200Mi \
> --max-ev-size=0x100000 \
> --eb=lyserv:7000 \
> --subev=crate=0,type=88,subtype=8800,control=0,procid=12 \
> "$@"
> 
> Is the "@0x02" in this command replacing the r3bfuser.cfg? If yes, 0x2 
> instead of 0x200 tells us that there is no timestamp, yes?

No, the @0x02 is the short-hand address for the trigger module (triva), 
and really means "address = 0x02 << 24 = 0x02000000". Drasi needs to 
know which module to talk to to know there are accepted triggers, to 
release deadtime etc.

Best regards,
Hans

> Ok, so the bottom line is, that we basicly don't understand this 
> timestamp thing :-)
> 
> Could you give us a hint?
> 
> Thank you so much!
> 
> Best greetings
> 
> Günter
> 
> 
> 
> 
>