ELOG Layer 1 Replacement

pXar code in /home/l_tester/L1_SW/pxar/ on the lab PC was updated yesterday from https://github.com/psi46/pxar/tree/15b956255afb6590931763fd07ed454fb9837fc0 to the latest version https://github.com/psi46/pxar/tree/e17df08c7bbeb8472e8f56ccd2b9d69a113ccdc3 which among other things contains updated DAC settings for ROCs.

All the configs will have to be regenerated before the start of the module qualification.

Wed Nov 27 18:25:08 2019

pXar code in /home/l_tester/L1_SW/pxar/ on the lab PC was updated on Monday, Nov. 25 from https://github.com/psi46/pxar/tree/e17df08c7bbeb8472e8f56ccd2b9d69a113ccdc3 to https://github.com/psi46/pxar/tree/9c3b81791738e1b8ec7dd9f0d1b68f8800f8416c which pulled in the latest updates to the pulse height optimization test. Today a few remaining updates were pulled in by going to the current HEAD of the master branch https://github.com/psi46/pxar/tree/5d358c5ebbf095a7d118cdde9e1e509c41ccc615.

The sequence of commands to update the code was the following:

cd /home/l_tester/L1_SW/pxar/
git pull origin master
cd build
cmake ..
make -j6 install

Thu Nov 28 18:34:00 2019

Dinko Ferencek wrote:

cd /home/l_tester/L1_SW/pxar/
git pull origin master
cd build
cmake ..
make -j6 install

pXar code updated to the current HEAD of the master branch https://github.com/psi46/pxar/tree/9eb0f3844e9c7f98d7701629c5af339632c5d84a to pick up the latest update that allows running of the fullTest() method of each of the tests from the command line and consequently also from elComandante.

Mon Jan 20 13:47:33 2020

new modules M1533 and M1534

Dinko Ferencek wrote:

cd /home/l_tester/L1_SW/pxar/
git pull origin master
cd build
cmake ..
make -j6 install

pXar code updated to the current HEAD of the master branch https://github.com/psi46/pxar/tree/f6e42c17c0bb3a44bdb3fa13d8f8afb6cae62a81 to pick up the latest PH optimization updates.

Tue Nov 19 14:10:10 2019

Andrey

Cold box tests

Yesterday Silvan wire bonded two new modules M1533 and M1534 that are both grade C due to high leakage current and a few ROCs with large number of defective bump bonds.
Today I run Reception1st test with IV at +10C for both modules and above features are confirmed.
The IV curves present on a MoreWeb webpage but the values of a leakage current in the table under the curve is 0A (?). May be it relates to the fact that it should be current at -150V shown,
while the voltage scan stops at -130V since one of the modules draw 98umA current at this voltage. If it so, the MoreWeb script should be corrected: the current taken at -150V or if voltage
is lower then it is taken at the last (highest) value.
Tomorrow a FullQualification will be run on both modules.

296

Fri Aug 14 13:47:26 2020

new PH optimisation test and Total Overview

General

New PH optimisation is done at -20C as a FT, hence the results of this test are added to "DB" file as the second m20_1 test.
If there are more than one result per test in the DB file the total production overview is corrupted in a way that for such
modules # of defects is not calculated (due to ambiguity) and hence these modules are not rank according to the number of defects.
To correct this one has to remove from the DB file the second row with the same test. In our case one needs to remove the "old" m20_1 test.
While doing this I noticed that some new FT ended with grade C while the previous ones were fine (graded B) or some subtests are failed
wile grading remains B. Here is the list of such modules:
M1546 graded C
M1556 graded B but trimming completely failed (DTB_WRE1O5): TO RE-TEST
M1624 graded B but instead if 79 pixel defects it has 295 in 3 chips due to trimming problem (DTB_WRE1O5): TO RE-TEST
M1600 graded B but instead of ~50 pixel defects it has about 300 due to trimming problems (DTB_WXC03A): to retest

In general latest FT at -20C has shows less defective pixels and bumps but often leakage current is slightly higher.

214

Wed Apr 15 17:14:42 2020

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

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.

290

Tue Jun 16 19:23:37 2020

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

135

Wed Mar 25 14:42:55 2020

modules 1545 & 1542 back from ETH

M1545 & M1542 were returned from ETH to PSI for further testing.

287

Tue Jun 9 17:19:00 2020

exchanged adapter for DTB_WXC03A

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.

163

Tue Mar 31 09:29:02 2020

Urs Langenegger

Full test

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.

167

Tue Mar 31 17:36:36 2020

Urs Langenegger

Full test

exchanged adapter for DTB_WXC03A

Urs Langenegger wrote:

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.

Wed Mar 4 11:32:42 2020

change the target trim threshodl to vcal=50

Full test

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.

272

Mon May 25 16:58:23 2020

XRay HR tests

a few commments

These is just to record the information:
1. measured hit rates at which Efficiency and Xray hits Maps are taken are 40-50% of the 50-400MHz/cm2 that in the titles of corresponding plots
2. in 2016 the maximum rate was 400MHz/cm2 but with such rate (or better corresponding settings of HV and current of Xray tube) in double columns of certain modules (likely depending on a module position with respect to Xray beam spot) the measured rate was smaller than 300MHz/cm2 that is target rate. Somtimes extrapolation of efficiency curve to 300MHz/cm2 is too large. I think this is not correct. Unfortunately higher rates cause too many readout errors that prevent a proper measurement of the hit efficiency. May be a new DTB with than 1.2A maximum digital current will help.
3.

Tue Aug 6 16:01:17 2019

Matej Roguljic

Wrong dac settings - elComandante

If it seems that elComandante is taking wrong dac settings for tests like Reception test or full qualification, one should remember that it does NOT read values from module specific folders like "M1523", but rather from tbm-specific folders like "tbm10d". The folders from which the dacs are taken are listed in "elComandante.config", the lines which look like "tbm10d:tbm10d".

213

Wed Apr 15 08:48:09 2020

Wolfram's tests from 14/4/20

Module doctor

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

150

Fri Mar 27 14:46:04 2020

Wolfram's summay from Mar 25

Module doctor

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

151

Fri Mar 27 16:41:16 2020