<!-- Title: 13:00:22  Tue Oct 22 2002 -->
<!-- Crewchief: Silifolk -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>For more on Oct 22 access, see previous file.</pre>


<!-- Date: Tue Oct 22 13:01:34 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Tue_Oct_22_2002_130125.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-859  align='top'></td><td>FECLK of IB0W4. Seems of poor quality and low swing compared to IB0W5</a></td></tr></table>
<!-- Author: Lester -->
<!-- Comment: Thu Oct 24 10;27;11 comment by...chill -->
<pre>Symptoms persist after FTM swap, suspect FF0 or bent pin.  Move to another slot next access.</pre>
<!-- Date: Tue Oct 22 13:21:20 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W4/5All 
<li>problem n: 747 
<li>Status: needs_observation
<li>Action: Swap_FTM
<li>entered by: sforrest 
<li>description is: FTM board swapped due to continued HRR and high current states.  <a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=127&frame=2&anchor=18:49:21'> see silicon e-log </a>.  FTM serial number 564035 OUT, 565902 IN. Rx's were swapped in place.  A list of Rx#/channel are (0/1033, 1/0925,2/0908,3/0886,4/0928,5/0920,6/1021,7/0923,8/1043,9/0906). <table border=1>
<tr><td><b>IN</b></td><td>PREP:</td><td>565902</td><td>Serial:</td><td>??</td></tr>
<tr><td><b>OUT</b></td><td>PREP:</td><td>564035</td><td>Serial:</td><td>105</td></tr></table> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W4/5&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Oct 22 14:06:14 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W10L3 
<li>problem n: 480 
<li>Status: needs_access_4hr
<li>Action: Diagnosis_update
<li>entered by: lmiller 
<li>description is: During access, unplugged wedge and tested powering supply.  This worked; seems to exonerate the supply. We tried  reintegrating the ladder but continued to get DVDD trips or software protection trips. It is left out. We should probe LV cables. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B3W10&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Oct 22 14:43:15 2002 -->
<pre>Access Report of Stan and Cigdem: 
================================= 
 
We swapped the RX on e280 twice and did not fix the dropping readout problem.  
After the first RX swap problem changed.  
We do know have no challens but data.  
 
e282 had a bit 2 low problem, which showed up today in the  
SVXDAQ. It had no problems until today. As we run the  
pretest, we did not even touch anything at this 
crate. 
We swapped the RX. Problem is not fixed.  
 
We swapped the RX of e264 (bit 1 low) did not fix problem. 
We swapped the RX of e273 (bit 2 low) problem fixed.  
We swapped the RX of e274 (bit2,3low) did not fix problem.  
 
 
We swapped the RX of e004 (bit 6 low) problem not fix.  
We should measure its light output next.  
We swapped the RX of 033 (bit 2 low) problem fixed.  
 
Two of our main Target RX swaps (e273, e033) were succesful and  
two of our main Target RX swaps (e280, e004) were not succesful. 
The other RX swap we did, because we had the board out and  
wanted to give them another try.   
 
No new errors were introduced.  
 
e341 (actually the whole board) did not show any problems in the 
prestest. Because of that we did not touch it.  
 
In case of e381,e384 and e392 we swapped the DOIM cable to  
figure out, if the problems are board or HDI related.  
 
We swapped DOIM cable of e381 and e382,  
e383 and e384, e392 and e393.  
 
      Before swap       After swap 
e381    chip ID 0         c2c2 
e382      ok               ok 
e383      ok             bit 2 problem 
e384   bit 7 low         bit 7 low 
e392   bit 7 low          ok  
e393     ok               ok  
 
After reswapping the DOIM cables to their original position, 
we reproduced the situation "Before swap".  
 
Problems of e381 and e384 are board related.  
For e392 we found a matching RX.  
In the next access we should swap the RX of e392 and e393  
with each other.  
 
For more details about which RX went in and out, see  
Problem Data Base.      
 
 
</pre>
<!-- Author: stan and cigdem  -->

<!-- Date: Tue Oct 22 15:34:27 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W0L2 
<li>problem n: 256 
<li>Status: needs_observation
<li>Action: Diagnosis_update
<li>entered by: chill 
<li>description is: SuperDuper FIB installed, needs observation to see if this fixes SPT and cell id problems. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=L00&wedge=B1W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Oct 22 15:48:58 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W0L4 
<li>problem n: 736 
<li>Status: fixed
<li>Action: PS_work
<li>entered by: chill 
<li>description is: Problem was in the supply, PS swapped, problem solved. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B5W0&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Oct 22 16:02:20 2002 -->
<p><b>IB5W0</b> was replaced today.  The new PS, s/n #39, was load box tested and cabled. 
<p>
<!-- Author: Napora, Mumford, Hill -->

<!-- Date: Tue Oct 22 17:14:12 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W10All 
<li>problem n: 90 
<li>Status: needs_observation
<li>Action: Removed_hdwdb
<li>entered by: evah 
<li>description is: Software protection trips, DVDD overcurrent.  Taken out of hdwdb. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W10&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Oct 22 17:16:57 2002 -->
<pre> 
Going through and clearing the pinkies in IMon.   
Note: 
IB0W4L2 Bias0 nominal was 3 and now is 0. 
IB0W4L4 Bias1 nominal was 3 and now is 0. 
</pre>
<!-- Author: Eva H. -->


<!-- Date: Tue Oct 22 17:23:29 2002 -->
<pre>Too tired to type long access report (I will do it later). It was 
basically very successful, thanks to the extra hours we were 
granted. 
 
Thanks to all who got up early and did a great job.</pre>
<!-- Author: chill -->

<!-- Date: Wed Oct 23 20:45:47 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W2L3 
<li>problem n: 231 
<li>Status: needs_access_2hr
<li>Action: Removed_hdwdb
<li>entered by: chill 
<li>description is: OC trip on bias 0 when going form off to standby.  Current limit not adjustable, could be software, but likely failure in PS. Have requested an access to investigate and/or replace PS. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Oct 23 21:11:07 2002 -->
<pre> 
Got paged for a trip: IB0W2L3 bias 0 overcurrent (happened at 
around 18:55). There was a quench at around 18:44, which appears 
to be unrelated.  I tried bringing this ladder back to standby 
but was unsuccessful.   
 
At the same time b0dap32 was down and was causing lots of problems.   
See <a href="http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2002&action=view&page=887&frame=2&anchor=18:12:39"> general elog  </a>. 
In the process of dealing with this with Chris, we exited the PS  
GUI and could not re-start it due to the b0dap32 server problems. 
Once this was fixed and started the GUI again the silicon HV 
went off since we had tried turning it off using the HV summary 
button earlier. 
 
