<!-- Title: 11:21:59  Mon Aug 28 2006 -->
<!-- Crewchief: Tuula (MPC) -->
<!-- Op1: Ignacio (Shadowing) -->
<!-- Op2: Ankush (SPL) -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Take good data!</pre>


<!-- Date: Mon Aug 28 11:37:29 2006 -->
<h3>Fixing Ricardo's Turbo-Ntupler</h3> 
 
<p>I was expecting Ricardo's Turbo-Ntupler to be firing today...instead it went like a wet squid...blurrghh</p> 
 
<p>The main shell script assumed CDF soft was set up and it was running in the correct directory.  A couple of script changes were made and I tested it from the svxii home directory.  It seems to run OK from there.  So let's wait till Tuesday to see if it works.</p>
<!-- Author: Ankush -->
<!-- Comment: Mon Aug 28 13;35;15 comment by...Ricardo -->
<pre>wet squid ?, that's nice Ankush...</pre>
<!-- Date: Mon Aug 28 13:04:39 2006 -->
<h3>RTserver problems</h3> 
Spoke with Bill Badgett about our concerns about the recent problems with the RTserver and the silicon flying blind during that time. He promised to look into the problem.  
<!-- Author: Ulrich -->



<!-- Date: Mon Aug 28 15:25:52 2006 -->
<h3>Another trigger table test</h3> 
Ted and Tom Wright repeated a test with the most recent trigger table. During the last test on Friday they discovered a CMP + track trigger (L1_TEST_MUON_PHI_GAP_PT15) which was running at a much higher rate than expected at 55e30. Still the rate was 70 Hz, not a problem for the silicon. At today's luminosity of 43e30, the measured rate was about 35 Hz. The test today showed a much smaller rate, 7 Hz. However, this rate is still higher than the expected rate of 2-3 Hz. At the moment it is unclear if we will start the new store with  the new trigger table (eventually with the troubled trigger pre-scaled). Ops will have to decide.
<!-- Author: Ulrich -->


<!-- Date: Mon Aug 28 15:31:39 2006 -->
<h3>S/N and SVT</h3> 
Here  a short summary what I found out this morning concerning the S/N required for SVT.  
The claim is 8 for the SVT to work ( according to the TDR). This should may be revisited at some point. Anyway, right now we have 19 4/5 Wedges in the SVX. Loosing L0 would affect 16 of those. So we could end up with 16 more holes in SVT coverage, but this will be a gradual process.  
  
<!-- Author: Marcel -->
<!-- Comment: Mon Aug 28 18;57;21 comment by...Ankush -->
<p>One point of clarification.  The dicussion centres around the SNR plots Juan-Pablo et al produced.  You can see the SNR reducing with time/luminosity.  The question was: "what is the minimum SNR before tracking or SVT stops working ?".</p>

<p>The idea is to do a naiive fit to the plots to extrapolate the luminosity where the SNR drops below this critical value.</p>

<p>One concerned ex-SPL got very worried reading the orignal entry by Marcel and belived the Silicon was dying right now.  I reassured him the silicon is still very much alive....for now.</p>

<p>I find it very touching the love for SVX continues even after retirement.</p>
<!-- Comment: Tue Aug 29 20;19;08 comment by...Ignacio -->
<pre> I have put the above mentioned plots from Juan Pablo et al
 together is a  
<a href= 'http://b0sili01.fnal.gov/~svxii/DReco.ps.gz'>
ps file</a>.  They show  the evolution of the parameters (noise, landau peak, S/N) grouped by layer, wedge and bulkhead   as a function of integrated luminosity. 

It is interesting that the noise  increase (that seems to drive the S/N decrease) happens very early (first 200 pb-1) for z and up to 1 fb-1 in phi. Afterwards I would say it stays kind of constant.  I think this is reassuaring.  On the other hand it makes less reliable an extrapolation.

</pre>
<!-- Date: Mon Aug 28 17:42:12 2006 -->
<h3>BERT Test Stand</h3> 
 
<p>Last week I discovered the chiller for the BERT test stand to be dead.  This meant we could not cool the TX to 15C.  The TX can be operated at Room temperature but there is reduced light output. Unfortunatly Bit 6 for one of the TX started giving bit 6 low results.</p> 
 
<p>Today, I tried again and the BERT stand seemed to be running error-free; no bit 6 low problem.  I noted the chiller temperature was now at 23.2C rather than 30.0C which I saw last week.  However after 5 mins of runnning, the bit 6 problem re-appeared.</p> 
 
 
<p>I found a fan by the test stand and positioned next to the TX which seem to be giving the bit errors. Now it runs fine.</p> 
 
<p>Now RX 0549, the one pulled out of e0a3, is being tested.  After 3.9x10<sup>10</sup> words, no errors were reported</p>
<!-- Author: Ankush -->
<!-- Comment: Fri Sep  1 15;05;53 comment by...Ankush -->
<h3>Results of RX 0549 Test</h3>

<p>I found the BERT stand terminated the test after 1 day 18.942 Hours on fatal burst errors.  There were 164 errors after 9.7x10<sup>12</sup> words. However closer examination of the errors show RX-A/TX-A was pulling the burst errors.  The RX under test was RX-C.  So as one of the reference RX is failing suggests a TX temperature problem. So the result is RX 0549 ran error free.  The next step is to run the RX in the WIB test stand.</p>

<p>As a reminder, this RX was pulled out of e0a3 as it was seeing no data at all.  So I have not been able to reproduce this error at all.</p>
<!-- Date: Mon Aug 28 19:18:23 2006 -->
<h3>Testing the <em>new</em> Octopuses and the Noyes fiber tester</h3> 
 
<p>During the great Silicon office clear up, a fibre tester was found and a batch of virgin Octopuses were found.</p> 
 
<p>The Noyes light tester has a light source and a receiver.  I tested the light source by connecting to our optical-probe+CRO.  This measured 3.414μW.  I then connected the light source to the meter and this registered -23.92 dbm which is 4.055μW.  So 0.641μW difference.  The difference between the two was an extra piece of fibre and an ST-ST connector.  If we blame the losses on the ST-ST connector, this implies a 84.2% coupling efficiency for the ST-ST connector.  This sounds a little large too me.</p> 
 
<p>One important point is the optical-probe is not calibrated for any particular wavelength.  But the Noyes optical reciever has a setting for different wavelengths and presumably applies the correct calibration.  So I need to dust off my InGaAs reponsitivty graphs and see how much it really changes from 1100nm to 1300nm.</p> 
 
