Discussing with Jihane we realized that there is not prohibited that the raw data frames come unsorted in cycleID.
This could happen if we have very large events (all sca filled) and somehow different occupancy in the slabs (i.e. one slab super noisy and others very quiet).
This will require a deep revision of the raw converter (for ASCII and binary). To be done after the beam test.
My suspicion is that for ASCII may be more severe effect because the data writing is actually much slower.
For the binary files, it seems to not be a problem:
I have tested that it does not occur at least for the run 050272 (very high rates run) and the run run_050260.
For the time being, I propose to simply "tag" the cycleIDs with potential issues. For that, I attached the TH1F wrongly_reconstructed_cycles with the data.
Discussing with Jihane we realized that there is not prohibited that the raw data frames come unsorted in cycleID. This could happen if we have very large events (all sca filled) and somehow different occupancy in the slabs (i.e. one slab super noisy and others very quiet).
This will require a deep revision of the raw converter (for ASCII and binary). To be done after the beam test. My suspicion is that for ASCII may be more severe effect because the data writing is actually much slower. For the binary files, it seems to not be a problem:
For the time being, I propose to simply "tag" the cycleIDs with potential issues. For that, I attached the TH1F wrongly_reconstructed_cycles with the data.
This histogram has to be used to veto cycleIDs