<!-- Title: 11:52:07  Mon May 15 2006 -->
<!-- Crewchief: Ankush (SPL) -->
<!-- Op1: Sasha (MPC) -->
<!-- Op2: The Silis -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<h4>Shutdown Week 12</h4> 
 
<p>We have all returned from Santa Barbara with the Blues...back to dogged Silicon work.</p> 
 
 
<p>The Plan:<br> 
- Try to fix the f502 VBias undervoltage trip<br> 
- Fix the bad ladders found from Friday Week 10&#39s COSMICS run<br> 
- Do a COSMICS run for Wednesday to solve residual problems<br> 
- Get the detector ready for data taking! 
</p>  


<!-- Date: Mon May 15 11:54:52 2006 -->
<h3>Dates to be aware of....</h3> 
 
<p>Solenoid is likely to be turned ON next week.  Must do GB checkout this week to guarantee Resonnance protection.</p> 
 
<p>Cryo/24 shift crew are expected to start up again in 7-10 days.</p> 
 
<p>Hopefully install the additional BLMs this week.</p>
<!-- Author: Ankush -->


<!-- Date: Mon May 15 14:06:00 2006 -->
<h3>tstsvx1 Checkout with new J3</h3> 
 
I have finished checking out tstsvx1 (the B0 teststand) with the new J3 backplane and it is working fine.  All slots for the J3 should be functional now, although slot 8 should only be used as a last resort since it has a pin that has been straightened.
<!-- Author: Mark & Spirit of Obi-Wan -->


<!-- Date: Mon May 15 16:33:19 2006 -->
<h4> b0sili01 had some troubles </h4> 
The /var filesystem was full and required some clean up. Ultimately, I took the system to single-user mode, cleaned everything up and restart things again. <br> 
We should be fine now, sorry, if I had to stop some people's jobs, but the machines was going haywire
<!-- Author: The spirit of Obi-Wan -->
<!-- Comment: Mon May 15 16;40;56 comment by...Yoda -->
FYI, you can actually see, that b0sili01 is always pretty busy:

<a href="http://b0sili01.fnal.gov/ganglia">http://b0sili01.fnal.gov/ganglia </a>


<!-- Date: Mon May 15 18:07:01 2006 -->
<h4>Radiation alarms IV and V</h4> 
The Tevatron was without power this morning. In the course of switching their feeders back on, they triggered a radiation abort at around 16:40, and an integrated dose alarm at 17:10. Steve Hahn  called them to ask if they are done with the exercise. They said yes, and Steve pressed the abort acknowledge button. At the same time, ACNET was acting funny. Neither could I issue a global reset on E2, nor was E4 showing something sensible. We will check out stuff tomorrow again. 
<!-- Author: Ulrich -->


<!-- Date: Tue May 16 09:23:04 2006 -->
<h4>Safety Test</h4> 
A safety test has been performed this morning starting at around 8:20. The test included tests of all crash buttons, so that both the 60 Hz and the 400 Hz detector power was cut off.
<!-- Author: Ulrich -->
<!-- Comment: Tue May 16 09;37;25 comment by...Marcel & Ulrich -->
As as quick check of the system, we:
<ul>
<li>pinged all FIB crates,</li>
<li>checked the state of the GLINKs in SVXDAQ (by performing a "readall" on the FFO), and</li>
<li>took the system through coldstart.</li>
</ul>
Everything checked out fine.


<!-- Date: Tue May 16 10:40:06 2006 -->
Got FFO S/N 105 back from prep where they replaced the glink.  Tested it in the teststand and it ran highspeed test and was able to drive the ghostbuster.  This is now marked as a spare and in the Silicon office.
<!-- Author: Mark -->


<!-- Date: Tue May 16 18:08:01 2006 -->
<h4> b0sili01 successfully rebooted </h4> 
It has also rediscovered its fourth CPU.... good  
<!-- Author: Marcel -->


<!-- Date: Tue May 16 22:17:40 2006 -->
<h3>iFix warnings/alarms published on web page</h3> 
Inspired by our current (shutdown) solution of sending the iFix tag to an alpha-numeric pager for the time when nobody is on shift, I have drafted a script to publish the data on a web page. The idea is the following: 
<ol> 
<li>SVXIICON sends mails with alarms/warnings to some e-mail address (currently <tt>husemann@fnal.gov</tt>) 
<li>A cron job runs a Perl script every 5 minutes which connects to the IMAP server, reads and interprets the mail, and creates a web page. Alarms/warnings older than 24 hours are ignored. 
</ol> 
The page can be found <a href="http://b0sili01.fnal.gov/~husemann/alarms.html">here</a>, please have a look and comment (the current alarms were triggered on purpose to test the code).
<!-- Author: Ulrich -->
<!-- Comment: Wed May 17 14;33;24 comment by...Ulrich -->
Today Marcel created a dedicated account for SVX messages on b0sili01. Since that machine also runs a mail server, we send the mail to <tt>svx-messages@b0sili01.fnal.gov</tt>. The script reads the message directly from <tt>/var/spool/mail</tt> instead of using IMAP. The new page can be found <a href="http://b0sili01.fnal.gov/~svx-messages/ifix_alarms.html">here</a>.
<!-- Date: Wed May 17 08:41:44 2006 -->
<h3>Silicon Grand COSMICS Day</h3> 
 
