<!-- Title: 10:25:00  Mon May  2 2005 -->
<!-- Crewchief: Sebastian -->
<!-- Op1: Tuula -->
<!-- Op2: Rong -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>take data</pre>


<!-- Date: Mon May 2 12:27:54 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6557&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6557  width='300' align='top'></a></td><td>Lost a RF station (3). MCR says everything is stable and we can put the silicon back in. TeVMon is green and the Si is included again.</td></tr></table>
<!-- Author: Sebastian -->
<!-- Comment: Mon May  2 12;42;09 comment by...sebastian -->
More datails in <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=365&frame=2&anchor=12:08:48.889'>shift elog</a>.

<!-- Comment: Mon May  2 13;39;49 comment by...sebastian -->
<pre>TeVMon gave the alarm accoring to RFSUM:
Event = 116981 Time:  02-May-2005 12:05:49
button = RMS (T:RFSUM) STATUS = 2  CONDITION = 1 
button = RMS (T:RFSUMA) STATUS = 2  CONDITION = 1 
</pre>


<!-- Date: Mon May 2 14:02:53 2005 -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2005&action=view&page=-7515&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2005&action=view&page=-7515 width='300' align='top'></a></td><td>BLM plot of Tevatron quench.</td></tr></table>  
<!-- Author: Rong -->
<!-- Comment: Mon May  2 14;03;14 comment by...Rong -->
<pre>Tev Quench F4 F48 U&L. </pre>

<!-- Date: Mon May 2 15:24:14 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W4L0 
<li>problem n: 135 
<li>Status: needs_quiet_time
<li>Type: DRO_00F3
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>I noticed all the ISEL bits were set to zero in SVXDaq. I set the ISEL bits to 01 001 00 0101 (the usual setting).  Then ran this ladder in RA and NN mode.  No errors seen.</p>  <p>So why do you get errors during data taking ?  Need to see if there any differences in the chip setting between SVXDaq and the hardware database.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W4&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon May 2 15:40:47 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W3L4 
<li>problem n: 237 
<li>Status: unfixable
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: tmaki 
<li>description is: We tryed changing R Driver values from 5 to 7 for chips 14 and 15. But still got cap id problems. Then we set the all chips for this ladder to 7, but it didn't help. Cannot fix this problem. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W3&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon May 2 15:50:08 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W3L2 
<li>problem n: 1136 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: Run this guy during quiet time, no error found neither in READALL nor NN mode after 5000 events, also tried biasing it, no avail. Interesting 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W3&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon May 2 16:13:58 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W8L2 
<li>problem n: 1469 
<li>Status: needs_access_2hr
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: tmaki 
<li>description is: Running this ladder during quiet time, error is reproducible. Swapped Fibers on the VRB, problem stayed with the fiber. So next thing is to work on the fib rack. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W8&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon May 2 16:24:18 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W1L2 
<li>problem n: 790 
<li>Status: needs_observation
<li>Type: pinhole
<li>Action: Added_hdwdb
<li>entered by: sebastian 
<li>description is: Unchopped the chips after bias splitting change. Should check with SVXMon (c2c2 and occupancy) when taking data. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon May 2 16:38:47 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W4L0 
<li>problem n: 974 
<li>Status: unfixable
<li>Type: Other
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>The threshold for this ladder is already at 15.  Can't do anything more.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W4&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon May 2 16:40:24 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W10L1 
<li>problem n: 1468 
<li>Status: needs_access_2hr
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: We ran this guy in nearest Neighbour mode and we got the errors. We swapped Fibers on the VRB, problem stayed with the fiber, not the VRB channel. Next thing is to play with the FIB 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W10&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon May 2 17:55:05 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W2L0 
<li>problem n: 1380 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Chip_bit_changes
<li>entered by: sebastian 
<li>description is: <p>The threshold for the chips on the Z side were increased.  Check the readout time to see if it reduced. </p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W2&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon May 2 19:19:48 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6558&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6559  width='300' align='top'></a></td><td>Bias current for e144...</td></tr></table>
<!-- Author: Marcel -->
<!-- Comment: Mon May  2 19;24;26 comment by...Marcel -->
<h3> Trying to revive e144 </h3>
We went through the list of MIA ladders. So we tried e144, which had a history of bias trips. We turned it on and it worked nicely, it still does draw quite a lot of bias current (2 mA) but does not trip anymore on 5 mA. We ran the ladder for quite some time without seeing any problems. So we give this a shot with beam. In case of tripping, we can take it out of the Hardware Database rather quickly. Sebastian is aware of the problem and will take it out immediately.

<!-- Comment: Mon May  2 19;25;01 comment by...Marcel -->
that should read Ankush & Marcel
<!-- Date: Mon May 2 19:22:58 2005 -->
<h4> Recovered Ladders </h4> 
 
<p> 
Two ladders were brought back into the Hardware data base. 
 
<ul> 
<li>SB1W4L4 (e144) </li> 
<li>IB1W1L2 (f112) </li> 
</ul> 
</p> 
 
<!-- Author: Ankush/Marcel/Sebastian -->



<!-- Date: Mon May 2 19:30:28 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W4L4 
<li>problem n: 709 
<li>Status: needs_work
<li>Type: BIAS
<li>Action: Added_hdwdb
<li>entered by: amitra 
<li>description is: <p>This ladder was put into the hardware database. It held bias without tripping and ran fine in SVXDaq.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W4&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon May 2 19:30:28 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W4L4 
<li>problem n: 709 
<li>Status: needs_work
<li>Type: BIAS
<li>Action: Added_hdwdb
<li>entered by: amitra 
<li>description is: <p>This ladder was put into the hardware database. It held bias without tripping and ran fine in SVXDaq.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W4&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue May 3 00:26:15 2005 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 404
Calibration type  : standard
Run period tag    : May_2005
DPS-off run       : 197291
DPS-on run        : 197290
Requested by      : sourabh
Main process id   : 9712
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->



<!-- Date: Tue May 3 04:56:12 2005 -->
Got paged because they are loading pbars. Talked to JP (monitoring ace). He will put the beam condition plot on the elog when scraping 
is done and i'll call in and give the ok to include Si.
<!-- Author: Sebastian -->


<!-- Date: Tue May 3 05:36:17 2005 -->
<p><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=367&frame=2&anchor=05:33:35.125'> 
Beam conditions</a> look fine, TeVMon green, we are taking data with Silicon.</p>
<!-- Author: Sebastian -->


<!-- Date: Tue May 3 05:41:45 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6561&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6562  width='300' align='top'></a></td><td>SVT for store <b>4125</b>.</td></tr></table>
<!-- Author: Sebastian -->
<!-- Comment: Tue May  3 05;42;47 comment by...sebastian -->
<pre>Initial luminosity was 75E30.</pre>


