<!-- Title: 15:01:33  Mon Aug 26 2002 -->
<!-- Crewchief: Silicon Group -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>PRevious file too long. 
3 shifts access coming on wednesday at 6 am. 
</pre>


<!-- Date: Mon Aug 26 17:08:00 2002 -->
<h3>Quench!</h3> which I heard from my office, so I came over 
to test the RF changes<ul> 
<li> Good News!  All ladders still initialize (on Standby) 
<li> OK News, so far the RF seems to be doing almost the right 
thing except it doesn't (yet) recognize all corrupt ladders as 
such.  Working on it. 
</ul>  
<!-- Author: SCN -->
<!-- Comment: Mon Aug 26 17;12;04 comment by...SCN -->
Looks like with a small tweak the RF fix works ok.  Runs are
150446, 150449, and 150452.  Please look at these and make sure they are
valid.  I will forward tweak to Paus.

<!-- Comment: Mon Aug 26 17;18;00 comment by...chill -->
<pre>I have checked the bias currents and L00 crowbars are all OK.</pre>

<!-- Date: Mon Aug 26 23:53:44 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W3L1 
<li>problem n: 638 
<li>Status: needs_work
<li>Action: Diagnosis_update
<li>entered by: bolla 
<li>description is: <pre>With BIT 7 HIGH every channel 4x becomes cx and so the 
VRB chop the readout because it is a EOR carachter.
The Umpacker can do very little for data that do not make it there.</pre> </ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Aug 27 00:43:42 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W6L2 
<li>problem n: 3 
<li>Status: unfixable
<li>Action: Action_request
<li>entered by: bolla 
<li>description is: <pre>Please chop this ladder where it should be done.
Chip a1 and a0 out of readout</pre> </ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Aug 27 06:35:30 2002 -->
<pre>Paged for HV trips in L00 from standby correlated with proton 
losses during beam studies.  Talk to MCR, find that these losses  
will likely continue.  Consequently, I turned L00 OFF.   
 
When quieter conditions return crowbars need to be examined. </pre>
<!-- Author: chill -->


<!-- Date: Tue Aug 27 06:44:41 2002 -->
<pre>Paged again for large losses which caused many SVX ladders to 
trip on bias from standby (Has this happened before?). 
 
Consequently, I turned OFF SVX and ISL as well. 
</pre>
<!-- Author: chill -->

<!-- Date: Tue Aug 27 10:02:19 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W6L2 
<li>problem n: 3 
<li>Status: unfixable
<li>Action: Change_last_chip
<li>entered by: nahn 
<li>description is: Fib now chops readout after chip 0xa2 sends last channel </ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Aug 27 15:01:59 2002 -->
<h3>Fib debugging</h3> 
For IB0W1 L1 I tried to reproduce <a href='http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W1&layer=L1'>Lester's "c5"</a> error using Fib2Vrb, and 
did not, so I cannot really swap around to see if it is a problem with the Fib or Vrb unless it is reproduceable with the ladder on 
(standby) and svxdaq.  I also looked at events by eye and examined the Calc Ram but all there was ok.<P> 
P.S. In case you were wondering, a decision was made to leave the Silicon off for now.
<!-- Author: SCN -->


<!-- Date: Tue Aug 27 19:42:07 2002 -->
<pre>I DID a fair amount of work to reproduce problem we will try to  
deal with during the access tomorrow. 
Here is what I got: 
SB0W11L0 BIT 4 Stuck LOW 
	 Wedge Situation: 
			L0 BIT 4 LOW PROBLEM REPRODUCED 
			L1 OUT 
			L2 GOOD 
			L3 GOOD 
			L4 chip 8a bit 5 LOW 100 
 
SB1W2L4 ZOO of errors 
	 Wedge Situation: 
			L0 GOOD 
			L1 GOOD 
			L2 During INIT reads back ffss 
			   Read OUT only partially the first chip 
			L3 GOOD 
			L4 PROBLEM NOT REPRODUCEABLE 
 
SB0W3L3 bit 2 and 3 LOW 
	 Wedge Situation: 
			L0 GOOD 
			L1 GOOD 
			L2 GOOD 
			L3 During INIT reads back 00s 
			   Read OUT BIT 2 and 3 STUCK LOW 
			   PROBLEM REPRODUCEABLE 
			L4 During INIT reads back 00s 
			   Read OUT ONLY PHI SIDE 
			   PROBLEM WELL KNOWN 
SB2W3L1 BIT 7 HIGH 
	 Wedge Situation: 
			L0 GOOD 
			L1 During INIT reads back 00s 
			   Read OUT ONLY PHI SIDE KNOWN PROBLEM 
			   FOR THE PROBLEM UNDER INVESTIGATION SEE * at  
			   the bottom of the entry, 
			L2 GOOD 
			L3 GOOD 
			L4 GOOD 
 
SB2W4L4 BIT 1 and 2 STUCK LOW 
	 Wedge Situation: 
			L0 GOOD 
			L1 GOOD 
			L2 GOOD 
			L3 GOOD 
			L4 PROBLEM REPRODUCED. Multiple BITs LOW 
 
