Data quality check -- PPS - timestamp offset

For data alignment we rely on the smurf "timing server" having decent NTP, and providing that timebase to the smurf timing hardware.

As part of data quality, we must keep an eye on the offset between the times when "Counter 2" crosses a second boundary, and the value of the Counter 0 (number of 480000 kHz ticks since last PPS edge). This should be within a few ms of zero. If this drifts, it indicates some major discrepancy between:

• the source of the PPS, i.e. the main GPS-synced M1000
• the timestamp being tracked in the smurf timing system hardware (which comes via the smurf timing system server, which is getting its timestamp through NTP, which is probably but not necessarily coming from the M1000, too)

More details in READ-010 or on request ...

Start with the issue's reference to READ-010 and identify the existing data-quality checks or entry point for PPS and Counter 0/Counter 2 timestamps. Define the check so the offset between Counter 2's second boundary and Counter 0 is monitored, with completion shown by detecting drift beyond a few milliseconds.