<!-- Title: 10:17:13  Mon Oct  3 2005 -->
<!-- Crewchief: Jared -->
<!-- Op1: Ankush (SPL) -->
<!-- Op2: Marcel (just in case) -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>California here we come...</pre>


<!-- Date: Mon Oct 3 10:25:56 2005 -->
<table border=0><td><tr><td bgcolor=#e0e030><h3>Ankush is this week's SPL on call.</h3> 
 
<p>For any SPL issues, page: 630-612-8214</p> 
 
<em>But don't worry folks, Marcel remains as back-up to the back-up.</em></td></tr></td></table>
<!-- Author: Ankush -->


<!-- Date: Mon Oct 3 11:59:29 2005 -->
<h4>Testing RX 00453 at FCC</h4> 
 
<p>We pulled this RX during the last access as this wasn't seeing any data at all.  I took it to the BERT test-stand to check it out.  This RX gave 107 errors after 1.6E13 words; an error-rate of 6.6E-12.  For each error, bit 7 was stuck low.</p> 
 
<p>So the RX is bad but I would have expected the error-rate to be much larger. The next step is to put into the FTM in the WIB stand and see if it performs any better/worse. </p>
<!-- Author: Ankush -->

<!-- Date: Tue Oct 4 02:34:37 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W1L4 
<li>problem n: 1521 
<li>Status: needs_work
<li>Type: DRO_00F3
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>So we took an access to do a fibre swap. Lo and behold it indeed was an internal probelm as long suspected.  So we need to play with chip setting or maybe do a light-level measurement if the light is low.</p>  <p>So it is definitly an internal problem.</p> 
<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: Tue Oct 4 02:35:45 2005 -->
<table><tr><td><a href=/elog/notebooks/silicon/Tue_Oct__4_2005_023534.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7597  align='top'></a></td><td> </td></tr></table>
<!-- Author: Ankush  -->
<!-- Comment: Tue Oct  4 02;50;12 comment by...Ankush, Sasha  & Jared -->
<h4>Light level measurments on e152</h4>

<p>This lader had been known to have a light level problem but the duty cycle had not been measured.  So we took the opportunity to revisit the measurement.</p>

<table border="1">
<tr><td>Bit 0</td><td>552 uW</td></tr>
<tr><td>Bit 1</td><td>608 uW</td></tr>
<tr><td>Bit 2</td><td>461 uW</td></tr>
<tr><td>Bit 3</td><td>544 uW</td></tr>
<tr><td>Bit 4</td><td>552 uW</td></tr>
<tr><td>Bit 5</td><td>690 uW</td></tr>
<tr><td>Bit 6</td><td>730 uW</td></tr>
<tr><td>Bit 7</td><td>592 uW</td></tr>
<tr><td>OBDV </td><td>700 uW</td></tr>
</table>

<p>OBDV Duty Cycle was ~50\50</p>

<p>The CRO trace above shows OBDV (CH1; Grey), Bit 0 (CH2; Green) and Bit 3 (CH3; Yellow). You can see the OBDV looks almost 50\50.  So the low duty cycle is not likely to be the reason this ladder gives bit errors.  You can see the transitions of Bit 0 clearly although the transitions are slight of phase with OBDV.  This may cause problems latching the data. What's more surprising is the trace for Bit 3 where a continous band is seen.  Similar traces are seen for Bits 1,2. Bit 5 and 6 look similar but not as bad.  Bit 7 looks fine. Now it's hard to tell whether the trace  is bad due to incorrect CRO settings or is a real effect.  If it is real this could explain why we see the broad bit errors for this ladder. </p>

<!-- Date: Tue Oct 4 02:57:23 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W5L2 
<li>problem n: 63 
<li>Status: needs_work
<li>Type: Optical_other
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>During an access, the light-level and the duty cycle of OBDV was measured.</p>  <table border='1'>  <tr><td>Bit 0</td><td>552 uW</td></tr>  <tr><td>Bit 1</td><td>608 uW</td></tr>  <tr><td>Bit 2</td><td>461 uW</td></tr>  <tr><td>Bit 3</td><td>544 uW</td></tr>  <tr><td>Bit 4</td><td>552 uW</td></tr>  <tr><td>Bit 5</td><td>690 uW</td></tr>  <tr><td>Bit 6</td><td>730 uW</td></tr>  <tr><td>Bit 7</td><td>592 uW</td></tr>  <tr><td>OBDV </td><td>700 uW</td></tr>  </table>   <p>OBDV Duty Cycle was ~50\50.  A picture of the CRO trace can be found <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=269&frame=2&anchor=02:35:45'> here</a>.  The trace shows OBDV is ~50/50.  What's more alarming is the abscence of transitions in the traces for Bit 1,2,3 and Bits 5 & 6 to a lesser extent.  At the moment I cannot tell if this is due to bad CRO settings or a real effect. If it is real it could explain why we see bit errors duri!
ng running.</p>  <p>Needs much more work.</p>        </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 Oct 4 03:11:01 2005 -->
<h4>Access Reprot: Delta Force</h4> 
 
<p>Tonight was the first test of my policy to encourage the younglings to get more experience of collision-hall work.  So Sasha and I went in while Jared drove from the Control Room.  We looked at SB4W1L4 (e414) and SB1W5L2 (e152).</p> 
 
<h5>SB4W1L4</h5> 
 
<p>This ladder was dropping readout after Chip 8b.  We did a fibre swap with the neighbouring ladder SB4W1L5.  This showed the problem was internal (as long suspected).</p> 
 
<h5>SB1W5L2</h5> 
 
<p>We did a light level measurement and the details are <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=269&frame=2&anchor=02:35:45'> 
here</a>. We saw the duty cycle for OBDV was normal.  But some of the bits appeared not to change.</p> 
 
<hr> 
 
<p>We were hoping to test SB1W6L4 (e164) but this is when we encountered problems with CAENvolts.dat.  We were using traceSilicon to write a new CAENvolts.dat which it failed to do.    It complained it could not write file temp.dat to the SPOOL area.  It turns out this disk was full.  After Marcel cleared out that area traceSilicon ran fine and we could regenerate CAENvolts.dat.  However the access had ended then.</p> 
 
<p>One point I should mention was Sasha remembering just seconds from me returning our access keys that we had not undone the fibre swap of SB1W6L4 (e164).  So that was put back to normal.</p> 
 
<p>Just to check everything was OK, I did a COLD-START and ran for 5,000 events.No errors seen.</p> 
  
<!-- Author: Ankush, Sasha, Jared -->
<!-- Comment: Tue Oct  4 13;34;37 comment by...s -->
The sulution is to make room in the svxii home area.. Look for useless log files from svxdaq and delete them.
<!-- Date: Tue Oct 4 09:31:10 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7598&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7599  width='300' align='top'></a></td><td>SVT SpyMon: Store 4431 </td></tr></table>
<!-- Author: Jared -->

<!-- Date: Tue Oct 4 10:46:42 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W4/5All 
<li>problem n: 1541 
<li>Status: fixed
<li>Type: Other
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: fixed the original problem and did not introduce any new ones 
<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: Tue Oct 4 13:15:32 2005 -->
<h3>Testing FIB 150</h3> 
The FIB was tested in the B0 teststand using the high speed test, and no problems were found during 36hs of running. After the 5V PS of the FCC teststand crate was replaced (see <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=268&frame=2&anchor=13:14:55'> 
here</a>) and the CAEN mainframe recovered (was sitting in the repair room, nobody was going to work on it for a while, I checked with Hank) we setup the teststand to look at this FIB, after checking that everything worked fine with the default FIB. We found no problems initializing the ladders (we checked the 10 channels) and also the data looked fine. This FIB needs further testing, but if no problmes are found we should labeled it as "only to be used in case of emergency". It is possible that the FIB is fine, and that got upset and needed a power cycle... (not just a VME bus reset). <br>  
<!-- Author: Mark/Sebastian -->