<!-- Date: Tue May 3 06:53:15 2005 -->
<pre>Got paged because DQMon was complaining (some ISL ladders 
Silicon/I/B5/W0/L* were not getting data). But while on 
the phone DAQ Ace - Sourabh - told me that b0fib00 was stuck 
in yellow. Logged to the crate and it looked fine. But 
there were no transition messages when Sourabh was trying to 
put the crate to halt. Monitoring Ace also told me at this time  
that some ladders had tripped, he recovered them. The run was  
aborted and now we are running again. IB5W0 is getting data as  
well. 
</pre>
<!-- Author: Sebastian -->
<!-- Comment: Tue May  3 07;33;08 comment by...s -->
<pre>Should say that ace tried to partition the crate alone but,
aparently, it was not responding.</pre>
<!-- Comment: Tue May  3 08;18;35 comment by...Sebastin -->
<br>Looks like the crate rebooted itself, so, in principle, partition and config should have brought fib00 back from the yellow (undefined) state.
<pre>
Crate b0fib00 -> FIB_SVX_00 started at Tue May 03 06:13:57 CDT 2005 Boot Time: TUE MAY 03 06:13:53 2005
Refreshing from HDWDB 
        Then    2005-04-28 10:30:19.0
        Now     2005-05-03 06:14:18.0
Loading Message
Transaction Time: 3516 ms
</pre>
<!-- Comment: Tue May  3 08;27;27 comment by...Sebastian -->
<br>
This is tre tripp, all from fib00:

<pre>
Tue May 03 06:13:42 CDT 2005                        TRIP: SVX  B0  W0 DVDD3 OverCurrent
Tue May 03 06:13:42 CDT 2005                        TRIP: SVX  B0  W0 DVDD4 OverCurrent
Tue May 03 06:13:42 CDT 2005                        TRIP: SVX  B0  W1 DVDD0 OverCurrent
Tue May 03 06:13:42 CDT 2005                        TRIP: SVX  B0  W1 DVDD1 OverCurrent
Tue May 03 06:13:42 CDT 2005                        TRIP: SVX  B0  W1 DVDD2 OverCurrent
Tue May 03 06:13:42 CDT 2005                        TRIP: SVX  B0  W1 DVDD3 OverCurrent
Tue May 03 06:13:42 CDT 2005                        TRIP: SVX  B0  W2 DVDD1 OverCurrent
Tue May 03 06:13:42 CDT 2005                        TRIP: SVX  B0  W2 DVDD2 OverCurrent
Tue May 03 06:13:42 CDT 2005                        TRIP: SVX  B0  W2 DVDD4 OverCurrent
Tue May 03 06:13:42 CDT 2005                        TRIP: SVX  B0  W3 DVDD0 OverCurrent
Tue May 03 06:13:42 CDT 2005                        TRIP: SVX  B0  W10 DVDD1 OverCurrent
Tue May 03 06:13:42 CDT 2005                        TRIP: SVX  B0  W10 DVDD2 OverCurrent
Tue May 03 06:13:42 CDT 2005                        TRIP: SVX  B0  W10 DVDD3 OverCurrent
Tue May 03 06:13:42 CDT 2005                        TRIP: SVX  B0  W10 DVDD4 OverCurrent
Tue May 03 06:13:42 CDT 2005                        TRIP: SVX  B0  W11 DVDD2 OverCurrent
Tue May 03 06:13:42 CDT 2005                        TRIP: SVX  B0  W11 DVDD3 OverCurrent
Tue May 03 06:13:42 CDT 2005                        TRIP: SVX  B0  W11 DVDD4 OverCurrent
Tue May 03 06:13:42 CDT 2005                        TRIP: SVX  B1  W0 DVDD0 OverCurrent
Tue May 03 06:13:42 CDT 2005                        TRIP: SVX  B1  W0 DVDD1 OverCurrent
Tue May 03 06:13:42 CDT 2005                        TRIP: SVX  B1  W0 DVDD2 OverCurrent
Tue May 03 06:13:42 CDT 2005                        TRIP: SVX  B1  W0 DVDD3 OverCurrent
Tue May 03 06:13:42 CDT 2005                        TRIP: SVX  B1  W0 DVDD4 OverCurrent
Tue May 03 06:13:42 CDT 2005                        TRIP: SVX  B1  W1 DVDD1 OverCurrent
Tue May 03 06:13:42 CDT 2005                        TRIP: SVX  B1  W1 DVDD3 OverCurrent
Tue May 03 06:13:42 CDT 2005                        TRIP: SVX  B1  W1 DVDD4 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B1  W2 DVDD1 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B1  W2 DVDD3 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B1  W2 DVDD4 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B1  W3 DVDD3 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B1  W3 DVDD4 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B1  W10 DVDD1 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B1  W10 DVDD2 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B1  W10 DVDD3 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B1  W10 DVDD4 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B1  W11 DVDD1 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B1  W11 DVDD2 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B1  W11 DVDD4 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B2  W0 DVDD3 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B2  W0 DVDD4 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B2  W1 DVDD1 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B2  W1 DVDD3 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B2  W1 DVDD4 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B2  W2 DVDD1 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B2  W2 DVDD3 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B2  W2 DVDD4 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B2  W3 DVDD0 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B2  W3 DVDD2 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B2  W3 DVDD3 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B2  W3 DVDD4 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B2  W10 DVDD0 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B2  W10 DVDD1 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B2  W10 DVDD2 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B2  W10 DVDD3 OverCurrent
Tue May 03 06:13:43 CDT 2005                        TRIP: SVX  B2  W10 DVDD4 OverCurrent
Tue May 03 06:13:44 CDT 2005                        TRIP: SVX  B2  W11 DVDD2 OverCurrent
Tue May 03 06:13:44 CDT 2005                        TRIP: SVX  B2  W11 DVDD4 OverCurrent
Tue May 03 06:13:53 CDT 2005                        TRIP: SVX  B0  W0 DVDD0 OverCurrent
Tue May 03 06:13:53 CDT 2005                        TRIP: SVX  B0  W0 DVDD1 OverCurrent
Tue May 03 06:13:53 CDT 2005                        TRIP: SVX  B0  W0 DVDD2 OverCurrent
Tue May 03 06:13:53 CDT 2005                        TRIP: SVX  B0  W2 DVDD0 OverCurrent
Tue May 03 06:13:53 CDT 2005                        TRIP: SVX  B0  W3 DVDD1 OverCurrent
Tue May 03 06:13:53 CDT 2005                        TRIP: SVX  B0  W3 DVDD2 OverCurrent
Tue May 03 06:13:53 CDT 2005                        TRIP: SVX  B0  W3 DVDD3 OverCurrent
Tue May 03 06:13:53 CDT 2005                        TRIP: SVX  B0  W10 DVDD0 OverCurrent
Tue May 03 06:13:53 CDT 2005                        TRIP: SVX  B0  W11 DVDD0 OverCurrent
Tue May 03 06:13:53 CDT 2005                        TRIP: SVX  B1  W1 DVDD0 OverCurrent
Tue May 03 06:13:53 CDT 2005                        TRIP: SVX  B1  W1 DVDD2 OverCurrent
Tue May 03 06:13:54 CDT 2005                        TRIP: SVX  B1  W2 DVDD2 OverCurrent
Tue May 03 06:13:54 CDT 2005                        TRIP: SVX  B1  W3 DVDD1 OverCurrent
Tue May 03 06:13:54 CDT 2005                        TRIP: SVX  B1  W3 DVDD2 OverCurrent
Tue May 03 06:13:54 CDT 2005                        TRIP: SVX  B1  W10 DVDD0 OverCurrent
Tue May 03 06:13:54 CDT 2005                        TRIP: SVX  B1  W11 DVDD0 OverCurrent
Tue May 03 06:13:54 CDT 2005                        TRIP: SVX  B1  W11 DVDD3 OverCurrent
Tue May 03 06:13:54 CDT 2005                        TRIP: SVX  B2  W0 DVDD0 OverCurrent
Tue May 03 06:13:54 CDT 2005                        TRIP: SVX  B2  W0 DVDD1 OverCurrent
Tue May 03 06:13:54 CDT 2005                        TRIP: SVX  B2  W0 DVDD2 OverCurrent
Tue May 03 06:13:54 CDT 2005                        TRIP: SVX  B2  W1 DVDD0 OverCurrent
Tue May 03 06:13:54 CDT 2005                        TRIP: SVX  B2  W1 DVDD2 OverCurrent
Tue May 03 06:13:54 CDT 2005                        TRIP: SVX  B2  W2 DVDD0 OverCurrent
Tue May 03 06:13:54 CDT 2005                        TRIP: SVX  B2  W2 DVDD2 OverCurrent
Tue May 03 06:13:54 CDT 2005                        TRIP: SVX  B2  W3 DVDD1 OverCurrent
Tue May 03 06:13:54 CDT 2005                        TRIP: SVX  B2  W11 DVDD0 OverCurrent
Tue May 03 06:13:54 CDT 2005                        TRIP: SVX  B2  W11 DVDD1 OverCurrent
Tue May 03 06:13:54 CDT 2005                        TRIP: SVX  B2  W11 DVDD3 OverCurrent
</pre>
If this happens again, Marcel recommends power cycling the VME crate (from RACKS menu in iFix).
<!-- Comment: Tue May  3 08;41;54 comment by...Sebastian & Marcel -->
<h4>The sequence of things <an reconstruction attempt) </h4>
<ol>
<li> Something (Beam) hit fib00, the crate CPU rebooted and the Glinks got probably out of sync. </li>
<li> Everything attached to this FIB  trips </li>
<li We get an inhibt </li>
<li> After the reboot, Aces can turn on wedges again, but cannot talk to crate via RC </li>
<li> So probably the fer code did not get loaded/did not work  (unclear why)</li>
<li> A second reboot brought the crate back</li>
</ol>
Slightly odd ....
<!-- Date: Tue May 3 06:55:09 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6563&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6563  width='300' align='top'></a></td><td>SVXMon now looks fine, asked the Ace (Sourabh) to restart 
DQMon because the yellow list was still there.</td></tr></table>
<!-- Author: Sebastian -->
<!-- Comment: Tue May  3 06;57;20 comment by...sebastian -->
<pre>mmm, svxmon_yellow.txt still has IB5W0 as yellow, though it's
fine, may be it takes a while to update..</pre>






