<!-- Title: 10:52:58  Mon Oct  9 2006 -->
<!-- Crewchief: Juan Pablo (MPC) -->
<!-- Op1: Ulrich Husemann (SPL) -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>continue data taking</pre>

<!-- Date: Mon Oct 9 11:36:25 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W8L0 
<li>problem n: 1497 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: There are almost no errors starting 09/28/06 (errors are intermitent with a very low rate). Because there were no serious problems for ~2 weeks, we need to continue observations and run this ladder in SVXDAQ. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W8&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Oct 9 13:35:16 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W0L0 
<li>problem n: 186 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis
<li>entered by: sasha 
<li>description is: This ladder has a constantly low rate of 'Bad ADC value' errors. No other errors are reported by Bit Reporter. Looking at Antonio's temporary ADCMon for run <a href='http://b0sili01.fnal.gov//monitoring_wg/svxmon_224126/'>224126</a>, one can see that the pattern is consistent with a some kind of a bit error. One needs to look at this ladder during quiet time.   
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Oct 9 13:51:38 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W4/5All 
<li>problem n: 1689 
<li>Status: needs_work
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Wedge wide CAP_ID errors are back again at 60% rate in run 224480. These errors were also present before, but usually with a rate of <1%. Earlier, there were also problems with other wedges from fib07 (<a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=321&frame=2&anchor=11:39:20'> see e-log</a>). This FIB is to be investigated during next access. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W4/5&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Oct 9 14:00:46 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W5L1 
<li>problem n: 1182 
<li>Status: unfixable
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: I'm closing this thread because this problem has been addressed and declared unfixable in thread 168.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W5&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Oct 9 14:13:43 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10007&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10007' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10008&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10008' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Mon Oct  9 14;17;12 comment by...Ankush -->
<h3>Yeah baby...it's a clock-glitch</h3>

<p>The logic analyser emailed me again and we got another clock glitch.  However this time on the ISL clock lines.  The largest glitch was 58.6μs.  This is what the error logger said:</p>

<pre>
CT: 2006.10.09 13:22:06
22'6" b0svx06:Messenger:Oct 9, 2006 01:22:06 PM->SRC Fatal Error:Sl 6 Too Many L1A 2 L1A to Buff 
 -->  
 Additional Information: 

 Attention !!!. FERML_SRC_FATALITY ERROR !!! 
 
 SRC Fatal Error from b0svx06: Sl 6 Too Many L1A 2 L1A to Buff 
 
 - HALT the run                   
 - record any relevant information in e-log     
 - RECOVER - RUN     
[MLE]
</pre>


<!-- Date: Mon Oct 9 14:45:12 2006 -->
<h3>List of things TO DO from the detector side</h3> 
 
<p> 
<h4>Quiet time studies</h4> 
<li>e092-- "Pipeline out of sync"</li> 
<li>e271-- "bit 1 low"</li> 
<li>e320-- try to adjust chip settings</li> 
<li>f500-- bit error</li> 
<li>e053-- check "init readback" in SVXDAQ</li> 
<li>f002-- try to bring back (low priority)</li> 
<li>e124-- try to bring back (low priority)</li> 
<li>e522-- try to bring back (low priority)</li> 
 
<h4>Observations</h4> 
<li>e224-- no errors since 10/07/06; continue observations</li> 
<li>e280-- no errors since 09/28/06; confirm with SVXDAQ; continue observations</li> 
 
<h4>Access</h4> 
<li>e3b3-- try to find RX sensitive to high light level</li> 
<li>fib07-- investigate this fib; wedge wide problems with f54/5, f40/1, f32</li> 
 
<h4>Other...</h4> 
Repeat "permanent" light level measurements. 
</p>
<!-- Author: sasha, jeannine -->


<!-- Date: Mon Oct 9 16:24:51 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10009&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10010  width='300' align='top'></a></td><td> looking at the behaviour of this ladder on SVXMon</td></tr></table>
<!-- Author:  Juan Pablo -->
<!-- Comment: Mon Oct  9 16;28;28 comment by...Juan Pablo -->
<pre>This ladder, IB5W1L1, is giving high AVDD current.
It is supposed to be running with just the first to chips (since
the others were chopped).
The strip mean charge on the second chip does not look fine to me.
Will look at other variables...</pre>


<!-- Comment: Mon Oct  9 17;17;34 comment by...Ankush -->
<p>Ever since I put this ladder back in, the AVDD for the ladder has been jumping from ~1000μA to ~700μA.  I suspect this is from chips, not involved in the readout,  switching on/off.</p>
<!-- Date: Mon Oct 9 16:32:41 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10011&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10012  width='300' align='top'></a></td><td>Here is the strip occupancy (bad , out 
of question)</td></tr></table>
<!-- Author:  Juan Pablo -->
<!-- Comment: Mon Oct  9 17;08;09 comment by...Ankush -->
<p>I put the second chip into RA mode as this fixed some readout errors.  This is documented in the Problem DB and the elog.</p>
<!-- Comment: Mon Oct  9 17;28;23 comment by...Juan Pablo -->
<pre>Ok, it makes sense</pre>
<!-- Date: Mon Oct 9 16:36:48 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10013&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10014  width='300' align='top'></a></td><td> Strip RMS for IB5W1L1 on run 224521</td></tr></table>
<!-- Author:  Juan Pablo -->





<!-- Date: Mon Oct 9 23:09:12 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10015&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10015  width='300' align='top'></a></td><td>Beam studies. No changes noticed on losses.</td></tr></table>
<!-- Author:  Juan Pablo -->
<!-- Comment: Mon Oct  9 23;09;45 comment by...Juan Pablo. -->
<pre>They are done playing with the tickler and no effect was seen.</pre>


<!-- Date: Mon Oct 9 23:46:40 2006 -->
<pre>CO noticed SVXMon was not updating. I asked her to restart 
SVXMon. Now we have a trigger inhibit (PSM) and have to wait 
to see SVXMon is back fine...</pre>
<!-- Author:  Juan Pablo -->


<!-- Date: Tue Oct 10 02:42:22 2006 -->
<pre>Tevatron quench at B1, D1, D2, and D3. 
Besides Ace-Monitoring decided to push the crash buttom.</pre>
<!-- Author: Juan Pablo -->


<!-- Date: Tue Oct 10 03:40:32 2006 -->
<h3>Power Glitch & Crash Button</h3> 
At around 2:20, there was a power glitch from feeder 46 which took out the Tevatron store and several things in CDF. During the glitch the ISL East flow dropped slightly, causing a PS trip in all East ISL power supplies. The flows were still fine. As we train the Aces to confirm that the <em>entire</em> ISL is off when there is an ISL cooling alarm, the Aces decided to hit the Rack Crash Button. 
<p> 
That's when they paged me (Ulrich). Juan Pablo was on the scene only seconds after they hit the crash button. It took the cryo tech (Steve Gordon) a while to get the silicon racks back on. First we realized that the Aces had hit the crash button but did not release it. Then Steve reset the Quadlog, we waited for 10 minutes, and the racks came back fine. In order not to freeze the COT, we raised the SVX temperature set point to -6°C. Once the racks were back, we went to -8°C. One of the power supplies (#8) had a communication failure, so we Hockerized it. 
<p> 
Next we ran Coldstart to bring everything back in line. After that we could power the detector back on. We first checked a single ladder and then we followed the regular turn-on procedure.
<!-- Author: Juan Pablo & Ulrich -->
<!-- Comment: Tue Oct 10 03;51;49 comment by...Ulrich -->
<p>
Here is Brian Drendel's assessment:
<pre>
 Power Glitch!  Lost Feeder 46B:   Ops and experts are working to get systems back online.   Here is a quick status report.

    * Feeder 46B:
          o Feeder 46B was lost at the Master Substation.
          o This feeder powers D0, CDF and F0.
    * Injector Chain
          o PreAcc Source does not look healthy
          o Drift Tube Linac RF stations are down hard
          o Klystron RF stations are down hard.
          o Booster RF is down hard.
          o Main Injector RF is back up after watchdog trips.
    * Pbars:
          o Recycler Stash of ~175e10 is intact.   Lifetime is poor but improving after earlier vacuum problems.
          o Pbar Stack of 68mA is intact.
    * Tevatron
          o Store is gone
          o Tevatron RF, CDF and D0 are down hard due to the lost Feeder 46B.
          o Quenches at B1, D1, D2 and D3. 
                + Houses B1 and D1 are mostly recovered.
                + The upstream end of house D2 got to 40°K
                + The upstream end of house D3 got to 150°K

 - B Drendel  
</pre>

<!-- Comment: Tue Oct 10 03;52;18 comment by...Ulrich -->
The SVX temperature set point is back to -10°C.

<!-- Comment: Tue Oct 10 04;06;44 comment by...Juan Pablo & Ulrich -->
The entire detector is back on, without major problems (SB4W8 tripped during the turn-on). We took some event in Coldstart, rebooted svxinter, and restarted PS GUI and IMON.

<!-- Comment: Tue Oct 10 08;36;36 comment by...Ulrich -->
More new from the Run Coordinator:
<pre>
06:12:41-  Tevatron A4 and D3 vacuum are bad. Tevatron A-E is now in on access to take a look. Cryo experts suspect a bad magnet at D3. - B Drendel
 07:39:50-  The cause of the Feeder 46B glitch was a rodent in the D0 switchgear. Feeder repair will take three hours, but the Tevatron is in worse shape. There is a blown vacuum relief at D34 and magnets are frosted. We should have more information later this morning. - B Drendel
</pre>


<!-- Date: Tue Oct 10 08:40:00 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10016&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10017  width='300' align='top'></a></td><td>A picture of the "crispy critter" (MCR elog)</td></tr></table>
<!-- Author: Ulrich -->


<!-- Date: Tue Oct 10 09:26:50 2006 -->
<h3>ISL COT face pressure and vacuum</h3> 
During the quiet time today I confirmed that the slight increase in ISL COT face pressure is indeed a result of the bad vacuum. Even with a freshly rebuilt pump, we never got better than 1.9 psi, and with VP2-A we were running at 2.1 psi. I tried VP1-A, which made the vacuum even worse (2.5 psi). So I requested a replacement of VP1-A. KC will take care of this later this morning.
<!-- Author: Ulrich -->
<!-- Comment: Tue Oct 10 13;41;24 comment by...Ulrich -->
KC swapped in a new vacuum pump fror VP1-A. The vacuum it creates is about as good as the one from VP2-A, around 2.0 psi. I leave the system running on the new pump for the time being.
<!-- Date: Tue Oct 10 11:22:06 2006 -->
<h3>Long Tevatron Downtime Likely</h3> 
It seems that the Tevatron has to be warmed up, so we will probably have of the order of 10 days of downtime. Here is the latest from Brian Drendel: 
<pre> 
10:23:44-  The news from the Tevatron tunnel is not good. There is a zero ohm fault between D32-5 and D32-4 both busses together and to ground. Tevatron experts believe we will have to warm up D3. They are breaking the bus to make sure there are not multiple faults. We will be having a meeting at 11am meeting with Cryo, Tevatron, Mechanical Support, EE Support, Operations, Run Coordination, etc.. to discuss the repair schedule.  - B Drendel 
-- Tue Oct 10 10:35:41 comment by...B Drendel --  Meeting will be in the Dungeon.   
</pre> 
If this proves to be true, we would go ahead and fix the ISL cooling problem during that time. The preparatory work has started already.
<!-- Author: Ulrich -->



<!-- Date: Tue Oct 10 16:26:10 2006 -->
<h3>Shutdown now confirmed</h3> 
 
<p>The run coordinator has posted an entry that the D3 magnet will need to be replaced.  This will take ~1 week and the final programme of repairs will be discussed during Wednesday's Accelerator meeting.</p> 
 
<p>So we will definitly use this time to open the East plug to fix the ISL cooling leak.  The rough timetable is: 
 
<ul> 
<li>Tuesday: Do Silicon COSMICs run.  This is currently ongoing.  the run-number is: 224637.  A DMode calibration may be carried out afterwards.</li> 
<li> Wednesday: Detector steel moved + East Plug pulled.</li> 
<li> Thursday: Plug work day.  We hope to have the problem diagnosed and fixed by the end of day.  Then carry out a detector checkout of the East half of SVX,ISL & L00.</li> 
<li> Friday: Close-up plug for soft close.</li> 
<li> Monday: Hard close of the East plug 
</ul> 
 
<p>If the ISL leak is not fixed on Thursday, then we will use Friday and the weekend, if necessary.</p>
<!-- Author: Ankush -->


<!-- Date: Tue Oct 10 17:42:18 2006 -->
<h3>Silicon COSMICs completed....now to warm up the detector</h3> 
 
<p>Now the Silicon COSMICS has been completed, Jennifer will start preparations to warm up the silicon detector.</p>
<!-- Author: Ankush -->
<!-- Comment: Tue Oct 10 18;26;15 comment by...Ankush & Jennifer :-) -->
<table border=0><td><tr><td bgcolor=#e0e030><h4>Silicon is OFF</h4>