<p>Today we will shall do the grand Silicon COSMICs day.  The objective is:- 
 
<ul> 
<li>See if f502 trips on undervoltage with the detector ON...then try to fix it.</li> 
<li>Go over odd chip problems and fix them,</li> 
<li>Test the CCC</li> 
</ul> 
 
</p> 
 
<p>Step 1: Cool down the ISL from +10C to +6C</p>
<!-- Author: Ankush -->


<!-- Date: Wed May 17 10:15:33 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>5V Enables are ON</pre></td></tr></td></table>
<!-- Author: sasha -->


<!-- Date: Wed May 17 10:30:02 2006 -->
<h4>ISL chiller calibrations</h4> 
While cooling down the ISL chiller for the silicon tests today, I tried to get the temperature calibration of the ISL chiller straight. We have 
<ul> 
<li>Set point: 10&deg;C, bias: +1&deg;C &rarr; chiller return temperature 10.5&deg;C</li> 
<li>Set point: 6&deg;C, bias: +1&deg;C &rarr; chiller return temperature 7.2&deg;C</li> 
</ul> 
This gives us a ratio of the wanted to the actual temperature gradient of 4.0/3.3 = 1.212. Extrapolating the temperature back to 0&deg;C with this ratio gives a bias of about 1.2&deg;C. I have dialed in these values at the chiller controller. Now I am waiting for the temperature to settle down.
<!-- Author: Ulrich -->


<!-- Date: Wed May 17 10:34:29 2006 -->
<h4>SVXIICON work tomorrow</h4> 
Mark Knapp will work on our iFix PC SVXIICON tomorrow morning between 8:00 and 10:00. He will mirror the hard disk and install "asset management" (in plain words: spying) software to bring the PC in compliance with Fermilab security regulations. Since we will be flying blind during that time, I discourage any silicon work.
<!-- Author: Ulrich -->


<!-- Date: Wed May 17 13:33:46 2006 -->
<h2>More on f502</h2> 
As part of the grand scheme today, we tried to make f502 trip.  Once again, it never tripped as long as it was turned on by itself, or as a couple of bulkheads were turned on.  But once we tried powering the whole detector, then turned f50 off and tried to turn f50 back on... it started tripping.  The trips actually alternate between IB5W0 External Trip (but only L2 trips off) and IB5W0 BIAS12 Undervoltage.  After making it trip the first time, it continues tripping reliably.<br> 
We went down and cabled the power supply to a loadbox, then went through the same procedure.  Again, the supply was fine when turned on by itself.  But after powering all ISL and turning the wedge off/on a few times, the External Trip/Undervoltage trips started happening again.  <b>So it looks like it's the supply that's gone bad.</b><br> 
At this point our options are limited.  We have no spare ISL supplies.  Of the two ISL wedges with L2 out, one of them we already swapped for a power supply with a bad L2.  The other one is located in SE Top Top, which we can't get to unless the CMX arch is pulled back.  Another option is to declare f002 completely dead (since it hasn't returned data since January) and use that supply, which is located in NW Bot Bot.  The only other option is to try and get back from FCC one of the two ISL supplies which had readback problems on L4.  That's definitely a non-optimal solution, but I emailed Hank to find out the status of those readback-problem supplies, see if he's had a chance to even look at them.<br>
<!-- Author: Jen, Jose, Ankush, Sasha, Mark -->
<!-- Comment: Wed May 17 13;48;11 comment by...Ankush, Jen & Jose -->
<h4>seems to like a 2 minute rest after tripping</h4>

<p>After Jen & Jose recabled the supply, f502 continues to trip on VBias1 undervoltage...BUT....if you leave it off for about 2 minutes it will go to STANDBY and ON with no problems.  But it will probably trip again if you go back to STANDBY....very wierd indeed.</p>

<!-- Comment: Wed May 17 14;13;54 comment by...Jen -->
Just heard back from Hank... both of the ISL w/ readback problems have been sent back to CAEN already.  So THAT option is a no-go.  And no idea when we'll get any of these supplies back...
<!-- Date: Wed May 17 14:12:08 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W0L0 
<li>problem n: 1019 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: I was not able to reproduce problems with SVXDAQ in both RA & NN modes. We need to see what is going to happen in next cosmic runs. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed May 17 14:17:54 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W0L2 
<li>problem n: 1622 
<li>Status: needs_work
<li>Type: Optical_other
<li>Action: Light_investigated
<li>entered by: sasha 
<li>description is: This is a very late entry. Some time a month ago, Ankush and I tried to swap a timing cable for this guy. The problem was still with the ladder. I guess it's totally screwed.We'll keep it in HWDB for a while hoping there might be some magic resurection later.    
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed May 17 14:20:43 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W0L4 
<li>problem n: 1610 
<li>Status: fixed
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: While running SVXDAQ, I noticed that this ladder was giving CAP_ID errors from chips 5,8,10, and 11 while in RA mode. However, there are no errors in NN mode after 5K events. So, I still keep it fixed.   
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W0&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed May 17 14:38:25 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W1L2 
<li>problem n: 1586 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: I tried with ladder in SVXDAQ one more time. It's OK in NN & RA modes. So, I still can't reproduce the errors. Let's what is going to happen in the next cosmic runs. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed May 17 14:47:54 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W1L3 
<li>problem n: 184 
<li>Status: fixed
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: While running SVXDAQ, I noticed that CAP_ID errors are still there but at very low rate: 10/3000. So, I guess I'll keep it in category 'fixed', but it may be interesting to take a look what is going to happen to this ladder in cosmics. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W1&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed May 17 15:02:49 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W1L4 
<li>problem n: 185 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: This ladder is giving 00_Sequence errors in NN and RA modes. Changing R-driver values has no effect. Need to see how it's  going to behave in comming cosmic runs. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W1&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed May 17 18:05:19 2006 -->
<h3> f220 access report </h3> 
 
