<!-- Title: 12:07:19  Mon Jul 12 2004 -->
<!-- Crewchief: Florencia -->
<!-- Op1: David (detector) -->
<!-- Op2: Azizur (monitoring) -->
<!-- Op3: Julia (DAQ) -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>.</pre>


<!-- Date: Mon Jul 12 14:57:13 2004 -->
<pre>From:   canelli@fnal.gov 
Subject: update 
Date: July 12, 2004 2:07:01 PM CDT 
To:   rappocc@fnal.gov, sforrest@fnal.gov, stanitz@fnal.gov, dkclark@brandeis.edu, gris@fnal.gov, petra@fnal.gov, rslu@fnal.gov 
 
Hello, 
 
It looks like we might have an abort at any time. If that happens 
we will have at least 4 hours of quiet time. 
 
They will try to keep this store until tomorrow morning.  If they can, 
the quiet time will be tomorrow. 
 
There is no clear plan more than we will have more than 4 hours quiet time 
between now and tomorrow at noon. 
I'll page SRC and DETECTOR unless you tell me otherwise. 
 
Best, 
 
Florencia 
</pre>
<!-- Author: Florencia -->


<!-- Date: Mon Jul 12 15:02:27 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4624&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4625  width='300' align='top'></a></td><td>SVT plot</td></tr></table>
<!-- Author: Florencia -->

<!-- Date: Mon Jul 12 16:26:28 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W4L2 
<li>problem n: 188 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Diagnosis
<li>entered by: rahaman 
<li>description is: Silicon error rate reporter gives 99% error rate due to unknown channel and also 100% bad events. This is seen over the whole month.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W4&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Jul 12 16:31:03 2004 -->
<pre>From Marcel  
 
===================================================== 
Attention !!!. CER_SVXMON_HALT_RECOVER_RUN_ERROR !!! 
errorfile184060.log- 
errorfile184060.log- Stuck Cellid I/B5/W5/L1/C4-7 . 
These are the ladders 
 
 
 
  Stuck Cellid I/B0/W0/L0/C4   5 
  Stuck Cellid I/B3/W1/L4/C0   2 
  Stuck Cellid I/B3/W1/L4/C4   1 
  Stuck Cellid I/B3/W1/L4/C8   1 
  Stuck Cellid I/B4/W3/L2/C12 29  <<<<<<<<<<<<<< is masked 
  Stuck Cellid I/B5/W5/L1/C4   3 
  Stuck Cellid S/B1/W5/L4/C0   2 
  Stuck Cellid S/B1/W5/L4/C7  15  <<<<<<<<<<<<<<<<<<<< check 
  Stuck Cellid S/B2/W7/L1/C0   2 
  Stuck Cellid S/B4/W6/L3/C0   3 
  Stuck Cellid S/B4/W6/L3/C6   1 
 
These are the badguys for 184xxx 
 
========================================= 
We should check e154 during quiet time.</pre>
<!-- Author: Rong-Shyang -->
<!-- Comment: Tue Jul 13 09;40;58 comment by...Rong-Shyang -->

I should check the problem database first.
e154 is the famous one with BEclock kludge then bit errors, <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W5&layer=L4"> see PBDB</a>. Maybe that's the reason causing confusion in SVXMon to issue HRRs.
<!-- Comment: Wed Jul 14 07;20;42 comment by...SCN -->
Might be worth it to make sure the FIB for e154 has the correct
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=157&frame=2&anchor=13:05:47'>
firmware</a> although if it didn't I guess you'd get the error all the time. It also could be that the kludge needs tuning (but that has been attempted before too).  Or, it just might be the happenstance of several low bits conspiring to give you a stuck cap id.  You could check by comparing the cell id with those of a different ladder in the same events.
<!-- Date: Mon Jul 12 16:47:58 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W4L2 
<li>problem n: 188 
<li>Status: unfixable
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: rong 
<li>description is: This is bit 6 low belongs to thread 944. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W4&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Jul 12 18:20:35 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4626&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4626' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4627&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4627' width='300'></a></center>
<!-- Author: Marcel -->
<!-- Comment: Mon Jul 12 18;28;58 comment by...Marcel -->
<h4> VRB studies </h4>
This is the number of VRB badByteCount errors as from basically beginning of the year. The left plots shows the errors over time, the right one the errors per crate.
These things only occured after the march shutdown basically. Although ISL crate b0eb24 suffers the most, also other crates are affected.<br>
This raises some points
<ul>
<li> It is not a single bad  VRB, this is spread over many crates</li>
<li> We don't touch the VRB's while running only the event builder does</li>
<li> what has changed after March shutdown </li>
</ul>
It also looks, like flashing the firmware of all the VRB's in b0eb24 may not solve the problem. It might well be, that we are not the bad guys at all. We don't have anything to do with the 
DAQ VRB's at all, and they see the same problem. 
These things happen without any preference for begin or end of run. These errors also occur without the silicon crates in for the DAQ VRB's. <br>
The next thing to check is a dependence on L2 Rate and test it using the software event builder as suggested by SCN and see wheter we get these problems at all.



<!-- Date: Mon Jul 12 18:29:38 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4628&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4628' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4629&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4629' width='300'></a></center>
<!-- Author: Marcel -->
<!-- Comment: Mon Jul 12 18;34;53 comment by...Marcel -->
<h4> CAEN supply madnesses</h4>
This shows the number of communication losses/ hockerizations/ spontaneous transitions that I found scanning manually through the silicon elog starting at Jan 2004, left per crate, right per month.
The ration between west:east is 21:10 , so there is a preference for the west side (the protons come from there). 
It also looks like as we would get these things more often now.