<p>But the device basically works.</p> 
 
 
<p>The next step was to check the virgin Octpuses.  The idea was to inject light into one our trusted octopuses and measure how much comes out of the octopus under test.  I did this for several inputs and no light was measured...ie: no chage when the light source is on/off.  I then replaced the virgin Octopus with another trusted Octopus.  Again no light was measured.  This is very odd.  I will need to try again tomorrow.</p>
<!-- Author: Ankush -->
<!-- Comment: Thu Aug 31 06;40;33 comment by...SCN -->
Hi
  The Noyes device was bought by to Max Chertok and used to check Glink fibers, ages ago, and also used by Doug G in the ISL roto-rooting.  Calibrating it is not hard but there are a few gotchas, especially in having the fibers coiled up a bit, which changes the transmission modes down the core (something to do with internal reflections damping out, but I don't remember exactly-I do recall that you get vastly different results if you do it one way or the other).  Probably JJ or Jon Chramowicz over at ESE are good people to consult on its use. <BR>
The octopi were purchased I think about 2 years back, since the old ones were falling apart.  Probably set on a shelf and forgot about, but they should be good.
<!-- Date: Tue Aug 29 01:03:03 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W10L3 
<li>problem n: 1398 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: yuji 
<li>description is: Bit 0 low for >90% of events in recent runs. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W10&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Aug 29 02:20:08 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9724&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9725  width='300' align='top'></a></td><td>SVTSPYMon plot for store #4929, initial luminosity 124E30.</td></tr></table>
<!-- Author: Tuula -->
<!-- Comment: Tue Aug 29 03;04;36 comment by...Tuula -->
<pre>L1A rate 18 kHz, deadtime ~6%. SVXMON OK.

Status: OK
---------------------------------------
Run 222314, Tue Aug 29 03:02:57
SVX
Status: OK
ISL
Status: OK
L00
Status: OK
</pre>
<!-- Date: Tue Aug 29 02:45:08 2006 -->
<pre>I got paged because of a persistent pinky on AVDD B5W0L2. I asked the ACE to keep an eye on it for 10 more minutes. When I called back, the pinky has started to settle. The ACE will page me again if it turns pink.</pre>
<!-- Author: Tuula -->
<!-- Comment: Tue Aug 29 08;17;09 comment by...Ankush -->
<p>A quick review of the problem database will show the AVDD for this ladder has been irratic since the shutdown.  I made a chip change last week in an attempt to stabilise the current.  It did jump up once but it seems to have settled again.</p>


<!-- Date: Tue Aug 29 08:37:05 2006 -->
<h3>SRC Error last night</h3> 
 
<p><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=627&frame=2&anchor=02:16:34.545'> 
Last night</a> on going to activate, there were a bunch of SRC errors, such as 2 L1A to Buff and L2A w/o L1A.  But an HRR fixed this.  One CMX crate also complained during this.  I guess there was some temporary wierdness rather than some SRC problem.</p>
<!-- Author: Ankush -->


<!-- Date: Tue Aug 29 09:39:08 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9726&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9726' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9727&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9727' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9728&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9728' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9729&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9729' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Tue Aug 29 09;51;07 comment by...Ankush -->
<h3>LA Traces from last night's SRC Error</h3>

<p>These are the logic analyser traces from the last night's SRC error.  It looks like a clock glitch.  The first picutre, you can see a gap in the SRC clock lines.  The following picutres are different zoomed in section about the clock glitch.  You can see the clock is missing on the SVX SRC and the ISL SRC.</p>

<p>However there is one curious point.  The LA, which triggers on SVX or ISL SRC error, fired before the clock glitch was seen on the SRCs.</p>


<!-- Date: Tue Aug 29 10:06:04 2006 -->
<h3>fib06 was sheparded</h3> 
 
<p>In the e-log, <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=628&frame=2&anchor=08:40:01.352'> 
fib06 was sheparded</a>.  I had a word with the ACE and it did seem fib06 did fail to reboot. So sheparding was the only option left.</p>
<!-- Author: Ankush -->


<!-- Date: Tue Aug 29 11:34:24 2006 -->
<h3>Overnight BERT testing</h3> 
 
<p>I went in this morning to check up on the BERT test stand.  Unfortunatly the test stopped after 1.7 x 10<sup>11</sup> words with consecutive burst errors.  Again the errors corresponded to TX-C/RX-C seeing bit 6 stuck low.  I also saw the chiller tripped off...so it was not running.  So the two maybe connected.</p> 
 
<p>I raised the trip limit for the chiller and I added a bigger fan for the TX.  I also noticed the RX seemed a little warm, so I added an additional fan for the RX.  After these additions, the BERT is running fine again.</p> 
 
<p>I also decided to change the RX under testing to RX 0356. I will now leave it running over night to see how the testing goes.</p>
<!-- Author: Ankush -->
<!-- Comment: Wed Aug 30 15;11;38 comment by...Ankush -->
<h3>Results of the BERT Test</h3>

<p>I went in around 10:15am to find the BERT test had stopped running after 19.506 hours from fatal burst error.  The fatal burst was due to bit6 for RX-C being stuck low. The burst contributes 20 errors.  However 181 errors were recorded, so there were 161 <em>real</em> errors.  The final error rate was 161/4.4x10<sup>12</sup> words = 36x10<sup>-12</sup>.  So RX-0356 is bad. The errors from before the fatal burst came from Bit1 and Bit0 of RX-0356.</p>


<p>RX-0549 is now under test.  This one was pulled out of e0a3.  When I left, it had sent 3.5x10<sup>9</sup> words with no errors yet.</p>
<!-- Comment: Wed Aug 30 15;13;23 comment by...Ankush -->
<p>...and other small point....I corrected the Date & Time on the PC...it no longer thinks it&#39s 2005.</p>
<!-- Date: Tue Aug 29 11:37:06 2006 -->
<h3>Ricardo's turbo-Ntupler</h3> 
 
<p>I just checked the log files and Ricardo's turbo-ntupler ran perfectly last night. CRON started it at 7AM and everything was done by 7:05AM.</p>
<!-- Author: Ankush -->

<!-- Date: Tue Aug 29 13:06:14 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W7L2 
<li>problem n: 1704 
<li>Status: fixed
<li>Type: BIAS
<li>Action: Currents_investigated
<li>entered by: tmaki 
<li>description is: The currents look fine and the limits are still good 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W7&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Aug 29 13:10:45 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W6L1 
<li>problem n: 1734 
<li>Status: fixed
<li>Type: DVDD
<li>Action: Diagnosis_update
<li>entered by: tmaki 
<li>description is: The current looks fine and the limit is still good.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W6&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Aug 29 13:14:53 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W1L3 
<li>problem n: 1519 
<li>Status: fixed
<li>Type: BIAS
<li>Action: Diagnosis_update
<li>entered by: tmaki 
<li>description is: The current looks fine and the limit is still good.   
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W1&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Aug 29 13:33:30 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W1L2 
<li>problem n: 1675 
<li>Status: fixed
<li>Type: DVDD
<li>Action: Diagnosis_update
<li>entered by: tmaki 
<li>description is: The current looks fine and the limit is still good. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Aug 29 15:05:42 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9730&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9730  width='300' align='top'></a></td><td>Results of tests from increasing bias1 on f401. 
Black is 80V. Red is 82V. Green is 90V. Blue is 95V. Yellow is 100V. Magneta shows the bias0 ladder that has a nominal landau, for comparison.</td></tr></table>
<!-- Author: David Stuart -->


<!-- Date: Tue Aug 29 15:38:22 2006 -->
<h3>Silicon Notes Folder</h3> <p> As requested by Ankush and Ulrich, I printed out all the CDF notes having the word "Silicon" in the title (but not the ones talking about Run 2b nor SVT). I put those notes in a folder and it has "Silicon notes 2001-2006" written on its back. The folder is in the Silicon office</p>
<!-- Author: Tuula -->



<!-- Date: Tue Aug 29 20:37:31 2006 -->
<pre>SB5W0L2 has been oscillating between being pinky and not. According to problem DB, it has had this kind of behaviour already for some time. Since Silicon was not included in the current run, I asked the ACE to power cycle the corresponding wedge. I will be paged if it becomes pinky again.</pre>
<!-- Author: Tuula -->
<!-- Comment: Tue Aug 29 21;13;14 comment by...Tuula -->
<pre>This ladder became pinky again. I talked with Ankush who advised to ignore it. The ACE marked the ladder to be ignored.</pre>
<!-- Date: Tue Aug 29 20:45:05 2006 -->
Jonathan and Jason installed new firmware to XFT boards. Silicon is not included in the current run. Ricardo, who is the CO, is keeping eye on trigger rates. There is a plan to include Silicon later in the evening if the trigger rates are OK. 
<!-- Author: Tuula -->



<!-- Date: Tue Aug 29 22:37:09 2006 -->
<table><tr><td><a href=/elog/notebooks/silicon/Tue_Aug_29_2006_223705.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9732  align='top'></a></td><td>SB1W4L1</td></tr></table>
<!-- Author: Tuula -->
<!-- Comment: Tue Aug 29 23;29;26 comment by...Tuula, Ankush -->
<pre>Raw data from svxdaq in read all mode:

e1413bfc 8527233a 22352738 273a2638
0x00000440:  263c243a 6038243a 2d392c3a 253d2033 2438273b 253a213b 273a263e 2c3f2738
0x00000460:  253b253f 2d372236 253a2739 603a253f 27392439 223d2539 203c6039 2140223c
0x00000480:  603f2640 60396042 21416039 213e6340 613a2341 263e213b 633c623c 203d2147
0x000004a0:  223d223d 203e2342 273f613d 263b613b 233a2140 203b8427 213e203e 223f223e
0x000004c0:  233b223f 223a603b 2741223c 223b203e 243e223e 273c273f 213e273a 203c2739
0x000004e0:  213f223c 253b233c 2541273b 243c2338 21422440 2642263a 27402c3a 263b233d
0x00000500:  233e2040 2039213c 243e233e 2c3f203e 60406040 203a213a 203e203d 22406039
0x00000520:  203d2143 2241223e 663d233c 203f2241 613d6040 213a203f 8327603c 22382443
0x00000540:  203e2d3c 213c2441 213f223c 24386139 20432539 22392740 21422236 203c223a
0x00000560:  603a603f 6336603a 203c213c 213a203a 2339263a 2c3f273a 273b273e 2c3e2739
0x00000580:  2539273c 24382638 2539223a 243a2037 263b263c 24342c3c 25382237 2c3d2537
0x000005a0:  243a2d3a 24342637 23392738 24392d3c 22382437 24362c37 2c3fa227 243c213d
0x000005c0:  273e213d 2f392336 203c2434 213c6039 223a223b 233b223a 253f233c 253d603b
0x000005e0:  243e213f 223c223c 20392141 243e223a 263b2238 22382739 6640213b 2638223c
0x00000600:  243b223f 263b263c 2539213d 203a2641 22392239 2c3e253b 223b2d34 603c263c
0x00000620:  20392038 223e253c 203b2037 26342238 2739603a 2235253d 24382639 a127603f
0x00000640:  20392041 213e603e 2244203c 273c233c 22406141 2038613c 223f2238 203d203d
0x00000660:  603e6141 263e603a 603f273f 20407858 2141223d 273d203e 633e613f 203a253d
0x00000680:  21402139 6037223e 253f243c 203c253b 203c213e 26332140 2339273a 613e203a
0x000006a0:  2e3b2541 223c2c3d 2c3a273e 60412738 243c2e3c 2437273c 223d253d 223ca027
0x000006c0:  243a2a37 2436243b 2a382e34 24332436 2d362b38 2b362133 27332e3b 26402c34
0x000006e0:  2d392d37 2f3c2b38 243b2e39 2d373838 2a392e3a 25382736 2e332933 2a382636
0x00000700:  2e342a34 2d352835 2c382439 2c36243a 2a342d37 2a3c2f38 24342238 2a332d33
0x00000720:  2d382532 2d382735 2e322c33 21392733 293c2d36 2b382c38 2a372f37 2c3b2a35
0x00000740:  c2c20000</pre>

<!-- Comment: Tue Aug 29 23;30;35 comment by...Tuula, Ricardo and Ankush -->
<h3>SB1W4L1 giving bad data</h3>

<p>Alberto noticed SVT was not seeing tracks for SB1W4.  This wedge already has one ladder out.  We looked more closely at the silicon and the problem was traced to SB1W4L1 giving garbled data.  The plot on the left demonstrates this.  As this appears on every chip, it is likely to be a DAQ error.</p>

<p>The first step was to eliminate the VRB.  We swapped the fibres on the VRB and the errors followed the fibre.  So the VRB is not the problem.</p>

<p>As a check on the chip, all ISEL bits were set to 1 and the RDriver was set to 7.  No change, the errors were still present.</p>

<p>An access had been requested to further diagnose this ladder.  The first step is to do a fibre-swap to determine whether the problem in internal or in the DAQ.  The likelihood is this is a DAQ problem.  In which case, I will gamble on a bad FIB and swap it.  If this does not fix the problem, the RX will have to be swapped.</p>
<!-- Comment: Wed Aug 30 08;51;22 comment by...An oldtimer -->
<h3> Just for your information </h3>
If SVT sees it as well, the VRB is automatically excluded, because the fiber splitter is before our VRB racks. <br>


<!-- Date: Tue Aug 29 23:05:59 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W4L1 
<li>problem n: 1740 
<li>Status: needs_access
<li>Type: Unknown
<li>Action: Incident
<li>entered by: tmaki 
<li>description is: This ladder doesn't return good data. Needs an access to fix it. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W4&layer=L1">report</a></ul>
<!-- Author: Problem DB -->





<!-- Date: Wed Aug 30 01:29:08 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9733&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9734  width='300' align='top'></a></td><td>SVTSPYMon plot for store #4930, initial luminosity 164E30. As expected, the cell B1W4 has lower density of data points than usually.</td></tr></table>
<!-- Author: Tuula -->
<!-- Comment: Wed Aug 30 02;35;28 comment by...Tuula -->
<pre>For some reason, there hasn't been an updated svxmon_yellow.txt for this store neither online consumer slides. I called to the CO. He said there are no yellow cells in SVXMON.</pre>


<!-- Date: Wed Aug 30 05:30:01 2006 -->
<pre>ACE (Alice) told b0fib05 would not have gone to halt on an HRR. She stopped the run. At the same time, ladders associated to this FIB crate turned pinky and the SVXMON cells turned red.  
 
FIB crate passed coldstart, and the AVDD currents are coming back to normal. I think the FIB crate just needed to go through CONFIG.</pre>
<!-- Author: Tuula -->
<!-- Comment: Wed Aug 30 05;31;57 comment by...Tuula -->
<pre>Now they are taking data without above problems.</pre>


<!-- Comment: Wed Aug 30 09;14;31 comment by...Ankush -->
<p>As Tuula mentioned in the 8am meeting, this FIB probably got sprayed by the beam. The SVXMon plot posted by the CO can be found  
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=630&frame=2&anchor=05:00:35.872'>
here in the shift elog</a>.</p>
<!-- Date: Wed Aug 30 07:02:41 2006 -->
<pre>Several DAQ crates, including b0svx08, turned red in RC. All the other crates were non-Silicon crates. The ACEs were starting a new run. At least the Silicon crate passed config.</pre>
<!-- Author: Tuula -->


<!-- Date: Wed Aug 30 07:53:43 2006 -->
<h3>Leak in ISL Cooling</h3> 
In addition to the notorious air leak we seem to lose water in the ISL system ever since the rate-of-rise test last week. The air separator water level decreased from around 20 in to 17 in (which is the iFix warning limit, so I got paged due to this problem). One inch in the air separator corresponds to 2-2.5 gallons of coolant. Jim Loskot is on the case.
<!-- Author: Ulrich -->
<!-- Comment: Wed Aug 30 11;50;50 comment by...Ulrich -->
<p>
A couple of updates on the leak issue:

<ul>
<li>Warren Bowman and Jim Loskot inspected the alcove. All the water they see there is most probably from condensation. They also followed the pipes through the assembly pit. No leak either.</li>
<li>We checked a couple of humidity sensors. No changes at COT face, inside silicon baggie and at the mini-skirts.</li>
<li>During the access tomorrow morning, I will have a look at the manifold.</li>
</ul>
<!-- Date: Wed Aug 30 09:52:45 2006 -->
<h3>Access in the middle of the night...<em>o joy</em></h3> 
 
<p>Willis just came in and told us we got our access at the end of the store.  However the store termination is likely to be in the middle of the night.....<em>Woo-Hoo !!</em></p>
<!-- Author: Ankush -->
<!-- Comment: Wed Aug 30 19;04;51 comment by...Ankush -->
<table border=0><td><tr><td bgcolor=#e0e030><p>The store is to be dumped at 4am :-(  </p></td></tr></td></table>
<!-- Date: Wed Aug 30 15:54:12 2006 -->
It has been almost 6 hours since a new entry was added to the elog, so I am make this entry so people don't think we took the day off.
<!-- Author: Mark -->
<!-- Comment: Wed Aug 30 16;00;05 comment by...Mark -->
...I am making this entry...
<br>
Honestly, English is my first language.
<!-- Date: Wed Aug 30 15:58:38 2006 -->
<h3>SVXMon Troubles</h3> 
Earlier today Kaori tried to run a newly compiled version of SVXMon only to find many red cells in the chip status maps; in particular all of L00.  It appears that SVXMon is only seeing data from L00 about 30% of the time which points to a problem with the code that unpacks the silicon banks.  Since none of the SVXMon code has changed, it could be a problem with someone elses code that we are using.  In the meantime, we have switched back to the old functioning SVXMon and I will debug this problem offline.
<!-- Author: Mark -->



<!-- Date: Wed Aug 30 17:32:40 2006 -->
Remember  
<a href= 'http://www-cdf.fnal.gov/internal/silicon/siDump.html?'> Ankush's web page </a> explaining how to dump raw data? 
There is new script (search_raw.sh) in the same directory (b0gateway:/cdf/onln/home/svxii/dumpraw_SL) that swap the byte 
order to the more familiar SVXDaq format. It also selects the data corresponding to  a ladder (or a range of ladders) defined by the variables: 
 
set LADDER = f800 
set NEXT   = f810  
<!-- Author: ignacio -->



<!-- Date: Wed Aug 30 19:21:29 2006 -->
<h3>Jose&#39s web current plotter looking at Ricardo&#39s ntupls</h3> 
 
<p>In an effort to force eveyone to check Ricardo&#39s turbo-ntupler, Jose&#39s web interface will now look at Ricardo&#39s turbo-ntupler of Ben&#39s original PS ntuples.</p> 
 
<p>So if you see anything strange in the graphs, let me know!!</p> 
 
<p>If this runs OK for the next week or two, then I think we should declare Ricardo&#39s ntupler official and switch off Ben&#39s CRON job.</p>
<!-- Author: Ankush -->

<!-- Date: Wed Aug 30 19:29:28 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W0L1 
<li>problem n: 1741 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>This current just crept over the upper IMON limit of 100.  I am bumping it up.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>65.9237</td><td>101.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>100.0</td><td>130.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Aug 31 06:54:08 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W4/5All 
<li>problem n: 1742 
<li>Status: needs_observation
<li>Type: Chip_other
<li>Action: Swap_FIB
<li>entered by: amitra 
<li>description is: <p>SB1W4L1 was returning garbled data which was creating an SVT hole as SB1W4L4 is already out in this wedge.  The data coming out was corrupted and no obvious bit error could be traced.</p>  <p>In the collision hall, a fibre-swap was carried out which confirmed it was a DAQ problem.  The FIB was swapped and now SB1W4L1 returns data with no errors.</p>  <p>The next step is to observe the ladders in SB1W4/5 and check they run error free.</p><table border=1>
   <tr>
    <td>
     <b>IN:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/fibdb/DBreport.pl?serial="></a>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/fibdb/DBreport.pl?prep=149">149</a>
    </td>
   </tr>
   <tr>
    <td>
     <b>OUT:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/fibdb/DBreport.pl?serial="></a>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/fibdb/DBreport.pl?prep=164">164</a>
    </td>
   </tr>
  </table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W4/5&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Aug 31 06:55:51 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W4L1 
<li>problem n: 1740 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: amitra 
<li>description is: <p>A fibre swap for this ladder showed this was a DAQ problem.  The FIB was swapped and now the ladder runs error free in SVXDAQ. One should observe this ladder during data taking to cofirm it is running error free.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W4&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Aug 31 07:01:40 2006 -->
<h3>Silicon Access</h3> 
 
<p>So Ignacio, Tuula, Ulrich and I with guest-star Dale Stenz came in at 4am for the access.  We came in to do two jobs: swap a FIB to fix SB1W4L1 and to investigate the cooling leak.</p> 
 
<p>The FIB swap was pretty straight forward.  We did a fibre-swap first and confirmed it was a DAQ problem.  The FIB was swapped and SB1W4L1 is now running error free.</p> 
 
<p>The cooling leak was quite obvious.  The pipe going to the flow meters was clearly dripping water.  You could also see water collected by the mini-skirt PMTs and on the floor.  This was quite serious and had to be fixed straight away.  The East ISL & L00 was was turned OFF and Ulrich closed the electronic and manual valves. Dervin then replaced the plumbing fixture. The manual valve was reopened and you could see the pipe was not leaking anymore.  So that hopefully fixed that problem.</p> 
 
<p>Now we in the process of restoring cooling to the ISL.</p>
<!-- Author: Ankush, Ulrich, Ignacio, Tuula and Guest-Star Dale Stenz -->


<!-- Date: Thu Aug 31 07:59:40 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9737&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9738  width='300' align='top'></a></td><td><h3>ISL Cooling Leak</h3> 
The picture shows the fixture which had developed a leak. You can also see the rust on the metal box to the right of it. The fixture is situated at a line which branches off between the manual supply valve and the e-valve of the ISL East cooling circuit #2. To isolate that part of the cooling line, we shut down all ISL East e-valves and closed the manual supply valve (red handle) in addition. Then Dervin took the fixture apart, cut off a piece of the flex tube and added a new collet. After that, the fixture seems to be tight again. 
<p>  
The cryo techs also replenished the ISL coolant. The current air separator level is 21.6 inches. To spot leaks earlier in the future, I have raised the iFix warning limit on the SVX and ISL air separator levels from 15/17 inches to 20 inches. 
 
<p> 
Thanks a lot to Dervin, who spotted the leak first and also finally fixed it.</td></tr></table>
<!-- Author: Ulrich -->

<!-- Date: Thu Aug 31 08:28:45 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L3 
<li>problem n: 1720 
<li>Status: fixed
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>The ISEL bits for chips have been reset to their defaults values.  So the AVDD current has gone up and the IMON limits have to be bumped up.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>970.0</td><td>1121.5</td></tr>
<tr><td><b>Lower</b></td><td>925.0</td><td>1055.0</td></tr>
<tr><td><b>Upper</b></td><td>1005.0</td><td>1140.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W0&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Aug 31 08:32:32 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L1 
<li>problem n: 1725 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: Diagnosis
<li>entered by: amitra 
<li>description is: <p>The bias1 has been increased from 100.0V to 105.0V.  The purpose is to confirm the ladder is fully depleated.  So far every increase in bias has increased the amount of charge collected.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Aug 31 08:44:04 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L4 
<li>problem n: 1638 
<li>Status: needs_observation
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>Following a suggestion in thread 73, I have set the threshold for chip a6 to 255 and turned DPS off for a6.  Observe how this ladder performs during data taking.  However the purpose was to fix the AVDD current.  But it has not changed.</p>  <p>So check in out in the next few stores.  Then reevaluate.</p> 
<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: Thu Aug 31 08:57:06 2006 -->
<h3>Quiet time studies</h3> 
 
<p>Using the quiet time after the access I did the following:</p> 
 
<ul> 
 
<li>IB4W0L3: The ISEL bits for all chips have been restored to their default values.  The AVDD IMON limit were also returned to their default values.</li> 
 
<li>SB0W8L4 : I made some bad chip changes which dropped readout and affect AVDD.  Last week I retuned the ISEL bits for chip 8a to 0.  Today I just set the threshold to 255 and DPS off for chip a6.  Now observe how this ladder behaves during data taking.  The AVDD current is still PINK in IMON.</li> 
 
<li>IB4W0L1: David Stuart requested to increase Bias1 from 100.0V to 105.0V.  We wait to see if the ladder is really fully depleated.</li>  
 
</ul>
<!-- Author: Ankush -->


<!-- Date: Thu Aug 31 11:44:41 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9740&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9741  width='300' align='top'></a></td><td>Store number 4932. 
Record luminosity 222 at CLC startup, 215 when data started to be recorded.  
Backgrounds flat as soon as scraping was done.  
(We were up before COT). Trigger table changed by hand by Ted becasue initial dead time was 80-100%.</td></tr></table>
<!-- Author: Ignacio -->
<!-- Comment: Thu Aug 31 11;47;17 comment by...Ignacio -->
<pre>LA1 now is 18 Khz (12 % dead time). </pre>

<!-- Comment: Thu Aug 31 12;14;00 comment by...Ignacio -->
<pre>SVXMOn looks OK.

Connor looking at event sizes (33 kbytes).  They seem to be larger than expected from luminosity  extrapolation. Maybe because trigger mixture has been biased towards high pt, fully-lit detector events.</pre>


<!-- Date: Thu Aug 31 12:40:16 2006 -->
<pre>We tested the FIB 164 which was just taken out from the collision hall. It gave a lot of errors on channel 1, and some errors on channel 9. I (Tuula) will take to the PREP.</pre>
<!-- Author: Tuula, Mark and Ignacio -->


<!-- Date: Thu Aug 31 13:01:36 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9742&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9742' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9743&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9743' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Thu Aug 31 13;07;40 comment by...Ankush -->
<h3>Evolution of Bias currents for IB4W0L3</h3>

<p>The plots here show the history of bias0 and bias1 currents.  Over the last few days, the temperature of the CCE1 line was down to 16C and quite stable.  You can see this in the plateau of the bias currents.</p>

<p>However after the access and cooling work, the temperature of the CCE1 line has jumped back upto 20.07C and the bias1 current is now up to 152uA.</p>

<!-- Date: Thu Aug 31 13:09:40 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L3 
<li>problem n: 1596 
<li>Status: needs_longterm_monitoring
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>The CCE1 tmperature jumped up after the access and the BIAS1 current has jumped up.  Bumping up the upper IMON limit.  Must keep an eye on the bias current of this ladder.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>76.6668</td><td>152.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>150.0</td><td>160.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W0&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Aug 31 14:32:56 2006 -->
<h3>Fan Pack Failure in NE Bottom</h3> 
Just when I walked out of the weekly meeting, I saw a couple of blue cells in IMON. My first thought was that a hockerization was needed. HOwever, the cause of the blues was a rack trip in NE Bottom, which in turn was caused by a fan pack failure. Now the fan pack is comprised of 8 fans, and a failure is issued if 1 or 2 of them die. We assume that we can still run the racks with 6 fans until the fan pack gets fixed. So the way to go is to bypass the fan failure in the APACS interlock temporarily and request an access for George, Roberto and company to exchange the fan pack. 
<p> 
In practice this means some 1/2 hour of downtime for the silicon. So I instructed the shift crew to start a run without silicon and tried to find somebody to bypass the interlock. I had to drag Roser out of a meeting which Jaco to do the job. <b>Thanks a lot, Rob!</b> We powered the rack back up, and now, we are running with silicon again. 
<p> 
How the concern is that the rack may overheat. So we instructed the shift crew to keep an eye on the rack temperatures (currently 70&deg;F for the lower CAEN temperature, 71&deg;F for the crate outlet temperature and 72&deg;F for the crate inlet temperature).  
<!-- Author: Tuula, Ankush, Ulrich -->
<!-- Comment: Fri Sep  1 16;02;49 comment by...Ulrich -->
I have written up how to do the APACS interlock trick on my <a href="http://b0sili01.fnal.gov/cgi-bin/TWiki/bin/view/Silicon/UlrichsUsefulStuff">TWiki page</a>.
<!-- Date: Thu Aug 31 20:28:19 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W1L1 
<li>problem n: 1602 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>I am bumping the upper IMON limit for this ladder.  Probably made the last one too conservative.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>115.0</td><td>115.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>125.0</td><td>150.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Aug 31 20:30:40 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W0L3 
<li>problem n: 1743 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>The BIAS0 current for this ladder has just crept over the nominal 100&#956;A upper IMON limit.  So I am going to bump it now.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>74.8825</td><td>101.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>100.0</td><td>150.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W0&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Sep 1 01:00:04 2006 -->
<pre>I got paged because IFIX crashed (?) and they lost the window to monitor the temperature in the NE bottom crate. I told them that the temperatures shouldn't increase much in 10 minutes (temperatures didn't increase in 12 hours), in which they expected to get IFIX working again. They will page me again if they cannot get temperature monitoring working within 10 minutes.</pre>
<!-- Author: Tuula -->
<!-- Comment: Fri Sep  1 01;11;09 comment by...Tuula -->
<pre>They didn't manage to get IFIX running. I asked them to page IFIX experts.</pre>


