<!-- Title: 10:58:09  Mon Apr 12 2004 -->
<!-- Crewchief: Rong-Shayng  -->
<!-- Op1: Jared (Detector, 612-8214) -->
<!-- Op2: Julia (DAQ, 218-8940) -->
<!-- Op3: Ben (Monitoring, 722-8729?) -->
<!-- Op4: Reid (Power Supply, 314-0128); -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->



<!-- Date: Mon Apr 12 11:00:39 2004 -->
Reminder from Rainer. 
A couple of ace instructions for L2 w/o L1 to be found in main 
<a href="http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=226&frame=2&anchor=17:47:10.768"> 
elog</a>
<!-- Author: Rong-Shyang -->


<!-- Date: Mon Apr 12 13:12:37 2004 -->
<pre>Tev study all day. Expect to have shot setup tomorrow day shift.</pre>
<!-- Author: Rong-Shyang -->

<!-- Date: Mon Apr 12 14:45:17 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W5L4 
<li>problem n: 657 
<li>Status: fixed
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: bbrau 
<li>description is: No bit errors seen for quite some time now.  Fixed. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B1W5&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Apr 12 14:48:42 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W5L2 
<li>problem n: 1161 
<li>Status: fixed
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: bbrau 
<li>description is: Problem not seen for quite a while now.  Fixed. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=L00&wedge=B1W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Apr 12 15:02:29 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W0L0 
<li>problem n: 1232 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: bbrau 
<li>description is: Not seen since just after the shutdown.  Keep watching another two weeks before declaring fixed. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Apr 12 15:15:52 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W1L3 
<li>problem n: 1179 
<li>Status: fixed
<li>Type: Chip_other
<li>Action: Monitoring
<li>entered by: bbrau 
<li>description is: A quick look at the PSntuples shows this guy stable at the new range.  Fixed. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B4W1&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Apr 12 15:28:04 2004 -->
<pre>Paged by ACE. Handshake broken between IFix and PSGui and SVX/ISL/L00 alarm. b0dau30 was rebooted by online expert then I reboot svxinter due to PS fronzen. (vxlogin svxinter; reboot) Restart PS and IMon and bring SVX go through coldstart due to current changes in IMon history for various cells. Now everything is normal.</pre>
<!-- Author: Rong-Shyang -->
<!-- Comment: Mon Apr 12 15;32;29 comment by...Rong-Shyang -->
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=231&frame=2&anchor=14:41:08.100'>
Shift elog entry</a>. They shut b0dau30 down. They should probably have told Monitoring ACE and us first to avoid any panic. 

<!-- Date: Tue Apr 13 09:54:32 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W10L2 
<li>problem n: 1226 
<li>Status: needs_observation
<li>Type: DRO_00F3
<li>Action: Monitoring
<li>entered by: bbrau 
<li>description is: Pipeline out of sync not seen since 3/24/04 after shutdown.  Watch for another two weeks and declare it 'healed' if the problem doesn't return. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B4W10&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Apr 13 10:01:39 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W1L1 
<li>problem n: 1205 
<li>Status: unfixable
<li>Type: FE_amp_osc
<li>Action: Monitoring
<li>entered by: bbrau 
<li>description is: Was declared busticated on 4/1.  Don't know why it was listed as needs_observation. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B5W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Apr 13 10:10:11 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3873&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3874  width='300' align='top'></a></td><td>SB0W4 IBias0L0</td></tr></table>
<!-- Author: bbrau -->

<!-- Date: Tue Apr 13 10:11:31 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W4L0 
<li>problem n: 1101 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: Currents_investigated
<li>entered by: bbrau 
<li>description is: Still on the spikey side.  Keep watching. <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=191&frame=2&anchor=10:10:11'> bias current</a> 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W4&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Apr 13 12:40:40 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W0L0 
<li>problem n: 1019 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: rong 
<li>description is: bit 3 low sometime during quiet time study but mostly happened on 2nd half-ladder, chip4~11. Change the R driver to ether 4 or 7 doesn't help. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Apr 13 12:46:54 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W6L2 
<li>problem n: 1158 
<li>Status: needs_observation
<li>Type: AVDD2
<li>Action: Change_last_chip
<li>entered by: rong 
<li>description is: Quiet time study shows normal data taking on A2 chip but A1/A0 are still bad. Change the last chip readout from A2 to A1 in hardware data base. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W6&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Apr 13 12:49:20 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W6L2 
<li>problem n: 3 
<li>Status: unfixable
<li>Type: AVDD2
<li>Action: Diagnosis_update
<li>entered by: rong 
<li>description is: We changed all ISEL bits to zero on A1 chip with svxdaq  but still could not recover downstream chip.  
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W6&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Apr 13 12:51:54 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W1L0 
<li>problem n: 1184 
<li>Status: needs_observation
<li>Type: FE_amp_osc
<li>Action: Chip_bit_changes
<li>entered by: rong 
<li>description is: Changed ISEL bits. Chip 4 ~ 11 set to 1110, except chip6 is set to 1111. Keep an eye on physics data and readout length. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B2W1&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Apr 13 12:54:56 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3875&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3876  width='300' align='top'></a></td><td>SB0W6L2/e062 Plots with Svxdaq while A2 chip is working normally. But A1/A0 chips could not be recoverd by changing ISEL bits.</td></tr></table>
<!-- Author: Rong -->


<!-- Date: Tue Apr 13 12:57:30 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3877&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3877  width='300' align='top'></a></td><td>ISEL bits are changed for IB2W1L0/f210. 
Setting was chip5~11 at 1111. We changed to  
chip 4~11 with 1110 excpet chip6 with 1111.</td></tr></table>
<!-- Author: Rong -->

<!-- Date: Tue Apr 13 15:27:54 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W2L3 
<li>problem n: 975 
<li>Status: needs_access
<li>Type: RX
<li>Action: Diagnosis_update
<li>entered by: sforrest 
<li>description is: Bit 4 high seems to come and go, recommend swap Rx. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=L00&wedge=B0W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Apr 13 15:47:31 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3878&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3879  width='300' align='top'></a></td><td>Messy trips for several wedges. 
IMon plots.</td></tr></table>
<!-- Author: Rong-Shyang -->
<!-- Comment: Tue Apr 13 15;51;16 comment by...Rong -->
<pre>Tue Apr 13 15:06:39 CDT 2004     Software protection trip: High DVDD Current  SVX B0 W0 L1 current 158.0 softLimit 150.0
Tue Apr 13 15:06:40 CDT 2004     Software protection trip: High DVDD Current  SVX B0 W8 L1 current 161.0 softLimit 150.0
Tue Apr 13 15:06:41 CDT 2004     Software protection trip: High DVDD Current  SVX B1 W8 L1 current 160.0 softLimit 150.0
Tue Apr 13 15:06:43 CDT 2004     Software protection trip: High DVDD Current  SVX B2 W4 L1 current 155.0 softLimit 150.0
Tue Apr 13 15:06:54 CDT 2004     Software protection trip: High DVDD Current  SVX B1 W8 L1 current 160.0 softLimit 150.0
Tue Apr 13 15:06:55 CDT 2004     Software protection trip: High DVDD Current  SVX B2 W4 L1 current 155.0 softLimit 150.0
Tue Apr 13 15:06:55 CDT 2004     TRIP: SVX  B0  W0 DVDD3 OverCurrent
Tue Apr 13 15:06:55 CDT 2004     TRIP: SVX  B0  W8 DVDD0 OverCurrent
Tue Apr 13 15:06:55 CDT 2004     TRIP: SVX  B0  W8 DVDD1 OverCurrent
Tue Apr 13 15:06:55 CDT 2004     TRIP: SVX  B0  W8 DVDD3 OverCurrent
Tue Apr 13 15:10:07 CDT 2004     Interlock SVX B3 is not enabled
Tue Apr 13 15:10:07 CDT 2004     Interlock SVX B4 is not enabled
Tue Apr 13 15:10:07 CDT 2004     Interlock SVX B5 is not enabled
Tue Apr 13 15:10:07 CDT 2004     Interlock SVX B2 is not enabled
Tue Apr 13 15:10:07 CDT 2004     Interlock SVX B1 is not enabled
Tue Apr 13 15:10:07 CDT 2004     Interlock SVX B0 is not enabled
Tue Apr 13 15:10:07 CDT 2004     Interlock ISL B4 is not enabled
Tue Apr 13 15:10:07 CDT 2004     Interlock ISL B3 is not enabled
Tue Apr 13 15:10:07 CDT 2004     Interlock ISL B5 is not enabled
Tue Apr 13 15:10:08 CDT 2004     Interlock ISL B1 is not enabled
Tue Apr 13 15:10:08 CDT 2004     Interlock ISL B2 is not enabled
Tue Apr 13 15:10:08 CDT 2004     Interlock ISL B0 is not enabled
Tue Apr 13 15:10:08 CDT 2004     Interlock L00 EAST is not enabled
Tue Apr 13 15:10:08 CDT 2004     Interlock L00 WEST is not enabled
Tue Apr 13 15:10:42 CDT 2004     IFix -  success: Silicon to STANDBY  
---------------- and more

Then ACE tried to reset and bring SVX back to standby but failed.
I came and try to bring up power with coldstart, and eventually all the trip are recovered.

