<!-- Title: 11:13:39  Mon Apr  7 2003 -->
<!-- Crewchief: Cigdem (pager) -->
<!-- Op1: Lester -->
<!-- Op2: all others -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
New week --> new file


<!-- Date: Mon Apr 7 11:15:45 2003 -->
Changed SVXCAL run configuration.  <BR>Now <B>all files from 
calibration will be written to tape</B>.<BR>  (A typical read-all  
calibration run with 5000 events occupies approx. 7GB.)<BR> 
These data are also valuable to the SiStudies group and others 
working on L00 hit embedding.
<!-- Author: Jason -->


<!-- Date: Mon Apr 7 11:56:38 2003 -->
<pre>here is my little report from last week: 
Too many HRRs.  
I asked for 4-6 hours access.  
It turned OUT I did NOT get it! 
 
Losses getting better and better. 
If you are in the control room feel free to use the faster  
tevmon if you see flat lossess.  
If you are at home better stick with the original one. 
 
L00 trips for DVDD SPT 
	taken care of by raising the limit.  
	necessary due to the higher trigger rates 
 
IB2W1 is out of businness untill we have an access 
 
LB1W3L3 Bias 0 is underdepleted by 50 V (out of 120)  
	Need to check the CROWBAR! 
 
FTM already buffed: 
 
FTM		mode 11		Mode 7 
SB0W4/5				03/17 
SB1W0/1		02/25		03/22 
SB1W4/5		02/20		03/24 
SB1W6/7		02/22		03/24 
SB2W0/1				03/17 
SB2W4/5		01/31		SHOULD STAY AS IS for NOW 
SB2W8/9  	02/22		NOT YET DONE 
SB2W10/11	01/15 		SHOULD STAY AS IS for NOW 
SB3W0/1		02/25		03/09 
SB4W8/9				03/24 
SB5W10/11	02/25		03/09 
IB5W2/3				03/22 
 
NEXT TO COME: 
IB2W0/1 
SB3W2/3 
SB5W0/1 
SB0W0/1 
IB1W4/5 
IB0W2/3 
</pre>
<!-- Author: Gino -->

<!-- Date: Mon Apr 7 15:11:45 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W0/1All 
<li>problem n: 746 
<li>Status: needs_observation
<li>Type: Other
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: board wide cap id errors run 160110. ~6%.  needs more observation. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B3W0/1&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Apr 7 15:30:14 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W2L1 
<li>problem n: 784 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: Bit 0 high 23% run 161013--signifcantly higher than in previous runs, should check to see if the error rate continues to be high. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Apr 7 16:26:57 2003 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1794&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1794' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1795&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1795' width='300'></a></center>
<!-- Author: Gino -->
<!-- Comment: Mon Apr  7 16;31;56 comment by...Gino & Steve -->
<pre>LEFT  cellID versus consumer evt # for a ladder on b0fib00
RIGHT cellID versus consumer evt # for a ladder on b0fib02
This is for RUN 161013 where all ladders (all of them) in b0fib02 
gave 7 % of pipeline out of sync.
This plots show how the failure mode is NOT harmful to the ladders.
It really looks like the crate missed a FECLK between evt 3320 
and evt 3321. And from then on all ladders in bofib02 are one 
cellID behind untill the next HRR.

This is a clear explanation for the unusual 600-700 chips being out of sync according to SVXMon during the last few days.

We are going to swap the FFO.
</pre>


<!-- Date: Tue Apr 8 09:07:56 2003 -->
<pre>Yesterday I tried to make LB1W3L3 to trip on udervoltage: 
Mon Apr 07 16:56:45 CDT 2003     success: Voltage0 changed for LB1W3 L3 to 100.0 V 
Mon Apr 07 16:57:40 CDT 2003     success: Voltage0 changed for LB1W3 L3 to 120.0 V 
Mon Apr 07 16:59:01 CDT 2003     success: Channel3 L00 EAST W3 to STANDBY 
Mon Apr 07 16:59:29 CDT 2003     success: Voltage0 changed for LB1W3 L3 to 100.0 V 
Mon Apr 07 17:01:06 CDT 2003     success: Channel3 L00 EAST W3 to STANDBY 
Mon Apr 07 17:01:35 CDT 2003     success: Voltage0 changed for LB1W3 L3 to 120.0 V 
Mon Apr 07 17:04:37 CDT 2003     success: Voltage0 changed for LB1W3 L3 to 2.0 VMon Apr 07 17:06:02 CDT 2003     success: Voltage0 changed for LB1W3 L3 to 120.0 V 
Mon Apr 07 17:08:10 CDT 2003     success: Power Supply L00 WEST W3 to STANDBY 
Mon Apr 07 17:09:09 CDT 2003     success: Power Supply L00 EAST W3 to STANDBY 
Mon Apr 07 17:09:42 CDT 2003     success: Voltage0 changed for LB1W3 L3 to 120.0 V 
Mon Apr 07 17:12:46 CDT 2003     success: Voltage1 changed for LB1W3 L3 to 135.0 V 
Mon Apr 07 17:14:51 CDT 2003     success: Channel3 L00 EAST W3 to STANDBY 
Mon Apr 07 17:15:18 CDT 2003     success: Power Supply L00 WEST W3 ON 
Mon Apr 07 17:15:40 CDT 2003     success: Power Supply L00 EAST W3 ON 
 
I was not able to see the trip.</pre>
<!-- Author: Gino -->

