Dear Corryvreckan Experts,
<Type>2149999981</Type>
<Extendword>3356476608</Extendword>
<Description>USBPIX_GEN3</Description>
<Flag>0x00000010</Flag>
<RunN>9740</RunN>
<StreamN>871196070</StreamN>
<EventN>32747</EventN>
<TriggerN>4294967295</TriggerN>
<Timestamp>0x0000000000000000 -> 0x0000000000000000</Timestamp>
<Timestamp>0 -> 0</Timestamp>
<Tags>
<Tag>board=0</Tag>
</Tags>
<Block_Size>1</Block_Size>
</Event>
<Event>
This is the event 32747 in which the trigger number (TriggerN) of the FEI4 reaches its limit and before jumping back to 0 it has one event with some kind of overflow trigger number of: 4294967295. When reading in the data in Corryvreckan (master branch) it basically get stuck at this event and tries to read in all following data into this one event. Trying to veto triggers, filter events or anything has not really worked and this issue would arise everytime the trigger number reaches its limits. Does someone know how to approch this issue?
My Corryvreckan config looks basically like this:
[EventLoaderEUDAQ2]
[EventLoaderEUDAQ2]
[EventLoaderEUDAQ2]
This is what it looks like for the mentioned event, when log level=“TRACE”:
And it continues without finishing the Corryvreckan event.
lhuth
May 23, 2024, 5:27pm
2
Hi @chkrause ,
this looks like an error in the configuration/naming scheme:
chkrause:
|12:03:04.263| (DEBUG) [R:EventLoaderEUDAQ2:usbpix_gen3_board_0_22] bdaq53b: decoding succeeded, event ID 32749
EUDAQ2 returns an event of type bdaq53b, but you expect a usbpix_gen3. I believe your type does not match the description of your data: Renaming the type in the usbpix_gen3_board_0_22 section of the detectors file to bdaq53b should solve your issue.
Please let me know if this solves it
Lennart
Hello Lennart,
lhuth
May 24, 2024, 7:33am
4
Hi @chkrause ,
sorry I misunderstood your issue. You have these two lines:
You shift the trigger ID by 1 and the last trigger ID in hex is 4294967295 = 0xFFFFFFFF. So you are expected to get the next ID being zero since the triggers are limited to the range of uint32_t. Since this cannot really happen (we do not have that many particles) you seem to have written a wrong ID in your DAQ there. Do I get you right, that you do not record triggerIDs? In this case, you can eventually force them to be not set in your EUDAQ2 StdEventConverter. But even if you get a single wrong trigger ID the loader should just skip it and read the next event.
could you post a few more output lines?
cheers,
Hey,
what events are we considering here … the EUDAQ raw event, or the EUDAQ StdEvent?
Cheers,
lhuth
May 24, 2024, 2:14pm
6
well, the conversion here is RawEvent to StdEvent. At the end, we copy pixels if the StdEvent matches.
here a longer output, it just goes on like this:
lhuth
May 27, 2024, 6:21pm
8
Hi,
Hi,
auto trigger_after_shift = static_cast<uint32_t>(static_cast<int>(evt->GetTriggerN()) + shift_triggers_);
to
auto trigger_after_shift = static_cast<uint32_t>(static_cast<int>(evt->GetEventN()) + shift_triggers_);
lhuth
May 28, 2024, 4:22pm
10
Hi,
Nice, but this will break it for everyone not having an eventID, but a triggerID and/or missing events. Is it possible to set the triggerID to the eventID in you StdEventConverter? In this case the corry default should work for you and since you seem not to exchange a trigger number they should be anyways identical
Cheers,