<!-- Date: Tue Jul 13 11:23:15 2004 -->
<H3> Reminder SRC and Triggerrates </h3> 
As there has been a slight discussion about SRC and trigger rate, here a recap/reconstruction of a test done by Jonathan, Greg, Steve and myself. 
The original stuff was lost thanks to the elog wipeout. 
<TABLE FRAME=BOX CELLSPACING=0 COLS=6 RULES=GROUPS BORDER=1> 
	<COLGROUP><COL WIDTH=86></colgroup> 
	<COLGROUP><COL WIDTH=101></colgroup> 
	<COLGROUP><COL WIDTH=86></colgroup> 
	<COLGROUP><COL WIDTH=118></colgroup> 
	<COLGROUP><COL WIDTH=86></colgroup> 
	<COLGROUP><COL WIDTH=86></colgroup> 
	<TBODY> 
		<TR> 
			<TD WIDTH=86 HEIGHT=16 ALIGN=CENTER><B><BR></b></td> 
			<TD WIDTH=101 ALIGN=CENTER><B>Total L1 Rate</b></td> 
			<TD WIDTH=86 ALIGN=CENTER><B>High PT</b></td> 
			<TD WIDTH=118 ALIGN=CENTER><B>High PT Prescale</b></td> 
			<TD WIDTH=86 ALIGN=CENTER><B>B L1 Rate</b></td> 
			<TD WIDTH=86 ALIGN=CENTER><B>Deadtime</b></td> 
		</tr> 
	</tbody> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=16 ALIGN=RIGHT SDVAL="1" SDNUM="1033;">1</td> 
			<TD ALIGN=RIGHT SDVAL="28000" SDNUM="1033;">28000</td> 
			<TD ALIGN=RIGHT SDVAL="600" SDNUM="1033;">600</td> 
			<TD ALIGN=RIGHT SDVAL="100" SDNUM="1033;">100</td> 
			<TD ALIGN=RIGHT SDVAL="27000" SDNUM="1033;">27000</td> 
			<TD ALIGN=RIGHT SDVAL="0.5" SDNUM="1033;">0.5</td> 
		</tr> 
		<TR> 
			<TD HEIGHT=16 ALIGN=RIGHT SDVAL="2" SDNUM="1033;">2</td> 
			<TD ALIGN=RIGHT SDVAL="30000" SDNUM="1033;">30000</td> 
			<TD ALIGN=RIGHT SDVAL="5000" SDNUM="1033;">5000</td> 
			<TD ALIGN=RIGHT SDVAL="10" SDNUM="1033;">10</td> 
			<TD ALIGN=RIGHT SDVAL="25000" SDNUM="1033;">25000</td> 
			<TD ALIGN=RIGHT SDVAL="1.1" SDNUM="1033;">1.1</td> 
		</tr> 
		<TR> 
			<TD HEIGHT=16 ALIGN=RIGHT SDVAL="3" SDNUM="1033;">3</td> 
			<TD ALIGN=RIGHT SDVAL="36000" SDNUM="1033;">36000</td> 
			<TD ALIGN=RIGHT SDVAL="23000" SDNUM="1033;">23000</td> 
			<TD ALIGN=RIGHT SDVAL="2" SDNUM="1033;">2</td> 
			<TD ALIGN=RIGHT SDVAL="15000" SDNUM="1033;">15000</td> 
			<TD ALIGN=RIGHT SDVAL="9" SDNUM="1033;">9</td> 
		</tr> 
		<TR> 
			<TD HEIGHT=16 ALIGN=RIGHT SDVAL="4" SDNUM="1033;">4</td> 
			<TD ALIGN=RIGHT SDVAL="22000" SDNUM="1033;">22000</td> 
			<TD ALIGN=RIGHT SDVAL="22000" SDNUM="1033;">22000</td> 
			<TD ALIGN=RIGHT SDVAL="2" SDNUM="1033;">2</td> 
			<TD ALIGN=RIGHT SDVAL="0" SDNUM="1033;">0</td> 
			<TD ALIGN=RIGHT SDVAL="2" SDNUM="1033;">2</td> 
		</tr> 
		<TR> 
			<TD HEIGHT=16 ALIGN=RIGHT SDVAL="5" SDNUM="1033;">5</td> 
			<TD ALIGN=RIGHT SDVAL="52000" SDNUM="1033;">52000</td> 
			<TD ALIGN=RIGHT SDVAL="43000" SDNUM="1033;">43000</td> 
			<TD ALIGN=RIGHT SDVAL="1" SDNUM="1033;">1</td> 
			<TD ALIGN=RIGHT SDVAL="9000" SDNUM="1033;">9000</td> 
			<TD ALIGN=RIGHT SDVAL="23" SDNUM="1033;">23</td> 
		</tr> 
		<TR> 
			<TD HEIGHT=16 ALIGN=RIGHT SDVAL="6" SDNUM="1033;">6</td> 
			<TD ALIGN=RIGHT SDVAL="28000" SDNUM="1033;">28000</td> 
			<TD ALIGN=RIGHT SDVAL="400" SDNUM="1033;">400</td> 
			<TD ALIGN=RIGHT SDVAL="100" SDNUM="1033;">100</td> 
			<TD ALIGN=RIGHT SDVAL="27600" SDNUM="1033;">27600</td> 
			<TD ALIGN=RIGHT SDVAL="0.5" SDNUM="1033;">0.5</td> 
		</tr> 
		<TR> 
			<TD HEIGHT=16 ALIGN=RIGHT SDVAL="7" SDNUM="1033;">7</td> 
			<TD ALIGN=RIGHT SDVAL="29600" SDNUM="1033;">29600</td> 
			<TD ALIGN=RIGHT SDVAL="3600" SDNUM="1033;">3600</td> 
			<TD ALIGN=RIGHT SDVAL="10" SDNUM="1033;">10</td> 
			<TD ALIGN=RIGHT SDVAL="26000" SDNUM="1033;">26000</td> 
			<TD ALIGN=RIGHT SDVAL="1.1" SDNUM="1033;">1.1</td> 
		</tr> 
		<TR> 
			<TD HEIGHT=16 ALIGN=RIGHT SDVAL="8" SDNUM="1033;">8</td> 
			<TD ALIGN=RIGHT SDVAL="36000" SDNUM="1033;">36000</td> 
			<TD ALIGN=RIGHT SDVAL="18000" SDNUM="1033;">18000</td> 
			<TD ALIGN=RIGHT SDVAL="2" SDNUM="1033;">2</td> 
			<TD ALIGN=RIGHT SDVAL="18000" SDNUM="1033;">18000</td> 
			<TD ALIGN=RIGHT SDVAL="7" SDNUM="1033;">7</td> 
		</tr> 
		<TR> 
			<TD HEIGHT=16 ALIGN=RIGHT SDVAL="9" SDNUM="1033;">9</td> 
			<TD ALIGN=RIGHT SDVAL="48000" SDNUM="1033;">48000</td> 
			<TD ALIGN=RIGHT SDVAL="37000" SDNUM="1033;">37000</td> 
			<TD ALIGN=RIGHT SDVAL="1" SDNUM="1033;">1</td> 
			<TD ALIGN=RIGHT SDVAL="11000" SDNUM="1033;">11000</td> 
			<TD ALIGN=RIGHT SDVAL="18" SDNUM="1033;">18</td> 
		</tr> 
		<TR> 
			<TD HEIGHT=16 ALIGN=RIGHT SDVAL="10" SDNUM="1033;">10</td> 
			<TD ALIGN=RIGHT SDVAL="28400" SDNUM="1033;">28400</td> 
			<TD ALIGN=RIGHT SDVAL="400" SDNUM="1033;">400</td> 
			<TD ALIGN=RIGHT SDVAL="100" SDNUM="1033;">100</td> 
			<TD ALIGN=RIGHT SDVAL="28000" SDNUM="1033;">28000</td> 
			<TD ALIGN=RIGHT SDVAL="0.5" SDNUM="1033;">0.5</td> 
		</tr> 
		<TR> 
			<TD HEIGHT=16 ALIGN=RIGHT SDVAL="11" SDNUM="1033;">11</td> 
			<TD ALIGN=RIGHT SDVAL="29500" SDNUM="1033;">29500</td> 
			<TD ALIGN=RIGHT SDVAL="3500" SDNUM="1033;">3500</td> 
			<TD ALIGN=RIGHT SDVAL="10" SDNUM="1033;">10</td> 
			<TD ALIGN=RIGHT SDVAL="26000" SDNUM="1033;">26000</td> 
			<TD ALIGN=RIGHT SDVAL="1" SDNUM="1033;">1</td> 
		</tr> 
		<TR> 
			<TD HEIGHT=16 ALIGN=RIGHT SDVAL="12" SDNUM="1033;">12</td> 
			<TD ALIGN=RIGHT SDVAL="36000" SDNUM="1033;">36000</td> 
			<TD ALIGN=RIGHT SDVAL="18000" SDNUM="1033;">18000</td> 
			<TD ALIGN=RIGHT SDVAL="2" SDNUM="1033;">2</td> 
			<TD ALIGN=RIGHT SDVAL="18000" SDNUM="1033;">18000</td> 
			<TD ALIGN=RIGHT SDVAL="7" SDNUM="1033;">7</td> 
		</tr> 
		<TR> 
			<TD HEIGHT=16 ALIGN=RIGHT SDVAL="13" SDNUM="1033;">13</td> 
			<TD ALIGN=RIGHT SDVAL="49000" SDNUM="1033;">49000</td> 
			<TD ALIGN=RIGHT SDVAL="37500" SDNUM="1033;">37500</td> 
			<TD ALIGN=RIGHT SDVAL="1" SDNUM="1033;">1</td> 
			<TD ALIGN=RIGHT SDVAL="11500" SDNUM="1033;">11500</td> 
			<TD ALIGN=LEFT><BR></td> 
		</tr> 
		<TR> 
			<TD HEIGHT=16 ALIGN=RIGHT SDVAL="14" SDNUM="1033;">14</td> 
			<TD ALIGN=RIGHT SDVAL="45000" SDNUM="1033;">45000</td> 
			<TD ALIGN=RIGHT SDVAL="37000" SDNUM="1033;">37000</td> 
			<TD ALIGN=RIGHT SDVAL="1" SDNUM="1033;">1</td> 
			<TD ALIGN=RIGHT SDVAL="13000" SDNUM="1033;">13000</td> 
			<TD ALIGN=RIGHT SDVAL="13" SDNUM="1033;">13</td> 
		</tr> 
		<TR> 
			<TD HEIGHT=16 ALIGN=RIGHT SDVAL="15" SDNUM="1033;">15</td> 
			<TD ALIGN=RIGHT SDVAL="47000" SDNUM="1033;">47000</td> 
			<TD ALIGN=RIGHT SDVAL="37000" SDNUM="1033;">37000</td> 
			<TD ALIGN=RIGHT SDVAL="1" SDNUM="1033;">1</td> 
			<TD ALIGN=RIGHT SDVAL="11300" SDNUM="1033;">11300</td> 
			<TD ALIGN=RIGHT SDVAL="16.5" SDNUM="1033;">16.5</td> 
		</tr> 
		<TR> 
			<TD HEIGHT=16 ALIGN=RIGHT SDVAL="16" SDNUM="1033;">16</td> 
			<TD ALIGN=RIGHT SDVAL="30000" SDNUM="1033;">30000</td> 
			<TD ALIGN=RIGHT SDVAL="3000" SDNUM="1033;">3000</td> 
			<TD ALIGN=RIGHT SDVAL="10" SDNUM="1033;">10</td> 
			<TD ALIGN=RIGHT SDVAL="23000" SDNUM="1033;">23000</td> 
			<TD ALIGN=RIGHT SDVAL="2.8" SDNUM="1033;">2.8</td> 
		</tr> 
		<TR> 
			<TD HEIGHT=16 ALIGN=RIGHT SDVAL="17" SDNUM="1033;">17</td> 
			<TD ALIGN=RIGHT SDVAL="30000" SDNUM="1033;">30000</td> 
			<TD ALIGN=RIGHT SDVAL="9000" SDNUM="1033;">9000</td> 
			<TD ALIGN=RIGHT SDVAL="10" SDNUM="1033;">10</td> 
			<TD ALIGN=RIGHT SDVAL="20000" SDNUM="1033;">20000</td> 
			<TD ALIGN=RIGHT SDVAL="3" SDNUM="1033;">3</td> 
		</tr> 
	</tbody> 