<!-- Date: Tue May 3 08:57:09 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6565&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6565' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6566&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6566' width='300'></a></center>
<!-- Author: Sebastian -->
<!-- Comment: Tue May  3 08;57;54 comment by...Marcel/Sebastian -->
<pre>e144 is giving physics data.</pre>


<!-- Date: Tue May 3 09:19:10 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6567&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6567' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6568&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6568' width='300'></a></center>
<!-- Author: Sebastian -->
<!-- Comment: Tue May  3 09;19;48 comment by...s -->
<pre>f112 is getting data on the Z side.</pre>

<!-- Date: Tue May 3 09:30:34 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W1L1 
<li>problem n: 1470 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Chip 10 (b5) has a large, new bump at high ADC in run 197317.  Bitreporter and DS EM are pristine.  Diagnose. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue May 3 10:09:36 2005 -->
<center><a href='/elog/notebooks/silicon/Tue_May__3_2005_100905.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6570' ></a><a href='/elog/notebooks/silicon/Tue_May__3_2005_100918.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6572' ></a></center>
<!-- Author: boveia -->
<!-- Comment: Tue May  3 10;32;48 comment by...boveia -->
<pre>f411, chip 10 (b5) now has a bad channel 98.</pre>

<!-- Date: Tue May 3 10:34:29 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W1L1 
<li>problem n: 1470 
<li>Status: fixed
<li>Type: Chip_other
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Channel 98 is hot.  <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=247&frame=2&anchor=10:09:36'> e-log</a> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue May 3 11:43:35 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W4L0 
<li>problem n: 1444 
<li>Status: fixed
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Bump on chip 0 is from bad channels 72-74 (mainly 74.)  Bump on chip 15 is from bad channels 10-20. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W4&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue May 3 12:00:20 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W5L1 
<li>problem n: 1421 
<li>Status: fixed
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: boveia 
<li>description is: See thread 645. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W5&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue May 3 13:23:23 2005 -->
<br> 
Had a busy time out from b0svx06 (Daniel called). In the crate cpu everything looked fine. Looking at the err log all I could find 
was: 
<pre> 
(MLE) b0l3pcom1.fnal.gov:main:May 3, 2005 12:24:13 PM->Host b0eb11.fnal.gov, task tRec_0 
SCPU-P0-E-VrbReadFailed: Error reading VRB in slot 10 for event 5379193. 
</pre> 
But I'm not sure this is the culprit. In any case we decided 
to stop the run and clear the EVB. After solving unrelated problems with RC 
(<a href='http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=368&frame=2&anchor=13:10:41.377'>see here</a>) we are running again.<br>  
<!-- Author: Sebastian -->
<!-- Comment: Tue May  3 14;51;45 comment by...Marcel -->
<h4> these Aces </h4>
How often do you need to tell them, that a BUSY TO is in 99 % of the cases not a problem of svx06. Your entry makes it very clear, this is actually eb11, (a DAQ VRB), so it has nothing to do with us. Looks like, the EVB got stuck reading, this VRB and then everything else went downhill from that. They should not even bother calling us, unless they can prove, that it is actually an SVX problem. Not that we did not tell them extensively about BUSY TO in the ACE training, maybe we'll have to tell them every week.


