 Mon Jan 25 13:03:22 2021, Dinko Ferencek, POS, POS configuration files created
|
The output POS configuration files has '_Bpix_' instead of '_BPix_' in their names. The culprit was identified to be the C3 cell in the 'POS' sheet of Module_bookkeeping-L1_2020 Google spreadsheet which contained 'Bpix' instead of 'BPix' which was messing up the file names. This has been fixed now and the configuration files regenerated.
The WBC values were also changed to 164 for all modules using the following commands
cd /home/l_tester/L1_SW/pxar2POS/
./pxar2POS.py --do "dac:set:WBC:164" -o /home/l_tester/L1_DATA/POS_files/Configuration_files/ -i 1
This created a new set of configuration files with ID 2 in /home/l_tester/L1_DATA/POS_files/Configuration_files/.
The WBC values stored in ID 1 were taken from the pXar dacParameters*_C*.dat files and the above procedure makes a copy of the ID 1 files and overwrites the WBC values. |
|
Sun Mar 22 13:57:25 2020, Danek Kotlinski, Reception test, M1617 failed
|
| Andrey Starodumov wrote: | ROC8 of M1617 is programmable but no readout from it.
Silvan noticed that a corner of one ROC of this module is broken,
this is exactly ROC8. |
Interesting that the phase finding works fine, the width of the valid region is 4, so quite
good. ROC8 idneed does not give any hits but the token passed through it, so the overall
readout works fine. There re no readout errors.
The crack on the corner of this ROC is clearly visible.
I wonder how this module passed the tests in Helsinki?
|
|
Sun Mar 22 14:02:20 2020, Danek Kotlinski, Reception test, M1616 failed
|
| Andrey Starodumov wrote: | ROC10 of M1616 is not programmable, no readout from ROC10 and ROC11.
Visual inspection of wire bonds - OK
To module doctor! |
For me ROC10 is programmable.
It looks like there is not token pass through ROC11.
This affects the readout of ROCs 11 & 10.
Findphases fails because of the missing ROC10&11 readout. |
|
Sun Mar 22 14:05:20 2020, Danek Kotlinski, Reception test, M1615 failed
|
| Andrey Starodumov wrote: | M1615 is programmable but "no working phases found"
Visual inspection of wire bonds - OK.
To module doctor! |
For me this module is working fine.
I could run phasefinding and obtained a perfect PixelAlive.
I left this module connected in the blue-box in order to run more advanced tests from home. |
Mon Mar 30 14:52:59 2020, Danek Kotlinski, Full test, FT of M1629, M1630, M1631, M1632 
|
I have tested M1630.
I see not problem with ROC1. See the attached plot.
There is one dcol in ROC12 which shoes the "pattern" problem seen in a few other ROCs.
I think this module is fine, should be B. Could be retested. |
 Mon Feb 3 11:28:38 2020, Anrey Starodumov, Full test, 4 modules FT: 1536, 1537,1538, 1540