SB2W7L4 BIT 2 and 3 STUCK LOW 
	 Wedge Situation: 
			L0 GOOD 
			L1 BIT 1 DEAD 
			L2 GOOD 
			L3 GOOD 
			L4 PROBLEM REPRODUCED. BIT 2 and 3 LOW 
 
SB0W6L4 OBDV PROBLEM 
	 Wedge Situation: 
			L0 OUT BAD 
			L1 GOOD 
			L2 GOOD 
			L3 LAST CHIP DOES NOT WORK OTHERWISE OK. 
			L4 DURING INIT READS BACK 0 DUE TO AVDD2 on chip a4 
			   OBDV PROBLEM REPRODUCEABLE  
 
SB2W6L4 BIT1 HIGH 
	 Wedge Situation: 
			L0 GOOD 
			L1 GOOD 
			L2 GOOD 
			L3 GOOD 
			L4 INIT OK 
			   BIT 1 HIGH RARELY PROBLEM REPRODUCEABLE. 
			    
 
 
 
* SB2W3L1 
			   FOR THE L1 TO UNDERSTAND THE PROBLEM I DID THE 
			   FOLLOWING: I set the Counter modulo to 20 and I take 
			   data. Here are 2 events: 
A GOOD ONE 
DataBlock 204 
03301502 00000000 00400000 00000000 00000000 00000000 030c0000 00000000  
e23188fc 851e0014 01140214 03140414 05140614 07140814 09140a14 0b140c14  
0d140e14 0f141014 11141214 13141414 15141614 17141814 19141a14 1b141c14  
1d141e14 1f142014 21142214 23142414 25142614 27142814 29142a14 2b142c14  
2d142e14 2f143014 31143214 33143414 35143614 37143814 39143a14 3b143c14  
3d143e14 3f144014 41144214 43144414 45144614 47144814 49144a14 4b144c14  
4d144e14 4f145014 51145214 53145414 55145614 57145814 59145a14 5b145c14  
5d145e14 5f146014 61146214 63146414 65146614 67146814 69146a14 6b146c14  
6d146e14 6f147014 71147214 73147414 75147614 77147814 79147a14 7b147c14  
7d147e14 7f14841e 00140114 02140314 04140514 06140714 08140914 0a140b14  
0c140d14 0e140f14 10141114 12141314 14141514 16141714 18141914 1a141b14  
1c141d14 1e141f14 20142114 22142314 24142514 26142714 28142914 2a142b14  
2c142d14 2e142f14 30143114 32143314 34143514 36143714 38143914 3a143b14  
3c143d14 3e143f14 40144114 42144314 44144514 46144714 48144914 4a144b14  
4c144d14 4e144f14 50145114 52145314 54145514 56145714 58145914 5a145b14  
5c145d14 5e145f14 60146114 62146314 64146514 66146714 68146914 6a146b14  
6c146d14 6e146f14 70147114 72147314 74147514 76147714 78147914 7a147b14  
7c147d14 7e147f14 831e0014 01140214 03140414 05140614 07140814 09140a14  
0b140c14 0d140e14 0f141014 11141214 13141414 15141614 17141814 19141a14  
1b141c14 1d141e14 1f142014 21142214 23142414 25142614 27142814 29142a14  
2b142c14 2d142e14 2f143014 31143214 33143414 35143614 37143814 39143a14  
3b143c14 3d143e14 3f144014 41144214 43144414 45144614 47144814 49144a14  
4b144c14 4d144e14 4f145014 51145214 53145414 55145614 57145814 59145a14  
5b145c14 5d145e14 5f146014 61146214 63146414 65146614 67146814 69146a14  
6b146c14 6d146e14 6f147014 71147214 73147414 75147614 77147814 79147a14  
7b147c14 7d147e14 7f14c1c1 00000000  
AND A BAD ONE 
DataBlock 270 
0438150b 00000000 00400000 00000000 00000000 00000000 04140000 00000000  
e23156fc 19f31e01 1e031e02 1e071e06 1e041e05 1e0f1e0e 1e0c1e0d 1e081e09  
1e0b1e0a 1e1f1e1e 1e1c1e1d 1e181e19 1e1b1e1a 1e101e11 1e131e12 1e171e16  
1e141e15 1e3f1e3e 1e3c1e3d 1e381e39 1e3b1e3a 1e301e31 1e331e32 1e371e36  
1e341e35 1e201e21 1e231e22 1e271e26 1e241e25 1e2f1e2e 1e2c1e2d 1e281e29  
1e2b1e2a 1e7f1e7e 1e7c1e7d 1e781e79 1e7b1e7a 1e701e71 1e731e72 1e771e76  
1e741e75 1e601e61 1e631e62 1e671e66 1e641e65 1e6f1e6e 1e6c1e6d 1e681e69  
1e6b1e6a 1e401e41 1e431e42 1e471e46 1e441e45 1e4f1e4e 1e4c1e4d 1e481e49  
1e4b1e4a 1e5f1e5e 1e5c1e5d 1e581e59 1e5b1e5a 1e501e51 1e531e52 1e571e56  
1e541e55 1eef19f3 1e011e03 1e021e07 1e061e04 1e051e0f 1e0e1e0c 1e0d1e08  
1e091e0b 1e0a1e1f 1e1e1e1c 1e1d1e18 1e191e1b 1e1a1e10 1e111e13 1e121e17  
1e161e14 1e151e3f 1e3e1e3c 1e3d1e38 1e391e3b 1e3a1e30 1e311e33 1e321e37  
1e361e34 1e351e20 1e211e23 1e221e27 1e261e24 1e251e2f 1e2e1e2c 1e2d1e28  
1e291e2b 1e2a1e7f 1e7e1e7c 1e7d1e78 1e791e7b 1e7a1e70 1e711e73 1e721e77  
1e761e74 1e751e60 1e611e63 1e621e67 1e661e64 1e651e6f 1e6e1e6c 1e6d1e68  
1e691e6b 1e6a1e40 1e411e43 1e421e47 1e461e44 1e451e4f 1e4e1e4c 1e4d1e48  
1e491e4b 1e4a1e5f 1e5e1e5c 1e5d1e58 1e591e5b 1e5a1e50 1e511e53 1e521e57  
1e561e54 1e551ef1 19f31e01 1e031e02 1e071e06 1e041e05 1e0f1e0e 1e0c1e0d  
1e081e09 1e0b1e0a 1e1f1e1e 1e1c1e1d 1e181e19 1e1b1e1a 1e101e11 1e131e12  
1e171e16 1e141e15 1e3f1e3e 1e3c1e3d 1e381e39 1e3b1e3a 1e301e31 1e331e32  
1e371e36 1e341e35 1e201e21 1e231e22 1e271e26 1e241e25 1e2f1e2e 1e2c1e2d  
1e281e29 1e2b1e2a 1e7f1e7e 1e7c1e7d 1e781e79 1e7b1e7a 1e701e71 1e731e72  
1e771e76 1e741e75 1e601e61 1e631e62 1e671e66 1e641e65 1e6f1e6e 1e6c1e6d  
1e681e69 1e6b1e6a 1e401e41 1e431e42 1e471e46 1e441e45 1e4f1e4e 1e4c1e4d  
1e481e49 1e4b1e4a 1e5f1e5e 1e5c1e5d 1e581e59 1e5b1e5a 1e501e51 1e531e52  
1e571e56 1e541e55 1ec327f3 1e011e03 1e021e07 1e061e04 1e051e0f 1e0e1e0c  
1e0d1e08 1e091e0b 1e0a1e1f 1e1e1e1c 1e1d1e18 1e191e1b 1e1a1e10 1e111e13  
1e121e17 1e161e14 1e151e3f 1e3e1e3c 1e3d1e38 1e391e3b 1e3a1e30 1e311e33  
1e321e37 1e361e34 1e351e20 1e211e23 1e221e27 1e261e24 1e251e2f 1e2e1e2c  
1e2d1e28 1e291e2b 1e2a1e7f 1e7e1e7c 1e7d1e78 1e791e7b 1e7a1e70 1e711e73  
1e721e77 1e761e74 1e751e60 1e611e63 1e621e67 1e661e64 1e651e6f 1e6e1e6c  
1e6d1e68 1e691e6b 1e6a1e40 1e411e43 1e421e47 1e461e44 1e451e4f 1e4e1e4c  
1e4d1e48 1e491e4b 1e4a1e5f 1e5e1e5c 1e5d1e58 1e591e5b 1e5a1e50 1e511e53  
1e521e57 1e561e54 1e551ed4 ae00bfd0 d0c2c2c4 00000000  
 