<!-- Comment: Mon May  9 09;41;53 comment by...s -->
<pre>our EVB crates are eb17 to eb25</pre>
<!-- Date: Wed May 4 08:56:40 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6579&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6579  width='300' align='top'></a></td><td>Beam condition for store <b>4126</b>.</td></tr></table>
<!-- Author: Tuula/Sebastian -->
<!-- Comment: Wed May  4 08;57;09 comment by...T/S -->
<pre>Initial luminosity: 81E30</pre>


<!-- Date: Wed May 4 08:59:33 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6580&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6581  width='300' align='top'></a></td><td>SVT spy for store 4126.</td></tr></table>
<!-- Author: T/S -->
<!-- Comment: Wed May  4 09;06;59 comment by...Tuula/Sebastian -->
<pre>No problems in SVXMon:

[svxii@b0dasvx01 ~]$ cat /data1/consumer/results/SVXMon/svxmon_yellow.txt 
Status: OK
---------------------------------------
Run 197405, Wed May  4 05:52:13
SVX
Status: OK
ISL
Status: OK
L00
Status: OK
</pre>


<!-- Date: Wed May 4 11:37:03 2005 -->
<h4>Resonances this morning</h4> 
<pre> 
26'47" b0svx02:Messenger:May 4, 2005 10:26:47 AM->SRC Fatal Error:Sl 6 Resonance Detected 
 SRC Fatal Error from b0svx02: Sl 6 Resonance Detected 
27'48" b0svx02:Messenger:May 4, 2005 10:27:48 AM->SRC Fatal Error:Sl 6 Resonance Detected 
 SRC Fatal Error from b0svx02: Sl 6 Resonance Detected 
12'35" b0svx02:Messenger:May 4, 2005 11:12:34 AM->SRC Fatal Error:Sl 6 Resonance Detected 
 SRC Fatal Error from b0svx02: Sl 6 Resonance Detected 
27'43" b0svx02:Messenger:May 4, 2005 11:27:41 AM->SRC Fatal Error:Sl 6 Resonance Detected 
 SRC Fatal Error from b0svx02: Sl 6 Resonance Detected 
</pre>  
<!-- Author: Marcel -->


<!-- Date: Wed May 4 11:38:22 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6582&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6582  width='300' align='top'></a></td><td>A weak hypothesis:<br> 
I don't see anything wrong with the SVX at the moment, however, the changes in prescales seem to coincide with the resonances ...<br> 
Do I believe it ....</td></tr></table>
<!-- Author: Marcel -->


<!-- Date: Wed May 4 11:51:39 2005 -->
<br>We got a: 
 
<pre> 
CT: 2005.05.04 11:35:31 
35'31" b0svx06:Messenger:May 4, 2005 11:35:33 AM->SRC Fatal Error:Sl 6 L2A w/o L1A  
 -->   
 Additional Information:  
 Attention !!!. FERML_SRC_FATALITY ERROR !!!   
 SRC Fatal Error from b0svx06: Sl 6 L2A w/o L1A  
</pre> 
We had one of these some week(s?) ago. Might be related to  
L2 changes.
<!-- Author: Marcel/Sebastian -->


<!-- Date: Wed May 4 11:54:58 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6583&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6583  width='300' align='top'></a></td><td>e144 bias has been ramping during this store.</td></tr></table>
<!-- Author: Sebastian -->
<!-- Comment: Wed May  4 12;47;03 comment by...s -->
<pre>Came back to nominal values.</pre>
<!-- Date: Wed May 4 12:13:10 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6585&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6585  width='300' align='top'></a></td><td>Bunch profile for store 4126.</td></tr></table>
<!-- Author: M/S -->
<!-- Comment: Wed May  4 12;15;25 comment by...s -->
<pre>The bunch structure looks different for this recycle shot, this
might explain why we are getting more resonances, the pbar bunches
are more equaly populated compared to normal shots. </pre>


<!-- Date: Wed May 4 12:43:33 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6586&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6586' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6587&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6587' width='300'></a></center>
<!-- Author: Sebastian -->
<!-- Comment: Wed May  4 12;45;11 comment by...s -->
<pre>p and pbar bunches intensities for store 4126 some 30 min after we had 4 resonances.</pre>



<!-- Date: Wed May 4 12:53:15 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6588&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6588' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6589&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6589' width='300'></a></center>
<!-- Author: Marcel/Sebastian -->
<!-- Comment: Wed May  4 12;53;56 comment by...Marcel/Sebastian -->
Intensity for pbar bunches 1-8 for this store (lefT) and last store (right)


<!-- Date: Wed May 4 15:23:21 2005 -->
<pre>Another resonance (fifth during this run - 197440 - so far). 
But the L1 rate is 26kHz, at which we sometimes get resonances.</pre>
<!-- Author: Sebastian -->


<!-- Date: Wed May 4 22:48:16 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6594&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6594' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6595&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6595' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6596&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6597' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6598&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6599' ></a></center>
<!-- Author: SCN -->
<!-- Comment: Wed May  4 22;54;48 comment by...Old timer -->
More on SB1W4L4 Bias.  First two plots are the IMON history
(see <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=372&frame=2&anchor=19:38:36.372'>
main log</a>) over the last several hours-it went pink, we paged
S and I called Marcel (the sharp drop was when I was talking to Marcel on the phone).  As you can see, the bias current continues
to wander around at the ~400 μA scale. The third plot is the distribution of 
bias currents over the last 4 years, and the final one is the time
versus bias current for about the same time range.  Needs further investigation, I guess.


<!-- Date: Thu May 5 09:05:00 2005 -->
<h3>Access report</h3> 
We swapped fibers for <b>e182</b> and <b>e3a1</b>.  
In both cases the errors stayed with the ladders 
(not DAQ problem).
<!-- Author: Tuula/Sebastian/all -->
<!-- Comment: Thu May  5 16;05;56 comment by...Ankush & Rong -->
<h3>Access Report 2</h3>

<p>Rong and I went to put a new RX into SB3W9L3 (e393).  We took out RX 0668 and put in RX 0791.  However the error rate remained the same.</p>

<p>As this ladder has had persistent laight level problems, the next step is to change the DOIM voltages.  Otherwise this ladder could be a candidiate for the Super-RX/AM-RX/Bitbooster.</p>
<!-- Comment: Thu May  5 16;14;36 comment by...Ankush/Marcel/Khadoum-Guest Ace -->
<h3>Access Report 3: Light level measurement</h3>