|
Jan 28: Reception test for 1536, 1537, 1538 OK
Then cap gluing
Jan 29
- Reception test for 1540 OK
- FT:
-- 1536: B/B/B (-20/-20/+10). Electrical Test is B due to mean noise >200e. IV: 3umA for -20 and +10, slope >300
-- 1537: C/B/B. First -20 is C due ROC10 >200 TrimBits failure, noise >200e. IV: A
-- Trimbit test fails but Trimbit distribution is OK and Threshold reasonable (attachment)
==> Manually regraded to B
-- 1538: B/B/B (-20/-20/+10). Electrical Test is B due to mean noise >200e. IV: <0.2umA for +10, slope ~1
-- 1540: B/B/B (-20/-20/+10). Electrical Test is B due to mean noise >200e. IV: <0.8umA for +10, slope ~2.7 |
|
Mon Feb 3 15:35:09 2020, Anrey Starodumov, Full test, 4 modules FT: 1539, 1541,1542, 1543
|
Jan 29
- Reception test for 1539 OK
- Cap gluing
Jan 30
- Reception test for 1541, 1542, 1543 OK
- Cap gluing
- FT:
-- 1539: C/B/B. First -20 is C due to INCOMPLETE TEST: DTB stuck
==> Must be retested at -20C and then files merging
-- 1541: C/C/C. Electrical Test is C due to Trimbit test failure in ROC13. Threshold is reasonable (see attachment)
==> Manually regraded to B
-- 1542: C/C/C. Electrical Test is C due to RelGain of 0.200 instead of <0.1 (too wide Gain distribution).
-- 1543: B/B/B (-20/-20/+10). Electrical Test is B due to mean noise >200e. |
|
Fri Sep 13 15:06:51 2019, Andrey Starodumov, Other, Modules 1504, 1505, 1520 irradiation report
|
It was discovered that these modules were stored in Zagreb in the climatic lab where T was about +22C. These modules have been transported from Co60 irradiation facility to the lab on open air with T>30C and RH>70%. Water in the air under the cap condensated on the surface of HDIs and diluted residuals (from soldering, passivation etc), that after remains liquid or crystallised.
The irradiation itself does not course any damage. This is also confirmed by the fact that after two previous irradiations in Jan and Jul 2019 of modules and HDIs, samples remained in a good shape without any residuals on HSI surfaces. These samples have been kept in an office where T and RH were similar to the outside and not in the climatic lab.
We consider the the case is understood and closed. |
|
Mon Dec 2 17:29:06 2019, Andrey Starodumov, Full test, 4 modules FT
|
FullQualification of four modules M1526, M1529, M1521 and M1534 has been done. Full time of the test is about 5.5hrs.
Test included: FT@-20C, IV@-20, 3Cycles from -20C up to +10C, FT@10C and IV@10C.
Only M1521 passed the test (Grade B). Several issues observed in other modules:
1) 2-6 ROCs with TrimBit test failure for many pixels
2) Trimming id bad for some ROCs
3) test at +10C often better than at -20C
4) some ROCs hav issues with Thr and Gain distributions (out of specifications)
To be understood before the mass production! |
|
Tue Dec 3 12:15:54 2019, Andrey Starodumov, Full test, 4 modules FT
|
| Andrey Starodumov wrote: | FullQualification of four modules M1526, M1529, M1521 and M1534 has been done. Full time of the test is about 5.5hrs.
Test included: FT@-20C, IV@-20, 3Cycles from -20C up to +10C, FT@10C and IV@10C.
Only M1521 passed the test (Grade B). Several issues observed in other modules:
1) 2-6 ROCs with TrimBit test failure for many pixels
2) Trimming id bad for some ROCs
3) test at +10C often better than at -20C
4) some ROCs have issues with Thr and Gain distributions (out of specifications)
To be understood before the mass production! |
We have run with Urs TrimBit test for M1526 at room T (without turning ON coldbox)
and results are confirmed yesterday observations of TrimBit test failure of several ROCs.
Urs will take a look and try to understand the issue.
To illustrate the problem below two summary tables of M1526 at -20C and +10C are shown. |
|
Mon Feb 3 15:53:32 2020, Andrey Starodumov, Reception test, 5 modules RT: 1545, 1547, 1548, 1549, 1550
|
Feb 03
- RT is done and OK for all modules. All 5 modules graded A. |
|
Mon Feb 3 17:09:36 2020, Andrey Starodumov, Reception test, 2 modules RT failed: 1544, 1546
|
Feb 03
- RT failed
-- 1544:
--- all ROCs are programmable
--- ROC14 no reliable Threshold found, ROC15 no threshold at all
-- 1546
--- all ROCs are programmable
--- no threshold found for all ROCs |
|
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!!! |
|
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. |
|
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. |
|
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. |
|
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. |
|
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.
|
|
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.
|
|
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 |