<!-- Title: 10:28:52  Mon Sep 26 2005 -->
<!-- Crewchief: Tuula -->
<!-- Op1: Sebastian (SPL) -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>It's 106 miles to Chicago. We've got a full tank of gas and half a pack of cigarettes. It's dark and we're wearing sunglasses. Hit it ! </pre>


<!-- Date: Mon Sep 26 12:48:07 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7531&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7531  width='300' align='top'></a></td><td><h4>Evidence of annealing</h4> 
 
<p>SB1W3L4 had been reported with the bias current going all over the place.  The bias current kept on increasing until DS-Day 1700 (28 August 2005).  Then the bias started dropping although it started increasing after DS-Day 1720 (17 Sept 2005).</p> 
 
<p>DS-Day 1700 was the day when the ACE hit the crash button and we didn't have cooling for several hours. So did the increase in SVX temperature anneal this ladder to reduce the bias current?  Any experts care to comment?</p></td></tr></table>
<!-- Author: Ankush -->
<!-- Comment: Mon Sep 26 13;06;53 comment by...Grumpy -->
we call him <b> Crash Button Sasha </b>
<!-- Comment: Mon Sep 26 18;10;35 comment by...David -->
I'd be surprised that a couple hours without cooling would lead to detectable annealing. (Reverse annealing can be rapid, but not pre-inversion). Any annealing effects would be global, so checking for a similar effect in most ladders would answer the question.
<P>
A different reason for a change in the leakage current could be that the temperature of the ladder decreased; leakage is strongly temperature dependent. Causes for a local temperature change are varied: nearby ladders being removed from the powerset, changes in the flow pattern of the different inlets and outlets, removal of air bubbles, changes in the I*I*R heating on that ladder's hybrid from e.g., a change in Rdriver.
<P>
Since this is a micron ladder (layer 4), it is possible that micro-discharge was responsible for the current and its variation. You could test that by comparing this guy's current to other ladders. E.g., if this is quite a bit more current than you see in other layer 4 ladders, I'd suspect discharge rather than bulk leakage.
<!-- Date: Mon Sep 26 12:52:20 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W3L4 
<li>problem n: 1216 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: Currents_investigated
<li>entered by: amitra 
<li>description is: <p>Had a look at the recent bias history and noticed the bias current started reducing around DS-Day 1700 (28 August 2005) which was the day when the ACE hit the crash button after a cooling trip.  Did the increase in SVX temperature help to anneal the ladder ? The  bias current is starting to increase again.  Should keep an eye on how this develops over the next month.</p>  <p>The bias history can be found <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=268&frame=2&anchor=12:48:07'> here</a>.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W3&layer=L4">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Mon Sep 26 18:09:36 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7532&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7532' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7533&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7533' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Mon Sep 26 18;11;31 comment by...Ankush -->
<p>The IMON limit for Bias1 for IB1W1L3 was increased to 115.0 last month.  The bias current is still increasing and should exceed the limit around DS-Day 1775 (11 November 2005).</p>

<!-- Date: Mon Sep 26 18:15:13 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W1L3 
<li>problem n: 1519 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>The IMON upper limit for the bias was increaed about a month ago.  The bias current is still steadily increasing and a fit to the data suggests the limit will be exceeded on DS-Day 1775 (11 November 2005). The graphs can be found <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=268&frame=2&anchor=18:09:36'>here</a>. </p>  <p>Keep monitoring the bias current and increase again if necessary.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W1&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Sep 26 18:33:04 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W4L3 
<li>problem n: 1520 
<li>Status: fixed
<li>Type: BIAS
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>Just reviewed the PS-Gui logs and this ladder has not tripped since it was reintegrated.  It is running error-free and the SVXMON strip plots are OK.  So declare this thread fixed.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W4&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Sep 26 18:38:36 2005 -->
<h4> Firmware upgrade for b0svx06/07 </h4> 
These VRB's have now the latest and greatest version of the VRB firmware. ISL/L00 is now entirely upgraded.
<!-- Author: Shulamit and Marcel -->
<!-- Comment: Mon Sep 26 18;47;57 comment by...Marcel -->
I also updated b0svx05 Slot 20. If it works also well for SVX, we'll do the rest...
<!-- Date: Mon Sep 26 18:41:36 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7534&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7534' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7535&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7535' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Mon Sep 26 18;56;46 comment by...Ankush -->
<p>The bias upper IMON limit was increased from 110.0 to 115.0 last month.  Doing my usual <em>noddy</em> fit this ladder is likely to exceed its limit on DS-Day 1760 (27 Oct 2005).  Let's see if it's true. </p>

<p>On a side note, we should try to get the PS-GUI to generate the bias limits as they're going to increase.  <em>PS-GUI author...this is my attempt at a subtle hint</em>.</p>

<!-- Date: Mon Sep 26 19:01:21 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W11L2 
<li>problem n: 1522 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>The IMON upper limit was increased to 115.0.  A fit to the recent bias history suggest the upper IMON limit will be exceeded on DS-Day 1760 (27 October 2005). </p>  <p>Continue to check on this ladder and maybe the next IMON increase should be larger.  The graphs can be found <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=268&frame=2&anchor=18:41:36'> here</a>.</p>    
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W11&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Sep 26 19:01:21 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W11L2 
<li>problem n: 1522 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>The IMON upper limit was increased to 115.0.  A fit to the recent bias history suggest the upper IMON limit will be exceeded on DS-Day 1760 (27 October 2005). </p>  <p>Continue to check on this ladder and maybe the next IMON increase should be larger.  The graphs can be found <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=268&frame=2&anchor=18:41:36'> here</a>.</p>    
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W11&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Sep 26 19:04:15 2005 -->
Changed Bias 0/1 for f442 from 45/50 V to 48/53 V respectively.
<!-- Author: Antonio & Marcel -->


<!-- Date: Mon Sep 26 20:47:20 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7536&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7537  width='300' align='top'></a></td><td>SVTSPYMon plot for store #4402, initial luminosity 120E30.</td></tr></table>
<!-- Author: Tuula -->


<!-- Date: Mon Sep 26 21:15:57 2005 -->
<pre>Everything OK in SVXMON. 
Status: OK 
--------------------------------------- 
Run 204746, Mon Sep 26 21:15:16 
SVX 
Status: OK 
ISL 
Status: OK 
L00 
Status: OK 
 
</pre>
<!-- Author: Tuula -->


<!-- Date: Mon Sep 26 22:57:55 2005 -->
Seems that the higher resonance rate is not coming (only) from the FPS/L2 changes last week. After Ted changes we still get lots of resonances: 
<pre> 
204746 36  
204747 37 (and still running) 
</pre> 
<!-- Author: Sebastian -->
<!-- Comment: Mon Sep 26 23;29;54 comment by...Marcel -->
Are you sure, by browsing the errorlog by eye, I come up with 4+/-2 for both runs ?


<!-- Comment: Mon Sep 26 23;53;09 comment by...sebastian -->
yes, bug in the new script... working on it...

<!-- Comment: Mon Sep 26 23;54;41 comment by...Marcel -->
good, i was doubting my eye sight  :-)


<!-- Date: Tue Sep 27 01:13:42 2005 -->
<pre>I got paged because of "Alarm on L00 Flow loops, east/west supply flow is just at the lower limit (1.8)." I asked them to page Silicon cooling. </pre>
<!-- Author: Tuula -->
<!-- Comment: Tue Sep 27 01;35;53 comment by...Sebastian -->
I called the CR, I think it is a warning, not an allarm. This is known, see: <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=266&frame=2&anchor=15:55:35'>
here</a>. 
<!-- Comment: Tue Sep 27 01;48;26 comment by...Eva H. -->
This time it's the L00 east supply flow.  (it's the west that is ignored right now)  It seems to be right on the threshold yet stable.  I asked the ace to put the history plot in the elog.
<!-- Comment: Tue Sep 27 01;55;48 comment by...Sebastian -->
ok, I talked to someone (Ping-Han?) that told me that it was west.. but he was not very sure (I got the impression...). I wonder if they will manage to put the plot in the elog..
<!-- Comment: Tue Sep 27 02;00;56 comment by...Eva H. -->
I spoke with Teresa and she verified it was the east side.  I talked her through getting the history plot and she promised to put it in the elog. She said it was flat (over the 24hrs plotted).
<!-- Date: Tue Sep 27 01:20:57 2005 -->
<pre>I got another page because of one spike in LOSTPB. The value was still well below the limits, and decreasing, so I told the ACE not to worry about it.  
 