We contacted Rob Napora about IB0W2L3 since the OC problem 
may be due to a PS failure.  We asked for an access but it was denied for now. 
 
I took IB0W2L3 out of the hdwdb, silicon is OFF, and shot setup is expected around 6am.  
</pre>
<!-- Author: Eva H. -->

<!-- Date: Thu Oct 24 09:55:13 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W2L3 
<li>problem n: 749 
<li>Status: needs_work
<li>Action: Monitoring
<li>entered by: evah 
<li>description is: DRO No first chip 99% since run 153177. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Oct 24 09:56:10 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W2L4 
<li>problem n: 731 
<li>Status: needs_work
<li>Action: Monitoring
<li>entered by: evah 
<li>description is: DRO No first chip 70% since run 153215. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W2&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Oct 24 10:00:19 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W3L4 
<li>problem n: 70 
<li>Status: needs_observation
<li>Action: Change_last_chip
<li>entered by: evah 
<li>description is: Had DVDD OC trips when going from OFF to STBY and ON. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W3&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Oct 24 10:04:25 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W3L4 
<li>problem n: 70 
<li>Status: needs_observation
<li>Action: Incident
<li>entered by: evah 
<li>description is: changed action field. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W3&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Oct 24 10:05:57 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W3L1 
<li>problem n: 750 
<li>Status: needs_observation
<li>Action: Incident
<li>entered by: evah 
<li>description is: Had AVDD OC trips when going from OFF to STBY and ON. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B5W3&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Oct 24 10:24:49 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W4All 
<li>problem n: 134 
<li>Status: needs_access_2hr
<li>Action: Removed_hdwdb
<li>entered by: chill 
<li>description is: Stuck cell ID problem persists.  During previous access we observed  poor FECLKs with cables disconected from PC.  Also terminations were measured at PC and found to be ok.  Thus, the problem is not internal.  Since we have already swapped FIB,FTM it must be either FFO or a bent pin.  Switching to another slot should address either.  
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W4&layer=All">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Thu Oct 24 10:55:24 2002 -->
<pre> 
While going through and clearing pinkies in IMon, I see that 
SB5W10L2 Bias is 0. 
</pre>
<!-- Author: Eva H. -->

<!-- Date: Thu Oct 24 12:24:38 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W7L0 
<li>problem n: 751 
<li>Status: needs_access_2hr
<li>Action: Removed_hdwdb
<li>entered by: chill 
<li>description is: Trigger inhibit caused by bias voltage suddenly dropping to OV.  Power cycling did not help.  Need acces to investigate and/or swap supply. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B5W7&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Oct 24 15:29:52 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 204
Calibration type  : standard
Run period tag    : Oct_2002
DPS-off run       : 153270
DPS-on run        : 153269
Requested by      : eusebi
Main process id   : 23676125
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Thu Oct 24 15:31:57 2002 -->
<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 204 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 153270
DPS-on run       : 153269
Requested by     : eusebi
Submitted        : 2002-10-24 13:25:55
Completed        : 2002-10-24 13:27:39
Status           : FAILURE

Last processing stage reported : checking silicon configuration
Failure diagnostics :
Run 153269 has 32 events, need at least 1000. Exiting.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Fri Oct 25 03:11:01 2002 -->
<p><b>Silicon Power Controlled Access</b> <p>Investigated <b>SB5W7L0</b> Bias. Rebooted crate and it operated normally, reporting both non-zero voltages and 
currents. <p><b>IB0W2 Bias 3.0</b> responded to changes to its max current setting via the crate front panel--I suspect the problems of last night are from the GUI. This 
channel does trip Ovc, however, when turned on. Removed the cables and turned the supply on and it worked normally, i.e. the problem appears to be downstream of the PS. 
I tried changing it's bias current sensitivity to the coarse setting, but it still trips Ovc. <p>By request I unplugged the remote sense cable from <b>IB2W2</b> and put in 
the jumper over-riding the cable enable. 
<!-- Author: Napora -->


<!-- Date: Fri Oct 25 07:27:29 2002 -->
<pre>Access Report (Julia, David, Rob,Cigdem) 
======================================== 
 
Julia and David moved the FIB and the FTM of IB0W4/5 from  
Slot 10 to 8.  
 
We could not turn the Wedge to Standby after we moved it to  
Slot 8, because SVXDAQ configuration files, which needed to be changed weren't changed.  
We paged Steve, Andy, Evah, Chris, because we did  not know  
what was causing the problem.  
The PS Gui was complaining, that the FIB was not responding.  
We rebooted the FIB couple of times did not help. We had Bus Error...etc.  
 
Rob worked on the PS of SB5W7L0 and it on and working. See  
his entry above.  
PS of IB0W2L3 is not working. 
He also unpluged the sense cable of IB2W2. 
 
Meanwhile as I was trying to figure out what is wrong with 
IB0W4, 45-55% of the Silicon Detector started to trip on  
DVDD OC and Software Trips.  
I just finished to test IB0W0_All, ~3:30am (because it was touched by Julia and David, during the FIB,FTM movement)  
and exit svxdaq as the trips started.  
 
The rest of the night we spend to understand this problem.  
Steve came in, checked the clocks....were ok.  
We rebooted SRC and exited PS-GUI.  
As Gino and Lester arrived, we were able to turn on  
the Silicon Detector to Standby.  
We did a coldstart, took some data in RC. Asked the shift crew  
to take some calibration data.  
 
So it is not clear what caused the problem to disappear.  
 
</pre>
<!-- Author: cigdem  -->
<!-- Comment: Fri Oct 25 07;28;33 comment by...cigdem  -->
<pre>IB0W4/5 are up and working and we could take data with them RC. 

</pre>