<p>f220 developed bit0 low problems recently. We tested this ladder with SVXDAQ and re-confirmed the errors. So, we went to the collision hall to do a fiber swap which showed that the problem is with RX. The RX swap fixed the problem.</p>
<!-- Author: sasha/ankush/mark -->
<!-- Comment: Wed May 17 21;47;50 comment by...Ankush -->
<pre>Nope...the errors transformed from Bit 0 to Bit 3...and then nothing at all after a marvelous RX swap.....</pre>
<!-- Comment: Thu May 18 08;13;33 comment by...sasha -->
<pre>It's weird... I remember there were no errors right after we left the collision hall. Regarding the bit3 error, it installed an RX was a bit3 suspect but was good in BERT and FCC test stands.</pre>
<!-- Date: Wed May 17 19:14:33 2006 -->
We turned off b0fib03 to swap a FIB, causing a PSM alarm.  Sorry if this cause you to get paged Ulrich.
<!-- Author: Mark & Ignacio -->


<!-- Date: Wed May 17 19:15:54 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8601&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8602' ></a></center>
<!-- Author: Mark/Ankush/Ignacio/Sebastian -->
<!-- Comment: Wed May 17 19;17;35 comment by...Mark/Ignaci/Ankush/Sebastian -->
Sebastian carried out a test of the CCC cards for SVX and ISL this afternoon which involved pulling clock cables.  As you can see from the picture, the test was a huge success since only half of SVX tripped.


<!-- Comment: Wed May 17 23;21;49 comment by...sebastian -->
I pulled the beam structure on both SVX and ISL, no problems (we were taking data). then I pulled RF on ISL, again no errors or trips. then I pulled RF on SVX and we tripped. This si not a surprise, since we know from previous test that the CCC is sensitive to RF glitches. Since ISL is more robust and the ISL CCC is somehow better behaved (the SVX one, 0x5000, gives intermitent GP errors which are not understood) we could try swapping the CCCs.
<!-- Date: Wed May 17 21:04:58 2006 -->
<h3>Shutdown may end early...</h3> 
 
<p>It seems D0 are ahead of schedule and all the Zebra muscles are dead...so the shutdown could end as early as the end of the month....so we should definitly make the push to resolve all the detector problems this week and really make sure we are ready for data taking.</p>
<!-- Author: Ankush -->


<!-- Date: Wed May 17 21:12:42 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>5V CAEN Enables OFF</pre></td></tr></td></table>
<!-- Author: Ankush -->


<!-- Date: Wed May 17 21:46:41 2006 -->
<h3>Great Silicon kick in the 'nads</h3> 
 
<p>The grand plan to resolve all the residual detector problems today was a total disaster.  We confirmed the VBias undervoltage of f502 is a CAEN problem.  But we have NO ISL spares(!!) and the trick of swapping supplies can only be done if the SE Arch is pulled in.</p> 
 
<p>....However, after speaking to Steve Hahn, Dervin will pull the SE arch in tomorrow.</p> 
 
<p>The CCC test was fantastic....before we would trip if RF or Beam Structure was lost. Now only if Beam Structure is lost on the SVX CCC, does half of SVX trip.</p> 
 
<p>Sasha went through his list of problem ladders from the last COSMICs run and could only reproduce the bit 0  error for f220.  So we did a fibre swap which pointed to a DAQ problem. We gambled on a RX problem and put a new one in. It appeared to fix the problem.  BUT...the histrograms from SVXDAQ did not look right.  It appeared the Analog FE was saturated on the R-Phi for all ISL/L00 ladders.  SVX seemed to be OK.  After initialising the RAM Pedestal for the FIB, the R-Phi side returned hardly any data.....something very wierd is going on !!!...</p> 
 
<p>Then f220 was starting to give problems again.  But this time the error was on bit 3. We repeated the Fibre-Swap and it still stayed with the DAQ channel.  So we thought it now must be the FIB.  THe FIB was swapped but the bit 3 error remained.  Looking into the history of the swapped in RX (RX 0457), it had suffered from Bit 3 but was now deemed to be OK.  So we did a second RX swap and put in RX 1009.  This time NO data at all was returned...we were getting no chip-ID in SVXDAQ....things just going from bad to worse....</p> 
 