I also asked them not to worry about two pinkies in VBIAS. I'll change limits in the morning.</pre>
<!-- Author: Tuula -->



<!-- Date: Tue Sep 27 01:40:09 2005 -->
<center><a href='/elog/notebooks/silicon/Tue_Sep_27_2005_013938.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7539' ></a><a href='/elog/notebooks/silicon/Tue_Sep_27_2005_013948.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7541' ></a></center>
<!-- Author: Sebastian -->
<!-- Comment: Tue Sep 27 02;03;46 comment by...Sebastian -->
<h3>More on Resonances</h3>
The plot in the left is the L1A rate at the time of resonances for 1918 runs (202500 < runnum < 204549). This corresponds to the "normal era" of resonances, (well) before store 4395 (Tuesday last week).
The plot on the right is the same but for 147 runs between 204549 < runnum < 204722, this corresponds to recent runs, after changes to the FPS/L2 bandwidth on Sep 20th. Note the peak at 25kHz. Also note that the current store
(4402) has seen only 4 resonances this far, after changing the FPS/L2 bw back to previous values. It is not certain what is going on, but is looks related to the increase in the trigger rate.

<!-- Comment: Tue Sep 27 02;13;23 comment by...Ted  -->
<pre>interesting plots. but there is a bias here. on the left, system spent a large fraction of the time running at 20KHz for those runs, that probably *could* be why the "peak" seems to be at 20KHz. on the right, system spent most of the time running at 25KHz L1A rate, that could be the reason that the peak "moved" to 25KHz....  

in any case, my initial impression by simply looking at these two plots is:  it so *looks like* that the resonances may not so much depend on the actual L1A rate...  in other words, if one simply&randomly sample at the L1A rate at different time for a given run, one could/may also come up with similar looking  plots... of course, initial impression is often wrong when it comes to complicated issues like this...:)

but I still like the plots. you are making good progress in getting the tools/plots needed to understand the issue.</pre>

<!-- Comment: Tue Sep 27 02;24;14 comment by...Ted  -->
<pre>Sebastian: I was writing my comments before I saw yours...:)   this store is still relative young (in time), let's see what we learn by the end of store (i.e. total number of resonances).  the hard question we may have to face: if the rate does drop, does it mean the resonances are caused by the higher L1A rate? or the higher L1A rate makes it more obvious (but not the actual cause)?   

anyway, let's get some solid data points first.... 

cheers,</pre>

<!-- Comment: Tue Sep 27 02;55;59 comment by...Ted  -->
<pre>Sebastian:  just one more comment. 

please remake the left plot, excluding the runs with runnumber < 202973. During July 22nd to Aug 16th, we were using the clean-up table 3_06 and had the L1A limit raised to 25KHz as well. after Aug 16th (or starting run 202973), we started using the unified table 3_07, and to be conservative at that time, we moved the L1A limit back to 20KHz for the initial period of running with 3_07. In addition, just in case you included, please make sure to exclude the test run 203488 with 3_08 table (which ran at higher L1A rate through the entire store)... 

let's see how the left plot look like after you remove those runs. just want to make sure that the data is "clean" and solid....:)

cheers,</pre>

<!-- Comment: Tue Sep 27 03;14;00 comment by...Ted -->
<pre>Sebastian: 

once you exclude the runs with runnumber < 202973 (i.e. with 25KHz limit setting), it will be very interesting to see if the peak at 25KHz for the left plot disappear or not. if it is gone (I think it is quite likely), then what I said in the first comment makes somwhat more sense. if the peak at 25KHz for the left plot stays, then it is quite a different story of course...unlikely, though unlikely things do happen...:)

of course, you may also want to make another plot just for the runs between July 22nd to Aug 16th... those were runs with table 3_06 and with L1A limit at 25KHz. and see how it looks like and what was the rate of resonances... that would be another independent data points! 

</pre>

<!-- Comment: Tue Sep 27 03;25;05 comment by...Ted -->
<pre>one minor correction to the run range:  with table 3_06, the L1A limit was increased to 25KHz on Aug 3rd, not July 22nd (that was the date the 3_06 was declared the default). To make it clear and easy for you, the runs between 202306 and 202973 were the runs with FredL1A limit at 25KHz. 

time for bed...:)  your two plots have kept me awake long enough...</pre>

<!-- Date: Tue Sep 27 08:16:01 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W0L3 
<li>problem n: 1510 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: tmaki 
<li>description is: Increasing limits.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>99.64</td><td>99.64</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>115</td><td>130</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W0&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Sep 27 08:22:14 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W0L4 
<li>problem n: 809 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: tmaki 
<li>description is: Increasing IMON limits.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>100.0</td><td>100.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>110</td><td>130</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B2W0&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Sep 27 11:21:49 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W9L3 
<li>problem n: 1511 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: this error is coming and going and it looks like a light level problem. I suggest a Light level measurement 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W9&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Sep 27 11:32:38 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W2L4 
<li>problem n: 1423 
<li>Status: needs_longterm_monitoring
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: this ladder has intermittent problems, we should keep an eye on it. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W2&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Sep 27 11:33:46 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7542&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7542' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7543&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7543' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7544&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7544' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Tue Sep 27 11;37;48 comment by...Ankush -->
<p>Last month we changed the ISEL settings on chip 85 for IB4W0L0.  The change in the ISEL bit increased the AVDD current, so the upper IMON limit was increased to 1155.</p>

<p>The AVDD current has been stable since the change.  The stip plots show the output of chip 85 before and after the chip change.  You can see chip 85 came back.</p>

<p>Conclusion: <b>We fixed it !!!</b></p>

<!-- Comment: Tue Sep 27 11;47;56 comment by...Ankush -->
<p>...well almost. The bit-reporter is reporting errors for
<ul>
<li>Instantaneous Limit out of limit</li>
<li>Occupation out of Limits</li>
<li>Mean Out of Limits</li>
<li>Stdev Out of Limits</li>
<li>Inst stdev Out of Limit</li>
<li>Inst mean Out of Limit</li>
</ul>
....anybody have a clue what these errors mean ?</p>

