<!-- Title: 10:20:48  Mon Dec  6 2004 -->
<!-- Crewchief: Jared -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>First collisions expected Tues. Dec. 7. Pending requests to ops. are 6 hr quiet time for check out and ~2 hr access for crowbar work.</pre>


<!-- Date: Mon Dec 6 11:57:31 2004 -->
<table border=0><td><tr><td bgcolor=#e0e030><h1> SILICON DAQ must not be used at the moment !!!! </h1></td></tr></td></table>
<!-- Author: Riggs & Murtaugh  -->


<!-- Date: Mon Dec 6 13:55:46 2004 -->
<table border=0><td><tr><td bgcolor=#e0e030><b>Silicon DAQ now ready for use</b></td></tr></td></table>
<!-- Author: Marcel/Sebastian -->

<!-- Date: Tue Dec 7 09:26:13 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W3L4 
<li>problem n: 1053 
<li>Status: needs_work
<li>Type: Other
<li>Action: Diagnosis_update
<li>entered by: rong 
<li>description is: Data truncated during chip 87 readout and confirmed by Svxdaq. Rdrivers has been set to 7 already. any idea? 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W3&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Dec 7 09:30:36 2004 -->
SB0W3L4 (e034) shows c2c2 in the latest calibration data (readall mode)<br>  
<pre> 
-------------------- 
e03403fc ............. 
774d7851 79517a4e 7b4e7c56 7d4d7e51 7f51871b 00580162 02610358 0461055c  
065c0763 0861095c 0a5c0b5c 0c610d61 0e610f61 105c115c 12611361 14611558  
165c1761 1863c2c2    
-------------------- 
</pre> 
It's fine with NN mode. z-side has been chopped with bits set to zero.
<!-- Author: Rong-Shyang -->
<!-- Comment: Tue Dec  7 09;31;47 comment by...Rong-Shyang -->
<pre>Also ladder has CAPID error for a long time. Chaning ISEL bits has no effect.</pre>

<!-- Date: Tue Dec 7 09:43:27 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L4 
<li>problem n: 1287 
<li>Status: unfixable
<li>Type: DVDD
<li>Action: Diagnosis_update
<li>entered by: rong 
<li>description is: Still no DVDD current.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Dec 7 09:51:28 2004 -->
<pre>SB5W6L4 should be tried again and see if chaning Rdriver reduce the error rate especially on bit 7. If so, change the hardware database setting.</pre>
<!-- Author: Rong-Shyang -->


<!-- Date: Tue Dec 7 12:18:01 2004 -->
Tevatron tried shot this morning and accumulated around 7,500E9 proton in the ring. But when they switch to Pbar shot, beam was aborted by D0 BLM, <a href=http://www-bd.fnal.gov/cgi-mcr/elog.pl?nb=2004&action=view&page=927&anchor=114226&hilite=11:42:26- target=_top>MCR elog</a>. Our BLMs didn't lanch any entry on E2 ACNET and the plot shows nothing during abort, <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=848&frame=2&anchor=12:05:38.628'> 
shift elog</a>. 
<!-- Author: Rong-Shyang -->
<!-- Comment: Tue Dec  7 12;21;00 comment by...Rong-Shyang -->
<br>
<a href=/cgi/elog/elog.pl?nb=2004&action=view&page=-12180&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2004&action=view&page=-12180 width='300' align='top'></a><br>
Having a plot here looks better?


