| ID |
Date |
Author |
Category |
Subject |
|
120
|
Fri Mar 20 17:05:58 2020 |
Andrey Starodumov | Reception test | M1617 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 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?
|
|
119
|
Fri Mar 20 14:53:52 2020 |
Andrey Starodumov | Reception test | M1616 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 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. |
|
118
|
Fri Mar 20 14:46:31 2020 |
Andrey Starodumov | Reception test | M1615 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 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. |
|
297
|
Fri Aug 28 11:13:33 2020 |
Andrey Starodumov | Module grading | M1615 |
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 Starodumov | Module grading | M1613 |
| 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 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. |
|
142
|
Thu Mar 26 10:41:24 2020 |
danek kotlinski | Module grading | M1606 |
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 |
Urs | Module grading | M1606 |
| attached find the threshold difference distributions for all four trimbits for all ROCs |
| Attachment 1: anaTrim-thrDiff-data__M1606__pxar.pdf
|
|
|
258
|
Mon May 11 14:14:05 2020 |
danek kotlinski | Other | M1606 |
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. |
| Attachment 1: m1606_roc2_thr_1d.png
|
|
| Attachment 2: m1606_roc2_thr_2d.png
|
|
| Attachment 3: m1606_roc2_ph70.png
|
|
|
114
|
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 |
|
110
|
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. |
|
299
|
Fri Aug 28 12:02:48 2020 |
Andrey Starodumov | XRay HR tests | M1599 |
| 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 Roguljic | Modules for P | M1595 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 Starodumov | Reception test | M1593 |
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 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. |
|
100
|
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. |
|
246
|
Fri May 1 19:34:01 2020 |
danek kotlinski | Module grading | M1582 |
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. |
| Attachment 1: m1582_roc1_thr.png
|
|
| Attachment 2: m1582_roc1_thr_2d.png
|
|