<!-- Title: 08:53:54  Mon Jul 22 2002 -->
<!-- Crewchief: Silicon People -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>There is going to be an access for 6 hours. 
Not yet clear if it is going to be controlled or supervised.</pre>

<!-- Date: Mon Jul 22 10:49:43 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 170
Calibration type  : standard
Run period tag    : Jul_2002
DPS-off run       : 148679
DPS-on run        : 148678
Requested by      : Jason Nielsen
Main process id   : 2573088
Comment           : Resubmitting job because online DB was down.
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->



<!-- Date: Mon Jul 22 12:21:23 2002 -->
<h3>Access report for Fibs</h3> 
<ul> 
<li>       SB2W10-11 b0fib00 was Sl 18 is Sl 19 S/N 135 PREP 560620 <->  
SB2W2-3 b0fib00 was Sl 19  is Sl 18 S/N<BR> to try and  
cure SPT on SB2W10 L1.<BR> 
SB2W2 and W3 seem fine with svxdaq, SB2W10 and SB2W11 as well, SB2W10 L1 is back online (for the moment) 
<li>       Replace IB2W0/1 b0fib01 Sl 12 S/N 105 PREP 550267 with Fib SN 126 PREP 560611 <BR>to 
         try and cure low rate Fib wide Cap ID mismatches<BR> 
Cap ID mismatches are gone but we have Bunch Crossing Mismatches  
on Ch 2 (f202).  This is a nuisance but not fatal to data taking, so for now we leave it as it is and prepare to swap it out when 
we have another ISL spare for the next access. 
</ul>   
<!-- Author: SCN -->
<!-- Comment: Mon Jul 22 18;33;04 comment by...Gino -->
<pre>On behalf of Chris and Mat.
They investigated LB0W0 where the layer 3 cannot be turned ON.
The problem is in the remote sensing cable and will
go away if either:
1. we butcher the cable and break some connectors
2. we install a L00 power supply
Today there was not time for option 1 and NOT a spare L00 PS for option 2
I like option 2 much better.
</pre>
<!-- Date: Mon Jul 22 12:26:21 2002 -->
<pre>Access Report of Lester and Cigdem 
=================================== 
 
 
We did light output measurements on e584 and e573.  
Both are ok.  
e584 needs RX Swap during the next access.  
Where as e573 is not so clear what do, because we could not reproduce the failure by taking data with SVXDAQ.  
 
We also repaired the doim cable of e520 and have to verify that 
this repair was successful.  
 
</pre>
<!-- Author: lester cigdem -->

<!-- Date: Mon Jul 22 12:31:33 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 171
Calibration type  : standard
Run period tag    : Jul_2002
DPS-off run       : 148679
DPS-on run        : 148678
Requested by      : Jason Nielsen
Main process id   : 2909895
Comment           : Resubmitting job because network was down.
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->



<!-- Date: Mon Jul 22 18:35:20 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W10L1 
<li>problem n: 395 
<li>Status: needs_observation
<li>Action: Added_hdwdb
<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=117&frame=2&anchor=12:21:23'> FIB swapped and ladder re-integrated </a>   </ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Jul 22 18:57:22 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 172
Calibration type  : standard
Run period tag    : Jul_2002
DPS-off run       : 148679
DPS-on run        : 148678
Requested by      : Jason Nielsen
Main process id   : 191155
Comment           : Data disk died in job 171.
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->



<!-- Date: Mon Jul 22 23:01:32 2002 -->
<p>We're in for store 1569.  Losses are low and stable and L1A started out at about 7 kHz.  When turning on, SB3W1L4 tripped 
on bias overcurrent.  Attempting to turn it on again showed 
about 4 mA (limit is at 5) -- then it tripped again before the 
next GUI update.  Thinking it might be a transient, I tried to 
coax the bias voltage up to 40 V, but at 10 V it was already drawing a steady 2 mA.  I kicked it out of the HDWDB and generated 
a new CAENvolts.dat.  Problem DB entry to follow.</p>
<!-- Author: Andy H. -->

<!-- Date: Mon Jul 22 23:06:52 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W1L4 
<li>problem n: 80 
<li>Status: needs_work
<li>Action: Removed_hdwdb
<li>entered by: hocker 
<li>description is: <pre>Trips on bias overcurrent.  Known problem?</pre> </ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Jul 22 23:14:20 2002 -->
<center><a href='/elog/notebooks/silicon/Mon_Jul_22_2002_230033.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-651' ></a><a href='/elog/notebooks/silicon/Mon_Jul_22_2002_230132.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-653' ></a></center>
<!-- Author: Gino -->
<!-- Comment: Mon Jul 22 23;16;49 comment by...Gino -->
<pre>SB3W1L4 probably kicked out of HDWDB because of BIAS O-C trips
while turning it ON.
LEFT PLOT behavior of this ladder (bias current) since the
          beginning of time
RIGHT PLOT current vs time for the last store.
          The current is high but nothing anomalous is visible

</pre>


<!-- Date: Tue Jul 23 11:09:52 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Tue_Jul_23_2002_110948.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-657  align='top'></td><td>What SRC sends to Fib for RECOVER</a></td></tr></table>
<!-- Author: SCN, Reid -->
<!-- Comment: Tue Jul 23 11;10;27 comment by...SCN, Reid -->
<h3>SRC commands to FIB</h3>
Here is a LA picture of the SRC sending the HRR commands
to the FIB.  <ul> 
<li> PARST START and STOP (04 and 02)
which are execute immediate and are not always there, but happen to be this time
<li> (13) is CHIP RESET, and is not execute immediate
<li> (1E) is an unnammed sequence, and we don't know what it does, but it is execute immediate
<li> (12) is FIB_RESET
</ul>