<!-- Date: Tue Dec 7 12:26:09 2004 -->
<br><b>MCLK tests</b><br> 
Yesterday we tested agian the MCLK (1.14) firmware:<br> 
<ul> 
<li> Dopey (on teststand): can sync FFO GL? Yes, can see FFO returns? No, can see keepalives?   
<li> On SVX: can sync FFO? Yes, can see FFO returns? No, can see 
keepalives? Yes, do we see the L1A in the blinky board if we hook 
up the teststand FFO? Yes 
</ul> 
So, is it only the FFO return that we are missing? The GL sync signals with MC1.14 are the same than with the  
previous firmware (in SVX, Dopey's J11 is not working).<br>
<!-- Author: Marcel/Sebastian -->
<!-- Comment: Tue Dec  7 12;27;09 comment by...s -->
<pre>Dopey, can see keepalives? Yes</pre>


<!-- Date: Tue Dec 7 12:47:12 2004 -->
<b>We have installed a flux compensator in the forward nacelles of b0svx06 ... </b><br> 
<p> 
In other words, in order to be prepared for the VRB dummy installation in b0svx06 we have unsplit the L00/SVT splitter and installed a splitter in b0svx06. This one is splitting the fibers from f840/f850.<p/>   
<p> 
Why are we doing this ? <br> 
In order to prepare for the VRB load balancing attempt, we probably need another VRB in SVX06. We can't do that, if the ISL/L00  is powered, so we are going to to this at the earliest convenience. The VRB will be not connected to anything, but it gets unhappy, if it sees no light on the VTM (may cause noise on the Backplane...). So we have to give him some light ... that is why we need the splitter. If we have the VRB installed, we can move fibers, whenever we please. We rather prefer not to rearrange all the fibers now, since a) it is not really urgent and b) we don't want to change too many things at once.  
</p>
<!-- Author: SCN, Marcel -->


<!-- Date: Tue Dec 7 15:05:01 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5422&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5422  width='300' align='top'></a></td><td>svrad plots for today, from 11 am.</td></tr></table>
<!-- Author: Jason Galyardt -->


<!-- Date: Tue Dec 7 15:28:54 2004 -->
Got the collision<br> 
<pre> 
Store 3821 
6250 E9 protons 
 338 E9 antiprotons 
10.25E30 initial instantaneous luminosity 
</pre>
<!-- Author: Rong-Shyang -->
<!-- Comment: Tue Dec  7 16;08;04 comment by...Rong-Shyang -->
<pre>MCR plans to have store lasting till 9am tomorrow.
If the store falls off earlier, we may get quiet time, but not sure how much.</pre>
<!-- Date: Tue Dec 7 15:43:05 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5423&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5423  width='300' align='top'></a></td><td>ACNET plot for loss and abort gap</td></tr></table>
<!-- Author: Rong-Shyang -->
<!-- Comment: Tue Dec  7 15;46;39 comment by...Rong-Shyang -->
<pre>LostP and LostPB are quiet. B0PAGC is just above limit (25KHz). B0AAGC is too high (used to be way lower than B0PAGC). AGIGI2 is ok  but SLPAH[37] doesn't make any sense. But we don't know if even AGIGI2 has been calibrated.
</pre>

<!-- Comment: Tue Dec  7 16;04;14 comment by...corrinne -->
B0AAGC is on a scale twice as big as B0PAGC, so it is actually way lower than B0PAGC, as it should be.  


<!-- Comment: Tue Dec  7 16;09;44 comment by...Rong-Shyang -->
<pre>?? B0AAGC is at 43KHz and B0PAGC is 27KHz.</pre>


<!-- Comment: Wed Dec  8 09;30;37 comment by...c -->
Sorry, you're right.  That is wierd.
<!-- Comment: Wed Dec  8 14;54;51 comment by...Rong-Shyang -->
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=851&frame=2&anchor=09:01:50.383'>
Rick's message</a> on abort gap loss measurment. It might not make sense on those numbers.

<!-- Date: Tue Dec 7 17:58:00 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Tue_Dec__7_2004_175754.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5425  align='top'></a></td><td>VME signals</td></tr></table>
<!-- Author: Sebastian -->
<!-- Comment: Tue Dec  7 18;14;41 comment by...Sebastian -->
<br><b>Testing Dopey</b><br>
Dopey has a two signals driving the same line (DS0 and
NAND(~DS0,~DS1) both drive LADDR). So if DS0=0 and DS1=1
a race condition occurs. Tried the SRC in different configurations
and modes (running with all L2Rs, Run DAQ, TSI emulator)
but did not get a DS0=0, DS1=1.
The SRC does D32:A32 VME mode so it is expected that 
one would get the plot above (DS0=DS1=LWORD=1). <br>
Also tried to reproduce the L2 w/o L1 by forcing the
error and then doing the HRR by VME, as Steve reported that
he could increase the error count back in 7/15/04, however
as we saw then, I could not reproduce the situation in the
teststand.<br>
 


<!-- Comment: Tue Dec  7 22;19;31 comment by...Grumpy -->
AFAIK, To drive this, you need a 64 Bit VME access, as e.g. done if you touch a VRB ...
<!-- Date: Tue Dec 7 20:44:49 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5427&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5427  width='300' align='top'></a></td><td>BLM Rad summary plot during quench.</td></tr></table>
<!-- Author: Jared and Rong -->


<!-- Date: Tue Dec 7 20:52:21 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Tue_Dec__7_2004_205210.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5436  align='top'></a></td><td>SB5W6L4</td></tr></table>
<!-- Author: Jared -->
<!-- Comment: Tue Dec  7 20;55;13 comment by...Jared -->
<pre>SB5W6L4 (e564) ran fine (no errors) in svxdaq with out changing parameters.  Change to monitoring group.</pre>


<!-- Date: Tue Dec 7 20:58:16 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5437&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5437  width='300' align='top'></a></td><td>Try again BLM summary plot</td></tr></table>
<!-- Author: Rong-Shyang  -->
<!-- Comment: Tue Dec  7 21;00;33 comment by...Rong -->
From <a href=http://www-bd.fnal.gov/cgi-mcr/elog.pl?nb=2004&action=view&page=928&anchor=184444&hilite=18:44:44- target=_top>MCR elog</a>, E1 quench.

<!-- Date: Tue Dec 7 21:02:50 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W6L4 
<li>problem n: 345 
<li>Status: needs_observation
<li>Type: TX
<li>Action: Diagnosis_update
<li>entered by: yamaoka 
<li>description is: Ran with svxdaq without any errors.   See<a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=226&frame=2&anchor=20:52:21'>e-log. </a>  Move to monitoring group.   
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W6&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Dec 7 21:33:57 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L0 
<li>problem n: 1231 
<li>Status: needs_observation
<li>Type: DRO_00F3
<li>Action: Incident
<li>entered by: yamaoka 
<li>description is: Changed ISEL bits and Rdriver, but they were no help.  Maybe it just needs some time and will fix itself like before.   
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Dec 7 23:11:42 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W4L0 
<li>problem n: 1120 
<li>Status: needs_observation
<li>Type: DRO_00F3
<li>Action: Diagnosis_update
<li>entered by: yamaoka 
<li>description is: Sparsed out first four and last four chips, and changed the Bias ratio to 1. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W4&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Dec 7 23:13:34 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W10L4 
<li>problem n: 603 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: yamaoka 
<li>description is: Sparsed out chip 88.  Moved to monitoring. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W10&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Dec 7 23:21:18 2004 -->
<br> 
e1a4: Sparsed out chip 88.  See previous <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=203&frame=2&anchor=12:13:28'> 
elog </a> entry. 
<br> 
<br> 
f040: Sparsed out first 4 and last 4 chips.  Changed bias ratio to 1.  See previous <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=210&frame=2&anchor=09:05:09'> 
elog </a> entry. 
<br> 
<br>
<!-- Author: Jared -->


<!-- Date: Wed Dec 8 08:31:15 2004 -->
<pre>Probable TeV Access Tomorrow: for 4 hours during the day shift.  Right now it hasn't been deceided if CDF will have an access.  We will have 4 hrs of quiet time.   </pre>
<!-- Author: Jared  -->




<!-- Date: Wed Dec 8 15:01:50 2004 -->
<pre> 
Store 3824  
initial luminosity 48E30  
6700 E9 protons  
 654 E9 pbars  
LOSTP 3.0 kHz  
LOSTPB 1.2 kHz  
This is really too good to be true...  from shift elog 
</pre>
<!-- Author: Rong -->


<!-- Date: Wed Dec 8 15:16:13 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5440&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5440  width='300' align='top'></a></td><td>Losses plot</td></tr></table>
<!-- Author: Rong-Shyang -->


<!-- Date: Wed Dec 8 15:24:58 2004 -->
<h3> Check-out Plan </h3> 
During the access / quiet time tomorrow morning, we will have system up, running, and taking D-mode calibration data. 
If we finish above and still have more than 2 hours quiet time, Ben will come in for bias scan. 
The other thing is that Calorimeter people will have access in parallel so their crates are not available providing cosmic trigger. The alternative way is using trigger group's Sparky (noisemaker) which provides random trigger for us. We can tune the rate down to 100 Hz before we have the silicon involved. So 
<li> Jared, Rong, and Marcle or Sebastian should coming first and have system up following the recovery procedure. 
<li> At the same time, Chen-Ju will help to setup the trigger scheme for us. 
<li> Run the random trigger and look at the SVXMon. 
<li> Take the D-Mode data 
<li> Do bias scan if we have 2+ hours available. 
  
<!-- Author: Rong-Shyang -->
<!-- Comment: Wed Dec  8 16;05;39 comment by...Rong-Shyang -->
<p><b>Update</b></p>
Had discussion with Jonathan. He suggests we run the zerobias_90Hz trigger table with silicon then no body has to do any change or setup. L2 is auto-pass and L3 will give output to StreamI which is okay for cosmic setting on SVXMon.


<!-- Comment: Wed Dec  8 16;33;21 comment by...Rong-Shyang -->
<p><b>Correction on Update</b></p>
After consulting with Steve, we decide not to use the syncronized zerobias_90Hz. Even we think that it's way too slow but it still has potential breaking bonds. So we will still try to use Sparky with low rate ~100Hz tomorrow. Cheng-Ju will come and set it up.

<!-- Date: Wed Dec 8 16:11:42 2004 -->
Upon Rong-Shong's request, I changed the low warning/alarm limits of L00WSUP from 2.7/2.5 to 2.6/2.4.  It has been hovering around 2.7 since the beginning of the month, after Andy and I turned off the cooling to install the new PLC cards for the new SVXIICON PC.
<!-- Author: Eva H. -->
<!-- Comment: Wed Dec  8 17;08;44 comment by...Eva -->
<pre>Sorry, I spelled your name wrong Rong-Shyang!</pre>

<!-- Comment: Wed Dec  8 20;04;56 comment by...Rong-Shyang -->
<pre>That is okay, I forgive you. :)</pre>