<!-- Date: Tue Apr 8 10:11:24 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W0/1All 
<li>problem n: 746 
<li>Status: needs_access_2hr
<li>Type: Other
<li>Action: Diagnosis
<li>entered by: nahn 
<li>description is: We want to swap the Fib (SN 105 PREP 550267) <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=117&frame=2&anchor=12:21:23'> which had problems before</a>.  It is in NWT crate b0fib04 Sl 8. The low rate is probably due to SVXMon catching it and issuing HRRs. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B3W0/1&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Apr 8 12:49:46 2003 -->
<pre>Persistent pinkie on SB3W1L1 DVDD. It is barely out of range. 
I changed high end from 56 to 61. 
</pre>
<!-- Author: Lester -->


<!-- Date: Tue Apr 8 12:51:04 2003 -->
<table><tr><td><a href=/elog/notebooks/silicon/Tue_Apr__8_2003_125102.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1797  align='top'></td><td>Sudden drop to zero of SB1W11L3 AVDD current.</a></td></tr></table>
<!-- Author: Lester -->
<!-- Comment: Tue Apr  8 13;02;03 comment by...Lester -->
<pre>Tested with svxdaq, and it inits and readout fine. Has normal 
(~2-3 counts) noise unbaised.

Probably a supply ADC failure.</pre>


<!-- Comment: Tue Apr  8 14;33;57 comment by...Gino -->
<pre>Time stamp of the failure:
New time 43027 Tue Apr  8 11:57:07 2003
</pre>
<!-- Comment: Tue Apr  8 14;36;33 comment by...Gino -->
<pre>Checked the LOSSES (there was beam in the machine) around the time stamp of the failure and nothing noticeable is visible.
</pre>
<!-- Comment: Tue Apr  8 14;57;50 comment by...Gino -->
Loaded into CAENLVcurrent.dat 400 mA (instead of 1200 mA) as tripping limit and the ladder tripped. SO THE HARDWARE TRIPPING MECHANISM WORKS FINE.
Still with the AMMETER reading zero the SOFTWARE PROTECTION TRIP MECHANISM WILL NOT WORK.
Sending a new ACCESS REQUEST soon.
<!-- Comment: Tue Apr  8 15;58;50 comment by...Gino -->
<pre>Commenting on my own comments.
SOFTWARE PROTECTION trip does NOT apply to AVDD.
</pre>
<!-- Comment: Wed Apr  9 14;39;48 comment by...Reid and Jason -->
<h3>Access Report</h3>
Swapped the SB1WB supply.  Pulled out S/N #63 Prep: 566489 and put in supply S/N #55.  Gino was not able to test completely with SVXDAQ but initial testing points to a success.  
<!-- Date: Tue Apr 8 13:47:50 2003 -->
<table><tr><td><a href=/elog/notebooks/silicon/Tue_Apr__8_2003_134739.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1799  align='top'></td><td>AVDD stepped down on SB1W10/11 and SB3W10/11.   This is an example for SB1W10 L0. Cold Start brought them back</a></td></tr></table>
<!-- Author: SCN -->
<!-- Comment: Tue Apr  8 14;44;29 comment by...Lester -->
<pre>This and SB3W10/11 are due to my futzing with svxdaq.</pre>




<!-- Date: Tue Apr 8 16:38:42 2003 -->
<pre>LOCATION OF MICRON DETECTORS IN L00: 
WEST LB0W1L3 
EAST LB1W4L3 
 
This is just a way to record it in the e-log.  
It might be usefull in the future.  
It is part of my investigation for the trips on LB1W3L3. 
</pre>
<!-- Author: Gino -->


<!-- Date: Tue Apr 8 17:11:40 2003 -->
<H3> ISL Occupancy Problem in f542 and f140 solved </H3> 
SVXDAQ investigation showed that the effected chips (8f-8c in f542, a3-a0 in f140) needed to have their Integrator current increased (ISEL changed from 1010 to 1111). 
<P> 
Since these chips now function properly, they have been unsparsed. 
<P> 
<I>For future reference:</I> if there are any sudden inexpicable (i.e. not bias) increases in ISL occupany with an odd-even structure in the data, this may be the solution.
<!-- Author: chill -->
<!-- Comment: Tue Apr  8 17;41;21 comment by...chill -->
<pre>See before (red) and after (blue) pedestal vs.channel plots below.</pre>
<!-- Date: Tue Apr 8 17:22:38 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W4L0 
<li>problem n: 974 
<li>Status: needs_observation
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: chill 
<li>description is: Problem begun in thread 949 and moved to 404 is believed to be FE amplifier oscillation.  It was solved in svxdaq by increasing integrator current from 210 uA to 350 uA (ISEL 1010 -> 1111). As the chips (a3-a0) now behave properly, they have been unsparsed.  Data should be monitored to see that occupancy returns to normal as expected. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B1W4&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Apr 8 17:23:26 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W4L2 
<li>problem n: 948 
<li>Status: needs_observation
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: chill 
<li>description is: Problem is believed to be FE amplifier oscillation.  It was solved in svxdaq by increasing integrator current from 210 uA to 350 uA (ISEL 1010 -> 1111). As the chips (a3-a0) now behave properly, they have been unsparsed.  Data should be monitored to see that occupancy returns to normal as expected. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B5W4&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Apr 8 17:39:52 2003 -->
<table><tr><td><a href=/elog/notebooks/silicon/Tue_Apr__8_2003_173948.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1807  align='top'></td><td>Before ISEL change (f140 chip a1).</a></td></tr></table>
<!-- Author: chill -->


