Time calibration of detector with common clock

[ajedele]

Currently, the newest version of R3BRoot has a function named R3BTimestitch. Below is an overview, description of the issue, the correction and the detectors affected.

Overview of the Timestitcher:
The function corrects the coarse time cycling of our TDCs. Typically, if the timing cycle is the same, a hit comes in somewhere in the middle of the cycle and when subtracting, for example, LOS from TOFD, you get the correct coarse time. However, sometimes, the LOS hit may come at the end of the cycle and the TOFD at the beginning. In this case, the coarse timing value is negative and incorrect. To compensate for this, we add x.5 time cycles, where x is an integer (usually 2-4 - value depends on how many clock cycles you will go through relative to the other electronics). We then take ((time + x.5*_length_of_cycle) % length_of_cycle). Then we subtract the 0.5*length_of_cycle that we added.

Issue:
If the electronics run of the same clock, you can do the time correction in 1 step, as done in the R3BTimestich code. However, NOT ALL OF OUR DETECTORS RUN ON AN INTERNAL CLOCK OF 200 kHz. For example, the 1st generation of our fiber detectors using the old drift chamber FW (should be s444, s473, s454) and the KILOMs run on a 150 kHz clock (currently incorrect in the code. Now set as 40965(ns), should be 40966.67(ns)). In this case, if you do the correction in 1 step, there will be an incorrect offset that is produced.

Correction:
To avoid the offset issue, the time correction should always be corrected in 2 step. Each detector should be correct individually and then the corrected times should be subtracted from each other.

Otherwise ALL detectors NEED to run on a 200 kHz clock.

Detectors affected:
-S2
-SOFIA start in cave c (maybe)
-LOS
-TOFD
-RPC
-Fibers
-NeuLAND (maybe)
-Any other current or future detector that runs on the clock distribution

[jose-luis-rs]

Thanks Andrea for reminding me of this class, also the CLOCK frequency is missing in the algorithms!

[ajedele]

Hi Jose Luis,

I'm not quite sure what you means with the clock frequency? Are you referring to the frequency of the clock distribution boards or the frequency of the electronics?

Also, could we rename this file? For me, it's not sure intuitive based on the name. I would recommend R3BCoarseTimeCorrector or something similar. Otherwise it gets confused with the old TimeStitcher or the timestitching in the unpacker, which do something completely different.

[jose-luis-rs]

Hello Andrea

About names, R3BTimestitch is used to calculate time differences between different time channels taking into account what you said in your first entry, although I have the impression that now you are talking about a simple time coarse correction applied by channel.

For me R3BTimeStitch is a time stitching class based on time coarse corrections, which is used for a proper synchronization of independent time channels, but we could change the name to R3BCoarseTimeStitch.

R3BCoarseTimeCorrector could also be implemented if you want to correct specific channels.

[jose-luis-rs]

Hello Andrea
In my previous entry I got confused with other developments, please, could you comment on this change?

• Now set as 40965(ns), should be 40966.67(ns))
  where do you see the value of "40965(ns)"? or how do you obtain it?
  Thanks in advance

[ajedele]

Hi Jose Luis,

There should be 2 values used in the coarse time correction: the width of the TDC and the clock frequency of the individual electronics. The clock frequency is 5ns for TAMEX and VFTX. It's 6.67ns for the KILOMs and the old CDC firmware.

The width of the bins is the correct values you have in the TimeStitcher code.

To get the correct offset, you need to multiply the clock width by the clock frequency and then by the factor of x.5, take the modular and subtract the factor of 0.5.

Basically, if you inputted the electronics of the device you are correcting 2 times (for example TAMEX, TAMEX), it would be correct.

[ajedele]

Sorry. I closed it. It shouldnt be closed. Wrong button

[jose-luis-rs]

Ok

[klenze]

In my understanding, time-stitching is the grouping of detector hits which appeared within a preset stitching window into one physics event. Unless I am very mistaken, this is not something which is feasible to do in R3BRoot for arbitrary sets of detectors.

Also, the modulus is not predefined over floating point numbers. Do you mean that as shorthand for a % b := a - b*floor( a/b )?

[jose-luis-rs]

This task was developed to manage the time correction (or time stitch) of two time signals given by a module (TRB, FEBEX, ClockTDC, ...) with the frequency of 200MHz. But we could need to use this class with other electronics with frequencies of 150 and 250 MHz.

In these lines:
: fRange1(2048 * 5.) // ns
, fRange2(2048 * 5.) // ns
, fRangeTamex(2048 * 5.) // ns
, fRangeTrb(2048 * 5.) // ns
, fRangeVftx(8192 * 5.) // ns
, fRangeClockTDC(4096 * 5.) // ns

the factor 5ns/ch is calculated for the frequency of 200MHz, for 250MHz it is 4ns/ch and for 150MHz is 6.67ns/ch. But this only needs a minor modification in the task.

[ajedele]

The idea is to 'reset' the coarse time so that it is in the middle of the coarse time range for each module instead of at the edges. This correction also becomes important if the timing difference between 2 modules exceeds (clock frequency)*(width of bins) - currently not an issue since even a 2048 width bin running on a 200MHz clock is 10 us.

This is a bug and not an enhancement. If you run the code inputting KILOM(CTDC right now) and TAMEX, you get a approx. 2000 ns offset. There is a condition in the Cal2Hit condition that the tof time has to fall within the timing window, which the calculated offset does not. We should uniformize this across all detectors, so that if we changed to different electronics or someone else works on the calibration code, the funciton still works.