<!-- Title: 10:40:37  Mon Aug 29 2005 -->
<!-- Crewchief: Sebastian -->
<!-- Op1: Juan Pablo, and all... -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<br>
can it be worst than last week?...<br>
Store 4358 colliding...


<!-- Date: Mon Aug 29 11:07:30 2005 -->
<h4>ISL Chiller: Update</h4> 
Today, the RAM technician came back to examine the ISL chiller. He found a problem with a temperature control valve. He will come back with the spare part tomorrow. See also the <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=cryo-gas&action=view&page=1667&frame=2&anchor=09:02:57'> 
cryo e-log</a>. 
<p> 
This time I got paged before they worked on the system. Specifically, they ran all three chillers at the same time, which is a potential problem for the chilled water supply. Jim Loskot monitored the chilled water pressure gauge carefully (left back wall of the alcove, approx. 4m above the floor). The chilled water flow should be better after Jim unclogged the strainer. The broken chiller was connected to a heater to increase the coolant volume and add heat-load to the system.
<!-- Author: Ulrich H. -->

<!-- Date: Mon Aug 29 11:56:14 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W1L4 
<li>problem n: 1521 
<li>Status: needs_work
<li>Type: DRO_00F3
<li>Action: Incident
<li>entered by: marcel 
<li>description is: this ladder shows a 00F3 problem with chip 8a. Rate is around 10-20%. Should be investigated during quiet time 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W1&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Aug 29 14:56:53 2005 -->
<h3>SVXMon plots on the Web</h3> 
Thanks to Charles P. we now have SVXMon plots on the  
<a href="http://www-cdfonline.fnal.gov/internal/mon/cdfdoc/Consumers/current_long.html"> 
web</a>. Follow the svxmon link and select your favorite plot(s).
<!-- Author: Sebastian -->


<!-- Date: Mon Aug 29 18:40:41 2005 -->
<h3>New and Improved Bit Reporter</h3> 
 
I have replaced the old version of the bit reporter with a <a href="http://b0sili01.fnal.gov/cgi-bin/bitreporter/bitreporter.pl"> new version</a> that fixes various bugs and runs a bit faster.  Please let me know of complaints, suggestions or bugs that you may find at <A HREF="mailto:mhartz@fnal.gov"> mhartz@fnal.gov</a>.
<!-- Author: Mark -->

<!-- Date: Mon Aug 29 23:27:27 2005 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 419
Calibration type  : standard
Run period tag    : Aug_2005
DPS-off run       : 203449
DPS-on run        : 203448
Requested by      : Sebastian
Main process id   : 8241
Comment           : First dmode with evb2
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->



<!-- Date: Mon Aug 29 23:31:11 2005 -->
<h3>Dmode calibration with evb2</h3> 
 
Markus got the new EVB to do a dmode calib... less than 
15min overall. We could probably make it faster...<br> 
  
<!-- Author: Sebastian -->


<!-- Date: Tue Aug 30 00:46:32 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7354&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7355  width='300' align='top'></a></td><td>SVT with new track fitters (TF++). At the start of the run the cables for W10 and W11 into the fitters were swapped, that explains the plot on the right. The SVT people fixed the problem and now everything looks fine. The L1/L2 rate is about 10kHz/100Hz right now.</td></tr></table>
<!-- Author: Sebastian -->


<!-- Date: Tue Aug 30 06:34:24 2005 -->
Looks like we lost the abort gap losses for 5min, see  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=724&frame=2&anchor=06:24:09.696'> 
here</a>. Things look normal now, and I have asked Greg to include silicon again. I'll ask Rick T about it.
<!-- Author: Sebastian -->

<!-- Date: Tue Aug 30 08:43:43 2005 -->
<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 419 finished successfully.

Job info
--------
Calibration type : standard
Beam condition   : on
DPS-off run      : 203449
DPS-on run       : 203448
Requested by     : Sebastian
Submitted        : 2005-08-29 23:27:02
Completed        : 2005-08-30 08:43:29
Status           : SUCCESS
Comment          : First dmode with evb2
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Tue Aug 30 09:24:05 2005 -->
<center><a href='/elog/notebooks/silicon/Tue_Aug_30_2005_092325.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7357' ></a><a href='/elog/notebooks/silicon/Tue_Aug_30_2005_092340.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7359' ></a></center>
<!-- Author: Juan Pablo y Sebastian -->
<!-- Comment: Tue Aug 30 09;31;33 comment by...Sebastian and Juan Pablo -->
<pre>Looking at e414 before shot setup (quite time)
We tried to reproduced the 00f3 drop readout errors with svxdaq.
The plot on the left shows this ladder in readall mode, the
right plots shows the ladder on spared mode.
Chip 89 has cap ID errors and it shows in the plots.
However we did not find any 00f3 drop readout errors in 8a of
e414.
Ladders were not biased.</pre>

<!-- Date: Tue Aug 30 09:37:00 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W1L4 
<li>problem n: 1521 
<li>Status: needs_work
<li>Type: DRO_00F3
<li>Action: Diagnosis_update
<li>entered by: fernand 
<li>description is: We run the ladder with svxdaq and could not reproduce any drop readout erros (00f3) for chip 8a. We run the ladder in both readout and sparse mode during quite time (without biasing) and neither one nor the other running mode showed the 00f3 error. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W1&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Aug 30 10:17:15 2005 -->
<h3>VRB firmware in b0svx08 slot 8</h3> 
Downloaded the vrb5822P.hex firmware in the ISL VRB svx08 slot 8, 
with the idea of making sure no strange behavior is introduced 
by the firmw change. <br>
<!-- Author: Juan Pablo, Marcel & Sebastian -->
<!-- Comment: Tue Aug 30 20;53;06 comment by...Sebastian -->
Been looking at b0svx08 for the beginning of this store. The VRB with the new firmware was not reset, but data coming out of it looks fine (looked at a few ladders of VRB_61) and there are no VME bus errors in the crate. Note than on the teststand I never had to reset the VRB after downloading firmware, might be safer to do it though.
<!-- Comment: Tue Aug 30 22;45;04 comment by...just stopping by -->
yes, this way you make also sure that the new firmware is loading fine
<!-- Comment: Wed Aug 31 00;05;08 comment by...Sebastian -->
Markus found that the BUSY TO we had earlier were not related to the new firmware, see 
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=726&frame=2&anchor=21:56:50.660'>
here</a> and
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=726&frame=2&anchor=23:32:44.857'>
here</a>. 
<!-- Date: Tue Aug 30 12:15:56 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7360&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7361  width='300' align='top'></a></td><td>SVTSpyMon plot for store 4359</td></tr></table>
<!-- Author: Sebastian - Juan Pablo -->
<!-- Comment: Tue Aug 30 12;25;34 comment by...JP/S -->
SVXMon is also good.


<!-- Date: Tue Aug 30 13:26:06 2005 -->
<h4> Dirty valve </h4> 
Bill Noe showed me the valve that was broken, it had some greasy black stuff on it. The Ramtech guy will clean the chiller tomorrow to remove this dirt. They assume,that it is from the incident, where the compressor died.  
<!-- Author: Marcel -->


