<!-- Title: 13:33:28  Mon Feb 24 2003 -->
<!-- Crewchief: Steve (pager) -->
<!-- Op1: Jason (weekend pager) -->
<!-- Op2: everybody else -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<ul> 
<li> Stack and Store 
<li> Access tuesday 
<li> more stack and store 
</ul>


<!-- Date: Mon Feb 24 13:39:31 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1604&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1604  width='300' align='top'></td><td>Store 2271 starts, SVT looks good</a></td></tr></table>
<!-- Author: SCN -->

<!-- Date: Mon Feb 24 14:06:22 2003 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 238 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 159263
DPS-on run       : 159262
Requested by     : Luis
Submitted        : 2003-02-24 02:54:43
Completed        : 2003-02-24 12:04:46
Status           : FAILURE

Last processing stage reported : combining ROOT files
Failure diagnostics :
Received SIGTERM. Exiting now.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->
<!-- Comment: Mon Feb 24 19;14;06 comment by...Jason -->
I killed this and restarted it (next entry) because the process
ran out of disk space before it finished.
<!-- Date: Mon Feb 24 14:07:12 2003 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 239
Calibration type  : standard
Run period tag    : Feb_2003
DPS-off run       : 159263
DPS-on run        : 159262
Requested by      : Jason Nielsen
Main process id   : 64420765
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->



<!-- Date: Mon Feb 24 17:42:23 2003 -->
<pre> 
<b> PLAN for tomorrow ACCESS </b> 
<LI> BEAM will be dump at 5:30 am 
<LI> Eva H. is going to show up before 6:00 am to warm up SVXII 
<LI> Gino is going to have all the pre-access tests done before 6:30 
<LI> at 6:30 our access will start.</LI> 
 
</P> 
The main goals are: 
<LI> Bring SB2W7 back as a SVT wedge 
<LI> install 3 <u>FTM</u> on the 3 SVX wedges still suffering from STUCK CAPID troubles. 
 
</P> 
 
We should accomplish this by 9:30 am.  
I believe it is feasible. 
 
Later on in the day when the plugs are closing we will  
bring the system back up and do a post-access check-out 
</pre>
<!-- Author: Gino -->


<!-- Date: Mon Feb 24 19:20:19 2003 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 239 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 159263
DPS-on run       : 159262
Requested by     : Jason Nielsen
Submitted        : 2003-02-24 12:06:22
Completed        : 2003-02-24 17:19:40
Status           : FAILURE

Last processing stage reported : comparing to the reference calibration
Failure diagnostics :
child process exited abnormally
</pre>
<!-- Author: D-mode script  -->
<!-- Comment: Mon Feb 24 22;10;44 comment by...Jason -->
<pre>The calibration failed the following reference comparison criteria:

            Cut Name    Sensor Set   Cut Value   Data Value
--------------------    ----------   ---------   ----------
bad_fraction abs max    SVX_PHI      0.02        0.027312  

Reference calibration runs are 159187 (DPS off) and 159186 (DPS on)
</pre>
<!-- Date: Mon Feb 24 22:05:03 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1605&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1606  width='300' align='top'></td><td>Sb2W6L0 long term bias current. No trouble.</a></td></tr></table>
<!-- Author: gino -->



<!-- Date: Tue Feb 25 06:44:50 2003 -->
Store lowlights<ul> 
<li> 2 DVDD trips on SB3W1L0-I threatened it with disintegration and then it behaved 
<li> 1 DVDD trip on SB5W1 L1, L3, L4 (but not L0, L2) 
<li> lots of temporary IMON pinks in bias mostly 
<li> b0dap42 hung.  Restarted GUI ok, had trouble 
restarting IMON (Ace + svxii + kerberos) so I logged in 
from home and started it myself 
</ul> 
I'll kill IMON now since we are off for the access.
<!-- Author: SCN -->


<!-- Date: Tue Feb 25 07:15:17 2003 -->
Warm up of svx began about 1/2 hr ago. <br> 
First step -6C -> -1C. <br> 
<br> 
Changed trip limits: <br> 
<pre> 
SVX           L00 
BH 6->20      SIL 5->20 
              Hyb 5->20 
The rest remain the same. 
</pre>  
<!-- Author: Eva H. -->
<!-- Comment: Tue Feb 25 07;40;10 comment by...Eva H. -->
<pre>
Going from 1C -> 6C.
</pre>

<!-- Comment: Tue Feb 25 08;42;03 comment by...Eva H. -->
<pre>SVX warmed up to 6C.</pre>

<!-- Comment: Tue Feb 25 09;45;29 comment by...Eva H. -->
Now warming up svx and isl to 10C (both from 6c).
<br>
ISL trip temps changed to:
<br>
<pre>
CC     20 -> 25
CPC's  15 -> 25
</pre>


