<!-- Title: 10:15:40  Mon Jan 31 2005 -->
<!-- Crewchief: Jared -->
<!-- Op1: Marcel -->
<!-- Op2: et. al. -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Another week another dollar.</pre>

<!-- Date: Mon Jan 31 15:05:48 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W2L3 
<li>problem n: 1333 
<li>Status: fixed
<li>Type: RX
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Problem has disappeared. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Jan 31 15:12:01 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W0L0 
<li>problem n: 647 
<li>Status: fixed
<li>Type: RX
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Bit problem is no longer a problem.  In the past month, appeared in run 192167 only (but for 68% of events.) 
<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: Mon Jan 31 15:17:54 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W6L4 
<li>problem n: 345 
<li>Status: fixed
<li>Type: TX
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: No bit errors seen.  Will this come back in the spring (like last year)? 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W6&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Jan 31 15:19:59 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W11L3 
<li>problem n: 1264 
<li>Status: fixed
<li>Type: Chip_capid
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Problem appears fixed, for now. 
<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: Mon Jan 31 19:03:48 2005 -->
<h4> E044</h4> 
showed a little excursion upwards in AVDD , so I bumped the limit up by 10. Should be reviewed in a few days 
<!-- Author: Marcel -->


<!-- Date: Mon Jan 31 19:05:55 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5961&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5962' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5963&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5964' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5965&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5966' ></a></center>
<!-- Author: Marcel -->
<!-- Comment: Mon Jan 31 19;07;18 comment by...Marcel -->
Current history of e044, looks like one chip is coming back, although values are not right for this. e044 is a troubled ladder anyway

<!-- Date: Mon Jan 31 19:09:23 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W4L4 
<li>problem n: 697 
<li>Status: unfixable
<li>Type: jumper
<li>Action: IMON_limits
<li>entered by: marcel 
<li>description is: changed limits again<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1200</td><td>1200</td></tr>
<tr><td><b>Lower</b></td><td>1100</td><td>1100</td></tr>
<tr><td><b>Upper</b></td><td>1325</td><td>1335</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W4&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Feb 1 09:01:17 2005 -->
<h2> RF station died </h2> 
Came in this morning to learn, that an RF station has died last night. This is certainly a thing, which first should be <b>noted in the elog </b> and secondly may justify to call the on-call SPL for advice, if the silicon remains in or not. TeVMON may not tell you the complete story. I told the Scico to take the Silicon out 30 minutes before the end of the store. I would like to see, whether they can abort this one cleanly, so we may make up our minds, what the future procedure for this is. Past experiences may not be 100 % accurate anymore, since the machine has been modified as well.  
<!-- Author: Marcel -->
<!-- Comment: Tue Feb  1 09;01;47 comment by...Marcel -->
For reference, this time it is station 7