<!-- Comment: Fri Sep  1 09;52;51 comment by...Ankush -->
<p>The iFIX problem was due to PC S3 in the cryo area which need not reboot cleanly.  More details in the <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=636&frame=2&anchor=01:00:31.648'>
shift e-log</a>.</p>
<!-- Date: Fri Sep 1 08:37:15 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9744&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9744' width='300'></a><a href='/elog/notebooks/silicon/Fri_Sep__1_2006_083639.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9746' ></a><a href='/elog/notebooks/silicon/Fri_Sep__1_2006_083651.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9748' ></a><a href='/elog/notebooks/silicon/Fri_Sep__1_2006_083700.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9750' ></a></center>
<!-- Author: Ankush -->
<!-- Comment: Fri Sep  1 09;04;32 comment by...Ankush -->
<h3>Silicon Resonance</h3>

<p>Last night at 12:22am, we got our first Silcion resonance after the WHA tower was masked out.  It appears to be a real resonance.  The ACE did a HRR and we continued running with no problems.</p>

<p>The LA plots above are the lines from the SRC and the scalar & TS.  You can see the L1A did not go bursty. That is why I beleive this was a real resonance. The L1 2 Track trigger seems to be at a high rate but it looks like it has always been at a high rate.</p>


<p>There is one curious feature. From the error logger, it say there was an L1 DONE TIMEOUT followed by an RXPT error loop. This is what the error logger said:</p>

