CMS Pixel Detector Miscellaneous
Phase 1 Phase 2
Layer 1 Replacement Layers 2-4
  Layer 1 Replacement Elog, Page 9 of 13  Not logged in ELOG logo
Entry  Thu Mar 19 17:17:27 2020, Andrey Starodumov, Reception test, M1609-M16012 
Reception test done and caps are glued to modules M1609-M1612.
M1611 graded B due to double column failure on ROC13. Others graded A.
Entry  Wed Mar 18 17:46:07 2020, Andrey Starodumov, Full test, FT of M1601-M1604 
M1601-M1604 passed full test
M1601: grade B
M1602-M1604: Grade C. The main reason is failed pixels during trimbit test.
To be understood the reason and to be upgraded manually.
Entry  Wed Mar 18 17:43:41 2020, Andrey Starodumov, Module assembly, M1605-M1608 
M1605 and M1606: reception done on Mar 17
M1607 and M1608: reception done today
All: grade A

Caps glued to M1605-M1608
Entry  Wed Mar 18 15:23:27 2020, Andrey Starodumov, General, New rules at PSI 
From today only two persons from the group allowed to be present. We are working in shifts: Urs in the morning start full qualification and I in the afternoon test HDIs, run Reception, glue caps and switch the cold box, chiller etc after the full test finished.
Silvan is building usually 4 modules and 6-8 HDIs per day.
Entry  Wed Mar 18 15:16:47 2020, Andrey Starodumov, Software, Change in trimmig algorithm 
Urs yesterday modified the algorithm and tested it. From today we are using it. Main change that threshold for trimming is not any more fixed to VthrComp=79 but calculated based on the bottom tornado value + 20. CalDel is also optimised. This allows us to avoid failures in the trimbit tests due to too high threshold, eg if the bottom of tornado close to 70 a fraction of pixels in a chip could have threshold above 70 and hence fail in the test.
Entry  Mon Mar 16 15:20:03 2020, Matej Roguljic, PhQualification, PhQualification on 16.3. 
PhQualification was run on modules M1561, M1564, M1565, M1566.
Entry  Mon Mar 16 15:17:18 2020, Matej Roguljic, Module assembly, M1601 and M1602 
Andrey and I assembled modules 1601 and 1602 on Friday, 13.3. On Monday, 16.3. I ran reception on them (both graded A) and then glued protection caps on them.
Entry  Mon Mar 16 11:04:41 2020, Matej Roguljic, PhQualification, PhQualification 14.-15.3. 
I ran PhQualification over the weekend with changes pulled from git (described here https://elrond.irb.hr/elog/Layer+1+Replacement/108).

14.3. M1554, M1555, M1556, M1557

First run included software changes, but I forgot to change the vcalhigh in testParameters.dat
The summary can be seen in ~/L1_SW/pxar/ana/T-20/VcalHigh255 (change T-20 to T+10 to see results for +10 degrees)

Second run was with vcalhigh 100.
The summary can be seen in ~/L1_SW/pxar/ana/T-20/Vcal100

15.3. M1558, M1559, M1560

I only ran 3 modules because DTB2 (WRE1O5) or its adapter was not working. Summary is in ~/L1_SW/pxar/ana/T-20/Vcal100





The full data from the tests are in ~/L1_DATA/MXXXX_PhQualification_...
Entry  Mon Mar 16 10:05:23 2020, Matej Roguljic, Software, PhQualification change 
Urs made a change in pXar, in the PhOptimization algorithm. One of the changes is in the testParameters.dat where vcalhigh is set to 100 instead of 255. This was implemented on the PC used to run full qualification. A separate procedure for elComandante was created, "PhQualification.ini", which runs pretest, pixelalive, trimming, ph and gainpedestal. This procedure will need to be run on all the modules qualified before this change was made and later merged with previous full qualification results.
Entry  Sat Mar 14 17:08:14 2020, Matej Roguljic, Full test, Fulltests on 2020/03/13 

Modules tested:
M1591 C (gain at -20)
M1595 B
M1597 B
M1598 B
Entry  Thu Mar 12 17:21:59 2020, Matej Roguljic, Full test, Fulltests on 2020/03/12  
Modules tested:
M1557 C (trim bits at -20)
M1558 C (gain at -20)
M1590 B (still graded C in moreweb because of the previous full qualification, this should be corrected)
M1600 B (still graded C in moreweb because of the previous full qualification, this should be corrected)
Entry  Thu Mar 12 12:19:43 2020, Matej Roguljic, HDI test, 5 HDI tests on 12.3. 
I tested 5 HDIs on 12.3. 1030,1029,1040,1039 and 1038. 1039 failed all the electrical tests. All the others passed the tests. HDI 1038 has one wirebond which is connected to the pad on the HDI and then it extends back up (like this: TBM./\.HDI/). The connection is good, but I just want to check with Silvan later if this is a problem.
Entry  Wed Mar 11 17:59:48 2020, Andrey Starodumov, Re-grading, Regrading C M1542: due to Noise 
Follow the instruction from M1591 regrading log:
"To correct the Summary page one needs to remove rows from DB with C grade from previous data analysis (that for some reason stayed in DB)
using python Controller -d and then run python Controller -m MXXXX"
The Mean noise remains the same but threshold scaled according to the new VCal calibration (44 instead of 50).
To have corrected Mean noise one needs to refit SCurves, means run MoreWeb analysis with -r flag: "Controller -m MXXXX -r"
The modules still graded C due to relative gain spread. It will be re-tested tomorrow with new HP optimization/calibration procedure.
Entry  Wed Mar 11 17:22:57 2020, Matej Roguljic, HDI test, 8 HDI tests on 11.3. 
I tested 8 HDIs today: 5029,5030,5031,6034,6036,6035,1031 and 1032
All of them tested fine.
Entry  Wed Mar 11 17:12:05 2020, Matej Roguljic, HDI test, HDI testing procedure change 
There is an additional test that will be used from 11.03. on all HDIs. It involves measuring the voltage between ground and the HV pin of the needle card with the goal of checking whether proper voltage is delivered to the HDI. The HDI testing script has been updated and it now prompts the user to set the voltage to -800 V, measure the voltage on the pin and write this into the test results. After this, another instruction has been added which tells the user to raise the Z-stage (needle card) before setting voltage to -1100 V. This is done to prevent sparking from the HV pad to the HV pin if the alignment is slightly off.

While measuring the voltage on the HV pin, one should keep in mind the proper settings on the Keithley. When the voltmeter probe is connected to the pin, the current reading on Keithley will go up and if the current readout range is low, it will limit the voltage even before hitting compliance. This was observed during the initial testing of the new procedure. Range should be set to maximum (100 muA) and compliance should be set to 105 muA. This is high enough that it is not reached while measuring voltage at -800 V.
Entry  Wed Mar 11 15:34:57 2020, Urs Langenegger, Other, M1586: issues with MOLEX? 
Module M1586 had passed the full qualification on 20/02/27. I had had to re-insert the cable in the Molex connector for it to become programmable.

On 2020/03/09, I tried to re-test M1586, but it was not programmable. Visual inspection revealed nothing to me. I did re-insert the cable once again, but this time this did not help.

Maybe one should try again re-inserting the cable.

Maybe these issues are an indication that the module (MOLEX) is flaky.
    Reply  Wed Mar 11 16:48:10 2020, Andrey Starodumov, Other, M1586: issues with MOLEX? 

Urs Langenegger wrote:
Module M1586 had passed the full qualification on 20/02/27. I had had to re-insert the cable in the Molex connector for it to become programmable.

On 2020/03/09, I tried to re-test M1586, but it was not programmable. Visual inspection revealed nothing to me. I did re-insert the cable once again, but this time this did not help.

Maybe one should try again re-inserting the cable.

Maybe these issues are an indication that the module (MOLEX) is flaky.


Most likely the cable contacts caused such behavior since they look damaged.
After changing the cable module do not show any more problems.
Entry  Mon Mar 9 16:16:48 2020, Andrey Starodumov, HDI test, HDIs: 3001, 3002, 3003, 3004 and 4033 
Today I tested 5 HDIs: 3001, 3002, 3003, 3004 and 4033
Results:
3001
- electrically OK
- HV OK
- I heard 10+ sparks during 60sec
--> HDI did not pass tests
Danek took it for HV test at his setup

3002-3004, 4033
- all showed different patterns of electrical test failures in Quadrant 0 and 3 (Q0, Q3)
- either all 3 (clock, CTR, SDA) tests fails on Q0 and/or Q3 or some of them or only Ch1 (out of two channels) fails.
--> HDIs did not pass tests
Since patterns were similar the reason could be miss-alignment of contacts. Under microscope in some cases one could see marks outside contact pads.
Conclusion:
we have to re-align the pin head of the jig with respect to HDI and repeat tests of HDIs: 3002-3004 and 4033.
Entry  Tue Mar 3 14:05:13 2020, Andrey Starodumov, Re-grading, Regrading C modules: due to Noise 
It has been realized by Urs that VCal to electron conversion used by MoreWeb is still 50e/VCal.
While recent calibration done by Maren with a few new modules suggest that this conversion is 43.7electrons per 1 VCal (the number from Danek).
I re-run MoreWeb analysis with 44e/Vcal for modules that are graded C for high noise (>300e).

1) Change 50-->44 in
(1) Analyse/AbstractClasses/TestResultEnvironment.py: 'StandardVcal2ElectronConversionFactor':50,
(2) Analyse/Configuration/GradingParameters.cfg:StandardVcal2ElectronConversionFactor = 50
(3) Analyse/Configuration/GradingParameters.cfg.default:StandardVcal2ElectronConversionFactor = 50