<h4>CAEN 5V ENABLES ARE OFF</h4></td></tr></td></table>

<!-- Comment: Tue Oct 10 18;43;46 comment by...Ankush & Jennifer :-) -->
<h3>Detector warm-up: part 1</h3>

<p>The first part of the warm-up is complete:<br>
ISL-->+10C<br>
SVX-->-5C<br>
</p>

<p>Now the next stage of the warm up begins...</p>


<!-- Comment: Tue Oct 10 18;52;50 comment by...Jennifer :-) -->
<pre>Final stage of the warm-up: SVX now set to 0°C and ISL now set to 10°C.</pre>
<!-- Comment: Tue Oct 10 19;09;09 comment by...Jennifer :-) & Anky the Infallible -->
<h4>Jennifer's Warm-Up mini-procedure</h4>
<ul>
<li>To begin with, I printed out SVX and ISL manifold, flow monitor, cooling system, and flow monitor iFix pages</li>
<li>SVX, ISL inlet, outlet and chiller evaporator temperature alarms silenced. *Note!* Since cryo people had a history of having their alarms un-ignored by the shift crew (could they do that under the ACE account?!) <b>Chiller Evaporator and Chiller Outlet temperature alarms can only be silenced by a cryo personnel</b>. This is what I'm told.</li>
<li>I also ignored the L00, SVX & ISL temperature über-trips and a slew of alarms for PCs and L00. Unfortunately, once I changed the A/W limis (too soon...) our poor Juan Pablo was incessantly paged. My bad.</li>
<li>We did the warm-up in 2 steps. SVX went from -10°C→-6°C→0°C, and ISL went from 6°C→10°C→15°C. This seemed to work out well.</li>
<li>I was impatient and didn't want to go back into the freezer, but I should have waited until we warmed up a bit more before changing the A/W limits. Here's how I changed them (in reference to April 2nd warm-up):
<ul><li>L00 temperature trip limits from 2.0°C→4°C</li>
<li>ISL PCs from 15.0°C→18.0°C</li>
<li>SVX BHs from 2.0°C→6.0°C</li>
</ul>
</li>
</ul>
Now I'm just waiting to leave alarms un-silenced, and then I'll be going home. I'll have the cell phone, so call if I screwed up: 585.355.9998.
<!-- Comment: Tue Oct 10 19;33;41 comment by...Ankush -->
<h3>List of alarms ignored</h3>