<pre>
CT: 2006.09.01 00:22:28
22'28" 1 crate/s: b0svx02(112),  in error. [RXPT]
(MLE) b0control21.fnal.gov:Thread-25:Sep 1, 2006 12:22:28 AM->FrontEnd Crate Error Condition from:
VRB_SVX_02

(MLE) b0control21.fnal.gov:Thread-25:Sep 1, 2006 12:22:28 AM->FrontEnd Error: VRB_SVX_02 
CT: 2006.09.01 00:22:35
22'35" L1 Done Timeout.[RXPT]
(MLE) b0control21.fnal.gov:Thread-25:Sep 1, 2006 12:22:35 AM->  Silicon Level 1 Done Timeout Error from SVX, ISL or L00

CT: 2006.09.01 00:22:36
22'36" 1 crate/s: b0svx02(112),  in error. [RXPT]
CT: 2006.09.01 00:22:39
22'39" L1 Done Timeout.[RXPT]
CT: 2006.09.01 00:22:40
22'40" 1 crate/s: b0svx02(112),  in error. [RXPT]
(MLE) b0svx00:Messenger:Sep 1, 2006 12:22:47 AM->Silicon Resonator: Sl 16 Ch 7 -> e072: Bytes: 00060

(MLE) b0svx01:Messenger:Sep 1, 2006 12:22:47 AM->Silicon Resonator: Sl 10 Ch 9 -> e134: Bytes: 00094