WITH THE DATA NOW at a fixed value it is clear that we are swapping  
channel with data. OBDV DUTY CYCLE MUST BE VERY BAD and NOT EVEN the  
SUPERFIB DEAL WITH IT PROBABLY DUE TO THE EXTREME DOIM VOLTAGES 
 
 
</pre>
<!-- Author: Gino -->
<!-- Comment: Wed Aug 28 05;23;35 comment by...Gino -->
<pre>SB5W7L0 OBDV
	Wedge Situation:
			L0 OBDV PROBLEM REPEATABLE (20%)
			L1 GOOD
			L2 GOOD
			L3 GOOD
			L4 GOOD
			
DataBlock 96
0180da0b 00000000 00000000 00000000 00000000 0000015e 00000000 00000000 
e57018fc 83200037 0136022e 0334043c 05330632 07310838 09320a30 0b310c3a 
0d370e3c 0f331036 11331233 13331438 15331637 17301836 19381a3b 1b391c3a 
1d3c1e38 1f342039 21382237 23382432 25372634 27372838 29342a3e 2b382c36 
2d352e33 2f323036 313f3233 33373431 35363639 3736383b 39383a37 3b343c34 
3d333e38 3f36403b 41344234 43304438 453a4634 47384833 49364a36 4b364c38 
4d334e35 4f335038 51365239 53385438 55365633 57365838 59365a35 5b335c38 
5d345e3b 5f376033 613a6239 633a6434 65336636 6735683e 693b6a33 6b3b6c34 
6d336e38 6f317036 71357236 73387438 75387638 77307830 793f7a33 7b387c33 
7d387e3e 7f388220 00350134 02340336 04350536 0635073a 0832093a 0a340b36 
0c340d35 0e340f31 102f112e 12341337 14361537 16321730 18381938 1a331b2f 
1c341d32 1e331f35 20332130 22362338 24372534 26312732 28d0d0c2 c2c40000 
DataBlock 268
</pre>
<!-- Date: Tue Aug 27 21:04:21 2002 -->
<pre>POST-STUDIES/PRE-ACCESS CHECKOUT. 
 