<!-- Date: Tue Oct 4 15:09:45 2005 -->
<h2> Problem Database Upgrade Beta Testing</h2> 
The following link is to a beta version of a modified Problem DB that has an additional status category called "svxmon_ignore". 
<br><br> 
<a href='http://b0sili01.fnal.gov/cgi-mark/pdb-devel/DBmain.pl'>Beta Version of New Problem DB</a> 
<br><br> 
If a ladder has a thread marked "svxmon_ignore", it will show up as purple in the problem overview page.  This category will be used to solve the problem brought up by Ankush in this <a href='http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=268&frame=2&anchor=02:02:16'> 
e-log entry</a>, where we want SVXMon to ignore a ladder but don't want it to be marked it as "needs_work".  Please take the time to test this version of the db, and let me know of any problems you may find.  It writes to a seperate database file than the current db, so you can add entries without affecting the current db. 
<!-- Author: Mark -->
<!-- Comment: Tue Oct  4 16;15;14 comment by...Sebastian -->
Nice, seems to work.. (see below). When you make it official, keep the old one as a backup.
<!-- Date: Tue Oct 4 16:12:59 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W4L2 
<li>problem n: 711 
<li>Status: svxmon_ignore
<li>Type: AVDD
<li>Action: Monitoring
<li>entered by: mystery-guest 
<li>description is: test... this is a test... 
<li>See <a href="DBreport.pl?detsys=SVX&wedge=B0W4&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Oct 4 17:03:40 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W5L1 
<li>problem n: 1477 
<li>Status: needs_observation
<li>Type: Chip_other
<li>Action: Chip_bit_changes
<li>entered by: amitra 
<li>description is: <p>Comparing two runs here are the readout time before and after the threshold change.</p>  <table border='1'> <tr><td>Run#</td><td>rphiMean</td><td>rphiRMS</td><td>totalMean</td> <td>totalRMS</td></tr> <tr><td>203488</td><td>1.13546</td><td>0.832843</td><td>2.27273</td> <td>1.47946</td></tr> <tr><td>203506</td><td>1.86221</td><td>1.02363</td><td>4.42579</td> <td>1.95856</td></tr> </table>  <p>It would appear the readout times have increased slightly.  This ladders needs more observation to see if the change in threshold did any good.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W5&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Oct 4 18:12:38 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W2L1 
<li>problem n: 784 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: this ladder still has a low rate of bit errors affecting the chip ids (and as it seems only them) on the Z side. Should be attacked for the next quiet time 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Oct 4 18:41:10 2005 -->
<h4> Funny failures in some ladders </h4> 
For some ladders we see failures for the CHIP_ID at a very low rate adn only a few are affected. 
<ul> 
<li> e412: 87,86,85 become 07,06,05 </li> 
<li> e021: a2,a0  become a3,a1</li> 
<li> e002: a2  becomes a3 </li> 
</ul> 
 
We do not know, how this can happen, but since this seems to spread, we should track this down  
<!-- Author: Ankush & Marcel -->


<!-- Date: Tue Oct 4 20:03:12 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7600&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7600  width='300' align='top'></a></td><td><p>Antonio pointed last week this ladder was looking under-biased. Possibly a pin-hole candidate.  I looked at the Bias1 history and it seems to have been zero most of the time.  I'm guesing this is a monitoring problem.  But we should check this in the collision hall.</p></td></tr></table>
<!-- Author: Ankush -->

<!-- Date: Tue Oct 4 20:10:29 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W2L3 
<li>problem n: 1529 
<li>Status: needs_access_4hr
<li>Type: BIAS
<li>Action: Monitoring
<li>entered by: amitra 
<li>description is: <p>The current bias1 line has reporting zero for a long time.  We should probably check this during an access to see if it is really zero.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B0W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Oct 4 20:19:46 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W2L3 
<li>problem n: 1529 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: Monitoring
<li>entered by: amitra 
<li>description is: <p>Oopps!!...I've been editing the wrong ladder.  No access needed.  Just continue observation.  My bad !!</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B0W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Tue Oct 4 23:26:43 2005 -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2005&action=view&page=-17965&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2005&action=view&page=-17965 width='300' align='top'></a></td><td></td></tr></table>
<!-- Author: Jared -->
<!-- Comment: Tue Oct  4 23;28;10 comment by...Jared -->
<pre>Ace said HRR didn't help, but then said it went back to ~285 after a few minutes.</pre>

<!-- Comment: Wed Oct  5 00;07;20 comment by...s -->
well it's a bias line, HRR will not affect it.

<!-- Comment: Wed Oct  5 00;43;37 comment by...Marcel -->
in theory yes, but I do not understand the bias behaviour at all. This looks like some cross talk with the Low voltage


<!-- Comment: Wed Oct  5 00;56;37 comment by...Ankush -->
<p>Well I guess I should make a contribution.  All the ladders had their upper IMON limit on BIAS set to 100.0.  That has been fine until now.  Radaition damage increases the ladder BIAS current and we've reached the point where many ladders are starting to hit the 100.0 limit.  So from now on we going to keep having a few pinkies in BIAS. I guess the sensible thing would be to go through all ladders and then increase their IMON limit to some appropiate problem.</p>

<p>As we're seeing these pinkies on a regular basis, we should probably employ somekind of pre-emptive stike.</p>


<!-- Comment: Wed Oct  5 01;14;45 comment by...Ankush -->
<p>Jared: If you get paged again, plot the BIAS current history for this ladder.  See if it has a history of erratic currents and whether the BIAS current has been steadily increasing with time (luminosity).</p>
<!-- Comment: Wed Oct  5 07;35;57 comment by...Ankush -->
<p>This ladder had been noted as having an irratic BIAS Current behvavour.  See <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'>
here</a>.  So it's more than just the Bias Current going up due to radiation.  Hmm...suspecting it is either a power-supply problem, or there's some dodgy connection between the PS and the ladder.</p>



<!-- Date: Wed Oct 5 01:11:18 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7605&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7605' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7606&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7606' width='300'></a></center>
<!-- Author: Sebastian -->
<!-- Comment: Wed Oct  5 01;11;55 comment by...s -->
L1A rate range: 19.5-21.5 KHz


<!-- Date: Wed Oct 5 01:12:58 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7607&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7607' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7608&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7608' width='300'></a></center>
<!-- Author: Sebastian -->
<!-- Comment: Wed Oct  5 01;13;33 comment by...s -->
L1A rate in range: 24-26 kHz


<!-- Comment: Wed Oct  5 01;14;46 comment by...s -->
Some numbers:
<pre>
Column: 1    2      3              4                     5
        RunN Nreso  Nreso_in_range min_in_l1ar_range reso_per_hour_in_range
            24-26 kHz               19.5-21.5 kHz
 204549       2 0 8 0                  2 0 0 0
 204550      14 0 14 0                14 0 56 0
 204576       5 4 74 3.240             5 0 0 0
 204578       5 4 202 1.140            5 0 0 0
 204589       1 0 0 0                  1 0 58 0
 204640      15 0 320 0               15 0 0 0
 204642       3 0 0 0                  3 0 62 0
 204643       2 0 98 0                 2 0 2 0
 204677       5 4 54 4.440             5 0 0 0
 204679      11 10 176 3.360          11 0 0 0
 204680       3 2 90 1.320             3 0 0 0
 204682       4 1 128 .420             4 0 66 0
 204714       7 4 12 19.980            7 0 0 0
 204721       8 5 202 1.440            8 2 60 1.980
 204722       2 0 74 0                 2 0 118 0
 204746       2 1 28 2.100             2 0 0 0
 204747       2 0 28 0                 2 0 10 0
 204748       3 0 26 0                 3 0 402 0
 204827       7 0 68 0                 7 0 110 0
 204921       4 0 48 0                 4 2 178 .660
 205007       3 0 18 0                 3 0 2 0
 205009       4 0 2 0                  4 3 310 .540
 205018       1 0 100 0                1 0 58 0
 205070       9 2 68 1.740             9 1 128 .420
 205073       1 0 0 0                  1 1 94 .600
 205074       4 0 0 0                  5 0 94 0     