(MLE) b0felix.fnal.gov:TEDCpp:Sep 1, 2006 12:22:48 AM->{ 0:22:48, 9/1/2006 }: L2-Pulsar-Linux: Halted while  waiting for SVT data
CT: 2006.09.01 00:22:51
22'51" b0svx02:Messenger:Sep 1, 2006 12:22:51 AM->SRC Fatal Error:Sl 6 Resonance Detected 
 -->  
 Additional Information: 

 Attention !!!. FERML_SRC_FATALITY ERROR !!! 
 
 SRC Fatal Error from b0svx02: Sl 6 Resonance Detected 
 
 - HALT the run                   
 - record any relevant information in e-log     
 - RECOVER - RUN     
[MLE]
CT: 2006.09.01 00:22:53
22'53" RXPT Error LOOP !!! Disabling AUTOMATIC HRRs.[EH Info]
(MLE) b0svx03:Messenger:Sep 1, 2006 12:22:54 AM->Silicon Resonator: Sl 10 Ch 9 -> e334: Bytes: 00066

(MLE) b0svx08:Messenger:Sep 1, 2006 12:22:56 AM->Silicon Resonator: Sl 16 Ch 3 -> f843: Bytes: 00780

(MLE) b0svx07:Messenger:Sep 1, 2006 12:22:57 AM->Silicon Resonator: Sl 16 Ch 3 -> fa03: Bytes: 00780

