[subexp-daq] Question on DRASI and R3BFUSER

[Håkan T Johansson]

On Wed, 17 Apr 2024, Hans Toshihide Törnqvist wrote:

> 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...),

I think a scary part here is that r3bfuser auto-finds a module to provide 
the time.  It would perhaps be possible to encourage to user to specify 
which (kind of) source (vetar, vulom, tridi...) one would like to use for 
the special formatting into the DAQ-readable location, and if not 
available, it errors out.  There could also be an option 'auto' for the 
lazy, who then get to keep both pieces when it breaks (or rather - be 
confused as to which timestamp source is used).

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

This is the 'wr_id' specified in the r3bfuser.cfg.

> 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

Cheers,
Håkan


>
>> 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
>> 
>> 
>> 
>> 
>> 
> -- 
> subexp-daq mailing list
> subexp-daq at lists.chalmers.se
> https://lists.chalmers.se/mailman/listinfo/subexp-daq
>