<!-- Date: Thu Dec 9 04:24:23 2004 -->
<pre>Ran two SVX guinea pigs, e0b1 and e481, and SOC to get prepared for system check-out. Also have run coldstart with them. We should be ready to go anytime later. 
One thing I notice is that I hit the ghostbuster break at 11th event running SVX ladder but at 8th event on ISL ladder. It was set to be like that intentionally?</pre>
<!-- Author: Rong-Shyang -->
<!-- Comment: Thu Dec  9 10;15;26 comment by...Grumpy -->
The event count in RunDAQ does not necessarily reflect the number of L1A the SRC has sent.

<!-- Date: Thu Dec 9 10:14:43 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5441&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5441' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5442&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5442' width='300'></a></center>
<!-- Author: The Silies -->
<!-- Comment: Thu Dec  9 10;22;08 comment by...The Sillies -->
<h2>SVXMON during the checkout ... </h2>
Problems so far:
<ul>
<li> e1a4  has no data </li>
<li> IB1W4L1 Z side some data missing</li>
</ul>
<!-- Date: Thu Dec 9 10:20:06 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5443&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5443' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5444&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5444' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5445&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5445' width='300'></a></center>
<!-- Author: Jared -->
<!-- Comment: Thu Dec  9 10;21;06 comment by...Jared -->
<pre>IMON plots from today's start up.</pre>


