<!-- Title: 09:45:47  Mon Apr 28 2003 -->
<!-- Crewchief: Jason Nielsen -->
<!-- Op1: silicon crew -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
New week, new file.  

<!-- Date: Mon Apr 28 11:39:11 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W2All 
<li>problem n: 957 
<li>Status: fixed
<li>Type: Wedgewide_HRR
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: No problems seen since ftm was switched.  fixed! 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W2&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Apr 28 11:49:36 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W2L2 
<li>problem n: 904 
<li>Status: fixed
<li>Type: DRO_00F3
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: since the buffed ftm was installed there have been no errors--fixed. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W2&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Apr 28 11:51:41 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W2L3 
<li>problem n: 905 
<li>Status: fixed
<li>Type: DRO_00F3
<li>Action: Diagnosis_update
<li>entered by: tompkins 
<li>description is: buffed ftm seems to be doing its job--no errors, considered fixed. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Apr 28 11:55:37 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W0L4 
<li>problem n: 888 
<li>Status: needs_observation
<li>Type: DRO_00F3
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: DRO_00F3 rate fluctuates between .5% and 1.15%.  doesn't appear to be getting worse, but is present in over 90% of runs 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B5W0&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Apr 28 12:01:42 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W1All 
<li>problem n: 900 
<li>Status: fixed
<li>Type: DVDD
<li>Action: Command_signal
<li>entered by: tompkins 
<li>description is: no problems since buffed ftm installed, considered fixed. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B5W1&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Apr 28 13:42:16 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W2/3All 
<li>problem n: 987 
<li>Status: fixed
<li>Type: Other
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: no problems, looks like the buffed ftm works. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B1W2/3&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Apr 28 13:51:50 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W6/7All 
<li>problem n: 979 
<li>Status: fixed
<li>Type: Other
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: no new problems, buffed ftm successful. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W6/7&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Apr 28 13:54:44 2003 -->
<h3>FFO related changes</h3> 
<ul> <li> During last access, I put the SRC-FFO Glink signal on 
a different fiber in the cable bundle, to see if it helps 
the "crate wide" pipeline out of synch problem.  Results pending 
more data (so far so good) 
<li> Just plugged in the four SVX FFO status cables into the 
SRCTM (in anticipation of the "handbrake").  I expect no trouble, but if there is (<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=54&frame=2&anchor=20:15:28'>SRC failing initialization</a> for instance...) just remove the cables (4 white ones in the back of the SRC crate, b0svx02, 1RR21G Top) 
and do a cold start. 
</ul> 
I gave the Si to the crew for COSMICs during the 2 hours of quiet time (and to test this change)  
<!-- Author: SCN -->

<!-- Date: Mon Apr 28 13:59:17 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8/9All 
<li>problem n: 980 
<li>Status: fixed
<li>Type: Other
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: no new problems introduced--successful.   
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W8/9&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Apr 28 14:03:26 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W8/9All 
<li>problem n: 981 
<li>Status: fixed
<li>Type: Other
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: no new problems introduced--buffed ftm successful 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W8/9&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Apr 28 19:07:56 2003 -->
<H3>Store #2491: CDF Lumi: 29E30.</H3> 
TevMon functioned correctly, and high voltage came up with no problems.  There is some problem with e061, inefficient on phi side and missing most of the data on z side.
<!-- Author: Jason, Gino -->


<!-- Date: Mon Apr 28 19:15:39 2003 -->
<center><a href='/elog/notebooks/silicon/Mon_Apr_28_2003_191515.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1911' ></a></center>
<!-- Author: Jason -->


<!-- Date: Mon Apr 28 19:17:29 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1913&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1913  width='300' align='top'></td><td>Z-side occupancy for e061</a></td></tr></table>
<!-- Author: Jason -->


<!-- Date: Mon Apr 28 19:17:47 2003 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1912&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1912' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1913&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1913' width='300'></a></center>
<!-- Author: Jason -->
<!-- Comment: Mon Apr 28 19;19;01 comment by...Jason -->
Phi- and z-side occupancy for e061.  Inefficient on phi-side and missing most data on z-side.  This is the cause of the inefficient wedge in SVT.


<!-- Date: Mon Apr 28 20:09:30 2003 -->
<pre>The data from e061 is garbage.  Here I reproduce the dump of e061  
and e062.  (e062 looks normal.) 
 
1315600 c1c1 0000 e061 0ffc 852d 0007 1717 02c3 
1315620 02c1 02c0 02f3 660f 0f04 0520 fd85 2630 
1315640 3e36 7b25 3657 6d0e 04ef 29f3 0a25 0508 
1315660 0d01 010c 2e1e 1906 0df1 291d 1c1f 0701 
1315700 1463 877b 1b08 040d 65d9 87f9 3b11 0826 
1315720 2d08 060c 21f3 b319 f8c9 6209 0503 3236 
1315740 1107 070b 1203 cb0c e062 0ffc 892d 00f3 
1315760 2508 2618 2794 2878 2926 2a10 2b02 6b08 
1316000 6c19 6d80 6e90 6f1c 700e 7112 7214 7312 
1316020 740c 7509 7603 882d 08f3 0913 0a13 0b26 
1316040 0c1b 0d37 0e1b 0f07 79f3 7a09 7b01 872d 
1316060 0df3 0e0b 0ff3 862d 0f04 1009 11f3 1b01 
1316100 1c0b 1df3 31f3 320a 33f3 852d 3301 340a 
1316120 3503 3604 3709 38f3 5006 5109 521e 534f 
1316140 54f0 55f0 563d 571c 5815 5911 5a22 5b5c 
1316160 5c7b 5d18 5e08 a42d 1f03 2010 2122 22f3 
1316200 23ad 2488 2511 26f3 5f02 600d 611c 6287 
1316220 63b4 642c 651b 6613 6718 680f 6909 6a07 
1316240 7b05 7c22 7d2f 7e18 7f2c a32d 002f 0109 
1316260 0203 a22d 7e05 7f09 c1c1 0000 e063 0ffc 
 
</pre>
<!-- Author: Jason -->
<!-- Comment: Mon Apr 28 21;22;00 comment by...Gino -->
looking at the data posted by Jason I see something very weird that is now underlined in bold:
</p>1315600 c1c1 0000 e061 0ffc 852d 0007 1717 02c3 
</p>1315620 02c1 02c0 02f3 660f 0f04 0520 fd85 2630 
</p>1315640 3e36 7b25 3657 6d0e 04ef 29f3 0a25 0508 
</p>1315660 0d01 010c 2e1e 1906 0df1 291d 1c1f 0701 
</p>1315700 1463 877b 1b08 040d 65d9 87f9 3b11 0826 
</p>1315720 2d08 060c 21f3 b319 f8c9 6209 0503 3236 
</p>1315740 1107 070b 1203 <b>cb0c</b> e062 0ffc 892d 00f3 
</p>1315760 2508 2618 2794 2878 2926 2a10 2b02 6b08 
</p>1316000 6c19 6d80 6e90 6f1c 700e 7112 7214 7312 
</p>1316020 740c 7509 7603 882d 08f3 0913 0a13 0b26 
</p>1316040 0c1b 0d37 0e1b 0f07 79f3 7a09 7b01 872d 
</p>1316060 0df3 0e0b 0ff3 862d 0f04 1009 11f3 1b01 
</p>1316100 1c0b 1df3 31f3 320a 33f3 852d 3301 340a 
</p>1316120 3503 3604 3709 38f3 5006 5109 521e 534f 
</p>1316140 54f0 55f0 563d 571c 5815 5911 5a22 5b5c 
</p>1316160 5c7b 5d18 5e08 a42d 1f03 2010 2122 22f3 
</p>1316200 23ad 2488 2511 26f3 5f02 600d 611c 6287 
</p>1316220 63b4 642c 651b 6613 6718 680f 6909 6a07 
</p>1316240 7b05 7c22 7d2f 7e18 7f2c a32d 002f 0109 
</p>1316260 0203 a22d 7e05 7f09 c1c1 0000 e063 0ffc 

</p>
What kind of termination carachter is that?
</p>
I cannot figure that out but this might help us out (with the knowledge of Steve) understanding if the problem in in the ladder on more upstream toward the DAQ.
</p> It cannot be the VRB otherwise SVT would NOT be inefficient. 

<!-- Comment: Mon Apr 28 21;46;12 comment by...Gino -->
I guess that if the ladder spit out <b>cboc</b> the FIB let it through and the VRB chop there because bigger than c000.
Here is what I think we should do:
<li> check the ladder with svxdaq
<li> power cycle the ladder and check it again with svxdaq
<li> if the symptoms are reproducible go in a access swap the fiber with the L2 that is good.
<li> proceed with an RX swap if the fiber swap fixed the problem.

<!-- Comment: Tue Apr 29 06;56;54 comment by...SCN -->
You are correct about the odd EOR and resulting FIB and VRB behaviour (before you complain, consider what would happen to our
data size if the VRB did NOT chop after the Fib EOR- all 10 ladders would have the same byte count as the longest one in the FIB/VRB...).  The plan sounds reasonable.

<!-- Comment: Tue Apr 29 08;02;01 comment by...Jason -->
<pre>This ladder is still bad, even for the read-all calibration data:

2315020 7b3f 7c42 7d3e 7e3e 7f3f c1c1 0000 e061
2315040 76fc 8510 2e33 2437 0100 0600 0102 0301
2315060 0000 0002 0302 0002 0202 0304 0005 0301
2315100 0400 0304 0200 0300 0600 0204 0204 0300
2315120 0600 0200 0106 0604 0200 0602 0002 0003
2315140 0100 0200 0300 0204 0000 0000 0000 0001
2315160 00c2 c2c4 0000 e062 76fc 8910 0037 013d

We will power cycle when we get a chance, probably end of store.</pre>
<!-- Comment: Tue Apr 29 13;10;44 comment by...Gino -->
<pre>Low luminosity (very low) so I power cycled the whole wedge without much impact on the errors. At this point it needs an access.
</pre>
<!-- Comment: Tue Apr 29 14;55;05 comment by...Gino -->
<pre>Problem is reproducible with svxdaq

DataBlock 12
0030d40b a08a28a0 a28a28a0 0000000a 00000000 00000000 00000000 00000000 e06135fc 85d0d0c2 c2c40000 00000000 

Very likely an OBDV trouble very likely an RX swap can do the job.

Waiting for an access.
</pre>
<!-- Comment: Thu May  1 22;04;56 comment by...Gino -->
<pre>For the record:
The RX was swapped and the problems was not solved.
Then the FIB was swapped and the problem went away.
Another DAQ problem costing an SVT wedge was fixed.
</pre>
<!-- Date: Tue Apr 29 07:49:11 2003 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 258
Calibration type  : nonstandard
Run period tag    : Apr_2003
DPS-off run       : 162250
DPS-on run        : 162247
Requested by      : Thorsten
Main process id   : 15723913
Comment           : used for run 162247 the farmes 1,4,6,8
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Tue Apr 29 07:50:40 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W9L1 
<li>problem n: 1020 
<li>Status: needs_observation
<li>Type: No_Init
<li>Action: Init_RB_mask
<li>entered by: nahn 
<li>description is: <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=355&frame=2&anchor=07:26:25.958'> Failed COLDSTART repeatedly</a>   during DMODE calibration coldstart, IMON is not complaining, so readback masked.  Of course, once masked it read back correctly (sigh). 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W9&layer=L1">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Tue Apr 29 07;58;38 comment by...Jason -->
Calibration data (run 162250) seem OK for this ladder.
<!-- Date: Tue Apr 29 07:56:37 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W6L1 
<li>problem n: 1021 
<li>Status: needs_study_time
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: nielsenj 
<li>description is: garbled readout since 162238-- chip ids are intact, but that's about it 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W6&layer=L1">report</a></ul>
<!-- Author: Problem DB -->





<!-- Date: Tue Apr 29 14:06:47 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 258 finished successfully.

Job info
--------
Calibration type : nonstandard
DPS-off run      : 162250
DPS-on run       : 162247
Requested by     : Thorsten
Submitted        : 2003-04-29 05:46:32
Completed        : 2003-04-29 12:04:22
Status           : SUCCESS
Comment          : used for run 162247 the farmes 1,4,6,8
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->




<!-- Date: Tue Apr 29 14:55:35 2003 -->
<h3>Abort</h3> on BQ9 this time...all Fibs cold start ok.
<!-- Author: SCN -->


<!-- Date: Tue Apr 29 16:09:35 2003 -->
<pre>Ken and I looked at the fuse problem using the DAQ3 WIB, here are the results of the study: 
 
1)we reproduced the result I saw with Gino yesterday: 5.34 A 
   
