update timestamp calibration constants based on 2x2 data

[krwood]

Timestamp "slope" calibration constants extracted from 2x2 data for each io_group separately by taking the mode of the (sync timestamps/1E7 - 1) across runs 50005, 50011, 50017, and 50018. Assumes the PPS timestamps are registered in each pacman at the same absolute time (i.e. all of the offset calibration constants are zeroed out). This assumption will need to be checked by looking for small offsets in the drift coordinate in tracks across TPC boundaries. This effect is expected to be very small. Values extracted by Brooke @russellphysics - see example plot below:

[mjkramer]

Also cherrypicked onto feature_run_on_data for reflow v5.

[YifanC]

@russellphysics @krwood @jaafar-chakrani @seg188 @kwresilo @diaza @mjkramer @liviocali
Hello! Sorry for haunting this topic and spamming you all. (There's no hurry to respond as you all are very busy:))
Thanks to Jaafar patiently chatting with me, this timestamp correction finally makes a bit more sense to me.

I will base my mumble on this simple equation t_c = (t_r - c_0) / (1 + c_1) (eq.1) where t_c is corrected timestamp; t_r is the raw timestamp; c_1[1E-7 tick] is the clock difference at each reset which corresponds to the pacman clock frequency; c_0[tick] indicates the "delay" of the pacman clocks which is also susceptible to the frequency differences of the pacman clock so it makes sense to have the frequency correction as well.

My naive understanding is that the above plot/measurement address the c_1, if the clocks are stable. Let's ignore the io_group 6 has some unexpected behaviour. Again, should we expect the same c_1 than the values from Bern?
We don't have a reference for all the systems, so the c_0 information is not accessible. I still think if the clocks are stable, the relative differences among c_0's from the single modules should be applicable to 2x2? I also wondered why can't we have unix time in microsecond precision, but it seems there will be a global timing systems so such time correction will no longer needed in FSD or ndlar depending on the pacman firmwares? I remember Brooke said potentially the c_0 issue could be addressed in the benchtop test. Is this still the plan?

My main concern and the reason to write here is that I don't understand the time correction logic applied on the single module data and I'm not sure it's correct? The logic and the result are summarised here with confirmation from /global/cfs/cdirs/dune/users/kwresilo/ana/PACMAN_ts_corr.ipynb. There are a few typos but it doesn't affect the reading. It does not match with the logic we laid out above. My guess of one reason why it is wrong is that eq1 becomes delta_t = t_r - t_c = c_1 * t_c + c_0 where the fit is doing delta_t = t_r - t_c = c_1 * t_r + c_0.

The effect is multiple mm if the correction is wrong, maybe not the most issue in the detector, but would double at the cathode (opposite drift). Since we are reprocessing the single module data and trying to learn and compare a few things, I think perhaps we should revisit this as well.

[diaza]

Would applying the 2x2 procedure on the single modules provide a check on whether c1 is being extracted properly?

[krwood]

c1 captures the difference in SoC clock frequency among pacman. The SoC clock frequency is sensitive to environmental conditions, like temperature. There were different ways of extracting the calibration constants for single module runs because the triggering was cabled up different (every pacman got an external trigger signal from the LRS). Because we don't have that here we measure c1 by counting the number of ticks between PPS. We assume all PPS arrive at the same time (c0=0), which was motivated by measurements with a scope that showed <<<100ns (= 1 CRS tick) jitter.

To a sanity check, we can look at a sample of tracks spanning TPCs, measure the hit displacement along the tracks at boundaries, and compare before and after the timestamp calibration is applied.

Clock stability doesn't imply anything about the applicability of single module c0's to 2x2 c0's. c1's may be correlated, but c0 should not.