<!-- Comment: Fri Dec 10 11;36;41 comment by...Jared,Marcel and Rong -->
<pre>We also raised the lower bond for bias current on SVX and ISL to 1.0 with variance 0.5. Several ladders show pinky after that and was recored and adjusted back to 0.0 +- 0.5. Needs to check the history for more detail later</pre>
<!-- Comment: Fri Dec 10 11;53;45 comment by...Jared, and Rong -->
<p>The pinky cells on above plots : <p>
<b>SVX - </b><br> 
<li>SB4W10L2  AVDD drop 400mA when run started, back to normal after reconfig.
<li>SB0W7L4  AVDD at 885mA with IMon setting at (920, 1100)
<li>SB0W0L2  AVDD at 775mA with IMon setting at (780,810)
--------- not shown above
<li>SB1W2L4  AVDD 1100mA while IMon(1065, 1095)
<li>SB1W1L4  AVDD 1115mA while IMon(1070, 1110)
<li>SB0W8L2  AVDD 785mA while IMon(765, 780)
<li>SB0W6L1  AVDD 491mA while IMon(475, 490)
--------- for bias current
<li>SB5W0L2 bias 196uA
<li>SB4W10L2 bias 119uA
<li>SB4W5L4 bias 106uA
<li>SB4W3L2 bias 148uA
<li>SB3W11L2 bias 381uA
<li>SB2W5L4 bias 176uA
<li>SB1W10L4 bias 741uA
<li>SB0W3L2 bias 134uA
<li>They are all showing decreasing trend. Should be just the charging effect after a long shutdown.
<br>
<b>L00 bias </b><br>
<li>LB0W0L2, LB0WA0L3, LB0W3L3, LB0W5L3 <br>
<li>LB1W2L0, LB1W2L3, LB1W3L3-1, LB1W4L1, LB1W5L3-1<br>
<b>ISL </b><br>
<li>IB2W2L0-3 AVDD and DVDD and DOIM current have not yet been adjusted.
<li> IB0W4L0  AVDD at 930 with setting (840, 885). 930 is still smaller than norminal 16 chips ISL ladder. It could be 1~2 chips have came back.
<li> IB1W1L2 bias 1293uA. This guy tripped on bias overcurrent when we turn on bias. I changed the bias current limit to 5000uA and lower the bias voltage to 20V and could turn it back on with 1293 uA current. After an hour running, I put the norminal voltage 45V back and it drew around 3500uA bias current. So if it trips again next time, try to lower the voltage first.

