| ID |
Date |
Author |
Category |
Subject |
|
92
|
Thu Feb 27 10:14:09 2020 |
danek kotlinski | Module transfer | M1562 to DESY |
M1562 was not qualified during a full test since the test did not complete.
Looking at the module I see that roc 2 has a lot of noise row 79.
I tried to mask all pixels in this row but the masking does not work.
With this feature one can run pixel alive but trimming fails completely for roc 2.
The only way to trim the module is to disable the whole roc 2.
Since it seems to me that we will never want to use this module in the detector
I have given it to Jory to be used in the DESY test beam.
She already has 2-3 module from the pre-production, so with older versions of HDIs & ROCs.
I have also looked at 2 other modules which were classified as C 1557 and 1558.
Both look fine to me but I have not run the PH optimization on them.
D. |
|
96
|
Wed Mar 4 11:32:42 2020 |
danek kotlinski | Full test | change the target trim threshodl to vcal=50 |
After some discussion we decided to change the target trimming threshold from vcal 40 to 50.
Many ROCs cannot be run with xrays at 40 while all I have seen until now can be run at 50.
45 might be possible for some rocs but will fail for others.
D. |
|
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. |
|
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 |
|
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 *). |
|
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. |
|
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
|
|
|
202
|
Thu Apr 9 14:19:40 2020 |
danek kotlinski | Module transfer | Modules moved to gel-pack |
The following good module class A/B have been moved to gel-packs:
1607, 1608, 1609, 1610, 1612, 1613, 1614, 1618, 1619, 1620, 1622, 1624, 1626, 1627, 1628.
The following bad module, not-working and C class have been moved to gel-packs:
1544, 1563, 1567, 1675, 1593, 1594, 1611, 1615, 1616, 1617, 1621, 1625, 1646, 1650, 1652 |
|
205
|
Thu Apr 9 16:13:51 2020 |
danek kotlinski | Module transfer | Modules moved to gel-pack |
| danek kotlinski wrote: | The following good module class A/B have been moved to gel-packs:
1607, 1608, 1609, 1610, 1612, 1613, 1614, 1618, 1619, 1620, 1622, 1624, 1626, 1627, 1628.
The following bad module, not-working and C class have been moved to gel-packs:
1544, 1563, 1567, 1675, 1593, 1594, 1611, 1615, 1616, 1617, 1621, 1625, 1646, 1650, 1652 |
A few corrections to the list of bad modules:
- On April 7 M1593 has been (F)-tested with a grade B due to Rel.gain width and mean noise of a few ROCs.
- 1611 should be C* since ROC13 has not working double column (160pixels) + 27 trimbit failures but very good trimmed threshold distribution, so these 27 trimbit failures should be ignored. |
|
213
|
Wed Apr 15 08:48:09 2020 |
danek kotlinski | Module doctor | Wolfram's tests from 14/4/20 |
two of are fixed and can be re-tested
M1623 tbm bond
M1657 bond roc 15
the others need further investigation, maybe a new tbm, maybe closer wire-bond inspection
M1633 roc 0-3 programmable, but no readout, unclear
M1635 roc 12-15 programmable, but no readout (except for roc 12), no token passed
M1653 roc 12-15 not programmable, otherwise ok, sda? tbm?
M1671 some problem with roc 14/15, unclear |
|
214
|
Wed Apr 15 17:14:42 2020 |
danek kotlinski | Module transfer | move 4 modules to gel-packs |
Moved to gel-apcks:
1629 B
1631 B
1660 C
1665 classifed as B in MoreWeb but has 170 pixel failures |
|
216
|
Wed Apr 15 17:33:53 2020 |
danek kotlinski | Module transfer | move 4 modules to gel-packs |
| danek kotlinski wrote: | Moved to gel-apcks:
1629 B
1631 B
1660 C
1665 classifed as B in MoreWeb but has 170 pixel failures |
M1665 is graded B since there is no a single ROC with >4% of damaged pixels (max 120 in ROC5). 170 pixel failures are totally in the module. |
|
242
|
Thu Apr 30 15:38:43 2020 |
danek kotlinski | Module transfer | M1635 & M1671 transferred to gel-pack |
| Two bad modules have been placed in gel-packs: 1635 & 1671. |
|
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
|
|
|
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
|
|
|
259
|
Mon May 11 14:40:16 2020 |
danek kotlinski | Other | M1582 |
On Friday I have tested the module M1582 at room temperature in the blue box.
The report in MoreWeb says that this module has problems with trimming 190 pixels in ROC1.
I see not problem in ROC1. The average threshold is 50 with rms=1.37. Only 1 pixel is in the 0 bin.
See the attached 1d and 2d plots.
Also the PH looks good. The vcal 70 PH map is reconstructed at vcal 70.3 with rms of 3.9.
5159 pixels have valid gain calibrations.
I conclude that this module is fine.
Maybe it is again a DTB problem, as reported by Andrey.
D. |
| Attachment 1: m1582_roc1_thr_1d.png
|
|
| Attachment 2: m1582_roc1_thr_2d.png
|
|
| Attachment 3: m1582_roc1_ph70.png
|
|
|
287
|
Tue Jun 9 17:19:00 2020 |
danek kotlinski | Module transfer | gel-pack transfers |
The following modules, which were already X-ray tested and came back from ETHZ,
have been transferred to gel_packs:
1623
1630
1632
1634
1636
1637
1639
1640
The following "good" modules have been transferred from gel-packs to frames,
they still have to go to ETHZ for X-ray testing:
1620
1622
1624
1626
1627
1628
1629
1631
D. |
|
290
|
Tue Jun 16 19:23:37 2020 |
danek kotlinski | Module transfer | modules from and to ETH, list 3 |
The 27 modules from list 2 have been transferred back to PSI.
The following 18 modules have been transferred to ETH:
1605
1606
1607
1608
1609
1610
1612
1614
1615
1613
1618
1619
1629
1622
1624
1626
1627
1628
|
|
291
|
Thu Jun 18 20:04:41 2020 |
danek kotlinski | Module transfer | Modules to ETH, transport #6 |
Today Lea has delivered another group of 18 modules to the ETH:
1604
1603
1602
1601
1600
1599
1598
1597
1596
1629
1631
1641
1642
1643
1644
1645
1647
1648
No modules were brought back, so there are now 18+18=36 modules at ETH. |
|
292
|
Thu Jul 2 13:48:20 2020 |
danek kotlinski | Module transfer | Transport #7 to ETH |
Lea brought the last batch of 8 modules to ETH:
1542
1593
1665
1672
1673
1674
1675
1676 |