<!-- Date: Tue Aug 30 16:43:27 2005 -->
<h3> Ace Sashas interrogation report</h3> 
We had a little chat with Sasha concerning his crash button mumbo jumbo on Saturday morning. We did not harm him, because we promised Dee not to physicially touch him. We learned the following 
<ul> 
<li> He got confused by the IFIX HV state compared to the PSGUI, he already saw, that things were off at the PSGUI. </li> 
<li> His more experienced co-Ace was talking to the Cryo, because they weren't able to find the Cryo's Number. Sic ! </li> 
<li> He considered the crash button as massive hockerization and not pulling the plug. He wanted to play it extrasafe, assuming the crash button thing is a smaller intervention </li> 
<li> He was not aware, that he was actually pulling the plug out of the system. </li> 
</ul> 
What we learnt:<br> 
We actually had an Ace that took initiative and was able to admit, that he screwed. That is remarkable already, compared to some previous Aces. We also learnt, that we have to improve the trainig to make things very clear for Aces.
<!-- Author: The holy inquisition -->
<!-- Comment: Wed Aug 31 15;50;11 comment by...G. Galilei -->
<pre>keep in mind that aces read the detector elogs, too. </pre>
<!-- Comment: Thu Sep  1 20;03;03 comment by...The holy inquisition -->
We got Gallileo Gallilei as well ... there is no escape 

<!-- Date: Tue Aug 30 18:09:36 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7362&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7362' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7363&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7363' width='300'></a></center>
<!-- Author: Ankush & Juan-Pablo & Sasha -->
<!-- Comment: Tue Aug 30 18;13;56 comment by...Ankush/Juan-Pablo/Sasha -->
<p>SB3W11L2 (e3B2) bias current went pink in IMON (plot to be added) as it just went over its limit of 110.0uA.  We could wait for it to go down but if you look at its history it is increasing. So I'm going to bump up the limit to 115.0.  This should keep us safe to DS-Day 1832 (July 1 2006) if you believe the fit.</p>


<!-- Comment: Tue Aug 30 23;27;18 comment by...Rong -->
<pre>If today is DS 1702, how could DS1832 be July 1 2006?
Still I don't understand why you only changed the bias limits by tiny amount and expect many pinky to be happened in the coming days. Anyway, I guess you guys want the pager carriers have something to do during the night.</pre>
<!-- Comment: Wed Aug 31 09;31;14 comment by...Ankush -->
<p>Ooppps....I misinterpretted the date 07/01/2006.  This of course is 7 Jan 2006 (....silly US-UK differences!!)</p>

<p>As for the limits, guess I'm being a bit over-cautious. I good be a bit bolder and bump up the limits by a larger amount.</p>
<!-- Date: Tue Aug 30 18:16:17 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7364&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7364  width='300' align='top'></a></td><td><p>Here's the IMON plot for SB3W11L2 (e3B2).  It went pink went the bias current went over 110.0uA.</p></td></tr></table>
<!-- Author: Ankush -->

<!-- Date: Tue Aug 30 18:22:16 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W11L2 
<li>problem n: 1522 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>Bumped up the upper limit from 110.0 to 115.0.  Bias current has increased due to radiation damage.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>104.197</td><td>104.197</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>110.0</td><td>115.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W11&layer=L2">report</a></ul>
<!-- Author: Problem DB -->







<!-- Date: Wed Aug 31 07:16:07 2005 -->
<br><b>Electron lens tripped off, see <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=727&frame=2&anchor=07:07:06.296'> 
here</a></b>. Asked the crew to call MCR before putting the Si back in.
<!-- Author: Sebastian -->



<!-- Date: Wed Aug 31 10:41:27 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7365&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7365  width='300' align='top'></a></td><td>Abort Gap excursion  this morning .... seems to be correlated with D0 temperature change</td></tr></table>
<!-- Author: Marcel -->


<!-- Date: Wed Aug 31 16:58:45 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W3L4 
<li>problem n: 1053 
<li>Status: unfixable
<li>Type: Other
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: In vain, we tried different sparsing options and chip chops. This ladder is dead.  Declaring this thread unfixable. 
<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: Wed Aug 31 17:44:10 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L0 
<li>problem n: 1038 
<li>Status: needs_work
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>This ladder runs fine with RA mode but chip 11 (SVXDAQ CONFIG order) does not return any data in NN mode. When the Threshold was set to zero this chip still didn't return any data in NN mode.  So recommend to turn DPS off in the HWDB for this chip to overcome the problem.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Aug 31 18:03:59 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W5L3 
<li>problem n: 867 
<li>Status: needs_work
<li>Type: AVDD2
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>Ran this ladder in NN and RA mode and there were no errors.  I put the Z-side back in and the ladder ran with no errors in NN mode.  The initialisation 'read-back' was even OK.  So I'm going to unchop the chip chain and bring back the 'init read-back'.</p> 
<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: Wed Aug 31 19:33:08 2005 -->
<pre>IB0W3 is out of the hardware database. Will have an extensive 
report later.</pre>
<!-- Author: Marcel and Juan Pablo -->


<!-- Date: Wed Aug 31 20:23:19 2005 -->
<h2>More mad CAEN disease (the story of IB0W3)</h2> 
So <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=258&frame=2&anchor=23:32:43'>long, long ago</a>, f032 began tripping AVDD Ovc, and we discovered that it was a problem with the supply.  Finally today, we had a spare supply to swap in, and the promise of a long access to do it in.  IB0W3 resides in Crate 3, SW Top Top, with 4 other ISL wedges.<br> 
We pulled the old supply out and put the new one in its place.  When we turned the crate back on, I tried to turn the supply on... only to discover that the crate wasn't recognizing the supply.  When you look at the crate map from the back of the CAEN SY527, it gives you full information on what's sitting in each of its 10 slots - if there's no supply there, it says "Not Present".  If there's an ISL supply there, it says something about "Mod. 510" and gives you the supply's serial number.  For the slot with our new supply in, the crate map was telling me "Wrong Hdwr Ck, Wrong Frmw Ck".  In other words, it didn't recognize the type of supply sitting in that slot.<br> 
We tried powercycling the crate a couple times, but that did nothing, so we pulled the supply out and brought it down for a look.  Upon inspection, we realized that one of the pins in the backplane connector was bent, pressed all the way down so that it was pushed against the pin below it.  We brought the supply back upstairs, straightened the pins with needlenose pliers, then put the supply on the teststand.  The teststand read it out just fine, so we went back down to try swapping it again.<br> 
When we put the supply back in downstairs, we got exactly the same message from the crate map.  We pulled the supply out and looked at it... this time, there was no bent pin.  Everything looked perfect.  We tried one more time, got the same message.  At this point, we decided to swap the old power supply back in.<br> 
We got the old supply, put it back in the slot... and got the exact same error message.  We decided to leave the power supply in the crate, fully cabled up, and come upstairs to think about things.<br> 
From the PSGui, IB0W3 appeared all gray, as it would for a communication failure.  But the rest of the supplies in the crate showed up as fine.  So we tried taking them to standby... and discovered another problem.  Each of the other 4 supplies freaked out, for one reason or another.  One tripped on software protection overcurrent, because it was reading back thousands of microAmps of current on the bias line even when there was 0 V of bias.  Another said that it was at standby, but when we looked at the readback, every channel said 0 V and 0 current.  We tried hockerizing, but as expected that didn't work.<br> 
Luckily Sebastian had the idea that we should try pulling the IB0W3 power supply out and see if that affected the rest of the crate.  So we went back down, pulled the supply out, turned the crate back on... and now the other 4 wedges are working again.<br> 
Diagnosis:  somehow we screwed up that slot.  And when there's a power supply in that slot, it screws up the whole crate.  I've already sent email off to Matt Herndon and Reid to see if they've ever seen anything like this before.  But at this point, it looks like we need to swap the whole crate if we want to recover IB0W3... and needless to say, that's not going to be easy.  The closest thing we have to a spare SY527 is the crate at the teststand at FCC.  And we would need at least, say, 6hrs access... a 2-person lift set up at the back of SW corner to reach the Top Top crate... Dervin and someone else with experience swapping things out of racks... and if things don't go well we risk losing all 5 ISL wedges powered by that crate.  A very nontrivial exercise.  And until this is resolved, IB0W3 is offline.<br>
<!-- Author: Jen/Mark/Sebastian/Ankush/Juan Pablo/Marcel -->
<!-- Comment: Wed Aug 31 21;50;28 comment by...Jen et al -->
Although it may be difficult to believe given the size of the previous entry, I realized I forgot to mention at least one important detail.  We did visually inspect the backplane of the crate for damage (while the supply was out, I stuck a flashlight in there and looked around), and didn't see anything.  These are pretty tough connectors, so it's hard to imagine how we could have damaged it.
<!-- Comment: Wed Aug 31 23;05;26 comment by...J/S -->
<pre>The pins that were touching each other were (not
100% sure..) a6-a7, in the connector labeled c-a.
Pin a6 was bended and touching a7.</pre>
<!-- Comment: Thu Sep  1 09;36;27 comment by...s -->
May be the error was "Wrong Header Checksum"  and "Wrong Firmware Checksum" (at least that is what the manual says).
<!-- Comment: Mon Sep  5 12;12;12 comment by...Sebastian -->
<br>
The banded pins were A7 and A8, both pins went into the hole of A8. We were <b>able to reproduce the failure mode</b> by disconnecting the 8 of the X28C256 EPROM on the module, see <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=265&frame=2&anchor=11:41:22'>
here</a>.
<!-- Date: Wed Aug 31 20:28:47 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W3All 
<li>problem n: 1523 
<li>Status: needs_access_8hr
<li>Type: Wedgewide_other
<li>Action: PS_work
<li>entered by: jpursley 
<li>description is: Power supply for IB0W3 was tripping AVDD Overcurrent on L2.  In trying to swap the supply, we somehow screwed up the backplane slot and had to remove the supply altogether.  Wedge cannot be powered, probably until we swap the entire crate.  Details in <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=264&frame=2&anchor=20:23:19'>elog</a>. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W3&layer=All">report</a></ul>
<!-- Author: Problem DB -->





