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.