The trip maybe related to the SRC work.</pre>

<!-- Date: Tue Apr 13 17:43:00 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L0 
<li>problem n: 1231 
<li>Status: fixed
<li>Type: DRO_00F3
<li>Action: Monitoring
<li>entered by: sforrest 
<li>description is: Not seen since march 28, fixed 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Apr 13 17:52:59 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3880&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3880  width='300' align='top'></a></td><td>SB0W5L3 AVDD last 100 days, call it fixed.</td></tr></table>
<!-- Author: ssf -->

<!-- Date: Tue Apr 13 17:55:04 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W5L3 
<li>problem n: 867 
<li>Status: fixed
<li>Type: AVDD
<li>Action: Incident
<li>entered by: sforrest 
<li>description is: AVDD stabel for last 100 days, see <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=191&frame=2&anchor=17:52:59'> silicon e-log entry </a> 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W5&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Apr 13 18:01:35 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W7L4 
<li>problem n: 1154 
<li>Status: fixed
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: sforrest 
<li>description is: combine with thread 1153 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W7&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Apr 13 18:23:42 2004 -->
<center><a href='/elog/notebooks/silicon/Tue_Apr_13_2004_182314.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3884' ></a><a href='/elog/notebooks/silicon/Tue_Apr_13_2004_182306.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3882' ></a></center>
<!-- Author: Lester, Marcel, Sal -->


<!-- Date: Tue Apr 13 18:26:23 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3885&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3885  width='300' align='top'></a></td><td>SB1W8L4 AVDD last 100 days, currents are normal for this ladder.  There has been no drop to ~700 mA since incident, fixed.</td></tr></table>
<!-- Author: ssf -->

<!-- Date: Tue Apr 13 18:29:31 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W8L4 
<li>problem n: 1235 
<li>Status: needs_observation
<li>Type: AVDD2
<li>Action: Diagnosis_update
<li>entered by: sforrest 
<li>description is: Currents are normal for this ladder. There has been no repeated drop in avdd since incident. see silicon  <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=191&frame=2&anchor=18:26:23'> e-log </a> for AVDD plot 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W8&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Apr 13 18:31:21 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Tue_Apr_13_2004_183115.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3887  align='top'></a></td><td>Nominal settings for vernier of clock output.</td></tr></table>
<!-- Author: Sal -->
<!-- Comment: Tue Apr 13 18;42;33 comment by...Lester, Marcel, Sal, Rong -->
<h3>SRC Testing Summary</h3>
We have measured some quantities from the phase-locked loop
in the <b><font color="red"> TEST STAND SRC</font></b>. We have the following plots with: 
<ul>
<li> Top : SY : Sync after PLL.
<li> Middle : RF from transition chip
<li> Bottom: SYNC : Sync coming from transition chip
</ul>
<b> This plot</b> is for the nominal (E) setting of the
clock fanout verniers.

The two plots <a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=191&frame=2&anchor=18:23:42'>
above</a> are for the BOUNDARIES of when sync (SY
above) goes away. That is, SY is present for vernier &#8805; 7
and &#8804; 2.
<ul>
<li> <b>THIS PLOT:</b> Nominal: Vernier = E
<li> <b>ABOVE LEFT:</b> Vernier = 7 
<li> <b>ABOVE RIGHT:</b> Vernier = 2 
</ul>

<br><br>
We examined the same measurement in the <font color="red">b0svx02 (SVX) SRC</font>. They were identical to the measurements in the test stand. 
<br><br>
We have hooked up 4 GHz timing cables to examine these quantities
plus some others in the SVX SRC in the future:
<ul>
<li> 0: RF_IN
<li> 1: SYNC from transition chip
<li> 2: VCO in SRC for PLL
<li> 3: SY : sync after clocking in
<li> 4: UP : "up" from PLL
<li> 5: DN-bar : "down" from PLL
</ul>
We ran the <b>Guinea Pigs</b> to check out our
changes, although we had <b>no firmware changes at all</b>.
Everything worked fine, so we gave the system
to the aces.
<!-- Date: Tue Apr 13 18:36:21 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W4L4 
<li>problem n: 1214 
<li>Status: fixed
<li>Type: AVDD
<li>Action: Diagnosis_update
<li>entered by: sforrest 
<li>description is: no errors seen since 03/04/04 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W4&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Apr 13 18:49:07 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W4L4 
<li>problem n: 1214 
<li>Status: needs_work
<li>Type: AVDD
<li>Action: Diagnosis_update
<li>entered by: sforrest 
<li>description is: correstion e144 has no errors because it as been out of the hwdb since 03/03/04 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W4&layer=L4">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Tue Apr 13 18;52;50 comment by...ssf -->
<pre>this was during the lost e-log time period, perhaps the PBdatabase entry was lost a well.</pre>


<!-- Date: Tue Apr 13 22:09:10 2004 -->
LostP high<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=235&frame=2&anchor=20:25:17.055'> 
elog plots </a>. CDF taking data without silicon for 2 hours.
<!-- Author: Rong -->
<!-- Comment: Tue Apr 13 22;33;10 comment by...Rong -->
<pre>After scraping by TEV experts, LostP went down to 16KHz.
Turned on the Silicon and ran.</pre>
<!-- Date: Tue Apr 13 22:25:44 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W4L3 
<li>problem n: 1227 
<li>Status: fixed
<li>Type: DropReadOut_nonRX
<li>Action: Diagnosis_update
<li>entered by: sforrest 
<li>description is: problem seen only on 03/23/04, fixed 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W4&layer=L3">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Tue Apr 13 22:53:30 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3888&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3888  width='300' align='top'></a></td><td>SB0W5L2, DVDD currents for the last 100 days.  Dvdd trip occured on david stuart day 1177, where the vertical line is.</td></tr></table>
<!-- Author: ssf -->
<!-- Comment: Tue Apr 13 23;14;02 comment by...ssf -->
<pre>A second artifact occurs on david stuart day 1152 just after noon.  A lot of calibration runs were taken during this time, but no silicon d-mode calibration. Silicon D-mode was the first time the Dvdd trip was noted. </pre>

<!-- Date: Tue Apr 13 23:16:07 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W5L2 
<li>problem n: 1225 
<li>Status: fixed
<li>Type: DVDD
<li>Action: Diagnosis_update
<li>entered by: sforrest 
<li>description is: No further trips, current history looks stable. See silicon <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=191&frame=2&anchor=22:53:30'> e-log </a> entry.    
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Apr 13 23:20:07 2004 -->
<pre>L2 w/o L1 error during 'Activate' (b0tsi00 error). 
Paged Sal and tried HRR then abort the run to cleaned EVB. 
When another new run started, 'Config' stuck at b0svx07. 
Tried vxlogin or minicom to b0svx07 but failed. Julia suggested 
to abort then reconfig again. It worked. 
Thanks for Sal, Julia and David and sorry to keep paging you and take too much your time.  
</pre>
<!-- Author: Rong -->
<!-- Comment: Wed Apr 14 04;02;33 comment by...rainer -->
<pre>normally, cleanup of EVB is not necessary. just abort the activate, do the sal manoevre (L1A, L2A, HRR from svxdaq) config one more time. there IS a chance the EVB gets hosed, but it is not  100% the case all the time.</pre>
<!-- Date: Tue Apr 13 23:21:55 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3889&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3890  width='300' align='top'></a></td><td>IMon plot for Bias current on e083</td></tr></table>
<!-- Author: Rong -->
<!-- Comment: Wed Apr 14 00;15;38 comment by...Rong -->
<pre>SVX system Power inhibit fired on SB0W8L3 bias.
But no trip alarm and no error message on either PSGui nor IFix.
The readout status on e083 bias was 
Bias(V)  V0Set(V)  I (uA)  Imax(uA)
0.0 V     94.0     1484.0   5000.0

David suggested to standby then turn on again, but the same
read back were seen.
Tried to hockerize crate 6 (SWBot Bot) but didn't help.
One weired thing is during my on/off e083, I don't see any 
message on svxinter. Even we reboot svxinter and PSGui, I 
could get message for other ladders but not e083.

-------------- before reboot, did several time of 'standby' and 'on' for e083, but no message -----
...
Sending Request for f816  (during ramping up, I think)
Sending Request for f806
Module is busy, sending code = 18
Module is busy, sending code = 18
Module is busy, sending code = 18
Module is busy, sending code = 18
Module is busy, sending code = 18
Module is busy, sending code = 18
com_int = 0
detector = 0, status = 0
detector = 2, status = 0
com_int = 0
detector = 0, status = 0
detector = 2, status = 0
com_int = 0
detector = 0, status = 0
detector = 2, status = 0

-> 
-> reboot

--------  after reboot of svxinter. before loading CAENvolts.dat, we turned off e083, but still no message.-----
 