</pre>

<!-- Comment: Wed Oct  5 01;39;08 comment by...s -->
Talked to Ted, I suggested reducing the L2 bandwidth but increasing the L1 rate to 25kHz. 

<!-- Comment: Wed Oct  5 01;44;46 comment by...Ted  -->
<pre>Ted can do this tomorrow.... don't know how much it will do by reducing the L2 bandwidth (as ScalerMon is still shy with increased L2A bandwidth anyway). but will reduce it just for you (and increase the L1A limit to 25KHz). </pre>

<!-- Comment: Wed Oct  5 07;07;39 comment by...Marcel -->
i do not think, that will make any difference, I am pretty convinced, that the track trigger is the problem.



<!-- Comment: Wed Oct  5 08;09;28 comment by...Ted  -->
<pre>maybe we could simply increase the L1A limit back to 25Khz... and keep the L2A limits as they are now? and see if anything new we can learn.... let's talk. I'd like to be convinced as well, whatever the causes. cheers.</pre>
<!-- Comment: Wed Oct  5 22;07;07 comment by...Sebastian -->
<br>
<a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7612&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7612' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7610&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7610' width='300'></a>
<br><br>
First plot it the luminosity when we resonate vs run number. The second is the l1a rate when we resonate vs run number. Looks like during the high resonance period, we were getting the resonances at all luminosities, not only from one certain range. This is supported by the following two plots which show the Lum plot above but for the "high" reso period only and for only the period of not "high number of resonances". (High lum period defined ar run number between (204450,204850), from the plot, I don't have the energy to go and search the precise numbers....
<br><br>
<a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7613&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7613' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7614&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7614' width='300'></a>
<br>

 

<!-- Comment: Thu Oct  6 17;34;01 comment by...Sebastian -->
About the structure of the above two plots, it is (mostly) understood, there is the UPS peak, the FPS increase, and the one on the right might be a result of the lum eanbled triggers (as suggested by Veronica).
<!-- Date: Wed Oct 5 07:54:40 2005 -->
restarted GUI becasue of stuck RED DAQ button
<!-- Author: Marcel -->
<!-- Comment: Wed Oct  5 08;26;23 comment by...Jared, Ankush and Marcel -->
and while we are at it, we changed the Java VM parameters temporarily. 
From  
<pre>
java -native -ss5m -oss5m -ms10m CAEN.PSControlForm
</pre>
to
<pre>
java -native -ss100m -oss100m -ms16m CAEN.PSControlForm
</pre>
That should give the GUI more memory.


<!-- Date: Wed Oct 5 08:54:19 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7609&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7609  width='300' align='top'></a></td><td>This shows that C4Q4 is rolling</td></tr></table>
<!-- Author: Marcel  and his Padawans -->

<!-- Date: Wed Oct 5 11:55:43 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W1L4 
<li>problem n: 1454 
<li>Status: needs_access_2hr
<li>Type: BIAS
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>I was trying to plot the Current history of Bias1 for this ladder and it looks like it's been reading zero for quite some time.  So we may want to have a look at it during an access to see if this is real or a monitoring problem.</p>  <em>...and this time I've got the right ladder !!</em> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W1&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Oct 5 12:33:42 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W2L3 
<li>problem n: 1462 
<li>Status: needs_bore_access
<li>Type: DVDD
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: had a look at the JC schematics. It could be, that this a JC failure since DVDD line 3 is outmost pin ... 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Oct 5 12:36:19 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W10L3 
<li>problem n: 480 
<li>Status: needs_bore_access
<li>Type: DOIM_cable
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: in case, we open the baggy, we could have a look at it again 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W10&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Oct 5 14:49:44 2005 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 422
Calibration type  : standard
Run period tag    : Oct_2005
DPS-off run       : 205080
DPS-on run        : 205081
Requested by      : Troy
Main process id   : 23660
Comment           : its a bit cold in here
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->



<!-- Date: Wed Oct 5 14:56:52 2005 -->
<table border=0><td><tr><td bgcolor=#e0e030><h3>PS-CAEN OFF ALARM IS CURRENTLY SILENCED.</h3> 
 
<p>REMEMBER TO UNSILENCE ALARM BEFORE START OF NEXT STORE</p></td></tr></td></table>
<!-- Author: Ankush & Marcel -->
<!-- Comment: Wed Oct  5 15;54;58 comment by...Jennfer & Ulrich -->
We also silenced another SVX alarm. The current temperature reading of PCE1B-1 is stable at 1.9C (alarm limit: 2.0C). Please remember to unsilence the alarm after the silicon has been switched on again.
<!-- Date: Wed Oct 5 15:17:30 2005 -->
<table border=0><td><tr><td bgcolor=#e0e030><h2> KILL switches flipped </h2></td></tr></td></table>
<!-- Author: Shulamit and Marcel -->


<!-- Date: Wed Oct 5 15:21:47 2005 -->
<h3>iFix rebooted!</h3> 
 
End of store reboot for our friendly iFix PC. Noticed after reboot, SVX came back up as "yellow", due to PC temperature alarms (too low) already silenced by the control room. 
<!-- Author: Ulrich H. & Jennifer :-) -->


<!-- Date: Wed Oct 5 17:25:12 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W10L3 
<li>problem n: 480 
<li>Status: needs_bore_access
<li>Type: DOIM_cable
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: in case, we open the baggy, we could have a look at it again 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W10&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Oct 5 17:51:46 2005 -->
<h4>Status </h4> 
Everything DAQwise is back on. Kill switches are enabled as well.  
<!-- Author: Sebastian, Ankush and Marcel -->


<!-- Date: Wed Oct 5 18:56:52 2005 -->
<h3> PS Converter offline </h3> 
Thanks to the great plan of moving things around, the PS converter is broken. Email has been send to Lammel and Co. Can be only days, till they figure out, what is broken.<br> 
For the time being use 
<a href='http://www-cdfonline.fnal.gov/internal/usr/stanitz/psconv.html'> this link </a>
<!-- Author: Marcel -->
<!-- Comment: Wed Oct  5 20;56;18 comment by...s -->
looks like svxii can not run cgi-bin scripts on the online machines... 
<!-- Comment: Thu Oct  6 11;56;34 comment by...Marcel & Ankush -->
This problem has been diagnosed by Jason Hedden. It was due to invalid Group id for svxii on the Web server. This will be fixed tomorrow morning after the end of store. 

<p>For the time being, there's a copy residing at:</p>

<p>
<a href=http://www-cdfonline.fnal.gov/internal/usr/stanitz/psconv.html>
http://www-cdfonline.fnal.gov/~stanitz/psconv.html</a>

<br>

or

<br>

<a href=http://www-cdfonline.fnal.gov/internal/usr/mitra/psconv.html>
http://www-cdfonline.fnal.gov/~mitra/psconv.html</a>

<br><br>

You can use either of these links as a temporary fix.</p>
<!-- Date: Wed Oct 5 20:05:13 2005 -->
<h4>Silicon Back On</h4> 
 
<p>After Dervin et al finished their work, we went through the Silicon check-out procedure to bring the DAQ back.  We did not encounter any problems there.</p> 
 