<!-- Date: Tue Feb 25 09:50:27 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W3L2 
<li>problem n: 899 
<li>Status: needs_observation
<li>Type: RX
<li>Action: Swap_RX
<li>entered by: sforrest 
<li>description is: Swapped Rx fixed OBVD dropped read out.  Post test shows bit  zero low.<table border=1>
<tr><td><b>IN:</b></td><td><a href="http://nkek15.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0161">0161</a></td></tr>
<tr><td><b>OUT:</b></td><td><a href="http://nkek15.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0523">0523</a></td></tr></table> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W3&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Feb 25 09:52:53 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W0/1All 
<li>problem n: 890 
<li>Status: needs_observation
<li>Type: Wedgewide_HRR
<li>Action: Swap_FTM
<li>entered by: sforrest 
<li>description is: Swapped FTM<table border=1>
<tr><td><b>IN</b></td><td>PREP:</td><td>564034</td><td>Serial:</td><td>??</td></tr>
<tr><td><b>OUT</b></td><td>PREP:</td><td>565891</td><td>Serial:</td><td>003</td></tr></table> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W0/1&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Feb 25 09:56:40 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W7L2 
<li>problem n: 852 
<li>Status: needs_observation
<li>Type: Optical_other
<li>Action: Swap_RX
<li>entered by: sforrest 
<li>description is: Swapped Rx.  Problem not seen in post test.  c2c2 needs observation.<table border=1>
<tr><td><b>IN:</b></td><td><a href="http://nkek15.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0355">0355</a></td></tr>
<tr><td><b>OUT:</b></td><td><a href="http://nkek15.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0914">0914</a></td></tr></table> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W7&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Feb 25 10:01:07 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W0/1All 
<li>problem n: 746 
<li>Status: needs_commissioning
<li>Type: Other
<li>Action: Swap_FTM
<li>entered by: reid 
<li>description is: Swapped FTM with a new buffed up FTM<br>  Tested with svxdaq with no apparent problems.  <table border=1>
<tr><td><b>IN</b></td><td>PREP:</td><td>564021</td><td>Serial:</td><td>102</td></tr>
<tr><td><b>OUT</b></td><td>PREP:</td><td>565888</td><td>Serial:</td><td>138</td></tr></table> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B3W0/1&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Feb 25 10:02:23 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W7L4 
<li>problem n: 605 
<li>Status: needs_observation
<li>Type: PC_Temperature
<li>Action: Swap_RX
<li>entered by: sforrest 
<li>description is: Swapped Rx.  Pretest did not show errors, since board was out  for work on SB2W7L2 we decided to swap Rx anyway.<table border=1>
<tr><td><b>IN:</b></td><td><a href="http://nkek15.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0344">0344</a></td></tr>
<tr><td><b>OUT:</b></td><td><a href="http://nkek15.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0106">0106</a></td></tr></table> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W7&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Feb 25 10:04:35 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W7L4 
<li>problem n: 605 
<li>Status: needs_observation
<li>Type: PC_Temperature
<li>Action: Swap_RX
<li>entered by: sforrest 
<li>description is: Post test showed several bit errors.  We decided to swap the old  Rx.<table border=1>
<tr><td><b>IN:</b></td><td><a href="http://nkek15.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0106">0106</a></td></tr>
<tr><td><b>OUT:</b></td><td><a href="http://nkek15.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0344">0344</a></td></tr></table> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W7&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Feb 25 10:04:35 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W10/11All 
<li>problem n: 891 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Swap_FTM
<li>entered by: reid 
<li>description is: Swapped FTM with a new 'buffed' up FTM.  Tested with svxdaq and found a persistent bit error on pipe 5.  <table border=1>
<tr><td><b>IN</b></td><td>PREP:</td><td>564054</td><td>Serial:</td><td>103</td></tr>
<tr><td><b>OUT</b></td><td>PREP:</td><td>565897</td><td>Serial:</td><td>129</td></tr></table> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B5W10/11&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Feb 25 10:04:35 2003 -->
<pre>&lt;pre&gt; 
&lt;b&gt;ACCESS WORK SO FAR.&lt;/b&gt; 
&lt;LI&gt; &lt;b&gt;SB3W0/1&lt;/b&gt; FTM swapped succesfully (no errors introduced) 
&lt;LI&gt; &lt;b&gt;SB1W0/1&lt;/b&gt; FTM swapped succesfully (no errors introduced) 
&lt;LI&gt; &lt;b&gt;SB5W10/11&lt;/b&gt; FTM swapped, introduced bit 0 LOW on SB5W11L0 
     The RX was swapped for SB5W11L0 
     after swapping the RX the problem is still there. 
     we will deal with it in the late afternoon 
     This problem was there in the past. 
&lt;LI&gt; &lt;b&gt;SB2W7L2&lt;/b&gt; RX swaped and OBDV problem. FIXED! 
     Inserted multiple bit trouble in SB2W7L4. 
     We will deal with it in the later afternoon. 
     This is a ladder with very low light output. 
     We will search inside the FTM for an optimized light match. 
&lt;LI&gt; &lt;b&gt;SB2W3L2&lt;/b&gt; RX swapped for OBDV problem. 
     OBDV problem FIXED. 
     BIT 0 LOW introduced. 
     We will deal with it in the later afternoon. 
     This problem was seen in the past. 
     We will search inside the FTM for an optimized light match. 
      
 
&lt;/pre&gt; 
</pre>
<!-- Author: Gino -->


<!-- Date: Tue Feb 25 10:04:51 2003 -->
<pre>&lt;pre&gt; 
&lt;b&gt;ACCESS WORK SO FAR.&lt;/b&gt; 
&lt;LI&gt; &lt;b&gt;SB3W0/1&lt;/b&gt; FTM swapped succesfully (no errors introduced) 
&lt;LI&gt; &lt;b&gt;SB1W0/1&lt;/b&gt; FTM swapped succesfully (no errors introduced) 
&lt;LI&gt; &lt;b&gt;SB5W10/11&lt;/b&gt; FTM swapped, introduced bit 0 LOW on SB5W11L0 
     The RX was swapped for SB5W11L0 
     after swapping the RX the problem is still there. 
     we will deal with it in the late afternoon 
     This problem was there in the past. 
&lt;LI&gt; &lt;b&gt;SB2W7L2&lt;/b&gt; RX swaped and OBDV problem. FIXED! 
     Inserted multiple bit trouble in SB2W7L4. 
     We will deal with it in the later afternoon. 
     This is a ladder with very low light output. 
     We will search inside the FTM for an optimized light match. 
&lt;LI&gt; &lt;b&gt;SB2W3L2&lt;/b&gt; RX swapped for OBDV problem. 
     OBDV problem FIXED. 
     BIT 0 LOW introduced. 
     We will deal with it in the later afternoon. 
     This problem was seen in the past. 
     We will search inside the FTM for an optimized light match. 
      
 
