CMS Pixel Detector Miscellaneous

Phase 1 Phase 2

Layer 1 Replacement Layers 2-4

Layer 1 Replacement Elog, Page 1 of 13  Not logged in

Find |  Login |  Help

Full | Summary | Threaded | Collapse | Expand     -- All entries -- Last day Last 3 Days Last week Last month Last 3 Months Last 6 Months Last Year Error: Attribute "Type" for quick filter not found  256 Entries

Goto page 1, 2, 3 ... 11, 12, 13   Next  All

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)       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/          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       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/.          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.   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):   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    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   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.   Fri Aug 28 14:07:24 2020, Andrey Starodumov, PhQualification, M1539  There is no new PH optimisation for this module?! To be checked!   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???   Fri Aug 28 11:53:23 2020, Andrey Starodumov, PhQualification, M1555  There is no new PH optimisation for this module?! To be checked!   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!   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.   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   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   Sun Jul 5 13:20:55 2020, Dinko Ferencek, General, Disk cleanup on the lab PC (pc11366.psi.ch)  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   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   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   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:   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        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/   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   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   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.   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   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       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/   Fri May 29 15:41:40 2020, Andrey Starodumov, General, M1546  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.   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    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   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]   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,   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   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       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/   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:   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   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   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   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   Mon May 18 14:05:01 2020, Andrey Starodumov, Module transfer, 8 modules shipped to ETHZ  M1555, M1556, M1557,  M1558, M1559, M1560, M1561, M1564   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-   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].       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]   Wed May 13 17:57:45 2020, Andrey Starodumov, Other, L1_DATA backup  L1_DATA files are backed up to the LaCie disk   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   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    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   Mon May 11 14:40:16 2020, danek kotlinski, Other, M1582  On Friday I have tested the module M1582 at room temperature in the blue box. The report in MoreWeb says that this module has problems with trimming 190 pixels in ROC1.   Mon May 11 14:14:05 2020, danek kotlinski, Other, M1606  On Friday I have tested M1606 at room temperature in the red cold box. Previously it was reported that trimming does not work for ROC2.   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:   Thu May 7 01:51:03 2020, Dinko Ferencek, Software, Strange bug/feature affecting Pixel Defects info in the Production Overview page  It was observed that sometimes the Pixel Defects info in the Production Overview page is missing [IMG]elog:256/1[/IMG]   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]   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   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.        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.        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.           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.    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   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]   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   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.   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    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   Fri May 1 19:34:01 2020, danek kotlinski, Module grading, M1582  M1582 was classified as C because of 167 pixels failing trimming in ROC1. I have tested this module. The attached plots show the 1d & 2d threshold distributions.   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.   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   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   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   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   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   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   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   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   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   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   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   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.   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   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   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   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       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          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   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,   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   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.   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       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   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)   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   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       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   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   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   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   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   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.   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   Thu Apr 9 17:43:54 2020, Andrey Starodumov, HDI test, 4 HDIa tested  HDIs 3029, 3031, 3032, 4042 passed tests. All OK.   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   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!   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.       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.   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.   Thu Apr 9 14:36:10 2020, Andrey Starodumov, Reception test, RT of M1669 and M1670  Both modules graded A.   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.       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]   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   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.   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.    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.    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.   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.   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.   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   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]:    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   Mon Apr 6 17:07:23 2020, Andrey Starodumov, HDI test, 8 HDIs tested  HDIs 4937 5043 5042 4040 2029 4019 4018 4017   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)"   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.   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.   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.       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.          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.   Fri Apr 3 18:06:11 2020, Andrey Starodumov, HDI test, 2 HDIs tested  HDIs 6018 and 6019 are passed tests.   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.   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   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       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   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:   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       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   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!   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.   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.   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.   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   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       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   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!    Tue Mar 31 18:14:47 2020, Andrey Starodumov, HDI test, 3 HDI tested  HDIs: 1027, 5002, 5003 are tested. All OK.   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)        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)    Tue Mar 31 17:32:47 2020, Andrey Starodumov, Reception test, RT of M1641-M1644  All modules graded A.   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()   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.   Tue Mar 31 06:54:12 2020, danek kotlinski, Module grading, M1542  I have tested M1542. It looks not bad but there is a group of pixels in the lower/left corner of ROC6 which behave different. One can also see that something is not right in some PH optimisation plots.   Mon Mar 30 17:49:31 2020, Andrey Starodumov, Reception test, RT of M1637-1640  All modules: M1637, M1638, M1639, M1649, are graded A.     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.   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   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.       Mon Mar 30 14:52:59 2020, Danek Kotlinski, Full test, FT of M1629, M1630, M1631, M1632  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.       Mon Mar 30 15:40:52 2020, Urs, Full test, FT of M1629, M1630, M1631, M1632  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.    Sun Mar 29 18:14:59 2020, danek kotlinski, Other, Modules 1544 & 1563 in gelpack  The 2 bad modules: M1544 M1563    Fri Mar 27 18:28:34 2020, Andrey Starodumov, Full test, 4 HDIs tested  HDIs 5020, 5018, 1044 and 1041 are OK   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   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*       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*   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   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   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.   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   Thu Mar 26 17:41:52 2020, Andrey Starodumov, Reception test, RT of M1629-1632  All modules M1629, M1630, M1631 and M1632 graded A   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.       Thu Mar 26 15:37:18 2020, Urs, Module grading, M1606  attached find the threshold difference distributions for all four trimbits for all ROCs   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*   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   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       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   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.   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       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   Wed Mar 25 14:44:37 2020, Andrey Starodumov, Reception test, RT of M1627 and M1628  Both modules graded A.   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.   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   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.   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.   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)   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.    Tue Mar 24 15:18:59 2020, Andrey Starodumov, Reception test, M1621 failed Reception  On M1621 ROC8 is not programmable.   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.   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!       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]   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!       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]   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.       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]   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   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.    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.   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.   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.    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   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.   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.    Mon Mar 16 15:20:03 2020, Matej Roguljic, PhQualification, PhQualification on 16.3.  PhQualification was run on modules M1561, M1564, M1565, M1566.    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.   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   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   Sat Mar 14 17:08:14 2020, Matej Roguljic, Full test, Fulltests on 2020/03/13  Modules tested: M1591 C (gain at -20)   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)   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.   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"   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.   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   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       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.    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]   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).       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).   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.   Mon Mar 2 17:39:36 2020, Urs Langenegger, Full test, Fulltests on 2020/03/02  Modules tested:  M1595 C M1596 B   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?)   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.   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   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:   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.    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   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:    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]   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]).   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   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   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)   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]   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   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]   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   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   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:   Sun Feb 9 12:05:47 2020, Dinko Ferencek, Module assembly, Cap gluing  Today protective caps have been glued to modules 1561 and 1562.   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   Sat Feb 8 20:48:11 2020, Dinko Ferencek, Full test, FT for 4 modules: 1550, 1551, 1552, 1553   [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   Fri Feb 7 20:35:44 2020, Dinko Ferencek, Full test, FT for 4 modules: 1545, 1547, 1548, 1549  [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   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   Thu Feb 6 00:45:25 2020, Dinko Ferencek, Cold box tests, Lost at least one Peltier in the coldbox  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       Thu Feb 6 17:28:23 2020, Dinko Ferencek, Cold box tests, New Peltiers installed  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   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]   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.   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.   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.   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   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.   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   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:    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].   Mon Feb 3 15:35:09 2020, Anrey Starodumov, Full test, 4 modules FT: 1539, 1541,1542, 1543  [COLOR=blue]Jan 29[/COLOR]  - Reception test for 1539 OK - Cap gluing   Mon Feb 3 11:28:38 2020, Anrey Starodumov, Full test, 4 modules FT: 1536, 1537,1538, 1540  [COLOR=blue]Jan 28[/COLOR]: Reception test for 1536, 1537, 1538 OK Then cap gluing [COLOR=blue]Jan 29[/COLOR]   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.   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   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]   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.   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]   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/   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   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/   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   Mon Jan 20 21:33:20 2020, Dinko Ferencek, Cold box tests, Latest tests of PH optimization  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.       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.   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   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       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          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   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:       Tue Dec 3 12:15:54 2019, Andrey Starodumov, Full test, 4 modules FT  [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:   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/   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   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'.       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   Thu Nov 28 15:58:20 2019, Matej Roguljic, General, Activities 26.-29.11.2019.  26.11. Prepared the tools for RD53A digital module assembly in the assembly lab   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   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.    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.    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   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       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          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   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   Tue Oct 29 16:36:23 2019, Matej Roguljic, Module assembly, Assembly lab cap gluing jigs  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.   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]       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.   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   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       Fri Sep 27 23:22:02 2019, Dinko Ferencek, Module assembly, Cap gluing training  Attached are the bump bonding threshold maps before and after cap gluing and the (before - after) difference for M1522.   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].   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   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.   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.   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"       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"   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       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.          Thu Sep 19 00:52:24 2019, Dinko Ferencek, Other, Modules 1504, 1505, 1520 irradiation report  [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.   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.   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   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   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.   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.   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".   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   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

Goto page 1, 2, 3 ... 11, 12, 13   Next  All

ELOG V3.1.3-7933898