CMS Pixel Detector Miscellaneous
Phase 1 Phase 2
Layer 1 Replacement Layers 2-4
  Layer 1 Replacement Elog, Page 2 of 13  Not logged in ELOG logo
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

Module Current@-150V Programmable Readout

M1569 -0.690uA OK OK
M1568 -0.530uA OK OK
M1566 -1.530uA OK OK
M1565 -1.430uA OK OK
M1554 -0.970uA OK OK
M1553 -1.300uA OK OK
M1552 -0.919uA OK OK
M1551 -1.310uA OK OK
M1550 -1.708uA OK OK
M1548 -0.470uA OK OK
M1547 -1.510uA OK OK
M1545 -0.770uA OK OK
M1543 -0.800uA OK OK
M1541 -0.750uA OK OK
M1540 -1.440uA OK OK
M1539 -0.680uA OK OK
M1537 -0.816uA OK OK
M1536 -4.270uA OK OK
Entry  Fri May 29 15:56:27 2020, Andrey Starodumov, FTs for ETHZ, Module list2 
green: correct in Total production overview
black: to remove old entries/rows
red: many failures at one or both temperatures

M1538: m20_1 and p10_1 of 2020-04-29
M1546: m20_1 and p10_1 of 2020-04-02
M1549: m20_1 and p10_1 of 2020-05-04
M1557: m20_1 and p10_1 of 2020-04-23
M1570: m20_1 and p10_1 of 2020-04-24
M1571: m20_1 and p10_1 of 2020-05-04
M1572: m20_1 and p10_1 of 2020-04-08
M1573: m20_1 and p10_1 of 2020-04-24
M1574: m20_1 and p10_1 of 2020-05-05
M1576: m20_1 and p10_1 of 2020-04-24
M1577: m20_1 and p10_1 of 2020-04-24
M1578: m20_1 and p10_1 of 2020-04-27
M1579: m20_1 and p10_1 of 2020-04-27
M1580: m20_1 and p10_1 of 2020-04-27
M1581: m20_1 and p10_1 of 2020-05-05
M1582: m20_1 of 2020-04-27 and p10_1 of 2020-05-11
M1583: m20_1 and p10_1 of 2020-04-27
M1584: m20_1 and p10_1 of 2020-04-27
M1585: m20_1 and p10_1 of 2020-04-27
M1586: m20_1 and p10_1 of 2020-04-28
M1587: m20_1 and p10_1 of 2020-04-28
M1588: m20_1 and p10_1 of 2020-04-28
M1589: m20_1 and p10_1 of 2020-04-28
M1590: m20_1 and p10_1 of 2020-04-28
M1591: m20_1 and p10_1 of 2020-04-03
M1592: m20_1 and p10_1 of 2020-04-28
M1593: m20_1 and p10_1 of 2020-04-07 NOT shipped to ETHZ
M1595: m20_1 and p10_1 of 2020-05-06
    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/
rsync -avPSh --no-r --include="M1546_FullQualification_2020-04-02*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1549_FullQualification_2020-05-04*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1557_FullQualification_2020-04-23*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1570_FullQualification_2020-04-24*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1571_FullQualification_2020-05-04*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1572_FullQualification_2020-04-08*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1573_FullQualification_2020-04-24*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1574_FullQualification_2020-05-05*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1576_FullQualification_2020-04-24*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1577_FullQualification_2020-04-24*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1578_FullQualification_2020-04-27*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1579_FullQualification_2020-04-27*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1580_FullQualification_2020-04-27*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1581_FullQualification_2020-05-05*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1582_FullQualification_2020-05-11*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1583_FullQualification_2020-04-27*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1584_FullQualification_2020-04-27*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1585_FullQualification_2020-04-27*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1586_FullQualification_2020-04-28*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1587_FullQualification_2020-04-28*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1588_FullQualification_2020-04-28*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1589_FullQualification_2020-04-28*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1590_FullQualification_2020-04-28*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1591_FullQualification_2020-04-03*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1592_FullQualification_2020-04-28*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1593_FullQualification_2020-04-07*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1595_FullQualification_2020-05-06*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
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.
It has been checked that using trimming parameters VCal threshold distribution is fine (checked at +20C). See plots attached:

VCal threshold distribution in p10_1 test:

Trim bits distribution in p10_1 test:

VCal threshold distribution taken with trim parameters at +20C:
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
M1555: 24 44 375 44xVcal-388e- A
M1556: 54 74 507 43xVcal-370e- B
M1557: 109 63 145 43xVcal-216e- A
M1558: 127 113 103 44xVcal-145e- B
M1559: 69 59 92 46xVcal-119e- A
M1560: 35 54 66 46xVcal-123e- A
M1561: 33 44 129 45xVcal-244e- A
M1564: 26 36 93 47xVcal- 29e- A
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
copied to ~/L1_DATA/M1630_FullQualification_2020-04-06_08h35m_1586154934/005_Fulltest_p10
and original files from ~/L1_DATA/M1630_FullQualification_2020-04-06_08h35m_1586154934/005_Fulltest_p10
copied to ~/L1_DATA/ExtraTests_ToBeKept/p10RemovedFrom_M1630_FullQualification_2020-04-06_08h35m_1586154934/005_Fulltest_p10
This is done to have a clean ranking of modules based on # of defects.
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
M1555 -6.000uA OK OK Current is rising up to 11uA with time after PixelAlive is done at +22C !!!
M1556 -1.282uA OK OK
M1557 -0.600uA OK OK
M1558 -0.835uA OK OK
M1559 -0.930uA OK OK
M1560 -0.745uA OK OK
M1561 -0.770uA OK OK
M1564 -1.755uA OK OK
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,
1566, 1568, 1569
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

rsync -avPSh --include="M????_*.tar" --include="WebOutput/***" --exclude="*" /home/l_tester/L1_DATA/ /media/l_tester/LaCie/L1_DATA/

It was discovered that /home/l_tester/L1_DATA/WebOutput/ was by mistake duplicated inside /media/l_tester/LaCie/L1_DATA/WebOutput/ However, this could still not explain the full disk.

The size of the tar files looked fine but /media/l_tester/LaCie/L1_DATA/WebOutput/ was 1.8 TB in size while /home/l_tester/L1_DATA/WebOutput/ was taking up only 50 GB and apart from the above-mentioned duplication, there was no other obvious duplication.

It turned out the file system on the external hard disk had a block size of 512 KB which is unusually large. This is typically set to 4 KB. In practice this meant that every file (and even folder), no matter how small, always occupied at least 512 KB on the disk. For example, I saw the following

l_tester@pc11366:~$ cd /media/l_tester/LaCie/
l_tester@pc11366:/media/l_tester/LaCie$ du -hs Warranty.pdf
512K Warranty.pdf
l_tester@pc11366:/media/l_tester/LaCie$ du -hs --apparent-size Warranty.pdf
94K Warranty.pdf

And in a case like ours, where there are a lot of subfolders and files, many of whom are small, a lot of disk space is effectively wasted.

The file system used on the external disk was exFAT. According to this page, the default block size (in the page they call it the cluster size) for the exFAT file system scales with the drive size and this is the likely reason why the size of 512 KB was used (however, 512 KB is still larger than the largest block size used by default). The main partition on the external disk was finally reformatted as follows

sudo mkfs.exfat -n LaCie -s 8 /dev/sdd2

which set the block size to 4 KB.
Entry  Fri May 22 17:09:37 2020, Andrey Starodumov, FTs for ETHZ, Module list1 
green: correct in Total production overview
black: to remove old entries/raws
red: many failures at one or both temperatures

M1536: M20_1 and p10_1 of 2020-04-29
M1537: m20_1 and p10_1 of 2020-04-29

M1538: 149 defects, retest at m20?
M1539: m20_1 and p10_1 of 2020-05-11
M1540: M20_1 and p10_1 of 2020-05-04
M1541: m20_1 and p10_1 of 2020-04-29
M1542: m20_1 and p10_1 of 2020-04-22
M1543: m20_1 and p10_1 of 2020-04-29
M1545: m20_1 and p10_1 of 2020-03-26
M1546: 167 defects, retest at p10?
M1547: m20_1 and p10_1 of 2020-04-29
M1548: m20_1 and p10_1 of 2020-04-30
M1549: 196 defects, retest at m20?
M1550: m20_1 and p10_1 of 2020-04-30
M1551: m20_1 and p10_1 of 2020-04-30
M1552: m20_1 and p10_1 of 2020-04-30
M1553: m20_1 and p10_1 of 2020-04-30
M1554: m20_1 and p10_1 of 2020-04-22
M1555: m20_1 and p10_1 of 2020-04-22
M1556: m20_1 and p10_1 of 2020-04-23

M1557: to be checked on May27 at -20C: run Vcal Scurves for trimmed to VCal=50 module and with -10 to VthrComp value to check failed 61 pixels on ROC4
....................
M1565: m20_1 and p10_1 of 2020-04-23
M1566: m20_1 and p10_1 of 2020-04-23
M1568: m20_1 and p10_1 of 2020-04-24
M1569: m20_1 and p10_1 of 2020-04-24
    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/
