<!-- Title: 10:06:55  Mon Nov  7 2005 -->
<!-- Crewchief: Marcel (Ronin) -->
<!-- Op1: Shulamit (Padawan) -->
<!-- Op2: Ankush(Popsy-SPL) -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
Der Mohr hat seine Schuldigkeit getan, der Mohr kann gehen


<!-- Date: Mon Nov 7 13:01:04 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7823&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7824  width='300' align='top'></a></td><td><h4>Pinkie in  SB1W1L3</h4> 
 
<p>This ladder just gave a pinkie in AVDD.  I asked the shift crew to do an HRR to reconfig the chip chain.  But no effect.  I went over to SVXMON and looked at the strip plots and they look fine.</p></td></tr></table>
<!-- Author: Ankush -->
<!-- Comment: Mon Nov  7 13;37;41 comment by...Ankush -->
<p>Just had a quick look at the cardEditor and the last chip ID is set to 32 (Decimal); 20 (Hex). This means it reads out all chips.  So no chips were chopped.  So this increase is not the reactivation of a new chip.  Could be readback problem?</p>
<!-- Date: Mon Nov 7 13:05:39 2005 -->
<h4>Magic drop in B0PAGC</h4> 
 
<p>Yesterday B0PAGC was very high (>20KHz).  So I took the descision to take silicon out.  The new store came in around 10pm last night and over night the B0PAGC had the same behaviour.  Before I went to lunch B0PAGC went up to 18KHz.  Then I came back from lunch and magically B0PAGC dropped dramitcally down to 2KHz.  So far no explanation in the MCR e-log.</p> 
 
<p>See the entry in the <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=932&frame=2&anchor=12:32:49.359'>
CDF Shift E-log</a>.</p>
<!-- Author: Ankush -->



<!-- Date: Mon Nov 7 14:21:37 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7825&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7826' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7827&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7828' ></a></center>
<!-- Author: Ankush -->
<!-- Comment: Mon Nov  7 14;25;59 comment by...Ankush -->
<h4>...well...that was a smart thing to do</h4>

<p>SB1W1L3 was giving a consistent PINKIE.  As SVXMON looked fine and no chips were chopped I though this could be a readback problem.  So I hockerised crate 1.  In doing so, SB1W1L3 stayed pink and at the same level as before.  In addition SB0W1L2 went pink aswell.  I tried a second CONFIG but this did not help.</p>

<p>SB0W1L2 is an AVDD2 ladder, so this guy may jump back to normal later on.  However I'm unsure why SB1W1L3 jump to a higher value.</p>


<!-- Comment: Mon Nov  7 14;39;33 comment by...Ankush -->
<p>I've currently put these to to IGNORE in IMON to avoid confusing the ACES.  But I have left the history plots up.</p>
<!-- Date: Mon Nov 7 14:39:29 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7829&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7829  width='300' align='top'></a></td><td>AVDD current history of e113. So the current value is pretty much out of bounds.  
 
</td></tr></table>
<!-- Author: Marcel -->



<!-- Date: Mon Nov 7 15:06:33 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7830&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7831  width='300' align='top'></a></td><td> <p>Well at least this ladder went back to normal.</p></td></tr></table>
<!-- Author: Ankush -->
<!-- Comment: Mon Nov  7 15;08;06 comment by...Marcel -->
as I have foreseen it ...


<!-- Date: Mon Nov 7 15:12:43 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7832&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7832' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7833&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7833' width='300'></a></center>
<!-- Author: Marcel -->
<!-- Comment: Mon Nov  7 15;15;29 comment by...Marcel -->
The previous an the current store. Although both kind of show the same behaviour of the Abort Gpa losses, it is interesting to note, that for 4490, also the B0AAGC is way more nosiy. At approx 12:15, something happened. Suddenly  B0PAGC drops down by a lot. <br>
Not clear, what happened there.

<!-- Comment: Mon Nov  7 15;32;42 comment by...Ankush -->
<p>Rick figured it out.  Someone started moving collimators. See<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=932&frame=2&anchor=15:07:34.672'>
CDF shift e-log</a>.</p>



<!-- Comment: Mon Nov  7 19;57;08 comment by...Ankush -->
<p>There are furthur comments in the <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=932&frame=2&anchor=15:07:34.672'>
CDF Shift e-log </a> from Willis and Ron Moore.</p>
<!-- Date: Mon Nov 7 15:13:51 2005 -->
<h4>Hooray for Hollywood</h4> 
 
<p>Jason brought a film crew into the Control Room and transformed Peter and me into film stars!!!.  I had to say:</p> 
 
<em>the abort gap loosses induced a drop in the analog power supply of the detector. So I had to reset the detector to fix it. It looks stable now but we should monitor the situation for the next 8 hours.</em> 
 
<p>I know...complete BS but it was fun to lie to high school kids.  The only pity was I did't get to use my Flash Gordon line:</p> 
 
<em>Check the angular vector of the moon</em> 
 
<p>now will they have to subtitle me?</p>
<!-- Author: Ankush -->
<!-- Comment: Mon Nov  7 15;16;54 comment by...Vultan -->
Well, who wants to live forever anyway ...



<!-- Date: Mon Nov 7 16:24:15 2005 -->
Store number 4490 quenched at F48. 
ColdStart OK. 
<!-- Author: Marcel and Shulamit -->
<!-- Comment: Mon Nov  7 17;23;16 comment by...The Ronin -->
From Jim Morgan
<pre>
The store was lost at the end of the day shift with a RFSUM abort and quench at F48L. TRF4 stopped putting out RF and TRF1 had already tripped earlier in the store. Normally we would expect a clean abort if the RF drooped so experts are checking orbits, beam loss etc. TRF1&4 are both pbar stations, and the loss was from pbars, so TRF4 may have pushed pbars into the abort gap before the abort was pulled
</pre>
<!-- Date: Mon Nov 7 16:47:02 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W1L0 
<li>problem n: 1570 
<li>Status: needs_urgent_monitoring
<li>Type: Chip_capid
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Chip a0 has a CAP id error for 16% of run 206671.  Spurious? 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W1&layer=L0">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Mon Nov 7 17:43:32 2005 -->
<pre>Bringing up ladder f311: 
Brought it back to the hardware DB, tried to put it to standby but the supply decided to ramp voltages to 'ON' without being instructed to. The suspicion was that supply configuration was hammered by beam. We hockerized crate 11 and everything turned back OK. We ran 5000 events and did not see any problem.</pre>
<!-- Author: Marcel and Shulamit -->