&lt;/pre&gt; 
</pre>
<!-- Author: Gino -->


<!-- Date: Tue Feb 25 10:08:00 2003 -->
<pre>  
<b>ACCESS WORK SO FAR.</b>  
<LI> <b>SB3W0/1</b> FTM swapped succesfully (no errors introduced)  
<LI> <b>SB1W0/1</b> FTM swapped succesfully (no errors introduced)  
<LI> <b>SB5W10/11</b> FTM swapped, introduced bit 0 LOW on SB5W11L0  
     The RX was swapped for SB5W11L0  
     after swapping the RX the problem is still there.  
     we will deal with it in the late afternoon  
     This problem was there in the past.  
<LI> <b>SB2W7L2</b> RX swaped and OBDV problem. FIXED!  
     Inserted multiple bit trouble in SB2W7L4.  
     We will deal with it in the later afternoon.  
     This is a ladder with very low light output.  
     We will search inside the FTM for an optimized light match.  
<LI> <b>SB2W3L2</b> RX swapped for OBDV problem.  
     OBDV problem FIXED.  
     BIT 0 LOW introduced.  
     We will deal with it in the later afternoon.  
     This problem was seen in the past.  
     We will search inside the FTM for an optimized light match.  
 
This time it should work 
</pre> 
<!-- Author: Gino -->

<!-- Date: Tue Feb 25 10:10:04 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W7L4 
<li>problem n: 605 
<li>Status: needs_access_2hr
<li>Type: PC_Temperature
<li>Action: Diagnosis_update
<li>entered by: sforrest 
<li>description is: Post test shows the same bit errors.  We should try to swap DOIM cables to find a better matching Rx in the board. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W7&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Feb 25 15:00:32 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W6L3 
<li>problem n: 903 
<li>Status: needs_work
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: chips 6 and 7 (a3, a2) have strange ADC distributions and are reading out low (or 0) numbers of ADC counts for odd channels 40-60 counts for even channels. chip problems don't give digital errors, however.   problem caught as occasionally 00f3 termination.  was seen before the shutdown as well.    
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W6&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Feb 25 15:16:02 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W1L2 
<li>problem n: 677 
<li>Status: needs_observation
<li>Type: DRO_00F3
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: same problem persists, although fairly infrequently.  OOf3 termination with no readout. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Feb 25 15:18:07 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W1L3 
<li>problem n: 678 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: problem persists infrequently, z side stuck cap ids. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W1&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Feb 25 15:27:14 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W1L4 
<li>problem n: 885 
<li>Status: needs_work
<li>Type: DRO_00F3
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: run 159175 cap id errors persist.  run 159176 and after z side is chopped and 00f3 termination.  
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W1&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Feb 25 15:34:50 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W2L2 
<li>problem n: 904 
<li>Status: needs_work
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: low digital error rate of chip b4 wrong cap id.  also occasional junk readout  'bf92ffa3 ffaaff1b ff5cffa3 ffa2bf22 ffa3ffaa ff1bffa3 ffa3ffa2 20ns 9f12ffa3 ffaaff1b ffa3ffa3 ffa2bf32 ffa3ffd0 d0c2c2c4' (very low rate of occurance of junk readout ~1%) 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W2&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Feb 25 15:37:11 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W2L3 
<li>problem n: 905 
<li>Status: needs_work
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: same problem as f022.  wrong cap id for chip a3, along with low occurence of 'junk' readout. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Feb 25 23:47:44 2003 -->
<pre>  
<b>ACCESS WORK.</b>  
<LI> <b>SB3W0/1</b> FTM swapped succesfully (no errors introduced)  
<LI> <b>SB1W0/1</b> FTM swapped succesfully (no errors introduced)  
<LI> <b>SB5W10/11</b> FTM swapped, introduced bit 0 LOW on SB5W11L0  
     The RX was swapped for SB5W11L0  
     after swapping the RX the problem is still there.  
     We swapped another RX and we got bit 0 HIGH. 
     This is a minor problem. We leave it there.  
     It should NOT affect much SVT and/or the offline 
     Runned out of time and energy 
<LI> <b>SB2W7L2</b> RX swaped and OBDV problem. FIXED!  
     Inserted multiple bit trouble in SB2W7L4.  
     We will deal with it in the later afternoon.  
     This is a ladder with very low light output.  
     No many problems at nominal temperature. 
     Decided to leave it as it is.  
<LI> <b>SB2W3L2</b> RX swapped for OBDV problem.  
     OBDV problem FIXED.  
     BIT 0 LOW introduced.  
     We will deal with it in the later afternoon.  
     This problem was seen in the past.  
     Not there anymore at nominal T. 
<LI> <b>SB2W0</b> we found a bad Power Supply while doing the checkout 
     Mat and reid swapped the supply and now we are happy. 
     This delayed things quite a bit. 
 
We had little time left and not final tools (but good ones)  
to check bias connection. We will have the final answer with  
the first beam that shows up. 
 
 
Gino, Steve, Stan, Julia, Reid, Matt, David, Cigdem and maybe more. 
 
</pre> 
<!-- Author: Gino -->


<!-- Date: Wed Feb 26 09:20:08 2003 -->
iFix 3.0 upgrade on SVXIICON PC is underway.  No stumbling blocks yet.  All PS enables were declared "INACTIVE" (and switched off) and all detector supply valves were shut prior to the upgrade.
<!-- Author: Andy H. -->


<!-- Date: Wed Feb 26 11:30:22 2003 -->
<ul> 
<li> Developing Run Type which allows one to dynamically select 
Thresholds, SPARSE/NN/RA, DPS ON/OFF, and even DAC for charge injection dynamically in Run Control.  Should make 
Checking Bias a bit more efficient.  Note:lots of failed initializations for b0fib00 in the log today... 
<li> Re-establishing pre-BiasCheck thresholds in the hdwdb 
</ul>
<!-- Author: SCN -->

