Calibration scans with tracking data format specs
Summary
This sums up issue#230 on GitHub. Needed for the various scan types is a definition of what the various bit fields mean in the output data format; current implementation in cmsgemos does the following:
RunType: 4 bits [59:56] in AMC H2
:
- normal operations: 1
- latency data: 2
- "threshold" data : 3 (possibly redundant with latency, as only one parameter is changing over time in a given scan)
- s-curve data: 4, new type, two parameters change over the scan: channel and calibration pulse height
RunParams 24 bits [55:32] in AMC H2
:
Here
- P.S. = CFG_PULSE_STRETCH,
- isC = isCurrentPulse with 0 (1) = False (True),
- isExtTrig = isExternalTrig with 0 representing calibration mode and 1 would be an external trigger; if isExtTrig = 1 and CFG_CAL_DAC = 0 it would imply signals coming from externally injected charge (e.g. from particles in the detector or a signal generator injecting into the VFAT)
- selC = CFG_SEL_COMP_MODE; (0x0 = CFD, 0x1 = ARM, 0x2 = ZCC). If CFG_SEL_COMP_MODE = 0 we are in CFD mode and CFG_THR_ZCC_DAC is released on the ZCC after the ARM comparator is determined the pulse is over CFG_THR_ARM_DAC.
The implementation in cmsgmeos
of the tracking data scans scans has followed what outlined in the python script trackigDataCalibrationScan.py (tested in http://cmsonline.cern.ch/cms-elog/1089564) without the usage of the calibration data format.