Conf file is /mnt/autofs/cdf/people2/svxii/daq/PSanywhere/PS.conf 
$CAENCONTROL_DIR
Mapping file is $CAENCONTROL_DIR/CAEN.map
Voltage file is $CAENCONTROL_DIR/CAENvolts.dat
PowerSet file is $CAENCONTROL_DIR/powerset.dat
LV Currents file is $CAENCONTROL_DIR/CAENLVcurrent.dat
Using local rtlm 
Zap TipcSrvLmCheck 
dummy add 107db0; tipcadd 1e5914, newins 7ff2249c
Connecting to <tcp:localhost> RTlm.
Using tcp protocol.
received connection from 127.0.0.1:1026, socket is 19
Message from RTlm: Connection established.
WARNING: Internal validation failed, file: ipcmsg.c, line 1314WARNING: Internal validation failed, file: ipcmsg.c, line 1314Message from RTlm: License for <RTclient> granted (132 licenses left).
Connecting to project <cdf_daq> on <tcp:b0dap33> RTserver.
Using tcp protocol.
Message from RTserver: Connection established.Start subscribing to subject </_svxinter_15383088>.
Crate #: 1
Group Name: "GROUP00"
Crate #: 2
....
Crate #: 16
Group Name: "GROUP00"
Module is busy, sending code = 18
Module is busy, sending code = 18
Voltage file is $CAENCONTROL_DIR/CAENvolts.dat


------------------

We decided to drop this ladder, and clean the inhibit.
</pre>
<!-- Date: Tue Apr 13 23:24:07 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W4L2 
<li>problem n: 1234 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: sforrest 
<li>description is: Ocassionaly bit reporter shows a 'bad strips ADC value'  Not seen since 04/02/04.  If not seen before the 16th call it fixed. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W4&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Apr 13 23:29:20 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W5L2 
<li>problem n: 63 
<li>Status: needs_access
<li>Type: RX
<li>Action: Diagnosis_update
<li>entered by: sforrest 
<li>description is: b5 hosed, swap Rx 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Wed Apr 14 00:21:17 2004 -->
<pre>L2 w/o L1 error at new run started in the 'Activate' state. 
Reset by Svxdaq, Tsi emulator, but Busy timeout after rerun. 
Cleaned the EVB and restart, but b0fib03 failed config. 
Abort and reconfig failed. Reboot and Shepherded the crate worked. Back to running, finally. What a night!</pre>
<!-- Author: Rong -->

<!-- Date: Wed Apr 14 00:29:08 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L3 
<li>problem n: 10 
<li>Status: needs_work
<li>Type: BIAS
<li>Action: Removed_hdwdb
<li>entered by: rong 
<li>description is: Bias read back 0 V with current 1484uA. But no alarm when the voltage was gone. see<a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=191&frame=2&anchor=23:21:55'> silicon elog</a> 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Apr 14 00:29:08 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L3 
<li>problem n: 10 
<li>Status: needs_work
<li>Type: BIAS
<li>Action: Removed_hdwdb
<li>entered by: rong 
<li>description is: Bias read back 0 V with current 1484uA. But no alarm when the voltage was gone. see<a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=191&frame=2&anchor=23:21:55'> silicon elog</a> 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Apr 14 01:45:18 2004 -->
<pre> 
Messenger: processStatechange Config [0] 
SVX processConfig 
It's a fib crate 
 
 
 
	 **** 	 Not Using Broker 	 **** 
 
 
 
Exiting Loop because end of message 
Not Using Broker Right Now 
Publishing Init Config... 
Done Publishing 
Messenger: processReadoutlist 
UNIVERSE_MAST_CTL      0x15D00000 
UNIVERSE_U2SPEC        0x00000000 
UNIVERSE_U2SPEC addr   0xC14004FC 
Set FER_GLOB_Delay to 0 
Crate Id         76 
Output->EVB/VRB  0/2 
Trigger mode     0 
Verbosity:       Minimal 
  BankName         L00D  (RE 0) 
  BankId           4 
  BankType         1 
  BankVersion      0 
  MaxMiniBank      1 
  UseBLT           0 
  IgnoreBC         0 
  ReadoutList      0 
  SlotMask         0x010000 
  BankName         ISLD  (RE 1) 
  BankId           4 
  BankType         1 
  BankVersion      0 
  MaxMiniBank      1 
  UseBLT           0 
  IgnoreBC         0 
  ReadoutList      0 
  SlotMask         0x008580 
  BankName         SIXD  (RE 2) 
  BankId           1 
  BankType         1 
  BankVersion      0 
  MaxMiniBank      1 
  UseBLT           0 
  IgnoreBC         0 
  ReadoutList      0 
  SlotMask         0x002000 
 
Sent ack to Run Control: 1 READY SUCCESS  
Messenger: processStatechange Abort [0] 
Sent ack to Run Control: 1 IDLE SUCCESS  
 
 
---------- 
message on b0fib03 when I did cold start. 
</pre>
<!-- Author: Rong -->


<!-- Date: Wed Apr 14 03:06:27 2004 -->
<a href=/elog/notebooks/2004/Wed_Apr_14_2004_Owl.004259.ps align=top><img
src=/cgi/elog/elog.pl?nb=2004&action=view&page=-5054 align='top'></a>
<br> 
SVXMon with wedge wide yellow. 
 
Several wedges all point to b0fib03 which failed to start at the begining of this run, so David and I tried to reboot the b0fib03 again via vxlogin. 
But Rainer pointed out this could be 2 VRB unsync problem and should be solved when it failed to config. 
 
Went through hockerization on crate 6 again, 2nd time it worked, then we bring back e083.  
 
Tried to make sure all the crates are running correctly by cold start and svxdaq. 
 
Restart the run while carfully checking SRC error status. Run started and no yellow on SVXMon anymore. 
  
<!-- Author: Rong -->



<!-- Date: Wed Apr 14 08:23:26 2004 -->
<pre>Paged by SciCo, TevMon gave 'Silicon Danger' while B0PAGC mean went beyond 10KHz, and they put SVX to standby. I was supprised but told him that Silicon should be standby if there is error by TeVMon, and they can keep running SVX if there is no error on TeVMon. On the 8 oclock meeting, someone said that he did something on TeVMon. It should be the reason why the limit goes down from 20 to 10KHz. He will look at TeVMon setting this morning.</pre>
<!-- Author: Rong -->


<!-- Date: Wed Apr 14 09:08:43 2004 -->
<a href=/elog/notebooks/2004/Wed_Apr_14_2004_Owl.031021.ps align=top><img 
src=/cgi/elog/elog.pl?nb=2004&action=view&page=-5066 align='top'> <br>SVT readout time plot </a> 
with several auto-HRR due to  
<pre>SVXMon error: stuck cell ID S/B0/W6/L2/C5-9 </pre> 
Steve found out that we made a mistake yesterday to change 
the last chip ID of e062 from A2(34) to A1(33) chip while A1 is the chip should be choped. 
The readout time is too long for SVT, and raw data showed C2C2 on e062.
So reset the last chip back to 34 at cardEditor and chipEditor then restart the run. 
  
<!-- Author: Rong -->


<!-- Date: Wed Apr 14 09:36:47 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3891&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3892' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3893&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3894' ></a></center>
<!-- Author: Rong -->
<!-- Comment: Wed Apr 14 09;39;57 comment by...Rong -->
<pre>AVDD current histroy for e012(left) and f432(right) since day 500.
They are pinky since last yesterday data taking resumed.

e012 has ~ 760mA with setting on normal 565mA with (535,580) interval.

f432 has ~ 1190mA with setting on normal 1110mA with (1100,1120) interval.

Will consult with David on these two.</pre>

<!-- Date: Wed Apr 14 09:47:36 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W1L3 
<li>problem n: 65 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: bbrau 
<li>description is: Still see very low rate of 32nd channel (not channel 32) read out of chip a3 bit 5 low.  Continue to monitor and hope it doesn't get worse. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W1&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Apr 14 09:51:47 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W1L1 
<li>problem n: 815 
<li>Status: unfixable
<li>Type: BIAS
<li>Action: Monitoring
<li>entered by: bbrau 
<li>description is: This guy may be biased but according to thread 578 he is dead and out of data taking which makes the whole issue of bias or not moot. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B5W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Apr 14 14:41:37 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W0L0 
<li>problem n: 1222 
<li>Status: needs_study_time
<li>Type: Chip_other
<li>Action: Monitoring
<li>entered by: bbrau 
<li>description is: SVXMon shows large occupancy in chip 0 and 1, probably from analog pick-up of noise, which are most likely the source of these bumps. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B2W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Apr 14 14:44:56 2004 -->
<pre>I happened to be here during a cooling alarm and although PSGui said silicon was off (and it was), I went downstairs and turned off the 5V enables just to be safe.  I leave it to cooling experts to explain the false alarm.</pre>
<!-- Author: bbrau -->

<!-- Date: Wed Apr 14 14:48:45 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W0L1 
<li>problem n: 1107 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: bbrau 
<li>description is: Still very occasional bit errors, but fairly rare.  Watch for two more weeks and declare it  fixed. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Apr 14 14:56:30 2004 -->
Flaky ISL RTD went nuts again (CCW2-1OUT).  See <a href= 
'/cgi/elog/elog.pl?nb=2004&action=view&page=237&frame=2&anchor=14:54:44.656'> 
main elog </a>.
<!-- Author: Eva H. -->
<!-- Comment: Wed Apr 14 15;30;26 comment by...Andy H. -->
<p>We "fixed" it by disconnecting/reconnecting one of the wires that
provides the RTD excitation current (white wire connected to "I1").
Effectively, we "power-cycled" the RTD.
An interesting thing to try next time this happens would be to
disconnect/reconnect one of the wires that measures the voltage drop across the RTD [red (V1) or black (G) wire], in order to
determine whether any little "perturbation" fixes it, or whether it
really needs a "power-cycle."</p>
<p>Another piece of information that I don't know how to interpret
at the moment is that this guy seems to only act up when the silicon is OFF.</p>