</table> 
The corresponding run numbers are <br> 
<pre> 
179217 
179215 
179214 
179212 
179211 
179208 
179205 
179202 
179199 
</pre>
<!-- Author: Marcel -->


<!-- Date: Tue Jul 13 11:49:15 2004 -->
<h3>SRC Work Summary</h3> 
We have tried to get a L2 w/o L1 error using 
<b>only silicon crates</b>. After roughly 100 transitions, 
we were not able to get an error. 
<br> 
<br> 
We obviously need to reproduce the error in order 
to debug it. What we will ask for is some time 
with silicon included in a cosmics run where we 
bring the system through various transitions (abort,reset, 
HRR, activate, all possible combinations) until 
we get a L2 w/o L1. 
<br> 
<br> 
We will then claim control of the system from the 
aces and try to track down the actual cause of the 
problem.
<!-- Author: Sal/Sebastian/Lashkar -->


<!-- Date: Tue Jul 13 13:41:19 2004 -->
<h3>SRC Saga Continues</h3> 
We got our quiet time. I am now having the ace run the 
system with silicon crates included (but the detector 
at standby of course). 
<ul> 
<li> Initially, both SRC's are happy (well, Dopey and 
Charming, but both are not in error) 
<li> First trial: 
<ul> 
<li> Brought through "activate", no errors occurred 
<li> Ended run via "END"  
</li> 
</ul> 
 
