<!-- Title: 22:21:06  Mon Jun 30 2003 -->
<!-- Crewchief: Julia -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>new week, new file</pre>


<!-- Date: Mon Jun 30 22:22:41 2003 -->
<pre>Lost the beam at ~6pm, silicon checked out ok. Waiting  
for collisions now.</pre>
<!-- Author: Julia -->


<!-- Date: Tue Jul 1 09:26:01 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2323&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2324  width='300' align='top'></td><td>run 165466</a></td></tr></table>
<!-- Author: julia -->

<!-- Date: Tue Jul 1 09:46:41 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W2L1 
<li>problem n: 229 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Diagnosis
<li>entered by: thom 
<li>description is: <pre>no data on all chips.</pre> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jul 1 09:46:41 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W2L1 
<li>problem n: 229 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Diagnosis
<li>entered by: thom 
<li>description is: <pre>no data on all chips.</pre> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Jul 1 12:56:05 2003 -->
<p>KC Cahill and Bill Noe rebuilt the SVX and ISL air separator vacuum pumps last week and put them online Thursday morning.  Overall system pressure is down by about 0.2 - 0.3 psi; this should provide enough breathing room for L00 to stay below the 13 psia warning level (i.e. turning yellow in iFix). 
</p><p> 
Vacuum pump rebuilds are a regular maintenance operation needed every six months or so.</p>
<!-- Author: Andy H. -->

<!-- Date: Tue Jul 1 13:17:16 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W10/11All 
<li>problem n: 1056 
<li>Status: fixed
<li>Type: Other
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: swapped FTM introduced no new problems.  fixed 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W10/11&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jul 1 13:23:29 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W3L0 
<li>problem n: 1027 
<li>Status: fixed
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: no problems seen in since last two monitoring times, considered fixed. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=L00&wedge=B0W3&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jul 1 13:35:56 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W8L4 
<li>problem n: 1050 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: low rate of error began again run 165198 with low rate.  Should continue to monitor. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W8&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jul 1 13:38:10 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W2L2 
<li>problem n: 613 
<li>Status: needs_observation
<li>Type: PC_Temperature
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: errors persist at low rate.  continue to monitor. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B4W2&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jul 1 17:33:55 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W0L0 
<li>problem n: 647 
<li>Status: needs_study_time
<li>Type: RX
<li>Action: Init_RB_mask
<li>entered by: nahn 
<li>description is: Failed Cold Start three times.  Currents look ok, suspect bit 3 again, but no run was taken to verify (End of Store). 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B5W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Jul 1 17:39:08 2003 -->
<pre>a cdf online disk crashed and we couldn't run the PSgui and imon for about an hour. Decided to keep the silicon on and watch the losses and cooling. Everything back to normal now. </pre>
<!-- Author: julia, SCN, Rainer -->


<!-- Date: Tue Jul 1 19:02:58 2003 -->
<pre>After repair of b0dap30 disk needed to reboot our machine. 
imon, psgui, svxinter vxlogin session restarted.</pre>
<!-- Author: rainer -->


<!-- Date: Tue Jul 1 19:07:18 2003 -->
trying to use quiet time to measure noise/depletion voltage decrease. however, can't get svxdaq to run. give similar symptoms 
with erronenous FIB channels which are not there etc. as seen 
earlier  (see <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=160&frame=2&anchor=23:06:18'> 
 access report. </a>) Lester/Steve prescription failed (namely to  
vxlogin into and killAll processes in offending VRB crate which might interfere 
with svxdaq). seems like failure is connected to load, i.e. including more HDIs helps cure the problem but still no systematic understanding. 
<!-- Author: Gino, Rainer -->