<p>After satisfying ourselves the DAQ was up and running, we powered the detector back on.  We then took the detector through COLD-START and ran for 5,000 events.  No errors there.</p> 
 
<p>We are now in the middle of a 30 minutes Silicon COSMICS run.  We had some problems starting the run.  It's been running for ~25 mintues and SVXMON looks fine.</p> 
 
<p>During powering the detector off/on we had to silience some IFIX alarms and hit the 5V enables off.  The IFIX alarms are now unsilenced and the 5V enables are on.</p> 
 
<p>Let's see how the detector handles during the encroaching hot store.  There's 280E10 sitting in the recycler.</p>
<!-- Author: Marcel, Sebastian and Ankush -->




<!-- Date: Wed Oct 5 23:11:29 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7615&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7616  width='300' align='top'></a></td><td><p>While we were waiting for scraping to finish, this ladder went PINK on AVDD.  Asked the ACE to do a CONFIG and it came back up fine.</p></td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Wed Oct 5 23:13:42 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7617&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7618  width='300' align='top'></a></td><td><p>...and this ISL ladder gave a PINKIE in BIAS1.  It seems to be going down.  So I'll be keeping an eye to see where it settles.</p></td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Wed Oct 5 23:20:16 2005 -->
<table><tr><td><a href=https://www-cdfonline.fnal.gov:443/cgi-bin/nph-MCRproxy_res.pl/000/http/www-cdfonline.fnal.gov/cgi-bin/det-system-elog.pl?nb=silicon&action=view&page=-7619&button=yes target='xxx' onclick='jswindow()'; align=top><img src=https://www-cdfonline.fnal.gov:443/cgi-bin/nph-MCRproxy_res.pl/000/http/www-cdfonline.fnal.gov/cgi-bin/det-system-elog.pl?nb=silicon&action=view&page=-7620  width='300' align='top'></a></td><td>SVT SpyMon: Store 4433</td></tr></table>
<!-- Author: Jared -->


<!-- Date: Wed Oct 5 23:21:48 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7621&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7622  width='300' align='top'></a></td><td><p>Store 4433: Initial Lumi was 149.33E30.  A hot store as predicted.  A couple of PINKIES at the start but now OK.  SVXMON looks fine.</p></td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Wed Oct 5 23:50:48 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7623&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7624' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7625&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7626' ></a></center>
<!-- Author: Ankush -->
<!-- Comment: Thu Oct  6 00;00;21 comment by...Ankush -->
<p>Here is a plot of the BIAS currents for IB1W4L0.  At the start of the store Bias 1 went pink but then went green.  This ladder is clearly suffering from a pin-hole due to the very large BIAS current.  It is interesting to note the current for Bias0.  This has started to go up as Bias1 went down.</p>

<!-- Date: Thu Oct 6 00:36:39 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 422 finished successfully.

Job info
--------
Calibration type : standard
Beam condition   : on
DPS-off run      : 205080
DPS-on run       : 205081
Requested by     : Troy
Submitted        : 2005-10-05 14:48:36
Completed        : 2005-10-06 00:36:00
Status           : SUCCESS
Comment          : its a bit cold in here
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Thu Oct 6 00:57:01 2005 -->
BTW, today support for the SRC LA pods have been added. Though not very robust, it is better than having the cables hanging from the SRCs. SCN would be happy (probably he is still reading the elog, but will he spot this short entry?).
<!-- Author: Sebastian -->
<!-- Comment: Fri Oct  7 10;46;25 comment by...Sebastian -->
Also added a CLK line for the LA SPA measurements (POD4, connected to RSMCLK).
<!-- Date: Thu Oct 6 09:59:33 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7631&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7632' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7633&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7634' ></a></center>
<!-- Author: Ankush -->
<!-- Comment: Thu Oct  6 10;03;24 comment by...Ankush -->
<p>CAEN PS 14 had to be hockerized <em>twice</em>.  The first hockerisation brought back all the ladders however the 2V & 5V DOIM s for e355 e465 stayed pink.  A second hockerisation seem to fix it.</p>

<p>So the question is why did I need to do it twice?</p>



<!-- Date: Thu Oct 6 16:28:13 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7635&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7636  width='300' align='top'></a></td><td>Bias0 on IB0W3L2 went slightly above its upper IMON limit. It has now dipped just below it.  But I guess I will have raise it at some point...may be very soon</td></tr></table>
<!-- Author: Ankush -->

<!-- Date: Thu Oct 6 17:15:23 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W3L2 
<li>problem n: 717 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>Need to raise the Bias0 limit again.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>105.0</td><td>105.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>150.0</td><td>170.0</td></tr></table> 
<li>See <a href="DBreport.pl?detsys=ISL&wedge=B0W3&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Oct 6 17:29:42 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W1L1 
<li>problem n: 1542 
<li>Status: svxmon_ignore
<li>Type: Other
<li>Action: Monitoring
<li>entered by: mhartz 
<li>description is: Adding thread with svxmon_ignore status so SVXMon will ignore this ladder 
<li>See <a href="DBreport.pl?detsys=ISL&wedge=B4W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Oct 6 17:30:12 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W1L1 
<li>problem n: 1250 
<li>Status: needs_observation
<li>Type: Other
<li>Action: Diagnosis_update
<li>entered by: mhartz 
<li>description is: Changing back to needs_observation since ladder is now marked with svxmon_ignore. 
<li>See <a href="DBreport.pl?detsys=ISL&wedge=B4W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Thu Oct 6 17:44:23 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7638&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7638  width='300' align='top'></a></td><td><h3>Resonances per hour</h3> 
Included are the recent runs, where the L1A rate was increased to 25kHz again. This far we do not see the sharp increase in the number of resonances as we saw last time we ran at 25kHz (the peak at around run 204500). I am beginning to suspect that our problem was in fact related to <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=803&frame=2&anchor=14:44:17.536'> 
ScalerMon</a>...</td></tr></table>
<!-- Author: Sebastian -->


<!-- Date: Thu Oct 6 18:15:09 2005 -->
<h3>Updated Problem Database</h3> 
I have updated the problem database to have an additional status category called "svxmon_ignore".  Thanks to Marcel's almost supernatural ability to detect missing semi-colons this version of the database seems to be functional (if you run into any problems, please let me know right away).  The purpose of the new category is to tell SVXMon to ignore a ladder without having to change a thread to "needs_work".  This can be done by creating a new thread with "svxmon_ignore" as its status.  Ankush and I tested the new category using <a href='http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W1&layer=L1'>IB4W1L1</a> and SVXMon ignored the ladder as expected.
<!-- Author: Mark -->
<!-- Comment: Thu Oct  6 19;26;01 comment by...A sith  -->
some may consider it unnatural 


<!-- Date: Thu Oct 6 23:42:58 2005 -->
<h4>Tevatron Aborted Store Early</h4> 
 
<p>Tevatron were having Cryo problems at A3.  The Cry dewer was at 20% and falling.  Fortunatly they forewarned CDF and we went to end-of-store (ie:- STANDBY for us).</p> 
 
<p>The store was manually aborted and the shift crew did a Post-Quench check out.  <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=837&frame=2&anchor=23:28:54.193'> 
It was clean for us.</a>  The only incident was an IB1W3L2 tripped off when the store was dumped.  However this trip was recovered.  The shift crew did a COLD-START and everything passed CONFIG.  Looks like we're OK.</p>
<!-- Author: Ankush -->