<!-- Date: Wed Feb 26 11:49:22 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W4L4 
<li>problem n: 906 
<li>Status: needs_work
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: Drop readout, no chip id or only chip 8d seen, c2c2 termination digital errors from 5-10 % 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W4&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Feb 26 12:09:24 2003 -->
<pre>Checked the CAENvolts.dat file. 
I re-integrated: 
SB2W0 all layers  
      (it was taken out yesterday because of a faulty power supply) 
SB1W6L4 it was taken out yesterday because of multiple trips. 
        I put it back so next time we turn the toy on we face  
        this guy. 
        Even better if there is study time we should face it then 
</pre>
<!-- Author: Gino -->

<!-- Date: Wed Feb 26 13:01:54 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W2L2 
<li>problem n: 613 
<li>Status: needs_observation
<li>Type: PC_Temperature
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: bit 2 problem persits at ~5% 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B4W2&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Feb 26 13:07:17 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W1All 
<li>problem n: 900 
<li>Status: needs_observation
<li>Type: DVDD
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: prior to DVDD trip (which happened run 159289) wedge wide random cap id problems in run 159264. seems to be isolated to this run. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B5W1&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Feb 26 17:44:57 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W3L0 
<li>problem n: 592 
<li>Status: fixed
<li>Type: RX
<li>Action: Monitoring
<li>entered by: petemc 
<li>description is: The c2c2 problem has not recurred since the swap. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W3&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Feb 26 17:50:55 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W4L1 
<li>problem n: 761 
<li>Status: fixed
<li>Type: RX
<li>Action: Monitoring
<li>entered by: petemc 
<li>description is: Bit errors have not recurred since the January access. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W4&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Feb 26 18:10:25 2003 -->
<p>iFix successfully upgraded to v3.0 today.  Turned out to be 
pretty painless.  Only source of trouble was that after the 
upgrade the software that we use to program the PLC was unable 
to recognize the security key.  Downloading and installing the 
latest-greatest version of this software fixed that up.</p> 
<p>I've tested various things -- cooling monitoring/control 
works fine, reading/writing the iFix database works fine, 
communication with the GUI works fine, communication with the 
control room global pages works fine.  The only things I still 
want to test is that (1) control of the voltages from the global 
HV summary page still works, and (2) the propagation of trigger 
inhibits still works.  I believe we've asked for ~1h of quiet 
time (after destructive beam studies) to perform these tests.</p>
<!-- Author: Andy H. -->

<!-- Date: Wed Feb 26 18:37:52 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W4L1 
<li>problem n: 847 
<li>Status: needs_work
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: petemc 
<li>description is: <pre>Bit Errors and Pipeline out of Synch errors not seen since swap.

Unknown channel error persists.  This is most pronounced in
read-only, where it may be related to thread 576, but is also
present in physics runs.</pre> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B1W4&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Feb 26 18:44:05 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W6L3 
<li>problem n: 609 
<li>Status: fixed
<li>Type: RX
<li>Action: Monitoring
<li>entered by: petemc 
<li>description is: Immediate C2C2 problem fixed. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W6&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Feb 26 18:56:45 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L0 
<li>problem n: 633 
<li>Status: needs_work
<li>Type: RX
<li>Action: Monitoring
<li>entered by: petemc 
<li>description is: Bit 5 problems persist. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Feb 26 19:06:45 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W4/5All 
<li>problem n: 873 
<li>Status: fixed
<li>Type: Optical_other
<li>Action: Monitoring
<li>entered by: petemc 
<li>description is: <pre>No data problem fixed.
No new problems introduced.</pre> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=L00&wedge=B0W4/5&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Feb 26 20:06:20 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W4L0 
<li>problem n: 135 
<li>Status: needs_work
<li>Type: Chip_other
<li>Action: Monitoring
<li>entered by: petemc 
<li>description is: <pre>See nothing on chip a3.
See no physics on chips a2-a0.
chip a3 caused some dropped readouts in calibration runs at end
of january, but no longer.</pre> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W4&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Feb 26 20:52:01 2003 -->
<pre>Big project ongoin is the IFIX upgrade. 
BD (beam division) has some destructive studies in mind. 
Once theY are done with them we will have 1 hour of quiet time. 
The idea during this one hour is to tes the button on IFIX 
to bring the system from STDBY to ON and back and the various  
implications on the trigger inhibit. 
So we will geet paged as soon aas the destructive studies are  
over.  
We will bring the silicon to STDBY. 
When the quiet time starts we will play the IFX HV button and the 
trigger inhibit. 
</pre>
<!-- Author: Gino -->
<!-- Comment: Thu Feb 27 19;40;32 comment by...SCN -->
Andy powered one SVXII, L00, and ISL Ladder <i>x</i>B0W2L2
using the IFIX button and saw that they went on and the trigger inhibit worked.  Everything should be now ready to go for the next shot (right Andy?)
<!-- Date: Thu Feb 27 15:24:02 2003 -->
<center><a href='/elog/notebooks/silicon/Thu_Feb_27_2003_152152.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1608' ></a><a href='/elog/notebooks/silicon/Thu_Feb_27_2003_152220.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1610' ></a><a href='/elog/notebooks/silicon/Thu_Feb_27_2003_152235.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1612' ></a></center>
<!-- Author: SCN -->
<!-- Comment: Thu Feb 27 15;27;44 comment by...SCN -->
This is a comparison of the Clock signals coming out of the FTM for driver settings 03, 07, and 11 ("Buff").  
The white is FE CLOCK, the Green is CMD CLOCK, and the Yellow is BE CLOCK.  I triggered on the 4 BE CLOCKs of the keep alive.