rsync -avPSh --no-r --include="M1537_FullQualification_2020-04-29*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1539_FullQualification_2020-05-11*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1540_FullQualification_2020-05-04*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1541_FullQualification_2020-04-29*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1542_FullQualification_2020-04-22*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1543_FullQualification_2020-04-29*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1545_FullQualification_2020-03-26*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1547_FullQualification_2020-04-29*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1548_FullQualification_2020-04-30*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1550_FullQualification_2020-04-30*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1551_FullQualification_2020-04-30*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1552_FullQualification_2020-04-30*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1553_FullQualification_2020-04-30*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1554_FullQualification_2020-04-22*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1565_FullQualification_2020-04-23*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1566_FullQualification_2020-04-23*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1568_FullQualification_2020-04-24*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
rsync -avPSh --no-r --include="M1569_FullQualification_2020-04-24*.tar" --exclude="*" /home/l_tester/L1_DATA/* /home/l_tester/DATA/L1_DATA_Backup/CERNBox_Dropbox/
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:
# Layer2 settings
# HitRateHigh = 150
# HitRateLow = 50
# Layer1 settings
HitRateHigh = 250
HitRateLow = 150
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 modules (likely depending on a module position with respect to Xray beam spot) the measured rate was smaller than 300MHz/cm2 that is target rate. Somtimes extrapolation of efficiency curve to 300MHz/cm2 is too large. I think this is not correct. Unfortunately higher rates cause too many readout errors that prevent a proper measurement of the hit efficiency. May be a new DTB with than 1.2A maximum digital current will help.
3.
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  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
M1623 130 151 91 45xVCal-67e- B
M1630 80 1 385 43xVcal-290e- A
M1632 14 9 124 45xVcal-145e- A
M1634 33 81 339 43xVcal-347e- B
M1636 10 14 109 46xVcal-255e- A
M1637 71 45 175 45xVcal-182e- A
M1638 12 95 269 43xVcal-183e- B
M1639 21 96 482 43xVcal-441e- B
M1640 30 22 115 44xVcal-134e- A
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
M1630 -0.430uA OK OK
M1632 -0.854uA OK OK
M1634 -0.243uA OK OK
M1636 -0.962uA OK OK
M1637 -0.452uA OK OK
M1638 -0.440uA OK OK
M1639 -0.760uA OK OK
M1640 -0.354uA OK OK
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  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-
M1636: Grade A, VCal calibration: Slope=45.9e-/Vcal, Offset=-255.2e-
M1638: Grade A, VCal calibration: Slope=43.3e-/Vcal, Offset=-183.1e-

A few comments:
1) Rates. One should distinguish X-rays rate and the hit rate seen/measured by a ROC (as correctly Maren mentioned).
X-rays rate vs tube current has been calibrated and the histogramm titles roughly reflect the X-rays rate. One could notice that
number of hits per pixel, again roughly, scaled with the X-rays rate (histo title)
2) M1638 ROC7 and ROC10 show that we see new pixel failures that were not observed in cold box tests. In this case it's not critical, since only
65/25 pixels are not responcive already at lowest rate. But we may have cases with more not responcive pixels.
3) M1638 ROC0: number of defects in cold box test is 3 but with Xrays in the summary table it's only 1. At the same time if one looks at ROC0
summary page in all Efficiency Maps and even in Hit Maps one could see 3 not responcive pixels. We should check in MoreWeb why it's so.
4) It's not critical but it would be good to understand why "col uniformity ratio" histogramm is not filled properly. This check has been introduced
to identify cases when a column performace degrades with hit rate.
5) PROCV4 is not so noisy as PROCV2, but nevertheless I think we should introduce a proper cut on a pixel noise value and activate grading on
the total number of noisy pixels in a ROC (in MoreWeb). For a given threshold and acceptable noise rate one can calculate, pixels with noise
above which level should be counted as defective.
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 elog, double-counting of pixel defects in the production overview page was fixed in 3a2c6772.
    Reply  Wed May 13 23:16:37 2020, Dinko Ferencek, Software, Fixed double-counting of pixel defects in the production overview page 

Dinko Ferencek wrote:
As a follow-up to this elog, double-counting of pixel defects in the production overview page was fixed in 3a2c6772.


A few extra adjustments were made in:

38eaa5d6: also removed double-counting of pixel defects in module maps in the production overview page
51aadbd7: adjusted the trimmed threshold selection to the L1 replacement conditions
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  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
M1606: Grade C due to 161 pixels failed trimming in ROC2 and total # of defects in this ROC 169. For P5 could use older test results (trim parameters) of March 19 M20_2 when only 36 pixels in ROC2 failed trimming or April 6 when 40 pixels failed (at all T this test has the best performance).
Entry  Mon May 11 21:41:15 2020, Dinko Ferencek, Software, 17 to 10 C changes in the production overview page 
0c513ab8: a few more updates on the main production overview page related to the 17 to 10 C change
ELOG V3.1.3-7933898