<!-- Date: Tue Apr 8 17:40:23 2003 -->
<table><tr><td><a href=/elog/notebooks/silicon/Tue_Apr__8_2003_174020.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1809  align='top'></td><td>After ISEL change (f140 chip a1).</a></td></tr></table>
<!-- Author: chill -->



<!-- Date: Wed Apr 9 15:06:26 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W0/1All 
<li>problem n: 746 
<li>Status: needs_observation
<li>Type: Wedgewide_HRR
<li>Action: Swap_FIB
<li>entered by: thom 
<li>description is: Fib swap. Test successful.<table border=1>
<tr><td><b>IN</b></td><td>PREP:</td><td>??</td><td>Serial:</td><td>550966</td></tr>
<tr><td><b>OUT</b></td><td>PREP:</td><td>??</td><td>Serial:</td><td>550267</td></tr></table> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B3W0/1&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Apr 9 15:12:50 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W2All 
<li>problem n: 96 
<li>Status: needs_observation
<li>Type: Other
<li>Action: Monitoring
<li>entered by: thom 
<li>description is: Buffed special FTM. Test OK 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B3W2&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Apr 9 15:15:13 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W1All 
<li>problem n: 838 
<li>Status: needs_observation
<li>Type: Wedgewide_HRR
<li>Action: Monitoring
<li>entered by: thom 
<li>description is: Buffed FTM. Test OK 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B2W1&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Apr 9 15:26:49 2003 -->
<pre>We swapped a FFO for b0fib02. In:serial 550302  
Out:550315</pre>
<!-- Author: julia -->


<!-- Date: Wed Apr 9 16:10:51 2003 -->
<h3>Firmware/Sequence Test Upgrade</h3> <ul> 
<li> Upgrading all Fibs in b0fib05 to <i>fib_v16.jam</i>.  To downgrade, either use <i>fib_v15.jam</i> plus <i>pipe27.jam</i> plus <i> clkshprz.jam</i> or (if available - asking Ken now) download <i>fibv15_5.jam</i> which will accomplish the same thing. 
<li> Upgrading sequences on b0fib00 to <i>CPC_020503_mask_abort1.seq</i> (old one is <i>CPC_082602_clean.seq</i>) 
</ul> 
These changes should only add robustness to the data processing. 
If there are problems, please page me (722 7483) and we will downgrade.
<!-- Author: SCN, Julia -->
<!-- Comment: Wed Apr  9 16;24;52 comment by...SCN -->
<ul> <li> CPC_020503_mask_abort1.seq checksum is 0x1552a
<li> CPC_082602_clean.seq checksum is 0x154da
</ul>


<!-- Date: Wed Apr 9 17:21:33 2003 -->
<pre>Changed IMon limits for SB1W11 because PS was exchanged.</pre>
<!-- Author: Steve, Julia -->
<!-- Comment: Wed Apr  9 23;17;24 comment by...David -->
<a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=149&frame=2&anchor=23:09:01'>
See below</a> for more IMON changes for this wedge.
<!-- Date: Wed Apr 9 19:29:42 2003 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>SENT TO THE ACES TODAY. 
 
 New Silicon Policies for STUCK LADDERS generating 
 HRRs    
 
 
         From:  
              <bolla@physics.purdue.edu>    
          Date:  
              Wed, April 9, 2003 7:21 pm    
           To:  
              <cdf_aces@fnal.gov>    
           Cc:  
              <cdf-ops-managers@fnal.gov>, <lmiller@fnal.gov>,   
 
   Hi,  
   when Silicon is included in data taking and you have a  HRR  
   because of STUCK LADDER error you report it in the shift e-log.  
   (nothing new so far).  
 
   It is a good idea to record the HRRs in the same entry as comments to  
   the first one you get.  
 
   This way you should be able to get a feeling online about the rate of  
   these errors. The usual message is something like:  
   SvxMon Halt Recver Run: Stuck Celid in 5 evts in Silicon/S/B3/W2/L4/C0-6  
 
   (nothing new so far).  
 
   What we are asking you from now on is to page the Silicon Pager  
   (218-8227) if you get a rate of this errors bigger than once per hour  
   coming out of the same wedge. A wedge is a part of the detector where  
   the /x/By/Wz does NOT change (the Lj does NOT matter and could change,  
   this means a different ladder in the same wedge)  
 
   YOU DO NOT HAVE TO STOP THE RUN. KEEP GOING.  
 
   Once you get the Silicon Pager paged (2188227). He/She will come in and  
   get the wedge out of the HDWDB. Once this is done He/She will ask you to  
   END the RUN and START a new one The changes in the HDWDB will be picked  
   up during the COLDSTART transition.  
 
   At that point the Silicon Pager carrier will  
   1. generate a new CAENvolts.dat and load it into the CAEN Silicon GUI.  
      This will turn that wedge OFF.  
   2. Ask the CO to kill and restart SVXMON so that the changes get picked up  
      even by the online consumer.  
   This is just for your information. You do not have to do anything.  
 
 
   This could be a source of some down time (minor one in principle)but it is  
   done for the safety of the Silicon.  
 
   After the wedge has been taken out a ACCESS REQUEST will be submitted by  
   the pager carrier and (hopefully) at the end of the store we will have an  
   opportunity to go in and FIX the problem.  
 
   Thank you for the attention,  
 
 
                              Gino and Steve  
 
   PS: I'm posting this on the cdf e-log and on the Silicon e-log as well.  
       Please pass this information to your co-shifters and to the ACEs that  
       take over from you.  
 
 
</pre></td></tr></td></table>
<!-- Author: Gino -->