<!-- Date: Mon Nov 7 17:45:28 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W1L1 
<li>problem n: 1568 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: Added_hdwdb
<li>entered by: shulamit 
<li>description is: was brought back succesfully, turned out to be a CAEN SEU, fixed by hockerization 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Nov 7 17:48:51 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7834&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7835' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7836&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7837' ></a></center>
<!-- Author: Shulamit and Marcel -->
<!-- Comment: Mon Nov  7 17;49;33 comment by...Shulamit and Marcel -->
Bias currents for Bias0/1. Both are stable and we decided to integrate the ladder again in the Database


<!-- Date: Mon Nov 7 19:11:07 2005 -->
<center><a href='/elog/notebooks/silicon/Mon_Nov__7_2005_191022.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7840' ></a><a href='/elog/notebooks/silicon/Mon_Nov__7_2005_191051.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7843' ></a></center>
<!-- Author: Ankush -->
<!-- Comment: Mon Nov  7 19;15;30 comment by...Ankush -->
<h4>Checking out SB1W1L3 (e113)</h4>

<p>SB1W1L3 had been consistently had AVDD at 855uA even after hockerising the crate.  So I ran the ladder for 10,000 events in NN (left) and RA (right) mode.  No errors were reported by SVXDAQ and the histograms look fine (see above).</p>

<p>The ladder seems to be fine.  So why does it read high?</p>

<p>For the moment I'll leave it ignored to avoid MPC getting paged about it.  But we should observe how this ladder behaves during the next store.</p>

<!-- Comment: Mon Nov  7 19;23;24 comment by...Ankush -->
<pre>...and I did a COLDSTART when I finished to put the Silicon back to a default state.</pre>



<!-- Date: Tue Nov 8 01:42:13 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7844&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7845  width='300' align='top'></a></td><td>Store 4492 came in, pretty high lostp at the beginning, which was going down rapidly. Initial Luminosity was 123E30, SVT looks ok</td></tr></table>
<!-- Author: Marcel -->
<!-- Comment: Tue Nov  8 01;57;28 comment by...Marcel -->
data for e113 looks good as well


<!-- Date: Tue Nov 8 10:18:01 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7846&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7846' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7847&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7847' width='300'></a></center>
<!-- Author: Marcel -->
<!-- Comment: Tue Nov  8 10;19;57 comment by...Marcel -->
Losses for the proton and pbar side for the last 20 days, with B0ILUM as orientation when CDF is live. So erveything started end of October, first we had huse B0AAGC losses, that got fixed and now we  are struggeling with B0PAGC.


<!-- Date: Tue Nov 8 11:34:18 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7848&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7848  width='300' align='top'></a></td><td>Abort Gaps in Detail. For the last few stores, the B0PAGC follows AGIGI2 actually very well. However, E0LABT, which is an alternative Counter at E0, does not for the current store. It looks like, as if this counter is either dead or there are no losses at E0</td></tr></table>
<!-- Author: MArcel -->


<!-- Date: Tue Nov 8 13:30:17 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7849&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7849  width='300' align='top'></a></td><td>The gaps during this store, AGIGI2 is nicely following B0PAGC</td></tr></table>
<!-- Author: Marcel -->


<!-- Date: Tue Nov 8 16:33:17 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7850&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7850  width='300' align='top'></a></td><td>History for Store 4492</td></tr></table>
<!-- Author: Marcel -->
<!-- Comment: Tue Nov  8 16;52;08 comment by...Ankush -->
<p>This is the excerpt from the MCR e-log:</p>

<pre>
16:10:22-   CDF is turning back on. Dean and Jerry found that one of the collimators stopped prematurely at the beginning of the store. Things are looking better halo-wise. (Entry started on Tue Nov 8 16:10:01 2005) - CE
</pte>


<!-- Comment: Tue Nov  8 18;09;38 comment by...fixer -->
</pre>
<!-- Date: Tue Nov 8 18:01:20 2005 -->
<h4>Update of shutdown <em>to-do</em> list</h4> 
 
<p>I've updated the March '06 shutdown <em>to-do</em> list. You can check it out 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 if there's anything missing, already done or incorrect, or needing to be added.</p>  
<!-- Author: Ankush -->