<!-- Date: Tue Jul 1 19:08:22 2003 -->
<pre>pre-Access svxdaq test for IB2W1L0  and IB0W2L1: 
IB2W1L0:(together w/f214) 
R 4501 E 206 Error: OO Sequence      Fib 0 Pipe 5 Chip 1: .. 117, 112 .. 
R 4501 E 206 Error: OO Sequence      Fib 0 Pipe 5 Chip 1: .. 113, 97 .. 
R 4501 E 206 Error: OO Sequence      Fib 0 Pipe 5 Chip 1: .. 125, 119 .. 
R 4501 E 206 Error: CAP ID           F 0 P 5 C 1 = 8 F 0 P 5 C 2 = 9 
R 4501 E 206 Error: OO Sequence      Fib 0 Pipe 5 Chip 2: .. 109, 3 .. 
R 4501 E 206 Error: CAP ID           F 0 P 5 C 2 = 9 F 0 P 5 C 3 = 15 
R 4501 E 206 Error: OO Sequence      Fib 0 Pipe 5 Chip 3: .. 109, 15 .. 
R 4501 E 206 Error: CAP ID           F 0 P 5 C 3 = 15 F 0 P 9 C 0 = 0 
R 4501 E 206 Error: CAP ID           F 0 P 9 C 12 = 0 F 0 P 5 C 0 = 15 
 
IB02W2L1: (together w/f034) 
 
R 4503 E 97 Error: CAP ID           F 0 P 1 C 0 = 29 F 0 P 1 C 1 = 250 
R 4503 E 97 Error: CAP ID           F 0 P 1 C 1 = 250 F 0 P 1 C 2 = 255 
R 4503 E 97 Error: CAP ID           F 0 P 1 C 2 = 255 F 0 P 1 C 3 = 254 
R 4503 E 97 Error: CAP ID           F 0 P 1 C 3 = 254 F 0 P 1 C 4 = 245 
R 4503 E 97 Error: CAP ID           F 0 P 1 C 4 = 245 F 0 P 1 C 5 = 254 
R 4503 E 97 Error: CAP ID           F 0 P 1 C 5 = 254 F 0 P 1 C 6 = 253 
R 4503 E 97 Error: CAP ID           F 0 P 1 C 6 = 253 F 0 P 1 C 7 = 248 
R 4503 E 97 Error: CAP ID           F 0 P 1 C 7 = 248 F 0 P 1 C 8 = 244 
R 4503 E 97 Error: CAP ID           F 0 P 1 C 8 = 244 F 0 P 1 C 9 = 250 
R 4504 E 14 Error: Too Many Chips   20 Fib # 0 Pipe # 1 
R 4504 E 14 Error: No EOR           Fib 0 Pipe 1 
R 4504 E 14 Error: CAP ID           F 0 P 1 C 19 = 190 F 0 P 9 C 0 = 8 
</pre>
<!-- Author: Rainer -->
<!-- Comment: Tue Jul  1 19;09;44 comment by...Rainer -->
needed to run with 2nd ladder in order to avoid BC/illegal fib ID
cazzo crap. <p>
b0svx06 and b0svx02 were rebooted and a local coldstart performed.


<!-- Date: Wed Jul 2 11:37:42 2003 -->
<pre>Single ploss spike set of the Tevmon alarm. 
Nothing going on with the machine though (D0 put in their roman pots..) </pre>
<!-- Author: julia -->


<!-- Date: Wed Jul 2 11:45:00 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2325&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2326  width='300' align='top'></td><td>.</a></td></tr></table>
<!-- Author: julia -->
<!-- Comment: Wed Jul  2 11;45;51 comment by...julia -->
<pre>run 165523</pre>