<p>...but at least the FIB2VRB test returned no errors...so hopefully we didn&#39t bugger any thing up with the FIB swap.</p> 
 
<p>Then to top it all off, Arsenal lost 2-1 to Barcelona after they scored the first goal.</p> 
 
<p>Overall, a crappy day :-(</p>
<!-- Author: Ankush -->
<!-- Comment: Wed May 17 22;29;08 comment by...Ulrich -->
Not to mention Lehmann&#039;s red card in the 18th minute...
<p>
The ISL has been warmed up again to 10&deg;C. I still do not understand how the calibration works. We will have another chance tomorrow, after Mark Knapps SVXIICON work.


<!-- Comment: Thu May 18 07;15;18 comment by...Oscar (for the spanish side of the silicon) -->
A remark... the result of the Champions League is not considered bad by everybody in the silicon group :)


<!-- Comment: Thu May 18 08;21;23 comment by...sasha -->
<pre>Regarding bit3 problem of RX0457, yes it was a bit3 suspect. However, both BERT and testing at FCC setup for SVX showed that it was perfectly normal.</pre>


<!-- Date: Thu May 18 08:32:22 2006 -->
<h4>SVXIICON work</h4> 
Mark has started his work on SVXIICON at around 7:50. He will mirror the system disk and install asset management software. Estimated time: 2 hours.
<!-- Author: Ulrich -->
<!-- Comment: Thu May 18 09;26;05 comment by...Ulrich -->
Mark finished about 8:50. Now starting to cool down ISL again.
<!-- Date: Thu May 18 09:04:39 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W8L0 
<li>problem n: 1497 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Tried in SVXDAQ--no luck. Let's see what is going to happen during cosmic and calibration runs. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W8&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu May 18 09:05:55 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W8L0 
<li>problem n: 1642 
<li>Status: needs_observation
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: No CAP_ID problems in SVXDAQ. Continue observations. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W8&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu May 18 09:10:51 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W8L2 
<li>problem n: 1394 
<li>Status: needs_observation
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: No CAP_ID problems in SVXDAQ.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W8&layer=L2">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Thu May 18 09:31:00 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>5V Enables are ON.</pre></td></tr></td></table>
<!-- Author: sasha -->


<!-- Date: Thu May 18 09:46:01 2006 -->
<h3>The Plan....or I just woke up!!</h3> 
 
<p>While I try to get ready ASAP, this is the plan...</p> 
 
<pre> 
SE Arch Move and f502 PS Swap 
- The SE Arch has moved.  Can Jen, Jose and Ulrich go into the collision and set up the ladder for the PS swap.  Then I guess Jose & Jen can take of things 
 
ISL/L00 Front End Problems 
Is the Analog FE still looking saturated ? 
If it is, double check the SVXDAQ settings.  If they look OK, can you grab Sebastian for advice.  It may or may not be CCC related.  I'd like this fixed first since I believe it's something obvious that wasn't done. 
 
Then follow up f220.  Do another fibre swap and confirm the problem is with the DAQ.  If it is a DAQ problem, check the VRB is not responsible.  Then consider repeating the FIB or RX swap. 
 
Can Sasha, Mark and Oscar look after this.   
</pre>  
<!-- Author: Ankush -->
<!-- Comment: Thu May 18 10;12;03 comment by...Mark -->
Weird FE problem is fixed.  I was stupid and had not turned Tracer Mode off.

<!-- Date: Thu May 18 11:04:40 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W2L0 
<li>problem n: 1548 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Swap_RX
<li>entered by: mhartz 
<li>description is: We did a fiber swap and found that the bit 0 error stayed with the DAQ channel 0.  We first swapped RX 0457 but saw bit 3 errors.  This was no suprise as this RX has a history of bit 3 problems in the collision hall, even though it was fine in the BERT teststand.  We then swapped in RX 1009 and the channel now shows no bit errors in 10,000 events in svxdaq. <table border=1>
   <tr>
    <td>
     <b>IN:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=1009">1009</a>
    </td>
   </tr>
   <tr>
    <td>
     <b>OUT:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0161">0161</a>
    </td>
   </tr>
  </table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B2W2&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu May 18 11:21:51 2006 -->
<h3>The Saga of f220</h3> 
Yesterday we did a fiber swap for f220 which was exhibiting bit 0 low errors.  Since the errors stayed with the DAQ channel we did an RX swap, swapping in RX 0457.  This RX had a <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W8&layer=L3">history of bit 3 low</a> but had been tested with no errors using BERT.  The bit 3 errors appeared for f220, so we tried swapping in another RX, 1009 (in this process the FIB 105 was swapped in as well).  After swapping in RX 1009, we were seeing no data for f220.  This is how we left it last night.  This morning Sasha and I went in and found that the wrong fiber was plugged into channel 0, hence the lack of data.  After fixing this, f220 exhibits NO errors in svxdaq.
<!-- Author: Mark/Sasha/Ankus/Oscar/Ignacio -->