<!-- Date: Tue Nov 8 18:07:08 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W3L1 
<li>problem n: 1558 
<li>Status: fixed
<li>Type: AVDD
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: No problems seen in the last two weeks, declare it fixed  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W3&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Nov 8 18:08:14 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W3All 
<li>problem n: 1523 
<li>Status: fixed
<li>Type: Wedgewide_other
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: The whole wedge is running fine. Declare it fixed 
<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 Nov 8 18:12:43 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W3L3 
<li>problem n: 1518 
<li>Status: fixed
<li>Type: Chip_other
<li>Action: Incident
<li>entered by: marcel 
<li>description is: No problems with the init readback anymore, declare it fixed 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B1W3&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Nov 8 18:20:39 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W1L2 
<li>problem n: 928 
<li>Status: needs_work
<li>Type: RX
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: The RX swap did the trick concerning the no-data problem, the original problem is still there, probably a candidate for the bit-booster 
<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 Nov 8 18:24:48 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 guy still has intermittent freakouts...not clear what is troubling this ladder. Could try another quiet time attack ... 
<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 Nov 8 18:26:52 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: Let's try one more time, I am feeling lucky ... 
<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 Nov 8 18:27:18 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W7All 
<li>problem n: 1517 
<li>Status: fixed
<li>Type: VDOIM
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: The swap was succesful, no problems with this wedge since the swap 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W7&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Nov 8 18:29:46 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W7L0 
<li>problem n: 1544 
<li>Status: fixed
<li>Type: AVDD
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: No problems... fixed 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W7&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Nov 8 18:29:46 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W7L2 
<li>problem n: 1545 
<li>Status: fixed
<li>Type: AVDD
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: No Problems, fixed 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W7&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Nov 8 18:31:00 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W7L2 
<li>problem n: 1546 
<li>Status: fixed
<li>Type: DVDD
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: No Problems, fixed 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W7&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Nov 8 18:35:08 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W7L3 
<li>problem n: 1547 
<li>Status: fixed
<li>Type: DVDD
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: no problems, fixed 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W7&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Nov 8 18:37:13 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W7L1 
<li>problem n: 1549 
<li>Status: fixed
<li>Type: AVDD
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: fixed 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W7&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Nov 8 18:38:57 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W2L3 
<li>problem n: 436 
<li>Status: needs_longterm_monitoring
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: Put it to longterm monitoring ... error is still intermittent, but has disappeared for a while 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Nov 8 18:41:21 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L0 
<li>problem n: 1038 
<li>Status: fixed
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: chip 5 shows data and currents are fine 
<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 Nov 8 18:43:51 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W1L2 
<li>problem n: 1445 
<li>Status: fixed
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: Problem has disappeared, declare it fixed for the time being 
<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: Tue Nov 8 18:47:34 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W2/3All 
<li>problem n: 1000 
<li>Status: needs_observation
<li>Type: DRO_00F3
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: no new problems introduced ... fixed 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B2W2/3&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Nov 8 18:49:40 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W11L2 
<li>problem n: 1522 
<li>Status: fixed
<li>Type: BIAS
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: fixed 
<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: Tue Nov 8 18:52:38 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W11L3 
<li>problem n: 1361 
<li>Status: needs_observation
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: Still small rate of errors (<0.1%). Keep an eye on it 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W11&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Nov 8 21:07:03 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7851&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7851  width='300' align='top'></a></td><td><h3>BIG GLITCH!!!</h3></td></tr></table>
<!-- Author: Ankush et al -->
<!-- Comment: Tue Nov  8 22;08;31 comment by...Ankush/Marcel/Shulamit -->
<p>Maybe <em>happy</em> is missing Sebastian</p>
<!-- Comment: Tue Nov  8 22;20;29 comment by...Ankush, Marcel, Shulamit -->
<h2>While on shore leave...</h2> 
The entire SVX tripped on DVDD overcurrent. L00 and ISL were not affected. First diagnosis excluded cooling trips, none of the cooling interlocks was activated. Next suspicion is a clock glitch that only affected SVX. SRC pulled fatal error - 2 L1 A to the same buffer, then we tripped. At the same time the L2 also showed significant problems. The theory is a screw up between the TS and the SRC.However, we cannot prove this. <br>
We first check out few ladders with svxdaq and then turned the SVX back to standby. Went through a coldstart with 5000 events without any problem. B2W9L0 needed few iterations to come up. 


<!-- Comment: Tue Nov  8 22;25;14 comment by...The three musketeers -->
an excerpt from the error log:
<pre>
(MLW) b0dap73.fnal.gov:Thread-24:Nov 8, 2005 8:15:06 PM->Inhibit flag SET 
(MLW) b0dap73.fnal.gov:Thread-24:Nov 8, 2005 8:15:10 PM->Inhibit flag CLEAR 
(MLE) b0dap73.fnal.gov:Thread-24:Nov 8, 2005 8:39:19 PM->SlowControl Icicle heart beat not updated since 2005-11-08 20:20:54.0
(MLW) b0dap73.fnal.gov:Thread-24:Nov 8, 2005 8:42:38 PM->Inhibit flag SET 
(MLE) b0dap73.fnal.gov:Thread-24:Nov 8, 2005 8:42:39 PM->FrontEnd Error: FCAL_00 CMX_01 
(MLW) b0dap73.fnal.gov:Thread-24:Nov 8, 2005 8:42:39 PM->Received error message: errmon Not a state HaltRecoverRun 1 crate/s: b0fcal00(26),  in error. [RXPT]
(MLE) b0dap73.fnal.gov:Thread-24:Nov 8, 2005 8:42:39 PM->Requested Halt-Recover-Run issued (errmon)
(MLE) b0cmx01:Messenger:Nov 8, 2005 8:42:43 PM->Runtime Error 1, Event 3818245: See nonsequential event number (old 4, new 15) in L2 message
CT: 2005.11.08 20:42:43
42'43" 1 crate/s: b0fcal00(26),  in error. [RXPT]
(MLE) b0svx00:Messenger:Nov 8, 2005 8:42:44 PM->Silicon Resonator: Sl 16 Ch 9 -> e074: Bytes: 00156

(RC)   20:42:49 Halt -> HALTED
(RC)   20:42:56 Recover -> RECOVERED
(RC)   20:42:58 Run -> ACTIVE
(MLW) b0xtrp00:Messenger:Nov 8, 2005 8:43:07 PM->No new event ...
(MLW) b0dap73.fnal.gov:Thread-24:Nov 8, 2005 8:43:23 PM->Inhibit flag CLEAR 
(MLW) b0xtrp00:Messenger:Nov 8, 2005 8:43:23 PM->No new event ...
(MLE) b0dap73.fnal.gov:Thread-24:Nov 8, 2005 8:43:24 PM->FrontEnd Error: VRB_SVX_02 
(MLW) b0dap73.fnal.gov:Thread-24:Nov 8, 2005 8:43:27 PM->Inhibit flag SET 
CT: 2005.11.08 20:43:28
43'28" 1 crate/s: b0svx02(112),  in error. [RXPT]
(MLE) b0svx03:Messenger:Nov 8, 2005 8:43:31 PM->Silicon Resonator: Sl 12 Ch 4 -> e344: Bytes: 00092
e340