<!-- Date: Wed Jul 2 14:20:00 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W2L1 
<li>problem n: 229 
<li>Status: needs_access
<li>Type: Unknown
<li>Action: Diagnosis
<li>entered by: thom 
<li>description is: <pre>bit 7 stuck high</pre> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jul 2 18:10:27 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W2L1 
<li>problem n: 229 
<li>Status: needs_observation
<li>Type: RX
<li>Action: Swap_RX
<li>entered by: rainer 
<li>description is: RX swapped. Post-Access Test successful.<table border=1>
<tr><td><b>IN:</b></td><td><a href="http://nkek15.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0734">0734</a></td></tr>
<tr><td><b>OUT:</b></td><td><a href="http://nkek15.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0838">0838</a></td></tr></table> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jul 2 18:16:40 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W3L0 
<li>problem n: 592 
<li>Status: needs_observation
<li>Type: RX
<li>Action: Swap_RX
<li>entered by: rainer 
<li>description is: introduced a bit2 error when swapping RXes in same FTM. after swapping this RX, problem disappeared. keep an eye on it.<table border=1>
<tr><td><b>IN:</b></td><td><a href="http://nkek15.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0431">0431</a></td></tr>
<tr><td><b>OUT:</b></td><td><a href="http://nkek15.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0706">0706</a></td></tr></table> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W3&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jul 2 18:18:31 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W1L0 
<li>problem n: 1073 
<li>Status: needs_observation
<li>Type: RX
<li>Action: Swap_RX
<li>entered by: rainer 
<li>description is: post access test after RX swap successful<table border=1>
<tr><td><b>IN:</b></td><td><a href="http://nkek15.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0362">0362</a></td></tr>
<tr><td><b>OUT:</b></td><td><a href="http://nkek15.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0652">0652</a></td></tr></table> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B2W1&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Jul 2 18:40:16 2003 -->
<b> Silicon Access Report </b><p> 
 