<!-- Date: Fri Oct 7 09:57:17 2005 -->
<h3>Access report alpha - cable probe of f414</h3> 
Bias 1 of f414 has been reading back zero current for quite some time.  We went down to probe the bias line and compared with a couple other ladders. 
<ul> 
<li> f414 
   <ul> 
   <li> Positive to negative: 28.8 kOhms or 27.8 kOhms 
   <li> Positive to reference: slow ramp up to OL 
   <li> Negative to reference: slow ramp up to OL 
   </ul> 
<li> f412 
   <ul> 
   <li> Positive to negative: 29.8 kOhms or 28.9 kOhms 
   <li> Positive to reference: slow ramp up to OL 
   <li> Negative to reference: slow ramp up to OL 
   </ul> 
<li> f404 
   <ul> 
   <li> Positive to negative: 29.8 kOhms or 29.9 kOhms 
   <li> Positive to reference: slow ramp up to OL 
   <li> Negative to reference: slow ramp up to OL 
   </ul> 
</ul> 
 
Conclusion: Bias probing shows ladder to be consistent with other healthy ladders.  Unfortunately we can't probe out the back of the supply to try and figure out why there's no current.<br>  
<!-- Author: Jen, Marcel, Ankush, Mark -->
<!-- Comment: Fri Oct  7 10;57;53 comment by...David -->
<pre>If you place a load on the supply (e.g. with the load box) it can tell you if the supply draws current when it is supposed to.</pre>
<!-- Date: Fri Oct 7 10:06:32 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W1L4 
<li>problem n: 1454 
<li>Status: needs_work
<li>Type: BIAS
<li>Action: PS_work
<li>entered by: jpursley 
<li>description is: Probed the bias cable for this ladder; everything looks consistent with healthy ladders.  See <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=269&frame=2&anchor=09:57:17'>elog</a>. 
<li>See <a href="DBreport.pl?detsys=ISL&wedge=B4W1&layer=L4">report</a></ul>
<!-- Author: Problem DB -->





<!-- Date: Fri Oct 7 12:13:44 2005 -->
<h3><u>High chip currents (and keepalives)</u></h3> 
 
When working on the FCC teststand <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=269&frame=2&anchor=13:15:32'> 
a few days ago</a> we found that we could not increase the current comsuption of the chip when not sending keepalives. After consulting with Stev Nahn (DAQ guru), I burned a RSM PROM to activate/deactivate sending keepalives from a register, and tried the following, after chip init: 
<ul> 
<li> Disable keepalives in the SRC: after about <b>20 sec</b> the DVDD currents increase about 10mA (only for HDI4, HDI0 is more stable). Re-enable keepalives brings the currents to normal state inmediately. 
<li> Unsynched the FFO: both DVDD and AVDD jump to lower currents in a few seconds. Re-sync the FFO brings the currents to normal state inmediately. 
<li> Disconnected copper cables: same behavior as FFO. 
</ul>    
So, looks like there is not much time (in human terms) after a CLK glitch to do something , but there is plenty of time for the CCC (clock clonning card) to re-establish the signals and keep the chips in order. <br>
<!-- Author: Sebastian -->


<!-- Date: Fri Oct 7 13:26:31 2005 -->
<h3>Access report beta - PS swap for SB0W7</h3> 
For the last few weeks, every time crate 6 was turned off and then on again, SB0W7 would come up with low currents on the DOIMs, low enough to cause pinkies.  The only way to fix it was by hockerizing crate 6.  While this wasn't a serious problem, we decided to swap out the supply to prevent it becoming serious.<br> 
The swap went off without a hitch, loadbox checkout was perfect, and the new supply is behaving nicely.  Some of the currents will have to be monitored and their limits changed.<br> 
I'll see if I can reproduce the problem with the old supply on the teststand, although it seems like a difficult one to catch...<br>
<!-- Author: Jen, Marcel, Jared -->

<!-- Date: Fri Oct 7 13:29:06 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W7All 
<li>problem n: 1517 
<li>Status: needs_observation
<li>Type: VDOIM
<li>Action: PS_work
<li>entered by: jpursley 
<li>description is: Swapped out the supply for this wedge, see if that fixes the DOIM problem.  Some currents have changed and will have to be monitored before moving the limits.  See <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=269&frame=2&anchor=13:26:31'>elog</a>. 
<li>See <a href="DBreport.pl?detsys=SVX&wedge=B0W7&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Oct 7 13:51:05 2005 -->
<h3>Access report gamma - f402 and f414 revisted</h3> 
As per David's suggestion, we went down to hook the loadbox up to the bias line of f414 to check out the current problem in more detail.  From the back of the crate, there was no current being read out when the ladder was at standby or at 20V.  When we hooked up the loadbox, we saw 0 current at 2V, 10 microA at 20V and 360 microA at 50V, with the loadbox resistance set to 100 kOhms.  So, it doesn't appear to be a ps problem or a problem with readback to the crate.<br> 
For f402: IB4W0 is the supply we swapped in <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=261&frame=2&anchor=11:43:45'>two months ago</a>, and this ladder began tripping sporadically on AVDD UnderVoltage <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=268&frame=2&anchor=20:33:01'>last week</a>.  We brought it back in the hdwdb, and it held without tripping, so we went down to probe the low voltage cable.  After deciphering the CAEN manuals to figure out which of the two ISL LV cables held the AVDD lines (it's OutputB), I looked at the AVDD resistances for f402 and f404:<br> 
<ul> 
<li> For Layer 2, the AVDD negative pins are 8, 28, 47, and 67.  The AVDD positive pins are 10, 29, 49, and 60.  Measuring 8 to 10, 28 to 29, 47 to 49, 67 to 69, 47 to 29, 28 to 10, 8 to 49, and 28 to 69, I found the same resistance for every combination: 1.04 kOhms. 
<li> For Layer 4, the AVDD negative pins are 1, 21, 40, and 60.  The AVDD positive pinis are 3, 22, 42, and 61.  Measuring 1 to 3, 21 to 22, 40 to 42, 60 to 61, 1 to 61, 21 to 3, 40 to 22, and 60 to 42, I found the same resistance for every combination: 1.04 kOhms. 
</ul> 
So, this ladder looks healthy.  Right now it's back at standby and holding; if it starts tripping reliably again before the end of the access, we can try a cable swap.<br> 
 
 
 
  
<!-- Author: Jen, Marcel, Jared, Sebastian -->

<!-- Date: Fri Oct 7 13:56:34 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L2 
<li>problem n: 1540 
<li>Status: needs_access_4hr
<li>Type: AVDD2
<li>Action: PS_work
<li>entered by: jpursley 
<li>description is: Probed the LV cable for AVDD; looks consistent with a healthy ladder.  Details in <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=269&frame=2&anchor=13:51:05'>elog</a>.  If trips start occuring again reliably during an access (currently it's holding fine), we can try swapping cables to make sure it's the supply. 
<li>See <a href="DBreport.pl?detsys=ISL&wedge=B4W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Oct 7 13:59:09 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W1L4 
<li>problem n: 1454 
<li>Status: needs_work
<li>Type: BIAS
<li>Action: PS_work
<li>entered by: jpursley 
<li>description is: Went back down to try hooking a loadbox up to the bias line; with the loadbox resistance at 100kOhms and 20V bias, we see 10 microAmps current from the display panel on the crate.  So it looks like it's not a PS or crate problem.  Details in <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=269&frame=2&anchor=13:51:05'>elog</a>. 
<li>See <a href="DBreport.pl?detsys=ISL&wedge=B4W1&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Oct 7 15:03:22 2005 -->
<h2> Access report for Chi team-- PS swap for e16. </h2> 
 