<li> Second trial: 
<ul> 
<li> Somehow upon "PARTITION", we got pipeline out of 
synch in 135 chips. 
<li> Continued with CONFIG 
<li> Went to ACTIVE without further problems 
<li> Ended run via ABORT 
<li> Ended cleanly, no errors from SRC 
</ul> 
 
<li> Third Trial: 
<ul> 
<li> Brought through ACTIVATE, no problems. 
<li> Ace mistakenly hit ABORT instead of RESET, try 
again 
</ul> 
 
<li> Fourth Trial 
<ul> 
<li> Brought through ACTIVATE, no problems 
<li> Now ended via RESET 
<li> Ended cleanly 
</ul> 
 
<li> Fifth Trial 
<ul> 
<li> Brought through ACTIVATE, no problem 
<li> Ended cleanly. 
</ul> 
 
</ul> 
<b>We have seen no errors in this trial. We are 
now out of time and must continue again.</b>  
<!-- Author: Sal, Rong, Sebastian, Lashkar -->



<!-- Date: Wed Jul 14 10:42:13 2004 -->
<pre>MCR does not see any proble with the electron lense and claims that a current (TL1COLI) above 4 mA is sufficient. Since the number of particles in the AG (T:AGIGI2, T:SLPAH[37]) are below the limit (3) and the AG losses are marginally below the limit (25kHz), we decided to turn the silicon back on. But we need to keep a close eye on these variables for the reminder of the store. </pre>
<!-- Author: Petra &Rong-Shyang -->

<!-- Date: Wed Jul 14 10:54:45 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W3L3 
<li>problem n: 660 
<li>Status: unfixable
<li>Type: jumper
<li>Action: IMON_limits
<li>entered by: canelli 
<li>description is: Change Imon limts to accomodate high trigger rates.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>950</td><td>950</td></tr>
<tr><td><b>Lower</b></td><td>900</td><td>900</td></tr>
<tr><td><b>Upper</b></td><td>1020</td><td>1040</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W3&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jul 14 10:56:35 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W4L4 
<li>problem n: 697 
<li>Status: unfixable
<li>Type: jumper
<li>Action: IMON_limits
<li>entered by: canelli 
<li>description is: Change Imon limts to accomodate high trigger rates.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1200</td><td>1200</td></tr>
<tr><td><b>Lower</b></td><td>1100</td><td>1100</td></tr>
<tr><td><b>Upper</b></td><td>1300</td><td>1325</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W4&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jul 14 11:06:40 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W9L0 
<li>problem n: 665 
<li>Status: fixed
<li>Type: jumper
<li>Action: IMON_limits
<li>entered by: canelli 
<li>description is: Change Imon limts to accomodate high trigger rates.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>350</td><td>350</td></tr>
<tr><td><b>Lower</b></td><td>341</td><td>341</td></tr>
<tr><td><b>Upper</b></td><td>410</td><td>430</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W9&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jul 14 11:08:04 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W8L0 
<li>problem n: 415 
<li>Status: unfixable
<li>Type: jumper
<li>Action: IMON_limits
<li>entered by: canelli 
<li>description is: Change Imon limts to accomodate high trigger rates.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>371</td><td>371</td></tr>
<tr><td><b>Lower</b></td><td>302</td><td>302</td></tr>
<tr><td><b>Upper</b></td><td>399</td><td>430</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W8&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jul 14 11:09:51 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W10L4 
<li>problem n: 536 
<li>Status: unfixable
<li>Type: jumper
<li>Action: IMON_limits
<li>entered by: canelli 
<li>description is: Change Imon limts to accomodate high trigger rates.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1145</td><td>1145</td></tr>
<tr><td><b>Lower</b></td><td>655</td><td>655</td></tr>
<tr><td><b>Upper</b></td><td>1345</td><td>1400</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W10&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jul 14 11:14:24 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W5L0 
<li>problem n: 449 
<li>Status: unfixable
<li>Type: jumper
<li>Action: IMON_limits
<li>entered by: canelli 
<li>description is: Change high limit to after looking at PS plot.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>391</td><td>391</td></tr>
<tr><td><b>Lower</b></td><td>137</td><td>137</td></tr>
<tr><td><b>Upper</b></td><td>495</td><td>430</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W5&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jul 14 11:18:15 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W7L0 
<li>problem n: 1139 
<li>Status: needs_observation
<li>Type: jumper
<li>Action: IMON_limits
<li>entered by: canelli 
<li>description is: Change high limit after looking at PS plot.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>465</td><td>465</td></tr>
<tr><td><b>Lower</b></td><td>380</td><td>380</td></tr>
<tr><td><b>Upper</b></td><td>510</td><td>490</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W7&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jul 14 11:41:25 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W9L4 
<li>problem n: 332 
<li>Status: unfixable
<li>Type: jumper
<li>Action: IMON_limits
<li>entered by: canelli 
<li>description is: Change Imon limts to accomodate high trigger rates.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1380</td><td>1380</td></tr>
<tr><td><b>Lower</b></td><td>1220</td><td>1220</td></tr>
<tr><td><b>Upper</b></td><td>1475</td><td>1550</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W9&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Jul 14 11:43:53 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Wed_Jul_14_2004_114342.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4631  align='top'></a></td><td>IAVDD for SB4W9L4</td></tr></table>
<!-- Author: petra -->