<!-- Date: Wed Apr 9 20:46:14 2003 -->
<pre>Due to the new POWER SUPPLY in SB1W11 I had to load the  
BIAS current limit from file. 
A new file was generated on  
svxii games 55647 Feb  3 18:03CAENcurrent_02032003_0603PM.dat 
with the HDWDB. 
This opened a BIG BIG CAN of worms and a lot of little  
ladders tripped on BIAS overcurrent. 
We linked CAENcurrents.dat to the right file (CAENcurrent_gino.dat)  
in the caencurrentfiles directory  
and slowly recovered all the trips. 
THIS IS a PATCH that is there since we changed the BIAS current  
limits in the supplies during the January access. (the name of  
the file tells you clearly who is responsible for this mess). 
We should deal with it ASAP. For the time being the situation is  
good. DO NOT click THAT button. 
We were NOT a source of DOWN time for CDF DATA TAKING because of  
other troubles (L3). This makes our mess to taste a little better. 
 
</pre>
<!-- Author: Gino -->


<!-- Date: Wed Apr 9 21:46:53 2003 -->
<table><tr><td><a href=/elog/notebooks/silicon/Wed_Apr__9_2003_214625.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1811  align='top'></td><td>SVTPLOT of today. </a></td></tr></table>
<!-- Author: cigdem -->


<!-- Date: Wed Apr 9 21:49:42 2003 -->
<pre>There is one yellow in SVXMON. e043, which is caused of bit 7 high on the z-side. It is a known problem.  
We did not change the catogory to needs work, because we don't  
want to mask the phi side of this ladder in SVXMON.  
  
For the meanwhile we will have it yellow in SVXMON.  
I informed the CO that he/she should not page the expert, but all  
other yellows he/she should do page us.  
 
</pre>
<!-- Author: cigdem  -->


<!-- Date: Wed Apr 9 23:09:01 2003 -->
Persistent pinkies in IMON during run <a href='http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER=161170'> 161170</a>: 
<UL><li>e1b3 DVDD over-voltage - changed high end from 60 to 70.</li> 
<li>e1b4 DVDD over-voltage - changed high end from 170 to 210.</li> 
</ul> 
These <a href= 
'/cgi/elog/elog.pl?nb=2003&action=view&page=297&frame=2&anchor=22:35:09.747'>over-voltages</a> occurred at about the same time that the prescales changed, ie, when the L1A rate increased. Also, these ladders had their power supply changed in today's access.
<!-- Author: David -->



<!-- Date: Thu Apr 10 08:51:38 2003 -->
<pre>We had a quench. Post quench test was ok.  
 
</pre>
<!-- Author: cigdem -->


<!-- Date: Thu Apr 10 08:59:01 2003 -->
<pre><H1> a 7 to 8 hours access is starting NOW </H1> 
<LI>The main goal is to buff all remaining FTMs in b0fib02. 
<LI>According to the time left we might do the same for b0fib01. 
 
</pre>
<!-- Author: Gino -->


<!-- Date: Thu Apr 10 11:04:06 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1815&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1815  width='300' align='top'></td><td>The quench of this morning was pretty clean.</a></td></tr></table>
<!-- Author: Gino -->

<!-- Date: Thu Apr 10 15:30:29 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W4L2 
<li>problem n: 944 
<li>Status: needs_access_4hr
<li>Type: RX
<li>Action: Diagnosis_update
<li>entered by: bolla 
<li>description is: Swapped FIBER with the L3.  Problem stays with the ladder.  Needs Light OUTPUT measurements to see if the BIT 6 DIED. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B1W4&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Apr 10 20:30:20 2003 -->
<pre>ACCESS REPORT 
 
We completed the buffing of the FTMs in b0fib02 and b0fib01. 
 
Here is the deal for these two crates in a slot by slot basis 
 
Fib Crate 	Slot 	Wedges		Date of legal buffing 
b0fib02 		SB0W4/5 	03/17 
b0fib02 		SB0W6/7 	04/10 TODAY 
b0fib02 		SB0W8/9 	04/10 TODAY 
b0fib02 		SB1W4/5         03/24 
b0fib02 		SB1W6/7         03/24  
b0fib02 		SB1W8/9 	04/10 TODAY 
b0fib02 		SB2W4/5         01/31 Still Illegal* 
b0fib02 		SB2W6/7 	04/10 TODAY 
b0fib02 		SB2W8/9         04/10 TODAY 
 
b0fib01			IB0W2/3         04/10 TODAY 
b0fib01			IB1W2/3         04/10 TODAY 
b0fib01			IB1W4/5         04/10 TODAY 
b0fib01			IB2W0/1         04/09  
b0fib01			LB0W2/3         04/10 TODAY 
 
In the process we introduced 2 OBDV troubles on  
SB2W6L3 and LB0W2L3.  
The RXs were swapped and the problems solved. 
 
One more thing to pay attention to is SB2W7L4. This is a well  
known trouble maker with very LOW light output. Steve decided to  
swap the RX. The problem got a little worse. We did NOT have time  
to go back to it. Being it is NOT used by SVT we left it as is. 
 
Thank you all the people involved. We accomplished a lot. 
 
</pre>
<!-- Author: Stan, Steve, Julia, Cigdem, Salvatore and Gino -->
<!-- Comment: Thu Apr 10 20;31;16 comment by...Gino -->
<pre>SB2W5/6 is still illegal because this is special. The FECLK is single ended and we better keep thins as they are.</pre>