<p>SB1W8L2 (e182) has had intermitent problems.  It couldn't be replicated in SVXDaq but has had problems during data taking.  So we went down to measure the light level; it's possible some light levels may be on the edge of threshold.</p>

<p>From the light level measurements, bit 2 is significantly lower than the other bits.  So the next step would be to either replace the RX or play with the DOIM voltage to increase the light out of bit 2.  However this ladder could also be a candidate for the Super-RX/AM-RX/Bitbooster.</p>

<b>Light Level Mesurments</b>

<table border=1>
<tr>
<td>Bit 0</td>
<td>680 uW</td>
</tr>
<tr>
<td>Bit 1</td>
<td>110 uW</td>
</tr>
<tr>
<td>Bit 2</td>
<td>48 uW</td>
</tr>
<tr>
<td>Bit 3</td>
<td>740 uW</td>
</tr>
<tr>
<td>Bit 4</td>
<td>800 uW</td>
</tr>
<tr>
<td>Bit 5</td>
<td>1000 uW</td>
</tr>
<tr>
<td>Bit 6</td>
<td>1000 uW</td>
</tr>
<tr>
<td>Bit 7</td>
<td>1120 uW</td>
</tr>
</table>
<!-- Date: Thu May 5 11:00:04 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W9L3 
<li>problem n: 1410 
<li>Status: needs_access_8hr
<li>Type: TX
<li>Action: Swap_RX
<li>entered by: rong 
<li>description is: Swapped RX again, but error rate did not change. Next thing to try is to play with the DOIM voltages to see if the situation improves.<table border=1>
   <tr>
    <td>
     <b>IN:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0791">0791</a>
    </td>
   </tr>
   <tr>
    <td>
     <b>OUT:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0668">0668</a>
    </td>
   </tr>
  </table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W9&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu May 5 11:00:42 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W9L3 
<li>problem n: 1410 
<li>Status: needs_access_8hr
<li>Type: TX
<li>Action: Swap_RX
<li>entered by: rong 
<li>description is: Swapped RX again, but error rate did not change. Next thing to try is to play with the DOIM voltages to see if the situation improves.<table border=1>
   <tr>
    <td>
     <b>IN:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0791">0791</a>
    </td>
   </tr>
   <tr>
    <td>
     <b>OUT:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0668">0668</a>
    </td>
   </tr>
  </table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W9&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu May 5 11:13:28 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W8L2 
<li>problem n: 1469 
<li>Status: needs_access_8hr
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>During the supervised access the light level from this ladder was measured.  The results are in the table below.  Only Bit 2 is low w.r.t other bits & OBDV.</p>  <p>The next thing is to either to raise the DOIM voltage to increase the light coming out of bit 2 or replace the RX.  This ladder could also be a candidate for the Super-RX/AM-RX/Bit Booster. </p>  <h5>Light Levels</h5>  <table border=1> <tr> <td> Bit 0 </td> <td> 680 uW </td> </tr> <tr> <td> Bit 1 </td> <td> 110 uW </td> </tr> <tr> <td> Bit 2 </td> <td> 48 uW </td> </tr> <tr> <td> Bit 3 </td> <td> 740 uW </td> </tr> <tr> <td> Bit 4 </td> <td> 800 uW </td> </tr> <td> Bit 5 </td> <td> 1000 uW </td> </tr> <tr> <td> Bit 6 </td> <td> 1000 uW </td> </tr> <tr> <td> Bit 7 </td> <td> 1120 uW </td> </tr> <tr> <td> OBDV </td> <td> 920 uW </td> </tr> </table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W8&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu May 5 15:19:11 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W10L1 
<li>problem n: 1468 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: went in and swapped the fibers, problem is internal, change rdrivers may be an option   
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W10&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu May 5 15:48:09 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W10L1 
<li>problem n: 1468 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>Found out increasing RDRiver to 7 for all chips in this ladder elimininates any error.</p>  <p>The hardware database was updated so all chips in this ladders user RDriver=7.  Monitoring group should keep an eye on this ladder during running to check we don't get any more errors.  If it is error-free for a few weeks, then declare this thread fixed.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W10&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu May 5 15:52:17 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W10L3 
<li>problem n: 1407 
<li>Status: needs_observation
<li>Type: DRO_00F3
<li>Action: Monitoring
<li>entered by: amitra 
<li>description is: <p>The previous entry mentioned RDRiver=6 for all chips reduced the error rate.  So the hardware database was edited and now uses RDriver=6 for all chips</p>  <p>Monitoring group should keep an eye on this ladder and see if the error rate does drop. However I don't expect the error rate to goto to zero for this ladder.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W10&layer=L3">report</a></ul>
<!-- Author: Problem DB -->





<!-- Date: Thu May 5 16:22:11 2005 -->
<h3>Changes to Hardware Database</h3> 
 
<p>The RDriver settings were changed for 2 ladders.</p> 
 
<ul> 
<li>SB3W10L1 (e3a1) : RDriver = 7 for all chips</li> 
<li>SB4W10L3 (e4a3) : RDriver = 6 for all chips</li> 
</ul> 
  
<!-- Author: Ankush/Marcel -->
<!-- Comment: Thu May  5 17;57;14 comment by...Ankush/Marcel -->
<p>Another change to the hardware database was made.</p>