<!-- Comment: Fri Oct 25 10;49;12 comment by...SCN -->
Some details<ul>
<li> After fib move, the hdwdb was updated but svxdaq was not.  In terms of fib maps, that means if you run svxdaq on this crate it can wipe out the knowledge of the fib move on the crate, making it think it was still in the old slot.  This would explain the handshake failure and the BUS Errors.  I realized this only a bit after Cigdem paged the first time (2 AM ?) and fixed the
file in svxdaq.
<li> Ahh, but then the second page regarding High current at
about 4 AM.  I had forgot to change the links file which says
which vrb is connected to which fib.  This has the effect of
(upon setDefaults) making svxdaq think none of the fib channels
on are connected to a Vrb, which means <i>all vrbs get turned off, so there is nothing to throttle the SRC trigger decisions</i>.  The result is that the SRC sends L1A and L2(r/a) as fast as it can.  In this case, one of two things may happen depending on the number of Readout BE Clocks <ol> <li> After each run (on End) the number of BE clocks is set to something very small, like 32, so readout is stopped after ~ 160 ns and the
Fib Command Fifo does not fill up.  In this case the ladders should not see too much DVDD as we know from Jumper studies with<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=barrel4&action=view&page=54&frame=2&anchor=15:16:43'>
short readout</a> (in that case, lots of L2R, but the effect is the same).
<li> However, at every reboot, the number of BE clocks is set to
4300, so those crates which had been rebooted would probably have
overflowed the command fifos.  However, when I came in and looked, nobody had overflowed fifos, so I cannot say for sure that this happened.
</ol>
In either case <ul>
<li> The RC Cold Start I had Cigdem issue should clear up the problems, but didn't.  It would be wise for someone to look at the currents for SB0W0 all over a period from 4 AM to 11:59 AM.  I saw some pretty high DVDD, and still it is a mystery how
it went away.
<li> It is bad to run the SRC with no throttling-to prevent this
in the future I added a dialog box requiring User Confirmation to
allow this to proceed. (It is something one might want to do to
test without Silicon on).
</ul>
</ul>
I think we owe last night's access crew a beer or something...
<!-- Date: Fri Oct 25 07:37:52 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 205
Calibration type  : standard
Run period tag    : Oct_2002
DPS-off run       : 153310
DPS-on run        : 153308
Requested by      : Jian
Main process id   : 26232988
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Fri Oct 25 07:37:52 2002 -->
<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 205 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 153310
DPS-on run       : 153308
Requested by     : Jian
Submitted        : 2002-10-25 05:32:39
Completed        : 2002-10-25 05:34:14
Status           : FAILURE

Last processing stage reported : checking silicon configuration
Failure diagnostics :
Beam info for run 153310 is not in the database. Exiting.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->


<!-- Date: Fri Oct 25 08:25:35 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 206
Calibration type  : standard
Run period tag    : Oct_2002
DPS-off run       : 153310
DPS-on run        : 153308
Requested by      : Jason Nielsen
Main process id   : 26415423
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Fri Oct 25 09:46:52 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W9L0 
<li>problem n: 755 
<li>Status: needs_observation
<li>Action: Monitoring
<li>entered by: evah 
<li>description is: No ADC distribution in ADCMon since ~ run 153050. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W9&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Oct 25 10:01:07 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W8L4 
<li>problem n: 737 
<li>Status: needs_observation
<li>Action: Monitoring
<li>entered by: evah 
<li>description is: No ADC distribution in ADCMon since ~ run 152459. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B3W8&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Oct 25 11:13:14 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W2L2 
<li>problem n: 754 
<li>Status: needs_observation
<li>Action: Diagnosis_update
<li>entered by: chill 
<li>description is: IV scan peformed with R~10kOhm, possible pinhole.  Draws 3250 uA at 30V, nominal depletion voltage.  Changed limit to 4000 uA and re-integrated. Check for physics. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W2&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Oct 25 11:16:05 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W2L3 
<li>problem n: 231 
<li>Status: needs_access_2hr
<li>Action: Diagnosis_update
<li>entered by: chill 
<li>description is: Can't even turn to standby with current limit of 5mA.  Probable HV short to gnd, in cable or detector.  Probe resistance on access.  
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Oct 25 11:57:35 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W2All 
<li>problem n: 753 
<li>Status: needs_access_2hr
<li>Action: Diagnosis_update
<li>entered by: chill 
<li>description is: Without sense cable, ladders do not initialize, presmably due to  voltage drop on DVDD.  Need to adjust supplies up or plug back in sense cable and come up with another plan. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B2W2&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Oct 25 13:24:05 2002 -->
<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 206 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 153310
DPS-on run       : 153308
Requested by     : Jason Nielsen
Submitted        : 2002-10-25 06:20:11
Completed        : 2002-10-25 11:20:13
Status           : FAILURE

Last processing stage reported : comparing to the reference calibration
Failure diagnostics :
The calibration failed the following reference comparison criteria:

             Cut Name    Sensor Set   Cut Value   Data Value
---------------------    ----------   ---------   ----------
dps_off_noise rel max    SVX_PHI      0.025       0.035108  
dps_off_noise rel max    SVX_Z        0.025       0.042182  
 bad_fraction abs max    SVX_PHI      0.02        0.025657  

Reference calibration runs are 150096 (DPS off) and 150097 (DPS on)
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->


<!-- Date: Fri Oct 25 18:18:23 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W9All 
<li>problem n: 682 
<li>Status: needs_observation
<li>Action: Monitoring
<li>entered by: evah 
<li>description is: SVMon showing DRO, 00f3 during run 153327.   HRR's are requested quite often. IMon shows currents (esp. DVDD) going up and down,  coinciding with the HRR's. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W9&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat Oct 26 14:06:26 2002 -->
<pre>SVXMon has been issuing many HRR's this weekend, causing a few % deadtime (it is happening on the order of every 5 minutes or so, or about 10 per hour).  I have been trying to break this down ladder by ladder.  I went through some of the runs from today with one of the ACE's (Martin H.).  Take a look in the general  
&lt;a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=895&frame=2&anchor=13:05:52'&gt; elog&lt;/a&gt;.  
&lt;br&gt; 
We can compare this to a run from last night. 
&lt;pre&gt; 
Run 153327: 104 HRR's from SVXMon, Runtime 13:38  
Silicon/S/B2/W9/L0/C0-1: 47 
Silicon/S/B2/W9/L1/C0-2: 37 
Silicon/S/B2/W9/L2/C0-4: 2 
Silicon/S/B2/W9/L3/C0-5: 6 
Silicon/S/B0/W2/L3/C0-5: 1 
Silicon/S/B5/W9/L3/C6-9: 6 
Silicon/I/B2/W1/L0/C0-3: 5 
Silicon/I/B0/W4/L1/C4-7: 1 
&lt;/pre&gt; 
 
So, last night two ladders in SB2W9 (L0, L1) were causing most of 
the HRR's, and today it's SB0W4L0.</pre>
<!-- Author: Eva H. -->
<!-- Comment: Sat Oct 26 17;35;17 comment by...Eva -->
<a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=895&frame=2&anchor=13:05:52'> oops</a>
<!-- Date: Sat Oct 26 15:56:48 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W2L3 
<li>problem n: 606 
<li>Status: needs_access
<li>Action: Incident
<li>entered by: evah 
<li>description is: Bias1 current is reading 0 after store was lost  (RF station was lost but Tev did not quench).   Before store was lost it was reading around 7uA.  
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=L00&wedge=B0W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Oct 26 16:08:32 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W2L3 
<li>problem n: 606 
<li>Status: fixed
<li>Action: Diagnosis
<li>entered by: evah 
<li>description is: After cycling this ladder (stby->on->stby) reading non-zero value again. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=L00&wedge=B0W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat Oct 26 16:15:53 2002 -->
Tev lost the beam after having lost an RF station.  No silicon trips. I started the post-quench procedure (although later I learned it was not a quench).  Silicon passed cold start.  Currents looked ok except for LB0W2L3 bias1 (historically had crowbar problems).  <br> 
<br> 
Then Gino strolled in and suggested I cycle the power on that ladder.  Now the current on that guy is reading non-zero like before. 
<br>  
<!-- Author: Eva -->