<!-- Date: Thu May 18 16:16:15 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W1L2 
<li>problem n: 1586 
<li>Status: needs_observation
<li>Type: RX
<li>Action: Swap_RX
<li>entered by: sasha 
<li>description is: We finally reproduced bit4 error with SVXDAQ. So, we did a fiber swap which showed that the problem is with DAQ. We swapped the RX. The swap was successful. So, this ladder is OK now.<table border=1>
   <tr>
    <td>
     <b>IN:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0418">0418</a>
    </td>
   </tr>
   <tr>
    <td>
     <b>OUT:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0477">0477</a>
    </td>
   </tr>
  </table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu May 18 16:17:30 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W1L2 
<li>problem n: 1586 
<li>Status: fixed
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: The problem is fixed after the RX swap. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu May 18 16:22:28 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W11L2 
<li>problem n: 1588 
<li>Status: needs_work
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: We did a fiber swap which showed that the problem is with DAQ. Then, we swapped the fib (it was easier that swapping RX). It didn't fix the problem. We need to swap the RX next.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W11&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu May 18 16:26:49 2006 -->
<h2>The CONTINUING saga of f502</h2> 
So the SE CMX arch was moved back this morning, and we went in to get IB4W3 (using the big ladder).  Then we removed IB5W0, and tried to put in the supply for IB5W0.  That's where the fun started - the ladder we had in the NE corner was too short, and we couldn't wrestle the power supply in.  In fact, in trying I managed to knock off one of the pins used to measure the bias trip setting on L0.  This doesn't affect anything, it just means you can't measure what the bias trip limit is.  The techs at FCC should be able to fix it, but since we shouldn't have to change the trip limits anyway, we just left it as is for now.  To make sure, I tested the supply quickly on the teststand after we gave up trying to install it.<br> 
Next, we decided to just try putting the IB5W0 supply in for IB4W3 using the big ladder, then we'd move the big ladder over to IB5W0 to put the other supply in.  More fun: we got the IB5W0 supply in for IB4W3, but when we tried to power it, f434 started tripping bias overcurrent.  Turns out there's a pinhole on that layer, and the previous power supply had special bias splitting on that layer to account for it!  We decide to take both supplies upstairs, and adjust the bias splitting on the old IB5W0 supply as it should be for IB4W3.<br> 
Confused yet?  But wait, there's more!  It turns out that the old IB4W3 supply is ACTUALLY a central ISL supply with special adapters to make it look like a forward supply!  And the special ADAPTERS were modified to give the 50-50 bias splitting on L4!  The old IB5W0 supply is a normal ISL foward, so in order to make the swap, we would have had to switch BOTH the resistors on 3 separate layers between the two supplies.  Trying to modify them both that much takes time and leaves a high probability of screwing up... in the end, we decided to put the IB4W3 supply back in for itself, and instead switch IB5W0 with IB0W0 (which has L2 not returning data).<br> 
We went back, put back IB4W3 - everything checked out fine.  We then took out IB0W0, and put in the supply from IB5W0 - so far that looks good.  Then we tried to bring the big ladder over to the NE corner to install the IB0W0 supply for IB5W0, and found that the NE CMX arch was too far out for us to get that ladder in there.<br> 
So once again, we end the day waiting for Dervin to pull in an arch tomorrow.  We're trying to get both the arches on the North side moved in, that will make the work in NW easier too.  At this point, the old IB0W0 supply is sitting upstairs, and crate 10 is off waiting for the supply to be installed.  If we're really REALLY lucky, maybe we can get this IB5W0 thing finished off tomorrow...<br>
<!-- Author: Jen, Jose, Ankush, Mark, Sasha, Ulrich -->


<!-- Date: Thu May 18 16:35:28 2006 -->
<h3>Access for f012 and e0b2</h3> 
We made an access to study and attempt to fix two ladders: 
<ul> 
<li>f012 - This ladder exhibited bit 4 low in both data and svxdaq.  We did a fiber swap and found that the error stayed with the daq channel.  An RX swap fixed the bit 4 low error and this ladder is now error free. 
<li>e0b2 - This ladder drops readout at seemingly random points in readout.  We were able to reproduce in svxdaq and first tried swapping VRB channels, which did not fix the problem.  Next we tried a fiber swap at the FTM which showed that the error stayed with the DAQ channel.  Since this is at NET and the arches are out, we tried swapping the FIB next since we can get to the front of the crate.  This did not fix the problem, so we will try an RX swap tomorrow after the arches are moved in. 
</ul> 
 