Power to STANDBY OK. 
L00 crowbars OK. 
Coldstart OK. 
Take Data OK w/ HEVB(Runs 150500,150501). 
Leave system in STANDBY for warm-up tomorrow. 
 
Note: No reformatter errors observed in runs 150500,150501.</pre>
<!-- Author: chill -->



<!-- Date: Wed Aug 28 07:53:52 2002 -->
ISL warm-up to 16 deg started at 07:50.
<!-- Author: Andy H. -->
<!-- Comment: Wed Aug 28 07;59;40 comment by...Andy H. -->
ISL temp trip limits set to 25 / 25 / 35 for CC / CPC / blocked CC.


<!-- Date: Wed Aug 28 09:03:36 2002 -->
SVX warm-up to 6 deg started.  SVX/L00 trip limits changed to 
their nominal 6 deg limits.  SVX remains at STBY to help warm up 
faster.
<!-- Author: Andy H. -->
<!-- Comment: Wed Aug 28 12;55;58 comment by...Andy H. -->
Everyone warm by about 11:45.  Trip limits maxed out.
<!-- Date: Wed Aug 28 10:01:54 2002 -->
<pre>Andy added 5 new tags to the ifix temperature message:  
SVX_TE_GAS_E_INLET =   4.09  
SVX_TE_GAS_E_UP =  15.58  
SVX_TE_GAS_E_DN =   8.98  
SVX_TE_GAS_W_UP =   8.98  
SVX_TE_RH_NE_1 =  15.28  
These measure the air temperature in various points. 
I modified the temperaure spy accordingly, so these temps are 
reported in the daily file.</pre>
<!-- Author: S. D&#39;Auria -->


<!-- Date: Wed Aug 28 12:04:02 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-706&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-706  width='300' align='top'></td><td>For Gino</a></td></tr></table>
<!-- Author: Andy H. -->


<!-- Date: Wed Aug 28 12:48:20 2002 -->
<h3>DAQ Access report</h3><ul> 
<li> Swapped Fibs to put a "doim killing Fib" (not really, but it is a fib where one of the DOIMs died) in the pitwib slot  
<table> 
<tr><th>SN<th>PREP<th>Was in<th>Is now in</tr> 
<tr><td> 160 <td> 550961 <td> b0fib06 Sl 17 SB5W4/5 <td>b0fib03 Sl 12 IB2W2/pitwib </tr> 
<tr><td> 116 <td> 560604  <td>b0fib03 Sl 12 IB2W2/pitwib <td> b0fib06 Sl 17 SB5W4/5 </tr> 
</table> 
I also made sure the firmware and sequences on 116 are up to date 
(undoing <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=119&frame=2&anchor=11:12:22'> 
this</a>). 
<li> Tested SB4W0/1 with Fib2Vrb test in response to <a href='http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B4W1&layer=L4'>SB4W1 L3 inducing problem on L4</a> but saw no trouble 
</ul>   
  
<!-- Author: SCN -->



<!-- Date: Wed Aug 28 13:59:11 2002 -->
<p>Power stuff we did today: 
<ul> 
  <li>Checked the jumpers for SB4W4 L2 and L4.  They were in the 50uA position.  They have been moved to the 5mA where they belong. 
  <li>Swapped power supplies between SB5W4 and the PitWIB 
  <li>Changed bias splitting for SB3W1L4 to be 50/50 (instead of 0/100) 
  <li>Checked the anomolous 3.2 volts on IB5W5L3 bias.  It measures as zero and is just an offset in the calibration of the PS. 
  <li>Changed bias splitting for IB1W4L0 so that it is now 30/70. 
  <li>Investigated IB2W2 Layers 1, 2, and 3 biases with the breakout adapter.  They all seem normal. 
</ul> 
  
<!-- Author: Napora and Mumford -->


<!-- Date: Wed Aug 28 14:19:57 2002 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-707&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-708' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-709&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-710' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-711&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-712' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-713&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-714' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-715&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-716' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-717&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-718' ></a></center>
<!-- Author: Gino -->
<!-- Comment: Wed Aug 28 15;19;41 comment by...Gino -->
<pre>BIT 3 light Output measurements (with OBDV as a trigger) taken from SB2W7L4 as the temperature of the silicon was going up.

Weird enough the Light Output is increasing with increasing 
temperature. The absolute value should be taken with large 
errors (attenuation due to fibers and so on) but the trend is 
well measured due to the fact that we did not move anything in 
the equipment.
This could explain why with the step DOWN in temperature we got 
some bits getting stuck LOW.</pre>