<!-- Date: Sat Oct 26 17:22:25 2002 -->
There are at least 3 events (of the 6) in the error 
stream for run 153327 that would be worth looking at.   
These are events that L2 traps when SVT does not 
send an EE word for a L1A.   The SVT group says that these 
are due to no data coming to them from silicon.   Perhaps 
the first of these three events will give you an idea why the silicon gets into this state where it stops sending anything to the SVT.   Look for the 3 events taken on Oct 26, 01:09 
in run 153327.   If you need help recovering events from 
the error stream, Matt Worcester, among others, can tell you how to do it.
<!-- Author: Saltzberg -->



<!-- Date: Sat Oct 26 22:45:47 2002 -->
High losses cause most of L00 and half of SVX to trip on vbias OC.  This was due to an "operator error".  See general <a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=896&frame=2&anchor=19:49:14'> elog</a>.  Note that the parts of SVX that tripped were mainly wedges 0, 1, 9, 10, 11. 
<br> <br> 
Started post-quench type checking.  Brought the system back to standby.  I had some trouble with LB1W4L3, LB1W5L3 vbias1 IntTrip.  Resetting trips before bringing these guys to standby worked. <br> <br> 
L00 crowbars are ok, except for possibly L0W2L3 bias1 and L0W3L1. 
They are reading 0 current right now. 
<br> <br> 
Rest of currents look ok in IMon.  
<!-- Author: Eva H. -->


<!-- Date: Sat Oct 26 23:13:31 2002 -->
Does anyone know why <a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=896&frame=2&anchor=22:59:09'> this </a> keeps happening? 
<br>
<!-- Author: Eva H. -->
<!-- Comment: Wed Oct 30 15;45;38 comment by...Under-the-Rug-Sweeper -->
No, but Bill Badgett has now disabled this check in RC.
<!-- Date: Mon Oct 28 13:37:57 2002 -->
Silicon ON for store 1918.  b0svx01 failed cold-start; aces issued a reset_crate, then stepped b0svx01 through partition and config.  I wonder if this would screw up the event builder, 
because then they had to do an EVB cleanup and start from scratch.
<!-- Author: Andy H. -->
<!-- Comment: Tue Oct 29 22;33;49 comment by...SCN -->
You betcha baby!  Anytime a vrb crate (b0svxXX) gets reset, you'll screw up the EVB.
<!-- Date: Mon Oct 28 16:46:37 2002 -->
IMON good-range high-end increased from 165 to 175 mA for SB0W4L2 DVDD.
<!-- Author: Andy H. -->

<!-- Date: Mon Oct 28 16:55:35 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W4All 
<li>problem n: 134 
<li>Status: needs_work
<li>Action: Monitoring
<li>entered by: hocker 
<li>description is: Intermittently gets stuck cell IDs and issues 'continuous' HRRs. Run <a href='http://www-cdfonline.fnal.gov/daq/runSummary/errorlog/errorfile153412.log'> 153412</a> is an example 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W4&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Oct 28 16:57:41 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W4L2 
<li>problem n: 756 
<li>Status: needs_observation
<li>Action: Monitoring
<li>entered by: evah 
<li>description is: Since run 153345 00f3 after chip 85, 20-40%.   Also, bit reporter shows 'stuck ladder', 30-90%. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W4&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Oct 28 18:38:37 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W4All 
<li>problem n: 757 
<li>Status: needs_observation
<li>Action: Monitoring
<li>entered by: evah 
<li>description is: This whole wedge is having lots of bit errors since run 153344.   The highest rate error in the bit reporter shows  up as 'stuck ladder'. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W4&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Oct 28 19:17:10 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W4All 
<li>problem n: 758 
<li>Status: needs_work
<li>Action: Removed_hdwdb
<li>entered by: hocker 
<li>description is: 5V DOIM o/c trip.  Cannot turn PC back on. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B5W4&layer=All">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Mon Oct 28 19;30;59 comment by...Andy H. -->
<pre>These are the last few readings from the 5VDOIM:

1384  0 -32765     5.42  1635.00 
1384  0 -32765     5.42  1630.00 
1384  0 -32765     5.42  1615.00 
1384  0 -32765     5.42  1620.00 
1384  0 -32765     5.42  1615.00 
1384  1   4099     1.14     0.00 
1384  1   4099     0.02     0.00 
1384  1   4099     0.07     0.00 

The overcurrent was too fast to catch with the 7 second update...</pre>

<!-- Comment: Mon Oct 28 19;44;54 comment by...Andy H. -->
<pre>Nothing was going on with the beam or DAQ when this happened.
The trip happened roughly 10 s after the run was activated.
</pre>


<!-- Date: Tue Oct 29 09:05:35 2002 -->
<p> 
<b>Last night's trip roundup:</b> 
<ul> 
  <li>IB0W4L0 SPT at 00:25:55-- then trip on L3 DVDD O/C as wedge was turning off. 
  <li>LB0W0PC 5VDOIM ext-trip while turning IB0W4 back on 
  <li>SB3W4L2 DVDD O/C while resetting SPT 
  <li>SB2W3 ext-trip during global ON->STBY transition at 07:37:14 -- then DVDD O/C trips on L0-2 (but reported in GUI as L3 three times -- must be a bug) 
  <li>SB4W9L4 AVDD O/C also during ON->STBY transition 
</ul> 
<p> 
All trips were recoverable.</p>
<!-- Author: Andy H. -->


<!-- Date: Tue Oct 29 09:14:34 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Tue_Oct_29_2002_091409.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-861  align='top'></td><td>SB4W9L4 AVDD current history to show that the trip wasn't due to a jumper failure</a></td></tr></table>
<!-- Author: Andy H. -->
<!-- Comment: Tue Oct 29 11;37;12 comment by...Gino -->
<pre>The Jumper failed on this ladder a long long time ago. 
If we start being able to break it twice we will have to review most of our basic understanding.</pre>