In summary,f012 is fixed and e0b2 is still a problem.  It looks like e0b2 has been giving dropped readout off and on since the <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=172&frame=2&anchor=14:48:11'> 
backplane for fib00 was swapped</a> back in the 2003 shutdown.  Would any of our resident Jedi Masters like to comment on the details of that backplane swap? 
<!-- Author: Mark/Sasha/Ankush/Ignacio... -->
<!-- Comment: Thu May 18 16;58;14 comment by...Obi-Wan -->
You should ask yourself the following questions concerning the backplane
<ul>
<li> All the clock and Command signals are shared between all the FIBs in one crate. Do you see any problems in any other FIB ?</li>
<li>If it is only this FIB, all ten ladders should be affected if those signals are bad. Do you see something like that ? </li>
<li> The only exclusive connection between HDI 7 and the Pipe 7 is the J3 connection between FTM and FIB. One point could be to have a look at this slot, did you check this ? </li> 
<li> What does D0 actually mean ? </li> 
</ul>
I hae to judge before all the facts are in, but at the moment, it looks unlikely, that it is the J3. I would try the RX first and if this fails, try another FTM to really exclude the FTM and do a visual inspection of the backplane. 
<!-- Comment: Thu May 18 21;06;11 comment by...The spirit of Farrukh -->
<p>...as Farrukh would say..."next he&#39ll be telling us how to scratch our bund.</p>
<!-- Comment: Thu May 18 22;40;40 comment by...The Ghostbuster -->
As everyone can recognize, this so-called spirit of Farrukh is a forger, because the real spirit of Farrukh would use much more colourful expressions.  
<!-- Date: Thu May 18 16:38:21 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W10L4 
<li>problem n: 603 
<li>Status: needs_work
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: mhartz 
<li>description is: This ladder's capid errors for chip 88 are reproducible in svxdaq, but the error where chip 8d is identified as chip 8f with capid f3 is only seen in dmode calibrations.  We should check the next cosmics run (make sure we write to look area) for the chip 8d errors.  In the meanwhile chip 88 is sparsed out. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W10&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu May 18 16:41:05 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W11L4 
<li>problem n: 1381 
<li>Status: needs_work
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: mhartz 
<li>description is: Verified the stuck capid error for chip a3 in svxdaq.  This chip is still sparsed out for data taking, so no changes needed.  We may want to unsparse when we finally have beam so the monitoring group can verify that the data is bad.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W11&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu May 18 16:50:25 2006 -->
<center><a href='/elog/notebooks/silicon/Thu_May_18_2006_164948.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8604' ></a><a href='/elog/notebooks/silicon/Thu_May_18_2006_165005.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8606' ></a></center>
<!-- Author: sasha -->
<!-- Comment: Thu May 18 16;52;02 comment by...sasha -->
<pre>e012 before (left plot) chip a4 started giving errors in SVXDAQ and after (right plot) errors re-appeared.</pre>


<!-- Date: Thu May 18 17:10:03 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W1L2 
<li>problem n: 2 
<li>Status: needs_work
<li>Type: AVDD2
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: I tested the ladder in SVXDAQ. It didn't have any errors for first 2K events and all distributions looked OK. However, after 2K events it started giving CAP_ID problems from chips 4 & 5. Also and init read back problems (see <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=301&frame=2&anchor=16:50:25'> e-log </a>). So, it's still affected by AVDD2 problem. Needs more observation and quiet time studies.    
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu May 18 17:11:53 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W1L2 
<li>problem n: 1635 
<li>Status: needs_observation
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: CAP_ID problems can be reporduced in SVXDAQ. This problem is likely to be a consiquence of AVDD2 (see thread 2). 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu May 18 18:51:22 2006 -->
<h3>Ghostbuster Checkout</h3> 
I checked that the ghostbuster works for ISL and SVX.  The only failure was channel 0 in SVX and this a known problem due to a bad SRCTM.  <b>Please do not reboot the VRB crates now, and if you absolutely have to, let me know afterwards</b>  
<!-- Author: Mark -->
<!-- Comment: Thu May 18 20;34;47 comment by...Mark -->
That should be: <b>Please do not power cycle the VRB crates</b> 


<!-- Date: Thu May 18 21:01:09 2006 -->
<pre>Old and New BLMs have been installed on East and West.</pre>
<!-- Author: Ulrich and Jose -->
<!-- Comment: Fri May 19 11;28;02 comment by...Jose & Ulrich -->
<h3>BLM and diamond installation summary</h3>
Yesterday we have installed four new BLMs and four new diamond detectors, two on each side of the detector. Out of the four diamonds, two are regular CDF diamonds, and two are prototypes for CMS. The new BLMs are the following:<p>
<table border='1' cellpadding='5'>
<tr><th>Position</th><th>S/N</th><th>Calibration (10<sup>7</sup> rad/C)</th></tr>
<tr><td>West Lower</td><td>02280503</td><td>1.13</td></tr>
<tr><td>West Upper</td><td>02150504</td><td>1.05</td></tr>
<tr><td>East Lower</td><td>07290401</td><td>1.01</td></tr>
<tr><td>East Upper</td><td>02150505</td><td>1.10</td></tr>
</table>

<p>
Currently, we have daisy-chained the HV for the BLMs on the West side and on the East side separately. The reason is that the HV cable which was supposed to connect the East and the West BLMs is about 2 m too short on both sides. We are expecting 10 ft extensions on both sides from Dervin. We will have to go in again and re-cable the HV then. We have also connected the second HV line, so that we have the option of monitoring the HV. We have checked with that line that the HV is hooked up correctly.
<p>
It is also worth noting that the whole system is now a bit heavier than the old system. As a consequence, we fixed the upper shell to the green CLC frame as well. The East side had a metal piece to connect to the frame, and on the West side we used a cable-tie.