<!-- Date: Wed Jul 14 11:53:54 2004 -->
<pre>We adjusted some current limits for the known list of IAVDD pinkies (jumper failures plus 1 other ladder) based on the current plots from the PS plotter over the last 10 days. The ladders we adjusted are: 
SB0W2L2, SB0W3L3, SB0W4L4, SB0W7L4, SB1W2L2, SB2W9L0, SB3W8L0, SB4W10L4, SB4W5L3, SB4W9L4, SB5W3L1, SB5W5L0, SB5W7L0 
</pre>
<!-- Author: Petra, Florencia, Rong-Shyang -->


<!-- Date: Wed Jul 14 14:22:44 2004 -->
<pre>We are taking the silicon to STDBY since the AG losses are >25 (the limit) since ~20 minutes and no clear trend for improvement can be seen. The electron lense current increased as well and the particles in the AG are actually kicked out (therefore the higher losses), but we decided to stick to the limits.</pre>
<!-- Author: Petra & Rong-Shyang -->


<!-- Date: Wed Jul 14 14:24:39 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4632&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4633  width='300' align='top'></a></td><td>Current of AVDD of e5b2 (SB5W11L2). Move the bonds up a little bit to avoid pinky.</td></tr></table>
<!-- Author: Rong-Shyang -->

<!-- Date: Wed Jul 14 14:30:11 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W11L2 
<li>problem n: 1279 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: rong 
<li>description is: Update the bonds, see <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=204&frame=2&anchor=14:24:39'> PS plot</a><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>845</td><td>845</td></tr>
<tr><td><b>Lower</b></td><td>835</td><td>835</td></tr>
<tr><td><b>Upper</b></td><td>850</td><td>855</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W11&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Jul 15 09:18:44 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4634&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4635' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4636&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4637' ></a></center>
<!-- Author: Petra -->
<!-- Comment: Thu Jul 15 09;22;41 comment by...Petra -->
<pre>IBIAS and IDVDD of two different ladders in one wedge (SB0W3L2/L4) acting up simultaneously. Does this happen to all the weak ladders at the same time, say during idle running conditions, or is there actually some electrical cross-talk or so in this wedge? Does anyone know?</pre>


<!-- Date: Thu Jul 15 10:46:53 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4638&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4639  width='300' align='top'></a></td><td>Current of e453(SB4W5L3) AVDD.</td></tr></table>
<!-- Author: Rong-Shyang  -->


<!-- Date: Thu Jul 15 11:42:37 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4640&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4641  width='300' align='top'></a></td><td>Bias current for e032. </td></tr></table>
<!-- Author: Rong-Shyang -->


<!-- Date: Thu Jul 15 14:27:19 2004 -->
This is a <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=84&frame=2&anchor=15:21:50'> 
link to previous measurements </a> done on the bench (controlled simple environment) about changes on the LV current consumption induced on the SVX3 chips if some of the Front-End comands (PRD2, PARST, FECLK) are missing.
<!-- Author: Gino -->


<!-- Date: Thu Jul 15 15:00:48 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4642&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4643' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4644&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4645' ></a></center>
<!-- Author: canelli -->
<!-- Comment: Thu Jul 15 15;18;31 comment by...Florencia -->
Around 11:55 2 ladders tripped (SB3W8L0 and SB5W5L0 AVDD).
The first one was recovered by the ace succesfully. Trying to recover the second one the ace turned off SB3W5L0, since this didn't help the trip on SB5W5L0 the ace paged me.<br>
When I came in, we could recover SB5W5L0 but we noticed that ALL 
the AVDD IMON SVX cells were pink as shown above.<br>
The history of all these ladders show that something happened at 11:55.
<br><br>
Steve, Petra, Rong, Gino, Florencia in the control room.<br>
Sal, Sebastian, Lashkar replaced the SRC board for the one in the silicon room (preshutdown) at 3:15.<br>



<!-- Comment: Thu Jul 15 17;06;07 comment by...Rong-Shyang -->
<pre>My impression is that SRC had board failure tripped off 3 ladders and brought all SVX ladders to low AVDD current state.
When I came in and reset trip, we could start data taking but AVDD current stayed low. Then I tried to reset the boards via Svxdaq and did see VRBs Glink out of sync and reset them but it didn't help.
Found Steve and figure out the Preamp Reset signal is missing on logic analyser. The SRC got failed badly and even the power recycle could fixed it, so Sal, Sebatian and Lashkar replaced the SRC with old one and are checking it out right now. No Silicon data taken since 12.</pre>
<!-- Date: Thu Jul 15 16:59:42 2004 -->
<pre>This is an attempt to at least list the actions that happened since 11:55 this morning and preliminary conclusions (mainly to keep things straight for ourselves and for our remote friends :): 
 
Probable order of events around lunchtime: 
 