<!-- Date: Wed Aug 31 23:17:27 2005 -->
<h3>Major Chip Updates</h3> 
 
<p>So during the quiet time we studied several ladders which were giving problems and found tweaking chip settings helped.  In case there are probles, these are the ladders changed</p> 
 
<ul> 
<li> e053: Unchopped Z-side chop and brought back "init readback"</li> 
<li> e022: RDriver values changed to avoid errors during startup</li> 
<li> e351: Set threshold to 12 for the chip a0 to reduce readout time</li> 
<li>f400: Changed ISEL bit for Pipeline read from 10 (35uA) to 11 (69uA).  Brings back chip 85.  As it draws more current this will go pink in IMON until I change the IMON limit.</li> 
</ul> 
 
 
<p>More details in the morning.......</p>
<!-- Author: Everyone  -->
<!-- Comment: Wed Aug 31 23;23;39 comment by...Marcel -->
in other news, I set the alarm for e3b4 to ignored in ifix ...


<!-- Comment: Thu Sep  1 06;38;06 comment by...s -->
You mean e3a4 (?)....
<!-- Comment: Thu Sep  1 06;58;26 comment by...Juan Pablo and Sebastian -->
Since on DPS the pedestal is obtained with the 30 % of the 1st channels latched, we suggest to raise the thershold for chip a0
to 18 (since slope along the chip is 20/128 ADC per channel, in order to overcome the last channels we need to set the threshold
to "pededestal variation across chip" - "<mean pedestal obtained with 30 % of 1st channels latched>" = 20 - 30/2 * 20/128 = 18 )
<!-- Comment: Thu Sep  1 07;01;05 comment by...Juan Pablo and Sebastian -->
<pre>Just to be clear, the comment just above this one refers to
e351.</pre>
<!-- Comment: Thu Sep  1 07;05;48 comment by...JP & S -->
<p>Somehow the formula did not come all right. I repeat last
sentence:<\p>
In order to overcome the last channels we need to set the threshold
to "pededestal variation across chip" - "mean pedestal obtained with 30 % of 1st channels latched" = 20 - 30/2 * 20/128 = 18
<!-- Date: Thu Sep 1 06:36:42 2005 -->
<h3>Store 4363</h3> 
<ul> 
<li> Got paged at 5:45am, was so asleep that I said over the phone 
I will watch from home... but then remmembered about our access 
and the fact that the system was not in a normal state... 
<li> When I got here b0fib00 was stuck. "reset_crate" brought 
it back. 
<li> Yuji was configuring... fib04 failed because of e3a4... 
<li> After some struggle e3a4 came back. 
<li> We did a cold start to double check system. 
<li> We are ramping the silicon now.. initial lum 96E30 (only 
from recycler, they were not able to produce pbars last night). 
</ul>
<!-- Author: Sebastian -->






<!-- Date: Thu Sep 1 07:41:45 2005 -->
<h3>EVB/Si problems at the beginning of the store (4363)</h3> 
 
We were getting BUSY TO as soon as we started taking data, coming 
from b0svx02. After trying to clean the EVB/L3 farms (we lost like 
20min with this, the time before that was the Plug Inhibit) and 
failed several times, we paged Markus. He quickly found the problem 
coming from b0eb18, slot 16... but this is e17 which is out.  
So, after sorting things out, seems that the problem was that he 
reactivated checks for this store, but there is no data coming out of this VRB (VRB_20 b0svx01) and he was expecting data. He removed the check and now everything is fine.<br>
<!-- Author: Juan Pablo/Sebastian -->


<!-- Date: Thu Sep 1 07:47:38 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7366&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7367  width='300' align='top'></a></td><td>SVT spy mon looks fine.</td></tr></table>
<!-- Author: JP/S -->
<!-- Comment: Thu Sep  1 08;45;51 comment by...Juan Pablo - Sebastian -->
<pre>SVXMon is fine too. We are adding 4 new ladders back to
diagnose them with SVXMon and see what happens (f400,
e351,e022,e053).</pre>
<!-- Date: Thu Sep 1 07:59:56 2005 -->
<h3>Data coming out of e351</h3> 
 
<pre> 
                                      e351c1c1  
     3516: 852347fc 010c000e 38030204 3a3e3912  
     3520: 3c2e3b19 3e343d3a 400b3f30 84234102  
     3524: 5a0b5904 5c085b1f 83237f08 011b000b  
     3528: 03730230 059f04ce 072e0691 090b0814  
     3532: 7e060a05 a2237f0c 1d0600f3 1f1d1e10  
     3536: 21142014 2314220f 2512241b 27192618  
     3540: 29212842 2b062a0c 641f6302 660a650e  
     3544: 68166716 6a17694a 6c2d6b0b 6e0e6d0e  
     3548: 70186f0f 720f710a 740a7310 76187515  
     3552: 781477f3 7a0f7906 7c177b0e 7e027d1e  
     3556: a1237ff3 01060009 0f02a023 110c100c  
     3560: 18081207 1a04190c c1c1 
</pre> 
Looks fine. We need to check if the size was reduced 
with DS tools... 
<br> 
<!-- Author: JP/S -->