<!-- Date: Thu Feb 27 15:28:56 2003 -->
<center><a href='/elog/notebooks/silicon/Thu_Feb_27_2003_152304.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1614' ></a><a href='/elog/notebooks/silicon/Thu_Feb_27_2003_152320.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1616' ></a><a href='/elog/notebooks/silicon/Thu_Feb_27_2003_152335.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1618' ></a></center>
<!-- Author: SCN -->
<!-- Comment: Thu Feb 27 15;30;57 comment by...SCN -->
<pre>This is the same as above, but now measured on a Blinky board
at the other end of the 71' FTM timing cable.  I triggered on
Ch 4, which are the Keep Alive BE clocks at the FTM.
One can see how buffed up drivers might help...</pre>

<!-- Comment: Thu Feb 27 18;49;21 comment by...Gino -->
<pre>With setting 3 the BECLK looks very poor to me.
We have the problem called 00f3 that we know could show up 
because the chip does NOT reach counter modulo.
Now if the chip sees less BECLK than what we actually sends 
because of the quality of the BECLK itself I imagine it would 
more likely end up to generate the 00f3.
I think we should locate a FIB with as many as possible 00f3 
problems (probably an ISL is the best choice) and put in there a 
PUFFED FTM? 

I think this investigation has the potential to clear up some of 
our "not yet undesrtood" troubles.

The problem should be posted to Vince ASAP.
</pre>

<!-- Comment: Thu Feb 27 19;38;48 comment by...SCN -->
Vince was mailed with this link just seconds after it was put in...
<!-- Date: Thu Feb 27 19:37:25 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W3L4 
<li>problem n: 321 
<li>Status: unfixable
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: sforrest 
<li>description is: No random walk during data taking. Cap ID remains constant during event. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W3&layer=L4">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Thu Feb 27 19:42:41 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W10L4 
<li>problem n: 603 
<li>Status: needs_observation
<li>Type: AVDD2
<li>Action: Diagnosis_update
<li>entered by: sforrest 
<li>description is: No random walk during data taking. Cap ID remains constant during event. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W10&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Feb 27 21:08:05 2003 -->
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=174&frame=2&anchor=21:05:34'> 
Tested that iFix control of Si power and trigger inhibits 
still work after iFix upgrade.</a>  Test successful.  I turned 
on LB0W1L1, SB0W1L1, and IB0W1L1 to do these tests; the rest 
of the detector remained off.
<!-- Author: Andy H. -->

<!-- Date: Fri Feb 28 08:43:57 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W10L3 
<li>problem n: 480 
<li>Status: needs_work
<li>Type: DVDD
<li>Action: Diagnosis_update
<li>entered by: bolla 
<li>description is: Tried with svxdaq. <LI> readback 00 during INIT. <LI> only fibheader during readout. <LI> pretty bad. <LI> left it out of HDWDB </LI> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B3W10&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Feb 28 09:13:06 2003 -->
<pre>SB4W5L3 is now out of HDWDB because of too many HRR from SVXMON. 
This ladder has the last chip (a0) chopped from the readout chain. 
Running it with svxdaq I see that only the last chip has trouble. 
By chopping it out the ladder is really behaving well. 
I re-integrate it and mask it in the SVXMON HRR check.  
The Stuck Chips list as of before the change is: 
/cdf/people1/bachacou/SvxMonConfig/stuckChips-022803.txt 
and after the change: 
/cdf/people1/bachacou/SvxMonConfig/stuckChips.txt 
 
This way we should see what it gives us during data taking. 
 
</pre>
<!-- Author: Gino -->

<!-- Date: Fri Feb 28 09:15:20 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W5L3 
<li>problem n: 857 
<li>Status: needs_observation
<li>Type: AVDD2
<li>Action: Added_hdwdb
<li>entered by: bolla 
<li>description is: <a href='http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=143&frame=2&anchor=09:13:06'> studied </a>. Re-integrated and masked in SVXMON. We should evaluate the masking during data taking   
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B4W5&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Feb 28 09:31:03 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W5L4 
<li>problem n: 11 
<li>Status: needs_access
<li>Type: Other
<li>Action: Diagnosis_update
<li>entered by: bolla 
<li>description is: <pre>Investigated with svxdaq. it init OK. The current is OK.
During READ-OUT you get nothing only some garbage between the 
FIBHEADEr and the termination caracther. Could it be  
a OBDV trouble on the FTM?
With the next access we should get the fiber of this ladder on
another PIPE of the DAQ and see if it is any better.
It stays out of the HDWDB.</pre> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W5&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Feb 28 19:37:21 2003 -->
<h3>Store 2285 in</h3>  
but the luminosity is piddly (13 E30 at start) and 
the <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=177&frame=2&anchor=19:16:28'>losses suck</a> because of 
a baseline of 18 kHz LOSTP even little spikes make TevMon complain.  Other the other hand, our <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=177&frame=2&anchor=19:00:57'> 
coverage</a> is better than ever. 
To keep it that way, we are going to take a D MODE calibration (underway) and then get out of this crappy store and let Kaori et al do other useful studies with this otherwise useless beam.  
  
<!-- Author: SCN -->
<!-- Comment: Sat Mar  1 09;33;59 comment by...SCN -->
<pre>PS.  For the one run we were in &lt;a href='http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=177&scroll=false'&gt;159603&lt;/a&gt; the DAQ was 96% efficient and there were no HRRs due to Si (but it was only about 1.2 hour long).</pre>
<!-- Comment: Sat Mar  1 09;34;37 comment by...the HTML button clicker -->
PS.  For the one run we were in <a href='http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=177&scroll=false'>159603</a> the DAQ was 96% efficient and there were no HRRs due to Si (but it was only about 1.2 hour long).
<!-- Date: Fri Feb 28 19:58:19 2003 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 240
Calibration type  : standard
Run period tag    : Feb_2003
DPS-off run       : 159606
DPS-on run        : 159605
Requested by      : David
Main process id   : 124740357
Comment           : Losses were unusually higher during these runs.
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Fri Feb 28 20:46:05 2003 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 240 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 159606
DPS-on run       : 159605
Requested by     : David
Submitted        : 2003-02-28 17:57:47
Completed        : 2003-02-28 18:44:31
Status           : FAILURE
Comment          : Losses were unusually higher during these runs.

