 Fri Jul 10 11:24:37 2020, Urs Langenegger, Reception test, proc600V3 modules
|
This week I tested 12 modules built with proc600v3. The module numbers are M1722 - M1733.
The results are summarized at the usual place:
http://cms.web.psi.ch/L1Replacement/WebOutput/MoReWeb/Overview/Overview.html
Cheers,
--U. |
|
Thu Sep 26 15:51:30 2019, Dinko Ferencek, Software, pXar code updated
|
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, Dinko Ferencek, Software, pXar code updated
|
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, Software, pXar code updated
|
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, Dinko Ferencek, Software, pXar code updated
|
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, new modules M1533 and M1534
|
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. |
|
Fri Aug 14 13:47:26 2020, Andrey Starodumov, General, new PH optimisation test and Total Overview
|
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. |
|
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 |
|
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. |
|
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
|
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
Mon May 25 16:58:23 2020, Andrey Starodumov, 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, Software, 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". |
|
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 |
|
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 |
|
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. |