<!-- Comment: Tue Oct 29 16;24;01 comment by...Mr. Should&#39;ve-checked-the-PDB -->
Good point.
<!-- Date: Tue Oct 29 13:29:57 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W4L4 
<li>problem n: 759 
<li>Status: needs_work
<li>Action: Monitoring
<li>entered by: evah 
<li>description is: No Data on Z side. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W4&layer=L4">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Tue Oct 29 14;40;32 comment by...Eva H. -->
Not jumper failure.  IAVDD is flat.
<!-- Date: Tue Oct 29 14:39:46 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W1L3 
<li>problem n: 760 
<li>Status: needs_access_2hr
<li>Action: Incident
<li>entered by: chill 
<li>description is: Andy was alerted via IMon that no current was being drawn on bias1.  No physics seen in SVXMon.  Need to replace crowbar fuse on next access, use 10mA kind (orange jacket). 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=L00&wedge=B1W1&layer=L3">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Tue Oct 29 15:53:56 2002 -->
<pre>Threshold changed globally from 7,8 to 9 in SVX,ISL,L00 (of course should not matter for L00). 
 
First run with new thresholds will be 153448.</pre>
<!-- Author: chill -->



<!-- Date: Tue Oct 29 19:41:41 2002 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Rdriver settings for ALL of SVX changed to 4 except the following 
which Jason & I identified as needing higher values. 
 
These needed RD=7: 
 
SB3W10L2C0-4 
SB3W10L2C5-9 
SB2W9L0C0-1 
SB5W3L1C0-2 
SB5W5L0C0-1 
SB5W6L1C0-2 
SB4W9L2C5-9 
SB1W2L0C0-1 
SB1W2L2C0-4 
SB0W2L2C0-4 
SB0W3L4C0-6 
SB0W4L4C0-6 
SB0W7L4C0-6 
 
These needed RD = 6: 
 
SB3W10L1C3-5 
SB3W10L1C0-2 
SB5W0L2C0-4 
SB4W9L2C0-4 
SB1W0L2C5-9 
SB1W2L3C0-5 
SB1W2L3C6-9 
SB0W11L3C6-9 
SB0W8L2C0-4 
SB0W8L2C5-9 
 
These needed RD = 5: 
 
SB3W4L3C0-5 
SB3W4L3C6-9 
SB2W11L0C2-3 
SB4W9L3C6-9 
SB1W3L3C6-9 
SB1W3L4C0-6 
SB0W10L3C0-5 
SB0W10L3C6-9 
 
To back out these changes there are two options: 
 
1) Chip editor allows you to read a configuration.  I wrote the old configuration to ~svxii/default_rd, you can just read it. 
2) You can just set SVX globally back to 7. 
 
Please page me before doing either of the above. 
 
This setting only had the granularity of the phi/z half of a 
ladder, and in principle needs to be repeated with chip 
granularity. 
 
These changes will take effect run 153448.</pre></td></tr></td></table>
<!-- Author: chill -->
<!-- Comment: Tue Oct 29 20;26;38 comment by...Jason -->
Please save current configuration as a reference (with the changed RD settings).
<!-- Comment: Wed Oct 30 09;37;20 comment by...chill -->
<pre>Already done, in directory called new_rd in ~svxii</pre>
<!-- Date: Tue Oct 29 20:20:21 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Tue_Oct_29_2002_202012.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-864  align='top'></td><td>Interesting behavior of AVDD current for SB1W2L2, which is an AVDD2 suspect.  IMON pinked on the jump up.</a></td></tr></table>
<!-- Author: Andy H. -->