Last processing stage reported : checking silicon configuration
Failure diagnostics :
ERROR: some ladders appear in one calibration run only. This is the list:
{center west 4 1 phi}
{center west 4 1 z}
{center west 4 2 phi}
{center west 4 2 z}
{center west 4 3 phi}
{center west 4 3 z}
{center west 4 4 phi}
{center west 4 4 z}
{center west 4 5 phi}
{center west 4 5 z}
{center west 5 1 phi}
{center west 5 1 z}
{center west 5 2 phi}
{center west 5 2 z}
{center west 5 3 phi}
{center west 5 3 z}
{center west 5 4 phi}
{center west 5 4 z}
{center west 6 1 phi}
{center west 6 1 z}
{center west 6 2 phi}
{center west 6 2 z}
{center west 6 4 phi}
{center west 6 4 z}
{center west 6 5 phi}
{center west 6 5 z}
{west east 4 1 phi}
{west east 4 1 z}
{west east 4 2 phi}
{west east 4 2 z}
{west east 4 3 phi}
{west east 4 3 z}
{west east 4 4 phi}
{west east 4 4 z}
{west east 4 5 phi}
{west east 4 5 z}
{west east 5 1 phi}
{west east 5 1 z}
{west east 5 2 phi}
{west east 5 2 z}
{west east 5 3 phi}
{west east 5 3 z}
{west east 5 4 phi}
{west east 5 4 z}
{west east 6 1 phi}
{west east 6 1 z}
{west east 6 2 phi}
{west east 6 2 z}
{west east 6 3 phi}
{west east 6 3 z}
{west east 6 4 phi}
{west east 6 4 z}
{west east 6 5 phi}
{west east 6 5 z}
{west west 4 1 phi}
{west west 4 1 z}
{west west 4 2 phi}
{west west 4 2 z}
{west west 4 3 phi}
{west west 4 3 z}
{west west 4 4 phi}
{west west 4 4 z}
{west west 4 5 phi}
{west west 4 5 z}
{west west 5 1 phi}
{west west 5 1 z}
{west west 5 2 phi}
{west west 5 2 z}
{west west 5 3 phi}
{west west 5 3 z}
{west west 5 4 phi}
{west west 5 4 z}
{west west 5 5 phi}
{west west 5 5 z}
{west west 6 2 phi}
{west west 6 2 z}
{west west 6 3 phi}
{west west 6 3 z}
{west west 6 4 phi}
{west west 6 4 z}
{west west 6 5 phi}
{west west 6 5 z}
Exiting. If you really want to proceed beyond this point, change the parameter "abort_on_ladderset_mismatch" in the run_calib_analysis.tcl script to 0 and restart.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->


<!-- Date: Fri Feb 28 20:46:05 2003 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 240 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 159606
DPS-on run       : 159605
Requested by     : David
Submitted        : 2003-02-28 17:57:47
Completed        : 2003-02-28 18:44:31
Status           : FAILURE
Comment          : Losses were unusually higher during these runs.

Last processing stage reported : checking silicon configuration
Failure diagnostics :
ERROR: some ladders appear in one calibration run only. This is the list:
{center west 4 1 phi}
{center west 4 1 z}
{center west 4 2 phi}
{center west 4 2 z}
{center west 4 3 phi}
{center west 4 3 z}
{center west 4 4 phi}
{center west 4 4 z}
{center west 4 5 phi}
{center west 4 5 z}
{center west 5 1 phi}
{center west 5 1 z}
{center west 5 2 phi}
{center west 5 2 z}
{center west 5 3 phi}
{center west 5 3 z}
{center west 5 4 phi}
{center west 5 4 z}
{center west 6 1 phi}
{center west 6 1 z}
{center west 6 2 phi}
{center west 6 2 z}
{center west 6 4 phi}
{center west 6 4 z}
{center west 6 5 phi}
{center west 6 5 z}
{west east 4 1 phi}
{west east 4 1 z}
{west east 4 2 phi}
{west east 4 2 z}
{west east 4 3 phi}
{west east 4 3 z}
{west east 4 4 phi}
{west east 4 4 z}
{west east 4 5 phi}
{west east 4 5 z}
{west east 5 1 phi}
{west east 5 1 z}
{west east 5 2 phi}
{west east 5 2 z}
{west east 5 3 phi}
{west east 5 3 z}
{west east 5 4 phi}
{west east 5 4 z}
{west east 6 1 phi}
{west east 6 1 z}
{west east 6 2 phi}
{west east 6 2 z}
{west east 6 3 phi}
{west east 6 3 z}
{west east 6 4 phi}
{west east 6 4 z}
{west east 6 5 phi}
{west east 6 5 z}
{west west 4 1 phi}
{west west 4 1 z}
{west west 4 2 phi}
{west west 4 2 z}
{west west 4 3 phi}
{west west 4 3 z}
{west west 4 4 phi}
{west west 4 4 z}
{west west 4 5 phi}
{west west 4 5 z}
{west west 5 1 phi}
{west west 5 1 z}
{west west 5 2 phi}
{west west 5 2 z}
{west west 5 3 phi}
{west west 5 3 z}
{west west 5 4 phi}
{west west 5 4 z}
{west west 5 5 phi}
{west west 5 5 z}
{west west 6 2 phi}
{west west 6 2 z}
{west west 6 3 phi}
{west west 6 3 z}
{west west 6 4 phi}
{west west 6 4 z}
{west west 6 5 phi}
{west west 6 5 z}
Exiting. If you really want to proceed beyond this point, change the parameter "abort_on_ladderset_mismatch" in the run_calib_analysis.tcl script to 0 and restart.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Fri Feb 28 22:59:53 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1619&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1619  width='300' align='top'></td><td>Latest physics run with silicon. SVT coverage. Better than ever before. </a></td></tr></table>
<!-- Author: Gino -->


