During the development of coincidence triggering in the MLT for the dunedaq-v4.1.0 release, it was noticed that TCs produced by CustomTriggerCandidateMaker - which uses the TimestampEstimatorSystem functionality - are off (timewise) to timestamps created internally within the MLT that uses the same base function:
std::chrono::duration_cast<std::chrono::microseconds>( std::chrono::system_clock::now().time_since_epoch().count() ) using the same clock frequency.
After further inspection, it was noticed that the calculation of the clock frequency inside the TimestampEstimatorSystem has a bug where the resulting value is rounded due to assuming an integer clock frequency once converted to MHz.
Example for clock frequency 62'500'000 Hz:
BEFORE (original code):
(m_clock_frequency_hz / 1'000'000) = 62
AFTER (with fix in this PR):
(m_clock_frequency_hz / 1000000.0) = 62.5
This was not noticed before as we were using 50 MHz clock that does not suffer from the division rounding.
During the development of coincidence triggering in the MLT for the dunedaq-v4.1.0 release, it was noticed that TCs produced by CustomTriggerCandidateMaker - which uses the TimestampEstimatorSystem functionality - are off (timewise) to timestamps created internally within the MLT that uses the same base function:
std::chrono::duration_cast<std::chrono::microseconds>( std::chrono::system_clock::now().time_since_epoch().count() )using the same clock frequency.After further inspection, it was noticed that the calculation of the clock frequency inside the TimestampEstimatorSystem has a bug where the resulting value is rounded due to assuming an integer clock frequency once converted to MHz.
Example for clock frequency 62'500'000 Hz: BEFORE (original code): (m_clock_frequency_hz / 1'000'000) = 62 AFTER (with fix in this PR): (m_clock_frequency_hz / 1000000.0) = 62.5
This was not noticed before as we were using 50 MHz clock that does not suffer from the division rounding.