<!-- Date: Wed Aug 28 15:20:50 2002 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-706&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-706' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-722&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-722' width='300'></a></center>
<!-- Author: Gino -->
<!-- Comment: Wed Aug 28 15;22;46 comment by...Gino -->
This is a better picture of what happened with the light Output of BIT 3 of SB2W7L4 during the warm-up of today access.

<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=121&frame=2&anchor=14:19:57'>
See previous entry </a> 






<!-- Date: Wed Aug 28 18:38:00 2002 -->
<pre>I have cooled the SVX at 4 C and ISL at 6 C. 
  
Changed the temperature trip limits to:  
SVX                   ISL                     L00   
 
BH      15        CC      20                SIL 15  
DOIM    20        CPC     15                Hyb 15   
PCW1A_2 28        blocked 33   
DDR     21        CCs   
=======================================================  
Now          
	      SVX    ISL   L00  
min temp       4      6      4  
max temp       9      12     6  
 
If everything is OK, we will go soon to -6 C for SVX. Chris and  
Gino are powering the detector.   
</pre>
<!-- Author: Mircea Coca -->


<!-- Date: Wed Aug 28 23:52:01 2002 -->
<pre>&lt;pre&gt; 
SILICON ACCESS REPORT: 
&lt;a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=121&frame=2&anchor=07:53:52'&gt; 
WARM UP &lt;/a&gt; without any trouble.  
 
&lt;a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=121&frame=2&anchor=12:48:20'&gt; 
DAQ ACTIVITIES &lt;/a&gt;  Finalized to further investigation with the PITWIB. 
 
 
 
&lt;a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=121&frame=2&anchor=13:59:11'&gt; 
POWER SUPPLIES WORK &lt;/a&gt; done succesfully by the JHU fellows. 
 
&lt;a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=121&frame=2&anchor=15:20:50'&gt; 
OPTICAL MEASUREMENTS &lt;/a&gt; and other work on the optical chain. 
 
FINAL CHECK with some question marks (NO DARK CURRENT) about the BIAS CONNECTION FOR 2 ISL Ladders.  
We re-entered the BORE and all connectors were pushed IN and looked FINE 
 
Noise Measurements make us confident the ladders are now OK. 
 
More Informations might follow tomorrow. 
&lt;/pre&gt;</pre>
<!-- Author: Gino -->


<!-- Date: Wed Aug 28 23:52:29 2002 -->
<pre>&lt;pre&gt; 
SILICON ACCESS REPORT: 
&lt;a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=121&frame=2&anchor=07:53:52'&gt; 
WARM UP &lt;/a&gt; without any trouble.  
 
&lt;a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=121&frame=2&anchor=12:48:20'&gt; 
DAQ ACTIVITIES &lt;/a&gt;  Finalized to further investigation with the PITWIB. 
 
 
 
&lt;a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=121&frame=2&anchor=13:59:11'&gt; 
POWER SUPPLIES WORK &lt;/a&gt; done succesfully by the JHU fellows. 
 
&lt;a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=121&frame=2&anchor=15:20:50'&gt; 
OPTICAL MEASUREMENTS &lt;/a&gt; and other work on the optical chain. 
 
FINAL CHECK with some question marks (NO DARK CURRENT) about the BIAS CONNECTION FOR 2 ISL Ladders.  
We re-entered the BORE and all connectors were pushed IN and looked FINE 
 
Noise Measurements make us confident the ladders are now OK. 
 
More Informations might follow tomorrow. 
&lt;/pre&gt;</pre>
<!-- Author: Gino -->


<!-- Date: Thu Aug 29 01:15:43 2002 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-723&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-723' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-724&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-724' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-725&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-725' width='300'></a></center>
<!-- Author: Andy H. -->
<!-- Comment: Thu Aug 29 01;19;04 comment by...Andy H. -->
SVX cooled down to -6, ISL to +6.  Trip limits shown above.  SVX BHE2 supply valve opened to 75% in order to compensate for less flow through this circuit at lower temperature.  Redefined chiller temperature alarm/warning limits to sensible (yet agressive) values.  All alarms unsilenced.  C'est tout.  I'm going home.