CT: 2006.09.01 00:22:56
22'56" 1 crate/s: b0svx02(112),  in error. [RXPT]
(MLW) b0control21.fnal.gov:Thread-25:Sep 1, 2006 12:23:00 AM->Inhibit flag SET 
(RC)   0:23:06 Halt -> HALTED
(RC)   0:23:21 Recover -> RECOVERED
(RC)   0:23:36 Run -> ACTIVE
</pre>

<p>I have just sent an email to the ACEs who were on duty.  I have asked them if they just got a single error box or an "explosion" of error boxes.</p>


<!-- Comment: Sun Sep  3 16;05;14 comment by...Ankush -->
<p>I received replies from the ACEs and it is not clear if the "error box" explosion occured. They both say a lot of error boxes did appear, some were RXPT error.  Also the CMX trip forced the ACE to go to HALT.</p>

<p>So I cannot be sure the "error box" explosion which occured during a resonance was a feature of the hot Calorimeter tower or a new RC feature.  I guess we&#39ll have to wait for the next resonance.</p>
<!-- Date: Fri Sep 1 09:44:43 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9751&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9751' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9752&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9752' width='300'></a></center>
<!-- Author: Mark -->
<!-- Comment: Fri Sep  1 09;51;35 comment by...Mark -->
As <a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=316&frame=2&anchor=11:44:41'>
mentioned yesterday</a>, when store 4932 came in with luminosity of 222e30, Conor measured an event size for the ISL/L00 VRB crates of >30 kBytes.  This seemed much larger than we expected so I ran over the initial dphysics stream data from runs 22271 (store 4928) and 22413 (store 4932) and extracted event sizes.  The plots above are consistent with our previous expectations for event size, so there may be something wrong with the script Conor was using to calculate the event size; for example, it may not be handling deadtime properly.  I will consult with Conor and see if we can get consistent results.




