Current Module LT Testing Capability

1. Current Module LT Testing Capability • Only Vienna Boxes Available • 10 slots at each site • ~75% efficiency of running time • Will estimate the amount of time run per module with: • 50,100 module tested at each site • 1 month, 2 months, 4 months run periods • Will assume 1 week at end to pull together results and 1 week lost to produce modules, procure & test module components, etc.

2. Current Time Estimates Modules Per Site • To run 100 modules for ~week each will need either: • Both sites running for ~2 months • 1 running for ~4 months • Any production beyond the 100 modules mentioned disrupts this test significantly • Any new modules would have to be put into Vienna box for testing as rods will not be available at rates to burn-in on rods • Thus, more modules could be run, but for less time • Even more time lost to loading/etc. • How long do we want to run the modules?

3. Way To Increase Modules Run • Run modules on rods in rod burn-in box • To get statistics needed (~100 modules), use 16 single sided rods • Use of DS rods will not increase statistics; DAQ hardware max-ed out at 8 SS4 rods • Two fully equipped/functional rod burn-in boxes • Or multiple runs with smaller number of rods • Calculate time run assuming: • 2, 4, or 8 rods per box • DAQ components for 2 rod running should be available at end of December • 4, 5, or 6 month periods from today • Assume 3 months to commission system to point that it is safe enough to run unattended and assemble 16 rods • Assume 75% efficiency once stable • Very aggressive, assumes that software and hardware works almost immediately and that system scales from 1 to 8 rods with no major problems • 10 more cabled rods available late Jan./early Feb. • Assume 2 weeks total to pull together results after run • THIS SCHEDULE IS EXTREMELY AGGRESSIVE AND HAS NEVER HISTORICALLY OCCURRED IN SIMILAR SITUATIONS

4. Rod Burn-in Time Estimates Rods Per Cycle • To get more significant running time per module (2 weeks) • Need 6 months with 2 rod per cycle capability • Need 5 months with 4 rod per cycle capability • Need 4 months with 8 rod per cycle capability • If a month per module is preferred, need 4-8 rod per cycle capability in order to finish test in time period given • Would take significant manpower, hardware increases, and software and data analysis development • Takes resources from other commitments: TOB/TEC hybrid PA wire bonding/testing, starting TEC module production, ramp up of TOB module production, finalization of module LT setups

5. Assumes equipment/hardware we do not have yet: 12 assembled rods PS cables 2 rods per cycle still need: 2 Delphi LV PS 2 OFED (2 OEC each) 2 oMUX crates with 3 oMUX each 4 rods per cycle still need: 6 Delphi LV PS 4 OFED (2 OEC each) 2 oMUX crates with 5 oMUX each 8 rods per cycle still need: 14 Delphi LV PS 8 OFED (2 OEC each) 4 oMUX crates with 5 oMUX each Recent/imminent deliveries of: All oMUX All OFED Parts and test equipment limit number of rods usable Assembled rods 10 more rods late Jan/early Feb Rest in late Feb Delphi LV PS 5 total for tracker in Dec. 5 total for tracker in Jan. 12 total for tracker at end of Feb. Rest in April To do significant number of rods would require majority of Delphi LV PS built May have to “borrow” existing supplies from current sites Difficulties in Rod Burn-in (Hardware)

6. Assumes software we do not have yet LT only shown to work on 1 rod May not be easily expandable to number of modules needed (Multiple oMUX crates, memory, etc.) May require significant fraction of Wim’s and Valery’s time Single rod commissioning/ validation software not developed yet Do not have algorithms to do fault finding Software to monitor/find changes in module response during module burn-in does not exist yet Similar rod software would have to follow the module software Rod burn-in slow controls/interlocks have not been commissioned with rods yet Integration beginning as we speak Difficulties in Rod Burn-in (Software)

7. Difficulties in Rod Burn-in (Manpower) • The same personnel at UCSB/FNAL would have to be used for: • Testing/assembly of modules/rods for this study • Begin TEC module construction/testing • Begin TOB/TEC hybrid testing • Construction/commissioning rod burn-in stand • Development in stages due to lack of rods and power supplies • The same personnel needed for software development • Module LT analysis • Rod commissioning • Rod burn-in software • Rod burn-in analysis

8. Conclusions (1) • The rod burn-in stands needed to run large number of modules for a significant period of time • Such a program would require a commitment of a large fraction of the resources needed for sub-structure assembly/testing • (Almost) all the Delphi LV PS in community • Large fraction of testing manpower at UCSB/FNAL • Most of the software developers time • This commitment will leave few resources for other tasks • Hybrid/module production and testing • TEC module production in US • If everything delivered on schedule and works perfectly, earliest we could get 100 modules run for 1 month each would be April • This assumes 8 rod burn-in assemble and commissioned at both sites starting late February • This assumes 4 complicated software packages will developed and commissioned in the same time frame

9. Conclusions (2) • From historically similar situations • It is not likely that all equipment needed will arrive in the time needed • It is not likely that all the software needed will be developed in time • From this experience I would assume that we could run 100 modules for an one-month period by June/July/Aug • I do not have enough information now to make a more precise estimate • Each equipment piece (2 types) and software package (4 types) can easily be delayed by a month easily