<!-- Date: Wed Oct 30 10:51:36 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W4L1 
<li>problem n: 761 
<li>Status: needs_observation
<li>Action: Incident
<li>entered by: chill 
<li>description is: SVXMon alarmed that it was receiving no data from 15 of 16 chips.  There was no discernible problems (no IMon alarms)in the currents (AVDD,DVDD,DOIM). This was somewhat alarming as this ladders is in the wedge that continues to have stuck cells.  Nevertheless, by the time the investigation was finished, the ladder was producing data again and SVXMon was happy. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W4&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Oct 30 15:30:58 2002 -->
<p>Attempted to fix SB5W4 5VDOIM O/C trip by using our new CAEN crate reset buttons.  Turned off SB3W[5-7], SB4W[4-6], and SB5W[4-6], then pressed the "SVX SE BOT 4" reset button (this is 
one we tested on the last access and its mislabeling has been fixed since then, so I knew it was the right one). 
Unfortunately, it didn't fix the trip.</p> 
<p> 
For the record, this is what svxinter spits out when a crate is 
reset (I don't expect anyone besides Andrew to be able to decipher it): 
<pre> 
->  Caenet_write: Error number -1 ffffffff received 
group_info:cr_n = 14, response = -1 
 Caenet_write: Error number -2 fffffffe received 
group_info:cr_n = 14, response = -2 
WARNING: found a power supply in the crate, which is not connected to a  
wedge in the detector, or absent in CAEN.map,  cr_n = 14, bd_n = 9 
 Caenet_write: Error number -253 received 
 
cr = 14, bd = 9,Errcode 10 
 
</pre> 
</p> 
<p> 
The remaining wedges could be turned back to STBY without any problem.</p>
<!-- Author: Andy H. -->

<!-- Date: Wed Oct 30 15:37:41 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L4 
<li>problem n: 73 
<li>Status: needs_observation
<li>Action: Diagnosis_update
<li>entered by: chill 
<li>description is: A6 changed to DPS off, threshold to 255. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Oct 30 15:39:45 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W9L3 
<li>problem n: 601 
<li>Status: needs_observation
<li>Action: Sparse_out_chip
<li>entered by: chill 
<li>description is: Chip a3 set to DPS off, threshold to 255. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B5W9&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Oct 30 16:09:48 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L1 
<li>problem n: 762 
<li>Status: needs_observation
<li>Action: Incident
<li>entered by: chill 
<li>description is: 00f3 since 152944, rate = 2%, chip b3 changed to DPS off. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B4W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Oct 30 16:41:36 2002 -->
<H1>00f3 work:</H1> 
<P> 
Looking at what we would lose if we sparse away chips that have 
00f3 problems, I observed the following by looking at 452 which 
has DPS set to off now so the underlying data that causes the 00f3 can be seen: 
<OL> 
<LI>00f3 events are caused by large upwards pedestal fluctuations as you would expect since this is why the ADC never reaches counter modulo.  An example of such an event is pasted in the e-log below.</LI> 
<LI>Non 00f3 events for this chip are fine, and see physics.  An example of such an event is pasted in the e-log below.</LI> 
</OL> 
Thus, I conclude that if the 00f3 rate is low, it is <B>not</B> a good idea to sparse out these chips, because you will be throwing 
away physics.  We need a better solution. 
<P> 
For now, I leave ISL 00f3 chips in DPS off but do not sparse them becuase I don't believe the occupancy is dangerous for ISL. 
<P> 
For SVX 00f3 chips (there are only two), I have turned them DPS off but have set their threshold to 255, sparsing them away.  This is because they both have high 00f3 rates and the occupancy is dangerous for SVXII.
<!-- Author: chill -->


<!-- Date: Wed Oct 30 16:42:46 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Wed_Oct_30_2002_164228.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-866  align='top'></td><td>Bad event (would cause 00f3) in f452.</a></td></tr></table>
<!-- Author: chill -->


<!-- Date: Wed Oct 30 16:43:16 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Wed_Oct_30_2002_164312.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-868  align='top'></td><td>Good event (no 00f3) for f452</a></td></tr></table>
<!-- Author: chill -->


<!-- Date: Wed Oct 30 20:26:55 2002 -->
<H2>More resistor driver scans</H2> 
I took some more read-all runs in the D-mode calibration framework, changing resistor driver settings before each run.<BR> 
<TABLE> 
<TR><TH>Run number</TH><TH>Chip setting</TH><TH>GUI setting</TH></TR> 
<TR><TD>153514</TD><TD>4</TD><TD>1</TD></TR> 
<TR><TD>153516</TD><TD>3</TD><TD>6</TD></TR> 
<TR><TD>153517</TD><TD>2</TD><TD>2</TD></TR> 
<TR><TD>153518</TD><TD>1</TD><TD>4</TD></TR> 
<TR><TD>153520</TD><TD>0</TD><TD>0</TD></TR> 
</TABLE> 
<BR> 
Now I am putting back the resistor drivers to their original settings -- the read-back of the configuration seemed to have worked.  (I will double-check Chris's work now.)  
<!-- Author: Jason -->
<!-- Comment: Thu Oct 31 00;10;50 comment by...Jason -->
I checked all of the chips, and they are OK according to Chris's entry.  I guess that the chipEditor chip number is reversed with respect to the offline numbering he wrote in his table.
<!-- Comment: Fri Nov  1 07;41;18 comment by...SCN -->
<pre>Chips go "backwards" relative to readout order in the
Chip Editor and also in teststand code (since it is really the same thing).  That means Chip 0 is the last chip on the Z side and Chip &lt;i&gt;(n-1)&lt;/i&gt; is the first chip on the phi side for 
a ladder with &lt;i&gt;n&lt;/i&gt; chips.  You can always check the Chip IDs
to understand where you are.</pre>
<!-- Comment: Fri Nov  1 07;42;08 comment by...the htmlizer -->
Chips go "backwards" relative to readout order in the
Chip Editor and also in teststand code (since it is really the same thing).  That means Chip 0 is the last chip on the Z side and Chip <i>(n-1)</i> is the first chip on the phi side for 
a ladder with <i>n</i> chips.  You can always check the Chip IDs
to understand where you are.
<!-- Date: Wed Oct 30 20:49:49 2002 -->
<p><b>Si Power Controlled Access</b> 
<p><b>SB5W4</b>: We removed the remote sense cable and the 2/5V DOIMs were able to turn on without tripping.  We swapped the cables onto the PS in slot 3 and had the same problem--the 5V DOIM tripped Ovc.  We removed the remote sense again and were able to turn on ok.  <b>The problem is in the remote sense line downstream of the power supply.</b>  We left the remote sense cable disconnected under the unlikely hope this would recover part of the wedge. 
<p><b>LB1W1</b>: Replaced its bad crowbar with a 10mA fused version.  Lester turned it on upstairs and all channels drew current. 
<p><b>IB2W2</b>: Plugged in the remote sense cable and removed the cable enable jumper. 
<p><b>IB0W2</b>: Visually inspected the bias cables for this supply.  They were connected properly and appear normal. 
<p>
<!-- Author: Napora and Herndon -->
<!-- Comment: Thu Oct 31 07;30;11 comment by...Andy H. -->
Re: SB5W4 -- PC turns on now but, like IB2W2, the ladders can't
initialize without the remote sense cable (tried L0 and L4).
 
<!-- Date: Wed Oct 30 21:39:46 2002 -->
We are done with controlled access.  MCR informed.
<!-- Author: Saltzberg -->
<!-- Comment: Wed Oct 30 21;46;24 comment by...DS -->
<pre>Oops, thought this was the main e-log.</pre>

<!-- Date: Wed Oct 30 21:49:31 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 207
Calibration type  : standard
Run period tag    : Oct_2002
DPS-off run       : 153532
DPS-on run        : 153531
Requested by      : JJ/Jason
Main process id   : 37446852
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->



<!-- Date: Thu Oct 31 03:22:17 2002 -->
<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 207 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 153532
DPS-on run       : 153531
Requested by     : JJ/Jason
Submitted        : 2002-10-30 19:48:30
Completed        : 2002-10-31 01:21:04
Status           : FAILURE

Last processing stage reported : comparing to the reference calibration
Failure diagnostics :
The calibration failed the following reference comparison criteria:

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

Reference calibration runs are 150096 (DPS off) and 150097 (DPS on)
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Thu Oct 31 03:44:02 2002 -->
<pre>Output of "dumpLVCurrent()" on svxinter (checks LV current 
limits in PS against limits in HDWDB): 
 
SVX power supply 16 layer 0 DVDD max current set at  250.00, read  500.00 
SVX power supply 16 layer 1 AVDD max current set at  650.00, read  900.00 
SVX power supply 16 layer 1 DVDD max current set at  250.00, read  900.00 
SVX power supply 16 layer 2 AVDD max current set at 1200.00, read 1500.00 
SVX power supply 16 layer 2 DVDD max current set at  375.00, read 1500.00 
SVX power supply 16 layer 3 AVDD max current set at 1200.00, read 1500.00 
SVX power supply 16 layer 3 DVDD max current set at  375.00, read 1500.00 
SVX power supply 16 layer 4 AVDD max current set at 1400.00, read 2100.00 
SVX power supply 16 layer 4 DVDD max current set at  450.00, read 2000.00 
value = 0 = 0x0 
 
What the hell does "SVX power supply 16" mean?  I don't know.  I 
will ask Yimei to specify the PS in a more meaningful way.  In 
the meantime, clicked "Load AVDD/DVDD limits" in the GUI, which 
does 'em all. 
</pre>
<!-- Author: Andy H. -->
<!-- Comment: Thu Oct 31 04;05;40 comment by...Andy H. -->
OK, well now I've convinced myself that the power supplies are
numbered 0-71, starting from B0W0.


<!-- Date: Thu Oct 31 07:00:53 2002 -->
<p> 
<b>First physics run with new thresholds/resistor drivers</b> 
</p> 
<p> 
No pinkies in IMon, nothing looks different in SVXMon.  Is the 
fact that the current store has a pitiful lumi (7E30) the reason 
why I can't tell a difference? 
</p>
<!-- Author: Andy H. -->



<!-- Date: Thu Oct 31 11:14:50 2002 -->
<pre>We just had two ladders trip in L00.  They were L00 West W0 with VBIAS13 OverCurrent and L00 East WO with VBIAS13 UnderVoltage.  We paged silicon - Andy responded - we reset them with the usual steps.  Andy may have been in the middle of something, he asked me to post here.  There was a little activity in the Tevatron, but nothing too unusual (silicon was at standby - we're between stores).</pre>
<!-- Author: Adam Gibson -->


<!-- Date: Thu Oct 31 11:37:31 2002 -->
<pre>Entry from on-shift monitoring ACE: 
 
Spikes in Tevatron loss at ~80kHz tripped the following in L00: 
West W0 VBIAS13 Overcurrent(4 instances), West W1 VBIAS4 Overcurrent(1 instance), East W0 VBIAS13 Undervoltage(4 instances), East W1 VBIAS13 Overcurrent (4 instances). 
 
spikes are now gone...paged Silicon. 
Andy Hocker advised to turn off entire L00 HV.  HV on L00 turned off as per Andy's request. 
 
</pre>
<!-- Author: Stan Lai, Adam Gibson -->
<!-- Comment: Thu Oct 31 21;20;29 comment by...Andy H. -->
L00 returned to STBY (and then to ON) when the next store began.
<!-- Date: Thu Oct 31 18:27:15 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W1L1 
<li>problem n: 763 
<li>Status: needs_work
<li>Action: Monitoring
<li>entered by: evah 
<li>description is: SVXMon shows 'No Data' on all chips. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B2W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Thu Oct 31 21;21;45 comment by...Andy H. -->
Could this be the result of the threshold raise?
<!-- Date: Thu Oct 31 18:28:59 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W8L2 
<li>problem n: 502 
<li>Status: needs_work
<li>Action: Monitoring
<li>entered by: evah 
<li>description is: SVXMon shows 'No Data' on z side. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B3W8&layer=L2">report</a></ul>
<!-- Author: Problem DB -->





<!-- Date: Thu Oct 31 23:29:01 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Thu_Oct_31_2002_232848.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-870  align='top'></td><td>AVDD currents for e122</a></td></tr></table>
<!-- Author: Jason -->

<!-- Date: Thu Oct 31 23:33:18 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W1L2 
<li>problem n: 516 
<li>Status: needs_access
<li>Action: Diagnosis_update
<li>entered by: nielsenj 
<li>description is: Changed IMON current limits because of   <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=128&frame=2&anchor=23:29:01'> these AVDD current swings</a>   
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->





<!-- Date: Sat Nov 2 07:45:02 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-871&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-871  width='300' align='top'></td><td>C:B0PAGC for the last week.  Comments to follow.</a></td></tr></table>
<!-- Author: Andy H. -->


<!-- Date: Sat Nov 2 08:05:46 2002 -->
<h3>Wussed out of store 1933</h3> 
<p> 
TeVMon was complaining about spikes in C:B0PAGC, prompting the 
shift crew to page me around 3:30 am.  Two things worried me: 
one, C:B0PAGC was much higher than normal (see above plot), and 
it and lots of other loss parameters were quite spikey.  I decided two worries were enough for me to get us out.  Now that 
my head is clearer and I've been able to examine data from this 
week a more carefully, it appears that this store really wasn't 
that dissimilar from the previous two, which weren't really problematic.  I think this was a bad call on my part.</p>
<!-- Author: Andy H. -->

<!-- Date: Sat Nov 2 19:44:02 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W3L4 
<li>problem n: 70 
<li>Status: needs_observation
<li>Action: Incident
<li>entered by: hocker 
<li>description is: AVDD O/C trip.  See <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2002&action=view&page=917&frame=2&anchor=17:42:36'> current history plot</a> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W3&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Nov 4 07:20:54 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W3L4 
<li>problem n: 70 
<li>Status: needs_observation
<li>Action: Currents_investigated
<li>entered by: bolla 
<li>description is: <pre>Changed the steady state AVDD tripping limit from 1400 mA to 1500 mA.
This is a direct consequence of the symptoms associated with the
jumper failure. It should be done to them all.</pre> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W3&layer=L4">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Mon Nov  4 07;27;50 comment by...Gino -->
<pre>The change did NOT take place yet.
I just changed the file CAENLVcurrent.dat.

When there will be time (in between stores or at the next trip) we should load the new file into the system.
It is my understanding that we have to:
1. Exit the GUI
2. Re-start the GUI (this load into the GUI the new file)
3. click on the GUI the "Set DVDD/AVDD currents" button.

</pre>
<!-- Date: Mon Nov 4 07:23:29 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-872&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-872  width='300' align='top'></td><td>.</a></td></tr></table>
<!-- Author: Gino -->
<!-- Comment: Mon Nov  4 07;24;35 comment by...Gino -->
<pre>This plot is for the previous entry. We run normally very very close to the tripping limit so I raised it by 100 mA.</pre>



<!-- Date: Mon Nov 4 12:58:38 2002 -->
<center><a href='/elog/notebooks/silicon/Mon_Nov__4_2002_125728.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-874' ></a><a href='/elog/notebooks/silicon/Mon_Nov__4_2002_125741.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-876' ></a><a href='/elog/notebooks/silicon/Mon_Nov__4_2002_125748.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-878' ></a><a href='/elog/notebooks/silicon/Mon_Nov__4_2002_125758.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-880' ></a><a href='/elog/notebooks/silicon/Mon_Nov__4_2002_125808.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-882' ></a></center>
<!-- Author: Andy H. -->
<!-- Comment: Mon Nov  4 13;02;32 comment by...Andy H. -->
These are the AVDD currents for the 12 jumper-failure ladders, layer-by-layer.  The data are from 03-NOV-2002.  Color legend for
the L0's is: black=SB3W8, red=SB5W5, blue=SB5W7, green=SB2W9.  Color legend for the L4's is: black=SB4W9, red=SB4W10, blue=SB0W7, green=SB0W4, cyan=SB1W3.
<!-- Comment: Mon Nov  4 13;07;23 comment by...Andy H. -->
Eyeballing the above plots,
<p>
<table BORDER COLS=4 WIDTH="100%" NOSAVE >
<tr>
<td>Ladder</td>

<td>Min (mA)</td>

<td>Nominal (mA)</td>

<td>Max (mA)</td>
</tr>

<tr>
<td>SB3W8L0</td>

<td>325</td>

<td>375</td>

<td>450</td>
</tr>

<tr>
<td>SB5W5L0</td>

<td>325</td>

<td>375</td>

<td>425</td>
</tr>

<tr>
<td>SB5W7L0</td>

<td>375</td>

<td>450</td>

<td>500</td>
</tr>

<tr>
<td>SB2W9L0</td>

<td>325</td>

<td>375</td>

<td>500</td>
</tr>

<tr>
<td>SB5W3L1</td>

<td>525</td>

<td>625</td>

<td>675</td>
</tr>

<tr>
<td>SB0W2L2</td>

<td>825</td>

<td>925</td>

<td>975</td>
</tr>

<tr>
<td>SB0W3L3</td>

<td>900</td>

<td>975</td>

<td>1025</td>
</tr>

<tr>
<td>SB4W9L4</td>

<td>1300</td>

<td>1425</td>

<td>1500</td>
</tr>

<tr>
<td>SB4W10L4</td>

<td>1125</td>

<td>1250</td>

<td>1300</td>
</tr>

<tr>
<td>SB0W7L4</td>

<td>1100</td>

<td>1200</td>

<td>1300</td>
</tr>

<tr>
<td>SB0W4L4</td>

<td>1075</td>

<td>1200</td>

<td>1300</td>
</tr>

<tr>
<td>SB1W3L4</td>

<td>1275</td>

<td>1375</td>

<td>1450</td>
</tr>
</table>
</p>
<p>
A trip limit of (nominal + 125 mA) should keep these guys from
unnecessarily tripping.  I will set these limits after the current store.  Should also double-check IMON limits and see
that they're sensible.</p>
<!-- Comment: Tue Nov  5 20;14;08 comment by...Andy H. -->
Actually all the limits in CAENLVcurrent.dat were already >= nominal + 125, except for SB5W3L1 and SB5W7L0.  I want to leave
SB5W3L1 alone for now for <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=129&frame=2&anchor=20:09:03'>
this reason,</a>  so the only one I changed was SB5W7L0 (500 mA -> 575 mA).

<!-- Date: Mon Nov 4 13:00:26 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W11L2 
<li>problem n: 765 
<li>Status: needs_observation
<li>Action: Monitoring
<li>entered by: evah 
<li>description is: Various chip/bit errors since run 153531. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W11&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Nov 4 13:06:42 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W5L2 
<li>problem n: 63 
<li>Status: needs_observation
<li>Action: Monitoring
<li>entered by: evah 
<li>description is: Came back around run 153458, ~25%. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Nov 4 13:13:27 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W9L4 
<li>problem n: 332 
<li>Status: unfixable
<li>Action: Monitoring
<li>entered by: evah 
<li>description is: DRO ~25% since around run 153616. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B4W9&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Nov 4 13:17:04 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W5L2 
<li>problem n: 702 
<li>Status: needs_access_2hr
<li>Action: Monitoring
<li>entered by: evah 
<li>description is: c2 termination ~15% since run 153616. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B5W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Nov 4 16:22:40 2002 -->
<pre> 
SB0W11L2: 
has a zoo of various kind of errors: 
1.   Frankstein Events 
2.   missing OBDV edges and so inserting spurious d0d0  
  e0b276fc 891100f3 88118711 86118511 0403050c 06f307d0 d0c2c2c4 
3.   missing last channel of the last chip    
  a22da12d a02d59f3 5a0f5b0c 5c0a5df3 71047217 73127424 7503c2c2 
 
It sounds to me like an OBDV problem so the solutions to be tried are: 
 
a. put a SUPERFIB 
b. swap the RX with a GOLD-Pinned one. 
 
</pre>
<!-- Author: Gino -->

<!-- Date: Mon Nov 4 16:25:49 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W11L2 
<li>problem n: 765 
<li>Status: needs_access_2hr
<li>Action: Diagnosis_update
<li>entered by: bolla 
<li>description is: <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=128&frame=2&anchor=16:22:40'> Look at the e-log </a> needs either a SUPERFIB or an RX swap for OBDV troubles     
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W11&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Nov 4 16:33:34 2002 -->
<p> 
Tested north side CAEN reset buttons (south side had already been tested).</p> 
<p> 
NW TOP 1 -- OK<br> 
NW TOP 2 -- OK<br> 
NW TOP 3 -- OK<br> 
NW TOP 4 -- OK<br> 
NE TOP 1 -- OK<br> 
NE TOP 2 -- <b><blink><font color=red>does nothing</font></blink></b><br> 
NE TOP 3 -- OK<br> 
NE TOP 4 -- <b><blink><font color=red>does nothing</font></blink></b><br> 
</p>
<!-- Author: Andy H. -->
<!-- Comment: Mon Nov  4 17;24;09 comment by...Love the blink tag -->
I could see the +5V at the rack panel output terminals, so the
problem is probably in the collision hall... <b><blink><font color=red>next supervised access</font></blink></b>


<!-- Date: Mon Nov 4 23:42:58 2002 -->
We took advantage of some quiet time and performed an I-V scan for the e262 bias. 
<TABLE><TR><TD>V (Volts)</TD><TD>I (microAmps)</TD></TR> 
<TR><TD>1.7</TD><TD>320</TD></TR> 
<TR><TD>4.8</TD><TD>1125</TD></TR> 
<TR><TD>9.7</TD><TD>2497</TD></TR> 
</TABLE> 
This is linear and consistent with a 5.8KOhm resistance.  
<!-- Author: Gino,Jason -->


<!-- Date: Mon Nov 4 23:55:16 2002 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-883&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-883' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-884&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-884' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-885&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-885' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-886&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-886' width='300'></a></center>
<!-- Author: Gino and Jason -->
<!-- Comment: Tue Nov  5 00;05;29 comment by...Gino and Jason -->
<pre>
The four plots are for SB2W6L2. They are to show that there is NOT a PIN-HOLE because there are NOT new bad channels.
From left to right:
1. PHI side noise as measured today with 15 V
2. Z side noise as measured today with 15 V
3. PHI side noise as measured at the beginning of september 
    with the nominal 45 V
4. Z side noise as measured at the beginning of september
    with the nominal 45 V
IT IS EVIDENT THAT THERE ARE NO NEW CHANNELS WITH LOW NOISE.

THE Current plot

<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-887&button=yes'
target='xxx' onclick='jswindow()'><img
src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-887' width='300'></a></center>
shows the current step UP that has not yet recovered.
</pre>

<!-- Date: Tue Nov 5 00:08:37 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W6L2 
<li>problem n: 739 
<li>Status: needs_access_2hr
<li>Action: Diagnosis_update
<li>entered by: bolla 
<li>description is: <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=128&frame=2&anchor=23:55:16'> THIS IS THE e-log LINK </a> showing that the ladders does NOT have a PIN-HOLE. Need resistance measurements at the cable. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W6&layer=L2">report</a></ul>
<!-- Author: Problem DB -->