<!-- Date: Wed Apr 14 17:18:41 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Wed_Apr_14_2004_171838.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3898  align='top'></a></td><td>Noise on Clock line 2</td></tr></table>
<!-- Author: SCN -->


<!-- Date: Wed Apr 14 17:19:07 2004 -->
<center><a href='/elog/notebooks/silicon/Wed_Apr_14_2004_171823.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3896' ></a><a href='/elog/notebooks/silicon/Wed_Apr_14_2004_171838.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3898' ></a></center>
<!-- Author: SCN -->
<!-- Comment: Wed Apr 14 17;32;09 comment by...SCN -->
(This time put both examples in)  <h3>Noise on BXING (and 53 Mhz too!) </h3>
I'll try to summarize what I know about the hunting down of the 
ubiquitious L2A without L1A error from the SRC.  <P>
Lester noted that there was a correlation with <i>walking on certain tiles in the 1st floor</i> and <i>SRC having a hard time 
keeping synch with the CDF Clock 53 Mhz</i>.  He3 noted this by
looking at the output of the phase lock loop, and saw that he could make it work much harder to keep synch by jumping on the floor, and
in some circumstances he could make the SRC pull CDF ERROR.  (pictures to follow, Lester/Sal can comment).  We know this sounds nuts, so we've checked it with many skeptics, and they all now believe.  <P>
We then went to examine CDF clock, and produced the two pictures above <ul>
<li> Left:  Grey is BXING from the LVDS CDF CLock cable through a differential probe with the proper 100 &Ohm; termination, and we triggered on the width of the BXING trace being out of spec.   Green is the potential difference between the Clock Fanout crate ("Crate ground") and the shield of the input signal, connected to the Clock Crate ground (on the 2nd floor)
<li> Right: Same thing (different trigger) but the 53 Mhz replaces BXING
</ul>
The theory is that there is a sizable ground bounce coincident with stepping on certain parts of the floor, which pushes at least one half of the differential signal (or more) beyond the 
threshold of the receiver, causing the noise.  <P>
We tried wiggling ever cable, the probes, and banging on the respective crates, but could not generate the effect.  Only stepping on (or off) certain tiles caused it to happen, though not every time.  Also (next pictures) problems in the clock signal may or may not correlate with problems in the SRC.  The working theory here is that the strength and origin of the noise source can cause it to couple to the either or both of the systems.  More with next pictures  <P>
Others should feel free to add their comments/corrections