<p>I have set the following iFIX alarms to be ignored:</p>

<p>
<b>SVX Power Supplies</b><br>
--- PS-TRP<br>
--- PS-ALARM<br>
--- PS-CAEN-OFF<br>  
<br>
<b>ISL Power Supplies</b><br>
--- PS-TRP<br>
--- PS-ALARM<br>
--- PS-CAEN-OFF<br>  
<b>L00 Power Supplies</b><br>
--- PS-TRP<br>
--- PS-ALARM<br>
--- PS-CAEN-OFF<br>  
</p>
<!-- Comment: Tue Oct 10 19;46;19 comment by...Jennifer :-) -->
<h4>Jennifer back this evening</h4>
I'll be back this evening to unsilence PC alarms, temp über-trips, and other misc. silenced alarms that I personally silenced for the warm-up. I'm not touching the PS and CAEN alarms. I'll also put in the warm-up plots, per usual procedure.
<!-- Comment: Tue Oct 10 23;04;54 comment by...Jennifer :-) -->
I have left the following alarms silenced:
<ul><li>Chiller Inlet, Outlet, and Evaporator Temperatures</li>
<li>2 portcards that think that they are cold (I don't want emails about them)</li>
<li>1 L00 guy that thinks that he's cold, too</li></ul>
</ul>
Everything else has been un-ignored. Don't worry, the PS and CAEN alarms ignored by Ankush have remained ignored.
<p>
You you all tomorrow, bright-eyed and bushy-tailed.
<!-- Comment: Wed Oct 11 10;46;30 comment by...Ulrich -->
<h4>Some adjustments</h4>
I have unsilenced the chiller inlet/outlet alarms, they are nowhere near alarm. Last week I had closed the e-valve for CCE1 to 70% and opened up CCE2 to 85% and CCE3 to 80%. This caused lower flow at the current temperature. So I brought these three valves back to their default values of 75%. Note to self: opening CCE1 to 80% is not a good idea. The pressure jumped up to 13.5 psi, barely below the trip limit.
<p>
I have also re-created a Real Time Plotter iFix page to monitor the dew points in the system. It is in the same directory as the regular Real Time Plotter page, but with the name <tt>realTimePlotter_dewpoint.grf</tt>.

<!-- Date: Tue Oct 10 18:51:08 2006 -->
<h4>Sorry Juan Pablo!!!!!</h4>  
<!-- Author: Miss &quot;likes to change temperature trip limits and not ignore any alarms&quot; -->




<!-- Date: Tue Oct 10 18:59:19 2006 -->
<h3> Bias change monitoring</h3> 
the page <a href=http://b0sili01.fnal.gov/EBias/Bias.html>EBias<a> now shows a view of the change of the leakage currents for all the ladders. The script compares the change with the "expected" behaviour.
<!-- Author: Jose -->



<!-- Date: Tue Oct 10 19:17:01 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10018&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10019' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10022&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10023' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10020&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10021' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10024&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10025' ></a></center>
<!-- Author: Ankush -->
<!-- Comment: Tue Oct 10 19;18;18 comment by...Ankush -->
<h3>SVXMon plots for COSMICS Run (Run #:224637)</h3>

<p>For reference, these are the SVXMon reference plots before the plug pull.</p>




<!-- Date: Tue Oct 10 20:45:27 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><h3>b0sili01 and b0sili02 problems</h3> 
 
<p>b0sili01 is stuck.  It is not pingable and not responding at the keyboard. So an emergency reboot will be needed.</p></td></tr></td></table>
<!-- Author: Jose & Ankush -->
<!-- Comment: Wed Oct 11 02;07;45 comment by...Mark -->
Any idea what caused this?  Also, have the backup disks arrived from TigerDirect yet?
<!-- Date: Tue Oct 10 22:59:43 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10026&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10026' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10027&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10027' width='300'></a></center>
<!-- Author: SVX Alcove and Manifold temps during the warm-up, compliments of Jennifer :-) -->


<!-- Date: Tue Oct 10 23:00:40 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10028&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10028' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10029&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10029' width='300'></a></center>
<!-- Author: ISL Alcove and Manifold temps during the warm-up, compliments of Jennifer :-) -->