Ladder e164 was tripping freequently in recent time. 
We went to the collision hall to swap PS cables for  
e16(suspect)<-->e15(healthy one) to see if the problem  
is due to PS or it is internal to the ladder. It  
appeared that e164 keeps tripping. So we can conclude 
that the problem is internal to the ladder.   
<!-- Author: Sasha/Sebastian/Jared -->
<!-- Comment: Fri Oct  7 15;35;21 comment by...s -->
made the entry in the problem DB.
<!-- Date: Fri Oct 7 15:30:36 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W7L0 
<li>problem n: 1544 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: yamaoka 
<li>description is: Change IMON limits after PS swap.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>332.5</td><td>324.0</td></tr>
<tr><td><b>Lower</b></td><td>330.0</td><td>320.0</td></tr>
<tr><td><b>Upper</b></td><td>335.0</td><td>330.0</td></tr></table> 
<li>See <a href="DBreport.pl?detsys=SVX&wedge=B0W7&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Oct 7 15:34:38 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W7L2 
<li>problem n: 1545 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: yamaoka 
<li>description is: Change IMON limits after PS swap.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>436.4</td><td>410.0</td></tr>
<tr><td><b>Lower</b></td><td>435.0</td><td>405.0</td></tr>
<tr><td><b>Upper</b></td><td>445.0</td><td>415.0</td></tr></table> 
<li>See <a href="DBreport.pl?detsys=SVX&wedge=B0W7&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Oct 7 15:34:38 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W6L4 
<li>problem n: 856 
<li>Status: needs_work
<li>Type: DVDD
<li>Action: Diagnosis_update
<li>entered by: sebastian 
<li>description is: We swapped PS cables (e16 and e15), but the ladder kept tripping. 
<li>See <a href="DBreport.pl?detsys=SVX&wedge=B1W6&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Oct 7 15:36:02 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W7L2 
<li>problem n: 1546 
<li>Status: needs_observation
<li>Type: DVDD
<li>Action: IMON_limits
<li>entered by: yamaoka 
<li>description is: Change IMON limits after PS swap.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>101.0</td><td>65.0</td></tr>
<tr><td><b>Lower</b></td><td>85.0</td><td>45.0</td></tr>
<tr><td><b>Upper</b></td><td>125.0</td><td>85.0</td></tr></table> 
<li>See <a href="DBreport.pl?detsys=SVX&wedge=B0W7&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Oct 7 15:36:02 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W7L2 
<li>problem n: 1546 
<li>Status: needs_observation
<li>Type: DVDD
<li>Action: IMON_limits
<li>entered by: yamaoka 
<li>description is: Change IMON limits after PS swap.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>101.0</td><td>65.0</td></tr>
<tr><td><b>Lower</b></td><td>85.0</td><td>45.0</td></tr>
<tr><td><b>Upper</b></td><td>125.0</td><td>85.0</td></tr></table> 
<li>See <a href="DBreport.pl?detsys=SVX&wedge=B0W7&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Oct 7 15:37:45 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W7L3 
<li>problem n: 1547 
<li>Status: needs_observation
<li>Type: DVDD
<li>Action: IMON_limits
<li>entered by: yamaoka 
<li>description is: Change IMON limits after PS swap.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>167.0</td><td>115.0</td></tr>
<tr><td><b>Lower</b></td><td>150.0</td><td>100.0</td></tr>
<tr><td><b>Upper</b></td><td>185.0</td><td>130.0</td></tr></table> 
<li>See <a href="DBreport.pl?detsys=SVX&wedge=B0W7&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Oct 7 15:55:31 2005 -->
<pre>Access Report: 
 
e002: Fiber swap, problem stayed with daq channel.  c2c2 truncated error. 
 
e021: No errors when run in SVX daq.   
 
e164: Ladder trips on DVDD.  Swapped PS cables, but problem stayed with ladder.   
 
e412: No problems seen.</pre>
<!-- Author: Jared, Ankish, Mark -->

<!-- Date: Fri Oct 7 15:57:49 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W2L1 
<li>problem n: 784 
<li>Status: needs_quiet_time
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: yamaoka 
<li>description is: Unable to reproduce error in svxdaq. 
<li>See <a href="DBreport.pl?detsys=SVX&wedge=B0W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Oct 7 16:04:04 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W0L2 
<li>problem n: 1490 
<li>Status: needs_quiet_time
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: yamaoka 
<li>description is: Tried fiber swap with e003, and the problem stayed with daq channel.   
<li>See <a href="DBreport.pl?detsys=SVX&wedge=B0W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Oct 7 16:05:00 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W0L2 
<li>problem n: 1490 
<li>Status: needs_access_2hr
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: yamaoka 
<li>description is: Maybe try a RX swap. 
<li>See <a href="DBreport.pl?detsys=SVX&wedge=B0W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Oct 7 16:07:16 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W1L2 
<li>problem n: 1445 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: yamaoka 
<li>description is: Unable to reproduce the problem in svxdaq. 
<li>See <a href="DBreport.pl?detsys=SVX&wedge=B4W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Oct 7 16:22:26 2005 -->
<h3>Tripmann returns</h3> 
This time not (yet) causing a trip. During quiet time, I have tried to re-tune some valve settings in order to bring flows and pressures back to normal: 
<ul> 
<li>E-valve for L00E 42% open (from 37%): brings flows to 2.1 lpm and pressured to 12.3 psi</li> 
<li>E-valve for L00W 80% open (from 70%): brings flows to 2.0 lpm and pressured to 12.7 psi</li> 
<li>Mechanical bypass valve of the ISL chiller slightly opened (was fully closed): brings ISL supply pressure to 26.8 psi.</li> 
</ul> 
The L00 and ISL flows and pressures seem to be within the range. 
I will check in two hours if the new settings are stable.
<!-- Author: Ulrich & Ankush -->
<!-- Comment: Fri Oct  7 17;34;43 comment by...Ulrich H. -->
Due to the lower ISL pressure, the flow on PCE was on the low side. I have opened up the e-valve to 70% (was 65%) before. Let's see...
<!-- Comment: Sat Oct  8 09;09;08 comment by...Ulrich H. -->
I forgot to mention yesterday that I touched the manual ISL bypass once more later because of the low PCE flows. I brought the supply pressure to 27.7 psi, which cranks op the SVX PCE flow to 3.3 lpm, i.e. above the warning limit of 3.2. 
<!-- Date: Fri Oct 7 16:34:32 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W2L3 
<li>problem n: 436 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: error is rare and intermittent, could not reproduce it in quiet time, needs monitoring ... 
<li>See <a href="DBreport.pl?detsys=SVX&wedge=B2W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Oct 7 17:56:48 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W4L4 
<li>problem n: 1233 
<li>Status: needs_access_8hr
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>This ladder is starting to give errors again.  We may need to re-align the BE Kluge.  If we wish to do this, Ken has to given 24 hours notice, the FCC test stand MUST be working.</p>  
<li>See <a href="DBreport.pl?detsys=SVX&wedge=B0W4&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Oct 7 18:13:18 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W1L4 
<li>problem n: 1521 
<li>Status: needs_observation
<li>Type: DRO_00F3
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>We set the thresholds of a4 (Chip 9 CONFIG order) and a2 (Chip 11C ONFIG order) to 255 to sparse it out.  Let's see how it performs during data taking.</p> 
<li>See <a href="DBreport.pl?detsys=SVX&wedge=B4W1&layer=L4">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Sat Oct 8 11:05:33 2005 -->
<b>IB2W2L0 gave no data during run 205313</b> (in 205312 it was fine). A new run was started, lets see what happens. If still no data, we could try power cycling the wedge.
<!-- Author: Sebastian -->
<!-- Comment: Sat Oct  8 11;51;24 comment by...Marcel -->
Does not look too good.
<pre>
f220c1c1 c2c256fc
</pre>
Powercycling is one option (easy and quick), but I suspect, either the FIB or the RX being bad. This shows similar symptoms to f323 a few weeks ago. 


