sbn::ExtraTriggerInfo: added cryostat trigger information #110
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
ICARUS trigger hardware is going to contribute one additional information (see e.g. SBNDocDB 36096 or 36264).
This PR extends the
sbn::ExtraTriggerInfo
data product to accommodate for that new information, that is the time from the opening of the beam gate at which the hardware sees the trigger. This is a more direct quantification of that time than with the White Rabbit timestamp, because once the hardware takes the trigger decision, this time is frozen by the very same hardware, while it takes further time (and jitters) for the decision to reach the timestamping hardware. In the ICARUS hardware the time is measured in FPGA ticks, but the data product should store it in nanoseconds, delegating the decoding of the value upstream.The protocol is a default value
NoTrigger
that denotes the absence of this information, a class method to test its availability (hasTrigger()
), and direct access to the data member value (beamToTrigger
).The change is backward-compatible in that old data will look like they don't have this part of the trigger information. However, the additional information is mostly diagnostics for trigger study and performance evaluation, and I don't foresee physics analyses directly using it.
Reviewers: