2. 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)

3. Bonding web site, renovated

4. 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

5. Center facilities archive
Machines are identified by the DB tool_id #

7. Official Documents

8. 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)

9. 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 unless revolutionary changes).
To doc 

10. Carrier/Transport/TO plate

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

12. 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.

13. 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 unless revolutionary changes).
To doc 

15. 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 These are probably shorts although I can't find an obvious
explanation for the peak at rC=2.6

16. 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 …

17. 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:  skip isolated 3,
skip all but lowest in 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

18. 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).

20. “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.

21. (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

23. # 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

24. Module Pull Tests

25. Module Pull Tests

26. Module Pull Tests

27. Module Pull Tests

28. Module Pull Tests

29. Module Pull Tests

30. Module Pull Tests

31. Module Pull Tests

32. Module Pull Tests

33. Module Pull Tests

34. Module Pull Tests

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

37. Catania
On 5 Dec 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.

38. Catania-Recent Activity
In preparation for mass production, looking for best parameter sets, bonded  pull tested:
Test Str (Hamamatsu, ST)
PA’s
Module (*)
(*) 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

39. Module
Material on APV pads
Scratches on PA pads

40. 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

41. 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.

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

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

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

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

48. 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.

49. Peculiar TEC R1 Sensor Design