 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.
I see not problem in ROC1. The average threshold is 50 with rms=1.37. Only 1 pixel is in the 0 bin.
See the attached 1d and 2d plots.
Also the PH looks good. The vcal 70 PH map is reconstructed at vcal 70.3 with rms of 3.9.
5159 pixels have valid gain calibrations.
I conclude that this module is fine.
Maybe it is again a DTB problem, as reported by Andrey.
D. |
|
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.
With this feature one can run pixel alive but trimming fails completely for roc 2.
The only way to trim the module is to disable the whole roc 2.
Since it seems to me that we will never want to use this module in the detector
I have given it to Jory to be used in the DESY test beam.
She already has 2-3 module from the pre-production, so with older versions of HDIs & ROCs.
I have also looked at 2 other modules which were classified as C 1557 and 1558.
Both look fine to me but I have not run the PH optimization on them.
D. |
|
Fri Aug 28 11:53:23 2020, Andrey Starodumov, PhQualification, M1555
|
There is no new PH optimisation for this module?!
To be checked! |
|
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.
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:
 |
|
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.
See the attached plot.
We should probably leave this module as grade C+.
D. |
|
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
- reconnecting the cable to the MOLEX on the module |
|
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:
TB1: M1539
TB3: M1606 |
|
Fri Aug 28 14:07:24 2020, Andrey Starodumov, PhQualification, M1539
|
There is no new PH optimisation for this module?!
To be checked! |
|
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.
To be understood:
1) why SCurves results (noise) empty?
2) why the number of ROCs with defects always -1?
|
|
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 it looked like at least one Peltier stopped working.
Silvan took apart the coldbox and will install new Peltiers. Based on measurements Andrey did with the old Peltiers it indeed looks like one Peltier stopped working but the remaining 3 also appear to be at different stages of degradation. |
|
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
I put them in the box called "For Wolfram ...." on the Wolfram's desk in the lab.
Nevertheless, I think this is an artificial issue that mmight be caused by a cable. I retested 5006, 5007 and 2005 with a new
cable and in all cases measured HV=790V what is normal. |
|
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.
We also noticed a change in the threshold distribution plot of the latest trim bit test compared to the previous version of the test (see attached plots). |
 Tue Jan 21 12:19:08 2020, Dinko Ferencek, Cold box tests, Latest tests of PH optimization
|
| Dinko Ferencek wrote: | 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.
We also noticed a change in the threshold distribution plot of the latest trim bit test compared to the previous version of the test (see attached plots). |
The problem was traced down to a wrong value of the vcallow parameter in the PH optimization configuration. The value was 10 instead of 50 expected by the test. It turned out that the optimization converged for M1521 because this is a PROC600V3 module for which the configuration files were regenerated for another reason and vcallow was consequently set to the right value of 50. The other 3 modules are PROC600V4 modules and for them old configuration files with a wrong vcallow value were used. |
|
Wed May 13 17:57:45 2020, Andrey Starodumov, Other, L1_DATA backup
|
| L1_DATA files are backed up to the LaCie disk |
|
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
http://cms.web.psi.ch/L1Replacement/
The links point to other pages or information related to the replacement module qualification. |
|
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
1538
1542
1608
1613
also take a D (broken) module 1671 for setup testing.
2) L2
2278
2160
2258
2293
2078
2026
2122
2155
2035
2036
2298
2244
2269 was at the top of Andrey's list but I just discovered that it does not have the cap,
so we leave it at PSI.
D.K. |
|
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 sounds produced by Keithley.
In order to properly communicate with the new Keithley, it was necessary to set its communication mode to RS-232 and BAUD rate to 57600 (https://youtu.be/-5RmguqC7xA). Everything else was left unchanged:
BITS = 8
PARITY = NONE
TERMINATOR = <CR+LF>
FLOW-CRTL = XON-XOFF |
|
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 |
|
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.
The problems were (1) strange error messages from pxar core, (2)
problems with USB connections to the DTBs, (3) loads of (intermittent)
data transmission errors from the DTBs, and (4) complaints about missing
(system) libs.
In the end I did killall firefox and (out of superstition) pkill compiz.
Then it worked again. |
|
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 tested and shown to be working fine. This is when we took a third DTB, put it in the same plae as previously WWVASW and WRN13L, connected all the cables and then the tests worked.
Conclusion of the tests is that DTB_WWVASW and DTB_WRN13L are suffering from the same failure mode. It was not noticed before on the WRN13L because it does not affect the HDI tests. This leaves us with 3 working DTBs for the FUllQualification tests. |