<p>The RDriver setting for SB2W3L3 (e233) was changed.  All chips now have RDriver=7</p>
<!-- Date: Thu May 5 16:31:02 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W10L0 
<li>problem n: 1167 
<li>Status: needs_access_2hr
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: ok, I was running a FIB2 VRB test on this guy, seems to be all fine. 100000 events no error. I suspect this problem to be downstream somewhere. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W10&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu May 5 17:23:08 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W3L3 
<li>problem n: 1467 
<li>Status: needs_work
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>Setting RDriver=7 for all ladders eliminates the problems reported.  After ~30,000 events no errors from this ladder were seen.  This setting should be added to the hardware database.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W3&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu May 5 17:37:00 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W5L3 
<li>problem n: 867 
<li>Status: needs_work
<li>Type: AVDD2
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>Ran this ladder again during quiet time.  Same results again. The Z side could be read out in Read-All and Nearest Neighbour mode.</p>  <p>May when I feel a bit braver I may edit the hardware database to bring the Z side back.</p>  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W5&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu May 5 17:47:55 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W3L3 
<li>problem n: 1467 
<li>Status: needs_observation
<li>Type: Chip_other
<li>Action: Added_hdwdb
<li>entered by: amitra 
<li>description is: <p>The RDriver was set to 7 for all chips in this ladder in the Hardware database. Monitoring should keep an eye on this during data-taking to check the error rate from this ladder.  If the error is zero for a few weeks then declare this thread fixed.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W3&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu May 5 17:47:55 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W3L3 
<li>problem n: 1467 
<li>Status: needs_observation
<li>Type: Chip_other
<li>Action: Added_hdwdb
<li>entered by: amitra 
<li>description is: <p>The RDriver was set to 7 for all chips in this ladder in the Hardware database. Monitoring should keep an eye on this during data-taking to check the error rate from this ladder.  If the error is zero for a few weeks then declare this thread fixed.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W3&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu May 5 17:54:56 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W1L2 
<li>problem n: 928 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>I ran this ladder during quiet time and I got the same results again.  It runs fine in Read-All mode but gives Illegal Channel Error in Nearest Neighbour mode.  However the rate was low; only 15 after 5,000 events.</p>  <p>I'm passing this thread onto Monitoring.  If the error rate starts rampinf up then pass it back to detector.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Thu May 5 18:04:44 2005 -->
<h3>Change of cooling alarm limits</h3> 
Upon request from our SPLs, we adjusted some limits in the cooling IFIX database. After reducing temperatures to -10C, the interplay between pressures and flows has become much more delicate. Consequently, some pressures went close to their upper warning limits. Since the current limits are still well below atmospheric pressure, we decided to increase them by 0.1 psi. The new  
limits are: 
<ul> 
<li>For PT-COTBHE[1..3], PT-COTBHW[1..3]: HI=13.1 psi (was 13.0), HIHI=13.6 psi(was 13.5)</li> 
<li>For PT-COTL00[E,W]: HI=13.1 psi (was 13.0), HIHI=13.6 psi (was 13.5)</li> 
</ul>
<!-- Author: Ulrich H. / Eva H. -->


<!-- Date: Fri May 6 03:19:18 2005 -->
<h2>Problems with PSGui/b0dasvx01</h2> 
 
Xiaojian paged me becasue the PSGui got stuck.  
IMon was ok, no trips but the PSGui was stuck and 
we could not even kill the java processes. svxinter 
looked OK at the time. Also failed to start a new 
PSGui with: 
<pre> 
<svxii@b0dasvx01>setup fer 
<svxii@b0dasvx01>cd ~/daq/PSanywhere 
<svxii@b0dasvx01>PS& 
[1] 15794 
<svxii@b0dasvx01>PS: Command not found. 
</pre> 
Also found lots of zombie processes: 
<pre> 
svxii    10482  0.0  0.0     0    0 pts/1    Z    May05   0:00 [java <defunct>] 
svxii    26292  0.0  0.0     0    0 ?        Z    May02   0:00 [plugger <defunct>] 
</pre> 
Since I couldn't get rid of these processes and we 
couldn't restart the PSGui I asked the Ace to reboot 
the machine. He couldn't log in as svxii (neither could I) so I added 
him to the .k5login and then he ssh'ed as svxii to the 
machine to start the PSGui. This worked and iFix 
was happy (green) again.<br> 
In the morning we will log in as svxii.<br> 
Should note that we restarted the PSGui yesterday.<br>
<!-- Author: Sebastian -->
<!-- Comment: Fri May  6 08;28;43 comment by...Marcel/Sebastian -->
<pre>This morning we talked with Sergei and looks like the password of the svxii account was reset. He set the password again and now PSGui is running under svxii.</pre>

<!-- Comment: Fri May  6 09;32;17 comment by...Marcel -->
<table border=0><td><tr><td bgcolor=#e0e030><h1> Arggggh</h1></td></tr></td></table>


<!-- Date: Fri May 6 13:21:48 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6601&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6601  width='300' align='top'></a></td><td>Store <b>4131</b> is in, Silicon included, initial luminosity is 56E30.</td></tr></table>
<!-- Author: Sebastian -->


<!-- Date: Fri May 6 13:28:23 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6602&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6602  width='300' align='top'></a></td><td>SVT hits. Note that the processing time histogram is empty.</td></tr></table>
<!-- Author: Sebastian -->
<!-- Comment: Fri May  6 13;35;37 comment by...s -->
<pre>Benedetto (from the SVT group) is now aware that the processing time plot missing (said it might take a while to load... but was there from the beginning in the past). </pre>


<!-- Date: Fri May 6 13:36:00 2005 -->
<pre>SVXMon is fine.</pre>
<!-- Author: Marcel/Sebastian -->


<!-- Date: Fri May 6 14:36:02 2005 -->
<pre>SVXMon complained after new run was started, now everything is fine.</pre>
<!-- Author: Sebastian -->


<!-- Date: Fri May 6 14:39:54 2005 -->
<pre>SB1W4L4 is set to be ingnored in IMon (current is now 2540 muA).</pre>
<!-- Author: M/S -->


<!-- Date: Fri May 6 17:11:51 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6603&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6603  width='300' align='top'></a></td><td>Trip: SVX B2 W2 DVDD4 OverCurrent</td></tr></table>
<!-- Author: K -->
<!-- Comment: Fri May  6 17;12;21 comment by...Kwangzoo -->
<pre>oops, wrong place..</pre>


<!-- Date: Sat May 7 02:04:05 2005 -->
<br> 
Had a series of resonances again, see  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=379&frame=2&anchor=01:19:38.201'> 
here</a>. 
This time the bunch structure looks normal, and the L1 rate is not high (about 17kHz). This is strange and I am not sure what is causing more resonances. The trigger tables were not changed  
recently, and I am not aware of any hardware work which would  
have affected the L1 rate. Should keep and eye on this and try 
to see if we are always getting resonances in bunches and/or 
at certain rates.<br> 
Also we lost communication to crate 2 and had a trip which  
the Aces (Xiaojian and Michael) recovered.<br>
<!-- Author: Sebastian -->
<!-- Comment: Sat May  7 02;16;00 comment by...Sebastian -->
<br>Forgot to note that we had a series of resonances earlier
this week (<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=247&frame=2&anchor=11:37:03'>
here</a>). Note that this was before the access on Thursday.
Veronica things that something might have been screwed up during the access because she is seeing larger than expected readout times, so there might be a problem with one fe crate (calorimeter?), but I do not think this is causing the resonances.




<!-- Comment: Sat May  7 13;31;59 comment by...Marcel -->
this is maybe something modsim could answer.., what happens if we have higher readout deadtime, that certainly has an impact on L1A as well. how directly i don't know, hence maybe Modsim (the trigger simulator ) can answer that. <br>
I also don't see anything wrong on our side.