<!-- Date: Tue Sep 27 11:52:05 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L0 
<li>problem n: 1038 
<li>Status: needs_observation
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>The new IMON AVDD limit is holding steady and chip 85 is now functioning again (See <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=268&frame=2&anchor=11:33:46'> silicon e-log</a> for graphs). However the Bit-Reporter is giving errors for <ul> <li>Instantaneous Limit out of limit</li>  <li>Occupation out of Limits</li>  <li>Mean Out of Limits</li>  <li>Stdev Out of Limits</li>  <li>Inst stdev Out of Limit</li>  <li>Inst mean Out of Limit</li>  </ul> </p>  <p>Will continue to observe thse errors to see if the rate changes.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Sep 27 13:01:57 2005 -->
<table><tr><td><a href=/elog/notebooks/silicon/Tue_Sep_27_2005_130151.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7548  align='top'></a></td><td>L1A rate of resonances for 202973 < run < 204549, (for runs between 202306 and 202973 the FredL1A limit was at 25KHz as in the plot on the right above). So, as Ted predicted, the resason we resonate at 25kHz is because we are most of the time running at that rate. The question is if for the same amount of time that we are around 25k, do we get more resonances now that before? (is this the best question to answer...?). </td></tr></table>
<!-- Author: Sebastian -->
<!-- Comment: Tue Sep 27 13;30;52 comment by...Ted  -->
<pre>good. at this point, your question seems to be the right question to get an answer for....</pre>


<!-- Date: Tue Sep 27 13:43:17 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7549&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7549  width='300' align='top'></a></td><td>Beam acting up. Muon tripped and Victor put the Si to STBY. WE are waiting for MCR to call back. </td></tr></table>
<!-- Author: Sebastian -->
<!-- Comment: Tue Sep 27 13;50;26 comment by...s -->
<pre>we are taking data again.</pre>


<!-- Date: Tue Sep 27 14:15:21 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7550&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7550' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7551&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7551' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Tue Sep 27 14;16;56 comment by...Ankush -->
<p>Last month the Z side of SB0W5L3 (e053) was reintegrated and you see can the strip plots before and after.  This ladder is also running error-free.  It all looks good.</p> 

<!-- Date: Tue Sep 27 14:19:00 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W5L3 
<li>problem n: 867 
<li>Status: fixed
<li>Type: AVDD2
<li>Action: Chip_bit_changes
<li>entered by: amitra 
<li>description is: <p>This ladder has been running with it's Z-side back in.  This ladder has been running error-free.  Consider this thread fixed.  The graphs can be found in the <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=268&frame=2&anchor=14:15:21'> e-log</a>.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W5&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Sep 27 14:25:46 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W2L2 
<li>problem n: 1461 
<li>Status: fixed
<li>Type: Chip_other
<li>Action: Chip_bit_changes
<li>entered by: amitra 
<li>description is: <p>According to the bit reporter this has been running error free. So consider this thread fixed.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W2&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Sep 27 14:28:57 2005 -->
CAEN 8 NW Bot Bot just turned itself off.
<!-- Author: Marcel -->

<!-- Date: Tue Sep 27 14:29:54 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W2L3 
<li>problem n: 1504 
<li>Status: fixed
<li>Type: RX
<li>Action: Monitoring
<li>entered by: amitra 
<li>description is: <p>After the RX swap this ladder has been running error free. This is thread fixed.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Sep 27 14:33:21 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W10/11All 
<li>problem n: 1525 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: amitra 
<li>description is: <p>After the FIB swap SB3W10L4 (e3a4) has been returning data and running error free.  This thread is fixed.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W10/11&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Sep 27 14:33:21 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W10/11All 
<li>problem n: 1525 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: amitra 
<li>description is: <p>After the FIB swap SB3W10L4 (e3a4) has been returning data and running error free.  This thread is fixed.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W10/11&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Sep 27 14:33:21 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W10/11All 
<li>problem n: 1525 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: amitra 
<li>description is: <p>After the FIB swap SB3W10L4 (e3a4) has been returning data and running error free.  This thread is fixed.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W10/11&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Sep 27 14:37:18 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W4L0 
<li>problem n: 1530 
<li>Status: fixed
<li>Type: Chip_capid
<li>Action: Added_hdwdb
<li>entered by: amitra 
<li>description is: <p>This ladder thas been running error-free according to the BitReporter after putting back into the HWDB. Consider this thread fixed.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W4&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Sep 27 14:38:11 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W10/11All 
<li>problem n: 1525 
<li>Status: fixed
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: marcel 
<li>description is: if it is fixed, declare it fixed :-) 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W10/11&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Sep 27 14:39:00 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W10L4 
<li>problem n: 1524 
<li>Status: fixed
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: FIB swap was successful 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W10&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Sep 27 15:01:53 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7552&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7552' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7553&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7553' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Tue Sep 27 15;02;44 comment by...Ankush -->
<p>After the power supply, the lower IMON limits had to be lowered.  The currents are now stable.</p>

<!-- Date: Tue Sep 27 15:06:36 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0/1All 
<li>problem n: 1516 
<li>Status: fixed
<li>Type: VDOIM
<li>Action: PS_work
<li>entered by: amitra 
<li>description is: <p>After the power supply swap, the IMON limits had to be lowered. The new currents are have been stable.  Consider this thread fixed.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W0/1&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Sep 27 15:13:39 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7554&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7554' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7555&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7555' width='300'></a></center>
<!-- Author: Marcel -->
<!-- Comment: Tue Sep 27 15;27;41 comment by...Marcel -->
readout time battle:<br>
This is e522, Micron, super grassy and it has a long readout time. Any ideas ?<br>
Thresholds have been set to 10/11 already, we could bump it up to 12/13, unclear how much physics is remaining then. 



<!-- Date: Tue Sep 27 15:29:35 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7556&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7556' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7557&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7557' width='300'></a></center>
<!-- Author: Marcel -->
<!-- Comment: Tue Sep 27 15;40;17 comment by...Marcel -->
<b>The saga continues</b> <br>
This is e1b4, we could try killing the first two chips on both sides to see, if that decreases the noise a bit. This ladder had no threshold adjustment yet, so we could just bump it up and see, if it has any impact ..
<!-- Date: Tue Sep 27 15:32:16 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7559&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7559  width='300' align='top'></a></td><td> <p>As noted by <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=266&frame=2&anchor=11:19:03'> 
Sasha</a>, the bias history of SB0W3L3 (e033) is rather irratic.</p></td></tr></table>
<!-- Author:  Ankush -->

<!-- Date: Tue Sep 27 15:37:07 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W3L3 
<li>problem n: 1514 
<li>Status: needs_longterm_monitoring
<li>Type: BIAS
<li>Action: Currents_investigated
<li>entered by: amitra 
<li>description is: <p>The upper IMON bias limit set previously has not been exceeded.  So it's OK.  However the bias history of this ladder is irratic. The plots are in the <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=268&frame=2&anchor=15:32:16'> e-log</a>.  Should check up on this ladder from time-to-time.  See if we can understand why it jumps around so much.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W3&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Sep 27 15:39:20 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W11L4 
<li>problem n: 1538 
<li>Status: needs_work
<li>Type: Other
<li>Action: Incident
<li>entered by: marcel 
<li>description is: this ladder continues to be very noisy, propose adjusting thresholds 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W11&layer=L4">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Tue Sep 27 15:41:16 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7560&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7560' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7561&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7561' width='300'></a></center>
<!-- Author: Marcel -->
<!-- Comment: Tue Sep 27 15;44;28 comment by...Marcel -->
<b> and more ... </b>
This is e314, troublesome already for a long time, we have changed thresholds and the bias voltage for this guy to no avail. <br>
I will propose a change of policy, If nobody has a better idea, kill this guy

<!-- Date: Tue Sep 27 15:55:56 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W3All 
<li>problem n: 1523 
<li>Status: needs_observation
<li>Type: Wedgewide_other
<li>Action: PS_work
<li>entered by: amitra 
<li>description is: <p>Since the power supply swap, IB0W3L2 has not tripped and is running error free. The whole wedge also hasn't tripped and only IB0W3L4 has errors.  But this is a known problem.</p>  <p>Let's have another look in a couple of weeks before declaring this thread fixed.</p>  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W3&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Sep 27 16:05:53 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7562&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7562  width='300' align='top'></a></td><td>L00 flows in the last 24hrs.  They are both stable.  The east side fluctuated down last night and went below the warning limit.  They are both ignored now in the global alarms page.  We should monitor them periodically.</td></tr></table>
<!-- Author: Eva H./Jennifer :-) -->

<!-- Date: Tue Sep 27 16:08:59 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W5L2 
<li>problem n: 853 
<li>Status: needs_work
<li>Type: Chip_capid
<li>Action: Monitoring
<li>entered by: marcel 
<li>description is: not only the CAP id is stuck, there is no data at all. Problem DB does not mention any sparsing. Should be investigated 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Sep 27 16:11:03 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W5L0 
<li>problem n: 840 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: Errors are still there, definetly a candidate for quiet time studies  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B1W5&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Sep 27 19:18:20 2005 -->
<h4>First draft of March 06 Shutdown <em>to-do</em> list</h4> 
 
<p>I've written a first draft of things to do during the shutdown.  This can be found at:  
<a href="http://www-cdf.fnal.gov/internal/silicon/ShutdownMar06/ShutdownMar06.html"> 
http://www-cdf.fnal.gov/internal/silicon/ShutdownMar06/ShutdownMar06.html.</a></p> 
 
<p>Let me know what you think and what to add/remove/change.</p> 
  
<!-- Author: Ankush -->


<!-- Date: Tue Sep 27 20:33:57 2005 -->
<pre>Tevatron quenched. MCR is investigating the reason.</pre>
<!-- Author: Tuula -->


<!-- Date: Tue Sep 27 22:36:01 2005 -->
<br><b>Access report</b><br> 
We went in and checked the light levels of e493. However 
with svxdaq we saw no errors (in read all and NN modes).  
Also, the recent data does not seem to indicate light  
level problems (or are we missing something?). In any case these are the measurements: 
<pre> 
OBDV 440 (uW) (50/50 duty cycle) 
Bit0 480 
Bit1 368 
Bit2 576 
Bit3 520 
Bit4 656 
Bit5 512 
Bit6 432 
Bit7 624 
</pre> 
  