<!-- Comment: Thu Apr 10 20;38;52 comment by...Gino -->
<pre>Raised the HV. Taken run 161303 with HV up. 200 + events to SVXMON.
Detector looks as good as it did before the access.
That was what I was hoping for.</pre>

<!-- Date: Thu Apr 10 22:50:38 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W5L4 
<li>problem n: 632 
<li>Status: fixed
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: petemc 
<li>description is: Problem hasn't recurred since swap.  Fixed. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W5&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Apr 10 23:01:12 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W0/1All 
<li>problem n: 890 
<li>Status: fixed
<li>Type: Wedgewide_HRR
<li>Action: Monitoring
<li>entered by: petemc 
<li>description is: Looks good.  Legal buffed FTM works. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W0/1&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Apr 10 23:15:44 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W6/7All 
<li>problem n: 381 
<li>Status: fixed
<li>Type: Wedgewide_HRR
<li>Action: Monitoring
<li>entered by: petemc 
<li>description is: Looks good.  Legally buffed FTM works. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W6/7&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Apr 10 23:30:01 2003 -->
<h3>Cosmics in the face of No Beam</h3> 
Allowed the shift crew to turn up the HV and run cosmics 
since the BD cannot seem to get beam into the Tev.  They  
are instructed to remove the Silicon and go to Standby when the BD calls and says they will start putting Beam in the machine,  
estimated to be > 2 Hours from now at least.
<!-- Author: SCN -->
<!-- Comment: Fri Apr 11 08;27;37 comment by...SCN -->
Good decision.  Still waiting for beam.  Took a lot of cosmics

<!-- Date: Thu Apr 10 23:32:22 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W0/1All 
<li>problem n: 926 
<li>Status: fixed
<li>Type: Wedgewide_HRR
<li>Action: Monitoring
<li>entered by: petemc 
<li>description is: Looks good with buffed FTM. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W0/1&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Apr 11 01:11:11 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W5L2 
<li>problem n: 63 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: petemc 
<li>description is: This bit 5 problem continues with a fairly high rate (~50%). 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Apr 11 01:15:21 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W4/5All 
<li>problem n: 724 
<li>Status: fixed
<li>Type: Wedgewide_other
<li>Action: Monitoring
<li>entered by: petemc 
<li>description is: This looks good.  Legally buffed FTM works. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W4/5&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Apr 11 01:25:45 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W10/11All 
<li>problem n: 935 
<li>Status: fixed
<li>Type: Other
<li>Action: Monitoring
<li>entered by: petemc 
<li>description is: This didn't cause any problems. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W10/11&layer=All">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Fri Apr 11 15:40:52 2003 -->
<h3>Store 2420</h3> was going great guns, but the TEL just tripped off, so we will get the Silicon to Standby and wait (and 
CDf will do trigger tests) until it comes back.
<!-- Author: SCN, Gino, Reid -->


<!-- Date: Fri Apr 11 15:43:27 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1816&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1816  width='300' align='top'></td><td>SVT map (until now)</a></td></tr></table>
<!-- Author: SCN -->


<!-- Date: Fri Apr 11 23:50:25 2003 -->
<table><tr><td><a href=/elog/notebooks/silicon/Fri_Apr_11_2003_235003.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1818  align='top'></td><td>Bias current for SB0W3L4 for past two months.</a></td></tr></table>
<!-- Author: David Clark -->
<!-- Comment: Fri Apr 11 23;52;42 comment by...David -->
<pre>Changed High limit on Bias from 100 to 500uA.</pre>

<!-- Comment: Fri Apr 11 23;56;07 comment by...David -->
This was changed due to IMON pinkie. <a href=
'/cgi/elog/elog.pl?nb=2003&action=view&page=303&frame=2&anchor=23:21:10.979'>
See e-log</a>.
<!-- Date: Fri Apr 11 23:54:47 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W3L4 
<li>problem n: 978 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: cigdem 
<li>description is: Bias current went up from 50 to 120/140.  <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=303&frame=2&anchor=23:21:10.979'> Bias Current seen in IMON.</a> Changed Bias current limit from 100 to 500.<br> <br> <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=149&frame=2&anchor=23:50:25'> This is the bias current history for the last 2 months. </a> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W3&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat Apr 12 07:41:52 2003 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 255
Calibration type  : standard
Run period tag    : Apr_2003
DPS-off run       : 161332
DPS-on run        : 161331
Requested by      : Yi Le
Main process id   : 219784617
Comment           : taken with beam
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->