<!-- Date: Wed Oct 11 08:59:27 2006 -->
<h3>BLMs and diamonds removed</h3> 
We have removed the BLMs and diamonds in order for the East plug to be pulled.
<!-- Author: Ulrich -->


<!-- Date: Wed Oct 11 09:11:54 2006 -->
<h3>Things to do for the next 7 days</h3> 
 
<p>So while the Tevatron magnets gets repaired, here's a list of things we could do:</p> 
 
<ol> 
<li>ISL Cooling leak fix<br> 
This has <b>top priority</b>.  This initial phases are already underway.<br>  Ulrich will be tied up by this.</li> 
 
<li>Replacing bad RH sensor<br> 
During the summer, one of the old RH sensor went bad and was taken out of the interlock. As the plug is opened, the RH sensor will be replaced<br> 
Ulirch + Jenninfer<br>  
</li> 
 
<li>Adding labels to PS cables<br> 
Jen et al. 
</li> 
 
 
<li>Running Test-stand in run Control<br> 
This was being pursued by Mark & Conor.  Maybe one of the new DAQ people can get involved here.</li> 
 
 
 
<li>Preparatory work for adding an extra VRB crate<br> 
Jonathan Lewis came in yesterday and told us the limiting factor at Level 2 was the readout from the ISL/L00 crates. This has half-expected.  Although the ISL/L00 crates are balanced, the load/EVB is still big.   
 
So we need to consider adding an extra VRB crate and moving some of the ISL/L00 VRBs into it.  However I wish to proceed slowly on this.  I want to make sure we are the bottle neck and then we know what have to do !! 
 
Any moving of fibres and VRBs should only be done <b>AFTER</b> the plug pull.  We will need a working DAQ to check out the detector!! 
</li> 
 
 
<li>Misc detector work & quiet time studies<br> 
Go through Sasha's list of jobs.  This should included reseating the 6U/9U adapter for the MVME CPU in b0fib07.<br> 
Sasha et al 
</li> 
 
<li>b0sili01 && b0sili02 maintenance work<br> 
There are still some issues with these machines with respect to the RAID controller.  We could use the down time to investigate this.<br> 
Jose et al</li> 
 
<li>Migration of ADCMon, etc to b0sili**</li>
</ol>

<!-- Author: Ankush -->



<!-- Date: Wed Oct 11 12:58:01 2006 -->
<h3>ISL repair preparation</h3> 
The plug has been pulled successfully this morning. 
A couple of things in preparation for the ISL can be found here: 
<ul> 
<li>Finalized the <a href="http://www-cdf.fnal.gov/~husemann/internal/expert/cooling/doc/jha_20061011.pdf">JHA</a></li> 
<li>Figured out how to use iFix in the collision hall (secret procedure...)</li> 
<li>Got monkey shit and T fittings from Ken Schultz</li> 
</ul>
<!-- Author: Ulrich -->