<!-- Comment: Wed Apr 14 18;47;03 comment by...rainer -->
<pre>this is quite impressive, indeed. however, why is somebody jumping at the beginning of CONFIG/ACTIVATE where the problem liked to show up in the past ? what's under these tiles ?</pre>
<!-- Comment: Thu Apr 15 09;01;45 comment by...SCN -->
Please be assured we looked under the tiles, there are cables there, we wiggled and pulled them all (several times, by several different now-converted non-believers) it did not reproduce the problem. In fact, with the tile removed, we could not get the problem to reoccur at all.  There are several hot spots scattered around, so it is not one tile or one cable.
We banged on the crates to try to make a vibration there that reproduced the problem, but no effect was seen.  We saw the problem both on the clock fanout and the SRC crates, sometimes simultaneously, sometimes not.  <P>
Current theories are <ul>
<li> Static discharge on certain tiles is large when you step on them (it's been drier in the winter, so you get more static building up) causing a transient on the 1st floor
<li> Stepping on a particular tile transmits a vibration via the support grid to some current source (presumably on the back wall)
causing a transient throughout the room.
<li> Insert your theory here
</ul>
I have no experience to say that this problem likes to show up 
during CONFIG/ACTIVATE.  It is possible we are just more sensitive to the problem there, since it causes more of a recovery headache (as I understand).  Or maybe this is a different problem altogether, although yesterday we did show that jumping can produce SRC errors.  Maybe something else can too?
<!-- Date: Wed Apr 14 17:33:22 2004 -->
<center><a href='/elog/notebooks/silicon/Wed_Apr_14_2004_173304.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3902' ></a><a href='/elog/notebooks/silicon/Wed_Apr_14_2004_173255.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3900' ></a></center>
<!-- Author: SCN -->
<!-- Comment: Wed Apr 14 17;38;24 comment by...SCN -->
<h3>Correlated Grounding Problems?</h3>
Here we set up the scope to trigger on noise problems as above, and used the trigger output to trigger the logic analyzer.  The D1 is the Scope trigger, and the logic analyzer traces Label 0 and Label 2 are 53 Mhz at different parts of the SRC, and Label 5 is the response of the phase locked loop.  On the left, you can see that the clock noise problem was not correlated with any problem in the SRC, whereas on the right, you can see it was, as you can see the problems in 53 Mhz and the PLL trying hard to resynch.  You'll have to ask Lester and Sal about the exact definitions of the Labels.


<!-- Comment: Wed Apr 14 22;51;49 comment by...Lester -->
<pre>We would like to try sending 53MHz from the upstairs fanout crate
to see if a solution would be possible by migrating the clock
fanout signals upstairs. It looks like this ground instability 
is everywhere on the first floor and not present upstairs. So if 
the SRC is vulnerable to ground bounce this will not be the 
solution. The best solution is to find the origin of the ground 
bounce since it is apparently not upstairs.

A note about the traces: The errors are caused only on the upper 
right style trace. This is where the phase lock response changes
character drastically (bit 5 above). The phase lock loop logic 
could be made more robust to this behaviour. Currently the loss
or gain of an odd number of rising edges causes this to occur;
the logic defines phase in terms of a halved frequency. 
A missing rising edge makes it think it is 180 degrees out of 
phase.
</pre>
<!-- Date: Wed Apr 14 18:39:36 2004 -->
<h3>Clock Fanout Configuration</h3> 
We put the silicon clock fanout back to its original 
configuration. 
 
<table border="1"> 
 <caption align="bottom">Silicon Clock Fanout Configuration</caption> 
 <tr> <th>Slot   <th> 8  <th> 9    <th> 10   <th> 13 <th> 14 </th> </tr> 
 <tr> <th>ID     <th>058 <th> 056  <th> 033  <th>005 <th>006 </th> </tr> 
 
 <tr> <th>0A     <th>  7 <th>   6  <th>   7  <th>  E <th>  F </th> </tr> 
 <tr> <th>1A     <th>  9 <th>   A  <th>   9  <th>  B <th>  8 </th> </tr> 
 <tr> <th>2A     <th>  9 <th>   B  <th>   A  <th>  B <th>  9 </th> </tr> 
 <tr> <th>3A     <th>  9 <th>   B  <th>   9  <th>  C <th>  8 </th> </tr> 
 <tr> <th>1B     <th>  6 <th>   7  <th>   7  <th>  E <th>  E </th> </tr> 
 <tr> <th>2B     <th>  8 <th>   9  <th>   9  <th>  C <th>  8 </th> </tr> 
 <tr> <th>3B     <th>  9 <th>   9  <th>   9  <th>  8 <th>  9 </th> </tr> 
 <tr> <th>4B     <th>  8 <th>   8  <th>   8  <th>  8 <th>  8 </th> </tr> 
 
 <tr> <th> Dip0  <th>  L <th>   R  <th>   L  <th>  R <th>  L </th> </tr> 
 <tr> <th> Dip1  <th>  L <th>   R  <th>   R  <th>  L <th>  L </th> </tr> 
 <tr> <th> Dip2  <th>  R <th>   R  <th>   L  <th>  L <th>  L </th> </tr> 
 <tr> <th> Dip3  <th>  L <th>   R  <th>   L  <th>  L <th>  L </th> </tr> 
 <tr> <th> Dip4  <th>  R <th>   R  <th>   L  <th>  L <th>  L </th> </tr> 
 <tr> <th> Dip5  <th>  R <th>   R  <th>   L  <th>  L <th>  L </th> </tr> 
 <tr> <th> Dip6  <th>  L <th>   L  <th>   R  <th>  L <th>  L </th> </tr> 
 <tr> <th> Dip7  <th>  R <th>   L  <th>   R  <th>  L <th>  L </th> </tr> 
</table>
<!-- Author: Steve Chappa, Lester, Marcel, SCN, Sal -->



<!-- Date: Wed Apr 14 19:32:02 2004 -->
<h3>SRC Checkout: DAQ, No Pigs</h3> 
I have finished the SRC checkout prior to turning 
on the pigs for both SRCs. Everything is proceeding 
smoothly, no errors or hitches. Moving on 
to the pigs.
<!-- Author: Sal -->


<!-- Date: Wed Apr 14 20:47:11 2004 -->
<h3>Silicon Checkout: PIGS!</h3> 
We have run the SRC checkout procedure on the pigs in 
SVX and L00. Both have checked out and happily oinked for a while. We then brought the system to standby, and config-ed. Rong can make any relevant entries. 
<br> 
<br> 
We have completed the checkout and have handed the silicon to the aces.
<!-- Author: Sal, Rong -->
<!-- Comment: Thu Apr 15 00;51;28 comment by...Rong -->
<pre>L3 trouble when we tried to end the previous run and put the silicon in. In the end, we could only take data with silicon for 5 mins but better than none. Silicon ran well. Will see what happen at next store.</pre>


<!-- Date: Thu Apr 15 02:20:37 2004 -->
<pre>Good store #3401. LostP at 16.5KHz and no SRC error during run starting.</pre>
<!-- Author: Rong -->


<!-- Date: Thu Apr 15 02:30:04 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3903&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3904  width='300' align='top'></a></td><td>SpyMon plot checkout in the begining of the run</td></tr></table>
<!-- Author: Rong -->


<!-- Date: Thu Apr 15 04:02:34 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3905&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3906' ></a><br><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3907&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3908' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3909&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3910' ></a></center>
<!-- Author: Rong -->
<!-- Comment: Thu Apr 15 04;03;27 comment by...Rong -->
<pre>IMon plot after the TeV quench. Several ladders triped.
</pre>


<!-- Date: Thu Apr 15 04:08:06 2004 -->
<pre>kicker pre-fire on Tevatron.  
120~130 Rad/s for all 4 Loss monitor. 
During post-quench checkout, ACE failed to config b0fib06 due to  
 
(MLE) b0fib06:Messenger:3:38:22 AM->Error Initializing HDI Slot 17 Chan 8: SVX B5W5 
 
After several try on abort/config, I could bring the system through cold start. (once has SRC error)</pre>
<!-- Author: Rong -->
<!-- Comment: Thu Apr 15 04;21;31 comment by...Rong -->
<TABLE bgcolor=#cdc9a5> <TR><TH>Date</th><th>Time</th><th>BLM</th><th colspan=2>Dose</th></tr> <tr><td>2004.04.15</td><td>04:12:43</td><td>W Inner BLM</td><td>170.20</td><td>RADS</td></tr> <tr><td>2004.04.15</td><td>04:12:43</td><td>W Outer BLM</td><td>183.46</td><td>RADS</td></tr> <tr><td>2004.04.15</td><td>04:12:43</td><td>E Inner BLM</td><td>201.68</td><td>RADS</td></tr> <tr><td>2004.04.15</td><td>04:12:43</td><td>E Outer BLM</td><td>166.85</td><td>RADS</td></tr> </table> <strong>Integrated dosage</strong>

<pre>Dose table by Olga in </pre><a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=239&frame=2&anchor=04:16:59.396'>
shift elog </a>
<!-- Comment: Thu Apr 15 04;31;50 comment by...Rong -->
<pre>
Duing cold start, there was once the b0fib06 didn't response on RC command. Tried soft reboot on b0fib06 to bring it back.</pre>
<!-- Date: Thu Apr 15 04:11:03 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3913&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3914  width='300' align='top'></a></td><td>AVDD current history of SB5W5L3. 
After quench, current drop from 820 to 505 and failed config. 
The difference indicated 4 chips lost. 
After retry, it came back.</td></tr></table>
<!-- Author: Rong -->


<!-- Date: Thu Apr 15 04:12:20 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3915&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3915' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3916&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3916' width='300'></a></center>
<!-- Author: Rong -->
<!-- Comment: Thu Apr 15 04;14;12 comment by...Rong -->
<pre>SB0W5L3, e053 (left plot) has current changed from 790 down to 625mA (2chips?)

SB3W2L0, e320 (right plot) has current changed from 212 up to 362mA (2 chips?)

Although they pass cold start, but need to check the data by Svxdaq.</pre>


<!-- Comment: Thu Apr 15 05;03;23 comment by...Rong -->

e053 has AVDD2 history, see
<a href='http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W5&layer=L3'> problem DB </a>
Current drop after every quench incident and recoverd by itself.

<!-- Date: Thu Apr 15 04:15:04 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3917&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3918' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3919&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3920' ></a></center>
<!-- Author: Rong -->
<!-- Comment: Thu Apr 15 04;16;15 comment by...Rong -->
<pre>A special case. SB4W0L0, e400 has current change of AVDD(left) from 348 down to 316 mA; DVDD(right) from 73 up to 108 mA. Need quiet time.</pre>





<!-- Date: Thu Apr 15 05:30:26 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3921&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3922' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3923&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3924' ></a></center>
<!-- Author: Rong -->
<!-- Comment: Thu Apr 15 05;31;59 comment by...Rong -->
<pre>Data taken under Svxdaq for e553(left) and e400(right).
They look ok. Then e400 needs to have IMon current setting changed.</pre>


<!-- Date: Thu Apr 15 05:51:14 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3925&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3926' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3927&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3928' ></a></center>
<!-- Author: Rong -->
<!-- Comment: Thu Apr 15 05;55;58 comment by...Rong -->
Data taken under Svxdaq.

Left are e053. By setting R driver 7, we could readout 6 chips then get c2c2.

Right are e320. Garbage data on z side. It pretty much like the situation we already know in 
<a href='http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B3W2&layer=L0'> problem database</a>, but don't know why we have current jump. Maybe just front-end setting on z side chips are changed.

<!-- Date: Thu Apr 15 07:51:45 2004 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 327
Calibration type  : standard
Run period tag    : Apr_2004
DPS-off run       : 181706
DPS-on run        : 181705
Requested by      : Shabnaz
Main process id   : 97396414
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->


<!-- Date: Thu Apr 15 08:37:37 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W5L3 
<li>problem n: 1238 
<li>Status: needs_observation
<li>Type: AVDD2
<li>Action: Incident
<li>entered by: dkclark 
<li>description is: Drop in current, 820->505mA, and init failures after kicker prefire incident. Recovered after a few configs. Watch for return of symptoms. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B5W5&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Apr 15 08:40:14 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3929&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3929' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3930&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3930' width='300'></a></center>
<!-- Author: rainer -->
<!-- Comment: Thu Apr 15 08;41;37 comment by...rong,rainer -->
<pre>left is quiet time dmod DPS OFF after the COT shutdown checkout, right is quiet time dmod DPS OFF after abort kicker prefire.</pre>


<!-- Comment: Thu Apr 15 09;10;25 comment by...rainer -->
<pre>e4a3 giving errors on z side chips in DPS OFF </pre>
<!-- Date: Thu Apr 15 08:42:31 2004 -->
<center><a href='/elog/notebooks/silicon/Thu_Apr_15_2004_084157.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3932' ></a><a href='/elog/notebooks/silicon/Thu_Apr_15_2004_084216.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3934' ></a></center>
<!-- Author: rainer -->
<!-- Comment: Thu Apr 15 08;43;49 comment by...rainer -->
svxmon plots sfor cosmics run after checkout run 181707.

<!-- Date: Thu Apr 15 08:47:59 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W5L3 
<li>problem n: 867 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: Incident
<li>entered by: dkclark 
<li>description is: <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=191&frame=2&anchor=04:12:20'> Current drop from 790->625mA</a> after kicker prefire. Looks like z side is lost again as seen in <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=191&frame=2&anchor=05:51:14'> svxdaq plots</a>. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W5&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Apr 15 09:01:33 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W2L0 
<li>problem n: 1239 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: Incident
<li>entered by: dkclark 
<li>description is: <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=191&frame=2&anchor=04:12:20'> AVDD current increased from 212->362mA</a> after kicker prefire. The z-side is still lost. If there are no errors during data taking, then change IMON limits accordingly. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B3W2&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Apr 15 09:06:23 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W0L0 
<li>problem n: 1240 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Incident
<li>entered by: dkclark 
<li>description is: <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=191&frame=2&anchor=04:15:04'> Current changes after kicker prefire incident</a>; AVDD went from 348->316mA, and DVDD moved from 73->108mA. <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=191&frame=2&anchor=05:30:26'> Data looks fine in svxdaq</a>. Keep an eye on it during data taking. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B4W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Thu Apr 15 09:11:05 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3935&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3936  width='300' align='top'></a></td><td>IMON snapshot of pinkies caused by kicker prefire.</td></tr></table>
<!-- Author: David -->


<!-- Date: Thu Apr 15 09:56:50 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Thu_Apr_15_2004_095646.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3938  align='top'></a></td><td>SVXDAQ plots of SB0W1L2 show that z side has returned. The ladder is biased and run in NN mode for these plots. Data also looked fine in RA mode.</td></tr></table>
<!-- Author: David -->

<!-- Date: Thu Apr 15 09:59:27 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W1L2 
<li>problem n: 2 
<li>Status: needs_maintenance
<li>Type: AVDD2
<li>Action: Incident
<li>entered by: dkclark 
<li>description is: AVDD current jumps from 565->760 after <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=191&frame=2&anchor=04:08:06'> kicker prefire incident</a>. <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=191&frame=2&anchor=09:56:50'> SVXDAQ plots </a> show z side has returned and looks perfectly healthy. Suggest unchopping z side in HDWDB (don't forget the rdrivers). 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Apr 15 10:02:16 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3939&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3940  width='300' align='top'></a></td><td>AVDD current of SB0W1L2 shows a flakey AVDD2 failure type.</td></tr></table>
<!-- Author: David -->


<!-- Date: Thu Apr 15 12:18:49 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Thu_Apr_15_2004_121837.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3942  align='top'></a></td><td>e133: Note channels 256 to 384  (chip 87) on the bottom right plot shows high occupancy on the first ~40 channels and little to nothing on the rest of the chip.  Also noticed only digital noise when in read all mode.  For these plots svxdaq was in  NN mode and the ladder was biased.        </td></tr></table>
<!-- Author: Jared, David -->


<!-- Date: Thu Apr 15 15:23:39 2004 -->
<h3>crowbar swap fest</h3> 
after being spotted by Ben and Chris, we had the opportunity to go in and replace all of the crowbars on the following ladders:<br> 
<ul> 
<li>LB0W0 
<li>LB0W1 
<li>LB0W4 
<li>LB1W0 
<li>LB1W1 
<li>LB1W2 
<li>LB1w5 
</ul> 
In all cases, it was found that at least one channel on the crowbar had failed. In all but one case, bias31 channel had failed. <br> 
We installed new crowbars and verified that all channels were okay. 
<br> 
<b>after today's exercise, we have zero spare crowbars. </b>
<!-- Author: reid, jared, and david -->
<!-- Comment: Thu Apr 15 19;30;39 comment by...bbrau -->
<pre>Is it possible to salvage the good fuses from the crowbars we removed to make spares?
</pre>

<!-- Date: Fri Apr 16 10:21:56 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W0L3 
<li>problem n: 1223 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: Diagnosis_update
<li>entered by: bbrau 
<li>description is: This is one of the guys which had a crowbar blown.  See  <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=191&frame=2&anchor=15:23:39'> crowbar fest</a>. Monitor these guys to confirm physics is seen again. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=L00&wedge=B1W0&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Apr 16 11:47:29 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W5L3 
<li>problem n: 1241 
<li>Status: needs_study_time
<li>Type: BIAS
<li>Action: Monitoring
<li>entered by: bbrau 
<li>description is: ADCMon chip 2 looks unbiased since at least run 167954 - no physics.  siHitAnalyzer ntuples made including runs as early as 160663 hit-on-track occupancy very low and charge looks sick (definately not landau - more like exponential decay).  Probably not crowbar since chip 1 has data and they share a bias line. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=L00&wedge=B0W5&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Apr 16 11:49:23 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W2L3 
<li>problem n: 1242 
<li>Status: needs_work
<li>Type: BIAS
<li>Action: Monitoring
<li>entered by: bbrau 
<li>description is: ADCMon chip 1 looks unbiased since at least run 167954 - no physics. siHitAnalyzer ntuples made including runs as early as 160663 hit-on-track occupancy very low and charge looks sick (definately not landau - more like exponential decay). Probably not crowbar since chip 2 has data and they share a bias line. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=L00&wedge=B0W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Apr 16 13:26:09 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3945&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3946  width='300' align='top'></a></td><td>SB1W1L4 AVDD current for last 100 days has seen a couple of small increases. No problems in data though.</td></tr></table>
<!-- Author: David -->

<!-- Date: Fri Apr 16 17:51:24 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W0L1 
<li>problem n: 1183 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: bbrau 
<li>description is: Looks like the rdriver change fixed the bit 0 low problem.  Monitor it again in two weeks. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B3W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Apr 16 18:02:33 2004 -->
<h3>SRC Checkout : NO PIGS</h3> 
We have installed new firmware for the Master Clock in 
both SRCs (Dopey on svx02 and the Prince on svx06). 
The old firmware was MC31, and we have now installed 
MC35. There is some question as to the differences 
between 31 and 34, since those are lost in the days 
of pre-historic SRC development when no records really 
existed (or could exist). Lester thinks there are only 
LA ports, but one cannot be sure. 
<br><br> 
There is a change in MC35 relative to the others, however, 
in that we implemented a different version 
of the PD for the PLL in the master clock file. The 
old design is 
<a href="http://harv11.fnal.gov/~rappocc/src/psfiles/mastclk/phase_det.ps"> type 4</a>, and the new design is 
<a href="http://harv11.fnal.gov/~rappocc/src/psfiles/mastclk/mc_type3.ps"> 
type 3</a>.  
<br><br> 
The major difference is that the PLL seems to be pulling harder 
than previously. It is also supposed to be less sensitive to 
losing a clock tick or two. 
<br><br> 
The SRC checkout pre-pigs went without a hitch. There is 
one curious feature of the new firmware. The LED in the front 
of the SRC that tells you the PLL is in lock no longer functions 
properly. It is always red, since UP and DN-bar are so strong. 
This does not mean the SRC is out of sync. I'll have to think 
about how to fix that so the LED knows about the new PLL.
<!-- Author: Lester, Sal, Marcel, Rainer, SCN -->
<!-- Comment: Fri Apr 16 20;26;47 comment by...Sal, Marcel, Rainer -->
<h3>SRC Checkout : PIGS</h3>
NET/b0fib04 power rack had a fan failure, causing
us a few hours of headache. We got the pigs  up and
running. The configuration is
COSMICS_SILIPIGS_TAPE in RC. The aces are instructed to
perform some transitions throughout the night.
<br><br>
Other than that, the checkout went smoothly. We even
did some RIVERDANCING downstairs, which caused the ground
on the oscilliscope to go crazy, but the differential
clock was fine. We did not get any problems with the PLL.
<br><br>
We are still on the "downstairs" clock for now. The aces should
page me if there are problems.
<!-- Date: Fri Apr 16 18:08:12 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Fri_Apr_16_2004_180808.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3948  align='top'></a></td><td>Here is the outputs of the new SRC PLL. See below.</td></tr></table>
<!-- Author: Sal -->
<!-- Comment: Fri Apr 16 18;12;00 comment by...Sal -->
These ports are:
<ul>
<li> 0: 53 MHz before PLL
<li> 2: 53 MHz after PLL
<li> 4, 5: UP, DN-bar
</ul>

The response of the PLL (4,5 = UP,DN) is much more stable
than in the past. This will make this PLL more robust
than the other.


<!-- Date: Fri Apr 16 18:14:06 2004 -->
<h3> fib crate trip</h3> 
SVX NET just tripped with a fan failure messsage. 
No one was doing anything on this crate ... <br> 
crate was reset, now waiting the usual 10 minutes  
<!-- Author: Rainer, Marcel -->
<!-- Comment: Fri Apr 16 18;36;22 comment by...Rainer,Marcel -->
<pre>crate came back without problems</pre>

<!-- Comment: Fri Apr 16 19;34;32 comment by...Rainer, Marcel, Sal -->
Tripped off again. Same deal. It took two times to bring
it back to life.

<!-- Comment: Fri Apr 16 19;42;34 comment by...no way -->
<pre>maybe this is due to the fact, that the crate has its test fifo not enabled</pre>

<!-- Comment: Fri Apr 16 20;14;35 comment by...rainer -->
<pre>disabled respective  CAEN crate #9,10 in CAEN.map 
making the first line in CAEN.map 11111111111111110 to 11111111001111110 to continue guniea pig checkout.
</pre>


<!-- Date: Fri Apr 16 20:18:14 2004 -->
<center><a href='/elog/notebooks/silicon/Fri_Apr_16_2004_201722.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3950' ></a><a href='/elog/notebooks/silicon/Fri_Apr_16_2004_201737.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3952' ></a></center>
<!-- Author: rainer -->
<!-- Comment: Fri Apr 16 20;19;48 comment by...rainer -->
<pre>lester mentioned he could not get the SRC into error by making marcel and sal jump around. they think it is related to humidtiy which makes surfaces more conducitive ....  I figure whether they actually have their test fifos enabled ...</pre>



<!-- Date: Fri Apr 16 20:39:13 2004 -->
<P><big>Weekly Monitoring Report</big></p> 
 
This has been an eventful week.  Wednesday, while I was getting Chris Hill to give me a tutorial in daqana, we discovered a number of L00 narrows which had no physics data.  We determined that they had blown crowbars and they were replaced Thursday.  They all need to be checked carefully when we get data again to confirm that they have physics again (with ADCMon, go to the plots2 link and check each chip).  The list of them is: 
<P> 
f803 chips 1,2 <BR> 
f813 chips 1,2 <BR> 
f843 chips 1,2 <BR> 
fa03 chips 1,2 <BR> 
fa13 chips 1,2 <BR> 
fa23 chips 1,2 <BR> 
fa53 chips 1,2 <BR> 
<P> 
The crowbars blew Feb 26, probably due to a quench which terminated run 179385, although there is no way to know for sure. 
<BR> 
During my investigation of this I found two others which have had no physics data since at least early 2003 and probably aren't biased, but I am still looking back earlier in time to find when they lost bias somewhere inside the bore where we can't get to.  Both share bias with another narrow which has physics so the problem is most likely a jumper inside the detector.  They are: 
<P> 
f823 <BR>  
f853  <BR> 
 
<P> 
Finally, ADCMon list ToDo list seems to be broken.  It isn't auto-updating, and Chris helped me update it manually while he was here.  Now I tried to check off a few runs, and they seem not to get checked off.  I will investigate this soon, but for now, let's just try to look at three runs each day and shifter keep track of what you have looked at. 
<P> 
 
 
  
<!-- Author: bbrau -->


<!-- Date: Fri Apr 16 21:06:59 2004 -->
<b> on SOC </b> 
currently, the SOC is running as a guinea pig. it is enabled as hdi f231 and masked online in the HWDB. logging through the SEB, it appears in the data stream: 
<pre> 
run 181789 
0021220 f231 47fc 851d 001a 0113 021f 0317 0413 
0021240 050e 0612 0710 080e 090d 0a07 0b08 0c0e 
0021260 0df3 0e0c 0ff3 100d 1107 1202 1307 1404 
0021300 150a 1607 1707 1806 1903 1a07 1bf3  
</pre> 
in the current run 181795. hdi f231 is reported by SVXMon as missing HDI. it does not seem to make it into SVXMon. either 
there does not exist any calibration for this HDI and SVXMon drops in in this case, or it is on some shitlist in SVXMon to be ignored.<p> 
in the data stream, there is actually some data: 
<pre> 
 f231 
0604640 00fc 853f 00f3 1403 1506 1603 24f3 2504 
0604660 26f3 7504 7604 7705 7802 7bf3 7c05 7d02 
0604700 843f 3bf3 3c04 3df3 43f3 4404 45f3 7b03 
0604720 7c06 7d04 7e06 7ff3 833f 00f3 0107 0209 
0604740 030e 040f 050e 0612 0717 0812 0914 0a10 
0604760 0b14 0c0d 0d11 0e11 0f0c 100e 1112 1210 
0605000 130c 140d 150c 1610 170f 1809 190d 1a0b 
0605020 1b09 1c09 1d0e 1e0c 1f09 2008 210a 220f 
0605040 230b 2409 250e 2609 2708 2804 2908 2a09 
0605060 2b07 2c08 2d07 2e06 2f06 3007 3106 3205 
0605100 3309 3406 3506 3602 3706 3806 3904 3a05 
0605120 3b06 3c06 3d04 3ef3 3f04 4006 41f3 4203 
0605140 4304 44f3 5101 5205 53f3 a23f a13f a03f 
0605160 7ff3 c1c1 0000 
</pre> 
  
<!-- Author: rainer -->
<!-- Comment: Fri Apr 16 21;16;48 comment by...rainer -->
furthermore, the SOC does not respond to general power ON commands from ifix or gui. it stays standby.


<!-- Comment: Fri Apr 16 21;23;47 comment by...rainer -->
<pre>enabled HDI e171 (SOC's power supply channel) just to see whether this makes any difference, but does not.</pre>


<!-- Date: Fri Apr 16 21:27:42 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3953&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3953  width='300' align='top'></a></td><td>no ISL HDI appearing (ie. no f231 SOC) 
</td></tr></table>
<!-- Author: rainer -->


<!-- Date: Fri Apr 16 22:04:02 2004 -->
<h2> current state of affairs </h2> 
<li> guinea pigs e481, f840, e0b1, f321 (SOC) enabled in hwdb - include b0fib03,fib00, fib06 to run them. 
<li> kill switches currently disabled to avoid Ace operator errors. 
<li> b0evb19 excluded from the EVB so b0svx02 can be power cycled. 
<li> b0fib04 has persistent fan failure. CAEN.map modified to exclude it. 
<li> guinea pigs ran fine for 90min.  
<li> SOC does not respond to IFIX and PSGui global commands - also SVXMon does not show any data athough HDI is in data stream.  
<!-- Author: rainer -->


<!-- Date: Sat Apr 17 09:26:49 2004 -->
Tevatron quench at F4 this morning. See <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=246&frame=2&anchor=08:41:10.121'> 
shift elog </a> . 
No cold start when ACE did post quench checkout due to Silicon 
is off.
<!-- Author: Rong -->
<!-- Comment: Sat Apr 17 09;27;33 comment by...Rong -->
<pre>From MCR elog:
09:07:39-  
Several TeV ion pumps tripped with the quench.  
At A1: IP1A and IP1B.  
At F4: IP8U, IP8D, and IP9.
 - Amanda
-- Sat Apr 17 09:09:05 comment by...Amanda --  The pumps turned on ok and vacuum is looking good. </pre>


<!-- Date: Sat Apr 17 10:43:57 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sat_Apr_17_2004_104352.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3959  align='top'></a></td><td>CDF clock at front panel of SRC. From downstairs is Chan2, 
from upstairs is channel 3.</td></tr></table>
<!-- Author: Lester -->


<!-- Date: Sat Apr 17 10:46:31 2004 -->
<center><a href='/elog/notebooks/silicon/Sat_Apr_17_2004_104531.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3961' ></a><a href='/elog/notebooks/silicon/Sat_Apr_17_2004_104319.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3955' ></a></center>
<!-- Author: Lester -->
<!-- Comment: Sat Apr 17 10;55;03 comment by...Lester -->
<pre>These are scope traces of single sides of the LVDS coming to 
the SRC's at b0svx02. I want to see the relative timing of
the new signals coming from upstairs to those down here. It looks
like the upstairs signals arrive 5 ns later than the 'original' 
ones. 

Vernier settings on the downstairs 53 MHz are 'F' and left.
Vernier settings on the upstairs 53 MHz are 'E' and right.

(Not as relevant but beam structure settings on downstairs are
7,9,9,9 and upstairs are 8,8,8,8)

To get them aligned we need to take the upstairs settings back by 
5ns which means setting upstairs to 9 on 53MHz and 
(3,3,3,3) on beam structure.
</pre>

<!-- Comment: Sat Apr 17 11;05;45 comment by...Lester -->
<pre>Correction. It appears that the beam structure fanout has two ns
per tick on the dial. Needs to be set to 5555 left.

</pre>

<!-- Comment: Sat Apr 17 11;11;01 comment by...Lester -->
<pre>Settled on 6666 right
</pre>


<!-- Date: Sat Apr 17 11:15:12 2004 -->
<center><a href='/elog/notebooks/silicon/Sat_Apr_17_2004_111502.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3965' ></a><a href='/elog/notebooks/silicon/Sat_Apr_17_2004_111447.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3963' ></a></center>
<!-- Author: Lester -->
<!-- Comment: Sat Apr 17 11;16;03 comment by...Lester -->
<pre>After adjusting upstairs fanout to match downstairs at front panel
of SRC: left is 53MHz (this one is the important one to match) and
right is CDFCLK.</pre>


<!-- Comment: Sat Apr 17 15;54;09 comment by...rainer -->
<pre><h2> reminder to ourselves </h2> the clock crate was changed, too. we have to make sure the timing is still at the right place, from data. landau peaks before and after the clock change would do it.</pre>
<!-- Date: Sat Apr 17 11:36:20 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sat_Apr_17_2004_113612.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3967  align='top'></a></td><td>Humidity for the last month.  
I couldn't figure out how else to do this.</td></tr></table>
<!-- Author: Sal -->
<!-- Comment: Sat Apr 17 12;03;41 comment by...rainer -->
<pre>well, you just have your test fifo enabled, otherwise there is no way.</pre>


<!-- Date: Sat Apr 17 12:09:12 2004 -->
<center><a href='/elog/notebooks/silicon/Sat_Apr_17_2004_120820.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3969' ></a><a href='/elog/notebooks/silicon/Sat_Apr_17_2004_120833.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3971' ></a><a href='/elog/notebooks/silicon/Sat_Apr_17_2004_120843.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3973' ></a><a href='/elog/notebooks/silicon/Sat_Apr_17_2004_120852.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3975' ></a></center>
<!-- Author: Sal -->
<!-- Comment: Sat Apr 17 12;13;19 comment by...Sal -->
<pre>Broken down by weeks.</pre>

<!-- Comment: Sat Apr 17 12;14;55 comment by...rainer -->
<pre>when you click on the icicle link, open it up on your own browser. the print  to ps. file.</pre>


<!-- Date: Sat Apr 17 12:25:49 2004 -->
<pre>We ran a guinea pig in svxdaq with the SRC with the upstairs clock 
fanout. We are trying to get set up to run the pigs with the  
cosmics.  
</pre>
<!-- Author: Lester -->


<!-- Date: Sat Apr 17 13:30:28 2004 -->
<h3>Silicon Guinea Pig Configuration</h3> 
We have standing instructions with the shift crew 
to run COSMIC_SILIPIGS_TAPE whenever possible to 
test the guinea pigs. In this configuration, only the 
silipigs should be in the HWDB. 
 
<br><br> 
Also, we have created a beam configuration including the  
silicon guinea pigs only. It is called 
AAA_SILIPIGS. If possible, we ask the shift crew to use 
this when taking data. 
 
<br><br> 
Both configurations include all the VRB crates, and FIB_ISL_03, 
FIB_SVX_00, and FIB_SVX_06.  
 
<br><br> 
We are running the b0svx02 SRC with the clock fanout from 
the <b>second floor</b>. We must check any data we have with this 
configuration to be sure it is good for physics. 
 
<br><br> 
We have instructed the pager carrier to page Sal (722-7599) 
and Marcel (218-9520) if any SRC-related problems arise.
<!-- Author: Lester, Sal, Rong -->



<!-- Date: Sat Apr 17 16:03:05 2004 -->
<b> after the fan action  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=246&frame=2&anchor=10:24:25.788'> 
this </a> 
morning, b0fib04 cannot be talked to via vxlogin.power cycle of crate does not help. CAENs are happy however. can talk to the CPU via minicom. on reboot, CPU gets stuck on reboot -  
</b>
<pre> 
]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]                                        ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]                                         ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]                                               ]]]]]]]]]]]  ]]]]     ]]]]]]]]]]       ]]              ]]]]         (R)    ]     ]]]]]]]]]  ]]]]]]     ]]]]]]]]       ]]               ]]]]                ]]     ]]]]]]]  ]]]]]]]]     ]]]]]] ]     ]]                ]]]]                ]]]     ]]]]] ]    ]]]  ]     ]]]] ]]]   ]]]]]]]]]  ]]]] ]] ]]]]  ]]   ]]]]]    ]]]]     ]]]  ]]    ]  ]]]     ]] ]]]]] ]]]]]]   ]] ]]]]]]] ]]]] ]]   ]]]]      ]]]]]     ]  ]]]]     ]]]]]      ]]]]]]]] ]]]]   ]] ]]]]    ]]]]]]]    ]]]]     ]]]]]]      ]]]]]     ]]]]]]    ]  ]]]]]  ]]]]   ]] ]]]]    ]]]]]]]]    ]]]]    ]]]]]]]    ]]]]]  ]    ]]]]]]  ]    ]]]   ]]]]   ]] ]]]]    ]]]] ]]]]    ]]]]   ]]]]]]]]  ]]]]]  ]]]    ]]]]]]]      ]     ]]]]]]]  ]]]]    ]]]]  ]]]] ]]]]]    ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]                                                  ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]       Development System                          ]]]]]]]]]]]]]]]]]]]]]]]]]]]]                                                    ]]]]]]]]]]]]]]]]]]]]]]]]]]]       VxWorks version 5.3.1                         ]]]]]]]]]]]]]]]]]]]]]]]]]]       KERNEL: WIND version 2.5                       ]]]]]]]]]]]]]]]]]]]]]]]]]       Copyright Wind River Systems, Inc., 1984-1997                                                                                                                 CPU: Motorola MVME2300 - MPC 603p.  Processor #1.                              Memory Size: 0x1000000.  BSP version 1.1/4b.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       Unable to open startup script boot/front-end/startup.all.flash 
-> i                                                                                                                                                              NAME        ENTRY       TID    PRI   STATUS      PC       SP     ERRNO  DELAY ---------- ------------ -------- --- ---------- -------- -------- ------- ----- tLogTask   logTask        efbd90   0 PEND         29e5a8   efbcc8       0     0 tExcTask   excTask        efe708   0 PEND         29e5a8   efe630       0     0 tShell     shell          ed2d88   1 READY        288278   ed2a10       0     0 tRlogind   rlogind        ed9898   2 PEND         2848b4   ed94d8       0     0 tAioIoTask1aioIoTask      eee678  50 PEND         284d28   eee5d0       0     0 tAioIoTask0aioIoTask      ee7470  50 PEND         284d28   ee73c8       0     0 tNetTask   netTask        edd088  50 PEND         2848b4   edcfd8       0     0 tAioWait   aioWaitTask    ef5880  51 PEND         2848b4   ef5728       0     0 tPortmapd  portmapd       ed8308 100 PEND         2848b4   ed8198      16     0 value = 0 = 0x0                                                                 ->  
 
 
</pre> 
my suspicion is that the ethernet cable is not plugged in. 
<!-- Author: rainer -->