We've seen the 0x1E command on the SRCs in the diagnostic crate, in the
crate at DAQ3, and in the "DEARFIB" commands from the real B0 SRC
(where it shows up as 0x7E which is (0x1E | 0x40 (synch) | 0x20 (xqt immediate))
so it is there all the time.  Anyone know why?


<!-- Comment: Tue Jul 23 11;53;46 comment by...SCN -->
After dicussion with Lester, we found out that command 0x7E is in fact command 0x3E ( | 0x40) which is 
Fib Fanout command to reset errors.  All "Fib" commands between
0x38 and 0x3F are actually FFO commands (note the double usage of the Execute Immediate 0x20).  According to the 
FFO document (page 21) <P><cite>"The assumption is that these commands are treated as no-ops by the FIBs in the same subrack"</cite> <P> Maybe someone ought to check on that No-op 
statement...
<!-- Date: Tue Jul 23 11:33:17 2002 -->
<pre>SB3W1L4. 
I re-integrated this ladder with a nominal BIAS voltage of 15  
(instead of the real 40 V) 
This is meant to be a temporary change to see the long term  
behavior of the current vs time. 
In a few days we will look at the outcome. 
</pre>
<!-- Author: Gino -->

<!-- Date: Tue Jul 23 11:36:40 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W1L4 
<li>problem n: 80 
<li>Status: needs_observation
<li>Action: Added_hdwdb
<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=117&frame=2&anchor=11:33:17'> Reintegrated VBIAS changed temporarely from 40 to 15 V </a>   </ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Jul 24 16:07:47 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W3L0 
<li>problem n: 592 
<li>Status: needs_observation
<li>Action: Monitoring
<li>entered by: evah 
<li>description is: Looking at SVXMon for run >=148674, this ladder has 98% c2c2, DRO,  no first chip.  </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jul 25 16:04:14 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W5L3 
<li>problem n: 593 
<li>Status: needs_observation
<li>Action: Monitoring
<li>entered by: cmircea 
<li>description is: <pre>Bit 3 stuck low in all Z side chips in two
runs: 148907, 148904 looking at SVXMon online.</pre> </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jul 25 16:16:08 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W2L4 
<li>problem n: 232 
<li>Status: needs_observation
<li>Action: Monitoring
<li>entered by: cmircea 
<li>description is: <pre>Bit 1 low problem has come back in 148908, 148907.</pre> </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jul 25 16:39:32 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W1L1 
<li>problem n: 586 
<li>Status: needs_observation
<li>Action: Monitoring
<li>entered by: cmircea 
<li>description is: <pre>Bit 0 low not a 100% of the time, c2c2 termination error for 
runs around 148908.</pre> </ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Jul 26 01:12:36 2002 -->
<p>There was an online cluster crash at about 23:45, killing the GUI.  The aces tried to turn the silicon to STBY, but of course they couldn't.  I had them keep a close eye on the beam and cooling conditions in case we needed to hit the crash button.  After b0dap42 was back up, I restarted the GUI.  The attempted STBY click from earlier then immediately took effect.  I let it 
go, then returned the bias to ON without incident.</p> 
<p> 
I also noticed all the FIBs were yellow in VxMon.  I logged into 
them and saw no FER_Messenger process running.  Rebooting them 
fixed that.</p> 
<p> 
I restarted IMON, but since b0dap71 did not survive the crash (to 
be fixed tomorrow, I think) I'm running IMON on b0dap42.</p>  
<!-- Author: Andy H. -->

<!-- Date: Fri Jul 26 10:04:11 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 173
Calibration type  : standard
Run period tag    : Jul_2002
DPS-off run       : 148921
DPS-on run        : 148918
Requested by      : gino
Main process id   : 8424148
Comment           : A L3 Filter error
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->



<!-- Date: Fri Jul 26 12:49:26 2002 -->
I forgot to mention that in the middle of the night last night 
there was a trip on SB5W7.  The GUI reported DVDD3 overcurrent, 
but it looks like all of layers 0-3 tripped.  The port card had 
to be power-cycled to get the ladders back on.
<!-- Author: Andy H. -->

<!-- Date: Fri Jul 26 16:53:07 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W6L3 
<li>problem n: 547 
<li>Status: needs_observation
<li>Action: Diagnosis_update
<li>entered by: cmircea 
<li>description is: <pre>Bit 3 stuck low in all Zside chips, c2c2 termination error for 
run 148950 seen in SVXMon online. </pre> </ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Jul 26 17:17:57 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W4All 
<li>problem n: 594 
<li>Status: needs_work
<li>Action: Monitoring
<li>entered by: cmircea 
<li>description is: <pre>on 3 layers out of 4 there are CAPID errors and C2C2 termination.
Worth looking at timing signal during access.
Maybe swap FIB</pre> </ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Jul 26 17:19:11 2002 -->
<pre>Beginning of STORE # 1583 
Highest Luminosity ever (2.7 E31). 
L1A trigger rate around 12 KHz. 
Proton losses above 20 KHz. 
Called MCR and they lowered the proton losses to acceptable  
        values (15 KHz slowly to 12 KHz) 
We Integrated the silicon after struggling with a few trips 
when the L1A trigger rate was about 10KHz. 
Only one of them is understood SB4W9L4 tripped on AVDD O-C  
due to the low limit in connection with DVDD connection broken  
on DVDD. 
 
L00 EAST W3 VBIAS03 Undervoltage tripped twice. 
We lowered the Vbias from 120 to 100 V and everything OK. 
This ladder always had 0 current. 
 
 
 
All the other trip are of unknown reason. 
 
 </pre>
<!-- Author: Gino and Andy -->


<!-- Date: Fri Jul 26 19:52:13 2002 -->
<pre>We lost the RECORD STORE at about 19:00 for not well known  
RF problem. 
The store was lost in a CLEAN way. 
The HV were still up and so I took advantage of the quiet time to 
do a BEAM OFF D-mode calibration.  
This should help Jason and IGOR. 
 
 
Furthermore: 
Ricardo and Jhon did a fantastic job with IMON. 
They placed a new version that is running now. 
 
Some nominals still have to be changed especially the bias ones because they are based on old data that changed with radiation damage. 
I changed the few AVDD and VDOIM that are necessary immediately 
for good monitoring of HIGH L1A rates potential failures. 
I leave the others to John. 
 
One more thing. 
while working with IMON I found out that SB4W5L1 has 0 reading  
on the DVDD current consumption. 
This might be an offset of the PS. 
Surely I have all indication that the ladder is behaving well. 
 
Ha you all a nice w-e</pre>
<!-- Author: Gino -->

<!-- Date: Fri Jul 26 19:56:09 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W3L3 
<li>problem n: 450 
<li>Status: needs_work
<li>Action: Incident
<li>entered by: bolla 
<li>description is: <pre>Tripped on BIAS 0 Undervoltage.
Changed VBIAS from 120 to 100 V</pre> </ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Jul 26 19:56:51 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 174
Calibration type  : standard
Run period tag    : Jul_2002
DPS-off run       : 148958
DPS-on run        : 148956
Requested by      : Takashi Ogawa
Main process id   : 9435001
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->



<!-- Date: Sat Jul 27 02:51:32 2002 -->
<pre>Probably obvious to everyone, but it's slow tonight... 
 
The channels that need their IMON nominals reset 
 
SB1W7 (SOC) 
 
 The following are ALL set to -1 
 
SB1W0 L2 Bias  
SB1W1 L2 Bias  
SB1W5 L4 Bias  
SB2W11 L4 Bias  
SB3W0 L4 Bias  
SB3W5 L2 Bias  
 
SB4W5 L1 DVDD  
SB4W4 L2 Bias  
SB4W4 L4 Bias  
 
IB0W1 L0 Bias1 
IB0W2 L4 Bias0 
IB0W2 L4 Bias1 
IB0W3 L4 Bias0 
IB0W4 L4 Bias0 
IB0W4 L0 Bias1 
IB0W5 L2 Bias0 
 
IB1W1 L0 Bias1 
IB1W3 L2 Bias0 
IB1W4 L4 Bias1 
IB1W5 L0 Bias0 
IB1W5 L4 Bias1 
 
IB4W0 L4 Bias0 
IB4W1 L2 Bias0 
IB4W1 L0 Bias1 
IB4W1 L2 Bias1 
IB4W1 L4 Bias1 
IB4W2 L0 Bias0 
IB4W2 L4 Bias0 
IB4W3 L4 Bias0 
IB4W4 L0 Bias0 
 
IB5W2  L4  Bias0 
IB5W3  L3  Bias0 
IB5W3  L4  Bias0 
IB5W3  L4  Bias1 
IB5W4  L4  Bias0 
IB5W4  L4  Bias1 
IB5W5  L4  Bias0 
IB5W5  L0  Bias1 
 
</pre>
<!-- Author: ADF -->


<!-- Date: Sat Jul 27 02:57:11 2002 -->
<pre> The following channels have nontrivial nominals in IMON, 
and persistently show purple.  Not too worried since 
we aren't taking data. 
 
LB0W0 L2 AVDD (Undercurrent 130 Readout &lt; 150 Min) 
LB0W0 L0 DVDD (Undercurrent 43 Readout &lt; 56 Min) 
LB0W0 L2 DVDD (Undercurrent 40 Readout &lt; 55 Min) 
LB0W4 L3 DVDD (Undercurrent 60 Readout &lt; 72 Min) 
LB0W5 L3 DVDD (Undercurrent 70 Readout &lt; 83 Min) 
 
SB1W4 L1 DVDD (Undercurrent 49 Readout &lt; 55 Min)</pre>
<!-- Author: ADF -->


<!-- Date: Sat Jul 27 08:05:31 2002 -->
<pre>On the MCR e-log they report that the last store that ended in a  
quench around 5:15 am had a lot of DC beam (factor of 400 with  
respect to the previous store if you believe the number they quote). 
As a consequence I went through COLD start and took some data  
on my own partition. 
No Problem has been seen. 
</pre>
<!-- Author: Gino -->


<!-- Date: Sat Jul 27 18:40:54 2002 -->
<pre>There were 2 hours of quiet time so I came IN and raised the HV  
I lowered them after about one hour. 
This was for me to check the behavior of some leakage current</pre>
<!-- Author: Gino -->


<!-- Date: Sun Jul 28 19:16:53 2002 -->
<pre>Silicon Integrated at about 18:50 after the BD lowered the proton 
lossess to acceptable values. 
 
During the transition from STDBY to ON I got 2 trips: 
 
Here is the sequence of events as reported by svxinter: 
 
detector = 1, barrel_n = 0, status = 0 
SVX B0W2L3 spontaneously turned off 
turning it back on 
Sending Request for e023 
SVX B2W3L3 spontaneously turned off 
turning it back to standby 
Sending Request for e233 
SVX B0W2L3 got a trip 
SVX B2W3L3 got a trip 
Both trips were DVDD O-C as happens when we turn a ladder OFF. 
 
So the two ladders that had a spontaneous transition are the only  
two that tripped. 
They probably tripped while going OFF as it usually happens since  
we lowered the current limits. 
 
 
Silicon was integrated in Run #149052 without any problem. 
Luminosity about 21.5 E31 and trigger rate of about 9 KHz 
Both of them slowly decresing.</pre>
<!-- Author: Gino and Lester -->


<!-- Date: Mon Jul 29 01:00:26 2002 -->
<pre>After COT trip and TSI HRR, numerous out-of-limit DVDD  
values in Imon. Three AVDD, all for LOW readings: SB0W2 L2,  
SB3W5 L1, LB0W0 L2.  Unmarked all in order to keep some semblance 
of a watch on things. 
 
After unmarking, almost all channels stated unmarked. 
The LB0W0 L2 AVDD current stayed marked 
(still low).  There are 3 L00 DVDD marks LB0W4 L3 (high), 
LB0W5 L3 (high), LB1W4 L3 (high).  SVX SB4W5 L1 has not  
had a DVDD range set yet.  All ISL AVDD & DVDD OK.</pre>
<!-- Author: ADF -->

<!-- Date: Mon Jul 29 13:42:56 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W0L4 
<li>problem n: 596 
<li>Status: needs_work
<li>Action: Init_RB_mask
<li>entered by: bolla 
<li>description is: <pre>SB5W0L4 MASKED BITSTREAM READBACK.
AVDD CURRENT DROPPED BY ~200 MA READOUT STOP AFTER 2ND Z CHIP
2ND Z CHIP HAS WEIRD OCCUPANCY AND MEAN CHARGE FROM SVXMON
2ND Z CHIP HAS RIGHT CAPID SO ALMOST AVDD2is but not completely</pre> </ul>
<!-- Author: Problem DB -->
<!-- Comment: Mon Jul 29 15;28;38 comment by...Gino -->
<pre>Out of this bad news there are some good news:
With the Online Monitoring tools we have available I was able to 
spot the following basically in real time:

IMON: The AVDD got PINK immediately
SVXMON:
	starting at the 3rd Z chip the 
	"Cell id SVX chip Status Map" got yellow immediately
	"SVXMon SVX Chip Status Map" got RED for the 2nd Z chip 
		and yellow for the chips after this one
	"Silicon Tracker Chip Occupancy
		East Barrel East Side
		L4 Z side
			IS RED due to chip 1 (starts from 0)
			this is exactly the 2nd Z chip of SB5W0L4

</pre>
<!-- Date: Mon Jul 29 15:05:39 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Mon_Jul_29_2002_150535.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-659  align='top'></td><td>SB2W7L1 IDvdd1, IDoim2 and IDoim5 from 11-Apr-2001 to 20-July-2001. Suspect the  bit 1 blew on 26-Apr-2001 (day 115).</a></td></tr></table>
<!-- Author: lester -->


<!-- Date: Mon Jul 29 15:07:27 2002 -->
Looking at history of SB2W7L1 history for blown bit 1: 
<b>Elog history:</b><ul> 
<li><b>17-Apr-2001</b><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=20&frame=2&anchor=20:35:31'> 
last mentioned to work</a></li> 
<li><b>18-Apr-2001</b><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=26&frame=2&anchor=08:58:48'> 
Light levels measured (e271 has light)</a></li> 
<li><b>23-Apr-2001</b><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=21&frame=2&anchor=17:28:06'> 
Comment implies all SB2W7 ladders in</a></li> 
<li><b>26-Apr-2001</b><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=22&frame=2&anchor=19:29:11'> 
SRC abort digitize/readout tests</a> 
<li><b>26-Apr-2001</b><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=22&frame=2&anchor=20:20:45'> 
Trips on high loss</a></li> 
<li><b>27-Apr-2001</b><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=22&frame=2&anchor=03:07:38'> 
bit 1 low first mentioned</a> 
<li><b>28-Apr-2001</b><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=23&frame=2&anchor=15:35:55'> 
Mentioned as out of hdwdb </a></li> 
<li><b>17-Apr-2001</b><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=e270-SVX-C-BRL-W-End-P-7&action=view&page=1&frame=2&anchor=07:23:30'> 
Bit 1 low again </a></li> 
<li>Mentioned several times as not working (never as working)</li> 
<li><b>08-Nov-2001</b><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=e270-SVX-C-BRL-W-End-P-7&action=view&page=1&frame=2&anchor=20:03:09'> 
No light measured from Detector</a></li> 
<ul> 
So the conclusion is not solid but perhaps the TS/SRC tests  
of the 26th of April (which caused many trips) were responsible. 
<br>No DS current record for this period.
<!-- Author: Lester -->
<!-- Comment: Mon Jul 29 15;08;22 comment by...Lester -->
did I just screw up the html?</ul>

<!-- Comment: Mon Jul 29 15;08;52 comment by...L -->
Yup

<!-- Comment: Mon Jul 29 15;09;48 comment by...L -->
</ul>Twice in fact



<!-- Date: Mon Jul 29 18:34:26 2002 -->
<center><a href='/elog/notebooks/silicon/Mon_Jul_29_2002_183321.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-669' ></a><a href='/elog/notebooks/silicon/Mon_Jul_29_2002_182948.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-661' ></a><a href='/elog/notebooks/silicon/Mon_Jul_29_2002_183044.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-663' ></a><a href='/elog/notebooks/silicon/Mon_Jul_29_2002_183120.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-665' ></a><a href='/elog/notebooks/silicon/Mon_Jul_29_2002_183201.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-667' ></a></center>
<!-- Author: Lester -->
<!-- Comment: Mon Jul 29 18;38;03 comment by...Lester -->
<b>Doim currents for SB4W6L3 around the time of failure. </b>
<ul>
<li><b>Top Left:</b> Port Card currents for around 5-Jan-2002 00:00
which is first point of failure.</li>
<li><b>Top Center:</b> IDoim2V for before this date.</li> 
<li><b>Top Right:</b> IDoim2V for after this date.</li> 
<li><b>Bottom Left:</b> IDoim5V for before this date.</li> 
<li><b>Bottom Right:</b> IDoim5V for after this date.</li> 
</ul>
If you squint you may convince yourself there is a change in
behaviour.



<!-- Date: Mon Jul 29 18:50:06 2002 -->
Looking at history of SB4W6L3 history for blown bit 3: 
<b>Elog history:</b><ul> 
<li><b>9-May-2001</b><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=e460-SVX-E-BRL-W-End-P-6&action=view&page=1&frame=2&anchor=07:09:03'> 
Bit 3 high CapID seen in WIB test</a> Later traced to VRB issue since it 
only occurs every sixth event on two chips.</li> 
<li><b>22-Dec-2001</b><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=85&frame=2&anchor=21:48:36'> 
Bit 3 high 2% reported in post-long-access checkout</a></li> 
<li><b>05-Jan-2002</b><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=87&frame=2&anchor=00:14:00'> 
New CDF Error throwing causes almost all SVX ladders to DVDD trip.<br> 
Problem is thought to be keep alives missing in halt.</a></li> 
<li><b>05-Jan-2002</b><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=87&frame=2&anchor=07:15:21'> 
Repeated init failures, ladder kicked out</a></li> 
<li><b>11-Jan-2002</b><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=89&frame=2&anchor=07:12:26'> 
AVDD, DVDD OC reported</a></li> 
</ul> 
Conclusion: Seems to have failed at midnight on 4-5 of Jan. 2002. 
While the failure is close to the end of the SVT CDF Error throws, 
These ended at around 23:50 (run 136271) One more physics run,  
136273, was taken. Then <a href="http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER=136274">136274</a> (00:37-00:56), an SVT two-track test table was taken with 1.8kHz L1A.  
The ladder failed init on 136275 (01:17). 
 
<!-- Author: Lester -->


<!-- Date: Mon Jul 29 20:20:58 2002 -->
<pre>Paged for beam abort incident. 
The following tripped: 
 
Mon Jul 29 19:20:05 CDT 2002     TRIP: L00  WEST  W0 VBIAS2 OverCurrent 
Mon Jul 29 19:20:05 CDT 2002     TRIP: L00  WEST  W0 VBIAS2 OverCurrent 
Mon Jul 29 19:20:05 CDT 2002     TRIP: L00  WEST  W1 VBIAS13 OverCurrent 
Mon Jul 29 19:20:06 CDT 2002     TRIP: L00  EAST  W0 VBIAS13 UnderVoltage 
Mon Jul 29 19:20:06 CDT 2002     TRIP: L00  EAST  W0 VBIAS13 UnderVoltage 
Mon Jul 29 19:20:06 CDT 2002     TRIP: L00  EAST  W0 VBIAS13 UnderVoltage 
Mon Jul 29 19:20:06 CDT 2002     TRIP: L00  EAST  W1 VBIAS13 OverCurrent 
Mon Jul 29 19:20:06 CDT 2002     TRIP: L00  EAST  W1 VBIAS13 OverCurrent 
Mon Jul 29 19:20:06 CDT 2002     TRIP: L00  EAST  W1 VBIAS13 OverCurrent 
Mon Jul 29 19:20:06 CDT 2002     TRIP: L00  EAST  W1 VBIAS13 OverCurrent 
Mon Jul 29 19:20:06 CDT 2002     TRIP: L00  EAST  W2 VBIAS13 OverCurrent 
Mon Jul 29 19:20:06 CDT 2002     TRIP: L00  EAST  W2 VBIAS13 OverCurrent 
Mon Jul 29 19:20:06 CDT 2002     TRIP: L00  EAST  W3 VBIAS02 OverCurrent 
Mon Jul 29 19:20:06 CDT 2002     TRIP: L00  EAST  W3 VBIAS02 OverCurrent 
Mon Jul 29 19:20:06 CDT 2002     TRIP: L00  EAST  W3 VBIAS02 OverCurrent 
Mon Jul 29 19:20:07 CDT 2002     TRIP: L00  EAST  W4 VBIAS13 OverCurrent 
Mon Jul 29 19:20:07 CDT 2002     TRIP: L00  EAST  W5 VBIAS13 OverCurrent 
Mon Jul 29 19:20:07 CDT 2002     TRIP: SVX  B4  W1 VBIAS0 OverCurrent 
Mon Jul 29 19:20:07 CDT 2002     TRIP: SVX  B4  W4 VBIAS2 OverCurrent 
Mon Jul 29 19:29:15 CDT 2002     success: Resetting trips 
Mon Jul 29 19:33:24 CDT 2002     TRIP: L00  EAST  W2 DVDD3 OverCurrent 
Mon Jul 29 19:33:24 CDT 2002     TRIP: L00  EAST  W5 DVDD3 OverCurrent 
Mon Jul 29 19:33:24 CDT 2002     ERROR: the L00 Handshake - Could not turn on power - checked 10 times 
Mon Jul 29 19:33:33 CDT 2002     TRIP: ISL  B5  W1 DVDD1 OverCurrent 
 
 
I told the ace to reset trips (seen above) and try turning L00 
back to Standby. It failed to repower LB1W2 and 5, and registered 
a new (!) ISL DVDD overcurrent trip. </pre>
<!-- Author: Lester -->


<!-- Date: Mon Jul 29 20:40:19 2002 -->
<pre>Continuing to try to repower L00: 
 
LB1W5L3 continues to have alternating Internal Trip 
and overcurrent on DVDD. Strangely, a lot of channels  
around L00 have 2V written to V0Set for AVDD and DVDD.  
Is this normal? There is no pattern to these... many are 
still V0Set=0. 
 
During the one update before IntTrip, DVDD current looks  
normal so I hope there's no real damage... 
 
As for the other nonL00 trips: 
 
SB4W4L2 VBias trip came back on. This ladder is suspected of  
having the wrong scale, so maybe not surprising. 
 
SB4W1L0 First attempt had DVDD0 trip, second successful 
 
IB5W1L1 has same symptom as L00: alternating DVDD OC and Internal 
Trip on DVDD. 
 
</pre>
<!-- Author: Lester -->
<!-- Comment: Mon Jul 29 20;50;11 comment by...Lester -->
<pre>The ladders which had Internal Trips were repowered by cycling
the wedge. (Secret recipe from Gino and SCN) Strange, huh.</pre>

<!-- Comment: Mon Jul 29 21;01;06 comment by...Lester -->
<pre>Successfully coldstarted.

Ladders on L00 which draw no current on bias:
=============================================
LB0W3L1
LB0W3L3 (VBias and VBias1)
LB0W2L3 (VBias1)
LB1W3L3 (VBias and VBias1)

These should be crosschecked.
</pre>

<!-- Comment: Mon Jul 29 21;54;29 comment by...Gino -->
<pre>
<a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=116&frame=2&anchor=17:29:46'>
LB0W3L1 </a> was spotted with 0 current before (not a problem).

<a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=112&frame=2&anchor=05:00:32'>
LB0W3L3 </a> was spotted with 0 current before (not a problem).

LB0W2L3 VBIAS 0 had 6.8 uA today when it was ON
		    0.5 uA today while in STDBY

LB0W2L3 VBIAS 0 had 7.6 uA today when it was ON
		     uA today while in STDBY
	After the quench it was NOT turned ON
		In STDBY the current is 0 uA
		It has always been the same at STDBY so no  surprises.


LB1W3L3 always had 0 bias current at STDBY on both BIAS0 and BIAS1

So the main point is that 

	no trouble has been induced by the quench
	
	Our checking was not completed probably because Lester 
		
		could NOT turn things ON (not only STDBY) due 
		to beam conditions 
		
		or lack of clear procedures on how to check 
		for this potential damage to the 
		fuses on the crowbars.

</pre>


<!-- Comment: Mon Jul 29 22;02;18 comment by...Gino -->
<pre>There is nothing secret about the recipe that was applied.
It is just a matter of doing a "search" on the e-log and find out
what Steve had to do when He was faced with a similar problem 
and compare what he did what what had already been tried tonight and try the rest. 
</pre>

<!-- Date: Tue Jul 30 05:20:28 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 175
Calibration type  : standard
Run period tag    : Jul_2002
DPS-off run       : 149100
DPS-on run        : 149099
Requested by      : SWLee
Main process id   : 15360011
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->



<!-- Date: Tue Jul 30 11:22:08 2002 -->
<pre>access report of Gino/Cigdem 
============================ 
 
Action 1  
======== 
 
we swapped RX of e584: OUT RX 0875 
                       IN  RX 1133  gold pinned 
 
This swap did not cure the problem. 
We put the DOIM cable of e584 into the FTM socket of e583 and 
the DOIM calbe of e583 into the FTM socket of e584. 
After this switch we could run of layers without any problem.  
We put the DOIM cables back to their old positions.  
 
We decided to swap the FIB of this FTM by a super FIB: 
 
We took out the FIB 550271  
and put in the super FIB 560610. 
After this FIB swap the problem of e584 was fixed.  
 
Action 2 
======== 
 
We swapped the FIB of f20/1 by another FIB (not a super FIB): 
 
OUT : 560611   IN: 560618 
 
Problem was not solved by this swap. We are suspecting that 
the problem may be caused by the VRB, which we will 
check after the access.  
 
 
 
</pre>
<!-- Author: cigdem & gino -->

<!-- Date: Tue Jul 30 12:01:29 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W2L4 
<li>problem n: 110 
<li>Status: needs_access_2hr
<li>Action: Swap_RX
<li>entered by: lmiller 
<li>description is: Rx 0845 out, 1108 in. Symptoms (multiple low bits) remain after swap. </ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jul 30 12:02:43 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W4L2 
<li>problem n: 163 
<li>Status: fixed
<li>Action: Swap_RX
<li>entered by: lmiller 
<li>description is: Rx 0984 out 1119 in.  Retested OK! </ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jul 30 12:10:08 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W0L0 
<li>problem n: 285 
<li>Status: needs_observation
<li>Action: Swap_RX
<li>entered by: lmiller 
<li>description is: Rx 0721 out, 0326 in. Dropped readout went away, now it has  bit 0 low. As this is repairable, it is left this way.   </ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jul 30 12:13:00 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W2L0 
<li>problem n: 575 
<li>Status: fixed
<li>Action: Swap_RX
<li>entered by: lmiller 
<li>description is: Rx 0882 out, 1116 in. DRO not seen after swap. </ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Jul 30 13:58:55 2002 -->
<p><b>Controlled Access this AM</b> 
<p>I swapped the power supplies for LB0W0 and LB0W1.  The 'L00 flavor' supply is now in LB0W0 and this should effectively work around our problems with the LV short between layers 3 and "4". 
<p>I was able to turn on the 5V DOIM, 2V DOIM and layer 3 channels for LB0W0 successfully via the crate front panel. 
<p>
<!-- Author: Napora and Mumford -->
<!-- Comment: Tue Jul 30 15;14;56 comment by...Andy H. -->
CAEN.map should be updated to reflect this swap!

<!-- Comment: Wed Jul 31 13;08;01 comment by...Jason -->
I thought I had updated CAEN.map. If I made a mistake, please let me know.
<!-- Date: Tue Jul 30 18:02:20 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W5L4 
<li>problem n: 85 
<li>Status: needs_observation
<li>Action: Added_hdwdb
<li>entered by: bolla 
<li>description is: <pre>SB2W5L4 Re-integrated. Was out for not very good reasons</pre> </ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jul 30 18:09:19 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W3L4 
<li>problem n: 508 
<li>Status: needs_observation
<li>Action: Added_hdwdb
<li>entered by: bolla 
<li>description is: <pre>SB4W3L4 re-integrated. Was out for DVDD trip that did NOT repeated today</pre> </ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jul 30 19:02:40 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W3L4 
<li>problem n: 86 
<li>Status: unfixable
<li>Action: Added_hdwdb
<li>entered by: bolla 
<li>description is: <pre>SB0W3L4 re-integrated.
Chnaged DVDD trip limits to 2000 mA now we can run the PHI side.
Readout truncated after the last chip</pre> </ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jul 31 09:20:11 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W4L2 
<li>problem n: 389 
<li>Status: needs_observation
<li>Action: Added_hdwdb
<li>entered by: bolla 
<li>description is: <pre>SB1W4L2 re-integrated, turned it ON and taken data with svxdaq without any problem</pre> </ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jul 31 09:49:28 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W0L3 
<li>problem n: 288 
<li>Status: fixed
<li>Action: Added_hdwdb
<li>entered by: bolla 
<li>description is: After <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=117&frame=2&anchor=13:58:55'> PS work </a>  this ladder is re-integrated </ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jul 31 11:25:56 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 176
Calibration type  : standard
Run period tag    : Jul_2002
DPS-off run       : 149233
DPS-on run        : 149232
Requested by      : Jim Kraus
Main process id   : 19010383
Comment           : L3 manager not included.
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Wed Jul 31 11:36:57 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W4L2 
<li>problem n: 389 
<li>Status: needs_work
<li>Action: Removed_hdwdb
<li>entered by: bolla 
<li>description is: <pre>SB1W4L2 removed from hdwdb for the same reason it was out up to today.
I have no idea about what is going on with it.</pre> </ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Jul 31 11:38:57 2002 -->
<pre>After they (who?) cleaned up RunControl the trigger table we use  
by default during our D-mode calibration is no longer there. 
I replaced it (with the help of Arndt) with COSMICS [6,117,297]  
and save it as default. 
</pre>
<!-- Author: Gino -->

<!-- Date: Wed Jul 31 11:44:40 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 177
Calibration type  : nonstandard
Run period tag    : Jul_2002
DPS-off run       : 149235
DPS-on run        : 149234
Requested by      : Jim Kraus
Main process id   : 18954992
Comment           : L3 manager is included.
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->




<!-- Date: Thu Aug 1 01:17:00 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-671&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-671  width='300' align='top'></td><td>Silicon to ON</a></td></tr></table>
<!-- Author: ADF -->


<!-- Date: Thu Aug 1 01:18:21 2002 -->
<pre>Unmarked all IMON channels</pre>
<!-- Author: ADF -->


<!-- Date: Thu Aug 1 01:33:39 2002 -->
<pre>~2% reformatter errors on e573 (comes out as e560).  IMON is 
happy and to my eye there is nothing absurd. Will power cycle, 
coldstart. </pre>
<!-- Author: ADF -->


<!-- Date: Thu Aug 1 01:50:49 2002 -->
<pre>Could not easily power cycle--got handshake error. 
Svxinter said, "All FIBs not initialized" and 
"No response from FIB".  Indeed, while logged into 
b0fib06 I saw no communication.  All processes on 
b0fib06 looked normal.  I rebooted b0fib06, then 
was able to turn ladder back on.  Now coldstarting.</pre>
<!-- Author: ADF -->


<!-- Date: Thu Aug 1 02:06:34 2002 -->
<pre>After power cycling, still get reformatter errors  
on e573.  Removed SB5W7 L3 from HDWB. Regenerated caenvolts file.</pre>
<!-- Author: ADF -->


<!-- Date: Thu Aug 1 02:14:45 2002 -->
<pre>And, according to Lester's suggestion, I even loaded  
the new caenvolts! 
 
Actually, this is a necessary step.  Apparently the trigger 
inhibit does not read the HWDB directly; it gets its 
info from the GUI.  If you removed something from HWDB, 
then turn it off without reloading the new caenvolts, 
the trigger inhibit will stop data-taking.  (Not that 
anyone I know here might have done that...)</pre>
<!-- Author: ADF -->


<!-- Date: Thu Aug 1 06:35:58 2002 -->
<pre>IMON purple spots (read out) &lt; or &gt; (limit) 
 
SB0W3 L2 AVDD 730 &gt; 725 
SB0W4 L2 DVDD 130 &lt; 145 
SB5W9 L4 DVDD 220 &gt; 190 
LB0W4 L3 DVDD 100 &gt; 82 
LB0W5 L3 DVDD 100 &gt; 93 
LB1W4 L3 DVDD 108 &gt; 77 
 
Unmarked all channels 
 
LB1W4 L3 DVDD persisted 
(plus, of course, innumerable bias currents)</pre>
<!-- Author: ADF -->

<!-- Date: Thu Aug 1 09:00:17 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 178
Calibration type  : standard
Run period tag    : Aug_2002
DPS-off run       : 149266
DPS-on run        : 149265
Requested by      : Minsuk
Main process id   : 21266111
Comment           : Stable beam(TeV lum=6.05
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->



<!-- Date: Thu Aug 1 09:28:54 2002 -->
<pre>Store # 1613. 
Lost an RF station at about 5:20 am. 
Losses and losses gated with the gaps are still normal. 
Luminosity approaching 6E30 at 8:30 am. 
For extra safety we decide (with the advises of Rick Vidal) to  
get the silicon Out of data taking. 
Before doing it we take D-mode calibration. 
Silicon is NOW STDBY. 
 
I will turn it OFF right now and wait for the abort. 
Next store will happen late in the day.</pre>
<!-- Author: Gino -->


<!-- Date: Thu Aug 1 10:13:19 2002 -->
<pre>SB5W7L3 was taken OUT tonight because of Reformatter error. 
Investigating it with svxdaq I see the following kind of events: 
 
e57301fc 89280028 013a0238 03380438 05380628 07280828 09280a39 0b290c2a  
0d280e38 0f29102f 1139122a 132f142d 152e1628 17281838 192d1a38 1b381c38  
1d281e38 1f28202e 212a2238 23382428 2538262e 272b2828 293a2a3b 2b2a2c2e  
2d282e38 2f2a3028 3129322b 33393428 35383629 3728382e 39393a39 3b283c2a  
3d293e2b 3f2a402a 412b4229 432b442a 452e4639 4728483b 492b4a28 4b284c38  
4d2e4e39 4f2b5029 51385229 532a5439 55285628 572b582a 592f5a38 5b285c29  
5d395e39 5f396039 6138622a 63296429 65296629 6728682a 69286a38 6b386c28  
6d386e3f 6f28703a 71397229 73387429 7538762a 7739783a 79287a38 7b2b7c3b  
7d3b7ed0 d0c2c2c4  
 
SO a d0d0 at the end of the first chip. 
 
or other events like: 
e57372fc 8911003f 013d023f 033b0438 053c063b 073a083e 09380a3a 0b380c3b  
0d380e28 0f3e1029 113b1238 13281439 153b163d 173b1828 19391a39 1b281c39  
1d2b1e3e 1f282038 213a223a 233a2428 2539263b 273f2829 29392a3e 2b282c3e  
2d3a2e39 2f3b3039 313b3239 333f3438 3538363b 37283839 393e3a3b 3b393c3a  
3d383e3a 3f394 
........................... 
85170036 01310232 03320433 053d0634 0735083d  
09330a35 0b330c35 0d300e34 0f321032 11321235 13311436 15361637 17321836  
19361a35 1b331c34 1d3c1e34 1f332031 21332235 23322431 25352634 27352834  
29352a32 2b322c33 2d362e34 2f333032 31103237 33373431 35103631 37363836  
39303a31 3b313c32 3d313e33 3f344032 41354236 43364437 45364631 47314837  
49344a37 4b374c31 4d324e33 4f325037 51345237 533c5434 5536563c 57355837  
59355a33 5b3c5c34 5d3c5e32 5f346034 613d6231 63306432 65366634 67356836  
 
LOOK AT THE NEXT 2 BYTES and what comes after them. 
 
696a3c6b 3f6c366d 246e326f 36703771 36723673 31743575 36763777 32783579  
357a327b 337c3c7d 357e347f 36841700 3c013402 3f033e04 37053506 3c073408  
34093c0a 340b340c 360d340e 360f3510 3c113412 38133414 36153e16 34173218  
3419341a 3c1b3c1c 3b1d351e 351f3420 3c213422 35233424 34253426 35273628  
3629362a 342b372c 3c2d332e 352f3230 34313532 34333134 36353236 36373638  
3c39363a 323b353c 343d343e 343f3240 34413442 36433c44 34453246 36473748  
3449344a 344b314c 344d324e 314f3650 31513552 34533254 37553456 32573258  
3759365a 355b345c 355d345e 345f3660 3c613462 31633164 34653466 33673d68  
39693c6a 356b3c6c 366d3f6e 366f3570 3d713572 3c733574 3d753a76 3e773a78  
3a79387a 3f7b3c7c 387d397e 297f2aa3 17002901 28022903 29042905 2a062907  
36082b09 2a0a2a0b 370c290d 2b0e290f 2a102811 29122913 2a142815 2a162917  
2b182a19 2a1a2a1b 291c2b1d 291e291f 29202921 2a222823 28242b25 29262927  
29282929 292a292b 2b2c292d 282e2b2f 28302931 29322b33 28342935 29362837  
29383639 283a293b 293c293d 2b3e293f 2e402841 29422943 29442845 28462947  
2b482949 284a294b 294c294d 284e294f 29502851 28522853 28542b55 29562857  
29582959 295a285b 285c285d 295e295f 29602861 29622863 29642b65 28662867  
2b682869 296a296b 286c296d 296e286f 29702a71 28722973 29742975 29762977  
2a782879 287a287b 2a7c287d 297e287f 28a21700 2e012d02 2d032e04 2e052f06  
2f072e08 2e092d0a 2e0b2a0c 2f0d2f0e 2c0f2e10 2e112d12 2f132d14 2f152c16  
2f172f18 2e192f1a 2f1b2e1c 2c1d2e1e 2f1f2f20 2d212e22 2e232d24 2e252f26  
2d272e28 2f292d2a 2d2b2c2c 2f2d2d2e 2d2f2e30 2d312d32 2d332d34 2d352f36  
2f372f38 2c392d3a 2c3b2e3c 2d3d2e3e 2f3f2c40 2e412d42 2d432f44 2d452f46  
2d472f48 2f492e4a 2d4b2d4c 2f4d2f4e 2c4f2f50 2c512f52 2e532f54 2e552e56  
2f572d58 2e592e5a 2e5b2f5c 2e5d2d5e 3c5f2d60 2e612e62 2f632d64 2e652d66  
2f672c68 2e692f6a 2e6b2d6c 2e6d2d6e 2d6f2e70 2e712e72 2d732e74 2f752e76  
2c772a78 2d792d7a 2f7b2d7c 2f7d2f7e 2a7f2aa1 17002a01 2f022f03 2f042e05  
2e062d07 2e082e09 2d0a2a0b 2e0c2e0d 2a0e2e0f 2e102a11 2c122d13 2e142a15  
2a162f17 2b182a19 2e1a2e1b 2a1c2a1d 2e1e291f 2d202a21 2a222e23 2b242b25  
2e262b27 2a282e29 2a2a2a2b 2a2c2a2d 2e2e2e2f 2a302a31 2e322e33 2a342a35  
2f362a37 2e382a39 2a3a2a3b 2e3c2e3d 2e3e2a3f 2e402a41 38422a43 2a442f45  
2d462e47 2e482e49 2e4a2e4b 2e4c2a4d 2a4e2b4f 2e502a51 2e522e53 2d542e55  
2a562e57 2a582e59 2e5a2d5b 2e5c2a5d 2e5e2e5f 2f602a61 2e622e63 2e642e65  
2f662e67 2a682e69 2f6a2e6b 2d6c2a6d 2a6e2e6f 2a702e71 2e722e73 2e742a75  
2e762e77 2a782a79 2e7a2a7b 2a7c2a7d 2a7e297f 2aa01700 2c012f02 24032e04  
2e052c06 2f072f08 2c092d0a 2d0b240c 2d0d2c0e 2e0f2c10 2c112d12 2e132d14  
2c152d16 2e172d18 2d192d1a 2d1b2d1c 2c1d2f1e 2c1f2f20 24212d22 2c232c24  
2d252d26 2f272d28 2f292e2a 2d2b2d2c 2c2d262e 2d2f2c30 2f312d32 2d332c34  
2f352c36 2c372f38 2e392c3a 2c3b2e3c 2d3d2d3e 2c3f2f40 2c412d42 2d432c44  
2d452f46 2e472f48 2e492f4a 244b2d4c 2c4d2f4e 2d4f2d50 2c512e52 2e532d54  
2d552c56 2d572d58 2c592d5a 2c5b2d5c 2d5d2d5e 245f2c60 24612d62 2e632d64  
2d652f66 2f672d68 2d692f6a 2d6b2d6c 246d2c6e 2d6f2d70 2d712f72 2f732f74  
2f752f76 2e772a78 2e792e7a 2d7b2f7c 2e3e7d28 7e2b7f3a 00760077 07780579  
057d0000 017c007d 037e007f 0000067b 00002200 00000000 000000c2 c2c40000 
 
 
Where at a certain point during readout the channel ID and the DATA get swapped as if a OBDV edge is not recognized by the FIB 
 
There are 2 solution to try: 
SWAP the RX 
INSTALL A SUPER-DUPER FIB. 
 
We will try with the next access 
 
</pre>
<!-- Author: Gino -->

<!-- Date: Thu Aug 1 10:16:59 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W7L3 
<li>problem n: 552 
<li>Status: needs_access_2hr
<li>Action: Removed_hdwdb
<li>entered by: bolla 
<li>description is: Here is a description of the <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=117&frame=2&anchor=10:13:19'> symptoms </a>  Needs a SUPERFIB or an RX swap. </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Aug 1 11:38:16 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W2All 
<li>problem n: 598 
<li>Status: needs_access_2hr
<li>Action: Diagnosis_update
<li>entered by: lmiller 
<li>description is: This wedge began giving problems between afternoon of July 8 and morning of July 9. This coincides with a lightning storm and beam dump. Needs command signal probing and possibly FIB swap. </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Aug 1 14:30:44 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W8L2 
<li>problem n: 502 
<li>Status: needs_bore_access
<li>Action: Diagnosis_update
<li>entered by: lmiller 
<li>description is: <b>Investigating history of OBDV for e382: </b> <ul> <li>Fine until 141621</li> <li>141621-142168 (3/25/02 - 3/31/02) Chip ID A2->22</li> <li>[3/31 has beam incident, DOIM currents on this wedge become  less stable after this]</li> <li>142202 (3/31/02) starts capid on 86, 85 and others.</li> <li>After a May 6 shot setup,  <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=109&frame=2&anchor=07:33:33'>software trip seen just before 144422</a> <li>144422-144455 (5/6/02) Drop readout at A0 starts and increases to 100%</li> <li>144456 c2c2 seen. OBDV not seen again</li> </ul>  </ul>
<!-- Author: Problem DB -->
<!-- Comment: Thu Aug  1 17;29;55 comment by...Gino -->
During run 144455 (The last one with some sign of life) There were <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2002&action=view&page=379&frame=2&anchor=01:17:10'>
CLOCK GLITCHES  </a> reported as well