<!-- Date: Thu Oct 12 09:36:08 2006 -->
<h3>Bore Work in progress</h3> 
 
<p>The bore work started at 7AM.  Ulrich, Warren Bowman & Ken Schultz are in teh collision hall attempting to debug the ISL cooling.  Dell, Doug and Jose are also in the collision hall assisting.  Jennifer :-) is in the cryo area monitoring iFIX.</p>
<!-- Author: Ankush for the ISL debugging crew -->


<!-- Date: Thu Oct 12 22:18:40 2006 -->
<h3>Summary of Bore Access for ISL Cooling Leak</h3> 
 
<h4>Leak Hunting</h4> 
<ul> 
<li>Initial Rate-of-Rise (RoR) test for East ISL: approx. 1.6 psi/min</li> 
<li>First round of attempts to find leak: 
<ol> 
  <li>Cover fitting with Apiezon Q sealing compound (monkey shit)</li> 
  <li>Perform RoR test to check if vacuum improved</li> 
  <li>If no improvement: continue with next fitting</li> 
</ol> 
</li> 
<li>After a couple of hours, all ISL fittings on the COT face were covered, but the vacuum did not improve. Suspicion: monkey shit does not work well on plastic compression fittings, does not stick, does not cover gaps.</li> 
<li>Visual inspection of all ISL cooling lines on COT face: searching for damage, e.g. by soldering iron → nothing found.</li> 
<li>Second round of attempts to find leak: 
<ol> 
  <li>Cover all fittings with epoxy (at atmospheric pressure to avoid sucking epoxy into the cooling lines)</li> 
  <li>Perform RoR test: marginal improvement of vacuum</li> 
</ol> 
<li>Modified RoR test (open individual valves): attempt to find bad line from variations in RoR → not conclusive 
<li>Visual inspection of manifolds and vacuum jacks in 30° crack: no fittings which could break, no obvious damage. Problem: partly not accessible (covered by cables, ...)</li> 
</ul> 
 
 
<h4>Conclusions</h4> 
 
<ul> 
<li>Bottom line: we were <b>not able to find a leak in the ISL cooling lines on the East COT face</b>.</li> 
<li>We stick to the following decision (made during the planning meeting and laid out in the JHA): we will <b>not attempt a leak repair inside the silicon baggie</b>. Reason: the potential damage is larger than the expected gain. Also leak hunting around the 30° crack is considered too dangerous.</li> 
</ul> 
 
<h4>Further ideas</h4> 
 
<ul> 
  <li><em>Helium sniffer</em>:<br> 
  Idea: Spray helium on fittings, connect vacuum pump with built-in sniffer to return side. Problem: vacuum pump must not get wet, impossible with our water/glycol mixture → not further pursued</li> 
  <li><em>Install more powerful vacuum pump</em>:<br>The current ISL vacuum pumps cannot create a vacuum better than 2 psi. Better suction on the air separator may increase the flow and flush air bubbles out more effectively → Very interesting idea, would need engineer to size pump.</li>   
</ul> 
 
<h4>Detailed checkout of Silicon system</h4> 
<ul> 
  <li>Bring every ladder to STANDBY and run in SVXDAQ</li> 
  <li>Bias every ladder and check if it draws bias current</li> 
  <li>Results:</li> 
  <ul> 
    <li>SVX: everything fine, except e084 (does not return data). This ladder was re-included during the Problem DB clean-up and has a history of problems.</li> 
    <li>ISL: everything fine</li> 
    <li>L00: everything fine</li> 
  </ul> 
  <li>Bottom line: <b>everything looks fine, we survived the bore access</b>! 
</ul> 
 
<h4>Problems: Biggest Bummer First</h4> 
<ul> 
<li><em>Unnoticed SVX trip</em>:<br>Around 13:00, the flow to the entire Silicon, including SVX, tripped. A possible reason is that we bumped into a dew point sensor cable during the bore work. The trip was not noticed until 17:00! Until then, the Silicon was already warmed up to about 20°C (from 0°C). <font color=red>Lesson learned: Next time we must be extremely careful in ignoring only alarms we expect to go off during our work, have somebody dedicated to monitoring the cooling/interlock system, and instruct the shift crew to inform us of any additional alarms.</font></li> 
<li><em>Manual valve for Portcard East return closed accidentally</em>:<br>When we re-established flow to the detector, we tripped immediately on over-pressure. The reason was found to be the return valve of the East Portcard lines, which had been closed accidentally. Luckily the interlock protects us from further damage due to over-pressurized cooling lines, but we should not rely on that. 
<font color=red>Learn: check <em>every</em> valve around the ones we worked on before re-establishing flow, not just the ones you think have been touched!</font></li> 
<li><em>Manual valve for CCE1 return leaking</em>:<br> 
The CCE1 manual return valve showed a leak. We found a Kim Wipe underneath the valve. Nobody knew who put it there and why he or she did not notify anybody in the light of the ISL cooling problem. We tightened the body of the valve and successfully stopped the leaking. Unfortunately, this did not solve the cooling problem. 
</li> 
<li><em>Pressure transducers on COT face not labeled</em>:<br> 
During the first attempts to localize a leak, we were unsure which cooling line is which. So we disconnected the readout cables of the pressure transducers one by one to identify and label them properly.</li> 
<li><em>Temperature trip during checkout</em>:<br> 
After the cooling work, the COT baggie was re-sealed, and a CDF Procedure 13 checkout was performed. Only then we were allow to turn our low and high voltage back on. We stayed at a temperature set point of 15°C for ISL (although 10°C should be fine if the COT baggie is in place), which apparently was too high for some SVX Portcards. This caused a temperature-driven PS trip in one bulkhead. We lowered ISL chiller set point to 12°C, and the rest of the checkout went fine. Over night, we return to 15°C.</li> 
</ul> 
 
