RF Calibration

Overview

• The RF signal from the accelerator comes in at a frequency of 499 MHz, regardless of the beam bunch frequency (typically 249.5 MHz). It is multiplexed and read out in 6 different locations; in one channel of each of the following crates:
  • F1TDCs: TAGH, FDC, PSC
  • CAEN TDCs: TOF
  • FADC250s: TAGH, ST

• Because the RF signal is periodic it is effectively self-analyzing: it can be compared against itself to study our understanding of the timing. It also serves as a good test of whether the TDC → time conversion is working properly.

MENTION CRATE/SLOT/CHANNEL

• However, the FADC250 algorithms were not designed to extract the pulse times from signals with a waveform of the RF distribution (see plot), so these signals are ignored.

Waveform of the RF Signal in TAGH FADC Crate

Notes / References

• Link to the RF_online plugin and scripts, which contains all of the code needed for these calibrations: Link
  • The ROOT macros for studying the data are located in the calib_scripts subfolder in this plugin directory.
• The following code snippets assume that you have checked out the online monitoring plugins (Link) to a folder defined by the environment variable:

$ONLINE_PLUGINS

• A wiki page detailing which ROCs are which can be found at: Link

Validating TI-Time Uniformity

• As detailed in GlueX Doc 2686, a copy of the global system clock time is present on each ROC (on the Trigger Interface (TI) board). To check whether they are all consistent with each other, run the RF_online plugin on a small sample of data (e.g. 10000 events), and then run the RFMacro_ROCTITimes.C macro on the resulting ROOT file:

root -l hd_root.root
.L $ONLINE_PLUGINS/RF_online/calib_scripts/RFMacro_ROCTITimes.C
main();

• It will print to screen any ROCs whose system clock is out of time with the average system clock times from the other ROCs. It will also draw the corresponding histograms. ROC 1 is known to be out of time with the others, but it's not clear that it's used for anything ...

• If any of the other ROCs are out of time with the others, notify the DAQ and/or electronics experts.

Time difference between ROC 61 (rocfdc11) and the times of the other ROCs

Time difference between ROC 1 and the times of the other ROCs

TDC → Time Conversion

• The details of how to convert the F1TDC and CAEN TDC signals to times are in GlueX Doc 2686. These algorithms are implemented by the DTTabUtilities class (Link). The

• F1TDCs: The F1TDC times are converted using the ROC TI time as the reference time. The DF1TDCConfig class contains the necessary constants for performing the conversion. If this class is not present in the data stream, the constants in the CCDB are used (Link). Also, the DF1TDCConfig information in the data stream was incorrect for runs <= 2965, so the CCDB constants are used for these runs as well.

• CAEN TDCs: The TDC → time conversion constant for the CAEN TDCs was derived by Ben Raydo and is documented in this email. This conversion constant has an uncertainty of +/- 0.0012 ps.

Validation

• Since they are periodic, the RF time signals are excellent for checking whether the TDC signals are being properly converted to time. To check this, run the RF_online plugin on a small sample of data (e.g. 10000 events), and then run the RFMacro_TDCConversion.C macro on the resulting ROOT file:

root -l hd_root.root
.L $ONLINE_PLUGINS/RF_online/calib_scripts/RFMacro_TDCConversion.C
main();

• This macro will draw histograms for each detector system of the time difference between the first RF signal in an event and the times of the subsequent RF signals. Zoom in on these histograms and confirm that the secondary peaks are occurring at the correct times.
  • The TOF & TAGH RF signals read out 1/128 times, so the first delta-t peak should be at 128*1000/499 = 256.513 ns.
  • The PSC & FDC RF signals read out 1/64 times, so the first delta-t peak should be at 64*1000/499 = 128.257 ns.

• If the RF signals don't arrive at their expected times, notify the online and/or electronics experts.

TDC Conversion Test

TDC Conversion Test: Zoomed in

RF Time Calibration

RF Signal Period

• To confirm that the RF signal is arriving at approximately 499 MHz, run the RF_online plugin on a small sample of data (e.g. 10000 events), and then run the RFMacro_TDCConversion.C macro on the resulting ROOT file:

RF Time Resolution

2) Study the resolution of each source of the RF signal: "DeltaT_RF_Itself" directory. Check in these constants.

root -l hd_root.root
.L $ONLINE_PLUGINS/RF_online/calib_scripts/RFMacro_SelfResolution.C
main();

Time Resolution: The resolution is the RMS / sqrt(2)

ccdb add PHOTON_BEAM/RF/time_resolution_sq -r 0- rf_time_resolution_sq.txt #"time resolution squared"

Coarse Time Offsets

3) Do a rough alignment of each RF system with respect to the TOF signal: "AbsoluteDeltaT_RF_OtherRFs" directory & FitMacro_RF_CoarseOffsets.C Macro. Check in these constants. - This is important in case the RF signal period is not exactly 499 MHz. If it's slightly wrong, add the time offsets are huge, then propagating across several micro-s will result in a many-ps error in the time.

root -l hd_root.root
.L $ONLINE_PLUGINS/RF_online/calib_scripts/RFMacro_CoarseTimeOffsets.C
main();

Coarse time offsets between RF signals

ccdb add PHOTON_BEAM/RF/time_offset -r 0- rf_coarse_time_offsets.txt #"coarse time offsets"

Fine Time Offsets

5) Do a detailed alignment of each RF system with respect to the TOF signal: "AverageDeltaT_RF_OtherRFs" directory. Update these constants (and the uncertainties).

root -l hd_root.root
.L $ONLINE_PLUGINS/RF_online/calib_scripts/RFMacro_FineTimeOffsets.C
main();

Coarse time offsets between RF signals

ccdb add PHOTON_BEAM/RF/time_offset -r 0- rf_fine_time_offsets.txt #"fine time offsets"
ccdb add PHOTON_BEAM/RF/time_offset_var -r 0- rf_time_offset_vars.txt #"time offset variances"

Intra-system Jitter

4) Study the resolution when taking the difference between RF times at different sources: "DeltaT_RF_OtherRFs" directory. - If these resolutions are much larger than the individual system uncertainties, then do not average the system times together. - This is the default behavior of the DRFTime factory (for the signals in the data stream, only uses the system with the best time resolution)

Check Alignment to Tagger Hodoscope

CONFIRM ALIGNMENT TO TAGGER HODOSCOPE: 1) Once the tagger hodoscope has been aligned to the RF, confirm the alignment: "DeltaT_RF_TAGH" directory.

     - If it is out-of-line, realign the tagger to the RF (outside the scope of this plugin)