 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. |
|
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
FullTest
bb2
exit
where FullTest is defined in https://github.com/psi46/pxar/blob/9eb0f3844e9c7f98d7701629c5af339632c5d84a/tests/PixTestFullTest.cc#L82-L121. For added flexibility, we would like to have individual tests specified in the definition file. However, by default this implies calling the doTest() method for each of the tests while FullTest actually calls the fullTest() method. For Scurves and GainPedestal the two methods are distinct. After the latest updates from Urs to the pXar code, we are now able to change the definition to
pretest
readback
alive
bb
bb2
scurves:fulltest
trim
ph
gainpedestal:fulltest
exit
Note that readback was placed first because in the past it was observed that pXar had a tendency to crash when this test was run last. |
|
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/
/home/l_tester/L1_SW/pxar/data/tbm10d_procv3_test/
/home/l_tester/L1_SW/pxar/data/tbm10d_procv4/
/home/l_tester/L1_SW/pxar/data/tbm10d_procv4_test/
This is the value we will use for the FullQualification. |
|
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
1665
1672
1673
1674
1675
1676 |
|
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*
M1546 TBM1 output alpha broken (sdata1) => replace TBM1
M1563 ROC 8 thinks he is roc 10 ==> check address wire bond on roc 8?
M1567 roc 11 missing, sdata2 (b-channel)
M1572 sticker says : both TBMs broken, no SDA => replace both TBMs?
M1593 tbm0, core B (roc 0-3), no decodable output, core/stack working ok, output beta+ high ~ 2V
M1594 roc 0 dead
M1615 nothing on sdata 3 (12-15), very bad cable (corrosion?) re-running with new cable
M1616 ROC 10 not programmable, no roc headers on sdata2 (b) ==> TODO check clock to roc 10
M1617 readout but no hits in ROC 8, mechanical damage on chip edge
M1621 ROC 8 not programmable, no roc headers or tbm trailers on sdata2a (tbm1b) ==> TODO check clock on ROC 8
M1623 probably no cal-trig-reset to roc 0-3
M1625 definitely not cal-trig-reset to roc 0-3 (CTR- at 0V), damaged when trying to pull wire-bonds
M1575 no readout from rocs 0,1 (tbm0b, sdata4), all rocs programmable ==> TODO check CTR roc 0 |
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
It turned out this was happening for those modules for which the MoReWeb analysis was run more than once. The solution is to remove all info from the database for the affected modules
python Controller.py -d
type in, e.g. M1668, and when prompted, type in 'all' and press ENTER and confirm you want to delete all entries. After that, run
python Controller.py -m M1668
followed by
python Controller.py -p
The missing info should now be visible. |
|
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:
- we switched sides, the cap gluing is now done on the window-side of the aisle
- there are now two jigs set up for cap gluing
The procedure itself for gluing did not change: Apply the stamp with the glue to module 1, release, put module 1 into its jig, insert module 2 into gluing jig, apply stamp (because of the glue fluidity, the marks from module 1 will have disappeared and there is no need to re-apply any glue to the stamp). The caps are lowered onto the modules only once the glue has been applied to both modules.
Silvan recommended applying the weight of only one copper(?) bar, to be placed centered on the top of the z-stage.
Silvan also recommended against using ethanol. Instead we are supposed to use aceton. As a result, the plastic tweezers should not be used anymore, but rather metallic tweezers.
Finally, Silvan changed the Peltiers, and applied isolation inside Red October. We observed cooling times from 10C to -20C of 6 minutes. |
|
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
- 381783-03-3 used for M1618
- 350853-16-1 used for M1619
It means that information about about ROCs used for these modules is missing in the Module_Assembly spreadsheet. |
|
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
2) threshold at which trim bit test is done
3) improvements in PH optimization algorithm
No changes in test algorithm have been introduced since March 18.
All modules have been tested with CtrlReg=9, for this several modules failed at +10C.
From now on for test CtrlReg=17 will be used.
Ft will be shorter: only one test at -20C, no T-cycling and one test at +10C. Leakage current will be measured up to 200V. |
|
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'.
The difference in the configurations is in the CtrlReg DAC value which is 9 for V3 and 17 for V4.
The following lines were also added in the [defaultParameters] section in /home/l_tester/L1_SW/elComandante/config/elComandante.conf
tbm10d_procv3: tbm10d_procv3
tbm10d_procv4: tbm10d_procv4 |
 Thu Nov 28 18:23:31 2019, Dinko Ferencek, Software, Reorganized pXar configuration files for pixel modules