<!-- Date: Thu Aug 29 07:41:32 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W3L1 
<li>problem n: 560 
<li>Status: needs_access
<li>Action: Light_investigated
<li>entered by: lmiller 
<li>description is: DRO, had RX swap. Measured OBDV cold to be 50.7% duty cycle, 424microW (with  extension cable). Should try superfib swap, could also have  the DOIM voltage reduced (2V is 1.68, nominal 1.93). </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Aug 29 07:45:35 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W3L3 
<li>problem n: 339 
<li>Status: needs_study_time
<li>Action: Light_investigated
<li>entered by: lmiller 
<li>description is: <pre>DRO chip 85 to 00f3 in NN. Unable to reproduce this in svxdaq
in sparse or readall. Light looked fine at transition from 
chip 86 to 85.
Should try putting chip 86 in readall and do rate dependency study.</pre> </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Aug 29 07:47:46 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W6L4 
<li>problem n: 620 
<li>Status: needs_access_2hr
<li>Action: Swap_RX
<li>entered by: lmiller 
<li>description is: RX 420 out, repinned 679 in. Problem not fixed. Needs light investigation.  </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Aug 29 07:49:50 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W4L3 
<li>problem n: 59 
<li>Status: needs_observation
<li>Action: Swap_RX
<li>entered by: lmiller 
<li>description is: <pre>RX 946 out, repinned 154 in for bit 4 high. 
Problem not seen at +4 degrees.</pre> </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Aug 29 07:53:59 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W0L0 
<li>problem n: 612 
<li>Status: needs_access
<li>Action: Light_investigated
<li>entered by: lmiller 
<li>description is: <pre>OBDV measured to have 715 microW (with extension cable) and 50.6%
duty cycle, so too much light. Needs SuperFib and if that doesn't
work then needs light attenuation. 2V is 1.93 (already nominal).</pre> </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Aug 29 08:08:30 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W9L2 
<li>problem n: 618 
<li>Status: needs_bore_access
<li>Action: Light_investigated
<li>entered by: lmiller 
<li>description is: Measured light:  bit 1 120 microW -- this is probably an RX problem. bit 7  20 microW       \ bit 6 ~hundreds microW / this is probably a DOIM cable problem. Should look at this in the bore.  </ul>
<!-- Author: Problem DB -->
<!-- Comment: Thu Aug 29 08;11;58 comment by...Lester -->
<pre>Typo -- That is bit 0, not bit 1</pre>

<!-- Date: Thu Aug 29 08:17:06 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W6L4 
<li>problem n: 345 
<li>Status: needs_bore_access
<li>Action: Light_investigated
<li>entered by: lmiller 
<li>description is: <pre>Low bits are low light:

Bit 7 11 microW
Bit 6 18 microW
Bit 5 ~hundreds microW