2) remove all SCurve_C*.dat files (otherwise new fit results are not written in these files)
3) run python Controller.py -r -m M1591


M1591:
- all three T grade C due to Mean Noise > 300 for ROC0 and/or both ROC0 and ROC1
- after rerun MoreWeb all but one grades are B on individual FT page but in Summary pages grades still C???
- second time at -20C: grade C is due to trimming fails in ROC0: 211 pixels have too large threshold after trimming

Trimming to be checked!!!
    Reply  Wed Mar 4 16:00:05 2020, Andrey Starodumov, Re-grading, Regrading C M1591: due to Noise 

Andrey Starodumov wrote:
It has been realized by Urs that VCal to electron conversion used by MoreWeb is still 50e/VCal.
While recent calibration done by Maren with a few new modules suggest that this conversion is 43.7electrons per 1 VCal (the number from Danek).
I re-run MoreWeb analysis with 44e/Vcal for modules that are graded C for high noise (>300e).

1) Change 50-->44 in
(1) Analyse/AbstractClasses/TestResultEnvironment.py: 'StandardVcal2ElectronConversionFactor':50,
(2) Analyse/Configuration/GradingParameters.cfg:StandardVcal2ElectronConversionFactor = 50
(3) Analyse/Configuration/GradingParameters.cfg.default:StandardVcal2ElectronConversionFactor = 50