<!-- Date: Sat Mar 1 08:53:15 2003 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1620&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1620' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1621&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1621' width='300'></a></center>
<!-- Author: SCN -->
<!-- Comment: Sat Mar  1 09;28;37 comment by...SCN, Jason -->
IB4W0L4 has shown <a href='http://nucsb03.fnal.gov/cgi-bin/PSPlot?plottype=ScatterPlot&XAXIS=Days&NXBIN=2400&MINX=779&MAXX=789&NYBIN=200&MINY=1000&MAXY=1200&OptSta=0&graphoption=P&showtitle=f&title=&Wedge1=IB4W0&variable1=IAvddL4&color1=black&fillcolor1=white&Mark1=8&linewidth1=3&Scalex1=1&Scaley1=1&Wedge2=&variable2=none&color2=red&fillcolor2=white&Mark2=21&linewidth2=3&Scalex2=1&Scaley2=1&Wedge3=&variable3=none&color3=blue&fillcolor3=white&Mark3=23&linewidth3=3&Scalex3=1&Scaley3=1&Wedge4=&variable4=none&color4=green&fillcolor4=white&Mark4=24&linewidth4=3&Scalex4=1&Scaley4=1&Wedge5=&variable5=none&color5=cyan&fillcolor5=white&Mark5=25&linewidth5=3&Scalex5=1&Scaley5=1&Cut1min=-999&Cut1Var=none&Cut1max=999&Cut2min=-999&Cut2Var=none&Cut2max=999&L1x0=15.2835&fit=none'>AVDD increase of 100 mA</a> but stable in the
last few days, and in physics it appears to be DPS OFF and therefore 100% occupied.  However, the HDWDB and the Fib crate are both saying it should be DPS ON,
and it never fails init.  Furthermore, the other ladder in the
pair sharing the HDI is fine (normal occupancy etc).  Our options <ol> <li>Sparse this ladder with DPS OFF thresholds (or just completely)
<li> Turn this (and the other ladder which is ok) off
</ol>
As a test, Jason and I opt for option 1, since the currents do not seem to be dangerous.  Thresholds are
<table>
<tr> <th> Chip (RO order) <th> 0 <th> 1 <th> 2 <th> 3 <th> 12 <th> 13 <th> 14 <th> 15 </tr>
<tr> <td>Threshold  <td> 77 <td> 80 <td> 80 <td> 81 <td> 87 <td> 90 <td> 89 <td> 89 </tr>
</table>
I don't think physics (in terms of deadtime) nor saftey (in terms
of setting us up for a resonance at (8*5 + 10 = 50 uS = 20 kHz))
allows us to let this go unaddressed.  Jason will make the appropriate PDB entries (linking to this).