<!-- Date: Thu Sep 1 08:38:13 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L0 
<li>problem n: 1038 
<li>Status: needs_observation
<li>Type: Chip_other
<li>Action: Chip_bit_changes
<li>entered by: fernand 
<li>description is: Changed ISEL bit for Pipeline read from 10 (35uA) to 11 (69uA). Brings back chip 85. See <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=264&frame=2&anchor=23:17:27'> here</a>.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Sep 1 08:41:10 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L0 
<li>problem n: 1038 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: fernand 
<li>description is: Changed limits, see entry above.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1105</td><td>1150</td></tr>
<tr><td><b>Lower</b></td><td>1085</td><td>1125</td></tr>
<tr><td><b>Upper</b></td><td>1115</td><td>1155</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Sep 1 08:58:52 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W5L1 
<li>problem n: 1477 
<li>Status: needs_observation
<li>Type: Chip_other
<li>Action: Chip_bit_changes
<li>entered by: fernand 
<li>description is:  Set threshold to 12 for the chip a0 to reduce readout time.   My guess is that the reason for this high readout occupancy is that the pedestal distribution of this chip is not flat (it varies 20 ADC along the 128 channels).  Since on DPS the pedestal is obtained with the 30 % of the 1st channels latched, I suggest to raise the thershold for chip a0 to 18 later (why 18 ADC? answer : since the slope along the chip is 20/128 ADC per channel, in order to overcome the last channels we need to set the threshold to 'pededestal variation across chip' - 'mean pedestal obtained with 30 % of 1st channels latched' = 20 - 30/2 * 20/128 = 18 ), if we see 12 ADC is not enough (my suspition). 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W5&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Sep 1 08:58:52 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W5L1 
<li>problem n: 1477 
<li>Status: needs_observation
<li>Type: Chip_other
<li>Action: Chip_bit_changes
<li>entered by: fernand 
<li>description is:  Set threshold to 12 for the chip a0 to reduce readout time.   My guess is that the reason for this high readout occupancy is that the pedestal distribution of this chip is not flat (it varies 20 ADC along the 128 channels).  Since on DPS the pedestal is obtained with the 30 % of the 1st channels latched, I suggest to raise the thershold for chip a0 to 18 later (why 18 ADC? answer : since the slope along the chip is 20/128 ADC per channel, in order to overcome the last channels we need to set the threshold to 'pededestal variation across chip' - 'mean pedestal obtained with 30 % of 1st channels latched' = 20 - 30/2 * 20/128 = 18 ), if we see 12 ADC is not enough (my suspition). 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W5&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Sep 1 09:05:20 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W2L2 
<li>problem n: 1461 
<li>Status: needs_observation
<li>Type: Chip_other
<li>Action: Chip_bit_changes
<li>entered by: fernand 
<li>description is: RDriver values changed to avoid errors during startup 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W2&layer=L2">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Thu Sep 1 10:08:56 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7368&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7368' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7369&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7369' width='300'></a></center>
<!-- Author: Marcel -->
<!-- Comment: Thu Sep  1 10;09;36 comment by...Marcel -->
<h4> Strip occupnacy for e053 </h4>
So we have both phi and z side working .... good

<!-- Date: Thu Sep 1 10:10:43 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W5L3 
<li>problem n: 867 
<li>Status: needs_observation
<li>Type: AVDD2
<li>Action: Chip_bit_changes
<li>entered by: amitra 
<li>description is: <p>So as this ladder had seemed to have recovered during quiet time we put this ladder back to normal.  The Z-side was put back in and the init read-back was put back in.  We should have a look at it again in weeks time to see if the changes did any good.</p> 
<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: Thu Sep 1 10:15:43 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W2L2 
<li>problem n: 1461 
<li>Status: needs_observation
<li>Type: Chip_other
<li>Action: Chip_bit_changes
<li>entered by: amitra 
<li>description is: <p>Specifically the changes made were: The R-Phi RDriver values set to 5 and chip 89 (first R-Phi chip read-out) was set to 7.  The Z sides is still chopped so all its ISEL bits are zero and the R-Drivers are at zero.</p>  <p>This should be checked in a weeks time to see if the changes did any good.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W2&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Sep 1 10:24:07 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7370&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7370  width='300' align='top'></a></td><td>Noise for the last Chip in e351, looks like an improvement already ... compared to <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=251&frame=2&anchor=17:46:39'> 
here </a> 
 
 
</td></tr></table>
<!-- Author: Marcel -->

<!-- Date: Thu Sep 1 11:13:50 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W2L3 
<li>problem n: 1504 
<li>Status: needs_observation
<li>Type: RX
<li>Action: Swap_RX
<li>entered by: amitra 
<li>description is: <p>After the FIB swap this ladder was still giving errors.  We did a fibre swap to re-confirm the error was with the RX.  The RX was swapped and this ladder started returning data.</p>  <p>We should look at this ladder ina weeks time to check it is running error free.</p><table border=1>
   <tr>
    <td>
     <b>IN:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=RX 0984">RX 0984</a>
    </td>
   </tr>
   <tr>
    <td>
     <b>OUT:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=RX 0453">RX 0453</a>
    </td>
   </tr>
  </table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Sep 1 11:37:39 2005 -->
<h3>Late Access Report: RX swap for IB3W2L3 (f323)</h3> 
 
<em>.....sorry it's a bit late</em> 
 
<p>IB3W2L3 (f323) was not returning any data at all.  During the last access, Marcel did a fibre swap which confirmed the problem stayed with the DAQ channel, not the fibre. So Marcel swapped the FIB which didn fix the problem.  Thus only the RX was at fault.</p> 
 
<p>Mark and I went into the collision hall and reconfirmed the problem was still there and did another fiber swap.  The problem didn't move with the fiber.  So we went ahead and swapped the RX.  RX0453 went out and we put in RX0984.  That fixed the problem and the ladder is now returning data.</p> 
 
<p>Today, I'll go to FCC and test the RX0453 with the resurrected BERT stand...and I'll keep an eye on this ladder to check it behaves itself.</p> 
<!-- Author: Marcel, Juan-Pablo, Sebastian, Jen, Mark, Ankush + anyone else I&#39ve forgotten -->


<!-- Date: Thu Sep 1 12:27:00 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7373&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7374  width='300' align='top'></a></td><td>This ladder went a little funny in the head.  HRR brought it back. Juan Pablo reminds me to thank ACE shawn</td></tr></table>
<!-- Author: Ankush & Juan-Pablo & Shawn -->
<!-- Comment: Thu Sep  1 13;29;18 comment by...loosing it -->
Hello Dimitri ....
We are all fine, just a little bit funny in our heads ...


<!-- Date: Thu Sep 1 15:07:26 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7376&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7376' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7375&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7375' width='300'></a></center>
<!-- Author: Juan Pablo -->
<!-- Comment: Thu Sep  1 15;09;31 comment by...Juan Pablo -->
<pre>SB3W10L4 does not show data on the z side on run 203650</pre>


<!-- Date: Thu Sep 1 15:11:47 2005 -->
<h3>RX Testing at the BERT Stand</h3> 
 
<p>We took the RX 0453 to FCC and put it into the BERT test-stand.  We could see this was giving intermittent errors on one of the higher bits. We left it running overnight to see how many errors we get.</p>
<!-- Author: Ankush, Marcel, Mark -->
<!-- Comment: Fri Sep  2 11;34;21 comment by...Ankush -->
<h3>Results from the BERT Test Stand</h3>

<p>I went to FCC to check the results of the overnight tests.  THe tests stopped after a fatal burst error.

<p>Total Test time: 14.933 hours</p>
<p>Total Errors: 323 Errors / 3.4E12 Words Send = 9.6E-11 Errors/Word</p>

<p>Now if I understand the results from the BERT stand bit 4 on our RX is stuck low</p>

<p>The results were:
<pre>
Expected: fc333041 Received: fc233041
Expected: fd5f744f Received: fd4f744f
</pre>

<p>So my guess this data from the 3 RXs in the BERT stand has been cocatanated and we're seeing</p>

<pre>
XX(RX C Data)(RX B Data)(RX A Data)
</pre>