(MLE) b0svx00:Messenger:Nov 8, 2005 8:43:30 PM->Silicon Resonator: Sl 10 Ch 8 -> e033: Bytes: 00050

(MLE) b0svx02:Messenger:Nov 8, 2005 8:43:31 PM->Silicon Resonator: Sl 16 Ch 9 -> e274: Bytes: 00098

CT: 2005.11.08 20:43:31
43'31" b0svx02:Messenger:Nov 8, 2005 8:43:31 PM->SRC Fatal Error:Sl 6 2 L1A to Buff 
 -->  
 Additional Information: 

 Attention !!!. FERML_SRC_FATALITY ERROR !!! 
 
 SRC Fatal Error from b0svx02: Sl 6 2 L1A to Buff 
 
 - HALT the run                   
 - record any relevant information in e-log     
 - RECOVER - RUN     
[MLE]
CT: 2005.11.08 20:43:32
43'32" 1 crate/s: b0svx02(112),  in error. [RXPT]
(RC)   20:43:33 Halt -> HALTED
</pre>
<!-- Comment: Tue Nov  8 23;17;23 comment by...The Ronin -->
On another note, Shulamits new best buddy is e290
<!-- Comment: Wed Nov  9 06;32;11 comment by...Sebastian -->
<pre>just for reference this was during run 206840.</pre>
<!-- Date: Tue Nov 8 22:22:26 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7852&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7853  width='300' align='top'></a></td><td>DVDD of SB4W0L1 shows a big spike at the time of the trip.</td></tr></table>
<!-- Author: Shulamit -->


<!-- Date: Tue Nov 8 22:52:50 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W1L3 
<li>problem n: 1571 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>I bumped the AVDD for this ladder.  Should check in a weeks time this is stable.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>823.345</td><td>823.345</td></tr>
<tr><td><b>Lower</b></td><td>810</td><td>810</td></tr>
<tr><td><b>Upper</b></td><td>835.0</td><td>860.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W1&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Nov 8 23:13:52 2005 -->
<h3> b0svx03 took some time off </h3> 
This CPU got somehow unhappy and needed two reboots to come back. On the same timescale b0evme20 got very unhappy ...<br> 
Looks like something happened in this crate
<!-- Author: Marcel -->



<!-- Date: Tue Nov 8 23:19:55 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7860&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7860' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7859&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7859' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7858&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7858' width='300'></a><a href='/elog/notebooks/silicon/Tue_Nov__8_2005_231818.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7857' ></a></center>
<!-- Author: Ankush -->
<!-- Comment: Tue Nov  8 23;21;11 comment by...Marcel, Shulamit, Ankush -->
<p>We did a short run to check Silicon was giving back data. Here are the SVXMON plots.  All seems good.</p>
<!-- Date: Tue Nov 8 23:20:45 2005 -->
<h4> Meanwhile ...</h4> 
From MCR elog: 
<pre> 
C:PAK1 is in alarm with PS within limits fault, it is still has high voltage ~35KV 
</pre> 
Called up MCR, they said, the kicker is still ok only the digital readback is bad
<!-- Author: Marcel -->



<!-- Date: Wed Nov 9 06:25:00 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7861&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7861  width='300' align='top'></a></td><td>The complete Store 4492. After moving some collimators in their right position (around 1600), B0PAGC looks very reasonable. There was an RF strip around 2100, TRF1 was the culprit. AGIGI2 was still rising, but somehow leveled around 5.7. Let's see the next stores behaviour...</td></tr></table>
<!-- Author: Marcel -->
<!-- Comment: Wed Nov  9 07;17;06 comment by...ronmoore -->
<pre>FYI - after studies, the store was terminated with T:AGIGI2 ~ 8.3 E9.</pre>
<!-- Date: Wed Nov 9 06:48:51 2005 -->
<h4> VME Powersupply Swap in b0svx00 </h4> 
Roberto and Dervin swapped the VME power supply for b0svx00, which had some problems, that may have caused troubles in the future ...
<!-- Author: Marcel -->


<!-- Date: Wed Nov 9 07:49:27 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W2L0 
<li>problem n: 1548 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: This guy developed intermittent bit0 errors. Tried to reproduce during quiet time, but did not succeed 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B2W2&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Nov 9 09:24:52 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W9L3 
<li>problem n: 1511 
<li>Status: needs_longterm_monitoring
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: we were not succesful in trying to reproduce the problem ... We should keep an eye on it to see, if the problem is coming back 
<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: Wed Nov 9 09:28:26 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W5L0 
<li>problem n: 840 
<li>Status: needs_longterm_monitoring
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: shulamit 
<li>description is: could not reproduce the error.... 
<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 Nov 9 11:08:09 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W4L1 
<li>problem n: 1170 
<li>Status: needs_urgent_monitoring
<li>Type: RX
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Bit 6 low (0x40->0x00) returned for 10% of run 206867. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W4&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Nov 9 13:05:16 2005 -->
<h3>The Great Silicon Bet</h3> 
 
<p>Next week, Marcel is supposed to be on vacation. David and I are putting together a betting pool to see how long it will take before Marcel reads the e-log while on vacation.  The <em>official</em> betting post is in the Silicon office.  Please enter your bets.</p> 
 
<h4>DUMRE : Days Until Marcel Reads E-log</h4> 
<table border="1"> 
<tr> 
<td>0</td> <td>1</td> <td>2</td> <td>3</td> <td>4</td> 
<td>5</td> <td>6</td> <td>7+</td> 
</tr> 
<tr> 
<td> - </td> <td> - </td> <td>David</td> <td>Ankush</td>  
<td> - </td> <td> - </td> <td> -   </td> <td>   - </td> 
</tr> 
</table>
<!-- Author: Trouble Maker -->