<!-- Author: Tuula/Ankush/Sebastian -->
<!-- Comment: Wed Sep 28 00;35;40 comment by...Marcel -->
ok, we have at least the light level things excluded.
<!-- Date: Tue Sep 27 23:10:39 2005 -->
<table><tr><td><a href=/elog/notebooks/silicon/Tue_Sep_27_2005_231031.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7564  align='top'></a></td><td><p>During quiet time I ran SB1W5L2.  Looking at the histograms from SVXDAQ, this looks like bit-error.</p></td></tr></table>
<!-- Author: Ankush -->

<!-- Date: Tue Sep 27 23:14:34 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W5L2 
<li>problem n: 63 
<li>Status: needs_access
<li>Type: Optical_other
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>I'm begining to suspect this is a light level issue.  The bits errors are across the whole ladder and the plots from SVXDAQ also suggest this.  During the next accesss, we should do a light-level measurement on this guy.</p>  <p>The plot can be found <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=268&frame=2&anchor=23:10:39'> here</a>.</p>    
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Sep 27 23:36:42 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W1L2 
<li>problem n: 928 
<li>Status: needs_access
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: amitra 
<li>description is: <p>During quiet time I ran this ladder and the chip does not return any data at all.  It just gives the fib header.  I increased the RDriver to 7 which did not help.  I then set all ISEL bits for all chips in this ladder to 11 111 11 1111.  This did not help either. DS-Error Monitor shows the same results from recent runs.</p>  <p>During the next access, we should do a fibre-swap and possibly a light-lvel measurement and proceed from there.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Sep 27 23:47:29 2005 -->
<h4>Quick Quiet Time Studies</h4> 
 
<p>Using the quiet time which became available, I ran SB1W5L2 (e152) and SB2W1L2 (e212).  The grand irony is these ladders really need an access to figure why they're behaving badly as opposed to SB4W9L3 (e493).</p> 
 
<p>Once I'd finished, I took the Silicon through COLD-START and ran over 5,000 events to check everyhting was OK.  It's all good.</p>
<!-- Author: Ankush  -->
<!-- Comment: Wed Sep 28 00;07;03 comment by...sebastian -->
We will probably get an access sometime this week... (BMU needs to be worked on).

<!-- Comment: Wed Sep 28 00;35;11 comment by...Marcel -->
I would not bother about e152 too much. I think, this is the one with the duty cycle problem according to Master Rong. e212 also has along history, but this behaviour is new. Looks like a bad RX or a bad FIB.





<!-- Comment: Wed Sep 28 02;27;31 comment by...s -->
well, if there is nothing more pressing, we can do these as training for the newer members...


<!-- Date: Wed Sep 28 03:07:00 2005 -->
<center><a href='/elog/notebooks/silicon/Wed_Sep_28_2005_030621.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7574' ></a><a href='/elog/notebooks/silicon/Wed_Sep_28_2005_030630.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7576' ></a><a href='/elog/notebooks/silicon/Wed_Sep_28_2005_030610.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7572' ></a></center>
<!-- Author: Sebastian -->
<!-- Comment: Wed Sep 28 03;09;22 comment by...s -->
204549 < run < 204722
<!-- Date: Wed Sep 28 03:07:37 2005 -->
<center><a href='/elog/notebooks/silicon/Wed_Sep_28_2005_030514.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7568' ></a><a href='/elog/notebooks/silicon/Wed_Sep_28_2005_030503.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7566' ></a><a href='/elog/notebooks/silicon/Wed_Sep_28_2005_030557.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7570' ></a></center>
<!-- Author: Sebastian -->
<!-- Comment: Wed Sep 28 03;15;01 comment by...s -->
202973 < run < 204549


<!-- Comment: Wed Sep 28 06;26;54 comment by...Ted  -->
<pre>interesting. by the way, this must be FredL1A you are plotting, not final L1A (better with final L1A as that is what you really care.... but good enough for now).

the scatter plot on the right looks a bit odd. at ~60E30, how come the FredL1A is above 27KHz? this is not possible with table 3_07. only possible with 3_08.... looks like you may have run 203488 included (that store/run had quite a few resonances). if you take that run out, then  the shape of the middle plot may change somewhat... and you may be able to see the peak at 44E30 (due to UPS kicking in) more clearly. </pre>
<!-- Comment: Wed Sep 28 08;14;04 comment by...s -->
yes, forgot to say, they are FredL1A.
<!-- Comment: Wed Sep 28 08;17;08 comment by...s -->
and, yes, 203488 is included. Will correct these, and make the rate plots per unit time as soon as possible.
<!-- Comment: Wed Sep 28 16;04;16 comment by...Sebastian -->
Runs between 202973 and 204549 with resonances at FredL1A rate larger than 27kHz (other than 203488):
<pre>
203345 27666.3  63.75
203347 31072    36.46
204444 28564.6  42.15
</pre>
There are many entries above 27kHz (see, for example:
<a href="http://www-cdfonline.fnal.gov/java/cdfdb/servlet/Level1Time?TABLE=LEVEL1_CONDITIONS&Y=FREDL1ACCEPTS&WHERE=RC_RUNNUMBER=203345&TITLE=FREDL1ACCEPTS_Run_203345_Rate&XLABEL='time'&YLABEL='Hz'">
here</a>). Are the log files incorrect?

<!-- Comment: Wed Sep 28 16;16;35 comment by...Sebastian -->

<center>
<a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7580&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7580' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7581&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7581' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7579&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7579' width='300'></a>
</center>

Same as above but without run 203488.
<!-- Comment: Thu Sep 29 10;12;51 comment by...Ted  -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>sorry, Sebastian. I forgot to tell you that those two runs were also taken with 3_08 but with version 1. that is why the rate is higher. please exclude them as well. in fact, exclude any run for that store with 3_08. </pre></td></tr></td></table>
<!-- Comment: Thu Sep 29 22;32;57 comment by...sebastian -->
this discussion continues <a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=268&frame=2&anchor=22:19:07'>
below</a>.

<!-- Date: Wed Sep 28 05:47:13 2005 -->
<pre>Quench again.</pre>
<!-- Author: Tuula -->


<!-- Date: Wed Sep 28 06:02:16 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7577&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7577  width='300' align='top'></a></td><td>Is this a typical BLM plot after a quench during shot setup? </td></tr></table>
<!-- Author: Tuula -->
<!-- Comment: Wed Sep 28 08;20;44 comment by...Sebastian -->
yes, the BLMs were not reset for begining of collisions, so this is normal.

<!-- Date: Wed Sep 28 08:31:07 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W5L2 
<li>problem n: 63 
<li>Status: needs_access
<li>Type: Optical_other
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>Light measurments have been made and it looks like either a low duty cycle for OBDV.  We should repeat the measurement and take 3 optical probes.  We should look at OBDV and a two bits together to comapre relative timings.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Sep 28 08:55:40 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W5L0 
<li>problem n: 840 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>Attempted to reproduce errors but no errors were seen with SVXDAQ. Let's observe this ladder and come back to it.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B1W5&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Sep 28 11:35:31 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W0L2 
<li>problem n: 1536 
<li>Status: needs_work
<li>Type: Chip_capid
<li>Action: Incident
<li>entered by: amitra 
<li>description is: <p>During quiet time I ran this ladder.  Only CAP_ID error was seen.  Data from all chips were seen in RA and NN mode.  Need to investigate why this ladder has a problem during data taking.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Sep 28 11:35:48 2005 -->
<h3>Silicon Cooling Trip</h3> 
 
As per previous agreement with SPLs and Cool Cooling people, Stefano decided to run downstairs and check the status of one of the manual values: ISL West Supply. Upon closing the valve completely, a temperature spike pulled the interlocks, giving an ISL uber-trip, coupled with termination of flows on ISL West. Eva and I acknowledged the uber-trip, reestablished flows, and all seems well. 
<p> 
Given the opportunity (i.e. during a supervised access period), we would like to try and *slightly* increase/"tune" the flows to L00, as east flows have matched the west in approaching alarm limits. Currently, BOTH East and West L00 flow alarms are ignored  (not something which we would like to continue). We will wait for an access, since increasing the flows might have a dramatic effect on the pressures--not something we want to risk during data-taking.
<!-- Author: Eva H. & Jennifer :-) -->