<!-- Date: Sat Apr 17 18:20:09 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sat_Apr_17_2004_182005.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3977  align='top'></a></td><td>SOC is biased. red is bias on, black is bias off.</td></tr></table>
<!-- Author: rong,rainer -->


<!-- Date: Sat Apr 17 18:22:50 2004 -->
<b> L1DONE error and SRC FATAL error</b> in silipigs cosmics running this 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=247&frame=2&anchor=17:19:55.698'> 
afternoon </a> 
 
  
<!-- Author: rainer -->


<!-- Date: Sat Apr 17 21:25:34 2004 -->
<b> silipigs running </b> in this store #3414, starting 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=247&frame=2&anchor=21:18:40.832'> 
here </a>
<!-- Author: rainer -->
<!-- Comment: Sat Apr 17 21;31;14 comment by...rong, rainer -->
<pre>checked the LA downstairs - appears to not be running the standard  
setting for catching the L2 w/o L1  problem. paged sal but now answer yet. leave it as is.</pre>


<!-- Date: Sun Apr 18 17:10:17 2004 -->
<pre>I changed the cables over to the downstairs fanout on svx02.  
The first run is 181854. 
</pre>
<!-- Author: Lester -->

<!-- Date: Sun Apr 18 17:25:20 2004 -->
<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 327 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 181706
DPS-on run       : 181705
Requested by     : Shabnaz
Submitted        : 2004-04-15 07:50:46
Completed        : 2004-04-18 17:24:31
Status           : FAILURE