<!-- Date: Wed Nov 9 13:15:10 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W9L4 
<li>problem n: 1557 
<li>Status: fixed
<li>Type: AVDD
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: This ladder has a jumper failure, so it will react badly to high trigger rates. If it is not run with 45 kHz, it will be fine 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W9&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Nov 9 13:19:49 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L1 
<li>problem n: 1561 
<li>Status: fixed
<li>Type: AVDD
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: swap succesful, limits stable. Fixed 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Nov 9 13:24:13 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W1L4 
<li>problem n: 1521 
<li>Status: unfixable
<li>Type: DRO_00F3
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: Probably both 89 and 8b are unfixable, but the rest of the ladder seems to be ok. 
<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 Nov 9 13:49:13 2005 -->
<h4>New IMON LImits loaded</h4> 
 
<p>Dean has produced new IMON limits which have now been loaded into IMON.  Should keep an eye on IMON...just in case we start to lots of PINKIES.....but it should be OK.  I had to manually reset AVDD for SB1W1L3 (e113) as it did not know about the recent incease in AVDD.</p>
<!-- Author: Ankush & Marcel -->


<!-- Date: Wed Nov 9 14:16:39 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7862&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7862  width='300' align='top'></a></td><td>SVT spymon plot, store 4494, initial luminosity 119.28</td></tr></table>
<!-- Author: Shulamit -->


<!-- Date: Wed Nov 9 14:30:37 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7869&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7870  width='300' align='top'></a></td><td><p>After loading in Dean's new IMON limits we noticed this DVDD for SB1W9L0 (e180) was yellow.  The DVDD currernt was very low; the reading was hovering around zero. This cannot be the correct reading as it should be around 100.0. The PS was hockerized but the DVDD current was still low. </p> 
 
<p>Once we started Data taking, the current went up to around 15.0 But still pretty low for DVDD. However the stip plots from SVXMON were healthy.  So the suspicion this a read back problem from the CAEN, or rather a pedestal problem.</p></td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Wed Nov 9 14:31:19 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7871&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7871  width='300' align='top'></a></td><td>p losses at the beginning of store. Had sharp rise in LostP at the beginnig, however after like 5 minutes it leveled off and came back down. After leveling off, we have included the Silicon</td></tr></table>
<!-- Author: Shulamit -->


<!-- Date: Wed Nov 9 14:41:44 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7874&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7874  width='300' align='top'></a></td><td>P losses of B0, E0, D0 at the beginning of the store - all seem pretty much the same with high losses rise at the beginning and went down and became stable later.</td></tr></table>
<!-- Author: Shulamit -->


<!-- Date: Wed Nov 9 14:52:14 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7875&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7875  width='300' align='top'></a></td><td> </td></tr></table>
<!-- Author:   -->
<!-- Comment: Wed Nov  9 14;56;32 comment by...Ankush -->
<h4>Bias1 of IB4W0L4 (f404) is reading 0.0</h4>

<p>After loading in Dean's new IMON limits we noticed the Bias1 for IB4W0L4 was reading zero.  By plotting the bias history, this ladder has been reading zero since DS-Day 1752/ 19 Oct 2005. Coincidently, we went in for an access the day before to examine IB4W0L2 (f402).</p>

<p>Looking at ADCMON, you can't easily tell if the ladder if the ladder looks unbiased.  Now the question is, is this real or is it a read back problem?</p>

<!-- Comment: Wed Nov  9 14;57;15 comment by...Shulamit, Marcel and Ankush -->
<pre>Sorry, I should have added Marcel and Shulamit.</pre>


<!-- Comment: Wed Nov  9 18;55;40 comment by...boveia -->
<pre>ADCMon doesn't say much because the occupancy is pretty low to begin with.  I also tried daqana but didn't learn anything other than that the dnoise looks similar among chips from the first halfladder (chips 0-7, except chip 3 which had lower dnoise) and among chips from the second halfladder.

Did you try comparing the dnoise distributions in SVXDAQ before and after bias?  You'd expect the dnoise to drop when succesfully biased.  If I remember right, bias1 corresponds to chips 0-3, 12-15.  If that's right the daqana dnoise distributions disfavor a bias problem.</pre>
<!-- Comment: Thu Nov 10 09;31;34 comment by...Jen -->
<h3>IMPORTANT NOTE</h3> We didn't just go in on Oct 18 to have a look at the supply.  On Oct 18 we SWAPPED the IB4W0 supply with the IB5W3 supply.  And if you check the PDB on f534, you see that back on 12/06/02 BIAS0 started reading back 0 bias current.  But they declared it ok b/c the physics from that ladder looked fine.  Looks like this is a "known" feature of the supply that we just didn't realize.  What's the BIAS0 current on f534 been doing since the swap?<br>
<!-- Date: Wed Nov 9 17:31:28 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7881&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7882  width='300' align='top'></a></td><td><h4>Bias for IB0W3L2</h4> 
 
<p>The Bias0 line for IB0W3L2 went pink.  However looking at the history, it doesn't look like the usual <em>Bias current just went over its upper IMON limit</em>.  You can see the current following an RC risetime type of curve.  So I am going to see how it behaves before changing any limits.</p></td></tr></table>
<!-- Author: Ankush -->
<!-- Comment: Wed Nov  9 17;35;51 comment by...Ankush -->
<p>Just looked in the problem-DB and saw the upper IMON limit was changed to 380.  Guess it wasn't picked up the new IMON limits.  I've changed it now.</p>



<!-- Date: Thu Nov 10 07:29:50 2005 -->
<h4>Mad-CAEN</h4> 
 
<p>At 11:43pm, lost communication with CAEN PS 7 (MW Bottom-Top).  ACE hockerized the crate and powered up the wedges.  No problems since.</p> 
<!-- Author: Ankush -->


<!-- Date: Thu Nov 10 08:30:26 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7885&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7885  width='300' align='top'></a></td><td><h4>Apparaently Tevmon went red on RFSUM and RFSUMA</h4> 
 