<p>I haven't figured out what the fc and fd at the start mean....any old-timers care to contribute...</p>
<!-- Date: Thu Sep 1 15:22:10 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7378&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7378  width='300' align='top'></a></td><td>This is how SB3W10L4 rphi-side looks in SVXMon (z side is empty)</td></tr></table>
<!-- Author: Juan Pablo & Ankushj -->
<!-- Comment: Thu Sep  1 15;52;56 comment by...Juan Pablo and Ankush -->
<p>This is how an event from this ladder (e3a4) looks like (we
need to diagnose it during quite time): </p>
<pre>
 e3a4c1c1 8d0253fd 000b02f3  
     5124: 00f30039 02721e04 1b1201f3 0a030106  
     5128: 0a557d09 02ef02ef 020302ef 0d010109  
     5132: 88028902 02f38702 21020009 411840f3  
     5136: d0c242d0 e3b0c2c4 830253fd 39080001  
     5140: 3b073a1e 4d164c07 4f174ea8 82025001  
     5144: 26f3a102 2811270c a00229f3 611060f3  
     5148: 630c6209 650d640b 6712660e 690d6812  
     5152: 6b026a11 c1c17ff3 </pre>

<!-- Date: Thu Sep 1 15:57:54 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W10L4 
<li>problem n: 1524 
<li>Status: needs_work
<li>Type: Chip_other
<li>Action: Diagnosis
<li>entered by: fernand 
<li>description is:  SB3W10L4 rphi-side looks problematic (z side is empty). It seem as if only 1st chip is being readout. See SVXMon <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=264&frame=2&anchor=15:22:10'> here</a>.</p>    
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W10&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Sep 1 15:58:10 2005 -->
<h4> Problems with e3a4 </h4> 
<pre> 
7cfce3a4 00f38d1c 0203062d 1e760008 
030200f3 8c1c1203 00d08b1c c2c4d0c2 
 
e3a4c1c1 8d2c76fc 001000f3 
05770101 00f30876 09060506 27d08c2c 
c2c4d0c2 
 
73fce3a4 
01f38d01 0604000c d0c200d0 
 
8d2909fc 03040002 02071403 4b044a0c 
07185605 04d0140d c2c4d0c2 
 
 
e3a4c1c1 8d0144fc 030201f3 01013020 
0a0c0028 020c0079 001700f3 56020c04 
0006030e 02ef1417 00f3012a 000f0904 
012603ef 0ff300f3 5b095af3 70f35cf3 
7203710c 13f38a01 15021409 45f38901 
47014610 51205004 88015207 0a090901 
87010b01 412a40f3 5cf342f3 5e035d20 
2ef3a601 30082f15 4c0f4bf3 a5014d07 
671366f3 a40168f3 670b6606 a3016802 
0101a201 00f30a0c 101f0a0c 01c000c1 
00f3017b 090e0e0b 600e0403 7ff30902 
08f3061b 0407054b 00c00d09 001f190a 
00f30d01 0804070f 60095f08 7ff36101 
080f1d16 053c06c2 0d09023d 0d5707f3 
05c106c3 050605c0 1e0b01f3 11f33407 
0203007b 0407190f 09010203 0ff07063 
000f2705 007f0a0e 297c057e 00790a7d 
0e7a007b 02690068 0059396b 1e5a005b 
1e510050 1d520053 1e560157 1cf30054 
273a00c4 0b310030 001c0607 0a7f0e2a 
0d790078 0a030b7b 00710a70 00720073 
00610b77 09620063 00550054 27f30ac6 
 
00070202 00180a06 081b0119 06f30013 
10161917 003a003b 00340b30 31200f35 
0cc73b21 05032701 040e0d02 000d040c 
040b0409 061c0f0a 0f18021d 0070067a 
1d731871 1d771072 0b740176 1ff31675 
0f031a61 05670f62 07640e66 0d0f0065 
001a0704 1d510a50 1c520a53 00101457 
0f551b54 270a02c2 1a1f061f 301d1a1c 
06501818 161c0101 a22701f3 02f32104 
15181d13 1d082716 0e0b0301 011d00f3 
00510306 101f00f3 1d0a03c0 001e001f 
0c08006b 0d010a40 013500f3 02500e2e 
00080006 01010c0c 7ef30107 00f30301 
03f30201 00f306f3 000300f3 c2c202f3 
</pre> 
 
So sometimes the Ladder looses it after the first or second chip, sometimes you get all chip ids and a lot of garbage after a0.  
 
<br> 
Our recommendation: Fiber swap and spare FIB.   
<!-- Author: Drs Clark and Stanitzki (Mystical Studies)  -->


<!-- Date: Thu Sep 1 16:04:44 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7379&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7379  width='300' align='top'></a></td><td>This is our life </td></tr></table>
<!-- Author: The Sillies -->
<!-- Comment: Thu Sep  1 23;59;14 comment by...Ted The Table Guy -->
<pre>you sillies!  This remind me of a long discussion we had back in early 90s at CLEO about whether we should hire 1000 monkeys to run the experiment... there is a chance one of them will eventually get it right.</pre>
<!-- Date: Thu Sep 1 17:58:10 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W3L2 
<li>problem n: 1280 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: fernand 
<li>description is: Bias current redefined in IMON<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>103</td><td>103</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>120</td><td>125</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W3&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Sep 1 18:05:36 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7380&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7380  width='300' align='top'></a></td><td>This is the companion plot that explains the action taken  
above (raising limits). It seems the bias drop is following 
the daq downtime ! ... ? ...  hmmm ... </td></tr></table>
<!-- Author: fernand -->


<!-- Date: Thu Sep 1 20:27:20 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W10L4 
<li>problem n: 1524 
<li>Status: needs_work
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>Marcel and I grabbed a few minutes of quiet time to run this ladder in SVXDAQ.  The ladder was returning no data.  As a quick try we set all the ISEL bits to 1 and all the RDriver to 7.  This didn't help.  The error seems to be like the dead RX seen in f323.  But really need an access to get to the bottom of it.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W10&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Sep 1 21:07:44 2005 -->
MCR called and asked us to put the detector in a safe configuration. The silicon is in STBY but we do not see any problems in the beam from our side (yet..).<br>
<!-- Author: Sebastian -->
<!-- Comment: Thu Sep  1 21;20;11 comment by...Sebastian -->
<h3>Some scary MCR elog entries</h3>
<pre>C:PAK5 in alarm with following status. Store is still intact.
This happened yesterday as well.
-- Thu Sep 1 21:03:02 comment by...marty --  We've informed the experiments and they are turning their Silicon and going into stand-by until we find the safest solution to this problem. </pre>



<!-- Date: Thu Sep 1 21:38:27 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7382&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7382' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7383&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7383' width='300'></a></center>
<!-- Author: Sebastian -->
<!-- Comment: Thu Sep  1 21;43;01 comment by...JP/S -->
In the plots above you can compare the status of PAK4 and PAK5.
MCR is going to try to fix the problems with PAK5 soon...

<!-- Comment: Thu Sep  1 22;23;38 comment by...JP/Sebastian -->
<b>The Tev crew brought PAK5 back. We are ramping the
silicon and the rest of the detector. </b>

<!-- Comment: Thu Sep  1 22;49;40 comment by...s -->
SVT spy mon looks fine (e3a is low, as expected, because of the problems with L4), and SVXMon is ok.


<!-- Date: Thu Sep 1 23:34:14 2005 -->
<h3>More on f03</h3> 
 
Matt send us the A510 schematics (at least a part of them). 
Looks like the pins we bended (J38 A6 and A7) are connected to an EPROM. Specifically,  to A0 and A3 of a 
X28C256, whose A0-A14 pins are the address inputs which select an 8-bit memory location during a read/write...<br> 
 
So, it is possible that we screwed some other PROM in the mainframe which 
is only relevant to this slot...  I mean possible. May be,  
more likely than breaking 
the backplane connector , which looks very robust...<br> 
We could try donwloading the firmware again, but further  
investigation is needed, I think. It would be great to have 
the schematics of the mainframe...<br> 
  