<!-- Comment: Sat Oct  8 12;15;53 comment by...Sebastian -->
well, I do not see data either now, but svxmon is not complaining, so at some point there was data coming:
<pre>
Run 205314, Sat Oct  8 12:12:26
SVX
Status: OK
ISL
</pre>

<!-- Comment: Sat Oct  8 13;04;30 comment by...Ankush -->
<p> I just started looking and it doesn't look good to me.  I just rang the Control Room and the say SVXMOn is happy...very odd indedd</p>

<!-- Comment: Sat Oct  8 13;07;56 comment by...Ankush -->
<p>even stranger.......the svxmon_yellow.txt is happy. Could the ladder be returning data even so often.  So enough for SVXMON to be happy ?</p>


<pre>
Status: OK
---------------------------------------
Run 205314, Sat Oct  8 13:05:49
SVX
Status: OK
ISL
Status: OK
L00
Status: OK
</pre>



<!-- Comment: Sat Oct  8 13;26;56 comment by...Marcel -->
still no data from consumer dump.... This FIB lives in fib03, Slot 12. This means, it is relatively easy to fix.




<!-- Comment: Sat Oct  8 14;04;06 comment by...Ankush -->
<p>NW-Bottom...good.  That will be a good training opporunity for our newbies.  It as if this was almost arranged ;-)</p>
<!-- Comment: Sat Oct  8 16;30;08 comment by...Sebastian -->
The ladder was power cycled, we now get: 
<pre>f220 d0c20bd0 f221c2c4</pre>
we have to look at it in the next quiet time.
<!-- Comment: Sun Oct  9 01;33;41 comment by...s -->
The ladder is giving good data again. But does not seem to be back directly after the power cycle, so not sure what happend...
<!-- Date: Sat Oct 8 13:30:15 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7639&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7639  width='300' align='top'></a></td><td>This shows SVXMON, saw some data, but then the ladder died again. Plan of action: Obvious, Access and isolated problem.</td></tr></table>
<!-- Author: Marcel -->



<!-- Date: Sat Oct 8 17:27:48 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W2L0 
<li>problem n: 1548 
<li>Status: needs_work
<li>Type: Unknown
<li>Action: Incident
<li>entered by: yamaoka 
<li>description is: No data from this ladder during running.  We did try to power cycle the ladder, but that didn't help.  May be RX or fib. 
<li>See <a href="DBreport.pl?detsys=ISL&wedge=B2W2&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Oct 8 18:22:14 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W7L1 
<li>problem n: 1549 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>AVDD needed to be adjusted after a new power supply was put in. Observe it for a keep to check it is stable.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>496.925</td><td>496.925</td></tr>
<tr><td><b>Lower</b></td><td>495.0</td><td>485.0</td></tr>
<tr><td><b>Upper</b></td><td>505.0</td><td>495.0</td></tr></table> 
<li>See <a href="DBreport.pl?detsys=SVX&wedge=B0W7&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Oct 8 18:24:46 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W11L2 
<li>problem n: 1522 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>Had to raise BIAS limits again.  Observe and may have to pre-empt next limit change.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>104.197</td><td>104.197</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.0</td><td>130.0</td></tr></table> 
<li>See <a href="DBreport.pl?detsys=SVX&wedge=B3W11&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat Oct 8 18:44:35 2005 -->
<h4>The continuing saga of f220 and teaching a C0</h4> 
 
<p>I came into the control room to redefine the IMON limits for e071 and e3b2.  However I was told SVXMON was not running which was true. Between the ACES, SciCo and CO they were not able to get SVXMON running.</p> 
 
<p>So I came over and looked over the CO instructions webpage and 2 seconds later I found the exact instructions and got it started.  Somehow following web instructions is a little difficults for some people.</p> 
 
<p>Now back to my point.  f220 is now returning data. So it's OK for now. But it is flaky.  Definite candidate for fibre swap suring next access and take a spare FIB and RX.</p>   
<!-- Author: Grump MK2 -->



<!-- Date: Sun Oct 9 14:09:49 2005 -->
<h4>Return of the Muppets</h4> 
 
<p>I guess all the old-guard are probbably wondering how the detector will be running under the stewardship of Drs Grinstein and Mitra.  Well today was a very good sample.</p> 
 
<p>During Saturday morning IB2W2L0 (f220) was not returning any data.  But by magic, the ladder started to return data.  This was very puzzling.  It just so happens there was an access today (Sunday morning) which we piggy-backed to investigate this ladder.</p> 
 
<p>While testing with SVXDAQ, f220 was returning data and then started giving errors.  In NN mode it consistently gave c2c2.  So it looked like the problem was real.   Mark and I went into the collision hall to do a fibre-swap with IB2W2L1 (f221) and it showed the problem stayed with the DAQ channel.</p> 
 
<p>We then swapped the RX but this didn&#39t fix the problem. We swapped the FIB and this did not help either.  Eventually Sebastian reset the VRB and this was the problem,  So the access was unnecessary.</p> 
 
<p>The muppet part of this access is Mark and I could not find the "off" switch for b0fib03.  This may sound silly but we honestly could not find it.  We checked other racks and it was obvious for those.  Luckily Sebastian turned off the racks remotely but we had a litle trouble turning the rack back on after the FIB swap.</p> 
 
<p>So the summary is we swapped everything we could and traced the problem to a VRB whch had to be reset. But the access was good training for Mark (& Ankush). Ankush cannot find the "off" switch for b0fib03. <em>Welcome to muppet force</em>
<!-- Author: Ankush, Sasha, Jared, Sebastian and Mark -->
<!-- Comment: Sun Oct  9 14;15;08 comment by...Ankush et al -->
<p>Forgot to mention we did a COLD-START at the end everything passed CONFIG.  We ran for 5,000 events and there were no errors.</p>

<!-- Comment: Sun Oct  9 14;31;55 comment by...Marcel -->
The power supply for b0fib03 is behind the rack on the blue steel bar next to the wall. It is the only one, where this is different. It is there, because this supply died very often (assumed to be due to SEU) and was moved there. Sicne then, there were no problem s with this VME power supply.  
<!-- Comment: Sun Oct  9 14;56;13 comment by...Ankush et al -->
<p>Well Mark and I did spot it. But we couldn&#39t understand why someone would put it there.  So we did not want to start turning off/on random power supplies.  Then we also thought, if the PS is over there, maybe there&#39s a special switch on the crate so you don&#39t have to reach over....o well I guess not.</p>
<!-- Date: Sun Oct 9 14:17:13 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W2L0 
<li>problem n: 1548 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>Discovered the problem was due to an VRB which needed to be reset.  Now keep an eye on it check it stays OK.</p> 
<li>See <a href="DBreport.pl?detsys=ISL&wedge=B2W2&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sun Oct 9 14:43:57 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W2L0 
<li>problem n: 1548 
<li>Status: needs_observation
<li>Type: DRO_00F3
<li>Action: Swap_RX
<li>entered by: amitra 
<li>description is: <p>This ladder was not returning any data, so we swapped the RX. However we later discovered VRB need to be RESET.</p><table border=1>
   <tr>
    <td>
     <b>IN:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0161">0161</a>
    </td>
   </tr>
   <tr>
    <td>
     <b>OUT:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0356">0356</a>
    </td>
   </tr>
  </table> 
<li>See <a href="DBreport.pl?detsys=ISL&wedge=B2W2&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Oct 9 14:46:02 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W2/3All 
<li>problem n: 1000 
<li>Status: needs_observation
<li>Type: DRO_00F3
<li>Action: Swap_FIB
<li>entered by: amitra 
<li>description is: <p>The FIB was swapped as this ladder was not returning any data.  But it found that the VRB needed to be RESET.</p><table border=1>
   <tr>
    <td>
     <b>IN:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/fibdb/DBreport.pl?serial=134">134</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=125">125</a>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/fibdb/DBreport.pl?prep="></a>
    </td>
   </tr>
  </table> 