<!-- Date: Sat Mar 1 09:33:34 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L4 
<li>problem n: 909 
<li>Status: needs_work
<li>Type: Chip_other
<li>Action: Sparse_out_chip
<li>entered by: nielsenj 
<li>description is: ISL laddder (1/2 HDI, C0-3,12-15) stuck in DPS-off mode. (See <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=143&frame=2&anchor=08:53:15'> detailed e-log entry</a>.)  Applied DPS-off thresholds (from  latest calibration) in chip editor.  
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B4W0&layer=L4">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Sat Mar  1 09;35;56 comment by...Jason -->
Caibration file was off_sichipthresh_159263.txt.

<!-- Date: Sat Mar 1 11:06:55 2003 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 241
Calibration type  : standard
Run period tag    : Mar_2003
DPS-off run       : 159629
DPS-on run        : 159627
Requested by      : Jason Nielsen
Main process id   : 121226763
Comment           : Checkout after kicker prefire
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->



<!-- Date: Sat Mar 1 11:20:41 2003 -->
<H2>TeV quench</H2> 
MCR:"Cause seems to be C:PAK3 kicker prefire." 
<P> 
The silicon was unbiased before, so 
we brought all of the trips back 
to STANDBY.  Power supply crates 3,5,7 were giving errors on the 
CAENnet, so we reset them from 1st floor counting room.   
<B>All crates and ladders came back OK power-wise.</B> 
<P> 
We brought the system through a ColdStart.  Only SB3W7 failed the  
first time, but is OK now.  We took a pair of beam-off 
D-mode calibration run with no DAQ errors.  <B>All crates and ladders came back OK DAQ-wise.</B> 
<P> 
We are still checking out the system with SVXMon...  
<!-- Author: Jason, Julia -->

<!-- Date: Sat Mar 1 12:47:42 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W1L3 
<li>problem n: 910 
<li>Status: fixed
<li>Type: No_Init
<li>Action: Init_RB_mask
<li>entered by: nielsenj 
<li>description is: No init RB after kicker prefire.  Looks OK in SVXMon. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B5W1&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat Mar 1 13:08:03 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1622&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1623  width='300' align='top'></td><td>SB0W3L4 DVDD current versus time since the beginning. Now this anomalosuly high DVDD current is down to 200 mA. It is mor elikely that we broke something else and so mask the previous problem than actually think that the problem got fixed. The ladder still does NOT initliaze (read back 00s as before). Worth looking at it with svxdaq when there will be studies time. </a></td></tr></table>
<!-- Author: Gino Julia Jason and the 40 thieves -->

<!-- Date: Sat Mar 1 13:10:41 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W3L4 
<li>problem n: 86 
<li>Status: needs_study_time
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: bolla 
<li>description is: <a href='http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=143&frame=2&anchor=13:08:03'> consequences of kicker prefire </a>  look at it with svxdaq. there might be a miracle here.  
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W3&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat Mar 1 13:22:48 2003 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1624&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1624' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1625&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1625' width='300'></a></center>
<!-- Author: Jason, Julia, Gino -->
<!-- Comment: Sat Mar  1 13;23;43 comment by...Jason, Julia -->
The red cell is a known problem e463 which gives automatic HRR
from time to time...


<!-- Date: Sat Mar 1 14:52:13 2003 -->
<pre>Fuse appears to be blown on FTM L0B0W5 
we went into a short access to replace the fuse. 
Success.</pre>
<!-- Author: Julia, Gino -->


<!-- Date: Sat Mar 1 14:55:08 2003 -->
So we got a kicker pre-fire. 
<LI> As far as digital errors are concerns there are not any new yellow in SVXMON. This is good. 
<LI> there  is only a new PINK in IMON, SB0W3L4 that is explained in another entry on this page 
<LI> 3 hours after the incident a fuse blew on the FTM for LB0W4/5 and was replaced in a access 
<LI> Bias connections look as good as before but we should check it out with the next beam.  
<!-- Author: Gino Julia and Jason  -->


<!-- Date: Sat Mar 1 20:24:14 2003 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sat_Mar__1_2003_202328.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1627  align='top'></td><td>Hits on z-side for e364. Chip a5 has less physics.</a></td></tr></table>
<!-- Author: David -->


<!-- Date: Sun Mar 2 08:13:26 2003 -->
Tevatron dept. is working on a ground fault problem, no  
predictions for shot setup. 
<P> 
CDF will use the quiet time to take a long cosmics run and will 
include the silicon in a BIASED state.  (This should be OK as 
long as we don't have fixed frequency cosmic triggers, right?)
<!-- Author: Jason -->
<!-- Comment: Sun Mar  2 08;25;31 comment by...Jason -->
Tevatron has requested to warm up a magnet to change-out temperatures.  Based on previous experience from Feb. 3, this could take a couple of days.


<!-- Date: Sun Mar 2 08:42:24 2003 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sun_Mar__2_2003_084214.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1629  align='top'></td><td>Bias current for SB5W8L4</a></td></tr></table>
<!-- Author: Jason -->
<!-- Comment: Sun Mar  2 08;47;38 comment by...Jason -->
This plot is for this morning only.<P>
The rise at 7:50 is NOT accounted for.
<BR>The rise at 8:20 marks the time when we turned SVX to ON.


<!-- Date: Sun Mar 2 08:56:37 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1630&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1631  width='300' align='top'></td><td>AVDD fo IB4W0L4 is back to ~1000mA.</a></td></tr></table>
<!-- Author: Jason -->
<!-- Comment: Sun Mar  2 09;02;42 comment by...Jason -->
The AVDD current has now gone back down.
We had made
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=143&frame=2&anchor=08:53:15'>
this old entry</a> when the current went up a few days ago.
<BR>
I am changing the IMON limits accordingly.

<!-- Date: Sun Mar 2 09:06:27 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L4 
<li>problem n: 909 
<li>Status: needs_work
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: nielsenj 
<li>description is: AVDD is back to ~1025mA, down from ~1125mA. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B4W0&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Mar 2 18:23:50 2003 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 242
Calibration type  : standard
Run period tag    : Mar_2003
DPS-off run       : 159673
DPS-on run        : 159671
Requested by      : Kristian Hahn
Main process id   : 131457534
Comment           : 159672 didn't pass coldstart
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Sun Mar 2 18:24:08 2003 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 242 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 159673
DPS-on run       : 159671
Requested by     : Kristian Hahn
Submitted        : 2003-03-02 16:23:34
Completed        : 2003-03-02 16:23:57
Status           : FAILURE
Comment          : 159672 didn't pass coldstart

Last processing stage reported : start of the run_calib_analysis.tcl script
Failure diagnostics :
Tcl error code : POSIX ENOSPC {no space left on device}
Tcl error info : error writing "stdout": no space left on device
    while executing
"puts "\nChecking connection to ${silicon_remote_account}@${silicon_remote_host}. If the script stops at this""
    invoked from within
"if {$run_histogram_analysis} {
    puts "\nChecking connection to ${silicon_remote_account}@${silicon_remote_host}.\
            If the script stops a..."
    (file "/cdf/home/nielsenj/Calib_scripts/run_calib_analysis.tcl" line 393)
</pre>
<!-- Author: D-mode script  -->



<!-- Date: Sun Mar 2 18:37:17 2003 -->
<h3><a href='http://www-bd.fnal.gov/cgi-mcr/elog.pl?nb=2003&action=view&page=165&anchor=135638&hilite=13:56:38'>Tev Warming up</a></h3> due to 
ground fault.  Warm by Tuesday, next data <i>maybe</i> March 9? 
We'll make plans in tomorrow's Silicon meeting.
<!-- Author: SCN -->

<!-- Date: Sun Mar 2 18:50:23 2003 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 241 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 159629
DPS-on run       : 159627
Requested by     : Jason Nielsen
Submitted        : 2003-03-01 09:06:39
Completed        : 2003-03-02 16:49:43
Status           : FAILURE
Comment          : Checkout after kicker prefire

Last processing stage reported : combining ROOT files
Failure diagnostics :
Received SIGTERM. Exiting now.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->
<!-- Comment: Mon Mar  3 07;55;29 comment by...Jason -->
Due to the same disk full problem as above.