<!-- Author: Jen/Sebastian -->



<!-- Date: Fri Sep 2 05:52:04 2005 -->
Lost RF station Num 7. Crew spoke with MCR, things are fine. We are still taking data with silicon.
<!-- Author: Sebastian -->



<!-- Date: Fri Sep 2 13:35:09 2005 -->
<h3> Access report Stardate 20050902 </h3> 
Somewhere in the demilitarised zone:<br> 
We went in to have a look at e3a4. Fiber swap isolated the problem with the DAQ channel. We then swapped the FIB, that was successful, it seems. <br> 
Summary:<br> 
<b>We came, we saw, We kicked its arse ! </b> 
<br> 
Let's see, if it works during Data taking 
   
<!-- Author: Ankush & Marcel and Sebastian and Juan Pablo -->


<!-- Date: Fri Sep 2 14:10:48 2005 -->
<h3>Access to look at IB0W3 CAEN backplane</h3> 
 
See <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=264&frame=2&anchor=20:23:19'> 
this</a> 
and  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=264&frame=2&anchor=23:34:14'> 
this</a> 
entries for reference.<br><br> 
 
We went in with a borescope (thanks Doug) and look at the backplane of the IB0W3 PS. We found that the actual pins which were bended were J38 A7 and A8. The A8 hole clearly shows a damaged connector, the plastic is dented and the copper conector is further away compared to other pins.<br><br> 
 
At this point we think that the problem is more likely the 
damaged connector (A8) than a problem with one IC (candidate was 
U46) on the mainframe. 
We will talk to Vince and cia about it. The possible plan  
is to try to make the relevant pin on the PS module thicker 
(by soldering).<br> 
 
 
  
<!-- Author: Jen/Sebastian and all -->
<!-- Comment: Fri Sep  2 16;54;11 comment by...Sebastian -->
<br>
Talked to Vince (Hank and Tim), after a long discussion we decided that the way to go would be to make the relevant pin (the one that connects to J38 A8) thicker by soldering on the left side of it (looking into the pin from the backplane) a thin extra layer. We should try to measure the size of the damage or take a photo of the socket...
<br>
Hank will also fix the crate that is misalign (the modules do not fit in properly).<br>

<!-- Date: Fri Sep 2 15:11:25 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W6L4 
<li>problem n: 74 
<li>Status: needs_observation
<li>Type: Chip_capid
<li>Action: Sparse_out_chip
<li>entered by: amitra 
<li>description is: <p>We tried to revive chip a5 but we couldn't get it back without spitting out errors.  If a5 is put into sparse mode and ISEL bits are set to 1, the ladder runs without any errors.  However we cannot run in sparse-mode during data taking.</p>  <p>So we decided to sparse out that chip.  Now the ladder runs fine in SVXDAQ.  Going to make the appropiate changes in the HWDB and let's see how it performs.</p>  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W6&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Sep 2 15:21:37 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W6L4 
<li>problem n: 74 
<li>Status: needs_observation
<li>Type: Chip_capid
<li>Action: Sparse_out_chip
<li>entered by: amitra 
<li>description is: <p>Looking a bit more closely at the HWDB, it turns out chip a5 had its threshold set to 255...BUT....it was still in NN mode not sparse mode.  So it's now in sparse mode and <em>hopefully</em> everything should be OK.</p>  <p>Now we should look at how this ladder performs during data taking.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W6&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Sep 2 15:51:47 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W10/11All 
<li>problem n: 1525 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Swap_FIB
<li>entered by: amitra 
<li>description is: <p>SB3W10L4 was returning any data.  We did a fibre swap to confirm the problem was in the FIB chain and not internal.  We then did a FIB swap and now the error runs error-free.</p>  <p>We shoudl keep an eye on wedges SB310/11 to chekc 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=??">??</a>
    </td>
   </tr>
   <tr>
    <td>
     <b>OUT:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/fibdb/DBreport.pl?serial=149">149</a>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/fibdb/DBreport.pl?prep=??">??</a>
    </td>
   </tr>
  </table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W10/11&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Sep 2 15:55:55 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W10L4 
<li>problem n: 1524 
<li>Status: needs_work
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>During the access we did a fibre swap to confirm the problem was in the DAQ chain and not internal.  We swapped the FIB and now the ladder runs error-free.</p>  <p>We should keep an eye on this ladder to check it runs error-free.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W10&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Sep 2 15:58:42 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W11L3 
<li>problem n: 643 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>During quiet time we playeed with the RDRiver values to remove the CAP-ID errors.  But setting the RDriver to 7 did not help. Fortunatly the error rate is small.</p>  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W11&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Sep 2 15:59:28 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W2L1 
<li>problem n: 784 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>We quickly ran this ladder in quiet time and it gave errors.  But we did not have time to investigate any furthur.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Sep 2 16:05:16 2005 -->
<h3>Quiet Time Studies</h3> 
 
<p>We took the opportunity to do some quiet time studies and made a chip change.</p> 
 
<ul> 
<li>SB3W6L4 (e364) : This chip is now propperly sparsed out.  The threshold is set to 255 and SPARSE mode set.</li> 
<li>SB3W11L3 (e3b3) : This ladder has low level bit problems.  Changing the RDriver didn't help.  Needs more study</li> 
<li>SB0W2L1 (e021) : We quickly ran this ladder in SVXDAQ in NN mode and it gave errors.  But we had no time to investigate furthur</li> 
</ul> 
 
<p>We did a COLD-START to check the detector was back to a good-state and everything is fine.</p>
<!-- Author: Ankush & Juan-Pablo -->

<!-- Date: Fri Sep 2 16:25:09 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W3All 
<li>problem n: 1523 
<li>Status: needs_access
<li>Type: Wedgewide_other
<li>Action: PS_work
<li>entered by: sebastian 
<li>description is: We borescoped the damaged socket. Found that J38 A8 is damaged. Most likely, we will try to make the relevant pin on the PS module thicker so that it makes contact. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W3&layer=All">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Sat Sep 3 00:33:28 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7385&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7386  width='300' align='top'></a></td><td><b>Store 4367 is in.</b> Initial lum is about 100E30. SVT looks fine (e3a4 is back!). Problems starting SVXMon... </td></tr></table>
<!-- Author: Sebastian -->
<!-- Comment: Sat Sep  3 00;49;26 comment by...Marcel -->
Cool .... sometimes we really fix things ...

<!-- Date: Sat Sep 3 01:27:53 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W1L0 
<li>problem n: 1526 
<li>Status: needs_urgent_monitoring
<li>Type: Chip_capid
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Chip a0 has the wrong cap id for 40% of events in run 203513. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W1&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Sep 3 01:34:05 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W9L1 
<li>problem n: 1527 
<li>Status: needs_urgent_monitoring
<li>Type: Chip_capid
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Chip a2 has the wrong cap id for 40% of events in run 203513. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W9&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat Sep 3 02:28:29 2005 -->
<br>SVXMon is still not running... two CO experts are here... If they do not fix this soon I'm leaving...<br> 
Running the High Speed on FIB 149 (the one that was taken out because of problems with e3a4, see <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=264&frame=2&anchor=15:22:10'> 
here</a>). Please leave the test running on tstsvx1 (this is to all the users of this teststand...).<bR>
<!-- Author: Sebastian -->
<!-- Comment: Sat Sep  3 03;02;05 comment by...Sebastian -->
<br>Ok, the CO experts could not fix the problem with SVXMon...
I took a quick look at the data and seems to be fine, for example
for e3a4:
<pre>
                    e3a4c1c1 8d2b41fc 3d010002 
     3940: 3f043e2a 5d195c05 7c045e06 7e0f7d0c 
     3944: 8c2b7f08 8a2b8b2b 4b094a03 71f34c03 
     3948: 73f37222 882b892b a62b872b 461845f3 
     3952: 61054701 6306620c a42ba52b 7f02a32b 
     3956: 0012a22b 02030111 a02ba12b c1c17ff3