<p>In the<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=940&frame=2&anchor=07:03:38.537'> 
CDF shift e-log</a> Silicon was put to STANDBY as TEVMON went red for RFSUM and RFSUMA. This happened around 6:50AM.  Bu tif you look at the ACNET plot RFSUM and RFSUMA have been completly stable from 4AM to 8AM.  So there was no real need to put Silicon to STANDBY.  O well...better safe than sorry.</p></td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Thu Nov 10 08:41:19 2005 -->
Bias1 in f403 went yellow, compared with the old IMON limits and put the old value of 150 instead of 110.
<!-- Author: Marcel -->
<!-- Comment: Thu Nov 10 08;42;37 comment by...Marcel -->
Same for bias0 put back the old value of 110



<!-- Date: Thu Nov 10 09:48:21 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7886&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7886' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7887&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7887' width='300'></a></center>
<!-- Author: Jen -->
<!-- Comment: Thu Nov 10 09;52;33 comment by...Jen -->
<h3>Answered my own <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=274&frame=2&anchor=14:52:14'>question</a></h3>
So the PDB is slightly mistaken, it's BIAS1 on f534 that was reading back 0 current, not BIAS0 (this makes even more sense!)  And ever since the ps swap, the current on f534 has jumped back to normal values.<br>
So, the 0 BIAS1 current now being read back on f404 looks like a ps feature... presumably just a lack of readback from the ps, if the data from the ladder still looks ok.<br>

<!-- Date: Thu Nov 10 13:35:56 2005 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 423
Calibration type  : standard
Run period tag    : Nov_2005
DPS-off run       : 207999
DPS-on run        : 207998
Requested by      : Peter Dong
Main process id   : 30379
Comment           : Beam-on
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->
<!-- Comment: Fri Nov 11 14;57;44 comment by...Jason -->
<BR>Error: precognition function not enabled yet in D-mode framework.<BR>
Run numbers should be 206999 and 206998.
<!-- Date: Thu Nov 10 16:11:45 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W0L0 
<li>problem n: 1019 
<li>Status: fixed
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: marcel 
<li>description is: this ladder has been well bahving the last month ... fixed 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Nov 10 16:31:41 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W1L3 
<li>problem n: 1519 
<li>Status: fixed
<li>Type: BIAS
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: no problems since .. fixed  
<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: Thu Nov 10 16:33:10 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W3L3 
<li>problem n: 1564 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: Currents stable ... fixed 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W3&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Nov 10 16:35:14 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L2 
<li>problem n: 1540 
<li>Status: fixed
<li>Type: AVDD
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: No new problems found, data looks good ... fixed 
<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 Nov 10 16:39:36 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W1L2 
<li>problem n: 1218 
<li>Status: fixed
<li>Type: BIAS
<li>Action: Diagnosis_update
<li>entered by: mhartz 
<li>description is: Currents is stable.  Fixed. 
<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: Thu Nov 10 17:25:15 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W4L0 
<li>problem n: 1567 
<li>Status: fixed
<li>Type: BIAS
<li>Action: Diagnosis_update
<li>entered by: mhartz 
<li>description is: Current looks stable.  Fixed. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W4&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Nov 10 17:29:15 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W0L4 
<li>problem n: 1506 
<li>Status: fixed
<li>Type: BIAS
<li>Action: Diagnosis_update
<li>entered by: mhartz 
<li>description is: Current stable.  Fixed. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W0&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Nov 10 18:08:27 2005 -->
<center><a href='/elog/notebooks/silicon/Thu_Nov_10_2005_180734.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7889' ></a><a href='/elog/notebooks/silicon/Thu_Nov_10_2005_180801.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7891' ></a><a href='/elog/notebooks/silicon/Thu_Nov_10_2005_180809.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7893' ></a></center>
<!-- Author: Ankush -->
<!-- Comment: Thu Nov 10 18;09;56 comment by...Ankush & Shulamit & Marcel -->
<h4>Obvious (??)</h4>

<p>To be thorough, I quickly ran SVXDAQ for f404 biased and unbiased.  The plots above should be self-explanatory...<em>right??</em></p>


<!-- Comment: Thu Nov 10 22;14;32 comment by...Ankush -->
<p>The graph on th left is f404 unbiased while the other two are biased.  I have two "biased" histogram to double check the ladder was completly biased...after all it's a Micron ladder.</p>

<p>You can see a slight difference in the DNoise between biased and unbiased.  So I&#39m going to say the ladder is really biased and it&#39s just a readback problem.  This goes in agreement with everyone else&#39s conclusions.</p> 
<!-- Date: Thu Nov 10 20:36:11 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7894&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7894  width='300' align='top'></a></td><td>SpyMon plots for store 4495. Initial luminosity 179.42. 
</td></tr></table>
<!-- Author: Shulamit -->


<!-- Date: Thu Nov 10 20:46:54 2005 -->
<h3> Going for the Double shot </h3> 
We came in and found several wedges of SVX and one ISL wedge pink. 
It took some detective work to see, what actually happened. 
<ol> 
 