<!-- Date: Sat Apr 12 11:41:30 2003 -->
<h3>Access Report</h3> 
We buffed up FTMs in the NET crate b0fib04 SB4WA/B SB5W0/1 SB5W2/3.  Everything was smooth as silk (except when the online 
system went down-that cost 10 minutes), we introduced no 
problems (didn't even need to clean or anything) and were done 
in about 2 hours.  Database entries made, system brought back 
to standby and cold-started.
<!-- Author: SCN, Cigdem, David -->


<!-- Date: Sat Apr 12 15:54:03 2003 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sat_Apr_12_2003_155354.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1820  align='top'></td><td>SVT Plot of today (after the access).  Looks fine. </a></td></tr></table>
<!-- Author: cigdem -->


<!-- Date: Sat Apr 12 19:30:18 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1821&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1821  width='300' align='top'></td><td>ISL chunck of RED because of PIPELINE out of Sync. David and I are going to try to understand what FIB it is. </a></td></tr></table>
<!-- Author: Gino and David -->
<!-- Comment: Sat Apr 12 19;39;10 comment by...Gino -->
Looking at SVXERRORLOGGER we figured out that the chunk of RED is IB4W2. IF the Silicon Pager get paged because of too many HRRs due to CAPID out of sync removing this WEDGE from the HDWDB should be considered. 


<!-- Date: Sat Apr 12 20:13:27 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1823&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1823  width='300' align='top'></td><td>Stuck ladder Errors on IB4W2. The next candidate for a buffed FTM.</a></td></tr></table>
<!-- Author: David -->

<!-- Date: Sat Apr 12 21:14:14 2003 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 255 finished successfully.

Job info
--------
Calibration type : standard
DPS-off run      : 161332
DPS-on run       : 161331
Requested by     : Yi Le
Submitted        : 2003-04-12 05:29:19
Completed        : 2003-04-12 19:05:55
Status           : SUCCESS
Comment          : taken with beam
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Sat Apr 12 21:31:43 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1824&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1824  width='300' align='top'></td><td>A plot of the status of the buffers during this run. I have to understand how this work.</a></td></tr></table>
<!-- Author: Gino -->
<!-- Comment: Sat Apr 12 21;34;05 comment by...GIno -->
<pre>The run is 161379. The plot is the fracction of time spent with 4,3,2,1,0 buffers empty during this run plotted versus the L1A rate.</pre>


<!-- Date: Sat Apr 12 22:43:40 2003 -->
<pre>I asked that the DAQ Ace performs an Coldstart of the silicon  
fib crates one by one. The coldstart was done between 22:13-22:20.  
This was suggested by Steve to see if the HRR run issues due 
to pipeline out of sync. will calm down.  
 
</pre>
<!-- Author: cigdem  -->
<!-- Comment: Sun Apr 13 00;40;24 comment by...cigdem  -->
<pre>The rate definetely went down after the coldstart. 
We do get now on the order of 1/hour a HRR due to pipeline out of sync. 
I decided not to take out IB4W2. 
The shift crew is informed that they should watch it and 
page me in case the situation starts to get turbulent again. 

</pre>


<!-- Date: Sun Apr 13 08:56:52 2003 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sun_Apr_13_2003_085620.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1829  align='top'></td><td>Bias Current History of IB1W3L0. </a></td></tr></table>
<!-- Author: cigdem -->
<!-- Comment: Sun Apr 13 08;58;31 comment by...cigdem -->
I was paged tonight twice, because the Bias Current of IB1W3L0 
crossed the high end limit of 100uA by 1 and than later by 
3uA. Limit is now set to 500 and this is the history of the bias current for this ladder. 


<!-- Comment: Sun Apr 13 09;00;51 comment by...cigdem -->
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=307&frame=2&anchor=06:52:04.651'>
And this is the Imon current history.</a> 


<!-- Date: Sun Apr 13 09:07:20 2003 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sun_Apr_13_2003_090650.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1831  align='top'></td><td>SVT PLOT of today. </a></td></tr></table>
<!-- Author: cigdem -->

<!-- Date: Sun Apr 13 09:49:45 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W0L1 
<li>problem n: 989 
<li>Status: needs_maintenance
<li>Type: Unknown
<li>Action: Diagnosis
<li>entered by: chill 
<li>description is: Ladder was integrated 1/21/03 13:23 by me after completion of ISL cooling work on west.  This ladder does not have a cooling problem. It was removed by on 1/27/03 for reasons undocumented (don't ask me I was at CERN).  We have no reason to think there is anything wrong with this ladder so it should be re-integrated ASAP.  If the 6/13/02 problem (AVDD and init failures) that dkclark mentions is the reason that this ladder is out, this should be immediately obvious.  If there is another reason that it should be removed then we will know that too (and document it this time).   
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B1W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Apr 13 13:14:45 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W0L1 
<li>problem n: 989 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Added_hdwdb
<li>entered by: bolla 
<li>description is: ADDED to HDWDB, turned it ON, runned it with svxdaq.  Not a single problem. I leave it IN for the next store. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B1W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Sun Apr 13 13;33;04 comment by...Gino -->
<H1> For the Si Pager carrier</H1>This ladder (IB1W0L1) has been re-integrated so with the next store a few plots with svxmon should be produced about its status (occupancy, mean charge and RMS charge).


<!-- Date: Sun Apr 13 15:18:15 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1832&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1832  width='300' align='top'></td><td>about 2200 seconds into the run we got a STUCK ladder error from <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=308&frame=2&anchor=14:43:43.065'> IB0W4 </a> The long time taken to readout the ladders (8 chips in read-all probably) had an impact on the L1DONE dead time. These plots are usefull for me to try (I'm a rooky on this) to understand a few things.</a></td></tr></table>
<!-- Author: gino -->


<!-- Date: Sun Apr 13 17:23:51 2003 -->
<pre>I was paged because of 7 pinkies in IMON.  
6 DVDD and 1 AVDD high currents.  
I came in and noticed, that SVXMON was not running since 1/2 hour. 
RT-server problems caused it to crash.   
I asked the shift crew to restart SVXMON and meanwhile  
to perform a manual HRR, which cured the pinkies.  
The list of pinkies you can find &lt;a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=309&frame=2&anchor=16:26:25.080'&gt; 
here.&lt;/a&gt; </pre>
<!-- Author: cigdem -->
<!-- Comment: Sun Apr 13 17;24;40 comment by...cigdem -->
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=309&frame=2&anchor=16:26:25.080'>
Here is the list of pinkies. </a> 


<!-- Comment: Sun Apr 13 17;37;05 comment by...cigdem -->
<pre>No yellow in SVXMON==&gt;no failures. </pre>


<!-- Date: Sun Apr 13 17:53:29 2003 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1833&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1833' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1834&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1834' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1835&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1835' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1836&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1836' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1837&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1837' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1838&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1838' width='300'></a></center>
<!-- Author: cigdem -->
<!-- Comment: Sun Apr 13 17;54;15 comment by...cigdem -->
<pre>strip mean charge, occupancy and rms charge for IB1W0L1. </pre>


<!-- Date: Sun Apr 13 21:41:43 2003 -->
I was paged, because  
<br> 
SB0W7,W8,W9 
SB1W7,W8,W9 
SB2W7,W8,W9 
<br> 
tripped.  
<br> 
The Trigger Inhibit was set, but there were not IFIX Alarms and  
also on the PS GUI there are no messages seen, that something 
tripped.  
The wedges were OFF (red) on the PS-GUI.  
While I was discussing with Steve what to do on the phone, the 
shift crew decided to take out silicon and to run without it.  
The wedges, which tripped came on to STandby.  
I came in and looked at the currents, everything looks ok. Until  
20:30, when the Trigger Inhibit was set. In the cases of the wedges, which tripped, the bias current drops at around 20:30.  
The wedges are 1/2 of b0fib02 and they belong all to the same 
PS crate: SWB, Bot.  
<br> 
Conclusion: It seems, that the PS had a glitch.  
I told the crew to power Silicon again and to include into the  
run.   
<!-- Author: cigdem -->
<!-- Comment: Sun Apr 13 21;43;26 comment by...cigdem -->
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=309&frame=2&anchor=20:41:09.378'>
Here is the Shift Elog Entry.</a> 


<!-- Comment: Sun Apr 13 22;06;29 comment by...cigdem -->
A more easy to read list: <br>

SB0W7<br>
SB0W8<br>
SB0W9<br>
<br>
SB1W7<br>
SB1W8<br>
SB1W9<br>
<br>
SB2W7<br>
SB2W8<br>
SB2W9<br>







<!-- Comment: Mon Apr 14 07;35;06 comment by...SCN -->
Since there was no "trip", it seems to me there are two possibilities <ol>
<li> All these wedges were sent an "OFF" command.  However, usually commands go wedge by wedge...
<li> The crate inhibit line was "pulled", thereby removing power to 
all supplies in the crate.  I am not sure how this would spontaneously happen, but I believe it matches the symptoms.
</ol>
I think this crate has had other infrequent communication problems recentl, so maybe it deserves a look at the cabling at least.
<!-- Date: Sun Apr 13 21:48:31 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1839&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1839  width='300' align='top'></td><td>Pipeline OUt of Sync in 693 Silicon channels caused  HRR. </a></td></tr></table>
<!-- Author: cigdem -->
<!-- Comment: Sun Apr 13 21;51;51 comment by...cigdem -->
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=309&frame=2&anchor=21:50:23.045'>
shift elog entry</a>



<!-- Date: Mon Apr 14 05:07:58 2003 -->
<center><a href='/elog/notebooks/silicon/Mon_Apr_14_2003_050301.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1841' ></a><a href='/elog/notebooks/silicon/Mon_Apr_14_2003_050352.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1843' ></a><a href='/elog/notebooks/silicon/Mon_Apr_14_2003_050417.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1845' ></a><a href='/elog/notebooks/silicon/Mon_Apr_14_2003_050424.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1847' ></a><a href='/elog/notebooks/silicon/Mon_Apr_14_2003_050708.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1851' ></a><a href='/elog/notebooks/silicon/Mon_Apr_14_2003_050720.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1853' ></a></center>
<!-- Author: cigdem -->
<!-- Comment: Mon Apr 14 05;25;33 comment by...cigdem -->
Was paged  because of IMON AVDD curren pinky of IB1W1L1. <br>
Ladder seems to have no data since 3:46am in SVXErrorlogger on  both the Phi and the Z-Side (plots will follow). 
<br>
<br>
You see here the AVDD,DVDD,BIAS,BIAS1, 2V DOIM and 5V DOIM currents. 
<dl>
<li> AVDD current does have two steps down. 
<dl>
<li> First Step at 3:30am by ~30mA.
<li> Second Step at 3:45am by ~20mA. 
</dl>
<li> DVDD current does have two steps down, too.
<dl>
<li> First Step at 3:30am by ~35mA. 
<li> Second Step at 3:45am by ~20mA. 
</dl> 
<li> BIAS current rock solid at 6. 
<li> BIAS1 current has 3 steps.
<dl>
<li> 1. Step is at 3:41am from 12uA -->11.5uA. 
<li> 2. Step is at 3:43am from 11.5uA -->12uA.
<li> 3. Step is at 3:46am from 12uA --> 11uA. 
     It stays since than at this value. 
</dl> 
<li> 2V DOIM current stable. 
<li> 5V DOIM current shows a step down at 3:30am from 1345 to 
      1340mA. Delta=5mA. Before this drop, current was increasing
since 3:15am in total of ~5mA. 
</dl>

<!-- Comment: Mon Apr 14 05;28;17 comment by...cigdem -->
<pre>No Problems reported about this ladder in PDB. 
Belongs to b0fib03. </pre>


<!-- Date: Mon Apr 14 05:36:51 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1854&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1854  width='300' align='top'></td><td>mean strip charge for the one phi side. </a></td></tr></table>
<!-- Author: cigdem -->
<!-- Comment: Mon Apr 14 05;38;22 comment by...cigdem -->
<pre>This is an example of all the other distributions of IB1W1L1.
All Strip Histogramms of this ladder don't have any entries in 
the short term Histogram(red). So nothing is seen on both 
Phi and Z sides for this ladder. 
</pre>


<!-- Date: Mon Apr 14 05:57:55 2003 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1855&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1855' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1856&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1856' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1857&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1857' width='300'></a></center>
<!-- Author: cigdem -->
<!-- Comment: Mon Apr 14 06;02;44 comment by...cigdem -->
With the help of "Find Message" Tool of SVX Error Logger 
I searched for any No Data entries of IB1W1L1 from yesterday
4pm until today 6am. <br>
<br> 
The first gif-file is the snapshot of my search criteria. <br>
The second gif-file shows that the first time IB1W1L1 gives 
"No Data" is 04/14/03 at 3:46am, which corresponds to the second
step down in AVDD and in DVDD currents seen in IMON.<br>
<br>
Since than it is giving "No data"-->second gif-file.<br>

<!-- Comment: Mon Apr 14 06;17;08 comment by...cigdem -->
<pre>We seems to have lost this ladder. &lt;br&gt;
The symthoms are not DVDD jumper failure. &lt;br&gt;
Looks like a AVDD2 failure. &lt;br&gt;
</pre>

<!-- Comment: Mon Apr 14 06;36;48 comment by...cigdem -->
Before the failure I see two HRR's because of PipeLine out of 
Sync in 75 chips. One at 0<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=310&frame=2&anchor=03:25:06.798'>
3:23:07</a> and the other one at <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=310&frame=2&anchor=03:45:48.553'>
03:43:37</a>.

<!-- Comment: Mon Apr 14 07;55;56 comment by...cigdem -->
<pre>IB1W1L1
=======

AVDD current
------------

Apr 14 03:26:43 2003   1015.00 --&gt; 985.00/980.00
Apr 14 03:41:00 2003    985.00 --&gt; 1010.00
Apr 14 03:41:10 2003   1010.00 --&gt; 950/965/970

DVDD current
------------

Apr 14 03:26:43 2003    370.00 --&gt; 320.00
Apr 14 03:41:00 2003    320.00 --&gt; 375.00
Apr 14 03:41:10 2003    370.00 --&gt; 300.00/305.00

</pre>
<!-- Comment: Mon Apr 14 09;11;55 comment by...Gino and Cigdem -->
<pre>Checked initialization log file:
04-14-2003 03:43:53 CDT : 1050309833 Init Fib f111 hdi 6 ERRORS: tried 16 chips: 
04-14-2003 04:06:18 CDT : 1050311178 Init Fib f111 hdi 6 ERRORS: tried 16 chips: 
04-14-2003 04:56:02 CDT : 1050314162 Init Fib f111 hdi 6 ERRORS: tried 16 chips: 
04-14-2003 05:13:21 CDT : 1050315201 Init Fib f111 hdi 6 ERRORS: tried 16 chips: 
04-14-2003 05:39:18 CDT : 1050316758 Init Fib f111 hdi 6 ERRORS: tried 16 chips: 
04-14-2003 06:01:27 CDT : 1050318087 Init Fib f111 hdi 6 ERRORS: tried 16 chips: 
04-14-2003 06:24:18 CDT : 1050319458 Init Fib f111 hdi 6 ERRORS: tried 16 chips: 
04-14-2003 06:45:14 CDT : 1050320714 Init Fib f111 hdi 6 ERRORS: tried 16 chips: 
&gt; 
It reads back 00s.
It came out of data taking at this time so no more errors.

Tested with svxdaq after the store was dropped:
During INITIALIZATION reads back 00s
During readout all you get is: f11100fc c2c20000
I AVDD = 570 mA
I DVDD = 290 mA

</pre>
<!-- Comment: Mon Apr 14 21;15;23 comment by...Gino -->
<pre>Forgot to say that the symtoms are NOT consistent with the AVDD2 
failure mode. It is more like this ladder is getting nothing at all. What if the DIGITAL DDR is completely gone (not being powered)? TO be tried on the bench.
</pre>
<!-- Date: Mon Apr 14 06:30:19 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W1L1 
<li>problem n: 992 
<li>Status: needs_work
<li>Type: AVDD2
<li>Action: Incident
<li>entered by: cigdem 
<li>description is: Was paged, because of IMON pinky in AVDD. Ladder has since 3:46am no data, seems to be dead.  The invetigations of the currents and in SVXMON you can find  <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=149&frame=2&anchor=05:07:58'> here. </a>. AVDD current is stepping down in two steps-->should check if it is an AVDD2.   
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B1W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Apr 14 07:03:01 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W1L1 
<li>problem n: 992 
<li>Status: needs_work
<li>Type: AVDD2
<li>Action: Removed_hdwdb
<li>entered by: cigdem 
<li>description is: I have taken the ladder out of the Hardware DB.   
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B1W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->





<!-- Date: Mon Apr 14 08:49:03 2003 -->
<pre>Checked for stuck ladders 
 
RUN		Wedges 
161411		IB4W2 
161414		IB0W4 
		IB0W0 
161415		none</pre>
<!-- Author: Gino -->



<!-- Date: Mon Apr 14 09:41:10 2003 -->
<pre>SB0W8/9 looks like the fuse on the FTM is gone!. 
Removed from HDWDB because of oncoming store. 
</pre>
<!-- Author: Gino -->
<!-- Comment: Mon Apr 14 11;39;47 comment by...Gino -->
<pre>Time stamp of the failure:
Mon Apr 14 07:56:56 2003 or earlier within a minute.
</pre>