| ID |
Date |
Author |
Category |
Subject |
|
168
|
Tue Mar 31 18:14:47 2020 |
Andrey Starodumov | HDI test | 3 HDI tested |
| HDIs: 1027, 5002, 5003 are tested. All OK. |
|
167
|
Tue Mar 31 17:36:36 2020 |
Urs Langenegger | Full test | exchanged adapter for DTB_WXC03A |
| Urs Langenegger wrote: | I did not manage to get any r/o from the module connected to that adapter, also after exchanging the module.
So I exchanged the module adapter with the one from the blue box, and all issues with r/o were gone (with both modules)
Of course, the apparently flaky adapter from WXC03A seems to be working again/now in the blue box.
Just fyi. |
Today I have to reconnect a few times modules to the module adapter in the blue box.
It looks like the Molex connector is a bit damaged. One should be very careful while connecting a cable to this Molex connector. |
|
166
|
Tue Mar 31 17:33:37 2020 |
Andrey Starodumov | Reception test | RT of M1546 |
This is a module with a broken TBM. Silvan put a new one on top of the broken TBM.
The module is graded A after reception test.
I'm still not sure that wire-bonds of the new TBM is lower than capacitors. I'll try to glue a cap tomorrow
to see whether we could substitute TBMs on another 6 modules with broken TBMs. |
|
165
|
Tue Mar 31 17:32:47 2020 |
Andrey Starodumov | Reception test | RT of M1641-M1644 |
| All modules graded A. |
|
164
|
Tue Mar 31 10:32:32 2020 |
Urs Langenegger | Full test | M1637 |
Maybe M1637 has an issue: It got stuck twice at the same place with
[09:53:16.043] <TB0> INFO: PixTestReadback::CalibrateIa()
[09:53:16.043] <TB0> INFO: ----------------------------------------------------------------------
[09:53:17.924] <TB0> ERROR: <datapipe.cc/CheckEventID:L486> Channel 6 Event ID mismatch: local ID (22) != TBM ID (23)
[09:53:17.924] <TB0> ERROR: <hal.cc/daqAllEvents:L1701> Channels report mismatching event numbers: 23 22 22 22 22 22 22 22
After that, the DTB is unresponsive and elCommandante loses it. (The printout above is from the second testrun. I had restarted the complete fullqualification after realizing that DTB0 was 'missing' and checking manually that M1637 was properly connected).
I hope elCommandante manages this gracefully. |
|
163
|
Tue Mar 31 09:29:02 2020 |
Urs Langenegger | Full test | exchanged adapter for DTB_WXC03A |
I did not manage to get any r/o from the module connected to that adapter, also after exchanging the module.
So I exchanged the module adapter with the one from the blue box, and all issues with r/o were gone (with both modules)
Of course, the apparently flaky adapter from WXC03A seems to be working again/now in the blue box.
Just fyi. |
|
162
|
Tue Mar 31 08:21:39 2020 |
Andrey Starodumov | Full test | FT of 1558, 1606, 1634, 1636 on Mar 30 |
M1558: B
M1606: C again due to trimmed threshold for 189 pixels of ROC2 at -20C. Second time at -20C and at +10C the number of failed pixels is 90+, hence grading is B.
We could manually upgrade this module to B.
M1634: A
M1636: A |
|
161
|
Tue Mar 31 06:54:12 2020 |
danek kotlinski | Module grading | M1542 |
I have tested M1542.
It looks not bad but there is a group of pixels in the lower/left corner of ROC6 which behave different.
One can also see that something is not right in some PH optimisation plots.
See the attached plot.
We should probably leave this module as grade C+.
D. |
| Attachment 1: Canvas_1.png
|
|
|
160
|
Mon Mar 30 17:49:31 2020 |
Andrey Starodumov | Reception test | RT of M1637-1640 |
All modules: M1637, M1638, M1639, M1649, are graded A.
|
|
159
|
Mon Mar 30 17:40:35 2020 |
Andrey Starodumov | HDI test | 3+2 HDIs (re-)tested |
For 3 HDIs: 3014, 3017, 6021, HV has been re-measured. In all cases 790V is measured with 800V supplied.
2 HDIs: 1026, 5022 were tested. Both OK.
All 5 HDIs will be used in module assembly. |
|
158
|
Mon Mar 30 16:46:59 2020 |
Andrey Starodumov | DB | Sensors missing in Advacam spreadsheet |
Dinko noticed that several sensors are missing in Advacam spreadsheet:
- 381785-03-3 used for M1586
- 381783-02-1 used for M1617
- 381783-03-3 used for M1618
- 350853-16-1 used for M1619
It means that information about about ROCs used for these modules is missing in the Module_Assembly spreadsheet. |
|
157
|
Mon Mar 30 15:40:52 2020 |
Urs | Full test | FT of M1629, M1630, M1631, M1632 |
M1630 is interesting because (I am using my terminology in the following) for the test at T=+10C ROC1 fails the PH optimization test and by consequence the gain/pedestal test is also failed.
The PH optimization test is failed because the minimum pixel on which the test is based is a 'dead' pixel (according to the PixelAlive test), but unfortunately has hits in the initial PH map. As a result the phscale and phoffset for this ROC are not optimal and this is seen in the gain/pedestal fits.
Please find the plots attached from the T=+10 tests. |
| Attachment 1: phval-curve_M1630_p10_C1.pdf
|
|
| Attachment 2: phshot_vcal255.pdf
|
|
| Attachment 3: pixelalive_C1.pdf
|
|
|
156
|
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. |
| Attachment 1: m1630_roc1_ph_fits.png
|
|
|
155
|
Sun Mar 29 18:14:59 2020 |
danek kotlinski | Other | Modules 1544 & 1563 in gelpack |
The 2 bad modules:
M1544
M1563
Have been moved to gelpacks. |
|
154
|
Fri Mar 27 18:29:53 2020 |
Andrey Starodumov | Full test | FT of M1629, M1630, M1631, M1632 |
M1629: B due to mean noise at -20C
M1630: C due to ROC1 with all pixels failed of PH calibration (Gain). Both FT at -20C are A!
Should be understood and retested. Put in C* tray.
M1631: B due to mean noise in all 3 FT
M1632: A |
|
153
|
Fri Mar 27 18:28:34 2020 |
Andrey Starodumov | Full test | 4 HDIs tested |
| HDIs 5020, 5018, 1044 and 1041 are OK |
|
152
|
Fri Mar 27 17:27:09 2020 |
Andrey Starodumov | Reception test | M1635 failed Reception |
All ROCs are programmable but DESER400 trailer error bits: "NO DATA" or "IDLE DATA".
ROC8-11 are affected (no data)
Visual inspection is OK
To module doctor |
|
151
|
Fri Mar 27 16:41:16 2020 |
Andrey Starodumov | Module doctor | Wolfram's summay from Mar 25 |
| Andrey Starodumov wrote: | M1542 nothing on sdata3 (12-15), bad output or wire-bond
M1544 ROC15 timing off, can be made to work (roc 15 vdig 11, ..), but probably not usable for the detector
M1545 full readout, ok, upgraded to C*
M1546 TBM1 output alpha broken (sdata1) => replace TBM1
M1563 ROC 8 thinks he is roc 10 ==> check address wire bond on roc 8?
M1567 roc 11 missing, sdata2 (b-channel)
M1572 sticker says : both TBMs broken, no SDA => replace both TBMs?
M1575 no readout from rocs 0,1 (tbm0b, sdata4), all rocs programmable ==> TODO check CTR roc 0
M1593 tbm0, core B (roc 0-3), no decodable output, core/stack working ok, output beta+ high ~ 2V
M1594 roc 0 dead
M1615 nothing on sdata 3 (12-15), very bad cable (corrosion?) re-running with new cable
M1616 ROC 10 not programmable, no roc headers on sdata2 (b) ==> TODO check clock to roc 10
M1617 readout but no hits in ROC 8, mechanical damage on chip edge
M1621 ROC 8 not programmable, no roc headers or tbm trailers on sdata2a (tbm1b) ==> TODO check clock on ROC 8
M1623 probably no cal-trig-reset to roc 0-3
M1625 definitely not cal-trig-reset to roc 0-3 (CTR- at 0V), damaged when trying to pull wire-bonds |
M1542 is fully OK. It's graded C due to very broad relative Gain distribution of ROC6.
If we will have time it would be useful to take a close look at this module.
It remains graded C. |
|
150
|
Fri Mar 27 14:46:04 2020 |
Andrey Starodumov | Module doctor | Wolfram's summay from Mar 25 |
M1542 nothing on sdata3 (12-15), bad output or wire-bond
M1544 ROC15 timing off, can be made to work (roc 15 vdig 11, ..), but probably not usable for the detector
M1545 full readout, ok, upgraded to C*
M1546 TBM1 output alpha broken (sdata1) => replace TBM1
M1563 ROC 8 thinks he is roc 10 ==> check address wire bond on roc 8?
M1567 roc 11 missing, sdata2 (b-channel)
M1572 sticker says : both TBMs broken, no SDA => replace both TBMs?
M1575 no readout from rocs 0,1 (tbm0b, sdata4), all rocs programmable ==> TODO check CTR roc 0
M1593 tbm0, core B (roc 0-3), no decodable output, core/stack working ok, output beta+ high ~ 2V
M1594 roc 0 dead
M1615 nothing on sdata 3 (12-15), very bad cable (corrosion?) re-running with new cable
M1616 ROC 10 not programmable, no roc headers on sdata2 (b) ==> TODO check clock to roc 10
M1617 readout but no hits in ROC 8, mechanical damage on chip edge
M1621 ROC 8 not programmable, no roc headers or tbm trailers on sdata2a (tbm1b) ==> TODO check clock on ROC 8
M1623 probably no cal-trig-reset to roc 0-3
M1625 definitely not cal-trig-reset to roc 0-3 (CTR- at 0V), damaged when trying to pull wire-bonds |
|
149
|
Fri Mar 27 14:32:11 2020 |
Andrey Starodumov | HDI test | List of suspicious HDIs |
Here are HDIs that the first time tested showed 500-600V measured on the pin or directly on the HDI pad instead of 800V:
5006, 5007, 2005
3014, 3017, 3019, 6021
I put them in the box called "For Wolfram ...." on the Wolfram's desk in the lab.
Nevertheless, I think this is an artificial issue that mmight be caused by a cable. I retested 5006, 5007 and 2005 with a new
cable and in all cases measured HV=790V what is normal. |