Time treatment in OpHiFinderDeco

[vpec0]

OpHiFinderDeco assumes raw::OpDetWaveform's timestamp to be (presumably unix time) in microseconds, see Line 130 in OpHitAlg_deco.cxx.

I am not sure, if this convention is followed in the digitizers (there are multiple, specific to each detector) but this seems to be the case as the output timestamps can bedirectly compared with the MCParticle times (whic are in ns). @jroto Can you confirm that the digitizers assume the timestamp to be in microseconds since the simulation's T0?

Current PDHD decoder stores the raw::OpDetWaveform timestamp as unix time in ticks. This convention is incompatible with the OpHitFinder. (The timestamp is taken from daq:: fddetdataformats::DAPHNEFrame/DAPHNEStreamFrame in the decoder)

Moreover, the timestamps are stored as double in raw::OpDetWaveform. Storing PDS clock timestamps in unix time into a double reduces the precision. The PDS clock runs at 16 ns per tick, however, double can only keep precision down to 16 ticks, or 256 ns. Originally, they are stored in dunedaq::detdataformats:: DAQHeader as two int32_t.

To summarize, there are 2 issues:

1. Opdet reconstruction uses differing time units to the data decoder - microseconds vs ticks.
2. Definition of raw::OpDetWaveform causes loss of precision for the waveform timestamp - double vs 2xint32_t - 16 ns -> 256 ns.

[jroto]

@jroto Can you confirm that the digitizers assume the timestamp to be in microseconds since the simulation's T0?

I think you are right.