|
| Dinko Ferencek wrote: | 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'.
The difference in the configurations is in the CtrlReg DAC value which is 9 for V3 and 17 for V4.
The following lines were also added in the [defaultParameters] section in /home/l_tester/L1_SW/elComandante/config/elComandante.conf
tbm10d_procv3: tbm10d_procv3
tbm10d_procv4: tbm10d_procv4 |
Since the new PH optimization code was added under the already existing PH test, the old configuration files would have to be updated to have the correct parameter values set for the expanded PH test. For this purpose, the old configuration folders were renamed
tbm10d_procv3 --> tbm10d_procv3_old
tbm10d_procv4 --> tbm10d_procv4_old
and new configuration files were re-generated from scratch
./mkConfig -d ../data/tbm10d_procv3 -t TBM10D -r proc600v3 -m
./mkConfig -d ../data/tbm10d_procv4 -t TBM10D -r proc600v4 -m
In addition, in both sets of configurations files, the configuration for the BB2 tab in the pXar GUI was moved from moreTestParameters.dat to testParameters.dat to have the BB2 tab available by default when starting pXar using these configuration files. |
|
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).
1) Change 50-->44 in
(1) Analyse/AbstractClasses/TestResultEnvironment.py: 'StandardVcal2ElectronConversionFactor':50,
(2) Analyse/Configuration/GradingParameters.cfg:StandardVcal2ElectronConversionFactor = 50
(3) Analyse/Configuration/GradingParameters.cfg.default:StandardVcal2ElectronConversionFactor = 50
2) remove all SCurve_C*.dat files (otherwise new fit results are not written in these files)
3) run python Controller.py -r -m M1591
M1591:
- all three T grade C due to Mean Noise > 300 for ROC0 and/or both ROC0 and ROC1
- after rerun MoreWeb all but one grades are B on individual FT page but in Summary pages grades still C???
- second time at -20C: grade C is due to trimming fails in ROC0: 211 pixels have too large threshold after trimming
Trimming to be checked!!! |
|
Wed Mar 4 16:00:05 2020, Andrey Starodumov, Re-grading, Regrading C M1591: due to Noise
|
| Andrey Starodumov wrote: | 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).
1) Change 50-->44 in
(1) Analyse/AbstractClasses/TestResultEnvironment.py: 'StandardVcal2ElectronConversionFactor':50,
(2) Analyse/Configuration/GradingParameters.cfg:StandardVcal2ElectronConversionFactor = 50
(3) Analyse/Configuration/GradingParameters.cfg.default:StandardVcal2ElectronConversionFactor = 50
2) remove all SCurve_C*.dat files (otherwise new fit results are not written in these files)
3) run python Controller.py -r -m M1591
M1591:
- all three T grade C due to Mean Noise > 300 for ROC0 and/or both ROC0 and ROC1
- after rerun MoreWeb all but one grades are B on individual FT page but in Summary pages grades still C???
- second time at -20C: grade C is due to trimming fails in ROC0: 211 pixels have too large threshold after trimming
Trimming to be checked!!! |
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
To the directory :~/L1_DATA/WebOutput/MoReWeb/FinalResults/REV001/R001/M1591_FullQualification_2020-02-28_08h03m_1582873436/QualificationGroup/ModuleFulltest_m20_2
file grade.txt with a content "2" (corresponds to grade B) has been added. Hence this test grade has been changed from C to B.The reason is that 211 pixels fail trimming (threshold is outside boundary) is a too low trim threshold: VCal=40. From now on 50 will be used. |
|
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"
The Mean noise remains the same but threshold scaled according to the new VCal calibration (44 instead of 50).
To have corrected Mean noise one needs to refit SCurves, means run MoreWeb analysis with -r flag: "Controller -m MXXXX -r"
The modules still graded C due to relative gain spread. It will be re-tested tomorrow with new HP optimization/calibration procedure. |
|
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
M1609: C->B
M1618: B->A
M1612: B->B
M1610: B->B
M1608: C->B
M1606: C->C (too many badly trimmed pixels)
M1605: C->B
Most of all B gradings and one C are due to badly trimmed pixels. The threshold after trimming usually has 3(!) separated peaks.
We should understand this feature. |
|
Wed Mar 25 18:31:46 2020, Andrey Starodumov, Re-grading, Reanalised test results
|
| Andrey Starodumov wrote: | Test resulsts of several modules have been re-analised without grading on trimbit failure.
M1614: C->B
M1613: C->A
M1609: C->B
M1618: B->A
M1612: B->B
M1610: B->B
M1608: C->B
M1606: C->C (too many badly trimmed pixels)
M1605: C->B
Most of all B grading and one C are due to badly trimmed pixels. The threshold after trimming usually has 3(!) separated peaks.
We should understand this feature. |
More modules have been re-analysed:
1604: C->B
1603: C->B
1602: C->B
1601: B->A
1545: C->C (too many pixels on ROC14 are badly trimmed, to be retested tomorrow) |
|
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 14:36:10 2020, Andrey Starodumov, Reception test, RT of M1669 and M1670
|
| Both modules graded A. |
|
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. |
|
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. |