</pre>
So, told the experts that it is ok with me if they fix the
problem tomorrow...

<!-- Comment: Sat Sep  3 03;03;51 comment by...s -->
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=736&frame=2&anchor=01:08:42.519'>
Main elog</a> entry about SVXMon problems.

<!-- Comment: Sat Sep  3 03;08;12 comment by...s -->
<pre>Already got some errors in the high speed test, looks like channel 4 gives garbage suddendly for a few events...</pre>


<!-- Comment: Sat Sep  3 15;49;00 comment by...Antonio, etc. -->
<pre>By running over older data (from two weeks ago, and from Thursday) with the old (6.1.0t) SVXMon release, I found that SVXMon was perfectly happy, whereas the data from last night causes it to crash.  Juan Pablo, Sebastian, Marcel, and I put our heads together and realized that one chip on e364 was put into sparse mode on Friday.  SVXMon does not like this and started to crash when it found out.  We took cosmics and verified that switching to(from) sparse mode breaks(fixes) the problem.

Before we run any chips in sparse mode, SVXMon needs to be fixed.  The bug appears to be in the tcl commands for "svx watch."  There may be other problems -- obviously running in sparse mode was not thoroughly tested.

</pre>
<!-- Comment: Sat Sep  3 16;05;09 comment by...DWG Leader / Chief SVXMON Crasher  -->
<p>ahhh...that may explain why e364 was not put into SPARSE when its threshold was set to 255.</p>

<p>yikes !! Guess I'm responsible for the SVXMON crash...cool ;-)</p>

<p>But one question for those not in tune with the insides of SVXMON.  Why would putting a chip in SPARSE mode make it crash in the first place ?</p>

<p>..or is there a line such as

<pre>
if (chipMode == SPARSE) {
    CRASH_MODE = TRUE 
}
</pre>
;-)</p>



<!-- Comment: Sat Sep  3 16;56;02 comment by...Marcel -->
I am afraid, this level of screwup needs an SPL :-) <br>
I think, I suggested to switch it into sparse mode. 
<p><em>
There are more things in heaven, earth and SVXMON, Horatio,
Than are dreamt of in your philosophy.
</em></p>
But anyway, it is another nice present from the past
<!-- Date: Sat Sep 3 13:10:41 2005 -->
<h3>Saturday morning</h3> 
 
<ul> 
<li> Lost the store this morning: 
<pre>-- Sat Sep 3 11:27:01 comment by...djinn --  No quench at all, just the abort. Investigation continues, contacting experts. </pre> 
<li> SVXMon is still not working. CO experts worked through the night but could not fix it. Antonio is here now working on this. 
<li> Since we lost the store we have the possibility of an access, I was planning on taking a picture of the backplane of IB0W3, but a test on the teststand did not worked... Called Rob 
and asked if he can get us a borescope with a camera... 
<li> Mary asked Marcel and I to help her out to pass a cable from the coll hall... We may go in just to do this... 
</ul> 
  
<!-- Author: Sebastian -->




<!-- Date: Sat Sep 3 19:52:51 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W6L4 
<li>problem n: 74 
<li>Status: needs_work
<li>Type: Chip_other
<li>Action: Sparse_out_chip
<li>entered by: fernand 
<li>description is: Due to compatibility-problems with SVXMon, we had to put chip a5 back into NN mode. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W6&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sun Sep 4 02:54:39 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7387&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7388  width='300' align='top'></a></td><td>SVT SPYMON for Store 4369. Everything looks good, SVXMON is working as well </td></tr></table>
<!-- Author: Marcel -->


<!-- Date: Sun Sep 4 05:56:55 2005 -->
Lost communication with crate 7, see <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=739&frame=2&anchor=05:50:30.323'> 
this</a> main elog entry. Shulamit is reseting the crate...
<!-- Author: Sebastian -->
<!-- Comment: Sun Sep  4 06;18;19 comment by...Sebastian -->
Ok, we had some problems with the PSgui, we restarted it but after recovering the wedges it got stuck again. I walked Shulamit over killing the gui, rebooting svxinter and restarting the gui again. This everything is fine and we are taking data. 

<!-- Comment: Sun Sep  4 06;20;33 comment by...s -->
This was done over the phone...



<!-- Comment: Sun Sep  4 12;47;44 comment by...MArcel -->
I hate the GUI ....
<!-- Date: Sun Sep 4 06:53:57 2005 -->
The DOIMs on SB1W7 are pink. Asked Shulamit to hockerize the crate (6).
<!-- Author: Sebastian -->
<!-- Comment: Sun Sep  4 07;03;35 comment by...Sebastian -->
Ok, after restarting the gui again, it froze once more...(?), we are taking data. The DOIMs are fine now.

<!-- Comment: Sun Sep  4 07;19;03 comment by...s -->
This was SB0W7 (not SB1W7..). 


<!-- Date: Sun Sep 4 07:57:52 2005 -->
After hockeriztion the DOIMs went pink again.  
Since the data looks goodm I we will put the cells to ignore for now.
<!-- Author: Sebastian -->
<!-- Comment: Sun Sep  4 09;23;17 comment by...Sebastian -->
Got paged once more.. this time the SPL and MP went off.. nice touch. Ok, SB1W8L2 AVDD is pink (and DOIM e07). Elena put the history plots before paging which is good, but I do not see the HRRs on it (the e18 one). So asked her to HRR at up to 2 mor etimes and see if it comes back, if not put history plot in elog... let's see.

<!-- Comment: Sun Sep  4 09;44;25 comment by...s -->
Luckily Juan Pablo is there. Looks like there was a confusion and the SOC (SB1W7) portcard was turn on... 

<!-- Comment: Sun Sep  4 09;45;21 comment by...s -->
Turned on sometime in the owl shift... we are fine now.


<!-- Date: Sun Sep 4 10:12:14 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7389&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7389  width='300' align='top'></a></td><td>B1W8L2: present and past (future = ?) 
This ladder is showing 810 mA on AVDD while IMON-limit was set to ~600 mA ( to accomodate to the operational fact that the z-side was chopped ).It was declared as an AVDD2 ladder 
long ago. Ignoring IMON for the moment and letting it running. 
Behavior of SB1W8L2 regarding strip occupancy seems normal. 
</td></tr></table>
<!-- Author: Juan Pablo -->
<!-- Comment: Sun Sep  4 16;56;03 comment by...Juan Pablo -->
<h3>More comments about this ladder (AVDD2 type generic):</h3>
<p>
The problems we are seeing
could be caused by a resistive connection in the AVDD2 path
for the problematic chip(s).
</p>
<p> The decrease in current consumption would be a signal of
resistive behavior in the detector
</p>
<p> The resistance in the detector would have to vary with time or
not be a pure resistance to reproduce the vaying behavior of the failure seen in the detector
</p>
<p> The change in the AVDD current usually comes together with other symptons like initialization failure, drop in noise and
drop in gain (also a stuck cell ID has been seen) for that chip(s)
</p>
<p> This device B1W8L2 has being showing a AVDD-current
of ~600mA and has come up to normal values, i.e. ~800mA
</p>
<p>
I do not know for how long it will stay like that but
this current seems to point to a temporary-putative recovery and
could probably initialize ok if the current keeps like that (~800mA). Lets see if that is the case when we have some 
quite time and lets try to retrieve the z-side (in case
it does not fail initialization, we will be able to operate
the z side; in an AVDD2 problem, all chips after the problematic chip are not initialized and cannot function properly).
</p>
<p>
This is just a reminder (to myself) that 10 mA change in the analog current is an indication of the beginning of the AVDD2 problem.
</p>
<p> I found all these details in CDF note 5817 (they even mention this ladder and have some plots about it).
</h3>
<!-- Comment: Sun Sep  4 19;10;55 comment by...s -->
html fix...
<!-- Date: Sun Sep 4 10:28:16 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7390&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7390  width='300' align='top'></a></td><td>This is the occupancy plot (the previous one was 
the strip RMS charge). Both seem normal.</td></tr></table>
<!-- Author: Juan Pablo -->
<!-- Comment: Sun Sep  4 10;32;53 comment by...Juan Pablo -->
<pre>Well, the occupancy on the last channels of the 1st chip
does not look fine. What I meant is that it is not something
new.
Probably it is (and has been) due to a non-flat pedestal.
We might reduce the occupancy by raising the threshold a bit
if starts giving us problems of long readout lenght. </pre>