<!-- Date: Sat May 7 03:56:04 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W1L1 
<li>problem n: 1470 
<li>Status: needs_observation
<li>Type: Chip_other
<li>Action: Monitoring
<li>entered by: yuji 
<li>description is: A bump in high ADC region on Chip 10 has shown up again in run 197640. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Sat May 7 14:03:28 2005 -->
<pre>SB4W7 tripped on DVDD overcurrent for every layers. Brought them back ok. But the whole wedge tripped a few minutes after again. This time is 5V DOIM overvoltage. Tried to bring the wedge back but failed. Hockerized the crate, still can't bring it back.</pre>
<!-- Author: Rong -->
<!-- Comment: Sat May  7 14;11;39 comment by...Rong -->
<pre>reboot the b0fib06 as well. also hockerized again. Wedge still trip on overvoltage of 5V DOIM. Will bring the wedge offline and wait for access to check the supply.</pre>

<!-- Date: Sat May 7 14:12:15 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W1L1 
<li>problem n: 1470 
<li>Status: fixed
<li>Type: Chip_other
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Bump is again due to channel 98.  Nothing to be done. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat May 7 14:12:15 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W1L1 
<li>problem n: 1470 
<li>Status: fixed
<li>Type: Chip_other
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Bump is again due to channel 98.  Nothing to be done. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat May 7 14:12:15 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W1L1 
<li>problem n: 1470 
<li>Status: fixed
<li>Type: Chip_other
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Bump is again due to channel 98.  Nothing to be done. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat May 7 14:23:00 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6604&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6605' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6606&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6607' ></a></center>
<!-- Author: Rong -->
<!-- Comment: Sat May  7 14;24;02 comment by...Rong -->
<pre>DOIM current for 2V and 5V of SB4W7. No excursion during tripping.
It still trip on 5V overvoltage (means no current?).</pre>


<!-- Comment: Sat May  7 15;13;13 comment by...MArcel -->
just a funny theory, did the cable fall off ?
<!-- Date: Sat May 7 14:38:27 2005 -->
<pre>Rong is in the CR, he will Ok including the Si.</pre>
<!-- Author: Sebastian -->


<!-- Date: Sat May 7 14:45:50 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6608&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6609  width='300' align='top'></a></td><td>Losses for store <b>4132</b></td></tr></table>
<!-- Author: Sebastian -->


<!-- Date: Sat May 7 15:05:05 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6610&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6611  width='300' align='top'></a></td><td>SVT spy plot. SB4W7 is gone.</td></tr></table>
<!-- Author: Rong -->


<!-- Date: Sat May 7 16:23:57 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W7All 
<li>problem n: 1471 
<li>Status: needs_access_2hr
<li>Type: VDOIM
<li>Action: Removed_hdwdb
<li>entered by: sebastian 
<li>description is: SB4W7 keeps tripping on 5V DOIM overvoltage. Needs access, have to find out if there is a problem with the PS or the DAQ. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W7&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat May 7 20:03:43 2005 -->
<br> 
Test of FIB SN152 in progress. In case a spare is needed for 
SB4W7.<br>
<!-- Author: Sebastian -->
<!-- Comment: Sat May  7 23;26;11 comment by...s -->
<pre>Tested FIB with no errors. </pre>


<!-- Comment: Sun May  8 02;47;50 comment by...Marcel -->
good job
<!-- Date: Sun May 8 00:11:20 2005 -->
<br> 
Looked if high deadtime is related to our slowest ladder reading out. Looks like it is not:<br> 
<pre> 
Run Num    RO Latency  Slowest Ladder 
197644     728us       17us (f112) 
197640     639us       17us (f112) 
197441     542us       16us (f112) 
197440     556us       16us (f112) 
</pre> 
So it does not look like the 100us increase in the 
RO latency (compare the first two runs to 
the last two) is caused by the Si readout.<br>  
<!-- Author: Veronica/Sebastian -->
<!-- Comment: Sun May  8 02;49;52 comment by...Marcel -->
no way, unless we would have an extremly long tail with that guy, which caused the readout to be that long. AFAIK, the VRB even hangs up after like 70 museconds, no matter what. We are never a source of latency in the readout, we are just way to fast compared to the COT.


<!-- Date: Sun May 8 02:58:29 2005 -->
<br> 
Some problems: SB2W2L4 tripped again, I asked Xiaojian to page 
me if if happens two more times.. I can take it out of the 
HWDB, but the recovery is fast and if it does not happen  
very frequently then I rather leave the ladder in.<br> 
FIB00 was rebooted when it went red in RC but the system kept 
running (no complains from IFix). SB2W2L4 is in fib00, but 
there was no trip at the time (again we will have to check the time diff between logs): 
<pre> 
Sun May 08 01:00:52 CDT 2005     TRIP: SVX  B2  W2 DVDD0 OverCurrent 
Sun May 08 01:02:24 CDT 2005     success: Power Supply SVX B2 W2 ON 
Sun May 08 02:37:56 CDT 2005     TRIP: SVX  B2  W2 DVDD4 OverCurrent 
Sun May 08 02:39:06 CDT 2005     success: Resetting trips 
Sun May 08 02:40:08 CDT 2005     success: Power Supply SVX B2 W2 OFF 
Sun May 08 02:40:16 CDT 2005     TRIP: SVX  B2  W2 DVDD0 OverCurrent 
Sun May 08 02:41:30 CDT 2005     success: Power Supply SVX B2 W2 ON 
</pre> 
and reboot:<br> 
Crate b0fib00 -> FIB_SVX_00 started at Sun May 08 02:08:50 CDT 2005 Boot Time: SUN MAY 08 02:08:45 2005<br> 
<br> 
So, I don't think that IFix missed a trip (which the Ace would have had to recover anyhow), but a spontaneous tarnsition in fib00.<br>  
<!-- Author: Sebastian -->
<!-- Comment: Sun May  8 03;11;47 comment by...Sebastian -->
<pre>note that there are two reboots in the log files:
Crate b0fib00 -> FIB_SVX_00 started at Sun May 08 02:07:36 CDT 2005 Boot Time: SUN MAY 08 02:07:31 2005
Crate b0fib00 -> FIB_SVX_00 started at Sun May 08 02:08:50 CDT 2005 Boot Time: SUN MAY 08 02:08:45 2005

strange that it appear red in RC and not yellow.</pre>

<!-- Date: Sun May 8 07:05:54 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W5L0 
<li>problem n: 1472 
<li>Status: needs_work
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: yuji 
<li>description is: No data from chips 2. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W5&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sun May 8 11:07:30 2005 -->
<br> 
<b>Trigger table test:</b> Veronica did a trig table test (for  
jet calibration data) with and without silicon, L1 rate was  
in both cases around 600Hz.<br>
<!-- Author: Sebastian -->


<!-- Date: Sun May 8 11:09:11 2005 -->
Access at 12:00, Rong, Jennifer and Marcel are on their way  
(will let Tuula know, in case she wants to come as well).<br>
<!-- Author: Sebastian -->