<li>  
CAENS 1 and 2 (NW TOP TOP and TOP BOT) both spontaneously turn off 
<pre> 
THU NOV 10 20:35:25 2005  Caenet_write: Error number -1 ffffffff received 
group_info:cr_n = 2, response = -1 
THU NOV 10 20:35:36 2005  Caenet_write: Error number -1 ffffffff received 
group_info:cr_n = 2, response = -1 
THU NOV 10 20:35:45 2005  Caenet_buffer: Error number 7 7 received 
group_info:cr_n = 2, response = 7 
THU NOV 10 20:41:38 2005  Caenet_write: Error number -1 ffffffff received 
group_info:cr_n = 1, response = -1 
THU NOV 10 20:41:47 2005  Caenet_buffer: Error number 7 7 received 
group_info:cr_n = 1, response = 7 
</pre> 
</li> 
<li> 
One of the Aces tries to turn things back to Standby  
<pre> 
Thu Nov 10 19:42:45 CST 2005                        success: Power Supply ISL B0 W1 to STANDBY 
Thu Nov 10 19:43:51 CST 2005                        success: Power Supply SVX B0 W10 to STANDBY 
Thu Nov 10 19:43:58 CST 2005                        success: Power Supply SVX B0 W11 to STANDBY 
Thu Nov 10 19:44:05 CST 2005                        success: Power Supply SVX B0 W0 to STANDBY 
Thu Nov 10 19:44:19 CST 2005                        success: Power Supply SVX B0 W1 to STANDBY 
Thu Nov 10 19:44:33 CST 2005                        success: Power Supply SVX B0 W2 to STANDBY 
Thu Nov 10 19:45:05 CST 2005                        success: Power Supply SVX B0 W3 to STANDBY 
Thu Nov 10 19:45:13 CST 2005                        success: Power Supply SVX B1 W3 to STANDBY 
</pre> 
</li> 
<li> However, then they decided to turn the whole Bulkhead 1 on during scraping 
<pre> 
Thu Nov 10 19:45:33 CST 2005                        success: SVX Bulkhead 1 ON 
</pre> 
How the hell did they came up with that idea. 
</li> 
<li> 
Then they tried to recover the rest of the ladders 
<pre> 
Thu Nov 10 19:45:43 CST 2005                        success: Power Supply SVX B1 W1 to STANDBY 
Thu Nov 10 19:45:53 CST 2005                        success: Power Supply SVX B2 W3 to STANDBY 
Thu Nov 10 19:46:04 CST 2005                        success: Power Supply SVX B2 W0 to STANDBY 
Thu Nov 10 19:46:16 CST 2005                        success: Power Supply SVX B2 W11 to STANDBY 
Thu Nov 10 19:46:19 CST 2005                        success: Power Supply SVX B2 W11 OFF 
Thu Nov 10 19:46:35 CST 2005                        success: Power Supply SVX B2 W2 to STANDBY 
Thu Nov 10 19:46:42 CST 2005                        success: Power Supply SVX B2 W1 to STANDBY 
Thu Nov 10 19:46:52 CST 2005                        success: Power Supply SVX B2 W11 to STANDBY 
Thu Nov 10 19:47:01 CST 2005                        success: Power Supply SVX B2 W10 to STANDBY 
Thu Nov 10 19:48:44 CST 2005                        TRIP: SVX  B1  W2 DVDD4 OverCurrent 
Thu Nov 10 19:50:19 CST 2005                        success: Power Supply SVX B1 W2 OFF 
</pre> 
</li> 
<li> 
At this point, Florencia and Willis realised, that the SVX is ramping and turn everything back to STANDBY 
</li> 
</ol> 
 
At this point we ride in to save the day. <br> 
First thing, was that the Aces forgot to initialize all the chips, hence the pinks. We recovered e124, and were ready to go.
<!-- Author: Shulamit and Marcel and Ankush -->
<!-- Comment: Thu Nov 10 21;01;16 comment by...The Ronin -->
<b> Veni Vidi Vici ! </b>
<!-- Date: Thu Nov 10 20:47:48 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7895&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7896' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7897&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7898' ></a></center>
<!-- Author: Marcel, Ankush and Shulamit -->
<!-- Comment: Thu Nov 10 20;49;01 comment by...Master Grumpy -->
Here are two sample ladders for the freakout




<!-- Date: Fri Nov 11 09:23:42 2005 -->
<h2> e202 bias current dropping to 0</h2> 
at 00:27, the bias current suddenly dropped to 0. Not clear why. 
First diagnosis shows no obvious loss of bias in SVXMON (using online ADC)  
<!-- Author: Ankush and Marcel -->
<!-- Comment: Fri Nov 11 10;42;19 comment by...Ankush, Antonio, Marcel -->
checked the online ADCMON, Ladders looks biased to us. Could be a CAEN readback problem
<!-- Comment: Fri Nov 11 18;00;18 comment by...Ankush & Marcel -->
As Vadim needed to restart the Run anyway, we hockerized the crate. That fixed it.
<!-- Date: Fri Nov 11 09:32:18 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7899&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7899  width='300' align='top'></a></td><td>Bias current for e202 for the last year</td></tr></table>
<!-- Author: Marcel -->


<!-- Date: Fri Nov 11 11:13:27 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W0L0 
<li>problem n: 647 
<li>Status: needs_urgent_monitoring
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Unknown bit error for 68% of events in the current run (207077.) 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Fri Nov 11 14;11;42 comment by...boveia -->
<pre>No data in ADCMon for run 207078.  Could be crash due to bit error.</pre>
<!-- Date: Fri Nov 11 12:47:03 2005 -->
e032 went pink, checked the Bias limits and changed them back to the settings before we reloaded Dean's new limit
<!-- Author: Marcel -->



<!-- Date: Fri Nov 11 15:11:22 2005 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 424
Calibration type  : standard
Run period tag    : Nov_2005
DPS-off run       : 206999
DPS-on run        : 206998
Requested by      : Jason
Main process id   : 10027
Comment           : resubmit for Peter
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->



<!-- Date: Sat Nov 12 01:10:26 2005 -->
<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 424 finished successfully.

Job info
--------
Calibration type : standard
Beam condition   : on
DPS-off run      : 206999
DPS-on run       : 206998
Requested by     : Jason
Submitted        : 2005-11-11 15:10:54
Completed        : 2005-11-12 01:09:14
Status           : SUCCESS
Comment          : resubmit for Peter
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->


<!-- Date: Sat Nov 12 08:24:40 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W0L0 
<li>problem n: 647 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: amitra 
<li>description is: <p>This ladder was now reading out during data taking.  When the store dropped we ran for 10,000 events in RA and NN mode. No errors seen.  See how this ladded performs during data taking over the next week.  If it runs fine, close this thread.</p>   
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Nov 12 08:45:56 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W1L2 
<li>problem n: 928 
<li>Status: needs_work
<li>Type: VRB_channel
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>Looking at the DS Error-Mon the 'position' of the error: ie:- it's normally the 3rd channelto be read out of chip 89.  The suspicion is the problem actually lies with the VRB.  However during quiet time we were unable to reproduce the problem.</p>  <p>If this ladder persists in giving errors and an opportunity arises, the we could try to swap the VRB.</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: Sat Nov 12 09:05:54 2005 -->
<h4>Quiet Time Studies</h4> 
 
