| ID |
Date |
Author |
Category |
Subject |
|
270
|
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 |
|
295
|
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
change ModuleType definition from tbm10d to tbm10d_procv4
in order to use CtrlReg=17 setting
2) in pxar/data/tbm10d_procv4
change in all dacParameter*.dat files Vsh setting from 8 to 10.
I hope these are the right locations.
D. |
|
217
|
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
Modules to be given to Silvan |
|
220
|
Mon Apr 20 15:20:07 2020 |
Andrey Starodumov | Reception test | Change TBMs on M1635, M1653, M1671 |
| Andrey Starodumov wrote: | M1635: no data from ROC8-ROC11 => change TBM1
M1653: ROC12-ROC15 not programmable => change TBM0
M1671: no data from ROC12-ROC15 => change TBM0
Modules to be given to Silvan |
After TBMs have been changed:
M1635: the same no data from ROC8-ROC11
M1653: reception test Grade A
M1671: the same no data from ROC12-ROC15
M1635 and M1671 to module doctor for final decision |
|
16
|
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 of the wire bonds. The Reception test will be repeated tomorrow. |
|
19
|
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. |
|
88
|
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
M1582
M1583
M1584
M1585
M1586
M1587
M1588
M1589
M1591
M1590 was not glued last week because it had one HV bond broken (Silvan fixed this on Monday, 20/02/24).
M1586 initially had problems with the readout after gluing, but this was fixed by porperly closing the MOLEX connector. In the reception test, M1586 was graded 'B'.
All other modules were graded 'A' in the reception test.
Overall the double-gluing setup works very well. The modules above were glued basically in one day. |
|
63
|
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. |
|
75
|
Sun Feb 9 12:05:47 2020 |
Dinko Ferencek | Module assembly | Cap gluing |
| Today protective caps have been glued to modules 1561 and 1562. |
|
175
|
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.
I think we do not need to repeat FT for this module.
I put it in a tray with good modules. |
|
35
|
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 all 4 BB tets in pXar, it was concluded that BB2 is the appropriate test to use. |
|
64
|
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 FLOW-CRTL in Keithley's communication settings to XON-XOFF.
The reception test was successfully run for modules 1545, 1547, 1548, 1549, and 1550 after cap gluing. |
|
49
|
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 files are regenerated. |
|
25
|
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.
The jig closer to the doors (red): Top two pins - 5.75; Left pin - 5.5
The jig further from the doors (blue): Top two pins - 5.71, Left pin - 3.25 |
|
269
|
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 |
|
279
|
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
|
|
266
|
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. |
|
18
|
Fri Sep 27 22:24:31 2019 |
Dinko Ferencek | General | Activities on 27. 9. 2019. |
|
|
6
|
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 fine!) started sparking during HV test. Burn marks visible under the microscope in the top-right corner of the right TBM, between wire-bond pads. Other HDIs were fine and were glued to 2 v4 modules (1523 and 1529) and 1 v3 module (1526).
1.8.
Prepared the software and hardware for the full-qualification of multiple modules in parallel. Ran reception test on M1520 and M1522.
2.8.
Ran full qualification on M1520 and M1522. It consisted of qualification at -20, IV@-20, 5 cycles between -20 and +10, qualification at -20, IV@-20, qualification at +10 and IV@+10. This set of tests will from now on simply be called "full qualification". For some reason, second qualification at -20 failed. M1522 shows significantly high leakage current compared to previous tests
5.8.
Boxes 2 and 9 have been filled with L1 module trays. Each tray can hold 4 modules and each box contains 13 trays. Box 9 filled with humidity collecting balls. M1520 and M1522 placed in the box 9 which is the box that should be filled first. Reception test was run on M1523 and M1526. There were a lot of issues with M1523 in the address decoding test affecting other tests as well. What was found out is that the third dac, Vsh, was set to the wrong value by default if one was making module configuration folder using mkConfig script. It was 30 and should be 8. This should be propagated in pXar later on.
6.8.
Started running reception tests with 3 modules (1523,1526,1529) in parallel, but with the corrected value of Vsh (8). Several issues were observed.
First, one of the DTBs had a connection timeout which appeared every time we tried the reception test. Changing the DTB didn't work. This was solved by plugging the USB cable on the PC side to a different USB slot
Second, pretest in the reception test did timing test which we deemed unnecessary so it was removed.
Third, results for 1523 and 1529 didn't look correct. It was as if there was a problem with either timing or dac values. Comparing the logfiles of the test and the pxar files, it was found out that the timing settings were correct. The issue was in the dac settings taken by elComandante. What we forgot was that elComandante does NOT take dac settings frmo the module folder, but rather from generic tbm folders like tbm10d. This is set in the elComandante.config. The issue was that tbm10d folder had wrong values for Vsh (30, instead of 8) and ctrlreg (0 instead of 17). After this correction reception tests ran fine.
PixPhOptimization.cc was edited to correct the starting values of the parameters for the PhOptimization test. The old values were sometimes causing the tests to algorithm to fail even though the chip was fine.
Started full qualifications of all 3 modules, but there were some issues with the coldbox. It was noticed when it was not cooling at the start of full characterization. The warning on the coldbox interface read "Geber-stillstand". Danek managed to make it go away by stopping the program, even though no program was being run.
Finally, full qualification started around 15:00, finished at 22:40.
M1523 failed first qualification at -20, but finished other two qualifications. IV curves for that module were taken while M1529 was stuck and connected to HV as well meaning that the readings are actually sum of IVs from these two modules.
M1529 failed first qualification at -20, few seconds apart from M1523 failure. One of them failed during the Gain Pedestal, other one on PhOptimization. It also failed other two qualifications (PhOptimization and GainPedestal)
M1526 had no issues in qualification, however, it was graded C. One chip was problematic in most of the tests, while 4 others had issues with TrimBits. This is a bit suspicious so we'll investigate it further.
7.8.
Investigating problems with qualifications on testboards 0 and 1. We noticed that it happens during PhOptimization or GainPedestal. Also investigating why M1526 failed trimbits test on several ROCs. The cause was identified as a memory leak (several Gbs!) during a PhOptimization scan. Separate log made for this.
8.8.
Started full qualification WITHOUT PhOptimization at 9:15 on modules 1523, 1526, 1529. Finished after 8 hours. 1529 had a reception test error during fulltest@+10, other tests ran fine. Glued protection caps on 4 modules - 1504,1505,1509,1520 using 2 component epoxy adhesive.
9.8.
Running fulltest@-20 and +10 for modules 1504, 1505, 1520. The plan is to irradiate them in Zagreb and evaluate the changes induced by radiation. |
|
27
|
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 note
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 nanoCrate. |