2) remove all SCurve_C*.dat files (otherwise new fit results are not written in these files)
3) run python Controller.py -r -m M1591


M1591:
- all three T grade C due to Mean Noise > 300 for ROC0 and/or both ROC0 and ROC1
- after rerun MoreWeb all but one grades are B on individual FT page but in Summary pages grades still C???
- second time at -20C: grade C is due to trimming fails in ROC0: 211 pixels have too large threshold after trimming

Trimming to be checked!!!


To correct the Summary page one needs to remove rows from DB with C grade from previous data analysis (that for some reason stayed in DB)
using python Controller -d and then run python Controller -m MXXXX

To the directory :~/L1_DATA/WebOutput/MoReWeb/FinalResults/REV001/R001/M1591_FullQualification_2020-02-28_08h03m_1582873436/QualificationGroup/ModuleFulltest_m20_2
file grade.txt with a content "2" (corresponds to grade B) has been added. Hence this test grade has been changed from C to B.The reason is that 211 pixels fail trimming (threshold is outside boundary) is a too low trim threshold: VCal=40. From now on 50 will be used.
Entry  Wed Mar 4 11:32:42 2020, danek kotlinski, Full test, change the target trim threshodl to vcal=50 
After some discussion we decided to change the target trimming threshold from vcal 40 to 50.
Many ROCs cannot be run with xrays at 40 while all I have seen until now can be run at 50.
45 might be possible for some rocs but will fail for others.
D.
Entry  Mon Mar 2 17:39:36 2020, Urs Langenegger, Full test, Fulltests on 2020/03/02 
Modules tested:
M1595 C
M1596 B
M1597 C
M1600 C

Andrey and I suspect that these grades are driven by a bad PH optimization.
ELOG V3.1.3-7933898