CMS Pixel Detector Miscellaneous
Phase 1 Phase 2
Layer 1 Replacement Layers 2-4
  Layer 1 Replacement Elog, Page 7 of 16  Not logged in ELOG logo
ID Date Author Category Subjectdown
  120   Fri Mar 20 17:05:58 2020 Andrey StarodumovReception testM1617 failed
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.
  123   Sun Mar 22 13:57:25 2020 Danek KotlinskiReception testM1617 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?
  119   Fri Mar 20 14:53:52 2020 Andrey StarodumovReception testM1616 failed
ROC10 of M1616 is not programmable, no readout from ROC10 and ROC11.
Visual inspection of wire bonds - OK
To module doctor!
  124   Sun Mar 22 14:02:20 2020 Danek KotlinskiReception testM1616 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.
  118   Fri Mar 20 14:46:31 2020 Andrey StarodumovReception testM1615 failed
M1615 is programmable but "no working phases found"
Visual inspection of wire bonds - OK.
To module doctor!
  125   Sun Mar 22 14:05:20 2020 Danek KotlinskiReception testM1615 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.
  297   Fri Aug 28 11:13:33 2020 Andrey StarodumovModule gradingM1615
M1615: one pixel in ROC10 unmaskable hence should be graded C. Otherwise the module is of grade A
To be checked!
  285   Fri Jun 5 13:47:11 2020 Andrey StarodumovModule gradingM1613
FT of this modules has been done twice: March 23 and March 25, in both cases with the final test SW. On March 23 module was graded C due to many trim bit failures. That is why it was retested. But after failure in trimbits were excluded from the grading, FT of Mar 23 looks better then later FT of Mar25. That is why FT of Mar 23 is kept.
  116   Thu Mar 19 17:17:27 2020 Andrey StarodumovReception testM1609-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.
  142   Thu Mar 26 10:41:24 2020 danek kotlinskiModule gradingM1606
I have looked more closely at M1606.
Trimming show problems in ROC2, 8 pixels have 0 threshold and for 61 pixels thr=-1.
Strange because from Scurves the 61 have a high ~62 threshold but no failure.
The PixelAlive and PH is OK for these 61 pixels, the 8 are just completely dead.
Trimbit test shows that 61 pixels failing.
So maybe this is the first time we see a real trimbit failure!

I suggest to grate this module C+( or *).
  143   Thu Mar 26 15:37:18 2020 UrsModule gradingM1606
attached find the threshold difference distributions for all four trimbits for all ROCs
  258   Mon May 11 14:14:05 2020 danek kotlinskiOtherM1606
On Friday I have tested M1606 at room temperature in the red cold box.
Previously it was reported that trimming does not work for ROC2.

In this test trimming was fine, only 11 pixels failed it.
See the attached 1D and 2D histograms. There is small side peak at about vcal=56 with ~100 pixels.
But this should not be a too big problem?

Also the Pulse height map looks good and the reconstructed pulse height at vcal=70
gives vcal=68.1 with rms=4.2, see the attached plot.

So I conclude that this module is fine.
  114   Wed Mar 18 17:43:41 2020 Andrey StarodumovModule assemblyM1605-M1608
M1605 and M1606: reception done on Mar 17
M1607 and M1608: reception done today
All: grade A

Caps glued to M1605-M1608
  110   Mon Mar 16 15:17:18 2020 Matej RoguljicModule assemblyM1601 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.
  299   Fri Aug 28 12:02:48 2020 Andrey StarodumovXRay HR testsM1599
ROC5 has eff=93.65% and should be graded C. Somehow efficiency was not taken into account for HR test grading???
  301   Wed Sep 2 16:09:24 2020 Matej RoguljicModules for PM1595 switch with M1558
Module 1595 was foreseen to go on the inner ladder 5, position -2 (negative two). During the pre-installation test, we saw it had a high leakage current, ~8 microAmps at room temperature. Therefore, we decided to place module 1558 in its place instead of it.
  186   Mon Apr 6 14:27:31 2020 Andrey StarodumovReception testM1593
Silvan has substituted the TBM0 of M1593.
I had to substitute a cable that has residuals and with which the Reception test failed completely.
The long cable has been attached.
Reception test grade: A
  99   Wed Mar 11 15:34:57 2020 Urs LangeneggerOtherM1586: 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.
  100   Wed Mar 11 16:48:10 2020 Andrey StarodumovOtherM1586: 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.
  246   Fri May 1 19:34:01 2020 danek kotlinskiModule gradingM1582
M1582 was classified as C because of 167 pixels failing trimming in ROC1.
I have tested this module.
The attached plots show the 1d & 2d threshold distributions.
The average threshold is 49.98 with rms=1.39 there is 1 pixel failing (at 0) and 1 pixel with a very low threshold of 37.
I think this ROC is OK, actually it is very nice.
D.
ELOG V3.1.3-7933898