<!-- Date: Thu Dec 9 11:24:07 2004 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 368
Calibration type  : standard
Run period tag    : Dec_2004
DPS-off run       : 190801
DPS-on run        : 190793
Requested by      : Jared
Main process id   : 1203034
Comment           : no trigger inhibit crate
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->


<!-- Date: Thu Dec 9 12:11:59 2004 -->
<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 368 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 190801
DPS-on run       : 190793
Requested by     : Jared
Submitted        : 2004-12-09 11:23:53
Completed        : 2004-12-09 12:10:20
Status           : FAILURE
Comment          : no trigger inhibit crate

Last processing stage reported : checking silicon configuration
Failure diagnostics :
error {There is an error in the biasInfo file for run 190801}
Exiting.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->
<!-- Comment: Thu Dec  9 13;31;57 comment by...Jason N -->
Aargh, stupid trigger inhibit!<BR>
If there is no trigger inhibit enabled, then the calibration tries
to use its own internal backup trigger inhibit and determine which ladders are biased.  This backup trigger inhibit has been turned off for some time, but I will restart the process now for this and all following runs.  Then I'll resubmit the calibration job.


<!-- Comment: Thu Dec  9 16;27;08 comment by...Cap&#39;n Hook -->
It's the curse of Volobuev!  Aaarrrgghhhh!
<!-- Date: Thu Dec 9 14:50:03 2004 -->
<h2>Bias scan</h2> 
Run number is 190810<br> 
<pre> 
deltaV     end event # 
-------    ----------- 
90          837 
75         1238 
65         1597 
55         1941 
45         2313 
41         2699 
37         3036 
---- new run 190817 ----- 
33          
29 
25 
15 
8 
4 
 
</pre>
Had to abort because of Eventbuilder problems.   May try again later if more quiet time after EVB is fixed...
<!-- Author: Ben, Jared, Corrinne -->


<!-- Date: Thu Dec 9 14:56:04 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Thu_Dec__9_2004_144004.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5447  align='top'></a></td><td>Master Clock Gap anomaly</td></tr></table>
<!-- Author: Marce/Sebastian -->



<!-- Date: Thu Dec 9 16:36:12 2004 -->
<pre>Bias Scan part 2 
 
Run 190828 
 
dV          Last event 
------------------------ 
33            351 
29            729 
25           1101 
15           1417 
8            1765 
4            2117 
0            2443 
70           2855 
60           3243 
50           3657 
43           4033 
39           4420 
35           4857 
31           5214 
27           5590 
20           5978 
10           6362 
6            6745 
 
We have put the silicon back to standby and then off, 
so we will be ready for beam again.  </pre>
<!-- Author: Ben, Jared, Corrinne -->