1) something goes booboo in the SVX SRC (b0svx02) 
2) as a result no more PARST's are issued (maybe the problem is related to clock/bunch structure ?) 
3) as a result ALL SVX AVDD currents drop by ~30mA and IMON goes PINK! 
4) also, two well known ladders (jumper failures?) trip (see previous entry) -> just the tip of the iceberg... 
5) we paged the SRC pager to get them in for SRC studies to understand the L2A w/o L1A business; we did not know at that time, that the SRC went sick (did not pay enough attention to all the pink in IMON!) 
6) Sal was busy preparing the blessing for the afternoon... 
7a) we switched all of the silicon to STDBY 
7b) Steve N. was around and therefore started to look into the L2A w/o L1A problem using RC and svxdaq 
8) in parallel we hooked up a logic analyzer to the SRC in question, we did not see any PARST issued! 
9) in order to understand this, we emulated the clock and we did see a PARST and the AVDD currents going back to normal! 
10) then we reset/reinitialized the SRC and looked again and the PARST were gone again; another emulated clock attempt did not work this time! 
11) Then Sal and co came over and powercycled the SRC, which did not help the problem (for this we switched SVX only off, ISL and L00 stay in STDBY) 
12) finally they swapped in a spare SRC and test it right now (a more detailed report on this should come from the experts) 
 
 
</pre>
<!-- Author: Petra for the crew -->
<!-- Comment: Thu Jul 15 17;07;53 comment by...Gino and Petra -->
<pre>Here is a couple of other remarks:
1. From the power supplies side:
   1a. 2 ladders tripped SB4W8L0 and SB5W5L0 both are jumper failures
   1b. according to our granularity in time the trips happened at the same time as the current went down in every ladder in SVXII

2. From Run Control side:
   2a. At event 10265409 every VRB connected to SVXII reported the following error:
       The VRB had no event.
   2b. The trigger inhibit was recorded at the same event 10265409

 </pre>