Needs light investigation in bore 
to check for DOIM cable damage</pre> </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Aug 29 10:25:46 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W4L0 
<li>problem n: 404 
<li>Status: needs_observation
<li>Action: PS_work
<li>entered by: chill 
<li>description is: PS modified to have 70/30 HV split.  Voltage limit not changed.  Need data to see if this will increase efficiency enough.    </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Aug 29 10:30:55 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W2L0 
<li>problem n: 581 
<li>Status: needs_bore_access
<li>Action: Bore_work
<li>entered by: chill 
<li>description is: No obvious damage to cable was seen in bore. </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Aug 29 10:36:54 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W2L0 
<li>problem n: 581 
<li>Status: needs_bore_access
<li>Action: LV_cable
<li>entered by: chill 
<li>description is: Exhaustive cable probing confirms AVDD short to GND (50 ohm).  There is also a connection between VRF_LY2 and ASP_LY0 which may be playing a role. </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Aug 29 10:46:30 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W2L2 
<li>problem n: 517 
<li>Status: needs_bore_access
<li>Action: LV_cable
<li>entered by: chill 
<li>description is: VRF_LY2 and VRF_LY3 connected by 17 ohm, implicating sense cable.  Sure enough, VRF_LY2 has 0 ohm short to ASP_LY0.  68 ohm (43 ohm to DOIM) connection between most of sense connector and this reference as well. </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Aug 29 10:47:14 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W2L3 
<li>problem n: 655 
<li>Status: needs_bore_access
<li>Action: Diagnosis
<li>entered by: chill 
<li>description is: VRF_LY2 and VRF_LY3 connected by 17 ohm, implicating sense cable.  Sure enough, VRF_LY2 has 0 ohm short to ASP_LY0.  68 ohm (43 ohm to DOIM) connection between most of sense connector and this reference as well </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Aug 29 10:52:51 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W5L2 
<li>problem n: 630 
<li>Status: needs_observation
<li>Action: Added_hdwdb
<li>entered by: chill 
<li>description is: Will run this ladder with first chip in readall.  Perhaps this solves the problem if it is localized to the sparsification logic of the chip (motivated by fact that this doesn't happen in calibrations - it is either this or L1A rate).  Take data and see. </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Aug 29 10:55:03 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W5L3 
<li>problem n: 398 
<li>Status: fixed
<li>Action: PS_work
<li>entered by: chill 
<li>description is: Access confirms 3.2V is just an offset. </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Aug 29 11:03:59 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W8L2 
<li>problem n: 502 
<li>Status: needs_study_time
<li>Action: Diagnosis_update
<li>entered by: chill 
<li>description is: Flashlight test performed in bore.  Fiber is ok.  Noticed that edge bits could be made to fade to black as a function of angle which cable aproaches FTM, especially if orange jacket is retracted.  This may be causing the OBDV problem here (and elsewhere?).  Should be confirmed during study time. </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Aug 29 11:40:52 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W1L3 
<li>problem n: 465 
<li>Status: needs_observation
<li>Action: Bore_work
<li>entered by: chill 
<li>description is: Bias 1 now draws some (small) current.  Bias 0 still draws no current.  Added to HDWDB, check for physics.  </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Aug 29 12:02:39 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W8L1 
<li>problem n: 385 
<li>Status: unfixable
<li>Action: Diagnosis_update
<li>entered by: chill 
<li>description is: This ladder lost bias as a result of the 3/30/02 radiation incident.  Bore work inicates no problem with connections - yet still no current is drawn when HV is applied.  This ladder is likely unrecoverable. </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Aug 29 12:04:49 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W4L0 
<li>problem n: 392 
<li>Status: needs_bore_access
<li>Action: LV_cable
<li>entered by: chill 
<li>description is: No cable damage observed.  On long access, should consider stringing spare cable. </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Aug 29 12:06:54 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W2L2 
<li>problem n: 81 
<li>Status: needs_bore_access
<li>Action: Bore_work
<li>entered by: chill 
<li>description is: Did not get a chance to check for leaky capacitor on access as that would require removing the JC.  Should be done when we have extended bore access. </ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Aug 29 17:56:12 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Thu_Aug_29_2002_175605.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-727  align='top'></td><td>SB3W1L4: noise vs channel on a region on the Z side. Different color are different BIAS voltages</a></td></tr></table>
<!-- Author: gino -->
<!-- Comment: Thu Aug 29 18;00;19 comment by...Gino -->
Changed NOMINAL VBIAS on the HDWDB from 15 V to 45 V.
As a result of the chnage of the BIAS splitting done <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=121&frame=2&anchor=13:59:11'>
yesterday </a> by Rob and Reid. We should NOW be able to deplete the ladder.

<!-- Date: Thu Aug 29 18:03:08 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W1L4 
<li>problem n: 80 
<li>Status: fixed
<li>Action: PS_work
<li>entered by: bolla 
<li>description is: BIAS PLITTING AND NOMINAL VBIAS CHANGED.<a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=121&frame=2&anchor=17:56:12'> Problem FIXED </a>   </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Aug 29 18:06:30 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W4L4 
<li>problem n: 621 
<li>Status: needs_access
<li>Action: Diagnosis_update
<li>entered by: bolla 
<li>description is: NO BITS found completely dead during access. <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=121&frame=2&anchor=15:20:50'> Some surprises while investigating Bit 3 light output vs temperature </a> </ul>
<!-- Author: Problem DB -->
<!-- Comment: Thu Aug 29 18;10;52 comment by...Gino -->
<pre>The light output vs T were measured on SB2W7L4.</pre>


<!-- Date: Thu Aug 29 21:12:15 2002 -->
Did some SRC + TS testing with the new Readout List feature.  Took over 2 million events at L1A o~ 20 KHz (no Silicon was on) 
and saw no TSI related errors on the SRC error page, so I declared the SRC ok in terms of Readout List.  Either I or someone else was kind enough to re-enable the rate limiter (since 
I cannot remember, I called in to check) so we should be "all set".
<!-- Author: SCN -->


<!-- Date: Fri Aug 30 12:02:15 2002 -->
<p> 
I figured out the 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=120&frame=2&anchor=16:36:49'> 
trigger-inhibit-not-firing problem</a> from a couple weeks ago. 
I found out that if no one is logged into iFix on the SVXIICON PC, then SVXIICONcannot write to the CDF_S2 database (where the inhibit tags are).  Now it turns out that if some airhead (read: Andy) leaves his 
priviledged account logged in for some period of time, iFix automatically logs it out.  D'oh.  Jim Loskot is going to change 
this behavior such that iFix will instead log in the "public" account (this is how the cryo PC's are set up).  This ought to cure the problem.
<!-- Author: Andy H. -->


<!-- Date: Sat Aug 31 00:49:18 2002 -->
<pre>Store # 1711. 
Silicon Is now integrated into Data taking with CDF since midnight. 
 
REFORMATTER ERROR is still an issue.  
The Counter on the Level 3 Display keep countin Reformatter  
errors and popping the window up in front of the DAQ ACE. 
NOTHING is recorded on the  errorfile150799_reformatter.log. 
 
</pre>
<!-- Author: GIno -->

<!-- Date: Sat Aug 31 02:12:42 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W0L1 
<li>problem n: 372 
<li>Status: fixed
<li>Action: Init_RB_mask
<li>entered by: bolla 
<li>description is: <pre>Never failed lately. Changed HDI address back to normal</pre> </ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Aug 31 02:15:04 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W0L0 
<li>problem n: 604 
<li>Status: fixed
<li>Action: Init_RB_mask
<li>entered by: bolla 
<li>description is: <pre>Never Failed AGAIN since latest report so HDI back to nominal</pre> </ul>
<!-- Author: Problem DB -->



<!-- Date: Sat Aug 31 02:52:03 2002 -->
<pre>With the help of Steve Nahn and Ilya the reformatter error was FIXED. 
 
HERE IS THE _EMAIL FROM STEVE THAT WAS GIVEN TO ILYA that implemented  
the change and recompiled the reformatter. 
 
Subject:  
                 Reformatter almost right...   
                                                                            From:  
                 Steve Nahn &lt;nahn@fnal.gov&gt;   
           Date:  
                 Mon, August 26, 2002 11:29 am   
             To:  
                 ikrav@fnal.gov, paus@fnal.gov, bolla@fnal.gov, chill@fnal.gov   
         Priority:  
                 Normal   
 
 
 
   Hi 
     There is a little bug in the RF still, which is completely my fault as 
   I gave Christoph the 
   wrong code.  The bug is in rr_rawevt.c and looks like: 
 
    corr |= (((k&gt;4) ? 0x10 : 0) &lt;&lt; 20);       /* Or in PC bit(20);Chan 5-9 
   */ 
 
   It says it is ORing in bit 20; 
   however, if you look at the code, you see it does not OR in bit 20, it 
   actually ORs 
   in bit 21.  (This comes from a habit of doing it slightly differently). 
   Correct code should be: 
 
    corr |= (((k&gt;4) ? 0x1 : 0) &lt;&lt; 20);       /* Or in PC bit(20);Chan 5-9 
   */ 
 
   So what happens now is the bad fib id gets turned into a good fib id but 
   not the good fib id, 
   then you get a duplicate fib id error, only in the case where the 
   problem is in a channel &gt; 4. 
 
   Also, these are not showing up in the RC error log file as they should 
   be.  Gino had to hunt for them 
   on a node by node basis.  This is not my bug (I don't think).  Probably 
   we want to get this changed 
   the next chance we get.</pre>
<!-- Author: Gino -->
<!-- Comment: Sat Aug 31 06;19;59 comment by...SCN -->
Note the date and time on my home computer is a little wacky.
<!-- Comment: Sat Aug 31 06;22;30 comment by...SCN -->
Also, I was a little tired-the bug was really ORing in bit
24, not bit 21.  This has the effect of all even bulkheads would
jump to odd bulkheads as well as getting the wrong PC (all
would be even) Eg   e010 -> e100
<!-- Date: Sat Aug 31 03:07:56 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sat_Aug_31_2002_030746.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-729  align='top'></td><td>SVT MAP from run 150801 showing a new HOLE on SB1W0. SB1W0L2 stopped giving data.</a></td></tr></table>
<!-- Author: Gino -->
<!-- Comment: Sat Aug 31 03;16;58 comment by...Gino -->
<pre>I believe it is a OBDV problem. We do not see any data since RUN# 150500 that was taken 
&lt;a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2002&action=view&page=717&frame=2&anchor=21:09:20'&gt;
Just Before the ACCESS &lt;/a&gt; but right after some trouble with the beam.
The ladder still initialize! 
The current consumption is still normal.
	FOR THE LADDER
	and FOR THE DOIM in that PORTCARD
I hope an RX SWAP can fix it.

I SUGGEST SWAPPING THE FIBER at the FTM and:
If the ladders work we swap the RX.
If it DOES NOT we think.
</pre>

<!-- Comment: Sat Aug 31 03;19;03 comment by...Gino -->
<pre>Spoke with Alessandro Cerri that was here in the COntrol ROOM.
He tried to use the L4 in that wedge instead of the L2.
THIS SHOULD BE VISIBLE IN RUN 150802.
I do not see any impact at all. TOO BAD
</pre>

<!-- Comment: Sat Aug 31 03;29;52 comment by...Gino -->
<pre>With Alessandro we (HE) found the bug. He masked the L3 instead of the L2.
He is now correcting the problem. We'll see how it goes.
</pre>

<!-- Comment: Sat Aug 31 04;39;23 comment by...Gino -->
<pre>The wedge now sees something but it is pretty inefficient.</pre>

<!-- Comment: Sat Aug 31 11;58;46 comment by...Bill A -->
Sometimes late at night things seem to be more clear
than they actually are.  (Or so I find.)  There would
be a pattern file update that would have to correspond
to this change in layer choice; it's not something that
can be done in a few minutes.  So the fact that no
improvement is seen when switching does not imply that
switching is hopeless when done in the light of day.

<!-- Date: Sat Aug 31 04:42:13 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W0L2 
<li>problem n: 656 
<li>Status: needs_access_2hr
<li>Action: Monitoring
<li>entered by: bolla 
<li>description is: <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=121&frame=2&anchor=03:07:56'> SB1W0L2 </a> stopped giving data before run 150500.  WE NEED TO SWAP THE FIBER WITH ANOTHER FTM CHANNEL AND IF IT WORKS SWAP THE RX  </ul>
<!-- Author: Problem DB -->





<!-- Date: Sat Aug 31 15:46:18 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 190
Calibration type  : standard
Run period tag    : Aug_2002
DPS-off run       : 150808
DPS-on run        : 150807
Requested by      : R. Eusebi
Main process id   : 24608590
Comment           : See e-log 8/31/2002, day shift
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->



<!-- Date: Sat Aug 31 21:42:17 2002 -->
<pre>Silicon to OFF before end of store 1712, for safety due to loss 
of RF. 
 
Silicon back to STANDBY after pbars loaded. 
Had trouble with IB5W5L2, SB2W10L1 - after several tried left 
decision to remove them until after scraping and the ON 
transition. 
 
After scraping and beam evaluation, silicon to ON. 
Had trouble with SB2W3 due to spontaneous transition + ACE  
booking crates prematurely. 
We need to go over shot-setup checklist with Kaori one more time. 
No run had been taken to establish L1A rate, so just verified L1A  
rate limiter was enabled and ACTIVATED the run. 
 
Silicon taking data in store 1713. 
</pre>
<!-- Author: chill -->