<!-- Date: Wed Sep 28 11:38:38 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W5L2 
<li>problem n: 853 
<li>Status: needs_work
<li>Type: Chip_capid
<li>Action: Monitoring
<li>entered by: amitra 
<li>description is: <p>During quiet time I ran this ladder with DSVXMON.  This gave no errors at all.  Needs furthur investigation to understadn why this ladder was failing during data taking.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Sep 28 11:39:11 2005 -->
<pre>ISL West cooling supply flow tripped when Stefano Moccia was fiddling with the valves during the access.  Cooling alarms went off and the power supplies tripped for SVX/ISL/L00 as expected. </pre>
<!-- Author: Mark -->
<!-- Comment: Wed Sep 28 11;39;54 comment by...Mark -->
<pre>This happend at ~10:30.</pre>

<!-- Date: Wed Sep 28 11:48:39 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W0/1All 
<li>problem n: 1539 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Swap_FIB
<li>entered by: amitra 
<li>description is: <p>SB2W1L2 (e212) was having problems and a fibre swapped had shown this was a DAQ error.  So we decided to swap the FIB.  However we have not been able to test it as the Hardware Database is currently unavailable.</p><table border=1>
   <tr>
    <td>
     <b>IN:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/fibdb/DBreport.pl?serial=133">133</a>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/fibdb/DBreport.pl?prep="></a>
    </td>
   </tr>
   <tr>
    <td>
     <b>OUT:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/fibdb/DBreport.pl?serial=148">148</a>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/fibdb/DBreport.pl?prep="></a>
    </td>
   </tr>
  </table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W0/1&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Sep 28 11:50:57 2005 -->
<h3>FIB Swap Access</h3> 
 
<p>We took the access to diagnose SB2W1L2 (e212).  This ladder was not returning any data ata ll.  We did a fibre swap which sowed it was a DAQ problem.  We then swapped the FIB.  Unfortunatly we have not been able to test it as the Hardware Database is currently unavailable</p>
<!-- Author: Ankush, Marcel, Tuula, Mark -->
<!-- Comment: Wed Sep 28 13;59;00 comment by...Sebastian -->
FIB148 is being tested... no errors this far.
<!-- Date: Wed Sep 28 12:44:16 2005 -->
<h3> Old EVB SCPUs removed </h3> 
Markus hot removed the old CPUS this morning. So blame verything since then on him.  
<!-- Author: Marcel -->



<!-- Date: Wed Sep 28 15:34:54 2005 -->
<h3>Ckeck out of FIB133</h3> 
 
We used the quiet time to check that the data that  is coming out of the fib we swapped in is error free... it is, except for e212 which still gives no data. So, looks like no new problem was introduced, but the orignal one was not fixed yet. The next thing to try is to swap the RX.
<!-- Author: Ankush/Sebastian -->

<!-- Date: Wed Sep 28 15:52:28 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W1L2 
<li>problem n: 928 
<li>Status: needs_access
<li>Type: Chip_bit_error
<li>Action: Diagnosis
<li>entered by: amitra 
<li>description is: <p>With the Hardware Database back up we tested the ladder.  Unfortunaltly the FIB swap did not help. So it is clearly an RX swap is needed.</p>  <p>For the next access: swap the RX!</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->





<!-- Date: Wed Sep 28 18:46:31 2005 -->
<h3> Restarted the PSGUI </h3> 
We rebooted SVXINTER, restarted the PSGUI and someone killed a spider. <br> 
Guess who ?<br>  
<!-- Author: Shulamit, Ankush and Marcel -->


<!-- Date: Wed Sep 28 19:09:20 2005 -->
<h4> VRB firmware upgrade </h4> 
All the VRB's now have the latest and greatest VRB firmware ! 
<!-- Author: A Master and his apprentice -->


<!-- Date: Wed Sep 28 19:32:05 2005 -->
<h4> Problems with the Temp spy </h4> 
Ankush and I looked into it and found out, the the program on SVXIICON had lost connection to the RT server. We paged Miss Tripiakis and she advised us do "kill it and restart it " 
That fixed the problem. <br> 
  
<!-- Author: Ankush & Marcel and Miss Tripiakis -->

<!-- Date: Wed Sep 28 20:47:19 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W1L4 
<li>problem n: 1521 
<li>Status: needs_access_2hr
<li>Type: DRO_00F3
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: We ran this ladder again. Definetly Chip 8b gives no data and we frequently loose the whole chain after chip 8a. We tried several Rdriver/ISEL combinations, but without any luck. We should try a fiber swap to really confirm, that the problem is internal. This is however very likely.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W1&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Sep 28 20:52:32 2005 -->
<table><tr><td><a href=/elog/notebooks/silicon/Wed_Sep_28_2005_205228.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7583  align='top'></a></td><td><h4> Another quiet time study </h4> 
In the 30 minutes quiet time, Ankush and I attacked e414. We have successfuly seen the drop Readout problems, we seen during data taking. All chips after 8a disappear, could be a AVDD2 failure. Chip 8b has also a problem. We have to have a look at it again.</td></tr></table>
<!-- Author: Marcel & Ankush -->

<!-- Date: Wed Sep 28 21:19:51 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W1L2 
<li>problem n: 1445 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: Error is still coming and going. By looking at it, it is mainly chip 85 and 86, that have problems. May be worht looking at bit 7 during a light level measurement. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Sep 28 21:43:59 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W6L4 
<li>problem n: 74 
<li>Status: needs_observation
<li>Type: Chip_other
<li>Action: Sparse_out_chip
<li>entered by: marcel 
<li>description is: this looks good, should be monitored for a while... 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W6&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Sep 28 23:30:09 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7584&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7585  width='300' align='top'></a></td><td>SVTSPYMon plot for store #4411, initial luminosity 64E30.</td></tr></table>
<!-- Author: Tuula -->


<!-- Date: Thu Sep 29 00:01:47 2005 -->
<pre>Everything OK in SVXMON 
 
Status: OK 
--------------------------------------- 
Run 204827, Thu Sep 29 00:01:10 
SVX 
Status: OK 
ISL 
Status: OK 
L00 
Status: OK 
</pre>
<!-- Author: Tuula -->


<!-- Date: Thu Sep 29 06:56:35 2005 -->
<pre>Several trips in ISL. The time between trips were 5-12 minutes. First I guided the ACEs to recover the trips via phone. Everytime the recovery hold for a while. On the third time I asked them to hockerize the corresponding CAEN crate. When the fourth trip occured, I decided to go to the control room and asked them to run without Silicon. At the control room, I recovered the trips, and everything has been OK for 10 minutes. Asked the ACEs to start a new run with Silicon.</pre>
<!-- Author: Tuula -->
<!-- Comment: Thu Sep 29 07;11;29 comment by...Tuula -->
<pre>The tripping wedge was ISLB4W0.</pre>


<!-- Date: Thu Sep 29 07:51:24 2005 -->
<pre>L00B0W4/5 AVDDs keep turning pink.</pre>
<!-- Author: Tuula -->
<!-- Comment: Thu Sep 29 08;15;42 comment by...Tuula -->
<pre>Marcel says it is a FIB problem.</pre>

<!-- Comment: Thu Sep 29 08;47;26 comment by...Ankush/Tuula/Marcel -->
<p>We did some more tests and concluded the FIB was completly dead.  The neighbouring FIBs worked fine and we rebooted FIB07 just to make sure.  All those were OK.</p>
<p>The specific problem with FIB03 is it would not download the chip sequences.  So we couldn&#39t even get the chips to pass "SET DEFAULTS" in SVXDAQ.</p>
<p>So we took FIB03 out of the Hardware Database which means LBW4 & LB0W5 are currently out.  We have requested an access to replace the FIB....stay tuned folks !!</p>