<!-- Date: Thu May 18 21:03:53 2006 -->
<h3>COSMICS...Finally</h3> 
 
<p>After another long day we finally got round to doing a COSMICS silicon run. CAEN Crate 10 was still off, so we put all its ladders offline.  Then as a double check we did a COLDSTART and found an SVX ladder failed to initialise and returned no data.  A quick trip to the collision hall and we discover the fibre was not connected.</p> 
 
<p>So once we got over that mistake the Silicon was biased and then we had to mask some HV inhibits as CAEN crate 10 was off.  So around 8pm the started the Silicon COSMICS Tape and made sure the data went to tape.</p> 
 
<p>We ran for about 15 minutes and it seem to be OK.</p> 
 
<p>We then turned the detector OFF and started warming up ISL from +6C to +10C.</p>
<!-- Author: Ankush, Mark, Oscar & Ignacio -->
<!-- Comment: Fri May 19 08;57;11 comment by...Ankush -->
<pre>The run number for the this COSMICs is 216319</pre>
<!-- Comment: Fri May 19 09;00;40 comment by...sasha -->
<pre>hmm... weird. What ladder was it? </pre>
<!-- Comment: Fri May 19 10;09;34 comment by...Mark -->
It was e011, which is next to e0b2, so I must have somehow disconnected it while reaching around for e0b2, e0b0 and e0b4.  The weird thing is that it was sitting in the connector, just not clicked in.
<!-- Date: Thu May 18 21:11:08 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>CAEN 5V Enables OFF</pre></td></tr></td></table>
<!-- Author: Ankush -->





<!-- Date: Fri May 19 09:38:38 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030>5V Enables are On.  Alarms Ignored.</td></tr></td></table>
<!-- Author: Mark -->



<!-- Date: Fri May 19 11:18:41 2006 -->
<br> 
<B>Diamond Installation (continuation)</B> 
<br><br> 
The BLM people (Urlich, Jose...) put 4 additional diamonds on place yesterday:  
<br> 
<br> 
East Side: 
<br> 
diamond <b>A422-10</b> goes to cable <b>E_DIA_BML_1</b><br> 
diamond <b>CMS-S5 </b> goes to cable <b>E_DIA_BML_2</b><br> 
<br> 
West Side: 
<br> 
diamond <b> A6T0-6 </b> goes to cable <b>W_DIA_BML_1</b><br> 
diamond <b>CMS-S4 </b> goes to cable <b>W_DIA_BML_2</b><br> 
<br> 
The diamonds have been powered this morning and they seem to have reasonable currents, even if they start a bit high. 
<br>Note: the CMS diamonds have been powered at 300V, the CDF diamonds at 500V. 
<br><br>
<!-- Author: the diamond people -->



<!-- Date: Fri May 19 12:59:21 2006 -->
<h3>The conclusion of f502</h3> 
Dervin & Co had the lifts in place on NE corner by about 10am, so we went down to put the IB0W0 supply in for IB5W0.  We put it in, cabled it up, turned the crate on, and voila!  The 2V DOIM current limit had to be raised to keep it from tripping, and the AVDD currents are all pink and need to be adjusted, but so far no sign of external or undervoltage trips on f502.  For now, the swap looks like a success.<br> 
While I was down there puttering around, I also found time to check all the labels on the SE and NW crates.  This completes all the power supply labeling I had left to do; every supply (including IB5W0!) should now have a correct label denoting which wedge it's hooked up to.<br> 
In other good news... I saw Tim Kazsa over at FCC today, and he said he'd talked with CAEN earlier this week about the two ISL supplies we'd sent them a month ago.  According to them, the supplies are being "processed" and should be here in two weeks or so!  We may actually have spare ISL supplies before the end of shutdown!<br>
<!-- Author: Jen, Mark, Ankush -->
<!-- Comment: Fri May 19 14;38;33 comment by...Ankush -->
<p>Afterwards I reset the 2V DOIM Current limit to its original value. This supply needed to have the limits for f50* downloaded.</p>
<!-- Date: Fri May 19 13:02:51 2006 -->
<h3>First Go at e0b2</h3> 
We went in this morning to replace the RX for e0b2.  Unfortunately we could not get the lift working on the back side of the crate, so we had to pull out the FTM from the side.  After replacing the RX the whole FIB was taken through ColdStart with no errors.  e0b2, however, still exhibits the same dropped readout.  Ankush and Sasha are now going to replace the FTM to see if that is the problem.
<!-- Author: Mark/Jen/Ankush/Sasha -->


<!-- Date: Fri May 19 14:17:15 2006 -->
<h2>Victory with e0b2</h2> 
Sasha and Ankush swapped in a new FTM for e0a/b in the hopes of fixing the dropped readout of e0b2.  This was a success and e0b2 is now running error free in svxdaq.  It also looks like this may have fixed low error rates for e0b1 and e0b3.  The only ladder in these two wedges that is still giving errors in svxdaq is e0b4 which has an unfixible bit 5 error.  e0a0 did trip a couple of times on DVDD overcurrent, but we expect this is the usual svxdaq silliness since it is now holding fine.  We checked the wedges connected to the neighboring FTMs in svxdaq and also took the whole of b0fib00 through Config with no problems.  
<!-- Author: Mark/Ankush/Sasha/Jen -->
<!-- Comment: Fri May 19 16;51;09 comment by...Ankush -->
<h4>...but we may need to look at the FTM again...</h4>