Last processing stage reported : calculating DPS-off pedestals
Failure diagnostics :
child process exited abnormally
</pre>
<!-- Author: D-mode script  -->
<!-- Comment: Sun Apr 18 17;53;20 comment by...Jason -->
There is no problem here; I am testing some new scripts.


<!-- Date: Sun Apr 18 20:27:01 2004 -->
<h2> silicon revived </h2> 
<li> clock is back to 1st floor clock fanout (by lester) 
<li> pigs are taken offline, whole silicon on standby 
<li> awaiting to take some cosmics during quiet 
<p> 
<h2> program for upcoming store: </h2> 
<li> take a dmod calibration 2hours after beginning of store 
<li> run in data taking for another 2 hours 
<li> then exclude silicon from readout and put to standby for the rest of the store.  
<!-- Author: rong, rainer -->


<!-- Date: Sun Apr 18 20:56:43 2004 -->
<pre><b> just as we could start our cosmics checkout </b> 
ISL_TE_CCW2L6_1OUT acting up again. Mircea is coming in to have a look at this sensor.</pre>
<!-- Author: rong,rainer -->
<!-- Comment: Sun Apr 18 21;01;59 comment by...rainer -->
of course, this guy tripped off the whole silicon again. we should disable or mask this flaky sensor.

<!-- Comment: Sun Apr 18 23;54;58 comment by...Andy H. -->
<p>The sensor had fixed itself by the time Mircea arrived, and we
tried powering the silicon again.  Again, everything was fine for about 10 minutes, then ISL_TE_CCW2L6_1OUT shot up and tripped everything off again.</p>
<p>
We have two choices.  One, we mask this RTD out of the interlock code as we have done in the past (requires signoffs from SPL and Ops Head).  Or, we disconnect this RTD (the interlock code ignores disconnected RTDs automatically).

