A few comments/questions on the DAQ commissioning guide
Thanks a lot for have written the detailed current DAQ commissioning procedure. I understand it was done with the existing tools, and I'll try to focus on what is different with the updated tools and what could be improved with new tools, likely coming from the development branch.
Since there is no cooling, it is prudent that the detectors be powered on for as little time as possible! And this time must be less than 30 minutes!!!
If I understand the rationale behind keeping powered the chambers during less than 30 minutes, wouldn't it be much preferable to monitor the actual temperature?
Test 1: Fiber power test
Do you happen to know where the sources of fiber_test.py
can be found (p5 CTP7 are not accessible right now)? Integrating the optical RX power value in the xDAQ monitoring interface should be quick to do, would be beneficial for the development branch and would simplify the test for less experienced people with a data displayed in a nice web interface. Actually, there is already an open issue on GitLab: https://gitlab.cern.ch/cmsgemonline/cmsgemos/-/issues/79.
Test 2: communication test
The testConnectivity.py
command arguments will change with the latest version of the legacy software. The gemType
and detType
are now mandatory. Moreover, I would store the right GBT phases, as well as the raw GBT phase scan data, with --writePhases2File
. As explained in #1, we do not expect the right GBT phases to change, so it might be interesting to keep track of the GBT phase scan results.
Test 3: check VFAT info
What is the purpose of this check? What do you expect to learn from that? (This is just a naive question, sorry.)
In "Test 1: configuring super chambers"
Many of the chambers on the minus endcap were installed before the usage of DAC fit test for VFATs. These chambers still operate correctly, but will fail the DAC fit test. Thus, be sure to use the
--acceptBadDACFits
flag.
One should check by eye the failing fits. In can be innocuous, but also testify from an issue with the VFAT, GEB or FEAST.
The DAC scan may fail [...]
In "Test 2: SCurves"
To fix this, manually write the DAC values from the
testConnectivity.py
output to the CTP7
How? Actually, that should be fixed in the latest version of legacy (probably not yet installed at p5).
Test 3: SBit threshold
This test definitively needs improvements, some Sbit connectivity errors are not caught by the
[...] Each VFAT has 8 SBits [...]
This is not right, each VFAT can send either 64 (our configuration) or 128 Sbits per BX. All these Sbits are time-multiplexed on 8 Sbits differential pairs (called "lines" in GEM jargon).
The DAC scan may fail at this point and one of the most common reasons for this occurence is that reference voltages on the CTP7 did not get correctly updated from the data base. [...]
Could be good to explicit what fail means here, i.e. the DAC cannot reach the nominal value/current. The DAC scan could also "fail" for other reasons, such as communication instability.
I believe the "Future phases of commissioning ???" section must be discussed thoroughly. Many sensitive and important parts of the of the electronics are not thoroughly tested or not even tested at all. I'm thinking among others about the temperature and voltages sensors, other SCA features like the VFAT reset lines, or the individual test of each Sbit. How can we proceed with that?