<!-- Date: Fri Sep 1 15:59:21 2006 -->
<h3>Cooling Update</h3> 
A couple of cooling things before the long weekend: 
<ul> 
<li>The output temperature of CCE1.1 is kind of high. I will try and massage the cooling lines once more. This was successful a few times in the past, but it was also unsuccessful at other times.</li> 
<li>The SVX chiller return temperature is now rather stable, at -8.5&deg;C. It seems that it is correlated with the chiller evaporator temperature. Keep watching it!</li> 
<li>After we fixed the leak yesterday, the air separator coolant level appears stable, around 21.7 psi.</li> 
<li>The cryo techs refilled the air separator of the backup chiller as well.</li> 
</ul>
<!-- Author: Ulrich -->


<!-- Date: Fri Sep 1 16:12:21 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W9L4 
<li>problem n: 1670 
<li>Status: needs_observation
<li>Type: DVDD
<li>Action: Monitoring
<li>entered by: amitra 
<li>description is: <p>oopss...this should be needs observation</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W9&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Sep 1 18:35:17 2006 -->
<h3>Permanent Light Level Measurement</h3> <p>We made the permanent light level measurement for e262.</p> <table border="1"> <tr><td>Bit</td><td>Light </td></tr> <tr><td>OBDV</td><td>284 μW </td></tr> <tr><td> 0 </td><td> 346 μW </td></tr> <tr><td> 1 </td><td> 460 μW </td></tr> <tr><td> 2 </td><td> 400 μW </td></tr> <tr><td> 3 </td><td> 472 μW </td></tr> <tr><td> 4 </td><td> 430 μW </td></tr> <tr><td> 5 </td><td> 416 μW </td></tr> <tr><td> 6 </td><td> 56 μW </td></tr> <tr><td> 7 </td><td> 420 μW </td></tr> </table>
<!-- Author: Tuula, Ignacio and Ankush -->


<!-- Date: Fri Sep 1 18:43:51 2006 -->
<h3>Cooling Work</h3> 
<ul> 
<li>I tried once more to "massage" the cooling lines. This time I was not successful at all. Currently the temperature at the cooling line is above 19&deg;C with only f451 and f453 powered. We will have to exclude f401 and f403 for the time being.</li> 
<li>I have also rebooted SVXIICON, as it is September 1st.</li> 
</ul>
<!-- Author: Ulrich -->
<!-- Comment: Fri Sep  1 23;55;10 comment by...Ulrich -->
Just checked the output temperature of CCE1.1. It has gone down to 19.5&deg;C.
<!-- Date: Fri Sep 1 18:50:31 2006 -->
<h3>Massaging DAQ and PSGUI</h3> 
In parallel to the other quiet time studies, we worked on the following: 
<ul> 
<li>Reboot of all 1st floor DAQ crate CPUs. The Silicon DAQ system became very slow, both in Run Control (Coldstart as well as data-taking) and in SVXDAQ. A reboot of the DAQ crates sped things up quite a bit. Question: which resource is freed by the reboot? Memory? Ports?</li> 
<li>Since we will have to upgrade all our b0dasvx PCs to Scientific Linux soon, we started the PS GUI on our test installation on b0dasvx03. We will do the quiet time studies using the PS GUI from there, and restart it on b0dasvx01 after we are finished.</li> 
</ul>
<!-- Author: Ulrich -->

<!-- Date: Fri Sep 1 20:22:54 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W5L3 
<li>problem n: 1654 
<li>Status: needs_work
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: ignacio 
<li>description is: We checked that the readback is still corrupted. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W5&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Sep 1 20:27:19 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W0L4 
<li>problem n: 37 
<li>Status: needs_work
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: ignacio 
<li>description is: Ladder remains on standby state but does not return any data. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W0&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Sep 1 20:27:19 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W2L2 
<li>problem n: 383 
<li>Status: needs_work
<li>Type: DVDD
<li>Action: Diagnosis_update
<li>entered by: ignacio 
<li>description is: Tryed again to power up. No success. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W2&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Sep 1 20:39:58 2006 -->
<table><tr><td><a href=/elog/notebooks/silicon/Fri_Sep__1_2006_203940.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9754  align='top'></a></td><td>We were looking at chip 87 becasue of CAP_ID errors. (still there)  We found out that chip a6 has a dead frontend (all channels==255). Checked that the failure  was present at least  since February 22 2006. 
Chip a6 is sparsed out.</td></tr></table>
<!-- Author: Ankush & Ignacio -->

<!-- Date: Fri Sep 1 20:50:05 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L1 
<li>problem n: 1697 
<li>Status: fixed
<li>Type: PC_Temperature
<li>Action: Removed_hdwdb
<li>entered by: amitra 
<li>description is: <p>This ladder had to be taken out as ISL cooling line CCE1.1 was already at 20C before IB4W0L1 and IB4W0L3 were switched on.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Sep 1 20:50:56 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L3 
<li>problem n: 1695 
<li>Status: fixed
<li>Type: PC_Temperature
<li>Action: Removed_hdwdb
<li>entered by: amitra 
<li>description is: <p>This ladder had to be taken out as ISL cooling line CCE1.1 was already at 20C before IB4W0L1 and IB4W0L3 were switched on.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W0&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Sep 1 20:53:21 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W3L4 
<li>problem n: 1591 
<li>Status: needs_work
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>While investigating Chip 87, we discovered chip a6 had a dead analog FE.  You can see the SVXDaq plot in the <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=316&frame=2&anchor=20:39:58'> Silicon elog</a>.  As this chip has a dead FE, I have set the ISEL bits to zero and set the RDriver bit to 0.</p>  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W3&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Sep 1 21:03:36 2006 -->
<h3>Summary of Quiet time work</h3> 
 
 
<p> 
<b>e053:</b> Init readback still fails <br> 
<b>e404:</b> This ladder can be taken to STANBY but it does not return any data in SVXDAQ. <br> 
<b>e522:</b> This ladder still trips on overvoltage <br> 
<b>e534:</b> Discovered chip a6 has a dead analog FE.  This chip has had its ISEL bits set to zero and the RDriver=0.<br> 
</p> 
 
 
<p>As a consequence of the cooling work, f401 and f403 had to be taken out of the HWDB again.  With both of these ladders OFF, the CCE1 temperature is already 20.07C.</p>  
<!-- Author: Ankush & Ignacio -->