<!-- Date: Thu Sep 29 12:25:51 2005 -->
<b>L00 bias scan</b> 
<p> 
startup notes: 
<p> 
Change prescales for L1 Two Track triggers:  bits 33, 51, and 61 prescale to 1 from 50, 20, and 12.  Change trigger bits 41 prescale to 1 from 2. Disable DPS. 
<p> 
nominal voltages in CAENvolts_09292005_0831AM.dat.  note:  wedges f84* and f85* (fib03) are out due to a dead fib. 
<p> 
luminosity was 1294.73/pb on 9/26/2005, approx. 200/pb since last L00 scan. 
<p> 
 
  
<!-- Author: boveia -->
<!-- Comment: Thu Sep 29 14;04;12 comment by...Ted  -->
<pre>those bits were from old trigger table. I will write down the details for current table 3_07, with trigger names as well as bits, after we are done.</pre>


<!-- Comment: Thu Sep 29 18;12;41 comment by...boveia -->
<pre>run 204839

vbias iev fev
=============
-90 15 34155
-85 34156 66557
-80 66558 99733
-70 99734 133229
-60 133230 167026
-50 167027 201261
-40 201262 236935
-30 236936 267932
-20 267933 299764
-10 299765 340326
0 340327 360868
-75 360869 397725
-55 397726 432368
-35 4323369 465477
-15 465478 498500

Bias voltages were then set to their nominal values.</pre>
<!-- Comment: Sun Oct  2 11;46;28 comment by...boveia -->
<pre>correction:  the second to last line should read
-35 432369 465477
</pre>
<!-- Date: Thu Sep 29 15:02:22 2005 -->
<pre>===== instruction on how to take bias scan events with trigger table 3_07 at luminosity around 17E30 ====== 
 
 
the following is what I did to setup the triggers for the bias scan. it seems to work well. 
 
 
 Thu Sep 29 14:49:25 Run 204839 ACTIVATE: RunSet: AAA_CURRENT Trigger: PHYSICS_3_07 [2,713,594]  - Lester x2080 
-- Thu Sep 29 14:59:12 comment by...Ted --   
for this run, I first set the prescale on L2_PS50_L1_TWO_TRK2 with PS1K. Then set 
L1_TWO_TRK2_PS4K set to PS5.  This gets us L1A to 7KHz, and L2A at 95Hz... the main L2A comes from L2_TWO_TRK2_D100 trigger (which should get good events for sili people).  This runs very well now. and we will take some good data first for silicon bias (30K L3As is what they want). </pre>
<!-- Author: Ted  -->
<!-- Comment: Thu Sep 29 18;13;30 comment by...boveia -->
<pre>Thanks Ted.</pre>
<!-- Date: Thu Sep 29 16:42:48 2005 -->
<h3>Silicon Access Time Update</h3> 
 
<p>Latest word from Willis is the access will be at 5AM (yikes!!),</p> 
  
<!-- Author: Ankush -->




<!-- Date: Thu Sep 29 20:33:01 2005 -->
<h3> f402 died horribly </h3> 
So this ladder kept tripping, so I hockerized crate 16 with no avail. Took it out of the Hardware Database, because it kept tripping.
<!-- Author: Marcel -->
<!-- Comment: Thu Sep 29 20;34;29 comment by...Marcel -->
<pre>
Thu Sep 29 20:08:24 CDT 2005                        TRIP: ISL  B4  W0 AVDD2 UnderVoltage
Thu Sep 29 20:08:47 CDT 2005                        success: Channel2 ISL B4 W0 to STANDBY
Thu Sep 29 20:08:52 CDT 2005                        TRIP: ISL  B4  W0 AVDD2 UnderVoltage
Thu Sep 29 20:11:47 CDT 2005                        success: Resetting trips
Thu Sep 29 20:11:55 CDT 2005                        success: Power Supply ISL B4 W1 ON
Thu Sep 29 20:12:01 CDT 2005                        success: Power Supply ISL B5 W5 ON
Thu Sep 29 20:12:10 CDT 2005                        success: Power Supply ISL B5 W1 ON
Thu Sep 29 20:12:17 CDT 2005                        success: Power Supply L00 EAST W1 ON
Thu Sep 29 20:12:31 CDT 2005                        success: Power Supply ISL B4 W0 ON
Thu Sep 29 20:12:36 CDT 2005                        TRIP: ISL  B4  W0 AVDD2 UnderVoltage
Thu Sep 29 20:12:48 CDT 2005                        success: Channel2 ISL B4 W0 ON
Thu Sep 29 20:12:54 CDT 2005                        TRIP: ISL  B4  W0 AVDD2 UnderVoltage
</pre>
So it kept tripping on Undervoltage. Let's give it some rest, before we start swapping Low Voltage Cables.

<!-- Date: Thu Sep 29 20:36:30 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L2 
<li>problem n: 1540 
<li>Status: needs_work
<li>Type: software_protection
<li>Action: Incident
<li>entered by: marcel 
<li>description is: This ladder kept tripping on AVDD undervoltage. Had to be taken out of the Hardware database. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Sep 29 22:19:07 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7586&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7586' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7587&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7587' width='300'></a></center>
<!-- Author: Sebastian -->
<!-- Comment: Thu Sep 29 22;31;40 comment by...Sebastian -->
<b>More on resonances...</b> as discuss with Ted and Jonathan, the plots above show the number of resonances per hour running
in the 24-26kHz rate vs run number (right). The plot in the left show the hours in that rate range. Do not like the binning?
<a href="http://www-cdf.fnal.gov/internal/people/links/SebastianGrinstein/SRC/rate_range_1.txt">Here</a>
is the data. Among other things, will check, at what time into the run the resonances occured.


<!-- Comment: Fri Sep 30 01;10;16 comment by...Ted  -->
<pre>need to talk to you to make sure I can understand what you really plot here... I am a bit confused with the title name and the comments.</pre>

<!-- Comment: Fri Sep 30 07;07;32 comment by...sebastian -->
the title is wrong, should say "in 24-26kHz" (L1A rate) range...

<!-- Date: Fri Sep 30 07:28:21 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W1L2 
<li>problem n: 928 
<li>Status: needs_observation
<li>Type: RX
<li>Action: Swap_RX
<li>entered by: amitra 
<li>description is: <p>We went in for an access and swapped the RX.  The RX swap was succesful and is now returning data. Now observe this during data taking so see how it performs.</p><table border=1>
   <tr>
    <td>
     <b>IN:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0668">0668</a>
    </td>
   </tr>
   <tr>
    <td>
     <b>OUT:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0145">0145</a>
    </td>
   </tr>
  </table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Sep 30 07:28:56 2005 -->
<h2> Access report (Team Alpha) </h2> 
We went in and swapped the FIB in b0fib03 Slot 17. This fixed all the problems concerning initialising the ladder. We moved in FIB 148 and swapped out  FIB 150. This guy needs testing.(Prelimiary diagnosis: <em> It is dead, Jim </em> )<br> 
The two wedges initalised fine so this should be ok.
<!-- Author: Shulamit and Marcel -->

<!-- Date: Fri Sep 30 07:30:55 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W4/5All 
<li>problem n: 1541 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Incident
<li>entered by: marcel 
<li>description is: We swapped the FIB for these two wedges. Monitor, if this did not introduce any new problems. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B1W4/5&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Sep 30 07:32:53 2005 -->
<h3 font-color="Red">Access Report: Delta Force</h3> 
 
<p>Tuula and I went in to fix SB2W1L2 (e212).  The previous access had shown the problem was with the DAQ pipe and swapping the FIB did not help. So we went back in and swapped the RX.</p> 
 
<p>After the swap, this ladder is now returning data.  The next step is to take the dead RX to FCC and test it at the BERT test stand.</p>
<!-- Author: Ankush & Tuula -->


<!-- Date: Fri Sep 30 13:14:55 2005 -->
<h2>Problems with the teststand</h2> 
This morning we were trying to test FIB150 that was taken out of the collision hall. However we could not sync the FFO glink. We tried usual things (software, slot, etc) but it did not work. Brought the FFO to FCC and it worked there. So we brought the SRCTM form FCC to the B0 teststand. We first tried the original SRCTM again and this time the glink would sync but the error LED would blink and the sync would be lost randomly. So it looked like a flakey connection. But we resetead the FF0 severeal times and it did not fix the problem. So we swapped the SRCTMs and everything worked fine. We tested the original SRCTM at FCC, but before we could conclude anything the 5V power supply of the VRB crate died (very likely unrelated to the SRCTM). FFC folks will replace the power supply. For now we leave the B0 testand SRCTM in FCC to test it.   
<!-- Author: Mark/Sebastian -->
<!-- Comment: Fri Sep 30 13;29;19 comment by...m/s -->
Note that we are not sure if there is something wrong with the SRCTM or if it was a wrongly seated board... 