2) a second FTM board shows exactly the same 5.34 A 
 
3) it doesn't matter if I'm running the daq or not, or if I'm 
   disconnecting channels (explains why we blow fuses with and without beam) 
 
4) we removed one RX after the other. The current drops ~280mA per RX, on average. We noticed quite some variation between individual RX's, between 340mA and 200mA. Vince tells us that the max. current draw per RX can be 400mA 
 
5) 10 RX's account for ~3 A, the 2 control cables for another 0.25 A 
 
6) the one thing we didn't do is unbuff the FTM to see if that makes a difference (it shouldn't, and it doesn't matter because this is how we want to use it) 
 
7) a 7A fuse would cover the range plus 20% (unless you happen to have 10 400mA RX's). 
 
</pre>
<!-- Author: Julia, Ken -->

<!-- Date: Tue Apr 29 17:39:34 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W6L1 
<li>problem n: 1021 
<li>Status: fixed
<li>Type: RX
<li>Action: Swap_RX
<li>entered by: nielsenj 
<li>description is: RX swap.  No problems in post test. <table border=1> <tr><td><b>IN:</b></td><td><a href='http://nkek15.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0902'>0902</a></td></tr> <tr><td><b>OUT:</b></td><td><a href='http://nkek15.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0679'>0679</a></td></tr> </table> <table border=1>
<tr><td><b>IN:</b></td><td><a href="http://nkek15.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0902">0902</a></td></tr>
<tr><td><b>OUT:</b></td><td><a href="http://nkek15.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0679">0679</a></td></tr></table> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W6&layer=L1">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Tue Apr 29 17;46;40 comment by...Jason -->
Cool, I did not know that the ProblemDB would make the table for me, so I made my own...  Sorry for the duplicate.
<!-- Date: Tue Apr 29 17:43:11 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W6/7All 
<li>problem n: 1022 
<li>Status: fixed
<li>Type: DropReadOut_nonRX
<li>Action: Swap_FIB
<li>entered by: nielsenj 
<li>description is: FIB swap.  Post-test is OK.<table border=1>
<tr><td><b>IN</b></td><td>PREP:</td><td>550965</td><td>Serial:</td><td>??</td></tr>
<tr><td><b>OUT</b></td><td>PREP:</td><td>550954</td><td>Serial:</td><td>153</td></tr></table> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W6/7&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Apr 29 17:45:48 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W6L2 
<li>problem n: 1023 
<li>Status: fixed
<li>Type: RX
<li>Action: Swap_RX
<li>entered by: nielsenj 
<li>description is: Swap RX <table border=1>
<tr><td><b>IN:</b></td><td><a href="http://nkek15.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0679">0679</a></td></tr>
<tr><td><b>OUT:</b></td><td><a href="http://nkek15.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0527">0527</a></td></tr></table> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W6&layer=L2">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Tue Apr 29 17:52:36 2003 -->
<H2>Victorious Access</H2> 
Our goal was to fix e061, which was giving garbled data. 
<P> 
We first tried to swap the RX, but the problem persisted.<BR> 
Then we swapped the FIB.<BR> 
After that, everything worked. 
<P> 
We also took advantage of our work on b0fib02 and <B>changed all of the FTM fuses in this crate</B>.
<!-- Author: Gino, Jason, Julia -->

<!-- Date: Tue Apr 29 21:48:19 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W2/3All 
<li>problem n: 986 
<li>Status: fixed
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: no errors--buffed ftm sucessful. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W2/3&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Apr 29 21:56:37 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W2/3All 
<li>problem n: 984 
<li>Status: fixed
<li>Type: Other
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: cleaned up SB5W3 no first chip problems--buffed ftm successful! 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B5W2/3&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Apr 29 22:07:48 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W10/11All 
<li>problem n: 985 
<li>Status: fixed
<li>Type: Other
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: buffed ftm did not cause any new errors, however it did not help with bit 5,7 high at ~1% rates in e4a2 (same problem in e4a3 unfixable) or ~1% no z side readout for e4a4.  buffed ftm is considered sucessful because no new problems were introduced.   
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B4W10/11&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Apr 29 22:16:06 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W8/9All 
<li>problem n: 886 
<li>Status: fixed
<li>Type: Other
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: no new problems--fixed 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W8/9&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Apr 29 22:21:31 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W6/7All 
<li>problem n: 982 
<li>Status: fixed
<li>Type: Other
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: now bit errors ~.1% occassionally.  buffed ftm cleared up the errors, considered fixed.  
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W6/7&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Apr 29 22:23:36 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W4/5All 
<li>problem n: 994 
<li>Status: fixed
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: buffed ftm, no new problems--fixed. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B4W4/5&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Apr 30 04:15:09 2003 -->
<center><a href='/elog/notebooks/silicon/Wed_Apr_30_2003_040354.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1915' ></a></center>
<!-- Author: Jason -->
<!-- Comment: Wed Apr 30 04;16;37 comment by...Jason -->
SVT map for store 2495. <BR>I have called Marco (carrying SVT pager) who will look at wedge 0.  I do not think it can be a silicon hardware problem because it extends across all barrels.


<!-- Comment: Wed Apr 30 07;04;59 comment by...SCN -->
I believe (and hope beyond all hopes) that you are correct...
<!-- Date: Wed Apr 30 04:39:59 2003 -->
It would be nice to have the cell ID status maps in SVXMon be all green...<P> 
Two red cells in SVXMon cell ID status map: 
<UL> 
<LI>e043 gives chip errors: known bit problem?</LI> 
<LI>f551 gives channel and ADC value errors: not the "unfixable" chips in the problem DB</LI> 
</UL> 
Others seem OK; maybe monitor these guys.  
<!-- Author: Jason -->


<!-- Date: Wed Apr 30 05:23:30 2003 -->
<center><a href='/elog/notebooks/silicon/Wed_Apr_30_2003_052229.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1917' ></a><a href='/elog/notebooks/silicon/Wed_Apr_30_2003_052304.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1919' ></a></center>
<!-- Author: Jason -->
<!-- Comment: Wed Apr 30 05;38;12 comment by...Jason -->
While I'm waiting for SVT to show up, there was a pinkie on e032 DVDD.  The nominal current in iMon was 260 mA, and I have just changed it to 265 mA.<P>
The plots above show the DVDD (left) and AVDD (right) currents for e032 during this store.  I do not know what the status/conclusion of the
 <A HREF="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W3&layer=L2">
AVDD2 investigation</A>
was for this ladder...



<!-- Date: Wed Apr 30 08:42:36 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1920&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1921  width='300' align='top'></td><td>Current SVT spy mon efficiency after Marco swapped the AM board.</a></td></tr></table>
<!-- Author: Jason -->


<!-- Date: Wed Apr 30 08:56:18 2003 -->
At the beginning of store 2495 last night, the electron lens tripped off a couple of times, causing TevMon to alarm. 
Apparently the shift crew "knew" that they can sometimes keep running if the electron lens current is unstable for a short period of time.  This seems to be undermining our simple strategy for TevMon. 
<P> 
The ACNET plots of the electron lens current and abort gap losses are in  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=359&frame=2&anchor=08:51:11.013'> 
this CDF shift e-log entry</a>.  The fluctuations in the current are due to the efforts of the Tevatron experts.
<!-- Author: Jason -->
<!-- Comment: Wed Apr 30 09;36;30 comment by...SCN -->
<pre>This has been an ongoing problem.  We should get an understanding 
from the BD about the status of the TEL at the beginning of the store, and tweak TevMon appropriately (i.e. a 20 minute grace period after scraping for the TEL, if it will always trip off
at the beginning of the store.)  It is not good for the Aces to
ignore Tevmon.</pre>


<!-- Date: Wed Apr 30 12:37:46 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1922&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1922  width='300' align='top'></td><td>Abort Gap Losses and the TEL over the last 5 stores</a></td></tr></table>
<!-- Author: SCN -->


<!-- Date: Thu May 1 04:42:31 2003 -->
Store 2496 is too lossy to turn on any subdetectors, let alone silicon.<BR> 
The LOSTP and LOSTPB scalars are both pegged to 100kHz.<BR> 
The uncapped B0ALOS is at 75kHz and B0PLOS is at 1250kHz, according to ACNET.<BR> 
MCR is aware that most of the beam is being lost...  
<!-- Author: Jason -->


<!-- Date: Thu May 1 05:14:02 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1923&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1923  width='300' align='top'></td><td>Radiation dose for the last half-hour</a></td></tr></table>
<!-- Author: Jason -->
<!-- Comment: Thu May  1 05;14;48 comment by...Jason -->
If I understand the radmon limits correctly, this is close to the automated alarm limit of 1 rad/min.  (But I wouldn't mind being enlightened.)



<!-- Comment: Thu May  1 16;37;04 comment by...Jason -->
Andy told me that the alarm limit is actually 18 rad/min.
<BR>
Gino and I looked at past runs in ACNET, and we believe rates of order 0.5 rad/min are common and are no cause for alarm.

<!-- Date: Thu May 1 15:20:30 2003 -->
In order to allow Andy, Andrew, and Yimei continue while Jason 
and Gino are in access for b0fib03, I did the following to CAEN.map <ol> 
<li> Turned off commands to crates 7 and 8 (top line:  11111111111111110  becomes 11111100111111110) 
<li> Mapped IB0W1 from crate 2 Sl 6 to crate 17 Slot 6 effectively making it not receive commands 
</ol> 
These should be undone when the guys in access are ready to turn 
things back on in the crate.
<!-- Author: SCN -->


<!-- Date: Thu May 1 16:27:49 2003 -->
<pre>Went in an access. 
Worked in b0fib03. 
1. swapped the FFO IN 550305 OUT 550319 
2. replaced 5A fuses with 7A fuses on every FTM but IB2W2/3 
   (does NOT work anyway and it would be nice to see this fuse  
   blowing with time) 
3. in the process we broke the fibers for the optical RX for  
   LB0W0L0. The RX was replaced succesfully. 
More will follow from Steve about the troubles with the FFO</pre>
<!-- Author: Gino -->

<!-- Date: Thu May 1 16:29:49 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W0L0 
<li>problem n: 1024 
<li>Status: fixed
<li>Type: RX
<li>Action: Swap_RX
<li>entered by: nielsenj 
<li>description is: Swapped RX which had fiber cut.<table border=1>
<tr><td><b>IN:</b></td><td><a href="http://nkek15.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0258">0258</a></td></tr>
<tr><td><b>OUT:</b></td><td><a href="http://nkek15.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0322">0322</a></td></tr></table> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=L00&wedge=B0W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Thu May 1 18:06:42 2003 -->
<h1>The Need for Speed</h1> 
<p> 
We modified the GUI and PSMon (the iFix interface to the GUI) 
to operate on all 3 detectors more-or-less simultaneously when 
aces click the global buttons on iFix (and when experts click the "POWER" buttons on the GUI).  The time from "ON button clicked" to "trigger inhibits cleared" is now about 3.5 minutes (when we were "staging" the global transition it took about 6.5 minutes, I believe).</p> 
<p> 
The 3.5 minutes breaks down approximately as follows: 
<ol> 
  <li>Sending and digesting the iFix command: <b>0.5 min</b> 
  <li>Actually sending the commands to the CAENs: <b>2 min</b> 
  <li>Waiting for ISL to finish ramping (the commands are still 
sent to the CAENs in a serial fashion; ISL is the last in the sequence): <b>1 min</b> 
</ol> 
Yimei is thinking about ways to improve #2. 
</p>
<!-- Author: Andy H., Yimei H., Andrew I. -->
<!-- Comment: Thu May  1 21;50;45 comment by...Andrew -->
<pre>In the next few hours we optimized step #2 and reduced it to 
almost 1 min. The new fast function works only for STBY-&gt;ON
transitions. It loops over all channels and changes bias voltage
settings. It is optimized for a case, when all channels were at 
STBY. That is a normal operation. In case if too many ladders 
were OFF, and we want to go to ON, it might be slower, than the
standard powering up procedure.
Also it allows to recover from trips automatically by clicking ON
button on the iFix, which is almost as fast as finding the 
tripped ladder on the GUI and turning it ON.   
The time from "ON button clicked" to "trigger inhibits cleared"
is about 2.5 min.
The ON-&gt;STBY transition remains to be 3.5 min. As well as the 
transitions from the GUI. 
For the moment we put 3.5 min version into the place, before 
we sort out some issues with ladders being OFF.</pre>
<!-- Comment: Thu May  1 22;19;47 comment by...Gino -->
<pre>This is great! 
I think at this point the potential major source of systematic 
downtime due to the silicon is the D-MODE calibrations 
(30 minutes a week is well comparable with few minutes 
per store). 
The effort to get the X-MODE calibration working should be 
resuscitated, finished and the product released to the CDF crew.</pre>
<!-- Date: Thu May 1 20:11:08 2003 -->
The FFO-SRC status cables are all still unplugged from the SRC.  Steve says this is OK.<BR> 
We will run like this tonight and see what happens...
<!-- Author: Jason -->
<!-- Comment: Thu May  1 22;13;45 comment by...Gino -->
we have been running like this untill<a href='http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=152&frame=2&anchor=13:54:44'> 3 days ago </a> so it should not be a problem now.
Still the problem has been there since <a href='http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=54&frame=2&anchor=20:15:28'>
July 22nd 2001 </a> and we did NOT yet tried to fix it up.
It is now necessary to fix the problem because of the safety of the silicon (handbrake against resonances). It canot stay under the rug any more.






<!-- Comment: Fri May  2 06;36;28 comment by...SCN -->
Gino is correct, almost.  As of yesterday afternoon due to some
work by Lester we now know <B>WHY</B> things failed on July 22nd, 2001.  The diagnostic crate was used to investigate some more after the access. The full story is that there are some registers in the SRC that have never ever been configured quite right (not in svxdaq, not in rc) plus some errors in the FFO are mapped to error bit 0 (the "Glink Error Bit") which should not be, and this prevents the SRC from coldstarting under certain circumstances.<P>
 However, given the choice between hastily writing some code to test these theories on the real Silicon during a store, or removing the cables and waiting until between store study time to plug them back in and test (as well as checking code for the handbrake), I chose to remove the cables for the interim.  I do not think it is anyone's intention to sweep anything under the metaphorical rug.
<!-- Date: Fri May 2 00:20:34 2003 -->
<table><tr><td><a href=/elog/notebooks/silicon/Fri_May__2_2003_002025.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1925  align='top'></td><td>SVT spy mon for store 2502</a></td></tr></table>
<!-- Author: Jason -->


<!-- Date: Fri May 2 00:33:47 2003 -->
CDF has extremely high deadtime -- trying to figure it out.<BR> 
Silicon seems OK.  Only SVXMon error is no data from IB5W5L1.
<!-- Author: Jason -->
<!-- Comment: Fri May  2 09;17;28 comment by...Jason -->
Deadtime was due to hot calorimeter trigger tower.


<!-- Date: Fri May 2 10:32:18 2003 -->
<pre>Came to the Control Room and as soon as I touched the mouse  
on bodap42 the machine went black and ask me to log into it. 
Logged in and restarted CAEN GUI and IMON without any trouble. 
I just hope I picked up the right CAEN GUI after the mods of  
yesterday.</pre>
<!-- Author: Gino -->


<!-- Date: Fri May 2 16:24:04 2003 -->
<h3> Trying to get back our <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=113&frame=2&anchor=17:25:22'> 
2 microsecs of VRB busy time</a></h3> which we 
rescinded because of   <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=113&frame=2&anchor=00:54:06'>resultant data corruption</a> I applied the new VRB firmware <i>vrb3502P.hex</i> 
to the VRB 550280 in the diagnostic crate and "ran it" (Auto L2R after readout, minimal digitize time) with various # Readout Clocks from the Fib, both before and after the firmware change.  Results are: 
<table> 
<tr> <th> # RO CLKs <th> RB time before (uS) <th> RB time after (uS) </tr> 
<tr> <td> 50 <td> 6.825  <td> 4.720 </tr> 
<tr> <td> 100 <td> 7.815 <td> 5.710 </tr> 
<tr> <td> 200 <td> 9.706 <td> 7.712 </tr> 
<tr> <td> 500 <td> 15.84 <td> 13.70 </tr> 
<tr> <td> 1000 <td> 25.81 <td> 23.72 </tr> 
<tr> <td> 2000 <td> 45.78 <td> 43.73 </tr> 
<tr> <td> 4000 <td> 85.81 <td> 83.60 </tr> 
</table> 
Looking at it, you can see the result, but anyway if you 
take time to fit it (left as an excercise to the reader) you get<BR> 
<B>Before</B> RB time = 0.020002 * BECLKs + 5.7938<BR> 
<B>After </B> RB time = 0.019975 * BECLKs + 3.7260<BR> 
which is to say that by dropping RB early, you can save 
about 2.1 uS (and the slope doesn't change)<P> 
However, I haven't tried to use it to read out any data yet, that is next (maybe over at FCC...)  There is hope that the way the VRB is doing things will be an improvement over previous 
attempts since it won't try to process a L1A while already proccessing a L1A.  We shall see... 
 
 
 
  
<!-- Author: SCN -->
<!-- Comment: Fri May  2 17;15;38 comment by...SCN -->
<pre>Test at FCC shows no problems with this firmware in the VRB.  Running 4 of the 5 channels available (Pipe 3 has some trouble with DPS on), DPS ON, Thre = 3, (one chip DPS OFF).  This tests
for Channel byte count corruption but not TSL1A Corruption since
you need two VRBs for that.  Not sure it is worth setting up two
Vrbs at FCC rather than applying it to Vrbs during study time at B0 and testing for trouble immediately.  
 </pre>
<!-- Date: Fri May 2 16:39:41 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1926&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1926  width='300' align='top'></td><td>Sad faces in SVX</a></td></tr></table>
<!-- Author: Gino -->
<!-- Comment: Fri May  2 17;01;37 comment by...Gino -->
<pre>SB0W4L3 has a bit 7 problem on the Z side that has been there 
        since the beginning of time. 
SB5W6L4 has some bits problems.</pre>



<!-- Date: Sat May 3 00:41:40 2003 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sat_May__3_2003_004133.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1928  align='top'></td><td>SVT spy mon for new store 2503</a></td></tr></table>
<!-- Author: Jason -->

<!-- Date: Sat May 3 00:55:54 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W4L2 
<li>problem n: 1025 
<li>Status: needs_work
<li>Type: DropReadOut_nonRX
<li>Action: Monitoring
<li>entered by: nielsenj 
<li>description is: DRO before first chip id -- when did it start? 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W4&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat May 3 01:04:12 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W7L1 
<li>problem n: 932 
<li>Status: needs_observation
<li>Type: Optical_other
<li>Action: Monitoring
<li>entered by: nielsenj 
<li>description is: Bit 1 low causes last channel 7f to be missing, and consequent c2 termination. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W7&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat May 3 08:38:47 2003 -->
<H2>Weird PS/iFIX incident</H2> 
At 7:44 (downtime logger time) DAQ stopped beacause of a 
 trigger inhibit set by SVX and ISL. 
<BR> iFix GLOBAL ALARM panel was 
 fine, both SVX and ISL were green.  
<BR>iFix High Voltage Summary  
was green but two columns were missing (both SVX and ISL showed 
 minimums of 0). 
<BR> Silicon power supply showed the following wedges off: 
<UL> 
<LI>SVX B3 W2,3</LI> 
<LI>SVX B4 W1,2,3</LI> 
<LI>SVX B5 W2,3</LI> 
<LI>ISL B5 W0</LI> 
</UL> 
But there were no trip messages in the PS GUI. 
<BR> 
The wedges were turned on at 8:02 with the PS GUI. 
<P> 
When I look at the IMON currents, I do NOT see 
any of them actually OFF (see plots next entry). 
So I do not understand why iFix claimed they were off.  
<!-- Author: Jason Nielsen and Alberto Belloni -->


<!-- Date: Sat May 3 08:42:21 2003 -->
<center><a href='/elog/notebooks/silicon/Sat_May__3_2003_084058.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1930' ></a></center>
<!-- Author: Jason -->
<!-- Comment: Sat May  3 08;44;13 comment by...Jason -->
Bias current for SB3W2L0 around the time of the incident.
<BR>
The dip at 8:02 is the point when we clicked ON in the PS GUI.
<BR>
Apparently this ladder was never really OFF before that...
<!-- Date: Sat May 3 08:42:39 2003 -->
<center><a href='/elog/notebooks/silicon/Sat_May__3_2003_084138.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1932' ></a></center>
<!-- Author: Jason -->
<!-- Comment: Sat May  3 08;44;54 comment by...Jason -->
AVDD current for SB5W2L0 around the time of the incident

<!-- Comment: Sat May  3 11;38;05 comment by...Jason -->
Should be SB3W2.


<!-- Date: Sat May 3 11:41:38 2003 -->
<H3>More investigation into this morning's "trip"</H3> 
<UL> 
<LI>No trigger inhibit was recorded in the run summary page</LI> 
<LI>No iFix alarms</LI> 
<LI>Yet 8 wedges were RED in the ps GUI...</LI> 
</UL> 
All of these wedges are in the same crate NE Top Bot (#10), but the ninth wedge in that crate, SB3W0 was not red. 
 
A look at the current history for SB3W2 this morning: 
<PRE> 
902 SVX B3W2 layer 4 VBIAS  voltage = 0.000000 
 
 07:36:18 902 	 45.00  
 07:36:27 902 	 44.90  
 07:39:17 902 	 0.00  
 07:58:26 902 	 7.50  
 07:58:37 902 	 29.10  
 07:58:50 902 	 44.70  
 07:59:02 902 	 44.90  
</PRE> 
 
But wait, didn't we turn things back on at 8:03 according to the DAQ logs?  Well, b0dap43 (which logs the power supply currents) is running about 3.5 minutes behind the other computers in the online cluster.  (I just sent mail to Serguei and Jeff to fix it.) 
<P> 
And SB3W0 probably should have been red as well: 
<PRE> 
866 SVX B3W0 layer 4 VBIAS  voltage = 0.000000 
 
 00:00:10 866 	 1.60  
 00:32:42 866 	 49.90  
 07:39:17 866 	 0.00  
 07:58:50 866 	 49.80  
 07:59:02 866 	 49.90  
</PRE> 
 
So why didn't IMON update and see the current off for these wedges?  
<!-- Author: Jason -->
<!-- Comment: Sun May  4 21;43;23 comment by...Andy H. -->
I'm not offering any explanations here, just some context/history.  Every now and then the CAEN crates arbitrarily
power down all the supplies in the crate (that's why no iFix alarms -- the supplies don't show up as "tripped," just "off").  This was an every-six-months-or-so phenomenon; now it has happened twice within the last month.
<!-- Date: Sat May 3 16:03:28 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W1L1 
<li>problem n: 992 
<li>Status: needs_work
<li>Type: Unknown
<li>Action: Diagnosis_update
<li>entered by: lmiller 
<li>description is: <pre>We looked at the light output of this ladder. There is no light 
at the level of few microwatts coming out wether it is powered
or not.

I tried looking at the light out of another ladder, though
while running it with power off. It also showed no light. 

It is interesting that when you init a ladder which has power
off you readback ff's but for IB1W1L1 the readback is again 00's

This still points suspicion to the DDR. But no real conclusions.</pre> 
<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: Sat May 3 23:02:10 2003 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sat_May__3_2003_230204.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1934  align='top'></td><td>SVT spy mon for store 2505</a></td></tr></table>
<!-- Author: Jason -->
<!-- Comment: Sat May  3 23;10;50 comment by...Jason -->
There was one pipeline out-of-synch error or 145 readout chips early in this run.
<BR>An automatic HRR was issued.

<!-- Date: Sat May 3 23:31:06 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W6L4 
<li>problem n: 345 
<li>Status: needs_observation
<li>Type: RX
<li>Action: Monitoring
<li>entered by: nielsenj 
<li>description is: In run 162453, no data from last phi chip and entire z side.   
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B5W6&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sun May 4 06:45:59 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1935&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1935  width='300' align='top'></td><td>A new Hole in SVT: SB2W0</a></td></tr></table>
<!-- Author: Gino -->
<!-- Comment: Sun May  4 07;45;54 comment by...Gino -->
<pre>This is due to bit 7 HIGH on SB2W0L0.
Here is the hex dump of the raw data file:

 c1c1 e200 0cfd 83a7
809b 8186 a587 a68f a780 bc86 bd8d be85
82a7 daf1 dbef dcf0 fcf0 fdef feef ffe2
a1a7 8080 a0a7 fff1 c2c2 
</pre>

<!-- Comment: Sun May  4 08;00;55 comment by...Gino -->
<pre>This is fixable (very likely) with an RX swap. A 1 hour access.
</pre>

<!-- Comment: Sun May  4 08;34;12 comment by...Gino -->
<pre>CDF was having its own trouble so I took advantage of the down time to power cycle SB2W0. Let's see what comes out of it. I do not expect much.</pre>

<!-- Comment: Sun May  4 08;39;39 comment by...Gino -->
<pre>Did NOT help at all. Access seems to be necessary!</pre>

<!-- Date: Sun May 4 08:58:21 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W7L2 
<li>problem n: 1026 
<li>Status: needs_maintenance
<li>Type: Unknown
<li>Action: Incident
<li>entered by: bolla 
<li>description is: This ladder is OUT for NOT good reason.  Should be re-integrated between this store and the next one. It was NOT put back in the hdwdb after swapping the <a href='http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=150&frame=2&anchor=19:51:00'>fuse in the FTM </a>   
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W7&layer=L2">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Sun May  4 14;32;57 comment by...SCN -->
Actually, if you take the time to read the link, you'll see that Reid and David noted it was not in the hdwdb <I>before the fuse incident</i> so needs some more digging I guess.  At least they
meant well and were not as careless as the above entry implies.


<!-- Date: Sun May 4 17:57:08 2003 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sun_May__4_2003_175657.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1937  align='top'></td><td>SVT spy mon plot for store 2507.</a></td></tr></table>
<!-- Author: Jason -->
<!-- Comment: Sun May  4 17;58;42 comment by...Jason -->
<BR>The wedge which was bad this morning now seems fine.