CMS Pixel Detector Miscellaneous
Phase 1 Phase 2
Layer 1 Replacement Layers 2-4
  Layer 1 Replacement Elog, all entries  Not logged in ELOG logo
 Find |  Login |  Help 
 Full | Summary | Threaded | Collapse | Expand  Show only new entries   Error: Attribute "Type" for quick filter not found  303 Entries 
Goto page 1, 2, 3 ... 14, 15, 16  
Entry  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
Entry  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 [URL=https://github.com/psi46/pxar/tree/15b956255afb6590931763fd07ed454fb9837fc0]https://github.com/psi46/pxar/tree/15b956255afb6590931763fd07ed454fb9837fc0[/URL]
to the latest version [URL=https://github.com/psi46/pxar/tree/e17df08c7bbeb8472e8f56ccd2b9d69a113ccdc3]https://github.com/psi46/pxar/tree/e17df08c7bbeb8472e8f56ccd2b9d69a113ccdc3[/URL]
which among other things contains updated DAC settings for ROCs.
Entry  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 [URL=https://github.com/psi46/pxar/tree/e17df08c7bbeb8472e8f56ccd2b9d69a113ccdc3]https://github.com/psi46/pxar/tree/e17df08c7bbeb8472e8f56ccd2b9d69a113ccdc3[/URL]
to [URL=https://github.com/psi46/pxar/tree/9c3b81791738e1b8ec7dd9f0d1b68f8800f8416c]https://github.com/psi46/pxar/tree/9c3b81791738e1b8ec7dd9f0d1b68f8800f8416c[/URL]
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
    Reply  Thu Nov 28 18:34:00 2019, Dinko Ferencek, Software, pXar code updated 
[quote="Dinko Ferencek"]pXar code in /home/l_tester/L1_SW/pxar/ on the lab PC was updated on Monday, Nov. 25 from [URL=https://github.com/psi46/pxar/tree/e17df08c7bbeb8472e8f56ccd2b9d69a113ccdc3]https://github.com/psi46/pxar/tree/e17df08c7bbeb8472e8f56ccd2b9d69a113ccdc3[/URL]
to [URL=https://github.com/psi46/pxar/tree/9c3b81791738e1b8ec7dd9f0d1b68f8800f8416c]https://github.com/psi46/pxar/tree/9c3b81791738e1b8ec7dd9f0d1b68f8800f8416c[/URL]
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
    Reply  Mon Jan 20 13:47:33 2020, Dinko Ferencek, Software, pXar code updated 
[quote="Dinko Ferencek"][quote="Dinko Ferencek"]pXar code in /home/l_tester/L1_SW/pxar/ on the lab PC was updated on Monday, Nov. 25 from [URL=https://github.com/psi46/pxar/tree/e17df08c7bbeb8472e8f56ccd2b9d69a113ccdc3]https://github.com/psi46/pxar/tree/e17df08c7bbeb8472e8f56ccd2b9d69a113ccdc3[/URL]
to [URL=https://github.com/psi46/pxar/tree/9c3b81791738e1b8ec7dd9f0d1b68f8800f8416c]https://github.com/psi46/pxar/tree/9c3b81791738e1b8ec7dd9f0d1b68f8800f8416c[/URL]
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
Entry  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 [B]Reception1st tes[/B]t with IV at +10C for both modules and above features are confirmed. 
Entry  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.
Entry  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
    Reply  Wed Apr 15 17:33:53 2020, danek kotlinski, Module transfer, move 4 modules to gel-packs 
[quote="danek kotlinski"]Moved to gel-apcks:
1629 B
1631 B
Entry  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:
Entry  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.
Entry  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
Entry  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) 
    Reply  Tue Mar 31 17:36:36 2020, Urs Langenegger, Full test, exchanged adapter for DTB_WXC03A 
[quote="Urs Langenegger"]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) 
Entry  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.
Entry  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
Entry  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".
Entry  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
Entry  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*
    Reply  Fri Mar 27 16:41:16 2020, Andrey Starodumov, Module doctor, Wolfram's summay from Mar 25 
[quote="Andrey Starodumov"]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*
Entry  Tue Aug 6 16:06:45 2019, Matej Roguljic, Other, Vsh and ctrlreg for v4 chips 
The recommended default value for Vsh is 8, but the current version of pXar has it as 30. One should remember this when making new configuration folders
from mkConfig. The recommended value of ctrlreg is 17.
Entry  Thu Nov 28 18:58:30 2019, Dinko Ferencek, Software, Updated Fulltest configuration 
The Fulltest definition used on the lab PC and stored in /home/l_tester/L1_SW/elComandante/config/tests/Fulltest had the following content

pretest
Entry  Thu Jan 23 15:15:45 2020, Dinko Ferencek, Software, Trimming Vcal value changed from 35 to 40 
Trimming Vcal value changed from 35 to 40 in the testParameters.dat files stored in

/home/l_tester/L1_SW/pxar/data/tbm10d_procv3/
Entry  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
Entry  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*
Entry  Thu May 7 01:51:03 2020, Dinko Ferencek, Software, Strange bug/feature affecting Pixel Defects info in the Production Overview page Production_Overview_Pixel_defects_problem.png
It was observed that sometimes the Pixel Defects info in the Production Overview page is missing

[IMG]elog:256/1[/IMG]
Entry  Mon Feb 24 13:53:32 2020, Urs Langenegger, Module assembly, Setup changes in week 8 
Setup changes in week 8

Silvan considered the single-module gluing approach suboptimal. It was changed: 
Entry  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
Entry  Tue Apr 21 15:34:57 2020, Andrey Starodumov, General, Retesting starts today 
From today we will retest modules that have been tested with pXar SW versions earlier than March 18.
There were a few changes before this date: 
1) trimming VCal: 40->50
Entry  Wed Nov 27 21:50:02 2019, Dinko Ferencek, Software, Reorganized pXar configuration files for pixel modules 
Due to different DAC settings needed for PROC V3 and V4, a single folder containing module configuration files cannot cover both ROC types. To address this
problem, the existing folder 'tbm10d' in /home/l_tester/L1_SW/pxar/data/ containing configuration for PROC V4 was renamed to 'tbm10d_procv4' and a new
folder for PROC V3, 'tbm10d_procv3', was created. For backward compatibility, a symbolic link 'tbm10d' was created that points to 'tbm10d_procv4'.
    Reply  Thu Nov 28 18:23:31 2019, Dinko Ferencek, Software, Reorganized pXar configuration files for pixel modules 
[quote="Dinko Ferencek"]Due to different DAC settings needed for PROC V3 and V4, a single folder containing module configuration files cannot cover both
ROC types. To address this problem, the existing folder 'tbm10d' in /home/l_tester/L1_SW/pxar/data/ containing configuration for PROC V4 was renamed to
'tbm10d_procv4' and a new folder for PROC V3, 'tbm10d_procv3', was created. For backward compatibility, a symbolic link 'tbm10d' was created that points
Entry  Tue Mar 3 14:05:13 2020, Andrey Starodumov, Re-grading, Regrading C modules: due to Noise 
It has been realized by Urs that VCal to electron conversion used by MoreWeb is still 50e/VCal.
While recent calibration done by Maren with a few new modules suggest that this conversion is 43.7electrons per 1 VCal (the number from Danek).
I re-run MoreWeb analysis with 44e/Vcal for modules that are graded C for high noise (>300e).
    Reply  Wed Mar 4 16:00:05 2020, Andrey Starodumov, Re-grading, Regrading C M1591: due to Noise 
[quote="Andrey Starodumov"]It has been realized by Urs that VCal to electron conversion used by MoreWeb is still 50e/VCal.
While recent calibration done by Maren with a few new modules suggest that this conversion is 43.7electrons per 1 VCal (the number from Danek).
I re-run MoreWeb analysis with 44e/Vcal for modules that are graded C for high noise (>300e).
Entry  Wed Mar 11 17:59:48 2020, Andrey Starodumov, Re-grading, Regrading C M1542: due to Noise 
Follow the instruction from M1591 regrading log:
"To correct the Summary page one needs to remove rows from DB with C grade from previous data analysis (that for some reason stayed in DB)
using python Controller -d and then run python Controller -m MXXXX"
Entry  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
    Reply  Wed Mar 25 18:31:46 2020, Andrey Starodumov, Re-grading, Reanalised test results 
[quote="Andrey Starodumov"]Test resulsts of several modules have been re-analised without grading on trimbit failure. 
M1614: C->B
M1613: C->A
Entry  Thu Apr 9 17:36:31 2020, Andrey Starodumov, Reception test, RT of M1671 failed 
ROC12-ROC15 no hits.
A candidate to TBM0 substitution, hence Grade C*.
To Module doctor1
Entry  Thu Apr 9 14:36:10 2020, Andrey Starodumov, Reception test, RT of M1669 and M1670 
Both modules graded A.
Entry  Wed Apr 8 15:20:38 2020, Andrey Starodumov, Reception test, RT of M1665 
With CtrlReg=9 RT grade was B due to 90 noisy pixels in ROC5.
Noisy in this case means that one pixel in a 2x2 cluster in a few column got 40 hits instead of 10.
With CtrlReg=17 this problem gone. RT grade is A.
Entry  Tue Apr 7 15:25:21 2020, Andrey Starodumov, Reception test, RT of M1662 failed 
Address decoding of M1662 failed in one double column of ROC4.
To be decided what to do with this module.
Currently in C* tray.
    Reply  Wed Apr 8 17:17:13 2020, Andrey Starodumov, Reception test, RT of M1662 failed 
[quote="Andrey Starodumov"]Address decoding of M1662 failed in one double column of ROC4.
To be decided what to do with this module.
Currently in C* tray.[/quote]
Entry  Mon Apr 6 14:52:09 2020, Andrey Starodumov, Reception test, RT of M1657 failed 
No hits in ROC14 and ROC15.
Here is an error:
"ERROR: <datapipe.cc/CheckEventValidity:L524> Channel 5 Number of ROCs (1) != Token Chain Length (2)"
Entry  Fri Apr 3 14:18:15 2020, Andrey Starodumov, Reception test, RT of M1651 on April 2 
Due to damaged module adapter the first Reception test failed and after MoreWeb analysis graded C.
After second Reception test (with proper connected cable) the grade is A.
To keep grade A instead of C in the MoreWeb summary table I removed the directory of the first Reception:
Entry  Thu Apr 9 14:49:07 2020, Andrey Starodumov, Reception test, RT of M1650 failed 
Module has been tested on April 2nd.
Under Molex connector in ROC12 471 dead or noisy pixels.
Grade C.
Entry  Tue Mar 31 17:32:47 2020, Andrey Starodumov, Reception test, RT of M1641-M1644 
All modules graded A.
Entry  Mon Mar 30 17:49:31 2020, Andrey Starodumov, Reception test, RT of M1637-1640 
All modules: M1637, M1638, M1639, M1649, are graded A.
 
Entry  Thu Mar 26 17:41:52 2020, Andrey Starodumov, Reception test, RT of M1629-1632 
All modules M1629, M1630, M1631 and M1632 graded A
Entry  Wed Mar 25 14:44:37 2020, Andrey Starodumov, Reception test, RT of M1627 and M1628 
Both modules graded A.
Entry  Wed Apr 8 13:40:45 2020, Andrey Starodumov, Reception test, RT of M1625 failed 
Silvan substituted TBM on this module.
Now ROC0 does not have hits.
Grade C, goes to "Bad" tray.
Entry  Tue Apr 14 15:49:05 2020, Andrey Starodumov, Reception test, RT of M1623, M1657, M1673, M1674 
M1623: Grade A, should be B due to 71 bump defects in ROC4 
M1657: Grade B, due to 51 dead pixels in ROC12
M1673: Grade A, again 31 dead bumps in ROC12
Entry  Wed Apr 8 13:43:15 2020, Andrey Starodumov, Reception test, RT of M1623 failed 
M1623: all ROCs are programmable but no readout from ROC8-ROC11.
Visual inspection is OK.
To module doctor. 
Entry  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.
Entry  Mon Apr 6 14:42:43 2020, Andrey Starodumov, Reception test, RT of M1575 failed 
Silvan has substituted the TBM0 of M1575.
Still no hits in ROC0-ROC3: "NO DATA" "IDLE DATA" warnings
The long cable has been attached.
Entry  Tue Apr 7 14:26:48 2020, Andrey Starodumov, Reception test, RT of M1567 failed 
After exchange of TBM1 the results is the same:

[B]WAS[/B]: 
Entry  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
    Reply  Wed Apr 1 15:32:43 2020, Andrey Starodumov, Reception test, RT of M1546 
[quote="Andrey Starodumov"]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
Entry  Tue Apr 7 18:02:07 2020, Andrey Starodumov, Reception test, RT of 1654 
After Silvan removed a cap and re-bonded broken and bent wires M1654 again has been tested.
RT grade is A.
Protection cap to be glued and to be (F)tested.
Entry  Thu Feb 13 21:44:28 2020, Dinko Ferencek, Reception test, RT for 6 modules: 1573, 1574, 1575, 1576, 1577, 1578 
[B]1573:[/B] Grade [COLOR=darkgreen]A[/COLOR]
[B]1574:[/B] Grade [COLOR=darkblue]B[/COLOR], I(150)/I(100) > 2 (4.63)
[B]1575:[/B] Grade [COLOR=red]C[/COLOR], problem with one TBM core
Entry  Tue Feb 11 10:25:32 2020, Dinko Ferencek, Reception test, RT for 6 modules: 1563, 1564, 1565, 1566, 1567, 1568 
[COLOR=blue]Feb. 10[/COLOR]

[B]1563:[/B] Grade [COLOR=red]C[/COLOR], ROCs 8 and 10 not programmable, no obvious problems with wire bonds
Entry  Fri Feb 7 19:40:27 2020, Dinko Ferencek, Reception test, RT for 6 modules: 1557, 1558, 1559, 1560, 1561, 1562  
Reception test is done and all 6 modules were graded [COLOR=darkgreen]A[/COLOR].

Protective caps were glued to 4 modules: 1557, 1558, 1559, 1560
Entry  Thu Feb 6 17:19:12 2020, Dinko Ferencek, Reception test, RT for 6 modules: 1551, 1552, 1553, 1554, 1555, 1556 
Today reception test was run for 6 modules and looks OK for all module. The modules were graded as follows:

1551: [COLOR=darkgreen]A[/COLOR]
Entry  Wed Feb 12 15:40:13 2020, Dinko Ferencek, Reception test, RT for 3 modules: 1569, 1570, 1571; 1572 bad 
[B]1569:[/B] Grade [COLOR=darkgreen]A[/COLOR]
[B]1570:[/B] Grade [COLOR=darkgreen]A[/COLOR]
[B]1571:[/B] Grade [COLOR=darkblue]B[/COLOR], I > 2 uA (3.09 uA)
Entry  Fri Feb 14 14:40:59 2020, Dinko Ferencek, Reception test, RT for 2 modules: 1578, 1580 
[B]1579:[/B] Grade [COLOR=darkgreen]A[/COLOR]
[B]1580:[/B] Grade [COLOR=darkgreen]A[/COLOR]
Entry  Tue Apr 14 17:29:46 2020, Andrey Starodumov, General, ROC4 or ROC12 defects 
Starting from M1650 almost every module has a cluster of dead pixels or broken bump bonds on
ROC4 or (more often) ROC12. The number of defects varied from 20 to 40.
It's almost excluded that such damage is made at PSI, since both of us: Silvan and me, first time connected the cable
Entry  Fri Jan 24 18:16:09 2020, Dinko Ferencek, Module assembly, Protective cap gluing 
Today I additionally practiced protective cap gluing by adding a protective cap to module M1536.
Entry  Fri Feb 14 14:05:16 2020, Dinko Ferencek, Module assembly, Production yield so far 
Of 41 modules produced and tested so far (1536-1576), 6 modules were found to be [COLOR=red]bad[/COLOR] before or during the reception test, 5 were graded
[COLOR=red]C[/COLOR] after the full qualification (one of which is possibly [COLOR=orange]C*[/COLOR]) and the remaining 30 modules were graded [COLOR=darkblue]B[/COLOR]
(of which 4 were manually regraded from [COLOR=red]C[/COLOR] to [COLOR=darkblue]B[/COLOR]).
Entry  Tue May 26 23:00:50 2020, Dinko Ferencek, Other, Problem with external disk filling up too quickly 
The external hard disk (LaCie) used to back up the L1 replacement data completely filled up after transferring ~70 GB worth of data even though its capacity
is 2 TB. The backup consists of copying all .tar files and the WebOutput/ subfolder from /home/l_tester/L1_DATA/ to /media/l_tester/LaCie/L1_DATA/ The
corresponding rsync command is
Entry  Wed Oct 2 12:50:52 2019, Dinko Ferencek, Software, Problem with elComandante Keithley client during full qualification 
Full qualification was attempted for M1532 on Oct. 1. After the second Fulltest at -20 C finished, the Keitley client crashed with the following error

[CODE]
    Reply  Sat Oct 5 22:59:58 2019, Dinko Ferencek, Software, Problem with elComandante Keithley client during full qualification 
A new attempt to run the full qualification for M1532 was made on Friday, Oct. 4, but the Keithely client crashed with the same error message. This time
we managed to see from log files that the crash happened after the first IV measurement at -20 C was complete and Keithley was reset to -150 V. Unfortunately,
the log files were now saved for the test on Tuesday so we couldn't confirm that the crash occurred at the same point.
Entry  Wed Feb 12 11:15:04 2020, Dinko Ferencek, Module grading, Problem with dead trimbits understood 14x
It was noticed that some modules are graded [COLOR=red]C[/COLOR] because of typically just one ROC having a large number of dead trimbits. One example is
ROC 10 in M1537
[IMG]elog:81/1[/IMG]
Entry  Mon Mar 16 15:20:03 2020, Matej Roguljic, PhQualification, PhQualification on 16.3. 
PhQualification was run on modules M1561, M1564, M1565, M1566. 
Entry  Mon Mar 16 10:05:23 2020, Matej Roguljic, Software, PhQualification change 
Urs made a change in pXar, in the PhOptimization algorithm. One of the changes is in the testParameters.dat where vcalhigh is set to 100 instead of 255.
This was implemented on the PC used to run full qualification. A separate procedure for elComandante was created, "PhQualification.ini", which runs pretest,
pixelalive, trimming, ph and gainpedestal. This procedure will need to be run on all the modules qualified before this change was made and later merged
Entry  Mon Mar 16 11:04:41 2020, Matej Roguljic, PhQualification, PhQualification 14.-15.3. 
I ran PhQualification over the weekend with changes pulled from git (described here https://elrond.irb.hr/elog/Layer+1+Replacement/108).

14.3. M1554, M1555, M1556, M1557
Entry  Wed Aug 7 18:01:06 2019, Matej Roguljic, Cold box tests, PhOptimization problem 
August 7 - we found out that PhOptimization algorithm starts leaking memory if it fails to find proper values. If running one setup, the test might go through.
However, if multiple modules are tested in parallel and they all start leaking memory at the same time, the system will kill one testboard process (or
two if necessary), causing the unlucky testboard(s) to get stuck (powered on, HV on, but no tests running) until they are reset. Current solution to this
Entry  Sat Sep 12 23:45:56 2020, Dinko Ferencek, POS, POS configuration files created 
pXar parameter files were converted to POS configuration files by executing the following commands on the lab PC at PSI

[B]Step 1[/B] (needs to be done only once, should be repeated only if there are changes in modules and/or their locations)
    Reply  Fri Nov 6 07:28:42 2020, danek kotlinski, POS, POS configuration files created 
[quote="Dinko Ferencek"]pXar parameter files were converted to POS configuration files by executing the following commands on the lab PC at PSI

cd /home/l_tester/L1_SW/MoReWeb/scripts/
    Reply  Tue Nov 10 00:50:47 2020, Dinko Ferencek, POS, POS configuration files created 
[quote="danek kotlinski "][quote="Dinko Ferencek"]pXar parameter files were converted to POS configuration files by executing the following commands on
the lab PC at PSI
    Reply  Tue Jan 19 15:12:12 2021, Dinko Ferencek, POS, POS configuration files created 
M1560 in position bpi_sec1_lyr1_ldr1_mod3 was replaced by M1613.

The POS configuration files were re-generated and placed in /home/l_tester/L1_DATA/POS_files/Configuration_files/.
    Reply  Mon Jan 25 13:03:22 2021, Dinko Ferencek, POS, POS configuration files created 
The output POS configuration files has '_Bpix_' instead of '_BPix_' in their names. The culprit was identified to be the C3 cell in the 'POS' sheet of [URL=https://docs.google.com/spreadsheets/d/1PTlNGoXFR4mV685KnVLmydQnlJ2bUdSRyfKQmNT5pmE/edit?usp=sharing]Module_bookkeeping-L1_2020[/URL]
Google spreadsheet which contained 'Bpix' instead of 'BPix' which was messing up the file names. This has been fixed now and the configuration files regenerated.
Entry  Wed Mar 18 15:23:27 2020, Andrey Starodumov, General, New rules at PSI 
From today only two persons from the group allowed to be present. We are working in shifts: Urs in the morning start full qualification and I in the afternoon
test HDIs, run Reception, glue caps and switch the cold box, chiller etc after the full test finished.
Silvan is building usually 4 modules and 6-8 HDIs per day.
    Reply  Thu Feb 6 17:28:23 2020, Dinko Ferencek, Cold box tests, New Peltiers installed IMG_20200206_144211_resized.jpgIMG_20200206_145330_resized.jpgIMG_20200206_155320_resized.jpg
Today new Peltiers were installed and tested. Unfortunately, we had trouble reaching -20 C with this new set of Peltiers (they are of different type than
the ones that were taken out). After better insulation ofthe sample compartment and lowering the chiller temperature from 11 to 6 C, the coldbox was able
to reach close to -19.8 C after about half an hour
Entry  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
Entry  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.
    Reply  Thu Apr 9 16:13:51 2020, danek kotlinski, Module transfer, Modules moved to gel-pack 
[quote="danek kotlinski"]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.
Entry  Tue Feb 25 17:11:18 2020, Urs Langenegger, Module assembly, Modules glued and tested Feb 24/25 
Modules glued and tested Feb 24/25

The letters after the module name indicate the reception test grade. 
Entry  Sun Mar 29 18:14:59 2020, danek kotlinski, Other, Modules 1544 & 1563 in gelpack 
The 2 bad modules:
M1544
M1563 
Entry  Tue Sep 10 15:18:20 2019, Matej Roguljic, Other, Modules 1504, 1505, 1520 irradiation report 
Modules 1504, 1505 and 1520 were taken to Zagreb for irradiation on 13.08.19. The goal was to check the v4 behavior after irradiation. They were irradiated
to 1.2 MGy and returned to PSI on 9th of September. Upon testing them at PSI, they all had issues. ROCs on M1504 and M1520 were not programmable at all,
changing Vana had no effect. Vana could be set on M1505 while targeting Iana = 28 mA/ROC, however, no timing could be found for it and no working pixel
    Reply  Fri Sep 13 15:06:51 2019, Andrey Starodumov, Other, Modules 1504, 1505, 1520 irradiation report 
It was discovered that these modules were stored in Zagreb in the climatic lab where T was about +22C. These modules have been transported from Co60 irradiation
facility to the lab on open air with T>30C and RH>70%. Water in the air under the cap condensated on the surface of HDIs and diluted residuals (from soldering,
passivation etc), that after remains liquid or crystallised.
    Reply  Thu Sep 19 00:52:24 2019, Dinko Ferencek, Other, Modules 1504, 1505, 1520 irradiation report ZG-FER_temp_hum_2019.08.16.-09.16.pngpixellab-main-room-1.png
[quote="Andrey Starodumov"]It was discovered that these modules were stored in Zagreb in the climatic lab where T was about +22C. These modules have been
transported from Co60 irradiation facility to the lab on open air with T>30C and RH>70%. Water in the air under the cap condensated on the surface of HDIs
and diluted residuals (from soldering, passivation etc), that after remains liquid or crystallised.
Entry  Wed Feb 5 16:18:30 2020, Dinko Ferencek, Module transfer, Module location tracking added to the assembly spreadsheet 
To keep track of the module location, two columns were added to the module assembly spreadsheet [URL=https://docs.google.com/spreadsheets/d/12m2ESCLPH5AyWuuYV4KV1c5O_NEy7uP5PQKzVsdr3wQ/edit?usp=sharing]https://docs.google.com/spreadsheets/d/12m2ESCLPH5AyWuuYV4KV1c5O_NEy7uP5PQKzVsdr3wQ/edit?usp=sharing[/URL]
that contain the dates when a given module is shipped to ETHZ and when it is returned to PSI.
Entry  Fri May 29 15:56:27 2020, Andrey Starodumov, FTs for ETHZ, Module list2 
[COLOR=green]green:[/COLOR] correct in Total production overview
black: to remove old entries/rows
[COLOR=red]red:[/COLOR] many failures at one or both temperatures
    Reply  Thu Jun 4 11:32:46 2020, Dinko Ferencek, FTs for ETHZ, Module list2 
The following FullQualification tar file have been uploaded to CERNBox

rsync -avPSh --no-r --include="M1538_FullQualification_2020-04-29*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
Entry  Fri May 22 17:09:37 2020, Andrey Starodumov, FTs for ETHZ, Module list1 
[COLOR=green]green[/COLOR]: correct in Total production overview
black: to remove old entries/raws
[COLOR=red]red[/COLOR]: many failures at one or both temperatures
    Reply  Tue May 26 22:56:46 2020, Dinko Ferencek, FTs for ETHZ, Module list1 
The following FullQualification tar file have been uploaded to CERNBox

rsync -avPSh --no-r --include="M1536_FullQualification_2020-04-29*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
Entry  Mon Jun 15 10:36:45 2020, Andrey Starodumov, FTs for ETHZ, Module list 3 
M1596 2020-04-28 
M1597 2020-04-30 
M1598 2020-05-04 
    Reply  Tue Jun 16 00:45:48 2020, Dinko Ferencek, FTs for ETHZ, Module list 3 
The following FullQualification tar file have been uploaded to CERNBox

rsync -avPSh --no-r --include="M1596_FullQualification_2020-04-28*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
Entry  Wed Jan 22 11:50:20 2020, Dinko Ferencek, Software, Module configuration files for interactive tests 
There are two module configuration folders set up for elComandante

/home/l_tester/L1_SW/pxar/data/tbm10d_procv3/
Entry  Wed Feb 5 16:07:03 2020, Dinko Ferencek, Module assembly, Module assembly spreadsheet migrated to Google Sheets 
Excel file stored on CERNBox containing the module assembly spreadsheet has been replaced with a Google Sheet [URL=https://docs.google.com/spreadsheets/d/12m2ESCLPH5AyWuuYV4KV1c5O_NEy7uP5PQKzVsdr3wQ/edit?usp=sharing]https://docs.google.com/spreadsheets/d/12m2ESCLPH5AyWuuYV4KV1c5O_NEy7uP5PQKzVsdr3wQ/edit?usp=sharing[/URL].
This change should make common editing of the spreadsheet easier.
Entry  Thu May 7 00:56:50 2020, Dinko Ferencek, Software, MoReWeb updates related to the BB2 test 9x
Andrey noticed that results of the BB2 test (here example for ROC 12 in M1675)

[IMG]elog:255/1[/IMG]
Entry  Thu Apr 30 16:47:00 2020, Matej Roguljic, Software, MoReWeb empty DAC plots 
Some of the DAC parameters plots were empty in the total production overview page. All the empty plots had the number "35" in them (e.g. DAC distribution
m20_1 vana 35). The problem was tracked down to the trimming configuration. Moreweb was expecting us to trim to Vcal 35, while we decided to trim to Vcal
50. I "grepped" where this was hardcoded and changed 35->50. 
    Reply  Thu Apr 30 17:24:57 2020, Dinko Ferencek, Software, MoReWeb empty DAC plots 
[quote="Matej Roguljic"]Some of the DAC parameters plots were empty in the production overview page. All the empty plots had the number "35" in them (e.g.
DAC distribution m20_1 vana 35). The problem was tracked down to the trimming configuration. Moreweb was expecting us to trim to Vcal 35, while we decided
to trim to Vcal 50. I "grepped" where this was hardcoded and changed 35->50. 
    Reply  Thu Apr 30 17:33:04 2020, Andrey Starodumov, Software, MoReWeb empty DAC plots 
[quote="Matej Roguljic"]Some of the DAC parameters plots were empty in the total production overview page. All the empty plots had the number "35" in them
(e.g. DAC distribution m20_1 vana 35). The problem was tracked down to the trimming configuration. Moreweb was expecting us to trim to Vcal 35, while we
decided to trim to Vcal 50. I "grepped" where this was hardcoded and changed 35->50. 
    Reply  Thu May 7 00:10:15 2020, Dinko Ferencek, Software, MoReWeb empty DAC plots 
[quote="Andrey Starodumov"][quote="Matej Roguljic"]Some of the DAC parameters plots were empty in the total production overview page. All the empty plots
had the number "35" in them (e.g. DAC distribution m20_1 vana 35). The problem was tracked down to the trimming configuration. Moreweb was expecting us
to trim to Vcal 35, while we decided to trim to Vcal 50. I "grepped" where this was hardcoded and changed 35->50. 
Entry  Fri Jan 24 18:12:00 2020, Dinko Ferencek, Software, MoReWeb code updates 
MoReWeb code updated to include the ROC wafer info in the XrayCalibration and XRayHRQualification pages:
[URL=https://gitlab.cern.ch/CMS-IRB/MoReWeb/commit/4de8ea39050600367ae0b8e959fcc00f29be45d8]https://gitlab.cern.ch/CMS-IRB/MoReWeb/commit/4de8ea39050600367ae0b8e959fcc00f29be45d8[/URL]
Entry  Sun Feb 9 18:36:13 2020, Dinko Ferencek, Module grading, Manual grading 
The procedure for manual grading is described in [URL=https://github.com/psi46/MoReWeb/pull/120]https://github.com/psi46/MoReWeb/pull/120[/URL].

In short, inside the test folder it is necessary to place a text file called [I]grade.txt[/I] that contains just one number representing the manual grade:
Entry  Fri Sep 18 15:45:21 2020, Andrey Starodumov, Other, M2211 and M2122 
I made a mistake and instead M2122 used ID M2211 in the .ini file.
Hence now we do not have entry for M2122 but have 2 entries for M2211: one is of Sept 18 and another one called old of Sep 17).
Test results of Sep 17 are for 2211
Entry  Mon May 4 15:28:14 2020, Andrey Starodumov, General, M1660  
M1660 is taken from gel-pak and cabled for retest.
This module was graded C only at second FT at-20C, the first FT at -20C and FT at +10C give grade B. Massive trimming failure of pixels in ROC7 was not
observed.
Entry  Fri Apr 3 17:39:19 2020, Andrey Starodumov, Module doctor, M1654 
After a protection cap glued to M1654, I observed a few strongly bent wire bonds and probably some shorts on ROC8. One (VD+) of them is even detached (on
HDI side). Pads from 25/26 till 35 are affected. 
Nevertheless the Reception test gave the same results as before the cap gluing: grade A.
Entry  Fri Apr 3 13:55:48 2020, Andrey Starodumov, Reception test, M1653 failed Reception 
Roc12-15 are not programmable.
Visual inspection is Ok, nothing found.
To module doctor!
Entry  Thu Apr 2 17:06:19 2020, Andrey Starodumov, Reception test, M1652 failed Reception 
ROC1 of M1652 is not programmable. 
Put in the "Bad" tray as C module.
Entry  Wed Apr 1 14:36:37 2020, Andrey Starodumov, Reception test, M1646 failed Reception 
M1646 showed Idig=1A, ROC6 is not programmable.
Visual inspection: scratch on a periphery (between bonding pads) of ROC6.
To module doctor! 
Entry  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()
Entry  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
Entry  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.
Entry  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
Entry  Tue Apr 14 16:54:31 2020, Andrey Starodumov, Other, M1633 cable disconnected 
We do not have any more module holders. 
M1633 was in "Module doctor" tray.
I took module off the holder and put it in a gel-pak.
Entry  Fri May 29 13:56:35 2020, Andrey Starodumov, Re-grading, M1630 
In ROC1 of M1630 gain calibration failed massively (3883 pixels) at +10C with CtrlReg 9.
A special test of M1630 only at +10C and with CtrlReg 17 showed no problem.
p10_1 from ~/L1_DATA/ExtraTests_ToBeKept/M1630_FullTestp10_2020-04-17_15h54m_1587131688/000_Fulltest_p10
Entry  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.
Entry  Tue Mar 24 15:20:18 2020, Andrey Starodumov, Reception test, M1623 failed Reception 
M1623: all ROCs are programmable but no readout from ROC0-ROC3.
Visual inspection is OK.
To module doctor. 
Entry  Tue Mar 24 15:18:59 2020, Andrey Starodumov, Reception test, M1621 failed Reception 
On M1621 ROC8 is not programmable.
Entry  Fri Mar 20 17:05:58 2020, Andrey Starodumov, Reception test, M1617 failed 
ROC8 of M1617 is programmable but no readout from it.
Silvan noticed that a corner of one ROC of this module is broken,
this is exactly ROC8.
    Reply  Sun Mar 22 13:57:25 2020, Danek Kotlinski, Reception test, M1617 failed 
[quote="Andrey Starodumov"]ROC8 of M1617 is programmable but no readout from it.
Silvan noticed that a corner of one ROC of this module is broken,
this is exactly ROC8.[/quote]
Entry  Fri Mar 20 14:53:52 2020, Andrey Starodumov, Reception test, M1616 failed 
ROC10 of M1616 is not programmable, no readout from ROC10 and ROC11.
Visual inspection of wire bonds - OK
To module doctor!
    Reply  Sun Mar 22 14:02:20 2020, Danek Kotlinski, Reception test, M1616 failed 
[quote="Andrey Starodumov"]ROC10 of M1616 is not programmable, no readout from ROC10 and ROC11.
Visual inspection of wire bonds - OK
To module doctor![/quote]
Entry  Fri Mar 20 14:46:31 2020, Andrey Starodumov, Reception test, M1615 failed 
M1615 is programmable but "no working phases found"
Visual inspection of wire bonds - OK.
To module doctor!
    Reply  Sun Mar 22 14:05:20 2020, Danek Kotlinski, Reception test, M1615 failed 
[quote="Andrey Starodumov"]M1615 is programmable but "no working phases found"
Visual inspection of wire bonds - OK.
To module doctor![/quote]
Entry  Fri Aug 28 11:13:33 2020, Andrey Starodumov, Module grading, M1615 
M1615: one pixel in ROC10 unmaskable hence should be graded C. Otherwise the module is of grade A
To be checked!
Entry  Fri Jun 5 13:47:11 2020, Andrey Starodumov, Module grading, M1613 
FT of this modules has been done twice: March 23 and March 25, in both cases with the final test SW. On March 23 module was graded C due to many trim bit
failures. That is why it was retested. But after failure in trimbits were excluded from the grading, FT of Mar 23 looks better then later FT of Mar25.
That is why FT of Mar 23 is kept.
Entry  Thu Mar 19 17:17:27 2020, Andrey Starodumov, Reception test, M1609-M16012 
Reception test done and caps are glued to modules M1609-M1612.
M1611 graded B due to double column failure on ROC13. Others graded A.
Entry  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.
    Reply  Thu Mar 26 15:37:18 2020, Urs, Module grading, M1606 anaTrim-thrDiff-data__M1606__pxar.pdf
attached find the threshold difference distributions for all four trimbits for all ROCs
Entry  Mon May 11 14:14:05 2020, danek kotlinski, Other, M1606 m1606_roc2_thr_1d.pngm1606_roc2_thr_2d.pngm1606_roc2_ph70.png
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.
Entry  Wed Mar 18 17:43:41 2020, Andrey Starodumov, Module assembly, M1605-M1608 
M1605 and M1606: reception done on Mar 17
M1607 and M1608: reception done today
All: grade A
Entry  Mon Mar 16 15:17:18 2020, Matej Roguljic, Module assembly, M1601 and M1602 
Andrey and I assembled modules 1601 and 1602 on Friday, 13.3. On Monday, 16.3. I ran reception on them (both graded A) and then glued protection caps on
them.
Entry  Fri Aug 28 12:02:48 2020, Andrey Starodumov, XRay HR tests, M1599 
ROC5 has eff=93.65% and should be graded C. Somehow efficiency was not taken into account for HR test grading???
Entry  Wed Sep 2 16:09:24 2020, Matej Roguljic, Modules for P, M1595 switch with M1558 
Module 1595 was foreseen to go on the inner ladder 5, position -2 (negative two). During the pre-installation test, we saw it had a high leakage current,
~8 microAmps at room temperature. Therefore, we decided to place module 1558 in its place instead of it.
Entry  Mon Apr 6 14:27:31 2020, Andrey Starodumov, Reception test, M1593 
Silvan has substituted the TBM0 of M1593.
I had to substitute a cable that has residuals and with which the Reception test failed completely.
The long cable has been attached.
Entry  Wed Mar 11 15:34:57 2020, Urs Langenegger, Other, M1586: issues with MOLEX? 
Module M1586 had passed the full qualification on 20/02/27. I had had to re-insert the cable in the Molex connector for it to become programmable. 

On 2020/03/09, I tried to re-test M1586, but it was not programmable. Visual inspection revealed nothing to me. I did re-insert the cable once again, but
    Reply  Wed Mar 11 16:48:10 2020, Andrey Starodumov, Other, M1586: issues with MOLEX? 
[quote="Urs Langenegger"]Module M1586 had passed the full qualification on 20/02/27. I had had to re-insert the cable in the Molex connector for it to become
programmable. 
Entry  Fri May 1 19:34:01 2020, danek kotlinski, Module grading, M1582 m1582_roc1_thr.pngm1582_roc1_thr_2d.png
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.
Entry  Mon May 11 14:40:16 2020, danek kotlinski, Other, M1582 m1582_roc1_thr_1d.pngm1582_roc1_thr_2d.pngm1582_roc1_ph70.png
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.
Entry  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.
Entry  Fri Aug 28 11:53:23 2020, Andrey Starodumov, PhQualification, M1555 
There is no new PH optimisation for this module?!
To be checked!
Entry  Fri May 29 15:41:40 2020, Andrey Starodumov, General, M1546 C10-p10.pdfTrimBits.pdfC10-50.pdf
ROC10 of M1546 has 107 pixels with trimming problems:
in a VCal threshold scan after trimming 81 has a threshold underflow, means <0, and 26 pixels are outside 40-60VCal window (around Vcal 50) at +10C only.
Trimbit distribution looks reasonable.
Entry  Tue Mar 31 06:54:12 2020, danek kotlinski, Module grading, M1542 Canvas_1.png
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.
Entry  Wed Apr 29 08:48:06 2020, Urs Langenegger, Other, M1539 
M1539 showed no readout. I tried, all without success, 
- reconnecting the cable to the adapter multiple times
- connecting to the adapter in the blue box
Entry  Mon May 11 13:19:51 2020, Andrey Starodumov, Cold box tests, M1539 
After several attempts including reconnecting the cable, M1539 had no readout if it's connected to TB3. When connected to TB1, M1539 did not show any problem.
M1606 worked properly both with TB1 and TB3.
For FT test the configuration is following:
Entry  Fri Aug 28 14:07:24 2020, Andrey Starodumov, PhQualification, M1539 
There is no new PH optimisation for this module?!
To be checked!
Entry  Wed Nov 20 16:53:50 2019, Andrey , Full test, M1533 and M1534 FullQualification 
FullQualification of two modules M1533 and M1534 has been done. Full time of the test is about 7hrs.
Test included: FT@-10C, IV@-10, 2Cycles from -10C up to +10C, FT@-10C, IV@-10C, Ft@1-C and IV@10C.
No issues observed. 
Entry  Thu Feb 6 00:45:25 2020, Dinko Ferencek, Cold box tests, Lost at least one Peltier in the coldbox TemperatureCycle.pdf
During an overnight (Feb. 4-5) FullQualification run with modules 1545, 1547, 1548, and 1549 the coldbox lost the ability to maintain the temperature at
-20 C. As can be seen from the attached temperature log, the problems already started during the temperature cycles where the last 2 cycles were noticeably
longer than the first 3 and finally during the second Fulltests at -20 C the temperature started rising and stabilized around -10 C. Based on these observations
Entry  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
Entry  Mon Jan 20 21:33:20 2020, Dinko Ferencek, Cold box tests, Latest tests of PH optimization TrimBitTest_old.pngTrimBitTest_new.png
We did some tests by running the latest version of pXar on modules M1521, M1529, M1534 and M1536, specifically trimming and PH optimization. Of the 4 modules
tested, the PH optimization converged only for M1521. We plan to further investigate with Urs' help possible reasons for failed PH optimization.
    Reply  Tue Jan 21 12:19:08 2020, Dinko Ferencek, Cold box tests, Latest tests of PH optimization 
[quote="Dinko Ferencek"]We did some tests by running the latest version of pXar on modules M1521, M1529, M1534 and M1536, specifically trimming and PH optimization.
Of the 4 modules tested, the PH optimization converged only for M1521. We plan to further investigate with Urs' help possible reasons for failed PH optimization.
Entry  Wed May 13 17:57:45 2020, Andrey Starodumov, Other, L1_DATA backup 
L1_DATA files are backed up to the LaCie disk
Entry  Fri Jan 24 18:22:00 2020, Dinko Ferencek, General, L1 replacement web page updated 
This week several new links were added to the main L1 replacement web page located at the following URL
[URL=http://cms.web.psi.ch/L1Replacement/]http://cms.web.psi.ch/L1Replacement/[/URL]
Entry  Fri Oct 23 13:33:04 2020, danek kotlinski, Module transfer, L1 & L2 modules to go to P5 
The following modules will be transported to CERN/P5 as spares.

1) L1 
Entry  Thu Jan 23 14:54:45 2020, Dinko Ferencek, Cold box tests, Keithley exchanged 
Yesterday during an attempt to run the FullQualification, elComandante would lose control over Keithley after performing the IV curve measurements and would
go in the subsequent Fulltest with HV off. This happened both between the two sets of tests at -20 C and between the tests at -20 C and +10 C. Today we
exchanged the old Keithley with a new one and we observe that the communication with this new Keithley is much smoother without any error codes and warning
Entry  Tue Aug 6 14:30:00 2019, Dinko Ferencek, Documentation, Jumo Imago 500 manuals 
Manuals can be found at https://www.manualslib.com/products/Jumo-Imago-500-8786441.html
Entry  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.
Entry  Thu Oct 31 10:41:12 2019, Matej Roguljic, Cold box tests, Issue with DTB_WWVASW 
On 29th of October, an issue with DTB_WWVASW was noticed when trying to run FullQualification on 4 modules at the same time. On a tested, working module,
setting Vana works but taking tornado plots (setvthrcomp) doesn't as well as other tests. Curiously enough, after switching the DTB with the one used for
HDI testing (DTB_WRN13L) the problem was still there. This lead us to believe that the problem was with cables or ground. All cables and the adapter were
Entry  Mon Mar 9 16:16:48 2020, Andrey Starodumov, HDI test, HDIs: 3001, 3002, 3003, 3004 and 4033 
Today I tested 5 HDIs: 3001, 3002, 3003, 3004 and 4033
Results:
[B]3001[/B]
Entry  Wed Mar 11 17:12:05 2020, Matej Roguljic, HDI test, HDI testing procedure change 
There is an additional test that will be used from 11.03. on all HDIs. It involves measuring the voltage between ground and the HV pin of the needle card
with the goal of checking whether proper voltage is delivered to the HDI. The HDI testing script has been updated and it now prompts the user to set the
voltage to -800 V, measure the voltage on the pin and write this into the test results. After this, another instruction has been added which tells the
Entry  Wed Sep 18 15:45:45 2019, Matej Roguljic, Module assembly, HDI sparking under HV test 7x
HDI [B]8010[/B] passed all test except the HV. Under the HV test, some sparks could be heard and even seen by eye on the right TBM (closer to the HV pad!).
Testing it again, showed that it was indeed damaged by the spark. Sparking craters could be seen with the microscope between pads 4 and 5 of the TBM.
Entry  Wed Aug 7 11:49:07 2019, Matej Roguljic, Module assembly, HDI glue irradiation tests 10x
Six different glues were used to glue the cap on six dummy modules. They were all irradiated to 120 MRad in Zagreb after which they were taken to PSI and
tested with the tweezers under the microscope.
Entry  Thu Feb 6 17:09:50 2020, Dinko Ferencek, Module assembly, Gluing stamp improvements 
Silvan has made additional grooves on the gluing stamp which now sits stably on top of the module without any rocking motion and also allows better glue
distribution to all the HDI components that are supposed to receive the glue.
Entry  Sat Mar 14 17:08:14 2020, Matej Roguljic, Full test, Fulltests on 2020/03/13 

Modules tested:
M1591 C (gain at -20)
Entry  Mon Mar 2 17:39:36 2020, Urs Langenegger, Full test, Fulltests on 2020/03/02 
Modules tested: 
M1595 C
M1596 B
Entry  Fri Feb 28 17:33:16 2020, Urs Langenegger, Full test, Fulltests on 2020/02/28 
M1589 B
M1590 C (gain issues?)
M1591 C (noise issues?)
Entry  Thu Feb 27 09:47:51 2020, Urs Langenegger, Full test, Fulltest on 2020/02/26 
On Wednesday, 2020/02/26 the following modules went through the full qualification procedure: 
M1581
M1582
Entry  Thu Jan 30 13:51:03 2020, Matej Roguljic, Cold box tests, Fulltest failure - psiAgente 
During the first fulltest@-20 of the full qualification procedure for modules: 1539, 1541, 1542 and 1543; an error message popped up "psi Agente: self.Testboards[0]
failed - the following boards are busy: TB1(DTB...:M1541), TB2(DTB...:M1542), TB3(DTB...:M1543). This means that the first fulltest for module 1539 was
not executed.
Entry  Tue Feb 11 17:56:06 2020, Dinko Ferencek, Cold box tests, Fulltest failure - psiAgente 
During today's full qualification the 2nd fulltest@-20 for TB1 (M1562) failed

[CODE]
Entry  Wed Feb 26 10:34:55 2020, Urs Langenegger, Full test, Fulltest after Peltier replacement 
On 2020/02/25, after SIlvan had replaced the Peltiers, I did a fulltest. Here the summary: 

  Finished all tests. Summary of test durations:
Entry  Mon May 11 21:37:43 2020, Dinko Ferencek, Software, Fixed the BB defects plots in the production overview page 
[URL=https://gitlab.cern.ch/CMS-IRB/MoReWeb/-/commit/0407e04c85725cac41a1cbf08af68744c40b2bc7]0407e04c[/URL]: attempting to fix the BB defects plots in
the production overview page (seems mostly related to the 17 to 10 C change)
[URL=https://gitlab.cern.ch/CMS-IRB/MoReWeb/-/commit/f2d554c5f53c712ffaec02d55bfb6006b0fe3799]f2d554c5[/URL]: it appears that BB2 defect maps were not
Entry  Mon May 11 21:32:20 2020, Dinko Ferencek, Software, Fixed double-counting of pixel defects in the production overview page 
As a follow-up to this [URL=https://elrond.irb.hr/elog/Layer+1+Replacement/255]elog[/URL], double-counting of pixel defects in the production overview page
was fixed in [URL=https://gitlab.cern.ch/CMS-IRB/MoReWeb/-/commit/3a2c67727b4b048c1546d666c4104396418bc2fe]3a2c6772[/URL].
    Reply  Wed May 13 23:16:37 2020, Dinko Ferencek, Software, Fixed double-counting of pixel defects in the production overview page 
[quote="Dinko Ferencek"]As a follow-up to this [URL=https://elrond.irb.hr/elog/Layer+1+Replacement/255]elog[/URL], double-counting of pixel defects in the
production overview page was fixed in [URL=https://gitlab.cern.ch/CMS-IRB/MoReWeb/-/commit/3a2c67727b4b048c1546d666c4104396418bc2fe]3a2c6772[/URL].[/quote]
Entry  Wed Oct 2 12:41:16 2019, Dinko Ferencek, Module assembly, First production modules assembled 6x
First production modules (M1530, M1531, M1532) were built on Monday, Sep. 30 2019.

There was a problem with wire bonding of ROC5 on M1530. There is a small crater on one of the ROC pads which appears to had been created by the BareModule
Entry  Mon Jan 27 17:50:48 2020, Matej Roguljic, Cold box tests, Failing modules at -20 
Friday, 24.1., it was noticed that the modules are graded as 'C' in similar fashion. Module is graded A/B at +10 degrees and then graded C at -20. The reason
for grade C was that the trimming procedure was not successful on at least one of the ROCs on each module. This problem was further investigated on 27.1.
Wolfram suspected that the problem lies in zero suppression mode since the pixels with failed threshold comes in groups of four pixels. The corresponding
Entry  Tue Apr 14 17:19:44 2020, Andrey Starodumov, Full test, FT of M1668, M1669, M1670, M1672 
M1668: Grade B due to mean noise >200e for several ROCs
M1669: Grade B due to ROC2 mean noise >200e
M1670: Grade B due to ROC1 mean noise >200e
Entry  Thu Apr 16 17:31:16 2020, Andrey Starodumov, Full test, FT of M1662, M1675, M1676 
M1662: Grade C due to failure of ROC4 in almost all tests: PixelAlive, PH calibration etc
Should be investigated and retested. At Reception PixelAlive etc was OK, only one double column showed problems
M1675: Grade B due to mean noise > 200e for several ROCs
Entry  Thu Apr 9 17:24:49 2020, Andrey Starodumov, Full test, FT of M1654, M1665, M1666, M1667 
M1654: Grade A
M1665: Grade B due to noisy pixels in ROC5. To be checked by module doctor!
M1666: Grade B due to mean noise of several chips > 200 electrons. Again on ROC12 there is a cluster of 31 dead bumps!
Entry  Thu Apr 2 22:50:33 2020, Andrey Starodumov, Full test, FT of M1645, M1646, M1647, M1648 
All modules graded B due to mean noise > 200 electrons.
    Reply  Fri Apr 3 15:33:10 2020, Andrey Starodumov, Full test, FT of M1645, M1646, M1647, M1648 
[quote="Andrey Starodumov"]All modules graded B due to mean noise > 200 electrons.[/quote]
Correction:
in reality M1546 has been tested and NOT 1646. M1646 failed Reception due to not working ROC and graded C.
    Reply  Mon Apr 6 14:23:03 2020, Andrey Starodumov, Full test, FT of M1645, M1646, M1647, M1648 
[quote="Andrey Starodumov"][quote="Andrey Starodumov"]All modules graded B due to mean noise > 200 electrons.[/quote]
Correction:
in reality M1546 has been tested and NOT 1646. M1646 failed Reception due to not working ROC and graded C.
Entry  Wed Apr 1 17:10:16 2020, Andrey Starodumov, Full test, FT of M1641-M1644 
M1641: B due to mean noise > 200electons for a few ROCs
M1642: B due to mean noise > 200electons for a few ROCs
M1643: B due to mean noise > 200electons for a few ROCs
Entry  Tue Mar 31 18:23:18 2020, Andrey Starodumov, Full test, FT of M1637, M1638, M1639, M1640 
M1637: C. Graded C due to not completed first test at -20C. Urs has reported issues. The second -20C after T-Cycle and test at +10C are graded A.
Tomorrow I'll upgrade this module manually to A
M1638: A
    Reply  Fri Apr 3 14:15:01 2020, Andrey Starodumov, Full test, FT of M1637, M1638, M1639, M1640 
[quote="Andrey Starodumov"]M1637: C. Graded C due to not completed first test at -20C. Urs has reported issues. The second -20C after T-Cycle and test at
+10C are graded A.
Tomorrow I'll upgrade this module manually to A
Entry  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.
    Reply  Mon Mar 30 14:52:59 2020, Danek Kotlinski, Full test, FT of M1629, M1630, M1631, M1632 m1630_roc1_ph_fits.png
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.
    Reply  Mon Mar 30 15:40:52 2020, Urs, Full test, FT of M1629, M1630, M1631, M1632 phval-curve_M1630_p10_C1.pdfphshot_vcal255.pdfpixelalive_C1.pdf
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. 
Entry  Wed Apr 15 17:26:46 2020, Andrey Starodumov, Full test, FT of M1623, M1657, M1673, M1674 
M1623: Grade B due to rel gain width, in ROC4 74 pixels failed trimming (Threshold) and mean noise >200e
M1657: Grade B due to 70 dead pixels in ROC12 and mean noise >200e
M1673: Grade B due to mean noise >200e in a few ROCs
Entry  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
    Reply  Wed Mar 25 17:03:11 2020, Andrey Starodumov, Full test, FT of M1615, M1619, M1620, M1622 
[quote="Andrey Starodumov"]Test results have been analysed with modified code:
M1615: B
M1619: A
Entry  Fri Mar 20 18:32:34 2020, Andrey Starodumov, Full test, FT of M1609-M1612 
M1609 and M1611 are graded C
M1610 and M1612 are graded B
Entry  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
Entry  Mon Apr 6 17:18:02 2020, Andrey Starodumov, Full test, FT of M1606, M1630, M1655, M1566 
M1606: B due to mean noise of several ROCs> 200e
M1639: C* due to failure many pixels of ROC1 at +10C as before: to be run at +10C with CtrlReg=17
M1655: B due to mean noise of several ROCs> 200e
Entry  Thu Mar 19 18:01:50 2020, Andrey Starodumov, Full test, FT of M1605-M1608 
Only M1607 graded B. All others are graded C due to trimbit test. 
M1606 should be looked carefully and may be retested since the threshold after trimming has strange features
(although not for all temperatures) that may mean that some trimbits really do not work.
Entry  Wed Mar 18 17:46:07 2020, Andrey Starodumov, Full test, FT of M1601-M1604 
M1601-M1604 passed full test
M1601: grade B
M1602-M1604: Grade C. The main reason is failed pixels during trimbit test. 
Entry  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
Entry  Tue Apr 7 16:57:01 2020, Andrey Starodumov, Full test, FT of M1593, M1658, M1659, M1660 
M1593: B due to Rel.gain width and mean noise of a few ROCs
M1658: B due to threshold and mean noise of ROC15
M1659: B due to threshold and mean noise of a few ROCs
Entry  Wed Apr 29 18:11:36 2020, Andrey Starodumov, Full test, FT of M1590, M1592, M1596, M1600 
Modules tested om April 28
M1590: Grade B  Grade B due to mean noise >200e for a few ROCs
M1592: Grade B  Grade B due to mean noise >200e for a few ROCs
Entry  Tue Apr 28 18:11:45 2020, Andrey Starodumov, Full test, FT of M1586, M1587, M1588, M1589 
M1586: Grade B due to mean noise >200e for a few ROCs
M1587: Grade B due to mean noise >200e for a few ROCs
M1588: Grade B due to mean noise >200e for a few ROCs
Entry  Tue May 5 13:58:45 2020, Andrey Starodumov, Full test, FT of M1582, M1649, M1667 
M1582: Grade C due to trimming failure in ROC1 for 189 pixels at +10C. This is third time module restesed:
1) February 26 (trimming for VCal 40 and old PH optimization): Grade B, max 29 failed pixels and in few ROCs mean noise
2) April 27: Grade C due to trimming failure in ROC1 for 167 pixels at +10C, at -20C still max 45 failed pixels and in few ROCs mean noise
Entry  Tue Apr 28 18:06:41 2020, Andrey Starodumov, Full test, FT of M1582, M1583, M1584, M1585 
Modules tested om Apr 27
M1582: Grade C due to 167 pixels failed trimming on ROC1 at +10C only. Previous test on Feb 26 at +10C was graded B!
M1583: Grade B due to mean noise >200e for a few ROCs
Entry  Wed May 6 16:24:21 2020, Andrey Starodumov, Full test, FT of M1580, M1595, M1606, M1659 
M1580: Grade B due to mean noise >200e in ROC5/8 and trimming failures for 100+ pixels in the same ROCs at +10C, previous result of April 27 was better
M1595: Grade B due to mean noise >200e in few ROCs, previous result of April 30 was much worse with 80/90 pixels failed trimming in ROC0 and ROC15
M1606: Grade C due to 192 pixels failed trimming in ROC2 at +10C, previous result of April 6 was much better with B grade
Entry  Mon Apr 27 13:50:09 2020, Andrey Starodumov, Full test, FT of M1578, M1579, M1580, M1581 
M1578: Grade B due to mean noise >200e for a few ROCs and 67 pixels failed trimming in ROC1 at -20C
M1579: Grade A 
M1580: Grade B due to mean noise >200e for a few ROCs and 59/112 pixels failed trimming in ROC5/ROC8 at +10C
Entry  Wed May 6 13:20:28 2020, Andrey Starodumov, Full test, FT of M1574, M1581, M1660, M1668 
Modules tested on May 5th
M1574: Grade B due to mean noise >200e in ROC10 and trimming failures for 89 pixels in ROC0, the same as the first time April 24 (there 104 pixels failed)
M1581: Grade B due to mean noise >200e in ROC8/13, no trimming failures in ROC8/13, as it was on April 27 (120+ pixel in ROC8/13 failed) ->[COLOR=red]
Entry  Mon Apr 27 13:23:47 2020, Andrey Starodumov, Full test, FT of M1573, M1574, M1576, M1577 
Test has been done on April 24
M1573: Grade B due to mean noise >200e for a few ROCs
M1574: Grade B due to mean noise >200e for a few ROCs and trimming failed for >100 pixels and RelGainWidth too  wide for ROC0
Entry  Wed Apr 8 17:09:05 2020, Andrey Starodumov, Full test, FT of M1572, M1661, M1663, M1664 
M1572: Grade B due to mean noise of ROC4 211 electrons
M1661: Grade B due to mean noise of a few ROCs > 200 electrons and in ROC12 44 pixels failed threshold cut
M1663: Grade B due to mean noise of a few ROCs > 200 electrons
Entry  Fri Apr 24 13:59:43 2020, Andrey Starodumov, Full test, FT of M1568, M1569, M1570, M1571 
M1568: Grade B due to mean noise >200e for a few ROCs and for ROC0 RelGainWidth(=0.1) is twice larger then for other ROCs
M1569: Grade B due to mean noise >200e for a few ROCs
M1570: Grade B due to mean noise >200e for a few ROCs
Entry  Thu Apr 23 17:26:51 2020, Andrey Starodumov, Full test, FT of M1561, M1564, M1565, M1566 
M1561: Grade B due to several ROCs mean noise >200e
M1564: Grade B due to two ROCs mean noise >200e
M1565: Grade B due to two ROCs mean noise >200e
Entry  Fri Apr 3 17:29:51 2020, Andrey Starodumov, Full test, FT of M1557, M1591, M1649, M1651 
M1557: C due to 214 pixel threshold failure in ROC4 only at +10C (several previous FTs at +10C were graded B!)
M1591: B due to mean noise > 200electrons for several ROCs
M1649: C due to 270 pixel threshold failure in ROC11 only at +10C
Entry  Thu Apr 23 13:37:29 2020, Andrey Starodumov, Full test, FT of M1556, M1557, M1559, M1560 
M1556: Grade B due to several ROCs mean noise >200e
M1557: Grade B due to several ROCs mean noise >200e and trimming failed for 60 pixel in ROC4 at -20C
M1559: Grade A
Entry  Mon May 4 14:13:39 2020, Andrey Starodumov, Full test, FT of M1552, M1553, M1595, M1597 
FT on April 30th
M1552: Grade B due to mean noise >200e for ROC7,8
M1553: Grade B due to mean noise >200e for a few ROCs
Entry  Thu Apr 30 15:25:36 2020, Andrey Starodumov, Full test, FT of M1548, M1549, M1550, M1551 
M1548: Grade B due to mean noise >200e for ROC11
M1549: Grade B due to mean noise >200e for ROC2. In total 200+ pixels failed trimming in the module [COLOR=red]-> investigate???[/COLOR]
M1550: Grade B due to mean noise >200e for ROC5
Entry  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 [B]Module placed in a tray C*[/B]
1627: B
    Reply  Fri Apr 3 15:21:54 2020, Andrey Starodumov, Full test, FT of M1545, M1557, M1627, M1628 
[quote="Andrey Starodumov"]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 [B]Module placed in a tray C*[/B]
1627: B
Entry  Fri Apr 17 18:05:45 2020, Andrey Starodumov, Full test, FT of M1542, M1557, M1630, M1649 only at +10C 
M1542 has grade C for relative gain width. Was tested with early versions of test SW with trim VCal=40 and not yet optimized PH optimization/calibration.
Other modules have grade C only at +10C. This time CtrlReg=17 instead of 9 is used/
M1542: Grade B due to 61 pixels failed Threshold criteria (trimming)
Entry  Tue Apr 21 17:39:48 2020, Andrey Starodumov, Full test, FT of M1542, M1554, M1555, M1653 
M1542: Grade C due to massive (>1000pixels in total) trimming failures at -20C in ROC11,14,15. There was no such problem at previous test when CtrlReg=9
was used, while for the present test CtrlReg=17 was used
M1554: Grade C due to massive (>1000pixels in total) trimming failures at -20C in ROC9,13. There was no such problem at previous test when CtrlReg=9 was
    Reply  Wed Apr 22 17:41:11 2020, Andrey Starodumov, Full test, FT of M1542, M1554, M1555, M1653 
[quote="Andrey Starodumov"]
M1542: Grade C due to massive (>1000pixels in total) trimming failures at -20C in ROC11,14,15. There was no such problem at previous test when CtrlReg=9
was used, while for the present test CtrlReg=17 was used
    Reply  Thu Apr 23 13:34:52 2020, Andrey Starodumov, Full test, FT of M1542, M1554, M1555, M1653 
[quote="Andrey Starodumov"][quote="Andrey Starodumov"]
M1542: Grade C due to massive (>1000pixels in total) trimming failures at -20C in ROC11,14,15. There was no such problem at previous test when CtrlReg=9
was used, while for the present test CtrlReg=17 was used
Entry  Thu Apr 30 15:16:58 2020, Andrey Starodumov, Full test, FT of M1540, M1541, M1543, M1547 
Modules tested om April 29
M1540: Grade B due to many (>1000) pixels failed trimming but only 70 are in "C-zone" for ROC0 at -20C [COLOR=red]-> retest!!![/COLOR]
M1541: Grade B due to mean noise >200e for a few ROCs
Entry  Mon May 4 14:18:20 2020, Andrey Starodumov, Full test, FT of M1540, 1549, 1571, 1598 
M1540: Grade A
M1549: Grade B due to mean noise >200e for ROC2 and 48 dead pixels in ROC5
M1571: Grade B due to mean noise >200e for many ROCs 
Entry  Tue May 12 13:29:27 2020, Andrey Starodumov, Full test, FT of M1539, M1582, M1606 
M1539: Grade B due to mean noise >200e in few ROCs
M1582: Grade B due to mean noise >200e in few ROCs and at -20C 137 pixels in ROC1 failed trimming. For P5 could use older test results (trim parameters)
of April 27 M20_1 when only 23 pixels in ROC1 failed trimming
Entry  Wed Apr 29 14:08:42 2020, Andrey Starodumov, Full test, FT of M1536, M1537, M1538 
M1536: Grade B due to mean noise >200e for ROC1
M1537: Grade B due to mean noise >200e for a few ROCs
M1538: Grade B due to mean noise >200e for a few ROCs and trimming failure for 70 pixels in ROC14 at -20C
Entry  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.
Entry  Sun Feb 9 19:34:55 2020, Dinko Ferencek, Full test, FT for 4 modules: 1557, 1558, 1559, 1560  

[B]1557:[/B] [COLOR=red]C/C/C[/COLOR] (-20/-20/+10). Mean noise >200e for some ROCs, dead trimbits, failed trimming and mean noise >300e in ROC 4. IV:
0.20 uA at +10 C, slope 1.08
Entry  Sat Feb 8 20:48:11 2020, Dinko Ferencek, Full test, FT for 4 modules: 1550, 1551, 1552, 1553  M1553_C11_AddressDecoding.pdfTemperatureCycle.pdf

[B]1550:[/B] [COLOR=darkblue]B/B/B[/COLOR] (-20/-20/+10). Electrical grade is B due to mean noise >200e for some ROCs. IV: 0.45 uA at +10 C, slope 1.09
[B]1551:[/B] [COLOR=red]C/C/C[/COLOR] (-20/-20/+10). Mean noise >200e for some ROCs, dead trimbits in ROC 13, but trimmed Vcal threshold distribution and
Entry  Fri Feb 7 20:35:44 2020, Dinko Ferencek, Full test, FT for 4 modules: 1545, 1547, 1548, 1549 TemperatureCycle.pdf

[B]1545:[/B] [COLOR=red]C/C/C[/COLOR] (-20/-20/+10). Problematic ROC 14: mean noise >320e, many dead trimbits, wide trimmed Vcal threshold distribution.
IV: 0.20 uA at +10 C, slope 1.09
Entry  Sun Feb 9 10:52:17 2020, Dinko Ferencek, Full test, FT for 4 modules: 1539, 1554, 1555, 1556 

[B]1539:[/B] [COLOR=darkblue]B/B/B[/COLOR] (-20/-20/+10). Electrical grade is B due to mean noise >200e for some ROCs. IV: 0.17 uA at +10 C, slope 1.08
[B]1554:[/B] [COLOR=darkblue]B/B/B[/COLOR] (-20/-20/+10). Electrical grade is B due to mean noise >200e for some ROCs. IV: 0.44 uA at +10 C, slope 1.80
Entry  Fri Feb 14 09:48:27 2020, Dinko Ferencek, Full test, FT for 12 modules: 1561-1576 (1563, 1567, 1572, 1575 excluded) 
[COLOR=blue]Feb. 11[/COLOR]

[B]1561:[/B] [COLOR=red]C/[/COLOR][COLOR=darkblue]B/B[/COLOR] (-20/-20/+10). Mean noise >200e for some ROCs, dead trimbits in ROC 6, but trimmed Vcal threshold
Entry  Fri Nov 29 17:06:26 2019, Dinko Ferencek, General, Dropbox folder on CERNBox set up 
A dropbox folder for elComandante tar files was set up in my CERNBox and synchronized with the following local folder on the lab PC

/media/disk1/DATA/L1_DATA_Backup/CERNBox_Dropbox/
Entry  Sun Jul 5 13:20:55 2020, Dinko Ferencek, General, Disk cleanup on the lab PC (pc11366.psi.ch) pxar_junk_home.txt
Home folder was cleaned up by deleting old pXar output .log and .root files. The full list is in the attached file. This released around 11 GB of disk space.

In addition, the following MoReWeb output folders which are no longer needed were deleted
Entry  Mon Jan 18 13:53:44 2021, Andrey Starodumov, Other, DTB tests 
M2217
--->DTB 154 (one of the red cold box setup):
- flat cable (with HV):
Entry  Thu Sep 26 22:09:14 2019, Dinko Ferencek, Software, DAC configuration update 
In accordance with the agreement made in an email thread initiated by Danek, the following changes to DAC settings for ROCs

vsh: 30 -> 8
Entry  Thu May 7 00:27:41 2020, Dinko Ferencek, Module grading, Comment about TrimBitDifference and its impact on the Trim Bit Test 
To expand on the following [URL=https://elrond.irb.hr/elog/Layer+1+Replacement/253]elog[/URL], on Mar. 24 Andrey changed the TrimBitDifference parameter
in Analyse/Configuration/GradingParameters.cfg from 2 to -2
Entry  Fri Jun 5 16:22:19 2020, Andrey Starodumov, General, Cleaning L1_DATA directory 
To be able to analyse Xray data and keep Total Production overview in a proper state we need to clean L1_DATA directory.
Reasons:
1) if one analyse Xray test results with flag -new, then all deleted with -d flag tests will be analysed again and Total production overview will have
Entry  Wed Apr 8 15:02:37 2020, Andrey Starodumov, Software, Change of CrtlReg for RT 
So far in a blue box for RT tbm10d_procv3 parameters were used. 
This is wrong, since CtrlReg=9 is better for -20C while for +10 or higher T
CtrlReg=17 is better. 
Entry  Wed Mar 18 15:16:47 2020, Andrey Starodumov, Software, Change in trimmig algorithm 
Urs yesterday modified the algorithm and tested it. From today we are using it. Main change that threshold for trimming is not any more fixed to VthrComp=79
but calculated based on the bottom tornado value + 20. CalDel is also optimised. This allows us to avoid failures in the trimbit tests due to too high
threshold, eg if the bottom of tornado close to 70 a fraction of pixels in a chip could have threshold above 70 and hence fail in the test. 
Entry  Mon May 25 17:24:05 2020, Andrey Starodumov, Software, Change in MoreWeb ColumnUniformityPerColumn.py 
In file
~/L1_SW/MoReWeb/Analyse/TestResultClasses/CMSPixel/QualificationGroup/XRayHRQualification$ emacs Chips/Chip/ColumnUniformityPerColumn/ColumnUniformityPerColumn.py
the high and low rates at which double column uniformity is checked are hard coded. Rates for L2 was there. Now correction is added:
Entry  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)
Entry  Fri May 22 16:19:01 2020, Andrey Starodumov, Software, Change in MoreWeb GradingParameters.cfg 
Xray noise:
grade B moved from 300e to 400e
grade C moved from 400e to 500e
Entry  Wed Jul 29 17:19:43 2020, danek kotlinski, PhQualification, Change configuration for PH qialification 
Preparing the new PH optimization I had to make the following modifications:

1) in elCommandante.ini
Entry  Thu Apr 16 15:21:51 2020, Andrey Starodumov, Change TBM , Change TBMs on M1635, M1653, M1671 
M1635: no data from ROC8-ROC11 => change TBM1
M1653: ROC12-ROC15 not programmable => change TBM0
M1671: no data from ROC12-ROC15 => change TBM0
    Reply  Mon Apr 20 15:20:07 2020, Andrey Starodumov, Reception test, Change TBMs on M1635, M1653, M1671 
[quote="Andrey Starodumov"]M1635: no data from ROC8-ROC11 => change TBM1
M1653: ROC12-ROC15 not programmable => change TBM0
M1671: no data from ROC12-ROC15 => change TBM0
Entry  Thu Sep 26 21:48:56 2019, Dinko Ferencek, Module assembly, Cap gluing training 
Today I performed my first cap gluing. As an exercise it was first done on two dummy modules and later on a pre-production module M1522. Before the cap
gluing the module M1522 was visually inspected and a Reception test was run. Before the cap gluing everything looked fine. After the cap gluing the module
M15222 was again visually inspected and it looked like wire bonds in one of the corners might have been slightly bent and some glue got deposited on some
    Reply  Fri Sep 27 23:22:02 2019, Dinko Ferencek, Module assembly, Cap gluing training M1522_beforeGluing.pngM1522_afterGluing.pngM1522_diff.png
Attached are the bump bonding threshold maps before and after cap gluing and the (before - after) difference for M1522.
Entry  Mon Feb 24 14:01:29 2020, Urs Langenegger, Module assembly, Cap gluing in W8 
In week 8 the following modules were glued and tested: 

M1581
Entry  Tue Feb 4 19:51:10 2020, Dinko Ferencek, Module assembly, Cap gluing 
Today protective caps have been glued to modules 1545, 1547, 1548, 1549, and 1550.
Entry  Sun Feb 9 12:05:47 2020, Dinko Ferencek, Module assembly, Cap gluing 
Today protective caps have been glued to modules 1561 and 1562.
Entry  Thu Apr 2 17:10:08 2020, Andrey Starodumov, Other, Cap glued to M1618 
M1618 has been tested (FT ) on March 23 without a protection cap. 
I have no idea how it's happened...
Today cap is glued and module passed Reception test again and it's A.
Entry  Wed Nov 27 08:39:24 2019, Matej Roguljic, Cold box tests, Bump bonding test investigation 
The BB test on M1534 shows a lot of dead bunmps on C10 and some on C1 and C0 as well. Putting a source on top of the module shows that the pixels for which
the test showed dead bumps are still able to read hits from the source. Therefore, it looks like the bumps are working, but the test is reporting them
as defective. It turns out that the bumps used by Helsinki are different than the bumps used at PSI so a different test needs to be used. After trying
Entry  Tue Feb 4 19:52:22 2020, Dinko Ferencek, Cold box tests, Blue coldbox setup for reception tests commissioned 
Today I continued where Matej left off with commissioning the blue coldbox setup for reception tests. All the necessary software (pXar and elComandante)
Matej already installed (just had to add the BB2 section in testParameters.dat). What was a problem in communication with Keithley (Model 2400) which was
fixed after changing the BAUD rate in elComandante/keithleyClient/keithleyInterface.py to 19200 (value set in Keithley's communications settings) and changing
Entry  Wed Jan 22 11:39:48 2020, Dinko Ferencek, Software, BB2 configuration 
When attempting to run the FullQualification this morning, pXar crashed while running the BB2 test. After some investigation, we realized the source of
the problem was the BB2 configuration missing from testParameters.dat. The configuration is available in moreTestParameters.dat but by default the mkConfig
script does not put it in testParameters.dat. Since we run BB2 in the FullQualification, the configuration needs to be copied by hand every time the configuration
Entry  Tue Oct 29 16:36:23 2019, Matej Roguljic, Module assembly, Assembly lab cap gluing jigs IMG_20191029_150037.jpg
There are two jigs for cap gluing in the assembly lab, circled in red and blue on the photo in the attachment. The one closer to the door (red) we used
to build glue Phase 2 HDI to a dummy sensor and four Phase2 ROCs. Before changing the head, the numbers of the alignment screws were noted.
Entry  Fri May 22 16:06:43 2020, Andrey Starodumov, XRay HR tests, Analysis of HRT: M1623, M1632, M1634, M1636-M1639,M1640 
Module                HRtest                VCal calibration     Grade
           #defects      max #noisy pix
        ColdBox   XRay
Entry  Fri May 29 15:04:04 2020, Andrey Starodumov, XRay HR tests, Analysis of HRT: M1555-M1561 and M1564 
Module            HRtest                VCal calibration     Grade
          #defects        max #noisy pix
         ColdBox XRay 
Entry  Fri May 15 17:15:34 2020, Andrey Starodumov, XRay HR tests, Analysis of HRT: M1630, M1632, M1636, M1638 
Krunal proved test result of four modules and Dinko analised them.
M1630: Grade A, VCal calibration: Slope=43.5e-/Vcal, Offset=-145.4e- 
M1632: Grade A, VCal calibration: Slope=45.4e-/Vcal, Offset=-290.8e-
Entry  Fri Sep 27 22:24:31 2019, Dinko Ferencek, General, Activities on 27. 9. 2019. 
[LIST]
[*] Today Silvan wire bonded TBMs to the first batch of 8 new HDIs which were then tested. 5 out of 8 HDIs received a passing grade. Of the 3 failing HDIs,
2 had a spark occurring. The final testing results can be found in [URL=https://github.com/mroguljic/HDI_L1/blob/bb78cddaacc7488910aa26bbf609fcff3618c597/HDIresults.csv]https://github.com/mroguljic/HDI_L1/blob/bb78cddaacc7488910aa26bbf609fcff3618c597/HDIresults.csv[/URL].
Entry  Wed Aug 7 12:24:14 2019, Matej Roguljic, Documentation, Activities 31.7.-9.8.2019. 
31.7.

Matej tested 4 HDIs (8030-8033 and 8010). 8010 had a faulty TBM which was replaced, however, during subsequent tests, other TBM (the one which was working
Entry  Wed Oct 30 10:38:04 2019, Matej Roguljic, General, Activities 28.-31.10.2019. 
28.10. - Investigated a problem with the FullQualification setup, described more in this [URL=https://elrond.irb.hr/elog/Layer+1+Replacement/23]note[/URL]
29.10. - Further investigated the aforementioned problem and worked on preparing the jigs for Phase2 dummy module building.
30.10. - Confirmed that the reported issue is not present at the moment on the qualification system. Glued dummy sensor to four phase2 ROCs. Built a FC7
Entry  Thu Nov 28 15:58:20 2019, Matej Roguljic, General, Activities 26.-29.11.2019. 1-1.jpg1-2.jpg1-3.jpg1-4.jpg
26.11.

Prepared the tools for RD53A digital module assembly in the assembly lab
Entry  Thu Sep 26 17:38:07 2019, Matej Roguljic, General, Activities 25.-26.9. 
It was planned to test a batch of HDIs these 2 days but the shipment was late. Dinko and Andrei were shown the HDI testing procedure. Matej further worked
on the script used to test the HDIs. Dinko glued caps on 2 dummy modules and on M1522. New HDIs arrived on 26th and it looks like the kapton will have
to be put underneath them during the testing to prevent sparking.
Entry  Mon Jan 20 18:09:50 2020, Matej Roguljic, General, Activities 20.-31.01.2020. 
20.01.

Expanded the HDI testing setup to be able to mount wire-bonded HDIs to HDI handles. Tested 12 HDIs (v7.2), all of them passed the tests. HDIs were given
Entry  Tue Aug 6 15:15:00 2019, Matej Roguljic, General, Activities 19.6.-4.7.2019. 
17.6.-21.6.

Andrei and Matej were at PSI working on the cap gluing setup
Entry  Thu Sep 12 10:32:27 2019, Matej Roguljic, General, Activities 10.9.-19.9.2019. 
10.9.
Modules 1504,1505,1520 brought to PSI after irradiation to 1.2 MGy in Zagreb. All 3 were not working when put under test with pXar. 1504 and 1520 couldn't
set Vana at all. 1505 could set Vana, but timing couldn't be found and pixels weren't responding. Inspection under the microscope showed some "white-greenish"
    Reply  Thu Sep 19 14:20:07 2019, Matej Roguljic, General, Activities 10.9.-19.9.2019. 
[quote="Matej Roguljic"]10.9.
Modules 1504,1505,1520 brought to PSI after irradiation to 1.2 MGy in Zagreb. All 3 were not working when put under test with pXar. 1504 and 1520 couldn't
set Vana at all. 1505 could set Vana, but timing couldn't be found and pixels weren't responding. Inspection under the microscope showed some "white-greenish"
Entry  Tue May 19 13:43:55 2020, Andrey Starodumov, Module transfer, 9 modules shipped to PSI 
Quick check: Leakage current, set Vana, VthrCompCalDel and PixelAlive
Module    Current@-150V    Programmable     Readout
M1623    -0.335uA          OK               OK
Entry  Wed Feb 12 10:43:04 2020, Dinko Ferencek, Module transfer, 9 modules sent to ETH: 1539, 1545, 1547, 1548, 1549, 1550, 1551, 1552, 1553 
Yesterday the following modules were sent to ETH:
1539, 1545, 1547, 1548, 1549, 1550, 1551, 1552, 1553
Entry  Thu May 28 14:40:57 2020, Andrey Starodumov, Module transfer, 8 modules shipped to PSI 
Quick check: Leakage current, set Vana, VthrCompCalDel and PixelAlive
Module Current@-150V Programmable Readout
[COLOR=red]M1555 -6.000uA          OK          OK Current is rising up to 11uA with time after PixelAlive is done at +22C !!![/COLOR]
Entry  Mon May 18 14:05:01 2020, Andrey Starodumov, Module transfer, 8 modules shipped to ETHZ 
M1555, M1556, M1557, 
M1558, M1559, M1560,
M1561, M1564
Entry  Tue Mar 24 15:16:56 2020, Andrey Starodumov, HDI test, 8 HDIs tested on Mar 23 
1014, 1016, 2001, 2003, 
2004, 4013, 4015, 5014
All are good.
Entry  Mon Apr 6 17:07:23 2020, Andrey Starodumov, HDI test, 8 HDIs tested 
HDIs
4937 5043 5042 4040
2029 4019 4018 4017
Entry  Wed Mar 11 17:22:57 2020, Matej Roguljic, HDI test, 8 HDI tests on 11.3. 
I tested 8 HDIs today: 5029,5030,5031,6034,6036,6035,1031 and 1032
All of them tested fine.
Entry  Tue Feb 4 19:35:38 2020, Dinko Ferencek, Module transfer, 7 modules prepared for transfer to ETH: 1536, 1537, 1538, 1540, 1541, 1542, 1543 
The following modules have been prepared today for transport to ETH for x-ray qualification:
1536, 1537, 1538, 1540, 1541, 1542, 1543
Entry  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
Entry  Thu Apr 2 17:08:03 2020, Andrey Starodumov, HDI test, 6 HDIs tested 
3013, 1046, 1047, 1048, 5038, 5039 are tested. All are OK.
Entry  Tue Apr 7 17:59:27 2020, Andrey Starodumov, HDI test, 6 HDIs tested 
HDIs
2030, 2031, 1021, 1022, 1023, 1035 
are tested. All OK.
Entry  Mon Feb 3 15:53:32 2020, Andrey Starodumov, Reception test, 5 modules RT: 1545, 1547, 1548, 1549, 1550 
[COLOR=blue]Feb 03[/COLOR]
- RT is done and OK for all modules. All 5 modules graded [COLOR=darkgreen]A[/COLOR].
Entry  Thu Mar 12 12:19:43 2020, Matej Roguljic, HDI test, 5 HDI tests on 12.3. 
I tested 5 HDIs on 12.3. 1030,1029,1040,1039 and 1038. 1039 failed all the electrical tests. All the others passed the tests. HDI 1038 has one wirebond
which is connected to the pad on the HDI and then it extends back up (like this: TBM./\.HDI/). The connection is good, but I just want to check with Silvan
later if this is a problem.
Entry  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.
Entry  Mon Feb 3 15:35:09 2020, Anrey Starodumov, Full test, 4 modules FT: 1539, 1541,1542, 1543 1542ROC13-TrThr.pdf
[COLOR=blue]Jan 29[/COLOR] 
- Reception test for 1539 OK
- Cap gluing
Entry  Mon Feb 3 11:28:38 2020, Anrey Starodumov, Full test, 4 modules FT: 1536, 1537,1538, 1540 1537ROC10m20-TrThr.pdf
[COLOR=blue]Jan 28[/COLOR]: Reception test for 1536, 1537, 1538 OK
Then cap gluing
[COLOR=blue]Jan 29[/COLOR]
Entry  Mon Dec 2 17:29:06 2019, Andrey Starodumov, Full test, 4 modules FT 
FullQualification of four modules M1526, M1529, M1521 and M1534 has been done. Full time of the test is about 5.5hrs.
Test included: FT@-20C, IV@-20, 3Cycles from -20C up to +10C, FT@10C and IV@10C.
Only M1521 passed the test (Grade B). Several issues observed in other modules:
    Reply  Tue Dec 3 12:15:54 2019, Andrey Starodumov, Full test, 4 modules FT M1526ATm20.pngM1526ATp10.png
[quote="Andrey Starodumov"]FullQualification of four modules M1526, M1529, M1521 and M1534 has been done. Full time of the test is about 5.5hrs.
Test included: FT@-20C, IV@-20, 3Cycles from -20C up to +10C, FT@10C and IV@10C.
Only M1521 passed the test (Grade B). Several issues observed in other modules:
Entry  Fri Mar 27 18:28:34 2020, Andrey Starodumov, Full test, 4 HDIs tested 
HDIs 5020, 5018, 1044 and 1041 are OK
Entry  Mon Apr 20 17:09:12 2020, Andrey Starodumov, HDI test, 4 HDIs tested 
After staying in 90%+ RH 2 HDIs became flat. The first one was easy to mount on an HDI holder.
But after 1-2hrs the second HDI became bent again, but still remained flexible, so was also easy to mount.
I put 2 more HDIs in the same conditions and after 2 hrs was able to mount and test them.
Entry  Thu Apr 23 18:01:16 2020, Andrey Starodumov, HDI test, 4 HDIs tested 
The following HDIs are tested:
6007: OK
1034: Failed due to not working Channel 1 in CLK0, CTR0, SDA0 and SDA1
Entry  Thu Apr 9 17:43:54 2020, Andrey Starodumov, HDI test, 4 HDIa tested 
HDIs 3029, 3031, 3032, 4042 passed tests. All OK.
Entry  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.
Entry  Fri Mar 20 18:09:47 2020, Andrey Starodumov, HDI test, 3 HDIs tested 
5008 failed, but most likely die to the pin head mis-alignment. Test to be repeated.
5007 and 5008: passed tests but during HV measurements (-800V) with a multymeter I heard high frequency noise and instead of -800V measure either -100V
or -500V but the voltage jumped significantly. This effect is to be understood. 
Entry  Fri Apr 24 13:56:11 2020, Andrey Starodumov, HDI test, 3 HDIs tested 
Following HDIs tested from the box "to be understood":
5021, 3019, 5008. All are fine.
Entry  Mon Apr 27 14:21:17 2020, Andrey Starodumov, HDI test, 3 HDIs tested 
# remaining HDIs from "to be understood" box were tested after flattening them during weekend in RH=99.9% box.
6024, 4034 are OK
1039 bad: no data from A1 and A2 DTB outputs, flat output
Entry  Tue Mar 31 18:14:47 2020, Andrey Starodumov, HDI test, 3 HDI tested 
HDIs: 1027, 5002, 5003 are tested. All OK.
Entry  Mon Feb 3 17:09:36 2020, Andrey Starodumov, Reception test, 2 modules RT failed: 1544, 1546 
[COLOR=blue]Feb 03[/COLOR]
- RT failed
-- 1544: 
Entry  Fri Apr 3 18:06:11 2020, Andrey Starodumov, HDI test, 2 HDIs tested 
HDIs 6018 and 6019 are passed tests.
Entry  Thu Jun 4 15:32:50 2020, Andrey Starodumov, Module transfer, 18 Modules shipped to PSI 
Quick check: Leakage current, set Vana, VthrCompCalDel and PixelAlive
T=+24C
Entry  Thu May 28 14:38:43 2020, Andrey Starodumov, Module transfer, 18 Modules shipped to ETHZ 
1536, 1537, 1539, 1540, 1541,
1543, 1545, 1547, 1548, 1550,
1551, 1552, 1553, 1554, 1565,
Entry  Mon May 11 21:41:15 2020, Dinko Ferencek, Software, 17 to 10 C changes in the production overview page 
[URL=https://gitlab.cern.ch/CMS-IRB/MoReWeb/-/commit/0c513ab8de39460ed793ef71c21b65becd4fccb9]0c513ab8[/URL]: a few more updates on the main production
overview page related to the 17 to 10 C change 
Entry  Wed Apr 22 17:28:42 2020, Andrey Starodumov, HDI test, 11 HDIs tested 
After keeping HDIs in a very high RH for a dew hours (24 is fine) became flat and could be fixed on HDI holder by vacuum.
11 HDIs were tested, all good:
3036, 3043, 3034, 3044, 1034, 6006, 6007, 6005,
Entry  Mon Oct 28 17:01:05 2019, Matej Roguljic, Software, Investigating the bug with the Keithley client 
We took module 1529 and tried recreating the issue observed in the beginning of October. To do this in a reasonable amount of time, a "shorttest" procedure
was defined which consists only of pretest and pixelalive. Three runs were taken
    Reply  Tue Oct 29 16:38:32 2019, Matej Roguljic, Software, Investigating the bug with the Keithley client 
[quote="Matej Roguljic"]We took module 1529 and tried recreating the issue observed in the beginning of October. To do this in a reasonable amount of time,
a "shorttest" procedure was defined which consists only of pretest and pixelalive. Three runs were taken
    Reply  Wed Oct 30 16:54:58 2019, Matej Roguljic, Software, Investigating the bug with the Keithley client 
[quote="Matej Roguljic"][quote="Matej Roguljic"]We took module 1529 and tried recreating the issue observed in the beginning of October. To do this in a
reasonable amount of time, a "shorttest" procedure was defined which consists only of pretest and pixelalive. Three runs were taken
Entry  Thu Mar 12 17:21:59 2020, Matej Roguljic, Full test, Fulltests on 2020/03/12  
Modules tested:
M1557 C (trim bits at -20)
M1558 C (gain at -20)
Goto page 1, 2, 3 ... 14, 15, 16  
ELOG V3.1.3-7933898