<!-- Comment: Tue Feb  1 10;16;02 comment by...Jared -->
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=94&frame=2&anchor=01:09:01.704'>
Beam quality</a> didn't seem to suffer from the passing of the RF.  
<!-- Date: Tue Feb 1 09:44:19 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5967&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5967' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5968&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5968' width='300'></a></center>
<!-- Author: Marcel -->
<!-- Comment: Tue Feb  1 09;48;01 comment by...Marcel -->
This are the losses including B0PBSM/B0ABSM (the ones Gino liked to look at as well) and the RFsation summary from Rick Tesarek (recall RJT-RF-Stat. The death of Station 7 is clearly visible.<br>
Talked to Rob, I'd like to watch the end of this store top get some confidence, that they are aborting this one cleanly. If so, and the loesses look sane, we can discuss to keep the Silicon in till the official end of store.




<!-- Date: Tue Feb 1 10:12:53 2005 -->
For the record, there was a hockerization by ACE last night on crate 2, see also<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=94&frame=2&anchor=04:54:57.885'> 
main elog</a>.
<!-- Author: rslu -->
<!-- Comment: Tue Feb  1 10;19;10 comment by...Jared -->
And <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=94&frame=2&anchor=07:36:23.087'>
crate 5 </a>

<!-- Date: Tue Feb 1 10:50:32 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W4L1 
<li>problem n: 576 
<li>Status: needs_observation
<li>Type: Chip_other
<li>Action: Change_last_chip
<li>entered by: yamaoka 
<li>description is: Chopped last 2 chips from the ladder. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W4&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Feb 1 10:55:57 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 384 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 192573
DPS-on run       : 192572
Requested by     : Jason
Submitted        : 2005-01-25 10:37:15
Completed        : 2005-02-01 10:55:48
Status           : FAILURE
Comment          : test new framework

Last processing stage reported : calculating DPS-off pedestals
Failure diagnostics :
child process exited abnormally
</pre>
<!-- Author: D-mode script run_calib_analysis_noph.tcl -->



<!-- Date: Tue Feb 1 11:20:56 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5969&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5969  width='300' align='top'></a></td><td>Phi side SB2W5L4</td></tr></table>
<!-- Author: Jared -->


<!-- Date: Tue Feb 1 11:22:44 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5970&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5971  width='300' align='top'></a></td><td>SB2W5L4 DVDD</td></tr></table>
<!-- Author: Jared -->
<!-- Comment: Tue Feb  1 11;29;18 comment by...Jared -->
<pre>IMON limits changed to 130-200.</pre>


<!-- Date: Tue Feb 1 15:58:12 2005 -->
<h3> Understanding bit errors in f802 </h3> 
I run f802 and was after some struggling with SVXDAQ able to run this ladder. So the error is there, it is a bit 0 low and it does not follow the fiber. 
The errors are mostly the kind of   
<pre> 
57715875 58705a73 5b705c70 
</pre> at a low rate, but also 
<pre> 
7c7c7e7b 7f7d8022 c1c10178 0278037c 14840577 0674077a da9c0976 0a770b76 
a4710d74 0e780f72 4b4b1176 1272136f 51661576 166f1776 33911973 1a721b 
</pre> 
which looks completely sick. so it seems to be this VRB, which we can't easily swapp, because it is in b0svx06 (SRC). We'll have to do that at the earliest convenience<br>
In other news, there seems to be some problems with the VRB readout in the ISL 8 buffer mode. These disappear, if ypu switch back to 4 buffers in the SRC. No conclusions yet, just an observation.
<!-- Author: Marcel -->
<!-- Comment: Tue Feb  1 20;29;43 comment by...Marcel -->
<h3> Update on the whole shabang </h3>
My first assumption was, that SVXDAQ has problems with the 8+4 buffers in ISL/L00 now. But on second thought, SVXDAQ does not care about this, it reads the stuff from the Output Fifo, as does the EVB. So I used the quiet time to reproduce the fatal failures with really screwed events we saw this afternoon (PCA/PCB bytes wrong) etc. <br>
I was assuming, that maybe due to changing the buffers, we are actually writing in areas, we have never ever written anything before. Se we may have found some bad memory in the VRB. The reason we see that in ISL only in SVXDAQ, is that SVXDAQ uses readall, compared to RC. So we having larger chunks of data. For L00 we already have one bad VRB (f802), that we need to change. 
So I ran through all the wedges using only reasonable ladders and trying to see, if I can find anything else of that kind. <br>
A first quick run gave the following:
<ul>
<li>f00/f01 </li>
<li>f12/f13 </li>
<li>f10/11 </li>
<li>f03/02 </li>
<li>f22 </li>
</ul>
I did not find any other problems. So I went back to these guys and had a look at them in Detail. I was not able to reproduce the catastrophic failures of this afternoon for these ladders, but I found a bit error in f031, that disappears when switching from 8 to 4 buffers in the SRC. Since Corrine and I had troubles this afternoon with some these guys, we should revisit them during next quiet time just to be sure, what is going on there.<br>
quiet time is over, so I'll take off now.
<!-- Date: Tue Feb 1 19:03:44 2005 -->
<b>Front-end oscillation studies</b><br> 
Today during some quiet time we followed up on the idea that the front-end oscillations originate from a  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=227&frame=2&anchor=13:57:00'> 
bias problem </a>. 
<p> 
The two questions we wanted to answer were: 
<ol> 
<li> Does the FEO-like behavior of underbiased good ladders disappear if the ladder is left in the same HV configuration for a while? 
<li> If we over-bias a FEO candidate do the symptoms disappear? 
</ol> 
<p> 
Question 1: We underbiased the known trouble-free ladders f130 and f131.  We started by running them in standby, and then with bias at 10% of nominal, then 20%, etc.  FEO-like symptoms were visible in f131 chips 9b-98 for standby through 50% nominal bias.  The symptoms were gone at 60% nominal and up.  Since the ladder was in standby for hours before we ran it and the problem was still visible, it does not seem to be (in principle) time dependent. 
<p> 
Question 2: We overbiased first f021 and then f210, both of which are Hamamatsu ladders and therefore can be biased up to 140V.  <br> 
f021: 
<ul> 
<li> Nominal bias is Bias0 = 90 V Bias1 = 100V.  We brought that up to 140/140 in 10 V steps, but the symptoms were still present.  In fact the symptoms (grassy pedestal/data) were present on both the p <i>and</i> n sides of the affected half-ladder.  Did overbiasing help? <i>no</i> 
</ul> 
f210: 
<ul> 
<li> Nominal bias is Bias0 = 100V Bias1 = 100V.  We ran this at nominal bias for a while.  First the problem was not evident, but then symptoms gradually appeared on some of the chips known to be affected.  Then the symptoms gradually disappeared again.  On the  other hand, similar symptoms were seen on some chips from the p side of that ladder.  Since we could not really reproduce the known symptoms, it was difficult to say whether overbiasing helped anything, although we stepped the bias up from 100/100 to 120/120 in 10V steps.   
</ul> 
So although we answered the two questions we had, it does not seem that we have made any real progress. 
<p> 
One other thing we tried (on a suggestion from Ankush) was to change the integrator adjustible bandwith using the initialization bitstream.  The nominal setting is "5".  We tried both "3" and "7" but neither seemed to affect anything.
<!-- Author: corrinne, Ankush, Marcel -->
<!-- Comment: Tue Feb  1 19;14;40 comment by...Ben -->
<pre>Can you remind me what is "integrator adjustible bandwith"?  Is that rdriver?  And then for clarity please remind me what "3" "5" and "7" correspond to in physical units of some sort?

Initialization bitstream?  Is that related to the gulf-stream?</pre>


<!-- Comment: Tue Feb  1 20;45;56 comment by...Marcel -->
<h4>for the record </h4>
The PSGUI dump from all the changes
<pre>
Tue Feb 01 15:50:10 CST 2005     success: Voltage0 changed for IB1W3 L0 to 5.0 V
Tue Feb 01 15:50:18 CST 2005     success: Voltage0 changed for IB1W3 L1 to 9.0 V
Tue Feb 01 15:50:28 CST 2005     success: Voltage1 changed for IB1W3 L0 to 4.5 V
Tue Feb 01 15:50:37 CST 2005     success: Voltage1 changed for IB1W3 L1 to 8.0 V
Tue Feb 01 15:55:49 CST 2005     success: Voltage0 changed for IB1W3 L0 to 10.0 V
Tue Feb 01 15:55:57 CST 2005     success: Voltage0 changed for IB1W3 L1 to 18.0 V
Tue Feb 01 15:56:07 CST 2005     success: Voltage1 changed for IB1W3 L0 to 4.5 V
Tue Feb 01 15:56:16 CST 2005     success: Voltage1 changed for IB1W3 L1 to 16.0 V
Tue Feb 01 15:56:25 CST 2005     success: Voltage1 changed for IB1W3 L0 to 9.0 V
Tue Feb 01 16:05:48 CST 2005     success: Voltage0 changed for IB1W3 L0 to 15.0 V
Tue Feb 01 16:06:09 CST 2005     success: Voltage0 changed for IB1W3 L1 to 27.0 V
Tue Feb 01 16:06:21 CST 2005     success: Voltage1 changed for IB1W3 L0 to 13.5 V
Tue Feb 01 16:06:27 CST 2005     success: Voltage1 changed for IB1W3 L1 to 24.0 V
Tue Feb 01 16:12:56 CST 2005     success: Voltage0 changed for IB1W3 L0 to 20.0 V
Tue Feb 01 16:13:02 CST 2005     success: Voltage0 changed for IB1W3 L1 to 36.0 V
Tue Feb 01 16:13:11 CST 2005     success: Voltage1 changed for IB1W3 L0 to 18.0 V
Tue Feb 01 16:13:20 CST 2005     success: Voltage1 changed for IB1W3 L1 to 32.0 V
Tue Feb 01 16:17:18 CST 2005     success: Voltage0 changed for IB1W3 L0 to 25.0 V
Tue Feb 01 16:17:26 CST 2005     success: Voltage0 changed for IB1W3 L1 to 45.0 V
Tue Feb 01 16:17:39 CST 2005     success: Voltage1 changed for IB1W3 L0 to 22.5 V
Tue Feb 01 16:17:46 CST 2005     success: Voltage1 changed for IB1W3 L1 to 40.0 V
Tue Feb 01 16:22:41 CST 2005     success: Voltage0 changed for IB1W3 L0 to 30.0 V
Tue Feb 01 16:22:47 CST 2005     success: Voltage0 changed for IB1W3 L1 to 54.0 V
Tue Feb 01 16:22:55 CST 2005     success: Voltage1 changed for IB1W3 L0 to 27.0 V
Tue Feb 01 16:23:07 CST 2005     success: Voltage1 changed for IB1W3 L1 to 48.0 V
Tue Feb 01 16:24:10 CST 2005     success: Channel0 ISL B1 W3 to STANDBY
Tue Feb 01 16:24:19 CST 2005     success: Channel1 ISL B1 W3 to STANDBY
Tue Feb 01 16:26:27 CST 2005     success: Loading CAENvolts.dat
Tue Feb 01 16:36:48 CST 2005     success: Voltage0 changed for IB1W3 L0 to 30.0 V
Tue Feb 01 16:36:55 CST 2005     success: Voltage0 changed for IB1W3 L1 to 54.0 V
Tue Feb 01 16:37:03 CST 2005     success: Voltage1 changed for IB1W3 L0 to 27.0 V
Tue Feb 01 16:37:08 CST 2005     success: Voltage1 changed for IB1W3 L1 to 48.0 V
Tue Feb 01 16:46:57 CST 2005     success: Voltage0 changed for IB1W3 L0 to 35.0 V
Tue Feb 01 16:47:05 CST 2005     success: Voltage0 changed for IB1W3 L1 to 42.0 V
Tue Feb 01 16:47:14 CST 2005     success: Voltage0 changed for IB1W3 L1 to 63.0 V
Tue Feb 01 16:47:24 CST 2005     success: Voltage1 changed for IB1W3 L0 to 31.5 V
Tue Feb 01 16:47:30 CST 2005     success: Voltage1 changed for IB1W3 L1 to 56.0 V
Tue Feb 01 16:51:53 CST 2005     success: Voltage0 changed for IB1W3 L0 to 30.0 V
Tue Feb 01 16:51:59 CST 2005     success: Voltage0 changed for IB1W3 L1 to 54.0 V
Tue Feb 01 16:52:09 CST 2005     success: Voltage1 changed for IB1W3 L0 to 27.0 V
Tue Feb 01 16:52:20 CST 2005     success: Voltage1 changed for IB1W3 L1 to 48.0 V
Tue Feb 01 16:59:45 CST 2005     success: Voltage0 changed for IB1W3 L0 to 25.0 V
Tue Feb 01 16:59:53 CST 2005     success: Voltage0 changed for IB1W3 L1 to 45.0 V
Tue Feb 01 17:00:03 CST 2005     success: Voltage1 changed for IB1W3 L0 to 22.5 V
Tue Feb 01 17:00:15 CST 2005     success: Voltage1 changed for IB1W3 L1 to 40.0 V
Tue Feb 01 17:06:17 CST 2005     success: Channel0 ISL B1 W3 to STANDBY
Tue Feb 01 17:06:21 CST 2005     success: Channel1 ISL B1 W3 to STANDBY
Tue Feb 01 17:06:40 CST 2005     success: Loading CAENvolts.dat
Tue Feb 01 17:07:14 CST 2005     success: Channel1 ISL B0 W2 ON
Tue Feb 01 17:34:01 CST 2005     success: Voltage0 changed for IB0W2 L1 to 100.0 V
Tue Feb 01 17:36:22 CST 2005     success: Voltage0 changed for IB0W2 L1 to 110.0 V
Tue Feb 01 17:36:31 CST 2005     success: Voltage1 changed for IB0W2 L1 to 110.0 V
Tue Feb 01 17:39:53 CST 2005     success: Voltage0 changed for IB0W2 L1 to 120.0 V
Tue Feb 01 17:40:05 CST 2005     success: Voltage1 changed for IB0W2 L1 to 120.0 V
Tue Feb 01 17:40:13 CST 2005     success: Max Current1 changed for IB0W2 L1 to 500.0 uA
Tue Feb 01 17:40:19 CST 2005     success: Max Current0 changed for IB0W2 L1 to 500.0 uA
Tue Feb 01 17:44:00 CST 2005     success: Voltage0 changed for IB0W2 L1 to 130.0 V
Tue Feb 01 17:44:07 CST 2005     success: Voltage1 changed for IB0W2 L1 to 130.0 V
Tue Feb 01 17:47:01 CST 2005     success: Voltage1 changed for IB0W2 L1 to 140.0 V
Tue Feb 01 17:49:14 CST 2005     success: Voltage1 changed for IB0W2 L1 to 130.0 V
Tue Feb 01 18:00:32 CST 2005     success: Voltage1 changed for IB0W2 L1 to 140.0 V
Tue Feb 01 18:08:13 CST 2005     success: Max Current0 changed for IB2W1 L0 to 500.0 uA
Tue Feb 01 18:08:21 CST 2005     success: Max Current1 changed for IB2W1 L0 to 500.0 uA
Tue Feb 01 18:08:32 CST 2005     success: Channel0 ISL B2 W1 ON
Tue Feb 01 18:30:41 CST 2005     success: Voltage0 changed for IB2W1 L0 to 110.0 V
Tue Feb 01 18:30:46 CST 2005     success: Voltage1 changed for IB2W1 L0 to 110.0 V
Tue Feb 01 18:33:42 CST 2005     success: Voltage0 changed for IB2W1 L0 to 120.0 V
Tue Feb 01 18:33:49 CST 2005     success: Voltage1 changed for IB2W1 L0 to 120.0 V
Tue Feb 01 18:43:23 CST 2005     success: Channel0 ISL B2 W1 to STANDBY
Tue Feb 01 18:43:33 CST 2005     success: Channel1 ISL B0 W2 to STANDBY
</pre>


<!-- Comment: Thu Feb  3 21;30;47 comment by...corrinne -->
<br>The "integrator adjustable bandwidth" is not Rdriver, it is 3 bits which adjust the capacitor value for the integrator which transfers charge from the detector into the pipelines.  It is discussed on (at least) pages 15, 53, and 60 of the SVX manual.  How any physical capacitance depends on the settings, including even whether 7 is the largest or smallest capacitance, remains obscure. <p>
Perhaps we are not worthy of the information.
<p>
The initialization bistream strongly resembles the gulf-stream in that more depends on it than most people realize, and if it dissappears we are in trouble.
<!-- Date: Tue Feb 1 22:57:40 2005 -->
When I came in for the shot Fib06 was unresponsive reset and shepherd fixed. See <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=96&frame=2&anchor=22:54:39.142'>e-log</a> 
 
  
<!-- Author: Jared -->
<!-- Comment: Tue Feb  1 23;01;32 comment by...Marcel -->
did it responds to ping or where you able to login via vxlogin ?
If so, a simple reboot would have been less invasive. If the crate CPU does not respond, well then there is no other way



<!-- Date: Tue Feb 1 23:04:22 2005 -->
<pre>Shot came in with lum. ~104e30.  Losses were very low.  Lostp=4kHz; Lostpb=3kHz; B0PAGC=300Hz.</pre>
<!-- Author: Jared -->


<!-- Date: Wed Feb 2 08:29:04 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5972&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5972  width='300' align='top'></a></td><td>ISL IB2W2L3 is not there .. according to IMON</td></tr></table>
<!-- Author: Marcel -->


<!-- Date: Wed Feb 2 08:31:58 2005 -->
PS gui tells me, it draws current, SVXMON does not show any problems .... AVDD and BIAS are ok ... <br> 
Mad Cow Disease ?
<!-- Author: Marcel -->


<!-- Date: Wed Feb 2 08:36:03 2005 -->
Pulled a resonance last night.  See <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=97&frame=2&anchor=05:26:17.496'>e-log</a>
<!-- Author: Jared -->


<!-- Date: Wed Feb 2 08:52:50 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5973&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5974  width='300' align='top'></a></td><td>IMON plot for IB2W2L3</td></tr></table>
<!-- Author: Marcel -->
<!-- Comment: Wed Feb  2 08;53;20 comment by...Marcel -->
This happened at 05:50 unnoted by the aces


<!-- Comment: Wed Feb  2 08;57;40 comment by...Marcel -->
This guy also sees physics in SVXMON

<!-- Comment: Wed Feb  2 10;49;14 comment by...Marcel -->
<b>Hockerization</b> did the trick 


<!-- Date: Wed Feb 2 10:59:10 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5975&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5975  width='300' align='top'></a></td><td>Dean's IMON version with the new limits</b></td></tr></table>
<!-- Author: Marcel -->


<!-- Date: Wed Feb 2 11:06:53 2005 -->
<pre>Because of a lost RF station the Si was put in standby.  Unforutunately RC was in PAUSE not HALT when the monitoring ACE put the Si in standby.  The DAQ ACE then put RC in HALT. 
 
When we tried to restart the run, there was a DAQ problem.  A new run was started to try and fix the problem, but ladders in fib02 and fib06 tripped.  I put the system through a COLDSTART and then had the Si put back in the run.   
 
   </pre>
<!-- Author: Jared  -->


<!-- Date: Wed Feb 2 11:40:45 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5976&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5976' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5977&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5977' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5978&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5978' width='300'></a></center>
<!-- Author: MArcel -->
<!-- Comment: Wed Feb  2 11;41;16 comment by...MArcel -->
test plots



<!-- Date: Wed Feb 2 11:52:06 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5979&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5980  width='300' align='top'></a></td><td>SVT SpyMon for store 3956</td></tr></table>
<!-- Author: Jared -->


<!-- Date: Wed Feb 2 12:17:50 2005 -->
<pre>Had another resonance error.  See <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=98&frame=2&anchor=12:09:36.427'>e-log</a></pre>
<!-- Author: Jared -->
<!-- Comment: Wed Feb  2 12;18;30 comment by...Jared -->
oops...<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=98&frame=2&anchor=12:09:36.427'>e-log </a>


<!-- Date: Wed Feb 2 13:19:28 2005 -->
<table border=0><td><tr><td bgcolor=#e0e030><H1> 
<A HREF ="https://www.costco.com/OrderStatus/TrackingDetails.aspx?PurchaseOrderId=c88ffe36-b03b-4059-80c3-a0e51e460942&SeqNo=1&TrackingNumber=1Z3065RV0310023306"> 
Coffee maker tracking page</a> 
</h1> 
 
What is the status of the IFIX interface for it?</td></tr></td></table>
<!-- Author: bbrau -->

<!-- Date: Thu Feb 3 06:57:28 2005 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 385
Calibration type  : standard
Run period tag    : Feb_2005
DPS-off run       : 193123
DPS-on run        : 193122
Requested by      : Tuula Maki
Main process id   : 16830
Comment           : L3 subfarms 3 & 5 excluded
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->



<!-- Date: Thu Feb 3 08:27:35 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5981&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5982  width='300' align='top'></a></td><td>SB0W5L2: Pinkie during calibration.  Went away when the Ace went back to normal running.</td></tr></table>
<!-- Author: Jared -->


<!-- Date: Thu Feb 3 12:12:50 2005 -->
<h2> Moving Logic Analysers </h2> 
Upon Request from the L3 we moved the logic analyser on the first floor. Therefore we had to unhook the cables on the LA side( we did not want to unhook cables on the SRC side of things). This worked but it is still an open heart operation,you would like to avoid.  We will never do this again, if it is not absolutely necessary. <br> 
Certainly not for changing one broken node, that is just not worth the risk.  
  
  
<!-- Author: Marcel/Ankush -->


<!-- Date: Thu Feb 3 15:00:14 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5983&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5984  width='300' align='top'></a></td><td>SB2W8L4 was't drawing any bias current.  Hockerization brought it back.</td></tr></table>
<!-- Author: Jared -->


<!-- Date: Thu Feb 3 15:10:03 2005 -->
<pre>Store 3958 went in at 112e30 with low losses.  Unfortunately MCR left a collimator in the the wrong place and it had to be moved.  We went to standby, but it did give us a chance to work on SB2W8L4 vbias.  </pre>
<!-- Author: Jared -->


<!-- Date: Thu Feb 3 15:12:00 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5985&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5986  width='300' align='top'></a></td><td>SpyMon plot for store 3958</td></tr></table>
<!-- Author: Jared -->


<!-- Date: Thu Feb 3 17:03:32 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5991&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5991' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5992&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5992' width='300'></a></center>
<!-- Author: Ankush & Jared -->


<!-- Date: Thu Feb 3 17:04:36 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5993&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5994  width='300' align='top'></a></td><td> </td></tr></table>
<!-- Author: Ankush & Jared -->
<!-- Comment: Thu Feb  3 17;09;12 comment by...Ankush & Jared -->
<b> Looking at history of B4W5L4 </b>
<p>This ladder had gone pink in IMON.  The mean charge for this ladder was looked at for runs 193107 & 193167 and they looked similar. We will adjust the IMON limits for this ladder.</p>

<!-- Comment: Thu Feb  3 17;11;26 comment by...Jared -->
<pre>Actually right now we will just "IGNORE"</pre>


<!-- Date: Thu Feb 3 17:20:04 2005 -->
<table border=0><td><tr><td bgcolor=#e0e030>We have a new device, available in the Silicon office: 
<h1> The Espresso machine finally arrived </h1> 
Big thanks to Ben for ordering it and bringing it in today.<br> 
<h3> Espresso is excellent !!! </h3> 
 
 
 
 
</td></tr></td></table>
<!-- Author: Marcel -->


<!-- Date: Thu Feb 3 17:46:29 2005 -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2005&action=view&page=-1922&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2005&action=view&page=-1922 width='300' align='top'></a></td><td>BLM</td></tr></table> 
 
 

<!-- Author: Jared -->
<!-- Comment: Thu Feb  3 17;47;51 comment by...Jared -->
<pre>BLM plot of the quench of store 3958.</pre>


<!-- Date: Thu Feb 3 19:36:01 2005 -->
<h3>Access Summary (more cable probing...)</h3> 
Probed the bias cable of SB4W2, Layers 0 and 1, to see if they looked normal and if there was any sign of a connection between them.  Results:<br> 
L0<br> 
<ul> 
<li> positive to negative, negative to positive:  overload 
<li> negative to reference: ramp up to OL 
<li> positive to reference: OL 
</ul> 
L1<br> 
<ul> 
<li> positive to negative, negative to positive:  overload 
<li> negative to reference: OL 
<li> positive to reference: ramp up to OL 
</ul> 
Probing between L0 and L1, everything showed OL (with no obvious ramp up) EXCEPT  
<ul> 
<li> L0 negative, L1 reference: ramp up to OL 
<li> L0 negative, L1 positive: 182/44.5 kOhms (different reading depending on which had the positive lead) 
<li> L0 reference, L1 positive: ramp up to OL 
<li> L0 reference, L1 reference: 0.3 MOhms/ramp up to OL 
</ul> 
Then checked a neighboring wedge (SB5W2) and saw the same sorts of measurements between L0 and L1, so nothing obvious is wrong with SB4W2.<br>
<!-- Author: Jen, Jared, Ankush -->

<!-- Date: Thu Feb 3 19:39:13 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W2L0 
<li>problem n: 767 
<li>Status: needs_work
<li>Type: BIAS
<li>Action: PS_work
<li>entered by: jpursley 
<li>description is: Probed bias cable, checking for connection with L1.  Nothing obviously wrong.  See <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=234&frame=2&anchor=19:36:01'>elog</a>  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W2&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Feb 3 19:53:10 2005 -->
<h3>Testing e224 </h3> 
We tried to get e224 to work again. We sparsed chip 5 and we still have a bit error for bit 4. The two last chips are gone. But otherwise, it looks ok. We should test it a bit longer, just to see, if it holds current or not.  
<!-- Author: Rong & Marcel -->


<!-- Date: Thu Feb 3 19:54:51 2005 -->
<table><tr><td><a href=/elog/notebooks/silicon/Thu_Feb__3_2005_195448.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5996  align='top'></a></td><td>Plot for e223 and e224</td></tr></table>
<!-- Author: Marcel -->


<!-- Date: Thu Feb 3 20:49:09 2005 -->
<h2> Problems with d-mode calibration </h2> 
<pre> 
Data representation is 0xd7000000. 
(MLE) b0dau32.fnal.gov:csl_mon_send:8:15:33 PM->CSL rejected event because it corresponds to an old version of ROOT.  
 Data representation is 0xd8000000. 
(MLE) b0dau32.fnal.gov:csl_mon_send:8:15:33 PM->CSL rejected event because it corresponds to an old version of ROOT.  
 Data representation is 0xcb000000. 
(MLE) b0dau32.fnal.gov:csl_mon_send:8:15:33 PM->CSL rejected event because it corresponds to an old version of ROOT.  
 Data representation is 0xca000000. 
(MLE) b0dau32.fnal.gov:csl_mon_send:8:15:33 PM->CSL rejected event because it corresponds to an old version of ROOT.  
 Data representation is 0xd5000000. 
(MLE) b0dau32.fnal.gov:csl_mon_send:8:15:33 PM->CSL rejected event because it corresponds to an old version of ROOT.  
 Data representation is 0xdf000000. 
(MLE) b0dau32.fnal.gov:csl_mon_send:8:15:33 PM->CSL rejected event because it corresponds to an old version of ROOT.  
 Data representation is 0xe0000000. 
(MLE) b0dau32.fnal.gov:csl_mon_send:8:15:33 PM->CSL rejected event because it corresponds to an old version of ROOT.  
 Data representation is 0xd3000000. 
(MLE) b0dau32.fnal.gov:csl_mon_send:8:15:34 PM->CSL rejected event because it corresponds to an old version of ROOT.  
 Data representation is 0xdd000000. 
</pre> 
 
so we cannot tkae Dmode calibration, although we are reading out the VRB's, e.g we are seeing L2A. 
<!-- Author: Marcel & Jared -->
<!-- Comment: Fri Feb  4 08;59;31 comment by...Marcel -->
Update from Tony Vaiculis
<pre>
I guess this calibration problem has nothing to do
with SVX people. It looks like the main CSL
is using the new pointer space (as we know)
and so it looks at word 20 to find the
"data representation". BUT, the sending program,
in this case Level-3 code, is apparently using the old pointer
space definition which puts the event number
into word 20 of the pointer space. If this is the case
then the error messages below make sense.
</pre>
and from Gilles de Lentdecker
<pre>
I guess it is because Run Configuration has not been updated for that
calibration. If someone could check what is the actual L3TAG used,
Veronique who is on shift right now could easily replace it by the
corresponding L3TAG using the new cs pointer space. If the corresponding
L3TAG does not exist then it is easy for us to build a new one. But I need
to know what is the L3TAG used for this calib to do so.
-Veronique, please could you check the L3TAG or the table used for that
calib. and replace it, if possible ?
</pre>
<!-- Comment: Fri Feb  4 09;43;08 comment by...Jason -->
Veronique has updated the run configurations with a new NULL L3 executable which can use the new CSL (tag 527).
<BR>
Note this NULL exe does not even include bank compression.  We can run now without bank compression.
<BR>
<!-- Date: Fri Feb 4 08:31:30 2005 -->
<pre>Shot went in at ~70e30 with low losses.</pre>
<!-- Author: Jared -->


<!-- Date: Fri Feb 4 08:32:50 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5997&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5998  width='300' align='top'></a></td><td>Spymon plot for store 3962</td></tr></table>
<!-- Author: Jared -->

<!-- Date: Fri Feb 4 08:41:00 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W5L4 
<li>problem n: 929 
<li>Status: fixed
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: yamaoka 
<li>description is: Adjusted IMON limits again.  High end now 1070.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1050</td><td>1050</td></tr>
<tr><td><b>Lower</b></td><td>1050</td><td>1050</td></tr>
<tr><td><b>Upper</b></td><td>1060</td><td>1070</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W5&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Feb 4 08:43:39 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5999&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6000  width='300' align='top'></a></td><td>SB4W5L4: IMON Plot</td></tr></table>
<!-- Author: Jared  -->




<!-- Date: Fri Feb 4 12:04:09 2005 -->
<table border=0><td><tr><td bgcolor=#e0e030><h1>Aaaahh... what a difference a ceramic espresso cup makes.</h1></td></tr></td></table>
<!-- Author: David -->

<!-- Date: Fri Feb 4 16:00:35 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W1L2 
<li>problem n: 1396 
<li>Status: needs_work
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: rahaman 
<li>description is: About 60% bad events coming from unknown chip error. 
<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 Feb 5 03:32:40 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W2L2 
<li>problem n: 383 
<li>Status: needs_work
<li>Type: DVDD
<li>Action: Removed_hdwdb
<li>entered by: yamaoka 
<li>description is: DVDD trip seems to have come back. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W2&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat Feb 5 03:35:49 2005 -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2005&action=view&page=-2011&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2005&action=view&page=-2012 width='300' align='top'></a></td><td>SB5W2L2 removed from HDWDB because of DVDD OC trip.</td></tr></table>
<!-- Author: Jared -->
<!-- Comment: Sat Feb  5 03;37;36 comment by...Jared -->
<pre>Couldn't recover DVDD trip.  Tried hockerization as suggested in problem db, but that didn't help.  COLDSTART also didn't help.</pre>

<!-- Date: Sat Feb 5 08:34:09 2005 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 386
Calibration type  : standard
Run period tag    : Feb_2005
DPS-off run       : 193274
DPS-on run        : 193273
Requested by      : Veronique
Main process id   : 12418
Comment           : even though Interval0 is at 100000 the L3 only uses half the farm and 2 nodes per farm, just to let you know.
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->


<!-- Date: Sat Feb 5 09:52:37 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W2L0 
<li>problem n: 767 
<li>Status: needs_work
<li>Type: BIAS
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: we tried to power this ladder again after the cable probing, still trips on Bias. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W2&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat Feb 5 11:21:40 2005 -->
<b>Store 3963 Quenched</b> before scrapping.  Ace did a COLDSTART things seem ok.   
<br> 
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2005&action=view&page=-2027&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2005&action=view&page=-2027 width='300' align='top'></a></td><td>BLM post-quench plots</td></tr></table> 
 
  
<!-- Author: Jared -->


<!-- Date: Sat Feb 5 12:45:48 2005 -->
<4>Testing f103</h4> 
In the process of tracking down some dubious wedgewide BXING errors, I ran f10x again. Still no BXING errors in SVXDAQ, but I found a CAP ID error in f103 in chip 4. 
<pre> 
 996 E 1 Error: CAP ID           F 0 P 3 C 3 = 27 F 0 P 3 C 4 = 31 
R 996 E 1 Error: CAP ID           F 0 P 3 C 4 = 31 F 0 P 3 C 5 = 27 
R 996 E 2 Error: CAP ID           F 0 P 3 C 3 = 31 F 0 P 3 C 4 = 63 
R 996 E 2 Error: CAP ID           F 0 P 3 C 4 = 63 F 0 P 3 C 5 = 31 
R 996 E 3 Error: CAP ID           F 0 P 3 C 3 = 9 F 0 P 3 C 4 = 63 
R 996 E 3 Error: CAP ID           F 0 P 3 C 4 = 63 F 0 P 3 C 5 = 9 
R 996 E 16 Error: CAP ID           F 0 P 3 C 3 = 15 F 0 P 3 C 4 = 28 
R 996 E 16 Error: CAP ID           F 0 P 3 C 4 = 28 F 0 P 3 C 5 = 15 
R 996 E 44 Error: CAP ID           F 0 P 3 C 3 = 20 F 0 P 3 C 4 = 9 
R 996 E 44 Error: CAP ID           F 0 P 3 C 4 = 9 F 0 P 3 C 5 = 20 
R 996 E 67 Error: CAP ID           F 0 P 3 C 3 = 8 F 0 P 3 C 4 = 4 
R 996 E 67 Error: CAP ID           F 0 P 3 C 4 = 4 F 0 P 3 C 5 = 8 
R 996 E 75 Error: CAP ID           F 0 P 3 C 3 = 11 F 0 P 3 C 4 = 37 
R 996 E 75 Error: CAP ID           F 0 P 3 C 4 = 37 F 0 P 3 C 5 = 11 
 
</pre>
<!-- Author: Marcel -->
<!-- Comment: Sat Feb  5 12;47;23 comment by...Marcel -->
swapped VRB cables, but problem stayed with Cable. 

<!-- Date: Sat Feb 5 12:50:27 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W0L3 
<li>problem n: 1032 
<li>Status: needs_access_2hr
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: We still see the CAP ID errors in Chip4. VRB has been checked, so next thing would be to swap fiber on the FIB and see, if it shows up again. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W0&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Feb 5 12:52:31 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W0L1 
<li>problem n: 1393 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Chip_bit_changes
<li>entered by: yamaoka 
<li>description is: In svxdaq we see chip error when the rdriver is set to 4, but no errors when it is set to 2.  The rdriver was set to 6 in the hdwdb and monitoring saw a bit errors, so we uped the setting to 1. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Feb 5 13:19:27 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W2L4 
<li>problem n: 672 
<li>Status: needs_observation
<li>Type: DVDD
<li>Action: Added_hdwdb
<li>entered by: yamaoka 
<li>description is: Was fine when running in sxvdaq.  Put back in hdwdb, and lets see if it runs. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W2&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Feb 5 13:24:41 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W0L0 
<li>problem n: 1019 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: Error still there 
<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: Sat Feb 5 14:43:12 2005 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 387
Calibration type  : standard
Run period tag    : Feb_2005
DPS-off run       : 193319
DPS-on run        : 193318
Requested by      : Veronique
Main process id   : 24596
Comment           : no beam, quiet time!
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->



<!-- Date: Sat Feb 5 15:34:50 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6001&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6002' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6003&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6004' ></a></center>
<!-- Author: Marcel -->
<!-- Comment: Sat Feb  5 15;37;56 comment by...Marcel -->
DVDD and AVDD for e224, that came back this morning.... They turned pink after the dmode calibration. Needs observation, who knows, if they old limits are accurate at all. However DVDD seems to be pretty high, though. AVDD on the other hand is fine.


<!-- Date: Sat Feb 5 15:52:30 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6005&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6005  width='300' align='top'></a></td><td>DVDD History for e224, so it seems to have two levels, one at 100 and one at 300. Wait and see</td></tr></table>
<!-- Author: Marcel -->

<!-- Date: Sun Feb 6 01:53:24 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W2L4 
<li>problem n: 672 
<li>Status: needs_observation
<li>Type: DVDD
<li>Action: IMON_limits
<li>entered by: yamaoka 
<li>description is: Adjusted IMON limits<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>135</td><td>135</td></tr>
<tr><td><b>Lower</b></td><td>115</td><td>115</td></tr>
<tr><td><b>Upper</b></td><td>180</td><td>305</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W2&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sun Feb 6 01:58:00 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6006&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6007  width='300' align='top'></a></td><td>SPYMON plot for store 3968</td></tr></table>
<!-- Author: Jared -->


<!-- Date: Sun Feb 6 02:00:54 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6008&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6009' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6010&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6011' ></a></center>
<!-- Author: Jared -->
<!-- Comment: Sun Feb  6 02;05;58 comment by...Jared -->
<pre>HRR brought the DVDD spike at 1:57 back down,</pre>

<!-- Date: Sun Feb 6 19:03:03 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W7L1 
<li>problem n: 1397 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: rahaman 
<li>description is: Error rate 98%  and 100% bad events coming from bit 1 low and C2 termination. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W7&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sun Feb 6 19:17:15 2005 -->
<pre>ADC distribution of SB2W7L4 has bump at about 60 ADC count which looks diff from reference dist. This is due to chip 5 ADC dist. 
Plots are added. 
</pre>
<!-- Author: rahaman -->


<!-- Date: Sun Feb 6 19:24:27 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6016&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6017  width='300' align='top'></a></td><td>ADC dist of SB2W7L4.</td></tr></table>
<!-- Author: rahaman -->


<!-- Date: Sun Feb 6 19:24:58 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6018&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6018  width='300' align='top'></a></td><td>ADC dist of chip 5</td></tr></table>
<!-- Author: rahaman -->


<!-- Date: Sun Feb 6 23:47:23 2005 -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2005&action=view&page=-2146&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2005&action=view&page=-2147 width='300' align='top'></a></td><td>Had some problems with SB1W1L0 tripping on AVDD at start of store. A few attempts to recover brought it back.</td></tr></table> 
 
  
<!-- Author: Jared -->


<!-- Date: Mon Feb 7 00:04:54 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6019&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-6020  width='300' align='top'></a></td><td>SPYMon plot for store 3969</td></tr></table>
<!-- Author: Jared -->