<!-- Comment: Mon Apr 19 00;52;38 comment by...Andy H. -->
We decided to disconnect the RTD.


<!-- Date: Mon Apr 19 01:15:59 2004 -->
After disconnecting RTD, silicon turned to STBY and cold-started.
<!-- Author: Andy H. -->


<!-- Date: Mon Apr 19 08:21:49 2004 -->
The plan was to have 2 hours beam data in the mid of run. But due to the bad beam condition and hardware problem on "a separator that is sparking", see
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=251&frame=2&anchor=03:42:11.379'> 
shift elog </a>, we didn't have a chance to do that. Should try again in next store.
<!-- Author: Rong -->

<!-- Date: Mon Apr 19 08:32:50 2004 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 328
Calibration type  : standard
Run period tag    : Mar_2004
DPS-off run       : 179932
DPS-on run        : 179931
Requested by      : Jason
Main process id   : 108951083
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->


<!-- Date: Mon Apr 19 08:42:31 2004 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 329
Calibration type  : standard
Run period tag    : Apr_2004
DPS-off run       : 181224
DPS-on run        : 181223
Requested by      : Jason
Main process id   : 111347159
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->



<!-- Date: Mon Apr 19 09:07:49 2004 -->
<li>Cryo reset b0fib04 crate to put the software protection trip back since the fan has been fixed. 
 
<li>taking cosmics data without COT HV. 
 
<li>May not have collision during day time, should check the Tevatron's plan and schedule.
<!-- Author: Rong -->


<!-- Date: Mon Apr 19 09:13:26 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3978&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3979  width='300' align='top'></a></td><td>e053 AVDD current plot</td></tr></table>
<!-- Author: Rong -->
<!-- Comment: Mon Apr 19 09;16;20 comment by...Rong -->
e053 lost z side chips due to AAK1 kicker prefire,<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=191&frame=2&anchor=04:12:20'>
see elog </a>.
It came back and current jump back to 790 after two days silicon off but lost z side again when we start to prepare the cosmic data running.

<!-- Date: Mon Apr 19 09:20:29 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W5L3 
<li>problem n: 867 
<li>Status: needs_observation
<li>Type: AVDD2
<li>Action: Incident
<li>entered by: rong 
<li>description is: The AVDD current jump back to 790 after 2 days silicon off but drop again right before the cosmics started. <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=191&frame=2&anchor=09:13:26'> see elog </a>  
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W5&layer=L3">report</a></ul>
<!-- Author: Problem DB -->