<!-- Date: Thu Dec 9 18:06:13 2004 -->
<h2> Swapping Master Clock Firmware again ...</h2> 
<p> 
We changed the Master Clock firmware again in svx02/06 moving back to the pre April 2004 Version which has the old and supposed to be better phase detector. The new version made with the same phase detector but slightly diffeent LA ports showed some trouble with the GAP signal this afternoon. So we took the conservative approach and will try to reproduce the error on the teststand. </p> 
We have started SRC checkout, but will probably do the pig running only tomorrow morning. 
  
<!-- Author: The Blues Brothers  -->
<!-- Comment: Thu Dec  9 19;18;57 comment by...The Blues Brothers -->
The first phase of the checkout was successful both for SVX and ISL. We had some exciting moments, as we did not connect the TSI cable in svx06. Clear message: <b> Do not try this at home </b>. After fixing this, we were able to excercise the system.
We'll keep a Coldstart running during the night to try to catch any problems.

 



<!-- Date: Fri Dec 10 08:27:47 2004 -->
<h3>SVXINTER died  </h3> 
<pre> 
tart subscribing to subject </caenInfo> again. 
Start subscribing to subject </_svxinter_14824416> again. 
WARNING: Lost connection to RTserver: error code = 10. 
Waiting before reconnecting. 
Attempting to reconnect to RTserver. 
Connecting to project <cdf_daq> on <tcp:b0dap33> RTserver. 
Using tcp protocol. 
Message from RTserver: Connection established.Start subscribing to subject </svxHVHdShk> again. 
Start subscribing to subject </caenInfo> again. 
Start subscribing to subject </caenInfo> again. 
Start subscribing to subject </_svxinter_14824416> again. 
Unable to allocate return data buffer 
0xe233e0 (t3): memPartAlloc: block too big - 71160 in partition 0x2ded8c. 
 
->  
-> msg_recv: bad size 0 reading length from socket 15, data dff2e8, type 0 
errno is 0 
Connection 127.0.0.1:1321 aborted, status is -1 
</pre>  
<!-- Author: somebody -->


<!-- Date: Fri Dec 10 09:02:23 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5448&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5448  width='300' align='top'></a></td><td><pre>Store 3821  
6250 E9 protons  
 338 E9 antiprotons  
10.25E30 initial instantaneous luminosity 
Tevatron quench at E1
</pre></td></tr></table>
<!-- Author: Rong-Shyang -->


<!-- Date: Fri Dec 10 09:02:58 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5449&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5449  width='300' align='top'></a></td><td><pre>
Store 3824   
initial luminosity 48E30   
6700 E9 protons   
 654 E9 pbars   
LOSTP 3.0 kHz   
LOSTPB 1.2 kHz   
Quench was at E11U and F48L
</pre><a href=http://www-bd.fnal.gov/cgi-mcr/elog.pl?nb=2004&action=view&page=932&anchor=002300&hilite=00:23:00- target=_top> MCR elog</a>
</td></tr></table>
<!-- Author: Rong-Shyang -->


<!-- Date: Fri Dec 10 09:03:56 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5450&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5450  width='300' align='top'></a></td><td> <pre>
** STORE: 3829 
 
** Pbars Loaded: 20:58 
** Ramp: 20:59  
** Flattop 21:01 
** protons: 6787.68 E09 
** antiprotons: 861.40 E09 
 
** Scraping Complete: 21:18 
 
** protons: 6472.62 E09 
** antiprotons: :830.29 E09 
**  
** LOSTP: 3103.995 Hz 
** LOSTPBAR: 1398.4375 Hz 
**  
** Init Inst Lum: 50.61 E30  
</pre></td></tr></table>
<!-- Author: Rong-Shyang -->


<!-- Date: Fri Dec 10 09:12:04 2004 -->
<pre>Generally, there is low loss on both proton and anti-proton. The lifetime of luminosity is also long. Abort gap loss rates are low for both P and Pbar. AGIGI2 readback is in reasonable range but SLPAH[37] is clearly not under controled.</pre>
<!-- Author: Rong-Shyang -->
<!-- Comment: Fri Dec 10 09;16;36 comment by...Rong-Shyang -->
Also, MCR has performed aperture scan for CDF on Nov.29, see <a href=http://www-bd.fnal.gov/cgi-mcr/elog.pl?nb=2004&action=view&page=906&anchor=211008&hilite=21:10:08- target=_top> MCR elog</a> and <a href=http://www-bd.fnal.gov/cgi-mcr/elog.pl?nb=2004&action=view&page=906&anchor=000001&hilite=00:00:01- target=_top> here</a>. Rob is going to ask if there is a plan for another scan.