<!-- Date: Fri Sep 1 22:29:19 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W3L4 
<li>problem n: 1591 
<li>Status: needs_observation
<li>Type: AVDD2
<li>Action: IMON_limits
<li>entered by: tmaki 
<li>description is: Ankush and Ignacio adjusted ISEL bits for this ladder, so the AVDD limits have to be adjusted.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1100</td><td>1055</td></tr>
<tr><td><b>Lower</b></td><td>1090</td><td>1025</td></tr>
<tr><td><b>Upper</b></td><td>1110</td><td>1100</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W3&layer=L4">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Fri Sep  1 22;48;14 comment by...Tuula -->
<pre>This ladder was pinky before adjusting IMON limits. Do the new values seem reasonable, i.e. that the range is not too large?</pre>


<!-- Date: Fri Sep 1 23:05:20 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9755&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9756  width='300' align='top'></a></td><td>SVTSPYMon plot for store #4934, initial luminosity 207E30.</td></tr></table>
<!-- Author: Tuula -->
<!-- Comment: Sat Sep  2 00;27;34 comment by...Tuula -->
<pre>SVXMON is OK.

Status: OK
---------------------------------------
Run 222530, Sat Sep  2 00:24:18
SVX
Status: OK
ISL
Status: OK
L00
Status: OK
</pre>


<!-- Date: Sat Sep 2 07:33:38 2006 -->
<pre>Shift crew wanted to ask if it is OK to include Silicon in a standard run without b0fcal00 crate. I said yes.</pre>
<!-- Author: Tuula -->


<!-- Date: Sat Sep 2 10:06:52 2006 -->
<h4>CCE1L6_1OUT dropped</h4> 
The temperature in our problematic cooling line CCE1L6_1OUT dropped over night from around 20&deg;C to 16.5&deg;C. Maybe we can re-include f401 and f403 at some point.
<!-- Author: Ulrich -->


<!-- Date: Sun Sep 3 09:54:29 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9757&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9758  width='300' align='top'></a></td><td>SVTSPYMon plot for store #4935, initial luminosity 191E30.</td></tr></table>
<!-- Author: Tuula -->
<!-- Comment: Sun Sep  3 12;05;01 comment by...Tuula -->
<pre>SVXMON looks fine.</pre>
<!-- Date: Sun Sep 3 11:19:13 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9759&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9759  width='300' align='top'></a></td><td><h3>DQMon Error for SB5W3L4</h3> 
In the  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=643&frame=2&anchor=10:38:29.901'> 
shift e-log</a>, there is a note about a DQMon error in B5W3L4, chip 7. They say SVXMon looks fine. I have checked the strip plots and did not find hits in that chip. From the problem database, I found that this chip (a6 in DAQ speak) was sparsed out on Friday with a dead analog front-end and hence did not show data ever since. How come that DQMon still complains about it?</td></tr></table>
<!-- Author: Ulrich -->


<!-- Date: Sun Sep 3 11:34:06 2006 -->
<h3>Reformatter Errors</h3> 
L3 has seen a couple of  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=643&frame=2&anchor=11:13:24.054'> 
reformatter errors</a>, which went away after an HRR. Connor will get in touch with us should this happen again. Looking into the log file, they seem to be all over the place, so a localized silicon problem is unlikely: 
<pre> 
Duplicate FIB ids:  0xf4407cf0  0xf4417cf0  0xf4427cf0  0xf4437cf0  0xf4407cf0  0xf05000fc  0xf05100fc  0xf4527cf0  0xf4537cf0  0xf45404f4 
0xf040b581  0xf041b581  0xf042b581  0xf043d901  0xf04000f0  0xf05009fc  0xf05109fc  0xf05209fc  0xf05309fc  0xf054b581 
0xf54003fc  0xf54103fc  0xf54203fc  0xf54303fc  0xf54403fc  0xf55003fc  0xf55103fc  0xf55203fc  0xf55303fc  0xf55403fc 
0xadeadcdf  0xadeadcdf  0xadeadcdf  0xadeadcdf  0xadeadcdf  0x333353fc  0x434353fc  0xbdbd33fc  0xbcbc53fc  0x3f0f030c 
</pre> 
What was the deal with "a dead cdf" again? Could somebody comment?  
<!-- Author: Ulrich -->



<!-- Date: Sun Sep 3 14:21:27 2006 -->
<h3>CAEN Crate 2 Communication failure</h3> 
 
<p>Just saw in the shift elog that CAEN Crate 2 (NW Top Bot) had to be hockerised.</p> 
 
<p><em>Is it me...or has this crate undergone a lot of hockerisation/spontaneous switch off recently ?</em></p> 
<!-- Author: Ankush -->
<!-- Comment: Sun Sep  3 14;39;00 comment by...Ankush -->
<p>Yes,  CAEN PS 2 spontaneously switched off on <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=315&frame=2&anchor=20:41:49'>
Friday August 25 at 20:41</a> and a <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=315&frame=2&anchor=18:03:10'>
few  days later</a>.</p>


<!-- Date: Sun Sep 3 16:19:45 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W6L3 
<li>problem n: 1744 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: tmaki 
<li>description is: This one was pinky because of increased BIAS current. Increase has followed the history, so I just adjusted limits.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>60.7</td><td>60.7</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>100</td><td>115</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W6&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Sep 4 00:06:23 2006 -->
<pre>Offline monitoring summary of the last week: 
                                                                                 
* SB2W2L4 
  SB5W6L4 Can't see ADCMon, though HWDB says these ladders are in (run222253) 
                                                                                 
* HDIs recently removed/included 
  IB5W1L1: Re-included 
</pre>
<!-- Author: yuji -->


<!-- Date: Mon Sep 4 09:18:20 2006 -->
<pre>The week summary: 
 
 
Monday: 
 Trigger table test 
 Work with BERT test stand 
 Testing new Octopuses 
 
Tuesday: 
 New store, #4929 
 Pinky on AVDD B5W0L2 
 SRC error 
 fib06 sheparded 
 Cleaning of problem database 
 Making Silicon notes folder 
 Tests for new firmware to XFT boards 
 SB1W4L1 returning bad data 
    -affects SVT 
    -we did quiet time studies to investigate it 
 
Wednesday: 
 New store, #4930 
 b0fib05 sprayed by beam 
 General DAQ problems 
 Leak in ISL cooling 
 Debugging new version of SVXMON 
 
Thursday: 
 Access 
   -FIB swapped for SB1W4L1 
   -Cooling leak fixed 
 Quiet time studies 
 New store, #4932, record luminosity 
 Testing FIB 164 
 Fan pack failure in NE bottom 
 
Friday: 
 IFIX problems 
 Silicon resonance 
 Quiet time studies 
 Pinky on SB5W3L4 
 New store, #4934 
 
Saturday: 
 ACEs checking they can run with Silicon without bofcal00 
 
Sunday: 
 New store, #4935 
 DQMon error 
 CAEN crate 2 spontaneous switch off 
 Pinky on BIAS SB3W6L3 
</pre>
<!-- Author: Tuula -->

<!-- Date: Mon Sep 4 11:28:39 2006 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 446
Calibration type  : standard
Run period tag    : Sep_2006
DPS-off run       : 222554
DPS-on run        : 222553
Requested by      : Adam Aurisano
Main process id   : 29562
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->