<li>See <a href="DBreport.pl?detsys=ISL&wedge=B2W2/3&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Oct 9 14:50:15 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W2/3All 
<li>problem n: 1000 
<li>Status: needs_observation
<li>Type: DRO_00F3
<li>Action: Swap_FIB
<li>entered by: amitra 
<li>description is: <p>Ooops...got the worn FIB Serial number.  THese are the correct ones.</p><table border=1>
   <tr>
    <td>
     <b>IN:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/fibdb/DBreport.pl?serial=134">134</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=126">126</a>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/fibdb/DBreport.pl?prep="></a>
    </td>
   </tr>
  </table> 
<li>See <a href="DBreport.pl?detsys=ISL&wedge=B2W2/3&layer=All">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Sun Oct 9 16:54:59 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7640&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7640' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7641&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7641' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Sun Oct  9 17;00;32 comment by...Ankush -->
<p>IB4W3L4 (f434)had been reported to be under-depleated.  This ladder has a PIN-HOLE as demonstrated by the larger current in bias0. But is probably not responsible for the under-depletion.  The current is Bias1 has been steadily increasing due to radiation damage.  My guess is the increase in the bias1 current has made the ladder under-depleat. Suggest increasing the bias voltage to see if that helps.  But then again, the bias-voltage should be decreasing until we invert?</p>

<!-- Date: Sun Oct 9 17:04:41 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W3L4 
<li>problem n: 273 
<li>Status: needs_work
<li>Type: pinhole
<li>Action: Monitoring
<li>entered by: amitra 
<li>description is: <p>This ladder has been reported under-depleated.  The ladder has a pin-hole for Bias0 but the Bias1 current has been steadily increasing.  See <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=269&frame=2&anchor=16:54:59'> Silicon e-log</a>.  This increase may be responsible for the under-depletion.  However, the depletion voltage should decrease until we invert?</p> 
<li>See <a href="DBreport.pl?detsys=ISL&wedge=B4W3&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sun Oct 9 17:18:00 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7642&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7642' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7643&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7643' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Sun Oct  9 17;22;12 comment by...Ankush -->
<p>IB4W5L0 (f450) has been reported as under-depleated. It has a PIN-HOLE as demonstrated by the large Bias1 current which apprears to be increasing since DS-Day 1700 (28 Aug 2005). The Bias0 current has been rock-steady.  I suspect the change in the Bias1 current is responsible for the under-depletion.  May need to increase the bias voltage.</p>

<!-- Date: Sun Oct 9 17:27:31 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W5L0 
<li>problem n: 539 
<li>Status: needs_work
<li>Type: pinhole
<li>Action: Monitoring
<li>entered by: amitra 
<li>description is: <p>This ladder was reported to be under-depleated.  The Bias1 current has been increasing since DS-Day 1700 (28 Aug 2005).  The Bias0 current has been completely flat. I suspect the increase in the Bias1 line current is responsible for the under-depletion. Suggest boosting the Bias voltage for the ladder.</p>  
<li>See <a href="DBreport.pl?detsys=ISL&wedge=B4W5&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sun Oct 9 17:39:10 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7644&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7644' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7645&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7645' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Sun Oct  9 17;47;20 comment by...Ankush -->
<p>Here is the Bias0 current for IB3W0L1 (f301).  It&#39s upper IMON limit had to be increased from 100.0 to 110.0 (Shown by the Red Line).  A simple linear fit to the data suggests the new IMON limit will be exceeded DS-Day 1752 (19 Oct 2005).  Maybe a good idea to increase the IMON limit at the start of the new main pager:Mon 17 Oct 2005.</p>

<!-- Date: Sun Oct 9 17:51:11 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W0L1 
<li>problem n: 1537 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: Monitoring
<li>entered by: amitra 
<li>description is: <p>The upper IMON limit had to be increased from 100.0 to 110.0.  A fit to the data suggests the new upper IMON limit will be exceeded on DS-Day 1752 (19 Oct 2005). 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=269&frame=2&anchor=17:39:10'> Silicon e-log</a>.</p> 
<li>See <a href="DBreport.pl?detsys=ISL&wedge=B3W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sun Oct 9 18:07:39 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7646&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7646' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7647&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7647' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7648&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7648' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7649&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7649' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Sun Oct  9 18;14;04 comment by...Ankush -->
<h4>Bias Currents for SB1W3</h4>

<p>In the Problem DB, SB1W3L4 (e134) was noted to have an irratic bias current.  If you look at the rest of the ladders in this wedge there are two distinct patterns.  From left to right we have: e131, e132, e133, e134.  e130 was taken out of the HWDB so no data is available.</p>

<p>The Hamamatsu ladders, e131 and e133 have the expected increase of Bias Current with integrated luminosity (Time).  However the Micron ladders, e132 and e134 have rather irratic bias currents.  In fact the current in e134 is so large it may even be a PIN-HOLE candidate. So more evidence that the Micron ladders are bad.</p>   

<!-- Date: Sun Oct 9 18:18:05 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>The bias current for this ladder is still irratic, although it seems to have dropped by ~300uA after DS-Day 1700.  Continue with the observation to see how it behaves. A plot of the bias current can be found in the <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=269&frame=2&anchor=18:07:39'> Silicon e-log</a>.</p>    
<li>See <a href="DBreport.pl?detsys=SVX&wedge=B1W3&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Oct 10 09:24:52 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W0L1 
<li>problem n: 1537 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>As a pre-emptive strike I raised the upper IMON limit on Bias0. Continue to observe hwo the current changes.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>78.0632</td><td>78.0632</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.0</td><td>120.0</td></tr></table> 
<li>See <a href="DBreport.pl?detsys=ISL&wedge=B3W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Oct 10 11:05:25 2005 -->
<br> 
<b>just like <i>"VH1`s The Best Week Ever"</i></b> 
<pre> 
Monday: 
 -All's quiet. 
 
Tuesday: 
 -Access: 
   *Fiber swap (SB4W1L4) show internal problem. 
   *Light level measurments (SB1W5L2). 
   *Problem writing CAENvolts.dat because of full svxii home area. 
  
 -Store 4431 (World Record Lumi 141.3E30). 
 -FIB 150 tested. 
 -Problem DB upgrade. 
 -Various ladder test/updates. 
  
Wednesday: 
 -Sebastian worked to understand the increase in resonances. 
 -C4Q4 rolling, caused unstable beam. 
 -D-Mode calibration at the end of the store. 
 -DAQ racks switched off for work on another system that just happens to share power with us. 
 -Store 4433. 
 -Various ladder test/updates. 
 
Thurday: 
 -PS 14 required hockerization twice to fix a DOIM voltage problem. 
 -TeV aborted early because of vacuum problem. 
 
Friday: 
 -Access: 
  *Probed PS cables. (f414, f412, f404) 
  *PS swap for SB0W7, to correct problem with DOIM voltages. 
  *Worked on SB1W6L4, determined problem is internal. 
  *Re-tuned some valves for the ISL and L00 cooling. 
 
Satuday: 
 -Store 44??. (I had problems with the elog) 
 -IB2W2L0, gave data intermittantly. 
 
Sunday: 
 -Access: 
  *Worked on IB2W2L0.  After much work resetting the VRB seemed to have fixed it.  Moral of the story try the easy stuff first. 
 -Various ladder test/updates. 
 
Monday: 
 -Various ladder work. 
 -TeV under repair. 
</pre>
<!-- Author: Jared -->