<!-- Date: Fri Dec 10 09:19:54 2004 -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2004&action=view&page=-12258&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2004&action=view&page=-12258 width='300' align='top'></a></td><td>X Y beam position</td></tr></table> 
 
  
<!-- Author: Rong -->
<!-- Comment: Fri Dec 10 09;23;40 comment by...Rong -->
Plots stole from <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=857&frame=2&anchor=08:27:22.967'>
elog</a>.  It shows at about 2.2mm in Y. I saw the number from Rob that during August, the beam in Y is something like 1.75mm.

<!-- Date: Fri Dec 10 10:55:17 2004 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 369
Calibration type  : standard
Run period tag    : Dec_2004
DPS-off run       : 190801
DPS-on run        : 190793
Requested by      : Jason Nielsen
Main process id   : 2301617
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->





<!-- Date: Fri Dec 10 12:01:38 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Fri_Dec_10_2004_120130.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5452  align='top'></a></td><td>SVX ISL SRC clocks</td></tr></table>
<!-- Author: Marcel/Sebastian -->
<!-- Comment: Fri Dec 10 12;11;39 comment by...Sebastian -->
<br>The plot shows a glitch (MCLK2) in SVX, captured this
morning while running a pig (e0b1). This was using the MC35 firmware,
the one that was in Happy before the shutdown. ISL, which
has the MC34 (good phase detector) firmware does not
have the glitch (MCLK1). Note that this is not the 
problem we had yesterday (see <a href="http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=copyentry&page=226&time=14:56:04">here</a>),
where only GAP was missing.
I would suggest to put MC34 on SVX too.

<!-- Comment: Fri Dec 10 12;38;25 comment by...Sebastian -->
<pre>Tested MC34 on the teststand with svxdaq and run control. No clock
problems found...</pre>


<!-- Comment: Fri Dec 10 15;53;25 comment by...Marcel/Sebastian -->
<h2>Installed MC34 in SVX</h2>
We swapped the MCLK EPROM in SVX, now both ISL and SVX have the 
MC34 version, pre-April 2004 (good phase detector). We tested
the SRC with both svxdaq and run control (with no ladders). No
problems found. We will try to include a pig before we power
up the silicon tomorrow.
<!-- Date: Fri Dec 10 15:17:39 2004 -->
After discussion with Rob, due to the fact that :  
<li>There is no plan for more aperture scan. (it has been done on Nov. 29) 
<li>The abort kickers have been check-out through the procedures and the timing looks good and no prefire during these days of TeV studies. 
<li>Recent stores have low rate on lostP, lostPb, abort gap losses 
<li>The luminosity lifetime is very good 
<li>Also this store was terminated well 
<br> 
We came up with a plan for Silicon 
<li>Wait for one more store which should come in this evening, Friday. 
<li>If this store is also good, have Silicon powered in the mid of next store which should come in the evening of Saturday. 
<li>During the Sunday daytime, mid of the store, have silicon powered up and included in the DAQ. 
<li>Have the silicon turned to 'Standby' or 'Off' after a few hours data taking. 
<li>If you have any suggestion or think we might forget something, let us know. 
<!-- Author: Petra and Rong-Shyang -->


<!-- Date: Fri Dec 10 15:52:25 2004 -->
<h3> Preparation of load balancing </h3> 
Thanks to the flux compensator installation a few days ago, we were ready know to install a spare VRB (SN 136)  in b0svx06/slot 17.  This will allow us to swap fibers whenever we please. In order to keep the new VTM (560883) happy, we comnnected the splitted fibers to it.  
<p> 
We checked with RC, that the VRB is switched off (no channels enabled and J3 off). We had no problems with it using coldstart. 
The only open question, is what will the event builder do. But we had a similar situation, where we took out some fibs, disbaled their corresponding VRB's and the EVB was happy. </p>  
<!-- Author: Sebastian/Marcel and Master Steve -->