we swapped RXes for  
<a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=161&frame=2&anchor=18:10:27'> 
IB0W2L1 </a> (b0fib01/SWT slot#9 channel#1), <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=161&frame=2&anchor=18:18:31'> 
IB2W1L0 </a> (slot#12 channel#5) and tested successful. As fallout, I (RSW) produced bit error in  
 
<a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=161&frame=2&anchor=18:16:40'> 
IB0W3L0 </a> (slot#9 channel #5) which got fixed with another RX swap. Hopefully I screwed up somehow because the latter was already a gold-plated RX. Remains to be seen in RX test. <p> 
We also exchanged all fuses in b0fib01/SWT with 7 amps fuses. We had a look at <a href=' http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W1&layer=L2'> SB2W1L2 </a> and saw problem stay with the readout channel, so a  future RX swap might be warranted.
<!-- Author: Julia, Rainer, SCN -->
<!-- Comment: Wed Jul  2 18;43;11 comment by...Rainer  -->
BTW had severe problems with molto cazzo FIB id/VRB screwup stuff which went away with choosing lower readout frequency. Needs further understanding.
<!-- Date: Wed Jul 2 18:41:18 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W1L2 
<li>problem n: 928 
<li>Status: needs_access
<li>Type: RX
<li>Action: Diagnosis_update
<li>entered by: rainer 
<li>description is: during last access swapped DOIMs and saw problem stay with readout channel. so text time, try an RX swap 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Jul 2 18:51:24 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W1L0 
<li>problem n: 1073 
<li>Status: needs_observation
<li>Type: RX
<li>Action: Swap_RX
<li>entered by: rainer 
<li>description is: above was a typo. the real swap was 0362 in 0562 out.<table border=1>
<tr><td><b>IN:</b></td><td><a href="http://nkek15.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0362">0362</a></td></tr>
<tr><td><b>OUT:</b></td><td><a href="http://nkek15.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0562">0562</a></td></tr></table> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B2W1&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Jul 2 21:01:57 2003 -->
<pre>Took some data with svxdaq with SB2W2/3. 
I took normal data and charge injection as well. 
I varied the Bandwidth and also the ISEL bits to figure out 
what is the lowest S/N achievable without changing the 
bias voltage. 
I have all data to tape and I have to crunch them.  
Not yet results but I'm working on it. 
</pre>
<!-- Author: Gino -->
<!-- Comment: Sat Jul  5 10;02;43 comment by...Gino -->
<pre>Taken even more data with different settings. More data to look at.</pre>
<!-- Date: Wed Jul 2 21:04:59 2003 -->
<pre>Julia informed me there is going to be a BIAS SCAN tonight. 
There is no beam and I do not know what trigger table you are 
going to use. I'm a bit afraid of going too fast (resonances) so I asked the SCICO to keep the MAGNET OFF during these tests. This should NOT imply any problem. 
Please contact me if you have any question.</pre>
<!-- Author: Gino -->
<!-- Comment: Thu Jul  3 07;40;29 comment by...SCN -->
This was a bias scan for noise, something Steve Worm told
me may be useful, and something I thought we should do again
because we have the opportunity and it cannot hurt.
Bias Scans go at Pedestal Run rates I believe, something like
10 Hz.  No need to turn off the magnet.
<!-- Date: Wed Jul 2 22:46:29 2003 -->
<b>Bias Scan</b> <br> 
Run #165573 <br> 
 
<TABLE bgcolor=#cdc9a5> 
<TR><TH>Delta-V</th><th>Start Evt</th><th>End Evt</th></tr> 
<tr><td>  0</td><td>    0</td><td> 1204</td></tr> 
<tr><td> -3</td><td> 1229</td><td> 2423</td></tr> 
<tr><td> -6</td><td> 2436</td><td> 3612</td></tr> 
<tr><td>-11</td><td> 3626</td><td> 4964</td></tr> 
<tr><td>-16</td><td> 5002</td><td> 6282</td></tr> 
<tr><td>-21</td><td> 6311</td><td> 7496</td></tr> 
<tr><td>-26</td><td> 7521</td><td> 8881</td></tr> 
<tr><td>-31</td><td> 8893</td><td>10150</td></tr> 
<tr><td>-36</td><td>10159</td><td>11620</td></tr> 
<tr><td>-41</td><td>11641</td><td>12817</td></tr> 
</TABLE> 
 
These files can be found in the look area. 
  
<!-- Author: Pete and David -->


<!-- Date: Thu Jul 3 01:26:56 2003 -->
<pre>shift crew tried to take cosmics data, red b0svx08 and a bunch of pink DVDD cells (across the board for SVX) 
Told them to unmark the cells, meanwhile B0svx08 turned green and they started the run.  
Don't expect collisions until evening shift....</pre>
<!-- Author: Julia -->


<!-- Date: Thu Jul 3 08:33:31 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W0L0 
<li>problem n: 636 
<li>Status: fixed
<li>Type: RX
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: No problems since swap--fixed. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jul 3 08:35:36 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W0L3 
<li>problem n: 829 
<li>Status: fixed
<li>Type: RX
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: no problems post-swap.  fixed. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W0&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Jul 3 11:43:29 2003 -->
<table><tr><td><a href=/elog/notebooks/silicon/Thu_Jul__3_2003_114324.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2328  align='top'></td><td>53 Mhz signals from new PCC fanouts on 1st floor</a></td></tr></table>
<!-- Author: SCN -->
<!-- Comment: Thu Jul  3 11;56;32 comment by...SCN -->
Steve Chappa wants us to move our 53 MHz signal from an old fanout module to new ones.  He has 4 53 MHz spigots (we need 3, 1 for each SRC plus one for the test SRC).  I used the lower spigot
of the current fanout (which was driving the 2nd SRC) to compare
against the other 4, while triggering on the 53 KHz input to 
the whole crate.  The real SRC 53 and 2nd SRC signals have been
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=155&frame=2&anchor=13:09:09'>compared previously</a> so this should be sufficient to convince us that 
this signal will be ok.  What you see above <ul>
<li> Top trace is 2nd spigot of old fanout 53 Mhz
<li> 4 overlapping traces are the 4 53 Mhz signals from the new ones.  To put them where they are I maxed out the delay setting (value of 0xf) and bumped the vernier to the right.
<li> Bottom trace is 53 Mhz out of the diagnostic port of the Clock Crate Fanin
</ul>
You'll notice that the new signals are all within a nanosec of each other and the falling edge is nicley aligned with an ols signal.  The duty cycle of the new signals is better (like 47% rather than 35%) although in the previous comparison the 
reference one used here was a bit smaller than the real one.<BR>
The upshot is that the next time we turn the Silicon off, we should move to the new fanout modules (I already put the 2nd SRC and the test SRC there) and give Steve Chappa his old one back.


<!-- Date: Thu Jul 3 12:28:00 2003 -->
<table><tr><td><a href=/elog/notebooks/silicon/Thu_Jul__3_2003_122734.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2332  align='top'></td><td><h3>Distribution of Synchronous Readout Kicks</h3> Gino made the following notes <ul> <li> started at 10:00 am with RUN # 165466 <li> Luminosity 14.0 at the beginning <li> All L1 prescale to 1 <li> Trigger rate around 10.0 KHz (time 3000 seconds) <li> Run Ended at 11:30 about 9 KHz </ul> </a></td></tr></table>
<!-- Author: SCN -->
<!-- Comment: Thu Jul  3 14;02;44 comment by...SCN -->
Gino also made a table with some measurements.  The above plot has
the "End of Store" numbers
<table> <tr> <th> Range <th> Meaning <th># @10:20 <th> # @11:29 <th>End of Store </tr> <tr> <td> 0 <td>3 kicks <td> 209600 <td>    842000  <td> 866.5 k </tr> <tr> <td> 1 <td> 4 kicks  <td>    27888  <td>  106800 <td> 98.43 k </tr> <tr> <td>2 <td> 5 kicks    <td>  4570    <td> 16875  <td> 14108 </tr> <tr> <td>3 <td> 6 kicks    <td>    793   <td>   2700 <td> 2002 </tr> <tr> <td>4 <td> 7 kicks    <td>  140     <td>  457  <td> 348 </tr> <tr> <td>5 <td> 8 kicks    <td>   23      <td>  80  <td> 57 </tr> <tr> <td>6 <td> 9 kicks    <td>    5       <td> 14  <td> 14 </tr> <tr> <td>7 <td> 10 kicks   <td>     0     <td>   4  <td> 4 </tr> <tr> <td>8 <td> 11 kicks   <td>     0      <td>  1  <td> 0 </tr> <tr> <td>9 <td> 12 kicks    <td>    0       <td> 2  <td> 0 </tr> <tr> <td>A <td> 13 kicks    <td>      0 <td> 0 <td> 0  </tr> <tr> <td>B <td> 14 kicks    <td>      0 <td> 0 <td> 0 </tr> </table> I think Gino probably reset the counters after his run ended, which may be why the End of Store numbers may be less.  Probably the End of Store numbers  also reflect lower L1A rates due to lower luminosity. 

<!-- Date: Thu Jul 3 15:29:31 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W2L1 
<li>problem n: 784 
<li>Status: needs_work
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: bit 0 error rate has jumped over 10% 5 times since 6/22.  there is a significant increase in frequency and rate of the errors. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Jul 3 16:05:05 2003 -->
<h3>Some VRB weirdness (the Europeans say something like <i>cazzo</i>?) investigation</h3> 
I played around with the VRBs trying to get it to reproduce  
errors seen lately in access testing.  The problem is basically 
that the VRB puts two headers into its output fifo, skips some 
data, and adds some crap.  Once the fifo is screwed up, it can 
only be fixed by a HRR.  I found that it is firmware dependent - I could reproduce the problem reliably running both SB2W2L0 and L1, but not running either one singly, and if I include L4, the problem vanishes.  Furthermore, if I chop the number of Chips for 
L4 down by 2 the problem reappears.  Finally, I can get around the problem by <ul> 
<li> Including a layer from a different Fib 
<li> Setting the wrong Last Chip ID and Disabling the NO DATA timeout for that channel (from the Fib expert menu) 
<li> Slowing down how fast I read out the VRBs. 
</ul> 
I have forwarded this on to Mark Bowden, we'll think about it  
for the weekend and try to reproduce it on the bench next week. 
(if we have a WiB which can give us 4 chips on one ladder, and 6 on another...)
<!-- Author: SCN -->


<!-- Date: Thu Jul 3 17:23:28 2003 -->
<table><tr><td><a href=/elog/notebooks/silicon/Thu_Jul__3_2003_172319.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2334  align='top'></td><td>The Cause of the VRB <i>cazzo</i> is that the SRC is not waiting long enough for the VRB to raise its SCANBUSY flag before sending it another L2A.  Here there are two L2A (CMD 5, they X and 0 markers) which are only 1.78 uS apart.  Either the SRC has to wait for SCAN even longer, or the VRB has to not try to process the 2nd L2A.  This is only recently a problem because of the new firmware which drops READBUSY earlier, which changes this timing a bit. are </a></td></tr></table>
<!-- Author: SCN -->


<!-- Date: Fri Jul 4 21:43:52 2003 -->
<pre>Integrated SVX dose alarm goes off during shot setup 
(huge losses, see CDF e-log). We call the RDCO pager carrier, who says that this is known to happen sometimes, as long as Silicon is in STBY it's ok.</pre>
<!-- Author: julia -->
<!-- Comment: Sat Jul  5 15;44;06 comment by...Andy H. -->
I didn't say that.  I think this is the first time we've ever had an integrated dose alarm during shot setup.  About the only thing one can do, however, is call MCR and tell them to be careful.  As long as it doesn't happen over and over, yuo can probably write it off as a one-time "oops."
<!-- Date: Sat Jul 5 02:11:55 2003 -->
<pre>several pinkies in ISL and L00 when trying to  
take cosmics (AVDD and DVDD step up). One L00 trip 
which is recovered right away. Silicon  
taken back to STBY because protons are being  
injected. Next collisions sometime tomorrow morning, so  
I'll come in in the morning to take care of the  
pinkies.</pre>
<!-- Author: julia -->


<!-- Date: Sat Jul 5 08:23:02 2003 -->
<pre>Gino fixed the pinkies with a coldstart. 
It's strange that this didn't succeed 
yesterday night, we tried the same thing 
(I pointed the ace to the post-quench-checkout 
web site, they did the coldstart and it didn't remove the pinkies. Maybe they didn't go through with it?)</pre>
<!-- Author: Julia -->
<!-- Comment: Sun Jul  6 00;07;34 comment by...Sunny/Mauro -->
<pre>Yes, we did it according to the web and phone instruction. </pre>


<!-- Date: Sun Jul 6 04:14:39 2003 -->
<pre>AVDD/DVDD O/C trip of B4W9L4. This layer has a history  
of AVDD O/C trips. On the third try we manage to turn 
it back to STBY. Running a coldstart removes all pinkies 
on wedge B4W9.</pre>
<!-- Author: julia -->
<!-- Comment: Sun Jul  6 04;17;41 comment by...julia -->
<pre>trip happened during the storm, related? </pre>


<!-- Date: Sun Jul 6 17:00:45 2003 -->
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=561&frame=2&anchor=16:46:57.569'> 
Pressed reset button on CAEN crate 5's V288 module to see what happens.</a>   
<!-- Author: Andy H. -->

<!-- Date: Mon Jul 7 03:25:36 2003 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 273
Calibration type  : standard
Run period tag    : Jul_2003
DPS-off run       : 165828
DPS-on run        : 165827
Requested by      : Jason Galyardt
Main process id   : 43328066
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Mon Jul 7 04:11:08 2003 -->
<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 273 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 165828
DPS-on run       : 165827
Requested by     : Jason Galyardt
Submitted        : 2003-07-07 01:23:53
Completed        : 2003-07-07 02:10:09
Status           : FAILURE

Last processing stage reported : checking silicon configuration
Failure diagnostics :
error {There is an error in the biasInfo file for run 165828}
Exiting.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->


<!-- Date: Mon Jul 7 04:50:44 2003 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 274
Calibration type  : standard
Run period tag    : Jul_2003
DPS-off run       : 165831
DPS-on run        : 165830
Requested by      : Jason Galyardt
Main process id   : 44414560
Comment           : Si biased for ~50min before calib.
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Mon Jul 7 05:38:06 2003 -->
<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 274 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 165831
DPS-on run       : 165830
Requested by     : Jason Galyardt
Submitted        : 2003-07-07 02:50:34
Completed        : 2003-07-07 03:36:48
Status           : FAILURE
Comment          : Si biased for ~50min before calib.

Last processing stage reported : checking silicon configuration
Failure diagnostics :
error {There is an error in the biasInfo file for run 165831}
Exiting.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->