<p>An oversite on my part but I forgot to write down the FTM serial number and the RX serial numbers that were on the FTM. So (probably Monday), we shall have to pull the FTM out to read off the serial numbers for our documentation.</p>
<!-- Date: Fri May 19 15:53:21 2006 -->
<h3>Finishing up BLM work</h3> 
Today, we finished the BLM work. We 
<ul> 
<li>fixed the cables more nicely,</li> 
<li>re-checked the cabling and put up <a href="http://www-cdf.fnal.gov/~husemann/internal/expert/radmon/doc/blm_cabling_shutdown2006.pdf">new cabling lists</a> for the old and the new BLM system,</li> 
<li>confirmed that the HV lines are properly connected</li> 
<li>insulated the diamond connectors</li> 
<li>took more pictures of the scene.</li> 
</ul>
<!-- Author: Jen, Jose, Anna, Ulrich -->


<!-- Date: Fri May 19 16:17:03 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Remember...return keys by 5pm</pre></td></tr></td></table>
<!-- Author: Ankush -->


<!-- Date: Fri May 19 16:37:13 2006 -->
<h3>One more diamond</h3> 
Rainer&#039;s diamond gang had another CMS diamond to be installed close to the BLM. There are no additional diamond cables, but some of the new BLM cables will most probably not be used in the system. There is no bleed current source and no HV monitoring foreseen in the new system, so one signal cable and one HV cable per side are free. We decided to go to the East side. The signal cable is 86809, BLM S2 E SIG, and the HV cable is 86811, BLM 4 E HV. The diamond is currently being tested and glued to the BLM fixtures.
<!-- Author: Rainer, Anna, Ulrich -->
<!-- Comment: Fri May 19 18;03;12 comment by...rainer for the diamond gang -->
<pre>one small comment: all diamonds are not glued but velcrowed, with tape support. they should come off easily if one needs to dismount the BLMs. thanks for giving us your cables.</pre>
<!-- Date: Fri May 19 16:43:28 2006 -->
<h4>Chiller calibration: still confused..</h4> 
So I took another attempt on chiller calibrations. From yesterday&#039;s cool-down, I got measured values (i.e. from the sensor to be calibrated) of 8 &deg;C and 11 &deg;C at true values (i.e. from the chiller return temperature) of 6 &deg;C and 10.2 &deg; C. From that, I infered a slope of 0.714 and a bias of 3.7. Let&#039;s see if this works out... 
<!-- Author: Ulrich -->



<!-- Date: Fri May 19 17:35:01 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8613&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8614' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8607&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8608' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8609&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8610' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8611&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8612' ></a></center>
<!-- Author: Rainer & Ulrich -->
<!-- Comment: Fri May 19 18;01;51 comment by...Anna, Ulrich, Rainer -->
<pre>View of the west and east side BLMs. the west side has two diamonds in the upper hemisphere: CDF-46T0-6 on the left, CMS-S4 on the right (towards center of beam). The east side has two diamonds in the lower hemisphere and one in the upper: left CMS-S5 (towards center of beam) and A422-10 on the right. left and right is always looking towards the center of CDF. In the upper hemisphere,  we mounted CMS-P1. CMS-P1 uses spare BLM cables 86811 SVX N2E/BLM-4-E-HV and 86809 SVX N3E/BLM_S2_E_SIG. Thanks to the BLM gang for giving us these cables. </pre>



<!-- Date: Mon May 22 09:29:12 2006 -->
<h3>Week summary</h3> 
<p><h4>Ladders fixed</h4> 
<ul><li>f220, f012 -- RX swap</li> 
<li>e0b2 -- FTM swap</li> 
<li>e0b1 & e0b3-- low rate errors are possibly fixed by FTM swap; need more observation</li>  
</ul></p> 
 
<p><h4>Ladders still bad</h4> 
<ul><li>f000 & e280 -- can't treproduce in SVXDAQ</li> 
<li>f014 -- 00_Sequence errors in SVXDAQ</li> 
<li>e1a4 -- CAP_ID problems</li> 
<li>e012 -- return of AVDD2 problems (chips 4 & 5)</li>  
</ul></p> 
 
<p><h4>f502 Power Supply</h4> 
<ul>Trips on bias undervoltage; fixed by swapping PS with f00* wedge</ul></p> 
 
<p><h4>Cosmics Run 216319</h4> 
<ul>Still to be looked at</ul></p> 
 
<p><h4>CCC live test</h4> 
<ul>Still trips, but "anti-trip robustness" is greatly improved</ul></p> 
 
<p><h4>Chiller calibration</h4> 
<ul>Some confusion still remains</ul></p> 
 
<p><h4>BLM & Diamonds</h4> 
<ul>Successfully installed</ul></p> 
 
  
<!-- Author: sasha -->