<!-- Date: Fri Dec 10 16:23:50 2004 -->
<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 369 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 190801
DPS-on run       : 190793
Requested by     : Jason Nielsen
Submitted        : 2004-12-10 10:54:53
Completed        : 2004-12-10 16:23:47
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_ped abs max    SVX_PHI      0.5         0.961669  
 dps_on_ped abs max    SVX_PHI      0.2         0.408144  
 dps_on_ped abs max    ISL_PHI      0.25        0.417676  
 dps_on_ped abs max    ISL_Z        0.25        0.411966  
   bad_chan rel max    SVX_Z        0.3         0.422823  
   bad_chan rel max    ISL_Z        0.25        0.264785  

Reference calibration runs are 184510 (DPS off) and 184509 (DPS on)
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->
<!-- Comment: Fri Dec 10 16;59;35 comment by...Jason N -->
The reference calibration is from June 2004.  I have made this new calibration the new beam-off reference calibration, but I will also post the largest changes between June and December.


<!-- Date: Sat Dec 11 13:23:17 2004 -->
<br><b>SRC MCLK checkout</b><br> 
Checked the MCLK firmware with e0b1. First with RC ran 
for a while, got no errors nor shorter GAP signals. 
With svxdaq check that ADC count distribution for the 
ladder were fine (got a "java out 
of memory error" first, but sync'ing the VRBs fixed it). 
GB worked fine, then disabled it, ran for 10000 
events with no problems. Back to RC, ran for 30min, again, no problems with the SRC clock signals.<br>
<!-- Author: Sebastian -->


<!-- Date: Sat Dec 11 15:53:31 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5453&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5453  width='300' align='top'></a></td><td>LostP/Pbar and Proton abort Gap losses for ongoing store. Doesn't look to nice</td></tr></table>
<!-- Author: Marcel -->


<!-- Date: Sat Dec 11 16:00:58 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5456&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5456  width='300' align='top'></a></td><td>Nasty spike .... </td></tr></table>
<!-- Author: Marcel -->


<!-- Date: Sun Dec 12 02:16:33 2004 -->
<pre>Paged for cooling alarm (Flow too low).  When i got to the control room the Ace (Adam) was on the phone with Eva.  After checking the history page, per Eva's instructions, I acknoledged the trip and everything went green.  Maybe a monitoring glitch?  Seems ok for now.  </pre>
<!-- Author: Jared -->
<!-- Comment: Sun Dec 12 10;23;58 comment by...Eva H. -->
No glitch.  Jim in cryo changed the resin for SVX at that time.  See <a href=
'/cgi/elog/det-system-elog.pl?nb=cryo-gas&action=view&page=1402&frame=2&anchor=02:01:53'>
cryo elog. </a>

<!-- Date: Sun Dec 12 22:34:05 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W10L4 
<li>problem n: 603 
<li>Status: needs_quiet_time
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: yamaoka 
<li>description is: During or check out, no data in SVXMON.  Need to double check hwdb settings with svxdaq.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W10&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Dec 13 09:23:12 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5457&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5458' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5459&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5460' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5461&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5462' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5463&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5464' ></a></center>
<!-- Author: Jason -->
<!-- Comment: Mon Dec 13 09;27;32 comment by...Jason -->
These plots show the difference between the June beam-off calibration and last week's calibration (taken2004.12.09).
<BR>
From left to right: IB0W4L0, SB0W11L4, SB0W5L2, SB5W10L2.  The red line is the older calibration pedestal, and the green line is the new.  You can see the green line drops out for some chips or is flat-lined at 0, meaning no data from these channels.


<!-- Comment: Mon Dec 13 10;19;47 comment by...Jason -->
IB0W4L0 was known already.  There was a DB entry in <a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=226&frame=2&anchor=23:11:42'>
this e-log entry</a>. Was it dead before this entry, too?

<!-- Date: Mon Dec 13 10:06:22 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Mon_Dec_13_2004_100603.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5466  align='top'></a></td><td>Since Webtalks is busted... here is this week's pager carrier report.</td></tr></table>
<!-- Author: Jared -->