<h4>Additional Project: Dew Point Sensor replacement</h4> 
<ul> 
  <li>Initial idea: swap out bad East COT face dew point sensor, hook spare Silicon baggie sensor to readout of broken old Silicon baggie sensor → 1/2 hour job...took us 3 hours after all</li> 
  <li>Problem I: The bad COT face sensor had a flaky connector (as predicted by Bob Wagner), but may otherwise have been fine. We swapped it out anyway, because the type of sensor initially used in the system is known to fail. We had to re-crimp the flaky connector. 
  <li>Problem II: The connection for the bad COT face sensor seems dodgy. One of the ground lines of the sensor was done with an un-insulated wire inside the cable.</li> 
  <li>Problem III: The connectors of the Silicon baggie sensors were hidden behind Silicon readout cables and hard to access without touching anything. We decided to cut the connectors off and re-do them closer to the point where they are connected. Unfortunately, we could not get the spare temperature sensor running because we could not figure out how the original sensor was wired. We tried all possible combinations for 4-wire RTDs, but none worked. So we left the sensor reading 0 V (i.e. -200°C). The idea is to use the temperature reading of the neighboring sensors in the dew point interlock.</li> 
  <li>To do: re-include dew point sensors in interlock logic. 
</ul> 
 
 
<h4>Acknowledgments</h4> 
<ul> 
  <li>The leak hunters: Ken Schultz, Warren Bowman, KC Cahill, Doug Glenzinski, Del Allspach</li> 
  <li>The COT crew: Bob Wagner, Morris Binkley, Eiko</li> 
  <li>Cooling & dew point sensor work: CDF's own Jennifer:-)</li> 
  <li>The checkout crew: Jose, Ignacio, Juan Pablo, Ricardo</li> 
</ul> 
  
<!-- Author: Ankush & Ulrich -->


<!-- Date: Thu Oct 12 22:36:04 2006 -->
<h3>Detector checkout</h3> 
 
<p>After the HV permit was returned, the detector checkout commenced.  The procedure to check out each wedge one by one.  For every wedge we did the following: 
 
<ul> 
<li>check you can turn it ON</li> 
<li>check it initialises with SVXDAQ</li> 
<li>check it returns data with SVXDAQ</li> 
<li>check it draw a BIAS current</li> 
</ul> 
 
<p>Two pairs worked together; one pair worked on SVX while the other pair worked on ISL/L00.</p> 
 
<p>In the check out the following was found:</p> 
 
<ul> 
<li>e132: It appears the Bit 0 problem has reappeared.  This may get better when the detector temperature is lowered.</li> 
<li>e22: During running with SVXDAQ, there were 1/2 errors per ladder.</li> 
<li>e084: This failed to return any data at all.  However this was a ladder brought back during the PDB review.  It already has some history of not functioning properly. We will need to run this ladder again when the detector is cold.</li> 
<li>e264: There was one error while running in SVXDAQ<li> 
<li>f204: ~70% 00 sequence error rate.  This may be realted to the temperature.  However this ladder initialsed with no problems.  We will need to re-examine this ladder once the detector is cold.</li> 
</ul> 
 
<p>Overall it appears the detector is in tact after the Bore work and warming up SVX to 20C(!!).  The next step is for the plug to be reinserted and to cool down the detector back to its normal operating temperature.  Once the detector is back up, we shall request a long COSMICs run to double check the system.</p>
<!-- Author: Ankush, Jose,  Juan-Pablo, Ignacio  and Ricardo -->


<!-- Date: Thu Oct 12 22:40:48 2006 -->
<h3>Event Size Test</h3> 
 
<p>While the bore work was going on, JDL and Conor were testing L3/EVB to see the impact of large data sizes affects the rate into L3. The results cna be found in the  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=760&frame=2&anchor=16:00:30.620'> 
CDF Shift elog</a>.  This is of interest as it has consequences for us.</p> 
 
  
<!-- Author: Ankush -->


<!-- Date: Thu Oct 12 22:45:18 2006 -->
<h4>Wrapping up the cooling</h4> 
At the end of a long day, we have: 
<ul> 
<li>Returned to 0°C (SVX) and 15°C (ISL)</li> 
<li>Unsilenced all alarms except: PS-CAEN-OFF, SVX-IA-CONDUCT, ISL-IA-CONDUCT, SVX-TE-PCE1B-1, SVX-TE=PCW1B-1, TE-CCwL00-3</li> 
</ul> 
Note also that I deactivated the iFix dew point alarms for the temperature sensor we could not get running.
<!-- Author: Ulrich -->


