Do not treat `(dragon_timestamp - ucts_timestamp) > 1e3` as jump
maxnoe opened this issue · comments
While having ucts time significantly earlier than dragon time should still be an issue, it is certainly not a jump by a single event forwards in time, so cannot be handled like this and it actually creates more problems than it solves to do so (jumps in every following event).
The reason is that the pps_counter increases before the tenMHz counter rolls over:
Run 3365 from 2020-12-11, occurs in event 8117
8111 | 1607725668.997992 | 8 | 9979916
8112 | 1607725668.998665 | 8 | 9986644
8113 | 1607725668.998740 | 8 | 9987397
8114 | 1607725668.998997 | 8 | 9989970
8115 | 1607725668.999175 | 8 | 9991749
8116 | 1607725668.999665 | 8 | 9996648
8117 | 1607725670.000000 | 9 | 9999999
8118 | 1607725669.000665 | 9 | 6652
Question: which pps_counter and tenMHz counters are these?
For the UCTS-TiCkS, the pps_counter and tenMHz counters should be coherent, as long as they are used in SPI mode (which is the standard in LST). {In non-SPI mode, there was a possibility that they could be incoherent, but this shouldn't take effect for LST}
These are dragon board counters, the first module in the data stream to be exact
Aha, okay... thanks. So, not on our TiCkS, at least...
If it's in a Dragon FPGA, it should be possible to ensure that the roll-over happens simultaneously, but it can be a bit tricky.