| ID |
Date |
Author |
Category |
Subject |
|
148
|
Fri Mar 27 14:28:14 2020 |
Andrey Starodumov | Reception test | M1633 failed Reception |
All ROCs are programmable but permanent DESERALISER ERROR, Ch6 and Ch7 event ID mismatch.
Visual inspection is OK
To module doctor |
|
147
|
Fri Mar 27 10:54:04 2020 |
Urs Langenegger | Full test | Issues with pc11366 on March 27 |
On March 27 I had a lot of troubles getting the full qualification up
and running.
The problems were (1) strange error messages from pxar core, (2)
problems with USB connections to the DTBs, (3) loads of (intermittent)
data transmission errors from the DTBs, and (4) complaints about missing
(system) libs.
In the end I did killall firefox and (out of superstition) pkill compiz.
Then it worked again. |
|
146
|
Thu Mar 26 17:45:15 2020 |
Andrey Starodumov | Full test | FT of M1545, M1557, M1627, M1628 |
Retested M1545: C->B (to be correct on the MoreWeb summary page)
Retested 1557: C->C in one ROC >160 pixels failed to be trimmed Module placed in a tray C*
1627: B
1628: B
All B grades due to high (>200electons) mean noise. |
|
145
|
Thu Mar 26 17:43:06 2020 |
Andrey Starodumov | HDI test | 6+1 HDI tested |
HDIs: 6021, 3014, 2005, 2009, 2006 and 2010 are OK
HDI 6024 failed: SDA0 and SDA2 on Ch1 missing
Looks like lower than 800V measured effect relates to the cable.
After cable has been changed all measurements 790V |
|
144
|
Thu Mar 26 17:41:52 2020 |
Andrey Starodumov | Reception test | RT of M1629-1632 |
| All modules M1629, M1630, M1631 and M1632 graded A |
|
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
|
|
|
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 *). |
|
141
|
Wed Mar 25 20:17:16 2020 |
danek kotlinski | Module doctor | The list of modules tested today by Wolfram |
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?
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
M1575 no readout from rocs 0,1 (tbm0b, sdata4), all rocs programmable ==> TODO check CTR roc 0 |
|
140
|
Wed Mar 25 18:40:53 2020 |
Andrey Starodumov | Full test | FT of M1599, M1613, M1624, M1616 |
M1599: B due to leakage current at +10 (2-3umA)
M1613: B due to a few pixels with bad trimmed threshold
M1624: B due to a few ROCs with mean noise>200electrons
M1626: A |
|
139
|
Wed Mar 25 18:31:46 2020 |
Andrey Starodumov | Re-grading | Reanalised test results |
| Andrey Starodumov wrote: | Test resulsts of several modules have been re-analised without grading on trimbit failure.
M1614: C->B
M1613: C->A
M1609: C->B
M1618: B->A
M1612: B->B
M1610: B->B
M1608: C->B
M1606: C->C (too many badly trimmed pixels)
M1605: C->B
Most of all B grading and one C are due to badly trimmed pixels. The threshold after trimming usually has 3(!) separated peaks.
We should understand this feature. |
More modules have been re-analysed:
1604: C->B
1603: C->B
1602: C->B
1601: B->A
1545: C->C (too many pixels on ROC14 are badly trimmed, to be retested tomorrow) |
|
138
|
Wed Mar 25 18:30:23 2020 |
Andrey Starodumov | HDI test | 4+2 HDI tested |
2 suspicious HDIs retested and found OK: 5006/5007
5013, 5016, 3017, 3019 are OK. |
|
137
|
Wed Mar 25 17:03:11 2020 |
Andrey Starodumov | Full test | FT of M1615, M1619, M1620, M1622 |
| Andrey Starodumov wrote: | Test results have been analysed with modified code:
M1615: B
M1619: A
M1620: B
M1622: B
One pixel of M1615 still failed mask test but it was not taken in to account in the final grading???
I put it in the shelves for Module doctor. To be decided what to do with this module. |
For Wolfram one channel of M1615 does not work. He noticed that the cable has corrosion (probably this cable has been attached to a module that has been irradiated in Zagreb). After Reception test this module again graded C due to a mask test failure of one pixel in one ROC.
Wolfram proposed to grade this module as C*.
|
|
136
|
Wed Mar 25 14:44:37 2020 |
Andrey Starodumov | Reception test | RT of M1627 and M1628 |
| Both modules graded A. |
|
135
|
Wed Mar 25 14:42:55 2020 |
danek kotlinski | Module transfer | modules 1545 & 1542 back from ETH |
| M1545 & M1542 were returned from ETH to PSI for further testing. |
|
134
|
Wed Mar 25 14:17:51 2020 |
Andrey Starodumov | Full test | FT of M1609, M1613, M1614, M1618 on Mar 23 |
FT for these modules has been done on Mar 23
M1609: C
M1613: C
M1614: C
M1618: B
All C due to trim bit test failures |
|
133
|
Wed Mar 25 14:11:35 2020 |
Andrey Starodumov | Reception test | RT of M1613 and M1614 on Mar 20 |
Reception test for these modules have been done on Mar20.
Grading A for both modules. |
|
132
|
Tue Mar 24 18:11:52 2020 |
Andrey Starodumov | Re-grading | Reanalised test results |
Test resulsts of several modules have been re-analised without grading on trimbit failure.
M1614: C->B
M1613: C->A
M1609: C->B
M1618: B->A
M1612: B->B
M1610: B->B
M1608: C->B
M1606: C->C (too many badly trimmed pixels)
M1605: C->B
Most of all B gradings and one C are due to badly trimmed pixels. The threshold after trimming usually has 3(!) separated peaks.
We should understand this feature. |
|
131
|
Tue Mar 24 18:09:07 2020 |
Andrey Starodumov | Full test | FT of M1615, M1619, M1620, M1622 |
Test results have been analysed with modified code:
M1615: B
M1619: A
M1620: B
M1622: B
One pixel of M1615 still failed mask test but it was not taken in to account in the final grading???
I put it in the shelves for Module doctor. To be decided what to do with this module. |
|
130
|
Tue Mar 24 16:08:58 2020 |
Andrey Starodumov | Reception test | M1625 failed Reception |
M1625: all ROCs are programmable but no readout from ROC0-ROC3.
The same symptom as for M1623.
Visual inspection is OK.
To module doctor. |
|
129
|
Tue Mar 24 15:41:29 2020 |
Andrey Starodumov | Module grading | Change in MoreWeb GradingParameters.cfg |
On March 3d the Vcal calibration parameter has been changed:
- StandardVcal2ElectronConversionFactor from 50 to 44 (electrons/VCal)
Om March 24 the following changes done:
- trimThr from 35 to 50 (to synchronize with current target trimming threshold of Vcal=50)
- TrimBitDifference from 2. to -2. This means that difference between trimmed and untrimmed
threshold close to 0 (<2 as it was) will be ignored. |