<pre> 
e500 - This started running fine during data taking.  After the store dropped, run it with SVXDAQ.  Error free after 10,000 events in NN and RA mode 
 
e212 - In DS Err-Mon the 3rd channel to be readout for chip 89 would always give a bit error.  However this could not be reproduced with SVXDAQ.  The suspicion is the problem lies with the VRB.  So when the opportunity aries, the VRB could be swapped. 
 
</pre>
<!-- Author: Ankush & Marcel  -->


<!-- Date: Sat Nov 12 13:23:12 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7900&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7900  width='300' align='top'></a></td><td>Spymon plot at the beginning of store 4497. Initial luminosity 135.04.</td></tr></table>
<!-- Author: Shulamit -->
<!-- Comment: Sat Nov 12 13;27;11 comment by...Shulamit -->
High losses at the beginning of the store, something wrong with the TEV, not yet explained.
Then we had an SVX inhibit from one of the wedges B5W10 - couldn't see any bias current. Marcel tried to bring it to standby but it didn't work, we needed to hockerize crate 9, then it was fine.


<!-- Date: Sat Nov 12 20:34:40 2005 -->
<h3> CAEN freakout day .... </h3> 
This time the 2 Volt DOIM just dropped to 0. However the 5 Volt DOIM and everything else is fine. SVXMON is also fine. The only thing, that it toook like 90 minutes, till they called me.  
There is not much we can do right now, if the opportunity arises, hockerize the Crate (NW TOP TOP 1).  
<!-- Author: Marcel -->
<!-- Comment: Sun Nov 13 17;47;55 comment by...Marcel -->
hockerization fixed it ...
<!-- Date: Sun Nov 13 13:36:48 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7901&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7901' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7902&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7902' width='300'></a></center>
<!-- Author: Marcel -->
<!-- Comment: Sun Nov 13 14;08;37 comment by...Marcel -->
bias current history for e033, left over 500 days, right the last half year. In the left plot, besides the spikeness, this also shows the expected behaviour due to radiation damage. However, this is overlaid by some really spiky behaviour, origin unclear...


<!-- Date: Sun Nov 13 14:10:36 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7903&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7903  width='300' align='top'></a></td><td>e043 for comparison ...</td></tr></table>
<!-- Author: Marcel -->


<!-- Date: Sun Nov 13 17:39:38 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7904&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7904  width='300' align='top'></a></td><td>e033 bias for the last few hours, I bumped the limit up to 450.</td></tr></table>
<!-- Author: Marcel -->



<!-- Date: Sun Nov 13 22:18:45 2005 -->
<h3> Fun on Sunday night ...</h3> 
Just got an integrated dose Alarm ....  silenced it. <br> 
MCR did not do anything different. While calling the RADCO, Alarm disappeared ...
<!-- Author: Shulamit and Marcel -->
<!-- Comment: Sun Nov 13 22;57;12 comment by...Eva H. -->
Plots of integrated dose for <a href=
'/cgi/elog/elog.pl?nb=2005&action=view&page=951&frame=2&anchor=22:29:56.677'>
this store</a> compared to <a href=
'/cgi/elog/elog.pl?nb=2005&action=view&page=951&frame=2&anchor=22:40:09.979'>
last store</a>.  Looks like proton losses were higher this time during squeeze (when alarm occured).  MCR crew chief will also do similar comparisons to see if we can understand why this store was different.  

<!-- Comment: Mon Nov 14 08;57;16 comment by...Marcel -->
From the Tev Elog
<pre>
Looking at the tune plot above, it looks like the horz tune jumped down momentarily at the time the pbars fell out. That dip can be seen in the Shot Scrapbook color spectrogram, too.  
</pre>
<!-- Date: Sun Nov 13 22:56:26 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7905&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7905  width='300' align='top'></a></td><td>Spymon plots at the beginning of store 4499. Initial luminosity 164.29. 
While squeezing we had an integrated radiation dose alarm. Details to follow from Eva.</td></tr></table>
<!-- Author: Shulamit -->



<!-- Date: Mon Nov 14 08:47:02 2005 -->
<h3> Weekly Summary </h3> 
<ul> 
<li><b>Monday :</b>MCR tuned down the B0PAGC by moving F17 Collimator out a bit. Ankush makles a guest appearances on TV<br> 
Store 4490 quenched at F48. It was an RF station abort, that was not clean<br> 
In the quiet time, we brought back f311, PS needed hockerization</li> 
<li><b>Tuesday :</b> Big meeting in AD to discuss B0PAGC, at the end, it was found, that two collimators were not in the right position.<br> 
Tuesday evening, the whole SVX tripped, looks like a glitch or Happy was missing Sebastian. We came back alright. 
</li> 
<li><b>Wednesday :</b> Store terminated at 6, Dervin and Roberto swapped VME power supply for b0svx00. Did some quiet time studies, loaded new IMON limits. Found Bias1 current in f404 being 0, traced back to a readback problem in the CAEN.</li> 
<li><b>Thursday :</b>  
 Crate 7 was hockerized. in the evening crates 1 and 2 were hockerized, the recovery by the Aces was less than optimal. At some point they biased the entire bulkhead 1 while we were scraping.  
</li> 
<li><b>Friday :</b>  
Readback of e202 garbled, Hockerization fixed it. 
</li> 
<li><b>Weekend :</b>  
Did some quiet time studies Saturday morning. Had some more fun with the CAENS. One of the DOIM currents went to 0, the ususal hockerization fixed this as well <br> 
Sunday night we triggered the intregated Dose Alarm for SVX, investigation ongoing. 
</li> 
</ul>
<!-- Author: Shulamit and Marcel -->



<!-- Date: Mon Nov 14 09:04:06 2005 -->
<h2>Acta est fabula, plaudite! </h2>
<!-- Author: Marcel -->