<!-- Date: Sun May 8 12:02:28 2005 -->
<h3> CAEN went gaga </h3> 
 
<pre> 
 setVoltages: Caenet_Write Error number ffffffff received  
 
Errcode 20 
 
 cr_n = 3, bd_n = 3, channel = 3SetPSStatus -- SetChannelStatus, err = 20, detector = 2, ps_n = 10 
 Caenet_write: Error number -1 received 
 
Errcode 10-1 
setPSStatus -- getPSstatus,err = 10,detector = 2, ps_n = 11 
 Caenet_write: Error number -1 received 
 
Errcode 10-1 
setPSStatus -- getPSstatus,err = 10,detector = 2, ps_n = 12 
setDetectorStatus,err = 1, detector = 2setStatus,err = 1ERROR: trying to change detector status via iFix 
 Caenet_buffer: Error number 7 7 received 
group_info:cr_n = 3, response = 7 
Sending Request for f036 
Sending Request for f136 
Sending Request for f146 
Sending Request for f156 
Sending Request for f206 
Module is busy, sending code = 18 
</pre> 
Looks like the thing went spontaneously off 
This corresponds to Crate 3 SW TOP TOP
<!-- Author: Marcel -->


<!-- Date: Sun May 8 14:53:11 2005 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sun_May__8_2005_145308.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6613  align='top'></a></td><td>SVXdaq data for SB4W7L0-4.</td></tr></table>
<!-- Author: Rong-Shyang -->
<!-- Comment: Sun May  8 14;53;34 comment by...Rong -->
<pre>Data is perfect. No error during running.</pre>


<!-- Date: Sun May 8 14:55:49 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6614&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6615  width='300' align='top'></a></td><td>PSGui snapshot after PS swapping. The wedge is biased now.</td></tr></table>
<!-- Author: Rong -->


<!-- Date: Sun May 8 15:36:53 2005 -->
<h2>SB4W7 Access Summary</h2> 
Went in to check out SB4W7, which started tripping <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=247&frame=2&anchor=14:03:28'>OverVoltage</a> on the 5 Volt DOIM yesterday and had to be removed.  We tried swapping cables with SB5W7, the problem stayed with the supply.  So an executive decision was made to try swapping in a supply from the FCC teststand, which was technically labeled as still needing a burn-in test before being considered "good".  We replaced the supply and started loadbox testing; everything checked out except that the hardware trip limit for L4 was not set correctly on the supply (an excellent example of why we like to check the supply out upstairs right BEFORE we try swapping it in!)  We had to pull the supply out, bring it upstairs, adjust the trip limit, and then put it back downstairs.  We checked that it now tripped properly on L4 OverVoltage and that everything could be powered from upstairs before leaving.  SB4W7 has been recovered; SUCCESS!<br><br> 
This supply did show some odd features, so we should keep an eye on it.  The 5V DOIM is set at 5.41V, and the readout on the supply also reads 5.41V, but the loadbox consistently read ~4.6V.  If this is a real feature and not just a problem with the loadbox, there may be some errors caused by the DOIM voltage difference being too small.  The supply also could not be powered when we brought it upstairs and put it in the teststand;  this is still a mystery.  At least it powered fine down in the hall.<br>
<!-- Author: Jen, Sebastian, Rong, Marcel -->
<!-- Comment: Sun May  8 16;07;32 comment by...Marcel -->
the decision to use this supply was of course driven by the fact, that it has been used for a long time at FCC and had been checked out twice for other reasons.<br>
And we did not have another supply as ready to go as this one


<!-- Date: Sun May 8 18:42:31 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6616&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6616  width='300' align='top'></a></td><td>Store <b>4134</b> is in, the Silicon is included, initial lum 75E30.</td></tr></table>
<!-- Author: Sebastian -->


<!-- Date: Sun May 8 18:58:41 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6617&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6618  width='300' align='top'></a></td><td>SVT spymon, e47 is back.</td></tr></table>
<!-- Author: Sebastian -->
<!-- Comment: Sun May  8 18;59;34 comment by...s -->
<pre>SVT people have been working on spymon.. noticed that it took longer than usual to get statistics.</pre>

<!-- Comment: Sun May  8 19;00;52 comment by...s -->
<pre>SVXMon is ok.</pre>

<!-- Date: Sun May 8 19:05:03 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W7All 
<li>problem n: 1471 
<li>Status: needs_observation
<li>Type: VDOIM
<li>Action: Added_hdwdb
<li>entered by: sebastian 
<li>description is: Swapped problematic PS, the wedge is back. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W7&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun May 8 19:08:16 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W7L0 
<li>problem n: 1473 
<li>Status: needs_observation
<li>Type: DVDD
<li>Action: IMON_limits
<li>entered by: sebastian 
<li>description is: Changed IMON limits fro e470 for AVDD and DVDD after PS was swapped.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>88</td><td>53</td></tr>
<tr><td><b>Lower</b></td><td>65</td><td>30</td></tr>
<tr><td><b>Upper</b></td><td>100</td><td>75</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W7&layer=L0">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Sun May  8 19;11;47 comment by...Sebastian -->
Also changed AVDD IMon limits.


<!-- Date: Sun May 8 20:22:06 2005 -->
<h3>The week (this far)</h3> 
 
<ul> 
<li> Stores 
<ul> 
<li> 4122 Ok (for this week at least) ended in quench - not bad for Si. 
<li> 4125 IB5W0 not getting data and fib00 rebooting - fixed with no mayor problems - down time: 25min to recover 2 trips. 
<li> 4126 resonance time, 25min to deal with 3 resonances and a  
L1Aw/oL2A. 
<li> 4131 PS crate 2 reset, resonance and 2 trips: 45min  
<li> 4132 e47 out of HWDB, trips in VDOIM, e224 tripped 4 times, fib00 resets itself: 25min   
<li> 4134 no issues until end of pager duties...
</ul> 
<li> Other Issues 
<ul>  
<li> SB1W4L4 back from the dead
<li> f112: 16us readout time, should reduce noise level, change threshold in quiet time  
<li> Access: fiber swap, light level measurement, RX swap (failed to solve problem with e393) 
<li> Access: PS swap in SEBT slot 2 (solved problem with e47) 
<li> On going work with CAEN PS at FCC and B0  
</ul> 
 
 
</ul>  
<!-- Author: Sebastian -->


<!-- Date: Sun May 8 20:24:52 2005 -->
<br> 
Electron lens tripped (see this  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=384&frame=2&anchor=20:08:28.492'> 
entry</a>), called MCR but they were reseting the trip already - no downtime.<br>
<!-- Author: Sebastian -->