<!-- Date: Fri Sep 30 13:40:18 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7588&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7589  width='300' align='top'></a></td><td><p>Store 4414: Initial Lumi: 67.86E100 (pretty poo-ey)<br> 
SVTSPYMon looks good and so does SVXMON.  So far so good.</p> 
 
</td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Fri Sep 30 14:57:54 2005 -->
PS num 4 turned itself off. We are taking data again.
<!-- Author: mark/sebastian -->


<!-- Date: Fri Sep 30 15:05:20 2005 -->
FIB150 (the FIB that was swapped out by Team Alpha) is currently being exercised by the High Speed Test in the the B0 teststand.  So far, after 0.5 million loops, there are 0 errors.  The test continues...
<!-- Author: Mark/Sebastian -->
<!-- Comment: Fri Sep 30 16;23;10 comment by...Marcel -->
well, it might well be, that we need Chips to find the problems. The DEM test is certainly good to exercise the Pipes, but what we saw, was a completely init failure and failure to download the sequences. 


<!-- Comment: Sat Oct  1 18;51;30 comment by...s -->
60 million loops and no errors.
<!-- Comment: Mon Oct  3 09;05;33 comment by...Mark -->
Ended the high speed test.  No errors after 70 million loops.  Will leave a note that the board should be tested at FCC when power supply is fixed.
<!-- Date: Fri Sep 30 22:31:20 2005 -->
<pre>Around 8 pm, crate 2 turned spontaneously off. I was advicing via phone, and it took for a while that I understood what was the problem (the ACE told about trips and PS GUI problems). Once I understood the problem, I asked the ACEs to hockerized the crate. That helped.</pre>
<!-- Author: Tuula -->
<!-- Comment: Fri Sep 30 23;54;53 comment by...Sebastian -->
In principle, if it just turns off, one should first try to turn it back on, there is no need to hockerize.


<!-- Comment: Sat Oct  1 10;55;22 comment by...Tuula -->
<pre>For those wedges, it was not possible to control HV in PS GUI. I asked the ACE to restart the PS GUI, but it didn't help. The ACE told everything (at least HV control buttons) was grey. So something else had to be done, and hockerizing the crate solved the problem. Maybe my diagnosis of the problem is not correct.</pre>
<!-- Comment: Sat Oct  1 11;17;58 comment by...s -->
That is correct then, if one can not communicate with the PS crate, then the crate has to be reset.
<!-- Date: Sat Oct 1 10:45:28 2005 -->
<pre>The wedges SB0W1,10,11, SB1W1,10,11 and SB2W0,1,10,11 tripped during ON to STANDBY transition. I adviced the ACE to turn them to STANDBY. </pre>
<!-- Author: Tuula -->
<!-- Comment: Sat Oct  1 10;52;37 comment by...Sebastian -->
Looks like PS #1 had a spontaneous transition to off at the time. So, the chips have to be initialized. 


<!-- Comment: Sat Oct  1 11;05;15 comment by...Tuula -->
<pre>OK. I called in. The monitoring ACE performed coldstart according to my instructions.</pre>



<!-- Date: Sat Oct 1 16:24:32 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7590&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7591  width='300' align='top'></a></td><td>BLM summary (entry in main elog is incorrect).</td></tr></table>
<!-- Author: Sebastian -->
<!-- Comment: Sat Oct  1 16;28;00 comment by...Sebastian -->
Quench during squeezing. Clean for us.

<!-- Comment: Sat Oct  1 16;30;52 comment by...s -->
of course, we were in STBY.

<!-- Date: Sat Oct 1 18:05:43 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W0/1All 
<li>problem n: 1539 
<li>Status: fixed
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>Once the hardware database returned, we tested the FIB and it worked fine.  Unforutunatly the ladder we were trying to fix (e212) still returned no data.</p>  <p>During a second access the RX was swapped and now everything works fine.  Closing this thread.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W0/1&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Oct 1 18:14:54 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W1L1 
<li>problem n: 1250 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: Diagnosis
<li>entered by: amitra 
<li>description is: <p>Current monitoring should go under 'NEEDS OBSERVATION' rather than 'NEEDS WORK'.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Oct 1 18:22:04 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L2 
<li>problem n: 1540 
<li>Status: needs_observation
<li>Type: software_protection
<li>Action: Added_hdwdb
<li>entered by: amitra 
<li>description is: <p>After a rest this ladder came back.. It has been up for 30 minutes with no problems and it run free in SVXDAQ after 10,000 events.</p>  <p>Let's see how it behaves during data-taking.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Oct 1 18:43:35 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W1L2 
<li>problem n: 1445 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>During quiet time I could get this ladder to give 00 sequence errors in NN mode at a rate of ~3 per 1,000 events.</p>  <p>A closer look at the DS Err Mon shows the errors are coming from the chip ID.  Every so often this ladder would give 0x instead of 8x for a chip ID; where x=5,6 or 7.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat Oct 1 19:18:58 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W2L0 
<li>problem n: 868 
<li>Status: needs_work
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>Looking more lcosely at the DS-Error-Mon, the errors are two-fold.  In RA mode Bit 5 is stuck.  In NN mode you have stuck CAP-ID.  Very odd indeed.</p>   
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W2&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat Oct 1 22:02:44 2005 -->
<pre>noise bias scan 
 
run 204974 
 
v iev fev 
-90 0 1540 
-80 1541 2517 
-70 2518 4065 
-60 4066 5021 
-50 5022 6029 
-40 6030 7018 
-30 7019 8030 
-20 8031 9026 
-10 9027 10028 
0 10029 11001 
-85 11002 12002 
-75 12003 13021 
-65 13022 13991 
-55 13992 15004 
-45 15005 16023 
-35 16024 17028 
-25 17029 18024 
-15 18025 19029 
-5 19030 19599 
 
bias voltages are back to their nominal configuration.</pre>
<!-- Author: boveia -->
<!-- Comment: Sat Oct  1 22;12;12 comment by...boveia -->
<pre>nominal CAENvolts.dat: CAENvolts_10012005_0545PM.dat</pre>

<!-- Date: Sat Oct 1 22:24:26 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L2 
<li>problem n: 1540 
<li>Status: needs_observation
<li>Type: AVDD2
<li>Action: Removed_hdwdb
<li>entered by: amitra 
<li>description is: <p>Damn...this ladder started tripping again.  Had to take this ladder out.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Oct 1 22:25:11 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W4L2 
<li>problem n: 1535 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: Monitoring
<li>entered by: amitra 
<li>description is: <p>Monitoring had shown this ladder was under depleated.  Increasing the bias by +3V helped to fully depleat the ladder. Bias voltages now made permanent.  Observe how this ladder behaves during data-taking.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W4&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat Oct 1 22:30:27 2005 -->
<h4>Quiet time studies</h4> 
 
<p>We made use of the post-quench quiet time to do my usual problem DB studies and Antonio did a noise bias scan.  This is rather good as we now have a on/off beam bias scasn close together in time.</p> 
 
<p>For the quiet time studies I brought back f402 which stayed up for about 4 hours.  However it then started tripping. So we had to take it out of the Hardware database.  I also used the quiet time to raise the bias voltages for f443 from 45/50 (bias0/bias1) to 48/53.</p>  
<!-- Author: Ankush, Antonio, Sebastian -->
<!-- Comment: Sat Oct  1 22;37;45 comment by...boveia -->
<pre>This should be f442...</pre>
<!-- Date: Sat Oct 1 22:36:33 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L2 
<li>problem n: 1540 
<li>Status: needs_access_4hr
<li>Type: AVDD2
<li>Action: Removed_hdwdb
<li>entered by: amitra 
<li>description is: <p>As this ladder keeps tripping, the suspicion is the power supply has developed a fault.  During the next long access and when we have a spare, we should investigate this ladder.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Sun Oct 2 08:19:59 2005 -->
<pre>Tevatron quenched again. It happened at flattop just before the squeeze, around 4 am.</pre>
<!-- Author: Tuula -->
<!-- Comment: Sun Oct  2 10;08;13 comment by...Sebastian -->
From JM: "The Tevatron lost another store before it got started. This time, pbar lifetime at 150 GeV was terrible in addition to enough losses during the squeeze to cause a quench. The priority will be to get the Tevatron working again." BLMs see <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=823&frame=2&anchor=04:50:50.011'>
here</a>.