<!-- Date: Fri Oct 13 07:17:54 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10042&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10043' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10041&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10041' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10040&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10040' width='300'></a></center>
<!-- Author:  Juan Pablo & Ignacio -->
<!-- Comment: Fri Oct 13 07;36;38 comment by... JP & IR -->
<pre>What you see is first the occupancy distribution (from SVXMon)
for IB1W4L0 (one of the slowest ladders according to David Stuart),
second, the noise distribution from this ladders (from Jason,
run 223500) and last, the pedestal distribution.</pre>
<!-- Comment: Fri Oct 13 07;53;36 comment by... JP & IR -->
This is a category of ladder in which we can not help that
much by increasin the threshold. The high occupancy is comming
from the high noise. This ladders seems a candidate for an unbiased ladder (already noticed <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=267&frame=2&anchor=14:34:05'>
here </a> by Antonio). This category has very few ladders
<!-- Comment: Fri Oct 13 09;13;15 comment by...Ignacio -->
Just mention that the pedestal distribution  are taken from 
a DPS OFF calibration run, so the actual threshold is not 9 
but it is shifted by a value per chip.
<!-- Date: Fri Oct 13 07:18:34 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10036&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10036' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10037&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10037' width='300'></a><a href='/elog/notebooks/silicon/Fri_Oct_13_2006_071504.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10039' ></a></center>
<!-- Author:  Juan Pablo & Ignacio -->
<!-- Comment: Fri Oct 13 07;38;27 comment by...JP & IG -->
<pre>What you see is first the pedestal distribution 
for IB5W4L0, a ladder with high occupancy in some of their chips,
second, the noise distribution from this ladders (from Jason,
run 223500) and last, the occupancy distribution (from SVXMon).</pre>
<!-- Comment: Fri Oct 13 07;59;58 comment by... JP & IR  -->
<pre>This ladder is in the category in which we do believe we
can help greatly (by raising the threshold). The source
is not noise but the pedestal shape (the so called wings)
[when using DPS, this produces a lot of channels above the
threshold and gives us high occupancy]. Increasing the
threshold will help considerably because the occupancy is
~50 % that means that half of the channels have a pedestal
>=9 (current threshold) on the last chip and the size of
the wing (1st plot on the left) is not too big (~10 ADC).</pre>
<!-- Date: Fri Oct 13 07:33:08 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10044&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10044' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10045&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10045' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10046&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10047' ></a></center>
<!-- Author: Juan Pablo & Ignacio -->
<!-- Comment: Fri Oct 13 07;39;26 comment by...JP & IR -->
<pre>What you see is first the pedestal distribution 
for IB5W5L0, a ladder with high occupancy in one of its chips,
second, the noise distribution from this ladders (from Jason,
run 223500) and last, the occupancy distribution (from SVXMon).</pre>




<!-- Comment: Fri Oct 13 08;01;48 comment by...JP & IR -->
<pre>Finnaly this ladder, though it is in the same category as the
previous one, will not get that much benefit from raising the
threshold (the size of the wing is quite big)</pre>


<!-- Date: Fri Oct 13 08:31:35 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><h3>CAEN 5V ENABLES OFF</h3></td></tr></td></table>
<!-- Author: Ankush -->
<!-- Comment: Fri Oct 13 08;33;45 comment by...Ankush -->
<p>The 5V enables were turned on last night for the detector check out.  However I stupidly forgot to document this. So they were left on overnight.  For the time being, the 5V enables will be off until the plug is closed.</p>

<!-- Comment: Fri Oct 13 08;50;09 comment by...Ankush -->
<table border=0><td><tr><td bgcolor=#e0e030><h3>Keys back by 4pm</h3>

<p>Don't forget to return the access keys by 4pm!!</p></td></tr></td></table>



<!-- Date: Fri Oct 13 09:22:32 2006 -->
<h4> 
<a href="http://www.fnal.gov/pub/today/archive_2006/today06-10-13.html"> 
<font color="pink"> 
Her Pinkness in Fermistan today</font> 
</a> 
</h4> 
 
<p><em>...so the silicon mandate had inflence....and of course we did this the Chicago way...</em></p>
<!-- Author:        -->
<!-- Comment: Fri Oct 13 11;53;58 comment by...Her Pinkness :-) -->
YAY!


<!-- Date: Fri Oct 13 12:16:30 2006 -->
<h3>Re-entering the bore</h3> 
 
<p>The COT is still having problems around the region where the new humdity sensors were installed.  So the COT-folks may reenter the bore.</p> 
 
<p><b>Silicon remains OFF until furter notice</b></p>
<!-- Author: Ankush -->
<!-- Comment: Fri Oct 13 15;07;09 comment by...Ankush -->
<h3>Problem gone....?</h3>

<p>The COT folks tried some further tricks which invovled power cycling some elctronics.  Then the noise dissapeared and has not come back.  Fortunatly they did not have to re-enter the bore. So that is good from our side.</p>

<p>However as all the techs have gone home, the plug will remain open over the weekend. But no one will be allowed in the collision hall over the weekend.</p>

<p>The detector will remain off over the weekend and we will ask the ACEs to watch the dewpoints.</p>
<!-- Comment: Fri Oct 13 15;57;28 comment by...Ankush -->
<h3>COT are back on</h3>

<p>The COT are now resuming Argon/Ethane flows and they are switching on their electronics. But the plug will remain open over the weekend.</p>

<p>I guess we shall wait for the plug to be closed on Monday and then we shall cool down and power up the detector.  This will be followed by lots and lots of COSMICs.</p>
<!-- Date: Fri Oct 13 14:51:20 2006 -->
<h3>Interlock Code Change</h3> 
After yesterday's bore work I modified the PLC code used for the Silicon interlock system. Here is a list of changes: 
<ul> 
<li>Re-enabled dew point interlocks for the East COT face and the East Silicon baggie sensors</li> 
<li>Adjusted calibration constants for newly installed relative humidity sensors</li> 
<li>Modified special function program #3: temperature reading of East Silicon baggie 2 sensor is now used for dew point calculation for East Silicon baggie 1.</li> 
<li>Adjusted ranges of engineering units for new sensors</li> 
</ul> 
The new sensors and calibration constants are: 
<table border=1 cellpadding=5> 
<tr><th>Sensor</th><th>Label</th><th>Calibration</th><th>% RH Range for 0-5 V</th></tr> 
<tr><td>East Silicon Baggie 1</td><td>new RH-A</td><td>RH=(V-0.838)/0.0310</td><td>-27.0 - 134.3</td></tr> 
<tr><td>East COT Face</td><td>new RH-D</td><td>RH=(V-0.930)/0.0312</td><td>-29.8 - 130.4</td></tr> 
<tr><td>East COT Face Spare</td><td>new RH-E</td><td>RH=(V-0.915)/0.0313</td><td>-29.2 - 130.5</td></tr> 
</table>
<!-- Author: Ulrich -->