<!-- Comment: Fri Jul 16 09;25;25 comment by...SCN -->
<h1>My story</h1>
<ul>
<li> I was dragged out of the 12:30 meeting (sorry Colin!  I did intended to hear your talk) by Rong to investigate.   The report was that a few ladders tripped, all ladders are pink, and we cannot recover from the L2A w/o L1A error.
<li> All ladders in SVX were drawing lower than normal current on AVDD, usually a sign that they are saturated because there are no preamp resets, which if it is all ladder means either <ol>
<li> The SRC is not sending PREAMP resets (PARST)
<li> All FFOs are out of synch, and therefore the chips are not getting PARST
</ol>
Using Rong's pre-existing svxdaq, I verifed that at least one FFO was in synch, thereby ruling out #2.
<li> Since the currents were <i>low</i> we <b>did not panic</b> (rule #1) and went to work trying to figure out the SRC L2A w/o L1A problem, assuming that the low currents were a symptom.  While I did not verify that we could not HRR (via Run Control) out of the situation, the upshot of this investigation was <ol>
<li> When issuing the RUN command by VME (that is, writing a particular register with a particular bit mask) the L2A w/o L1A error counter would increment once.  When the RUN command came from the TS via the TAXI, this was not the case.  Note: The RUN command (and HALT and RECOVER command as well) first READS the state of this register, changes the HRR bits, and then writes it back.  It is possible that if some other bit in the register is set, it may cause the fake L2A (this would explain why it sometimes goes away and cannot be reproduced).
<li> At no time during this stage did we reset the SRC in a grandiose way (we did do READ/WRITE and VME HRRs, as well as Run Control CONFIGs)  However, at the end of it we convinced ourselves that we were back in the "normal" situation of exactly one "L2A w/o L1A" error (from the VME RUN whihc is part of the CONFIG transition) at the beginning of the run, recoverable by a RC (i.e. TS) HRR, and one at the end (from the VME RUN as part of the SRC cleanup).
</ol>
<li> So, we thought we were good to go, but the currents had not returned to normal levels, which means it was not a symptom of the fact that the SRC was in an ERROR state due to the above.  At this point, I decided we needed to look at the PARST coming from the SRC.  I used our handy test crate, and hooked its FFO up
to the SVXII SRC, and looked for Fib Commands  0x2 and 0x4, which weren't there.  Fib Command 0xC (KEEPALIVEs) were there, as
was FECLOCK, and the KEEPALIVE BE CLOCKs, etc.
This situation remained true even after a Run Control Config
<li> Since the sending of PARST has to happen inside an Abort Gap, I reasoned that if the SRC does not see an Abort Gap, it cannot send PARST.  I switched the SRC to emulated clocks and 
(Ouila!) PARST came back.  
<li> Unfortunately we cannot run with CDF on emulated clocks. Going back to CDF Clocks, PARSTs disappeared.  Timestamps can be obtained from current plots.  Since this was (as far as I know) a new failure mode for Si, we then tried several things to bring them back taking the rather drastic step of power cycling the board<ul>
<li> Tried initialization with svxdaq.  This actually made it worse, as PARST even disappeared in emulated clock mode.
<li> There is in fact a bit in the SRC to disable the sending of PARST (useful once upon a time for VME board testing) It (of course!) was not set, but we toggled it to see if that had any effect.  It did not.
<li> In hindsight: There is something about chip initialization that disables PARST at the FIB level, which is suppossed to be brought back by the CHIP_RESET (or FIB_RESET) command the SRC sends as part of RECOVER.  This may have been a problem- if the SRC wasn't sending that command, once you initialize the FIB, you don't get PARST anymore.  This probably should be investigated more thoroughly.
</ul>
</ul>
At this point I had to leave so I made people get Sal and Co. over there, explained the problem, and took off.  I have only glanced through the log at the subsequent problems, some of which make sense ("The Vrb had no Event") and some of which don't
("MSRAM Corrupt" has nothing to do with the TSI return cable.  <b> I would highly suggest someone make sure the sequences in the FIBs has the correct checksum</b>).  <P>
Sorry I couldn't help out more, but on the other hand, the cynic in me says the the last 3 or 4 generations (at least back to WJS) of Operations Heads have warned the collaboration about the declining quantity of expertise - this is a pretty good example of the consequences.  We can have a debriefing session on the "post-14:00" events next week if it is deemed useful.   
<!-- Comment: Mon Jul 19 13;40;31 comment by...SCN -->
<h2>Correction</h2> or clarification, perhaps<BR>
I think my comments about disabling PARST at the FIB level were
confusing PRD2 with PARST.  Anyway, I was spying on the FIB 
backplane, i.e. before the FIB gets the commands, so whatever
was going on in the FIB, the PARST commands still should have been there.
<!-- Date: Thu Jul 15 21:15:14 2004 -->
<h3>SRC Swap Summary And Silicon Revival</h3> 
 
This is the continuation of the saga started 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=204&frame=2&anchor=15:00:48'> 
here</a>.  
<ul> 
<li> Investigated the lack of PARST, of course they 
were still gone. 
<li> Power-cycled the crate to check if it came back 
<li> <b>At this point, KEEPALIVES disappeared</b> 
when it was brought back up. 
<ul> 
<li> <i>This is the reason we decided to swap out the SRC</i> 
<li> Further investigation of this board is necessary 
</ul> 
<li> We brought out the backup SRC (<b>Dopey</b>) and put it in, and commenced the checkout procedure. 
<li> After some pilot confusion, the checkout procedure went smoothly, and we signed off on the SRC 
 and ran the guinea pig ladders (SVX only since ISL/L00 was 
still all at standby). 
<li> We were seeing several errors like 
 
<pre>FISION: S_errno_EIO (0x5): VME BERR received!<pre> 
 
over and over again from the fib crates 
<li> We were also getting  
<i>MSRAM</i> and <i>EEPROM</i> corruption errors.  
The problem turned out that the TSI status return was 
not plugged in. Once we plugged it in the <i>MSRAM</i> 
and <i>EEPROM</i> errors went away. 
<ul> 
<li> I should mention that we had tried several sequences 
of rebooting and power cycling the crates in the order: 
<ol> 
<li> b0svx02 
<li> b0svx00 
<li> b0svx01 
<li> b0svx03 
<li> b0svx04 
<li> b0svx05 
</ol> 
</ul> 
<li> We then got errors about heap corruption. We tried several cycles of reset and power cycles of the crates in the order 
above 
<li> We tried to bring up the system and initialize it, but the fibs kept failing on CONFIG. 
<li> For no apparent reason whatsoever, when we also reset 
b0svx06/07/08 (in that order), the heap corruption error messages went away. 
<li> We also had to synch the GLINKS for b0svx00 and b0svx02 
because they were unsynched. 
<li> We brought up the system one wedge at a time, and we got the fibs to successfully pass CONFIG and brought up the 
system. 
<li> For reference, the successful sequence of resetting 
crates was 
<ol> 
<li> b0svx02 
<li> b0svx00 
<li> b0svx01 
<li> b0svx03 
<li> b0svx04 
<li> b0svx05 
<li> b0svx06 
<li> b0svx07 
<li> b0svx08 
</ol> 
</ul> 
</ul>
<!-- Author: Sal/Rong/Dave/Sebastian/Reid/Lashkar/Petra/Gino/Steve/Florencia (anyone else I forget???) -->
<!-- Comment: Fri Jul 16 10;02;53 comment by...Rong-Shyang -->
<pre>
- " FISION: S_errno_EIO (0x5): VME BERR received! "
is the error pop in b0svx## crates. I had two minicom logged in b0svx00 and b0svx03. They both had this popping for million times.
 </pre>
<!-- Date: Thu Jul 15 21:39:57 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W3L2 
<li>problem n: 1280 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: canelli 
<li>description is: Change high end in Bias IMON limit. <a href= '/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=204&frame=2&anchor=11:42:37'> See bias current plot.</a><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>??</td><td>??</td></tr>
<tr><td><b>Lower</b></td><td>??</td><td>??</td></tr>
<tr><td><b>Upper</b></td><td>100</td><td>110</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W3&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jul 15 22:18:26 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W5L3 
<li>problem n: 857 
<li>Status: needs_observation
<li>Type: AVDD2
<li>Action: IMON_limits
<li>entered by: canelli 
<li>description is: Change IMON limits. <a href= '/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=204&frame=2&anchor=10:46:53'> See plot. </a> <table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>755</td><td>885</td></tr>
<tr><td><b>Lower</b></td><td>700</td><td>800</td></tr>
<tr><td><b>Upper</b></td><td>875</td><td>920</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W5&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Jul 15 22:38:24 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4646&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4647  width='300' align='top'></a></td><td>AVDD current of e053. After power recycle, we seem to get one chip back. But don't expect it stays long.</td></tr></table>
<!-- Author: Rong-Shyang -->


<!-- Date: Thu Jul 15 22:48:59 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4648&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4649  width='300' align='top'></a></td><td>IMon for SVX after data taking resumed. Except e053 has one chip back, others are fine.</td></tr></table>
<!-- Author: Rong-Shyang -->
<!-- Comment: Thu Jul 15 22;49;30 comment by...Rong-Shyang -->
<pre>BTW, we didn't touch ISL and L00, so they are all fine.</pre>


<!-- Date: Thu Jul 15 23:24:13 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4650&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4651  width='300' align='top'></a></td><td>SVT spymon plot. Very low occupancy on wedge 10 and 11. 
SVT expert were paged and now are wapping boards. 
Looks like two more board in the same crate the work on earlier today.</td></tr></table>
<!-- Author: Rong-Shyang -->
<!-- Comment: Thu Jul 15 23;25;36 comment by...Rong-Shyang -->
<pre>BTW, SVXMon is fine, so SVX is running ok in digital point of view.
For wedge 10 and 11, I look at charge and occupancy distributions for some ladders, they are all running well. So that was SVT problem for sure.</pre>


<!-- Date: Fri Jul 16 00:23:44 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4652&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4653  width='300' align='top'></a></td><td>SVT plot after SVT fix</td></tr></table>
<!-- Author: Florencia -->




<!-- Date: Fri Jul 16 12:19:35 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Fri_Jul_16_2004_121926.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4655  align='top'></a></td><td>SVT plot</td></tr></table>
<!-- Author: Florencia -->

<!-- Date: Fri Jul 16 13:18:04 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W6L4 
<li>problem n: 345 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: rahaman 
<li>description is: The problem is still there. This gives rise to 20-60% bad events. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W6&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Jul 16 13:39:13 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4656&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4657  width='300' align='top'></a></td><td>PS Gui plot when multi-wedge of ISL got down. 
Had ACE hockerized crate 11, and brought them back to run.</td></tr></table>
<!-- Author: Rong-Shyang, David, Gino -->
<!-- Comment: Fri Jul 16 14;01;30 comment by...Rong-Shyang -->
<pre>Also, PSGui and IMon both stuck after hockerization. I restarted both of them.</pre>


<!-- Date: Fri Jul 16 14:09:02 2004 -->
<pre>We removed SB4W9L4 from the HWdb because it tripped 3 times at 
the begining of the run (very high luminosity ~110).</pre>
<!-- Author: Florencia -->

<!-- Date: Fri Jul 16 15:01:38 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W9L4 
<li>problem n: 332 
<li>Status: unfixable
<li>Type: jumper
<li>Action: Removed_hdwdb
<li>entered by: rong 
<li>description is: Took out due to tripping in the hight lumi store. Should investigate a way to have it in. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W9&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Jul 16 17:01:16 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Fri_Jul_16_2004_170109.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4659  align='top'></a></td><td>Scope plot from Ghostbuster.</td></tr></table>
<!-- Author: Gino and Rong-Shyang -->
<!-- Comment: Fri Jul 16 17;12;11 comment by...Gino and Rong-Shyang -->
<pre>In the begining of the store, we got a lot of resonance detected.
Gino setup the scope downstair and got the snapshot of information between event RO time and error when issuing resonance. So
- upper curve is the command send to FFO to readout events
- lower line is the trigger when GB pull out error for resonance.

- first measurment is a wider gap about 26.8us before the resonances started. So the end of the gap is event count 1.

- so the RO time between event 1 and event 2 will be the reference event (RO time).

- at event count 13, GB fired the resonances error. (11th event have the same length as reference event.)

- The 22 uS seem to be still longer than SVX RO time needed. So the L1 readout is not waiting for us.

</pre>


<!-- Date: Sat Jul 17 11:23:40 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4660&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4660  width='300' align='top'></a></td><td>At 23:00 last night, there started to have discrepency between AGIGI2 and SLPAH[37]. I have asked SciCo to consult MCR if they understand what happened.</td></tr></table>
<!-- Author: Rong-Shyang -->
<!-- Comment: Sat Jul 17 12;31;01 comment by...Rong-Shyang -->
Another comparison of AGIGI2 and SLPAH[37] in these 4 days can be found <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=519&frame=2&anchor=11:26:25.916'>
here</a>.


<!-- Date: Sat Jul 17 13:57:05 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4661&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4662  width='300' align='top'></a></td><td>AVDD current of e594 in these 20 days.</td></tr></table>
<!-- Author: Rong-Shyang -->
<!-- Comment: Sat Jul 17 13;59;35 comment by...Rong-Shyang -->
Pinky of e594 in IMon,<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=519&frame=2&anchor=09:09:12.040'>
see here</a>. It is at high bond in these two days. 

<!-- Date: Sat Jul 17 17:06:00 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W9L4 
<li>problem n: 1281 
<li>Status: needs_observation
<li>Type: AVDD2
<li>Action: IMON_limits
<li>entered by: canelli 
<li>description is: Change high end limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1055</td><td>1055</td></tr>
<tr><td><b>Lower</b></td><td>1010</td><td>1010</td></tr>
<tr><td><b>Upper</b></td><td>1075</td><td>1090</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W9&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat Jul 17 22:51:52 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4663&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4664  width='300' align='top'></a></td><td>AGIGI2 with SLPAH[37] since 13th. </td></tr></table>
<!-- Author: Rong-Shyang -->
<!-- Comment: Sat Jul 17 22;57;06 comment by...Rong-Shyang -->
<pre>As you can see, these two measurements have different gain.
Also, AGIGI2 doesn't go to zero when there is no beam.
Today it got worse, a clear negative offset happened with some activity while SLPAH was stablely decreasing.</pre>


<!-- Date: Sat Jul 17 23:16:39 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4665&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4666  width='300' align='top'></a></td><td>SVT spymon for store 3659 / run 185259.</td></tr></table>
<!-- Author: Rong-Shyang and Florencia -->
<!-- Comment: Sat Jul 17 23;17;26 comment by...Rong-Shyang -->
<pre>Store init lumi 30E30. Tevatron lost half of the Pbar during shot.</pre>


<!-- Date: Sun Jul 18 10:33:26 2004 -->
<center><a href='/elog/notebooks/silicon/Sun_Jul_18_2004_103246.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4674' ></a><a href='/elog/notebooks/silicon/Sun_Jul_18_2004_102657.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4670' ></a></center>
<!-- Author: Florencia -->
<!-- Comment: Sun Jul 18 10;38;56 comment by...Florencia -->
<pre>Bias current for e033 keeps going above its limit (500). After HRR goes to its lower limit (20). <a href='/cgi/elog/elog.pl?nb=2004&action=view&page=522&frame=2&anchor=09:32:42.136'>
History in main e-log. </a> 
The data looks fine.</pre>
<!-- Comment: Sun Jul 18 11;33;10 comment by...Florencia -->
<pre>See below for bias history.</pre>
<!-- Date: Sun Jul 18 10:33:58 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4671&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4672' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4675&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4676' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4677&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4678' ></a></center>
<!-- Author: matt -->



<!-- Date: Sun Jul 18 20:54:24 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W2L1 
<li>problem n: 1282 
<li>Status: needs_work
<li>Type: Chip_capid
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: New ADC bump btwn 125-150 in 185247 for all chips (Z more than phi.) Excess of one-strip clusters with Q=125-150. DS EM shows capid bit 3 problems (0->8, 2->a, etc.) 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Jul 19 09:24:01 2004 -->
<br><br>
<a href='/cgi/elog/elog.pl?nb=2004&action=view&page=523&frame=2&anchor=18:39:07.678'> 
 Pink Imon cell AVDD B0W5L3 (left) and DVDD B0W3L4 (right). </a> 
<br><br> 
<a href='/cgi/elog/elog.pl?nb=2004&action=view&page=523&frame=2&anchor=18:54:12.724'> 
 Pink Imon cell for ISL AVDD B4W3L2.</a>
<!-- Author: Florencia -->