<!-- Date: Sun Oct 2 17:09:51 2005 -->
There were significant increase in DVDD_B5W11L0 during no data taking, see <a href='http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=825&frame=2&anchor=16:24:32.040'> 
here</a>. According to Sebastian's instructions, I performed coldstart to see whether if configs. No problems there, and the pinkie disappeared.
<!-- Author: Tuula -->


<!-- Date: Sun Oct 2 23:01:27 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7592&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7593  width='300' align='top'></a></td><td>SVTSPYMon plot for store #4428, initial luminosity 109.7E30.</td></tr></table>
<!-- Author: Tuula -->


<!-- Date: Sun Oct 2 23:39:45 2005 -->
<pre>SVXMON Status: ERROR 
--------------------------------------- 
Run 205007, Sun Oct  2 23:34:03 
SVX 
Status: OK 
ISL 
Status: ERROR 
Silicon/I/B4/W1/L1/C1 
Silicon/I/B4/W1/L1/C2 
Silicon/I/B4/W1/L1/C13 
Silicon/I/B4/W1/L1/C14 
L00 
Status: OK 
 
I asked the DAQ Ace to HRR and the CO to restart the SVXMON. I'll wait for a while to see whether it helps or not. </pre>
<!-- Author: Tuula -->
<!-- Comment: Sun Oct  2 23;57;54 comment by...Sebastian -->
There is still not data comming from this ladder. I would suggest power cycling the wedge.

<!-- Comment: Sun Oct  2 23;59;49 comment by...Tuula -->
<pre>Yes, I already asked the monitoring ACE to power cycle the wedge.</pre>

<!-- Comment: Mon Oct  3 00;15;50 comment by...Sebastian -->
Looks like it worked:
<pre>
                                      f411c1c1 
     6152: 8f1776fc 8e1700f3 8c178d17 9a179b17 
     6156: 04330306 06050526 361f3506 38063722 
     6160: 480d4703 4a06491f 511250f3 5310520c 
</pre>




<!-- Comment: Mon Oct  3 01;16;28 comment by...Tuula -->
<pre>For the new run, the same ladder gave errors in SVXMON. According to Sebastians instructions, I reset the corresponding VRB. I gave the shift crew instructions that they should not page me if the yellow cells persist.</pre>

<!-- Comment: Mon Oct  3 01;45;32 comment by...Sebastian -->
Lets recapitulate: svxmon complains about data missing from f411.
Tuula asked to restart svxmon, did not fix it. We power cycled the wedge, and then looked at the incoming data. The data looks fine, but svxmon still complains. FIB is fine so it could be a VRB problem, so I asked Tuula to reset the corresponding VRB. Could
be that the raw event dump does not catch the problem in a few events (I remember something like this some time ago). Anyhow, the events look fine to me:
<pre>
                    f411c1c1 8f0c4dfc 8e0c00f3
     7236: 8c0c8d0c 2ef39b0c 30f32f09 6a0a6905
     7240: 6ca86b25 6e0c6d2e 9a0c6f06 5a03990c
     7244: 5c0b5b27 6d075d08 6f1d6e11 7103700a
     7248: 4202980c 44364311 46f045b4 487a47f0
     7252: 4a134923 b70c4bf3 290b2804 51f32af3
     7256: 5328520a 55f05488 576e56f0 59095820
     7260: b60c5af3 1c0b1b03 1e0a1d2d 29051ff3
     7264: 2b242a12 b50c2c08 62f06101 b40c63f3
     7268: 1e1a1d08 201b1fbb a30c2108 a10ca20c
     7272: 7f0ea00c f412c1c1
</pre> 
Or am I too tired to see the error? Anyhow, this is not
that important, lets look at it in the morning.

<!-- Comment: Mon Oct  3 02;00;10 comment by...Sebastian -->
<h3>JA!</h3>
I did looked at the problem DB, but should have looked more
carefully! The status of the ladder was recently (10/01/05) change
to needs observation... but previous entry says:
<pre>
Again, a change only to accomodate SVXMon, which shows the newly sparsed chips as yellow.
</pre>
So, no surprise the data looked fine (but no data was coming for these chips!)... anyhow, will change back to needs_work... 

<!-- Date: Mon Oct 3 02:02:16 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W1L1 
<li>problem n: 1250 
<li>Status: needs_work
<li>Type: Other
<li>Action: Diagnosis_update
<li>entered by: sebastian 
<li>description is: mark as needs work to avoid problems with svxmon for the sparsed out chips. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Mon Oct  3 06;17;37 comment by...Ankush -->
<h4>Ooops...my bad !!</h4>

<p>I guess I&#39m responsible for keeping you two up...sorry.  But could someone remind me why this had to go under "NEEDS_WORK". My second point is we should really fix the problem in SVXMON. Having to put everything under "NEEDS_WORK" just to accomodate SVXMON is silly.</p>

<!-- Date: Mon Oct 3 08:35:50 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W8L0 
<li>problem n: 1497 
<li>Status: needs_longterm_monitoring
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: boveia 
<li>description is: I can't see this error.  Watch it for awhile then declare it fixed. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W8&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Oct 3 08:44:08 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W4L2 
<li>problem n: 1270 
<li>Status: fixed
<li>Type: Other
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Channel 113 on chip 5 is hot.  I've masked it off in ADCMon. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W4&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Oct 3 08:53:03 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W5L4 
<li>problem n: 1502 
<li>Status: fixed
<li>Type: Chip_other
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Fixed. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W5&layer=L4">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Mon Oct 3 09:08:31 2005 -->
<br> 
<b>Monitoring summary</b> 
<p> 
Two bias scans (L00 run 204839, SVX run 204974.) 
<p> 
Previous problems:<br> 
e280 bit error. now gone.<br> 
e142 bump.  hot channels masked off.<br> 
e554 bit 7 looks fixed.<br> 
<p> 
Also, I took the L00 bias scan as an opportunity to test the new SVXMon.  While it was able to see the effects of unbiased ladders, the overall normalization was screwed up, and the automatic comparison which uses this normalization failed to find a problem.  This will be fixed in the next version. 
<p>
<!-- Author: boveia -->


<!-- Date: Mon Oct 3 09:13:44 2005 -->
<pre>Week summary 
 
Monday: 
 Firmware upgrade for b0svx06/07 
 New store with initial luminosity 120E30 
 
Tuesday: 
 Warning on L00 Flow loops 
 Small spike in LOSTPB 
 Persistent pinkies in VBIAS 
 Studies of resonancies 
 High beam losses, Silicon to standby 
 CAEN crate 8 turned spontaneously off 
 Tevatron quenched 
 Controlled access, light levels of e493 checked 
 Quiet time studies 
 
Wednesday 
 Tevatron quenched during shotsetup 
 Access, fibre swap and FIB swap for SB2W1L2 
 Silicon cooling trip 
 Quiet time studies 
 New store with initial luminosity 64E30 
 
Thursday 
 ISLB4W0 kept tripping, removed from hardware database 
 FIB03 died  
 L00 bias scan 
 
Friday 
 Access: RX swap for SB2W1L2, FIB swap in b0fib03 Slot 17 
 New store with initial luminosity 67.8E30 
 CAEN crate 4 turned spontaneously off 
 CAEN crate 2 turned spontaneously off 
 
Saturday 
 CAEN crate 1 turned spontaneously off during ON-STANDBY 
         transition 
 Quench during squeezing 
 Quiet time studies 
 
Sunday 
 Quench before the store got started 
 New store with initial luminosity 109.7E30 
 SVXMON error 
 
Monday 
 SVXMON error still there  
 </pre>
<!-- Author: Tuula -->
<!-- Comment: Mon Oct  3 09;24;46 comment by...Sebastian -->
mm? The svxmon error is gone:
<pre>
Run 205009, Mon Oct  3 09:22:10
SVX
Status: OK
ISL
Status: OK
L00
Status: OK
</pre>
See a couple of entries above.