Bonding web site, renovated Finished renovating Bonding WG web site, a tasks handed down to me by Alan last July 2003. Both site infrastructure and contents renovated Uniform graphic style Automated handling of bookkeeping info (such as Meetings archive, mailing lists and now also Center facilities). Revised and updated documents. Organized into “Procedures” and “Tech Info” sections. Some docs were in need of major updates, for which Group consensus is in order (discussed later during this Meeting)

Bonding web site, renovated

Center facilities archive Uses info gathered by Alan with a questionnaire sent to Institutes on 26 Apr 2000 I will ask all Level-3 Responsibles to update the info Mechanism similar to Bonding I/F: Update older info about existing machines Enter new info for a new machine Access controlled username and pw will be distributed to L3’s I hope working together with the L3’s we can keep this info up-to-date at all times from now on

Center facilities archive Machines are identified by the DB tool_id #

Official Documents

Procedure Document Source Technical structure Based on Alan’s original 24Sep2002 doc Includes: additions specific for TIB/TID developed in the INFN community items from the Oct 23, 2003 official doc of the Module Test WG concerning all tests correlated with Bonding my own additions mainly concerning interactions with the DB. Technical structure Global and comprehensive (the Reference ‘Bible’ of CMS Module Bonding), i.e. has all procedures for all Module types Paragraphs referring only to specific Tracker components (TEC, TOB, TIB/TID) are coded for an automated program which can extract and present to the user a subdocument with only the relevant info Same technique can be used to extract info tailored to specific operations or audiences (Klaus’ comment)

Document approval path Advertised ~2 weeks ago Gathered comments until yesterday (but only Susanne Kyre reacted) Still has missing/not yet available info Will go thru it now and get live comments, if any Formal approval. With approval it becomes a living document, open to changes as need arises with growing experience and to the addition of info missing or not yet available today (subject each time to the group approval, by e-mail unless revolutionary changes). To doc 

Carrier/Transport/TO plate

50th wire pull test Small addition (by S.Kyre) :

Source Specs Document Based on Alan’s original 29 Oct 2000 doc Includes: additions specific for TIB/TID developed in the INFN community Recent additions and changes by Alan my own additions mainly concerning specs implemented within DB I/F.

Document approval path (same as for Procedure doc) Advertised ~ 2 weeks ago Waited for comments until yesterday (none) Still has missing/not yet available info Will go thru now and get live comments, if any Formal approval. With approval it becomes a living document, open to changes as need arises with growing experience and to the addition of info missing or not yet available today (subject each time to the group approval, by e-mail unless revolutionary changes). To doc 

Bad strips study conclusions (from last Meeting, 21 Oct 2003) 1) Practically all good-IDIEL strips have 0<IDIEL<0.1 nA 2) Most bad-IDIEL strips have higher IDIEL, but 16% have the good 0<IDIEL<0.1 nA 3) Having constructed the relative CAC rC=CACOfBAdCACStrip/AvgCACOfAllGoodCACStripsInThatSensor, all isolated bad-CAC strips have rC<1 4) the consecutive bad-CAC have a complex distrib with 2 parts, one for rC<1 which is very similar to the isolated ones, thus indicating these are not shorts but (mostly) pairs of strips affected by the same defect which causes a low capacitance (a scratch?) and one with rC>1, with peaks at 2, 3, 4 and a marked peak at 2.6. These are probably shorts although I can't find an obvious explanation for the peak at rC=2.6

Bad Sensor strips Presented study at ModProd Meet 23 Oct 2003 Got response from Manfred, Sensor Group Coordinator The technical reasons why 16% of bad-IDIEL strips have just good IDIEL and rC has a peak at ~2.5 remains unexplained, but Manfred said they will investigate. As a general remark, they occasionally have uncertain results because of flaky probe contacts. However, we cannot put Bonding on hold until we get an explanation. Ambiguous cases account for only 0.038% of all tested strips Finally, an agreement was reached on strips to leave unbonded within a de-facto commettee made of Manfred, Alan, Tony and myself …

Skip rules Old rule New rule Leave unbonded All strips in bad-IDIEL list (considered pinholes) All Isolated bad CAC (believed to have high chance to develop into pinholes with irradiation) All but lowest in a bad CAC chain (believed to represent shorts) CAC Example: 3 34 35 36 37  skip isolated 3, skip all but lowest in 34-37 chain, or: bond only 34 Old rule Leave unbonded all strips in bad-IDIEL list (although 16 % are good), i.e. do not bother looking at their actual IDIEL value. Bond all isolated bad-CAC For the consecutive bad-CAC, compute rC and consider them members of a short if rC>1.5. Then bond only the first strip in the short. If rc<1.5 bond them, as if they were isolated New rule

New release of DB I/F (v. 3.2) Unfortunately, we will need a new release: To implement new skip rule to produce new lists of strips to skip and corresponding red boxes in checkerboards In v. 3.1, if no test data by QTC Centers (e.g. if no rows with status ‘reference’) are found in DB for a Sensor, we suggest to bond all strips. However, we are moving to a sampling test mode of sensors  most sensors will never have rows with status 'reference‘ but just 'valid‘ (data inserted by Manufacturer, which we will simply have to trust), so I/F will look: first for 'reference' rows, then for 'valid' rows to implement skip suggestions, and finally suggest to bond all strips only if no rows whatsoever are found for a given Sensor. Release will also include 1 additional variable about Hybrid Quality Control (requested by Strasbourg). Center names will have to change (requested by TrackerDB Administrators).

“Bonding & Repair” Group Module Repair Originally, we were named the “Bonding & Repair” Group It is possible Management assumes we should take responsibility for Module repair in a general sense, not just bonding-related Do we think we should? Which repairs besides bonding? I’ve asked to put this question on the Agenda of the TPO Thursday, but I should also voice there the thoughts of this Group.

(Bond) Repair document Alan is working on a first draft Request has been sent to all in Mod Test for input on problem/cure cycles Alan: Procedure for shorts that are found to be either on the PA or due to the PA-APV bonding If there is a PA short fixed, this will give the following "fault" in the readout test: the channel which had the bond pulled will look like a standard open. The other channel will have about 2x the normal capacitance so will have higher noise. It will likely fail the noise cuts. This will also be true of a short on the first sensor which has been fixed in the "standard" way given in the module bonding procedures. Clearly the whole interpretation of the data from a bonded module becomes much more complex when there are these various faults and repairs. Tony Affolder has volunteered to contribute the experience they have made in Santa Barbara, e.g. on CMN problem/cure pairs

# Modules pull tested, separately per bond type Center Compliance Results in DB from 7 Centers # Modules pull tested, separately per bond type Center PA Test Areas 50th PA-Sen 50th Sen-Sen Bari 3 n/a  Firenze 6 2 Padova 1 Pisa 4 Fermilab 28 Santa-Barbara 12 9 Zurich n/a

Module Pull Tests

Module Pull Tests

Module Pull Tests

Module Pull Tests

Module Pull Tests

Module Pull Tests

Module Pull Tests

Module Pull Tests

Module Pull Tests

Module Pull Tests

Module Pull Tests

Reports from Centers Aachen Bari Catania CERN Fermilab Firenze Hamburg Karlsruhe Padova Pisa Santa Barbara Strasbourg Torino Vienna Zurich

Catania On 5 Dec 2003 the INFN Consortium has agreed to re-designate Catania as Production Center. This means we are going to become a full-blown Bonding Center Previously we were “Bonding Repair Center” and we also already had responsibility for LT Module Testing. It’s foreseen we will bond ~500 TIB/TID Modules. Correspondingly the load of Module to LT-Test will reduce from ~1000 down to the ~500 we will bond. Modules for Catania would come from the Bari Gantry. Sebastiano will now give an overview of the Catania facilities.

Catania-Recent Activity In preparation for mass production, looking for best parameter sets, bonded  pull tested: Test Str (Hamamatsu, ST) PA’s Module 30200020000008 (*) (*) This is a Module with unbonded Hybrid, assembled in Bari, originally to be bonded (both Hyb-PA and PA-Sen) in Padova, but which has shown several problems (foreign material stuck to APV pads, scratches across the PA pads facing APVs, misalignment of PA to Sen by 1 pad) and therefore has been granted to us for exercise

Module 30200020000008 Material on APV pads Scratches on PA pads

Catania – Pull Tests Best-Performance (All pull strengths in g) Substrate # bonds min max avg SD FBHB FBLO MSB SBHB SBLO HPK(*) 20 7.8 10.7 9.3 0.9 18 2 ST (*) 6.3 8.0 0.8 19 1 PAs TIB3 12 4.0 7.0 5.2 1.1 11 PA on old CSEM Mod 10 6.0 7.5 1.0 Mod *008 PA-Sen ($) 5.0 8.6 (*) same parameters ($) every 25th wire

Firenze Has bought automatic Pull Tester identical to the one of Pisa. From now on, will join Pisa in the systematic Sensor’s Test Structure Pull Test job (relevant to Sensor qualification). Test Structures will still come into Pisa only, but subsets of them will then be moved to Firenze for test bonding and pull.

Hamburg Jigs? DB… Center registration into DB? “HAMBURG-U” ? tool_id’s…

Schedule Alan cannot attend Info will be given by Gabriella Pasztor/ Bruno Wittmer at Mod Prod Mtg

Problems w/ delayed data recording in TrackerDB This Module seems to have been assembled (“GANTRYVAL”) in Aachen

Problems w/ delayed data recording in TrackerDB For this Module MODPULLTEST seems to have occurred in Aachen, not Zurich

Peculiar TEC R1 Sensor Design Klaus Kretschmer of Hamburg pointed out a peculiar variable pitch observed on TEC R1 Sensor bond pad row. Klaus Freudenreich investigated at my request and it turns out it’s a feature: From Anna Macchiolo: The wedge sensors W1 TEC, W1 TID and W2 are the ones where the strip pitch is narrower and this has required some adjustment on the DC and AC pad position. For these three designs the pad step has been kept constant except for one over 16 pads. The first pad in each group of 16 has been repositioned in such a way to center it with respect to the corresponding strip.This was discussed in the sensor group at the time of the mask approval. We are showing it here to make everybody who has to bond R1&2 Modules aware of this.

Peculiar TEC R1 Sensor Design