Update to RawWaveformAna module - wfm and trigger timestamps#140
Conversation
…to each protodunes.
…red in either double and uint64 type. Including also the trigger timestamp.
|
✔️ CI build for LArSoft Succeeded on slf7 for e26:prof -- details available through the CI dashboard |
|
✔️ CI build for LArSoft Succeeded on slf7 for c14:prof -- details available through the CI dashboard |
|
parent CI build details are available through the CI dashboard |
|
🚨 For more details about the warning phase, check the ci_tests DUNE phase logs parent CI build details are available through the CI dashboard |
| nSamples = wfm.Waveform().size(); | ||
| TimeStamp = (uint64_t)wfm.TimeStamp(); | ||
| TimeStamp_uint64 = (uint64_t)wfm.TimeStamp(); | ||
| TimeStamp_double = wfm.TimeStamp(); // was in ticks (16 ns, PDS clock), now custom fix to microseconds |
There was a problem hiding this comment.
This comment is valid for both time stamps, you are only changing the number format, not the units here, right?
There was a problem hiding this comment.
yeah, this was an older comment.. I'll update this to be clearer.
|
|
||
| // TriggerCandidateData::time_candidate ... time of the trigger signal? | ||
| // TriggerCandidateData::time_start ... time of the DAQ window opened? | ||
| ts_uint64 = trig.time_candidate; // in ticks (16 ns, time system clock) since epoch |
There was a problem hiding this comment.
If I am reading this correctly, the trigger time and waveform timestamp will still be in different units: trigger in ticks since epoch and waveform in us. Given this is an analyzer already, would it be interesting to have both directly comparable, moving (or adding) the trigger time to us as well?
There was a problem hiding this comment.
I consider this a data dumper more than a true analyzer. I wanted to store relevant data and keep the interpretation for later steps. As is, this dumper can be used on any PDS data (or at least that is the goal), not dependent on the underlying assumptions.
In the next iteration, I will consider adding another branch holding the waveform timestamp relative to the CTB trigger. Which would add the interpretation, but that would be data-format dependent.
There was a problem hiding this comment.
I was just wondering that having the trigger time converted to ticks could be interesting since this in principle requires obtaining info from the pd clock, something which would need to be put by hand in an analysis macro that reads this tree, instead of retrieving this info from the service. Not a big deal if people know what they are doing :-)
Added comments to clarify waveform timestamp conversion and backward compatibility.
3 participants
This PR includes timestamps in two types - double and uint64. Trigger timestamp is read and stored. Trigger info can now be read for PD HD or VD.