<!-- Date: Sun Sep 4 14:36:26 2005 -->
<pre>Spike on B0PAAGC during a few minutes. Now back to normal. 
Silicon was on stdby during such a period. Still waiting a bit to 
turn it on again. Plots to come in the CDF elog.</pre>
<!-- Author: Juan Pablo. -->
<!-- Comment: Sun Sep  4 14;52;43 comment by...Marcel -->
right call, looks like an RF station went. Have a look at RFSUM and RFSUMA. 

<!-- Comment: Sun Sep  4 14;53;12 comment by...Juan Pablo -->
<p>
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=740&frame=2&anchor=13:35:57.644'>
 this is the promised link in CDF e-log </a> with the abort gap going like a rocket for a few minutes.
</p>
<p>
Now we are running again and B0PAGC is around 8Khz.
</p>

<!-- Comment: Sun Sep  4 16;27;12 comment by...Marcel -->
that is still rather high for these days, hard limit is 20 kHz, though. Looks like something is happening in the machine, may a quad is moving ?


<!-- Comment: Sun Sep  4 20;11;08 comment by...Marcel -->
MCR now claims, that TRF7 had sparked: 
<p>
<pre>
 We consulted with john Reid. He believes that the station sparked. It may be an after effect from the vacuum bursts we had in the P1 and A1 lines on yesterday day shift. John will look at additional things from home.
</pre>
</p>
<!-- Date: Sun Sep 4 17:09:36 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W8L2 
<li>problem n: 4 
<li>Status: needs_study_time
<li>Type: AVDD2
<li>Action: Diagnosis_update
<li>entered by: fernand 
<li>description is:  This device B1W8L2 has being showing a AVDD-current of ~600mA and now has come up to normal values, i.e. ~800mA  I do not know for how long it will stay like that but this current seems to point to a temporary-putative recovery and could probably initialize ok if the current keeps like that (~800mA). Lets see if that is the case when we have some quite time. My suggestion is to try to retrieve the z-side (in case it does not fail initialization, we will be able to operate the z side; in an AVDD2 problem, all chips after the problematic chip are not initialized and cannot function properly) as long as the current is the expected (~800mA).  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W8&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Sep 4 19:09:23 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W8L2 
<li>problem n: 4 
<li>Status: needs_study_time
<li>Type: AVDD2
<li>Action: IMON_limits
<li>entered by: sebastian 
<li>description is: After current stable for 8hs I'm changing the limits to it's original values (845us, see entries above by Rong and Juan Pablo).<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>602</td><td>800</td></tr>
<tr><td><b>Lower</b></td><td>580</td><td>600</td></tr>
<tr><td><b>Upper</b></td><td>620</td><td>845</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W8&layer=L2">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Sun Sep  4 19;12;56 comment by...s -->
Lets see what it does during quiet time and during next store...


<!-- Date: Sun Sep 4 23:25:20 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W0L0 
<li>problem n: 647 
<li>Status: needs_urgent_monitoring
<li>Type: RX
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Bit 3 high was back for ~20% of events in run 203764. Monitor for recurrence. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Sep 4 23:28:16 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W1L3 
<li>problem n: 1512 
<li>Status: fixed
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Gone. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W1&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Sep 4 23:38:57 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W1L4 
<li>problem n: 1454 
<li>Status: needs_longterm_monitoring
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Physics tails still look a little low relative to the reference run.  If we had the appropriate tool It would be nice to compare tracking efficiency as well. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W1&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Sep 5 00:36:44 2005 -->
Electron lens tripped off. Si was put to STBY, when  
recoverd Si was biased again. See main <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=742&frame=2&anchor=00:04:21.002'> 
elog</a>. 
 
  
<!-- Author: Sebastian -->


<!-- Date: Mon Sep 5 08:15:43 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7391&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7392  width='300' align='top'></a></td><td>Store 4370 looks fine for SVT and SVXMon.</td></tr></table>
<!-- Author: Sebastian -->
<!-- Comment: Mon Sep  5 08;20;47 comment by...s -->
I was not paged last night. This was a miscommunication between me and Larry (psico) and John (monitoring). When I was in the CR last night I told them I was not comming in, and will be over the phone, but I guess they understood there was no need to page me. Will talk to them to clarify the situation.


<!-- Date: Mon Sep 5 08:28:47 2005 -->
<h4> Threshoild change on e351 </h4> 
Had a first look on e351: 
 
<pre> 
after 
e351  2.77703  
e351  2.62907  
before 
e351  4.09801  
e351  3.58341  
</pre> 
Looks like, we are moving in the right direction. Approx one 1 mus less in average is not too bad  
<!-- Author: Marcel -->


<!-- Date: Mon Sep 5 09:23:37 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7393&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7393  width='300' align='top'></a></td><td>RF excursion yesterday, there is a spike in T:RF7UE, from that point on, the Abort Gap got very busy, but the TEL cleaned everything</td></tr></table>
<!-- Author: Marcel -->


<!-- Date: Mon Sep 5 12:09:12 2005 -->
<h3>Week Summary</h3> 
 
<ul> 
<li> Monday: Store 4358 colliding. Dmode with evb2 finally worked.  
RAM technician started working on ISL chiller. 
<li> Tuesday: tests with new TF++ of SVT. Download new VRB firmware in b0svx08 slot 8 (did not give problems). Store  4359 came in. 
<li> Wednesday: access to swapp RX (f323) which worked fine, and to  
swapp ISL PS (f03) which failed due to bended module pin. Slot is broken, plan to make pin in connector A8 J38 thicker to make contact. 
<li> Thursday: major quiet time work. Store 4363 started with EVB problems, Markus had enabled checks which expect data from all the VRBs.. RX which was removed from f323 was tested in BERT teststand and found to have errors. Probelms started with e3a4. 
MCR successfully recoved PAK5 which was in a bad state. 
<li> Friday: swapp FIB for e3a4, success. 
<li> Saturday: problems with SVXMon, traced to the fact that SVXMon crashes if a chip is in sparse mode.  
<li> Sunday: problems with PS Gui early morning. Reset crate/svxinter/etc. e182 AVDD came back to 800mA... 
<li> Monday: store 4370 came in... 
</ul>
<!-- Author: Sebastian and all -->
<!-- Comment: Mon Sep  5 15;39;27 comment by...boveia -->
<b>Monitoring summary</b>
New problems:<p>
e010 chip a0 - bad CAP ID for 40% of events for one run (203513)<p>
e291 chip a2 - bad CAP ID for 40% of events for one run (203513)<p>
e500 - bit 3 high returned for one run.  Keep an eye on it.<p>
f414 - physics tail is still a little low on some chips.  Watch for it to get worse.<p>
<br>
Old problems:<p>
e313 - bit 2 high problem is gone.<p>
<br>
Other:<p>
Discovered SVXMon bug that disallows running chips in sparse mode.<p>