<!-- Date: Fri Oct 13 17:13:36 2006 -->
I have performed the regular bi-weekly reboot of SVXIICON today.
<!-- Author: Ulrich -->



<!-- Date: Sun Oct 15 17:28:35 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10030&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10030' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10032&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10033' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10034&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10035' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10036&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10036' width='300'></a><a href='/elog/notebooks/silicon/Fri_Oct_13_2006_071504.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10039' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10040&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10040' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10042&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10043' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10044&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10044' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10046&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10047' ></a></center>
<!-- Author:  Juan Pablo. -->
<!-- Comment: Sun Oct 15 17;29;57 comment by... Juan Pablo -->
<pre>
Examples of misbehaving chips in ISL ladders
Pedestal (from calibrations) and occupancy (SVXMon)</pre>


<!-- Date: Sun Oct 15 17:44:20 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10066&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10067' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10068&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10069' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10072&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10073' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10074&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10075' ></a></center>
<!-- Author:  Juan Pablo and Mark Mathis -->
<!-- Comment: Sun Oct 15 17;46;01 comment by...Juan Pablo and Mark Mathis (first appearance in elog ! ! ) -->
<pre>In the 1st three plots, what you see is the following :
Each plot with 4 graphs. Each graph represents a chip. 
The name of the ISL ladder is given in the last chip.
What you see is the percentage of channels reading out above
an additional thresold given in the x-axis (so the 1st point
represents the current number of channel being typically read
out when using an sparsification threshold of 9; the rest intents
to represent how many channels would be read out if we would 
increase the sparsification threshold by the amount given in the
x axis). Notice how all of them expect 1 go below 10 % when 
adding just 4 ADC counts more to the sparsicifacion threshold.</pre>

<!-- Comment: Sun Oct 15 17;47;33 comment by...Juan Pablo et al (Mark, Jos&#39;e E., Ignacio and the big fishes ...) -->
<pre>The histogram represents the number of addtional ADC counts we
would need to add to all the chips in ISL that have > 80%
of channels being read out so that the final number of channels
to be read would be < 10 %. 
As you can see most of them need just 6 or less additional
counts. We know from our efficiency of charge collection studies
that this do not mean any loss whatsoever in the charge
collection efficiency.
</pre>


<!-- Comment: Sun Oct 15 17;58;27 comment by...Juan Pablo. -->
<pre>Why this has changed w.r.t. yesterday ? 
I was not simulating DPS properly.
Ignacio is cross checking my DPS simulation.</pre>

<!-- Comment: Sun Oct 15 18;00;40 comment by...Juan Pablo. -->
<pre>Ah, there is also the fact that some ladders like 
IB5W5L0 (see pedestal distribution above) show a negative
pedestal. I had to start the counter at -50 to cope with that.</pre>

<!-- Comment: Sun Oct 15 18;45;33 comment by...Ankush -->
<p>Stictly speaking, the four-graphs of each ISL ladder are not the chips but a group of 4 chips which make up each side of the ganged pair.  So each graph is a collection of 4 chips.</p>

<!-- Comment: Sun Oct 15 19;23;58 comment by... JP -->
<pre>Te points on the last plot have an scale factor of 0.9
(there is still a 10 % noise left). I am sure though I have
to apply that factor.</pre>


<!-- Date: Sun Oct 15 19:27:32 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10079&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10080  width='300' align='top'></a></td><td>I am repeating the study but starting to count ladders with 
chips that have >10% of channels with an occupancy above the mean</td></tr></table>
<!-- Author:  Juan Pablo -->


<!-- Date: Sun Oct 15 20:47:24 2006 -->
<h3> 
Monday : tickler<a href='http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=322&frame=2&anchor=23:09:12'> studies </a> 
 did not affect us (but we decided to go to stdby anyway during approx. 1 hour). <br> 
 Sasha list of problematic ladders :<a href='http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=322&frame=2&anchor=14:45:12'> to do list </a> <br> 
<br> 
Tuesday: BOOM, power glitch and Tev quench ... lost 1 magnet. No data till this week. <a href='http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=322&frame=2&anchor=03:40:32'> Crash bottom event </a>. He did it right but it was not necessary. Recovery was fast (after uncrashing the button)<br> 
<br> 
Wednesday : BLMs and diamonds removed<br> 
Thrusday : <a href='http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=322&frame=2&anchor=22:18:40'> ISL cooling leak hunt </a>  and <a href='http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=322&frame=2&anchor=22:36:04'> detector checkout </a> 
(went fine). <br> 
Event Size Test.<br> 
Friday-Sunday: plug open ... ISL threshold studies (no cosmics though). 
</h3>  
<!-- Author: Juan Pablo -->


<!-- Date: Mon Oct 16 09:06:19 2006 -->
<h3>Monitoring summary:</h3> 
I have checked (with the manual ADCMon) the last physics runs taken before the "rat attack". They are fine (i.e. only the known problems).<br> 
The only issue regarding monitoring is the pain of not having the web browser working.
<!-- Author: Oscar -->