<!-- Title: 11:01:01  Mon Jun  5 2006 -->
<!-- Crewchief: Sasha (MPC) -->
<!-- Op1: Ulrich (SPL) -->
<!-- Op2: The Silis -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<h3>Coming out of the shutdown</h3> 
 
<p>The Tevatron is back up and doing studies to get the beam back in place.  So there will be beam in the Tevatron on and off all week. </p> 
 
<p>We (& CDF) have requested a request to swap an RX and do a light level measurment.</p> 
 
<p>Items for this week: 
<ul> 
<li>Swap RX and do Light Level Measurement</li> 
<li>...and permanent Light Level Measurement</li> 
<li>Exchange cooling resin</li>  
<li>Get CCC working for ISL</li> 
<li>Check b0dasvx03 is coping with the SL3 upgrade</li> 
<li>Bug CAEN to get a working ISL PS back again</li> 
</ul> 
</p> 


<!-- Date: Mon Jun 5 13:01:10 2006 -->
<h3>Clock work...</h3> 
While stealing a banana from the control room, I overhear that Steve Chappa the clock guy is resyncing the clock back to the 53MHz TeV clock (TEVSYNC?). 
<p> 
If I don't see anyone before I leave, I'll page our SPLs so that they know. 
<p>Right now, Steve says that the clock might be a bit off; he'll revisit before we have beam.
<!-- Author: Jennifer :-) -->


<!-- Date: Mon Jun 5 13:22:47 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8659&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8659  width='300' align='top'></a></td><td>LA Trace after the clock switch over</td></tr></table>
<!-- Author: Ankush -->
<!-- Comment: Mon Jun  5 13;29;21 comment by...Ankush -->
<p>Looks like the clocks from the SRCs are still in sync aftert the clock work.  I looked at the CCC and it reports the following:</p>

<pre>
Your pick? 0x2
Status: 0, Read: 3e
BZ error
BX error
SY error
GP error
Master clk error
CCC is locked to RF
</pre>

<p>I haven't cleared the errors yet.</p>

<!-- Comment: Mon Jun  5 13;49;28 comment by...Ankush -->
<p>Just started up SVXDAQ and did the following:</p>

<pre>
***  SVX  Cards ***

* SVX
- Opened SRC page & did READ ALL
- It gave error for To TSI Error.  Did an HRR & another READ ALL and this cleared the SRC Error.

* VRB
- Opened VRB menu and did a READ ALL.  Only error for High Occupancy came up.

* FFO
- Opened FFO page & did READ ALL to see Readout Return was not enable.  I enabled it and did another READ ALL.  Readout Return was on and GLINK gave a green light.

* FIB
- Did a READ ALL and no problems seen.

* GB
- Did a read all.  GB channels are enabled with 10 ticks set.

*** ISL Cards ***
* SRC 
- Same as SVX SRC.  Gave an error for To TSI Error.  AN HRRR and Read All cleared the error.

* VRB
- Same as SV VRB.  Only High Occupancy error

* FF0
- Readout return was again not enabled after a Read All.I enabled it and did another Read All.  Readout Return was enabled and GLINKs gave a green LED.

* FIB
- Did a Read All and no errors spotted..

* GB
- Did a Read All and all channels enabled for 10 ticks.
</pre>

<p>Did a COLDSTART and forced a transition to ACTIVATE. I ran for a few hundred events and no problems seen.</p>


<!-- Comment: Mon Jun  5 17;18;05 comment by...Sebastian -->
Just to note that it is a very good thing that <b>the CCC did not
loose lock while CDF switched clock modes</b>.
<!-- Date: Mon Jun 5 15:17:21 2006 -->
<h3>Access this Wednesday!!</h3> 
 
<p>There will be a 2x8 hour access this Wednesday starting at 8AM.  I have already informed Ops we will take this access.  We will attempt the following:</p> 
 
<ul> 
<li>RX swap for e001 (fib00) ; NW Top</li> 
<li>Light Level Measurement for e244 (fib02); SW Bottom</li> 
<li>Permanent Light Level Measurment for e262 (fib 02); SW Bottom</li> 
<li>Miscellaneous Fibre Swaps</li> 
</ul>  
 
<p>Rumour has it that CDF also wants to do a long COSMICs run.  So we may not have the full 16 hours. We also not sure if the this will be controlled or Supervised Access.  Stay tuned for details.</p> 
<!-- Author: Ankush -->


<!-- Date: Mon Jun 5 16:26:42 2006 -->
<h3>More Silicon PS teststand work</h3> 
Satyajit and I went over to have a look at the misbehaving FCC CAEN crate.  After some poking around, we uncovered several problems: 
<ul> 
<li> The CAEN SY527 crate address must be set to the same number as the slot for the CAENnet controller (6 right now). 
<li> The spare CAENnet controller we brought over from B0 doesn't work.  However, the spare one at FCC does, and Tim Kasza told us we were free to use it as long as we don't take it out of FCC. 
<li> On the back of the SY527, the CH OUT REMOTE DISABLE/ENABLE switch was flipped to DISABLE when it should have been set on ENABLE.  Now that it's been ENABLEd, you can turn off the power supply from the back of the crate (no more pulling the 5V enable!) 
</ul> 
At this point, the hardware is up and running!  The software is <i>almost</i> ready, we just have to change some directory paths that are hardcoded into the code, recompile, and then do a full-out burn-in test.<br><br> 
While I was there, I also talked to Tim about our ISL spare situation.  He cc'd me on another insistent email to CAEN asking for a status update.  Originally CAEN said they would get the ISL boards shipped by the end of May, but we haven't gotten confirmation that the boards have gone out yet.  We should get a response back by morning in Italy...<br><br>
<!-- Author: Jen & Satyajit -->
<!-- Comment: Tue Jun  6 08;28;17 comment by...Jen -->
<b>Word from CAEN:</b> the two ISL supplies were shipped from CAEN on May 29.  They should be at FNAL "very soon".
<!-- Date: Tue Jun 6 07:56:58 2006 -->
<h4>BLMs reset</h4> 
After the shutdown, the store-integrated dose of the BLMs had not been reset. Checking again this morning, there was a reset yesterday around 4:00.
<!-- Author: Ulrich -->


<!-- Date: Tue Jun 6 07:59:56 2006 -->
<h3>1.5 hour access today</h3> 
D0 has been granted a 1.5 hour access today from 9:30 to 11:00. I have quickly discussed this with Rick Tesarek. The duration just fits for our RX swap in NW Top, and opening the arches would not interfere with our work. Are you ready?
<!-- Author: Ulrich -->



<!-- Date: Tue Jun 6 08:47:33 2006 -->
<h3>Testing FTM-147 at FCC</h3> 
 
<p>Yesterday, Jeannine and I went over to FCC to continue FTM-147 investigation. We started from confrming that both working hybrids (i.e., 0 and 4) were still working if connected to pipes 0 and 4. Then, we connected these hybrids to two "random" (in this case 5 and 7) pipes and observed that hybrid 4 started misbehaving. It is exactly what I saw on Friday. After cleanning fiber connectors and applying "liquid glass" (or whatever that transparent stuff is), we repeated the test. Apparantly, it didn't have any positive effect on hybrid 4 which was giving errors till the end of our tests. Then, we started testing the FTM-147 by using only hybrid 0. We checked all the pipes on FTM-147 and found the following results: 
<li>pipe 0--- "Truncate" and "Illegal channel" errors;</li> 
<li>pipe 1--- OK;</li> 
<li>pipe 2--- "Not Chip ID", "00_Sequence", "Truncate" and "Illegal channel" errors;</li> 
<li>pipe 3--- "Truncate" and "Illegal channel" errors;</li> 
<li>pipe 4--- OK;</li> 
<li>pipe 5--- "Truncate" and "Illegal channel" errors;</li> 
<li>pipe 6--- OK;</li> 
<li>pipe 7--- "Not Chip ID";</li> 
<li>pipe 8--- "Truncate" and "Illegal channel" errors;</li> 
<li>pipe 9--- "Truncate" and "Illegal channel" errors.</li> 
 
After testing FTM-147, we put default FCC FTM back in and confirmed that all 10 pipes are OK. 
</p>
<!-- Author: sasha, jeannine -->


<!-- Date: Tue Jun 6 09:32:10 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030>5V Enables are on.  Alarms Ignored.</td></tr></td></table>
<!-- Author: Mark -->


<!-- Date: Tue Jun 6 09:36:07 2006 -->
Since there has been recent CCC work and we are turning ladders for today's access, I did a checkout of the GhostBuster resonance protection, which is fine.
<!-- Author: Mark -->


<!-- Date: Tue Jun 6 10:11:26 2006 -->
<h3>iFix PC crashed</h3> 
We were hanging out in the control room for the access, when we realized a heartbeat error in SVX, ISL, and L00. The reason was that SVXIICON crashed, pretty much in the same way as before the shutdown and the upgrade to iFix 4.0. Too bad. So we will be going back to our old strategy of rebooting SVXIICON every two weeks. 
<p> 
The PC was so paralyzed that I could not save the database before the reboot. As a conseqence, some iFix alarm limits were wrong. Another "Set A/W Limits" did the job, and we are up and running again.
<!-- Author: Ulrich -->


<!-- Date: Tue Jun 6 11:03:40 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030>5V Enables are off. Alarms are enabled (except for PS-CAEN-OFF).</td></tr></td></table>
<!-- Author: Mark -->

<!-- Date: Tue Jun 6 11:16:07 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W0L1 
<li>problem n: 1382 
<li>Status: needs_observation
<li>Type: RX
<li>Action: Swap_RX
<li>entered by: amitra 
<li>description is: <p>This ladder was reported to be giving bit errors and was confirmed to be a 'DAQ' problem. A previous FIB swap did not resolve the problem.  We have now swapped the RX and the ladder is running error-free in SVXDAQ.</p>  <p>One should monitor this ladder during data taking to ensure it still runs 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=0656">0656</a>
    </td>
   </tr>
   <tr>
    <td>
     <b>OUT:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0607">0607</a>
    </td>
   </tr>
  </table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Jun 6 11:16:27 2006 -->
<h3>Access for e001 RX Swap</h3> 
e001 was exhibiting bit 5 low errors which were determined to be a problem in the DAQ Channel after a fiber swap.  Ankush and Sasha made an access this morning to swap out the RX for this DAQ channel.  RX 0607 came out and RX 0656 went in.  After the swap e001 ran without bit 5 low errors and all of the other ladders in the 2 wedges ran with the expected problems.  An interesting sidenote; svxdaq was reporting c2c2 errors for one of the chips that was reading out 2b2c 2c2c.  Apparently it is not smart enough to figure out that this is just a coincidence due the the pedestal for channels 2b and 2c being near the value of 2c.
<!-- Author: Ankush/Sasha/Ulrich/Ignacio/Mark -->
<!-- Comment: Wed Jun  7 16;21;18 comment by...Old Guy -->
<pre>Bullshit.  Software parses top byte and bottom byte of 16 bit words, not nibbles-no way it can confuse 2b2c 2c2c with c2c2 (unless someone recently rewrote parseData.c) </pre>
<!-- Date: Tue Jun 6 11:40:26 2006 -->
<h3>...breaking news</h3> 
 
<p>Channel 11 are outside to come in to do an expose on us...cool.  Time to hide our <a href="http://en.wikipedia.org/wiki/Star_trek_4"><em>nuclear wessels</em></a></p> 
 
<p>Also all the foreigner's should hide lest they wish a free holiday to Cuba.....<em>woo hoo free Mojitos!!</em></p>
<!-- Author: Ankush -->
<!-- Comment: Tue Jun  6 11;48;10 comment by...Ankush -->
<pre>As I type this I am trying to look scientific for Channel 11 which is PBS...woo hoo</pre>


<!-- Date: Tue Jun 6 13:41:22 2006 -->
<h3>WORLD CUP COUNTDOWN: 2 days 21 hours 20 minutes to go... </h3>
<!-- Author: EN-GER-LAND, EN-GER-LAND, EN-GER-LAND  -->


<!-- Date: Tue Jun 6 15:36:37 2006 -->
<h3>Plan for Wednesday's Access</h3> 
 
<p>As today's RX access was successfull, Wednesday's access will be a lot more relaxed.  The items for access are: 
 
<ul> 
<li>Light Level Measurement for e244 (fib02); SW Bottom</li> 
<li>Permanent Light Level Measurment for e262 (fib 02); SW Bottom</li> 
</ul> 
</p> 
 
<p>I guess we shall have quite a bit of quiet time so we can investigate: 
 
<ul> 
<li>e060: Repeated CAP-ID error reported by SVXMon during COSMICs running</li> 
<li>e564: Reported to return no data by SVXMon during COSMICs</li> 
<li>e154: This is a BE kludge which every generation of Siliconeers has tried to fix.  We should decide if we really want to keep this ladder in or just remove it permanently.</li> 
<li>Investigate the BUSY-TO observed during COLDSTART. Can it be reproduced and can we debug it.</li> 
</ul> 
</p> 
 
<p>Now I have heard CDF may be doing a long COSMICs run tomorrow.  We may want to join in to exercise the detector.  Ulrich and I have still to decide if we want to do this.</p>  
<!-- Author: Ankush -->
<!-- Comment: Tue Jun  6 18;16;42 comment by...Ankush & Ulrich -->
<h4>Update on access time plan</h4>
As you could read in the <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=377&frame=2&anchor=17:25:00.269'>
CDF e-log</a>, the access tomorrow will start at 8:00 and will be <em>supervised</em> (as opposed to <em>controlled</em>) and last for 6 hours. The rest of the quiet time will be used for a long cosmics run (mainly for XFT commissioning).

<!-- Comment: Tue Jun  6 19;05;09 comment by...Ankush & Sasha -->
<h3>Additional ladders to study during quiet time</h3>

<p>Sasha suggested we should also examine the following ladders during quiet time.</p>

<ul>
<li>e182 -- svxdaq, re-include z-side if it's OK</li>
<li>e332 -- svxdaq, re-include z-side if it's OK</li>
<li>e404 -- it was OK during the PDB review; we need to study it one more time with svxdaq and, possibly, re-include the ladder.</li>
<li>e420 -- it was OK during the PDB review; we need to study it one more time with svxdaq and, possibly, re-include the ladder.
</li>
</ul>


<!-- Date: Tue Jun 6 19:21:20 2006 -->
<pre>At the FCC Sasha and I checked two octupuses. The first one is normally used for light level measurements (referred to as 1 in the following) and the second one will be used in the collision hall for permanent light level measurements (refered to as 2). 
 
We used for these LL e000, which was double checked to behave fine (no bit errors, ...). We also checked the last event, bit 6 is definitively fine. 
 
             
        |                  Amplitude [muW] 
        |          Fiber number 4       Fiber number 0 
        |     Octopus 1    Octopus 2       Octopus 2 
----------------------------------------------------------- 
OBDV    |       280          280              310 
Bit 0   |       320           48              280 
Bit 1   |        90           84               92 
Bit 2   |       420          405              308            
Bit 3   |       270             does not exist 
Bit 4   |       330          305               75 
Bit 5   |       220          215              140 
Bit 6   |         0            0                0 
Bit 7   |       450          456              435 
-----------------------------------------------------------</pre>
<!-- Author: Jeannine -->


<!-- Date: Wed Jun 7 08:30:00 2006 -->
<table border=0><tr><td bgcolor=#e0e030>CAEN 5V Enables ON</td></tr></table>
<!-- Author: Ankush & Jose -->
<!-- Comment: Wed Jun  7 08;44;53 comment by...Ankush,Jose, Ulrich, Jeannine, Sasha -->
<p>Light Level measurement for e244 has commenced.</p>


<!-- Date: Wed Jun 7 13:46:52 2006 -->
<pre>Sasha, Ulrich and I went to the collision hall to perform the light level measurement of e244, while Jose and Ankush drove the SVXDAQ. As reference we used the healthy ladder e243. Here the result: 
 
        |         Amplitude [muW]  
        |       e244         e243     
--------------------------------------- 
OBDV    |        100           160               
Bit 0   |         46           420         
Bit 1   |         22 (noise)   280 
Bit 2   |         17   "       350 
Bit 3   |         28   "       340 
Bit 4   |         26   "       420 
Bit 5   |         45   "       450 
Bit 6   |         70   "       430 
Bit 7   |         97           420 
---------------------------------------</pre>
<!-- Author: Jeannine -->
<!-- Comment: Wed Jun  7 17;22;25 comment by...Ankush for Jeannine, Sasha and Ulrich -->
<p>You can see an example CRO capture <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=304&frame=2&anchor=17:15:53'>
here</a>.</p>



<!-- Date: Wed Jun 7 14:03:31 2006 -->
<pre>Sasha, Ulrich and I tried to install the permanent light level measurement using ladder e262. While doing that we noticed that the old permanent light level measurement device seems to be ok. 
 
Here the LL measurements performed with the octopus used normally (referred to as 1), the octopus, which was forseen for the this permanent LL measurement (referred to as 2), and the "octopus" of the old LL device (referred to as 3): 
 
 
        |                  Amplitude [muW]  
        |     Octopus 1    Octopus 2       Octopus 3  
-----------------------------------------------------------  
OBDV    |        540          560             580           
Bit 0   |        448          490             544 
Bit 1   |        720          720             750 
Bit 2   |        610          640             672 
Bit 3   |        576      does not exist      632 
Bit 4   |        608          650             648 
Bit 5   |        610          620             680 
Bit 6   |         -            -              190 
Bit 7   |         -            -              712 
----------------------------------------------------------- 
 
</pre>
<!-- Author: Jeannine -->
<!-- Comment: Wed Jun  7 15;08;18 comment by...Ankush, Ulrich, Mark, Sasha and Jeannine -->
<p>After confirming the "old" permanent light level setup was working in the collision hall, we made measurements of the fibres on the first floor.</p>

<p>The table below gives the measurements in the collision hall, on the first floor and the coupling efficiency of the DOIM fibres to the GLINK fibres.  (I still need to check the core sizes and the estimated coupling efficiency.  NB: The DOIM wavelength is 1550nm and the GLINK ~890nm.  It would be no surprise if the GLINK fibre core size was ~x2 smaller).</p>

<table border=1>
<tr><td>Bit</td> <td>Collision Hall Value (μW)</td> <td>1st Floor (μW)</td> <td>Coupling Efficiency</td></tr>

<tr>
<td>OBDV</td> <td>580</td> <td>240</td> <td>41.3%</td>
</tr>

<tr>
<td>0</td> <td>544</td> <td>340</td> <td>62.5%</td>
</tr>

<tr>
<td>1</td> <td>750</td> <td>470</td> <td>62.7%</td>
</tr>

<tr>
<td>2</td> <td>672</td> <td>390</td> <td>58.0%</td>
</tr>

<tr>
<td>3</td> <td>632</td> <td>450</td> <td>71.2%</td>
</tr>

<tr>
<td>4</td> <td>648</td> <td>420</td> <td>64.8%</td>
</tr>

<tr>
<td>5</td> <td>680</td> <td>380</td> <td>55.9%</td>
</tr>


<tr>
<td>6</td> <td>190</td> <td>53</td> <td>27.9%</td>
</tr>

<tr>
<td>7</td> <td>712</td> <td>448</td> <td>62.9%</td>
</tr>

</table>

<p>The coupling efficiency is simply the (percentage) ratio between the 'first floor' and 'collision hall' measured values. They are mostly between 50%-->60%.  Although the measurments for OBDV and bit 6 are comparatively low.</p>  

<p>The next step is to repeat these measurements over the next few days to see how stable the values are.  If we believe they are reproducable we can then start making regular measurements to track the change in DOIM light levels.</p> 


<p>For future reference here is the mapping from the Octopus cable number to actual bit value.  (You can find this mapping on the octopus box cover).  I have also added the GLINK fibres which are now connected as part of the permanent light level measurement</p>

<table border=1>
<tr> <td>Bit</td> <td>Octopus Cable Number</td> <td>GLINK Fibre Bundle Number</td> </tr>
<tr> <td>OBDV</td> <td>10</td>                      <td>167-6</td>    </tr>      
<tr> <td>0</td>    <td> 9</td>                      <td>167-5</td>    </tr> 
<tr> <td>1</td>    <td> 8</td>                      <td>289-6</td>    </tr>
<tr> <td>2</td>    <td> 7</td>                      <td>289-5</td>    </tr>
<tr> <td>3</td>    <td> 6</td>                      <td>267-6</td>    </tr>
<tr> <td>4</td>    <td> 5</td>                      <td>267-5</td>    </tr>
<tr> <td>5</td>    <td> 4</td>                      <td>145-6</td>    </tr>
<tr> <td>6</td>    <td> 3</td>                      <td>145-5</td>    </tr>
<tr> <td>7</td>    <td> 2</td>                      <td>245-6</td>    </tr>
</table>


<!-- Comment: Thu Jun  8 18;47;11 comment by...Ankush -->
<p>Photographs of the octopus and connection to the GLINK fibres in the collision hall can be found 
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=304&frame=2&anchor=08:42:01'>
here</a>.</p>



<!-- Date: Wed Jun 7 15:47:47 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W5L4 
<li>problem n: 11 
<li>Status: unfixable
<li>Type: DropReadOut_nonRX
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: This ladder has a long standing issue of OBVD problems. Every generation of siliconers was trying unsuccessfully to do something about this. On top of OBVD problem, there are also multiple bit problems (at least bits 0,1,2,3, and 7). In particular, bit 7 low causes CAP_ID problems which result in frequent HHR's. So, we're giving up on this ladder and putting it to unfixible.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W5&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 7 16:03:42 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W2L0 
<li>problem n: 767 
<li>Status: unfixable
<li>Type: BIAS
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: We tried to reinclude this ladder again and run it with svxdaq, but it tripped on bias. So, we keep out of hwdb. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W2&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Jun 7 16:09:34 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8660&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8660' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8661&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8662' ></a></center>
<!-- Author: Mark/Sasha -->
<!-- Comment: Wed Jun  7 16;12;52 comment by...Mark/Sasha -->
Left is the AVDD current history for e332 which is chopped after a4.  One can see that the current occasionally steps up indicating recovery, but this is only temporary.  Right is the AVDD current now, which indicates no recovery for this a3-a0.


<!-- Date: Wed Jun 7 16:14:37 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8663&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8663' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8664&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8665' ></a></center>
<!-- Author: Mark/Sasha -->
<!-- Comment: Wed Jun  7 16;17;42 comment by...Mark/Sasha -->
Left is the AVDD current for e182 which in the past had the classic AVDD2 failure.  Since DS day 1700 the current has stepped back up to the origninal value.  Right shows the current now which is at the nominal value for the full ladder.
<!-- Date: Wed Jun 7 16:16:50 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W6L0 
<li>problem n: 1636 
<li>Status: unfixable
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: This ladder gives 3f as CAP_ID (corresponding to unexisting cell 63) all the time for all the chips. This is actually an old problem (see <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=e060-SVX-W-BRL-W-End-P-6&action=view&page=1&frame=2&anchor=15:39:30'> here </a> and also thread 87). It looks like the problem is somewhere between DDR and SVX chips. Nothing can be done about this, so we're taking the ladder out of hwdb.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W6&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 7 16:16:50 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W6L0 
<li>problem n: 1636 
<li>Status: unfixable
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: This ladder gives 3f as CAP_ID (corresponding to unexisting cell 63) all the time for all the chips. This is actually an old problem (see <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=e060-SVX-W-BRL-W-End-P-6&action=view&page=1&frame=2&anchor=15:39:30'> here </a> and also thread 87). It looks like the problem is somewhere between DDR and SVX chips. Nothing can be done about this, so we're taking the ladder out of hwdb.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W6&layer=L0">report</a></ul>
<!-- Author: Problem DB -->





<!-- Date: Wed Jun 7 16:24:42 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8666&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8667' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8668&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8669' ></a></center>
<!-- Author: Mark/Sasha -->
<!-- Comment: Wed Jun  7 16;25;25 comment by...Mark/Sasha -->
AVDD and Bias current plots for e404 which we put back into the database.

<!-- Date: Wed Jun 7 16:27:11 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W3L2 
<li>problem n: 1426 
<li>Status: unfixable
<li>Type: AVDD
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: The chips a0-a3 are still bad. One can see that from these <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=304&frame=2&anchor=16:09:34'> plots</a>. It turns out that AVDD current steps up only occasionally. It could be that I tested this ladder exactly at that rear moment. So, in summary, a0-a3 are still dead and we declare this ladder unfixible. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W3&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Jun 7 16:32:33 2006 -->
<h3>More work on FCC PS teststand:</h3> 
 
I took over the loadbox setup + one extra SVX supply to run burn-in tests on our new teststand.  This setup is COMPLETELY separate from the WIB setup, there is nothing you have to change to run the DAQ on the FCC teststand.  Please DO NOT move/disconnect/runawaywith anything attached to the second SVX supply.  Right now everything is off, but tomorrow I will set it up to run overnight/weekend burn-in tests (hopefully - I would have done it today but portions of the FCC network are still down).  If you have any questions or problems, call x8619 or email me - talk to me before doing anything drastic!<br> 
Thanks!<br>
<!-- Author: Jen -->

<!-- Date: Wed Jun 7 16:36:30 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W8L2 
<li>problem n: 4 
<li>Status: needs_observation
<li>Type: AVDD2
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: The AVDD current is back to normal values during past ~300 dyas (see <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=304&frame=2&anchor=16:14:37'> here</a>). When running in svxdaq, we can get data from all chips. So, it looks like this ladder has recovered from AVDD2 failure. We reincluded z-side back in. However, we had to set all chips on z-side to NN mode with DPS off to get rid off 'Illegal channel' errors. We set the thresholds to the following values: a0--75, a1--76, a2--71, a3--76, a4--76. One should keep an eye on this ladder for ~1 week after beam returns. Also, monitoring group has check the effect of turning DPS off.  
<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: Wed Jun 7 16:37:32 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W8L2 
<li>problem n: 4 
<li>Status: needs_observation
<li>Type: AVDD2
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Forgot to mention in the previous entry that the ladder inits OK in svxdaq. 
<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: Wed Jun 7 16:47:53 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W0L4 
<li>problem n: 37 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: The AVDD for this ladder is OK, and it also holds bias (see <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=304&frame=2&anchor=16:24:42'> here</a>). We didn't see any problems while running in svxdaq, so we re-included this ladder back into hwdb. One must keep a close look on how this ladder is going to behave during cosmic runs and when beam returns.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W0&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 7 16:59:41 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W6L4 
<li>problem n: 345 
<li>Status: needs_observation
<li>Type: Optical_other
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Mark studied this ladder during quiet time. He found that it's a bit7 low problem due to low light level. It should mostly affect only the chip ID. Monitoring group should check the data from this ladder and study a possiblity for an offline fix. We also need to consider a possiblity to put a more sensitive RX.    
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W6&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Jun 7 17:15:53 2006 -->
<center><a href='/elog/notebooks/silicon/Wed_Jun__7_2006_171524.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8671' ></a><a href='/elog/notebooks/silicon/Wed_Jun__7_2006_171538.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8673' ></a></center>
<!-- Author: Ankush -->
<!-- Comment: Wed Jun  7 17;21;12 comment by...Ankush for Sasha, Jeannine and Ulrich -->
<h4>Example CRO shots from light level measurement of e244</h4>

<p>The screen shots are examples of the good/bad bits from the Light Level Measurements from e244. The grey trace is OBDV.  The left hand green trace is Bit 0 and the right hand green trace is Bit 3.  As you can see the light level for bit 3 shows no structure and looks like noise.</p>
<!-- Date: Wed Jun 7 17:17:00 2006 -->
<h3>Quiet Time Studies 6/7/06</h3> 
During the quiet time studies today we attacked a few ladders with unresolved issues. 
<ul> 
<li>e332 - Due to the classic AVDD2 failure, this ladder has chips a3-a0 chopped.  During the PDB review the AVDD current temporarily jumped back up leading to the suggestion that we try to include these chips.  Looking at the <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=304&frame=2&anchor=16:09:34'> 
current history</a>, any recovery is temporary, so these chips should remain out. 
<li>e182 - Another AVDD2 failure, chips a4-a0 have shown <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=304&frame=2&anchor=16:14:37'> 
signs of recovery</a> starting at DS Day 1700, as the AVDD current has jumped up to 815 uA.  We reintegrated chips a4-a0 in svxdaq and they ran without error in RA mode.  In NN mode we get illegal channel errors, which is expected since chips in this ladder give that error when dps is on.  Next we ran in NN with dps off and thresholds raised by the pedestal values for each chip.  In this mode the ladder was error free.  We reintegrated chips a4-a0 into the hdwdb in NN mode and DPS off with the thresholds set to 9+Pedestal: a4=76, a3=76, a2=71, a1=76 and a0=75.  Finally, this ladder now initializes fine, so we can remove the init readback mask when we have time. 
<li>e060 - This ladder was reintegrated during the PDB review because it initialized ok.  It, however, reads out capid 63 for every event, which is a <a href= 
'/cgi/elog/det-system-elog.pl?nb=e060-SVX-W-BRL-W-End-P-6&action=view&page=1&frame=2&anchor=15:39:30'> 
known unfixable problem</a>.  We removed this ladder from the hdwdb. 
<li>e564 - During <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=302&frame=2&anchor=19:50:42'> 
recent cosmics runs</a> the z side of this ladder appears to be giving no data.  A closer look at the data reveals: 
<br><br> 
<font color=yellow><b>10</b></font><font color=yellow><b>50</b></font><font color=blue>0d</b></font><font color=cyan><b>0b</b></font> <font color=yellow><b>04</b></font><font color=yellow><b>10</b></font><font color=yellow><b>41</b></font><font color=yellow><b>00</b></font> <font color=yellow><b>00</b></font><font color=yellow><b>00</b></font><font color=yellow><b>00</b></font><font color=yellow><b>00</b></font> <font color=yellow><b>00</b></font><font color=yellow><b>00</b></font><font color=yellow><b>00</b></font><font color=yellow><b>00</b></font> <font color=yellow><b>00</b></font><font color=yellow><b>00</b></font><font color=yellow><b>00</b></font><font color=yellow><b>00</b></font> <font color=yellow><b>00</b></font><font color=yellow><b>00</b></font><font color=yellow><b>00</b></font><font color=yellow><b>00</b></font> <font color=yellow><b>08</b></font><font color=yellow><b>16</b></font><font color=yellow><b>08</b></font><font color=yellow><b>16</b></font> <font color=yellow><b>00</b></font><font color=yellow><b>00</b></font><font color=yellow><b>00</b></font><font color=yellow><b>00</b></font>  
<br> 
<font color=black>e5</b></font><font color=black>64</b></font><font color=green>73</b></font><font color=cyan>fc</b></font> <font color=green><b>8d</b></font><font color=black>10</b></font><font color=blue><b>00</b></font><font color=black>f3</b></font> <font color=green><b>8c</b></font><font color=black>10</b></font><font color=green><b>8b</b></font><font color=black>10</b></font> <font color=green><b>8a</b></font><font color=black>10</b></font><font color=green><b>89</b></font><font color=black>10</b></font> <font color=blue><b>21</b></font><font color=black>f3</b></font><font color=blue><b>22</b></font><font color=black>13</b></font> <font color=blue><b>23</b></font><font color=black>02</b></font><font color=red><b>08</b></font><font color=black>1f</b></font> <font color=red><b>87</b></font><font color=black>10</b></font><font color=blue><b>11</b></font><font color=black>f3</b></font> <font color=blue><b>12</b></font><font color=black>11</b></font><font color=blue><b>13</b></font><font color=black>03</b></font> <font color=red>360ns</font><br> 
 
<font color=green><b>a6</b></font><font color=black>10</b></font><font color=blue><b>0f</b></font><font color=black>03</b></font> <font color=blue><b>10</b></font><font color=black>0a</b></font><font color=blue><b>11</b></font><font color=black>f3</b></font> <font color=green><b>a5</b></font><font color=black>10</b></font><font color=blue><b>24</b></font><font color=black>1f</b></font> <font color=red><b>a3</b></font><font color=black>10</b></font><font color=green><b>a2</b></font><font color=black>10</b></font> <font color=blue><b>17</b></font><font color=black>f3</b></font><font color=blue><b>18</b></font><font color=black>09</b></font> <font color=blue><b>19</b></font><font color=black>05</b></font><font color=blue><b>21</b></font><font color=black>1f</b></font> <font color=red><b>20</b></font><font color=black>1f</b></font><font color=red><b>06</b></font><font color=black>02</b></font> <font color=blue><b>07</b></font><font color=black>09</b></font><font color=blue><b>08</b></font><font color=black>01</b></font> <font color=red>800ns</font><br> 
 
<font color=blue><b>7f</b></font><font color=black>06</b></font><font color=red><b>c2</b></font><font color=red><b>c2</b></font> <br><br> 
What is happening here is that bit 7 occasionally goes low, in this case you can see that chip 88 is read out as chip 08.  The fib seeing 08 thinks that the next byte is data and assumes it needs to convert from gray code, messing up the capid.  Bit 7 low is a known problem due to a light level of 32 uW.  According to Matt Herndon the bit unpacker can fix bit 7 errors, so we should double check the offline quality of this ladder.  We also may want to find an RX that can better handle the low light level. 
<li>e404 - This ladder was excluded due to a low AVDD current and 100% DRO way back in <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W0&layer=L4">2002</a>.  The AVDD current seems to be <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=304&frame=2&anchor=16:24:42'> 
back to normal</a> and we were able to run in svxdaq with no errors.  We reintegrated the ladder into the hdwdb and biased it with the rest of the detector.  The bias current seems to be jumping around so we should address this. 
<li>e420 - This ladder was out due to trips on bias overcurrent.  It was biased with success during the PDB review, but tripped when we tried to bias it today, so we leave it out. 
<li>e154 - This ladder is a BE kludge with known bit 7,3,2,1,0 errors and capid errors.  We have marked this as unfixable and should check offline to see if it makes any contribution to tracking.  May have to mask capids for SVXMon as well. 
</ul>  
<!-- Author: Sasha/Mark -->
<!-- Comment: Wed Jun  7 17;25;22 comment by...Sasha/Mark/Jeannine/Ulrich/Ankush/Ignacio/Jose -->
Forgot one ladder:
<ul>
<li>e244 - This ladder has bit low problems on bits 0,1,2,3 and 4.  A measurement of light levels confirms noise only on these bits, so we removed this ladder from the hdwdb.
</ul>
<!-- Comment: Wed Jun  7 22;41;57 comment by...Ankush -->
<P>This is good work here. I am pleased.  Let's hope your endevours and diligence pay off.</p>
<!-- Comment: Wed Jun  7 23;56;20 comment by...Ankush -->
<p>One point to mention was e262, which was used for the permanent LL measurement, was out of the HWDB.  I put it back in by editing the CAENVolts.dat file. For the moment we will need to reinclude e262 eveytime we want to this light level measurement.  Unless there is a way a ladder can be active and always gets included for CAENVolts.dat by the HWDB but not take part in the DAQ.</p>
<!-- Date: Wed Jun 7 17:21:10 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W4L4 
<li>problem n: 621 
<li>Status: unfixable
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: This ladder is useless because many bits are dead (see <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=304&frame=2&anchor=13:46:52'> here</a> and <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=304&frame=2&anchor=17:15:53'> here</a>). It's taken out of hwdb. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W4&layer=L4">report</a></ul>
<!-- Author: Problem DB -->





<!-- Date: Wed Jun 7 17:23:43 2006 -->
<h3>Taking COSMICs now</h3> 
 
<p>The rest of CDF is taking a long COSMICs run tonight for XFT.  We decided to join in to exercise the detector and check out the changes made by Sasha and Mark.</p>
<!-- Author: Ankush -->
<!-- Comment: Thu Jun  8 19;22;01 comment by...Ankush -->
<p>For reference the relevant Run Numbers & length of running were:

<ul>
<li>217682 --> 10 mins</li>
<li>217684 --> 14 mins</li>
<li>217687 --> ~2 hours</li>
<li>217694 --> ~3 hours</li>
</ul>

</p>
<!-- Date: Wed Jun 7 17:37:49 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W0L4 
<li>problem n: 37 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: mhartz 
<li>description is: Having integrated this ladder, set the AVDD imon limits.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>--</td><td>1115</td></tr>
<tr><td><b>Lower</b></td><td>--</td><td>1075</td></tr>
<tr><td><b>Upper</b></td><td>--</td><td>1155</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W0&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 7 17:40:11 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W0L4 
<li>problem n: 37 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: mhartz 
<li>description is: Set DVDD IMON limits.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>--</td><td>130</td></tr>
<tr><td><b>Lower</b></td><td>--</td><td>65</td></tr>
<tr><td><b>Upper</b></td><td>--</td><td>185</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W0&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 7 17:42:24 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W0L4 
<li>problem n: 37 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: mhartz 
<li>description is: Set Bias IMON limits<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>--</td><td>490</td></tr>
<tr><td><b>Lower</b></td><td>--</td><td>0.6</td></tr>
<tr><td><b>Upper</b></td><td>--</td><td>550</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W0&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Jun 7 20:11:19 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8674&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8674' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8675&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8675' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8676&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8676' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8677&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8677' width='300'></a></center>
<!-- Author: Ulrich -->
<!-- Comment: Wed Jun  7 20;16;26 comment by...Ulrich -->
<h3>SVXMON Plots for Current COSMICS Run</h3>
The SVXMON plots for the current COSMICS run basically look fine. There is only one ladder which returns no data in a small part of the φ side chips and the entire z side: e564. This ladder has been examined in the quiet time studies earlier today. It contains a bit 7 error which may be fixable offline.


<!-- Comment: Wed Jun  7 21;49;54 comment by...Ulrich -->
Another problem (documented in the <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=380&frame=2&anchor=21:40:18.172'>
main e-log</a>): e154 has a couple of CAP ID problems, and SVXMON is complaining.
<!-- Date: Wed Jun 7 20:20:32 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8678&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8679  width='300' align='top'></a></td><td>Mark was monitoring this bias current earlier today. The ladder it belongs to has been out of the HWDB for a long time.  We do not have a good explanation for this behavior.</td></tr></table>
<!-- Author: Ulrich -->
<!-- Comment: Wed Jun  7 23;02;09 comment by...Ankush -->
<p>This structure is rather irratic, even for a Micron ladder. The CAEN PS has no history of acting badly. So here are a few checks to make:

<ul>
<li>During the next quiet time, plot the IV curve for this ladder to see if it looks resistive or diode like.</li>
<li>When we get some collision data, the Monitoring group should check this looks like a biased ladder.</li>
</ul>
</p>


<!-- Date: Wed Jun 7 23:30:55 2006 -->
<h3>BUSY Condition on COLDSTART</h3> 
 
 
 
<p>The COSMICs run with silicon has ended.  I put silicon to STANDBY and tried COLDSTART again.We are still BUSY Condition on COLDSTART yet COMSICS runs fine.  Still no bright ideas from this side.  This is the RC error:</p> 
 
<pre> 
 Busy Condition in VRB/EVB forwarded by front-end crate(s) 
Busy conditions are produced by the VRB and are forwarded 
 by the front end crates to the busy crosspoint.  Busy 
 conditions do not represent a problem with the front end 
 crates themselves, but with the EVB system. 
</pre> 
 
 
<p>Mark spotted this first and tried again earlier in the day.  So this is a real problem.  The Silicon DAQ has not changed. So could it be with the MVME Crate processor ?</p> 
  
<!-- Author: Ankush -->


<!-- Date: Wed Jun 7 23:47:41 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8680&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8681  width='300' align='top'></a></td><td><p>Bias current for e404 at then end of COSMICs.  Around 22:00, the Bias current looked like it was starting to settle.  However we really need to run this longer so get a better idea of how 'irratic' this current will be.</p></td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Wed Jun 7 23:50:19 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>CAEN 5V Enables are OFF</pre></td></tr></td></table>
<!-- Author: Ankush -->
<!-- Comment: Wed Jun  7 23;53;05 comment by...Ankush -->
<p>After powering down the detector, some of the portcards were bit  cold.  So I have ignored their warnings for the time being.  The iFIX tags are: TE-PCE-1B-1 and TE-PCW-1B-1.</p>


<!-- Comment: Wed Jun  7 23;58;16 comment by...Ankush -->
<p>..and TE-PCE-3B-2..</p>

<!-- Comment: Thu Jun  8 00;58;55 comment by...Ankush -->
<p>...and TE-PCE-1B-2</p>


<!-- Date: Thu Jun 8 08:42:01 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8682&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8683' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8684&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8685' ></a></center>
<!-- Author: Ulrich -->
<!-- Comment: Thu Jun  8 08;43;40 comment by...Ulrich -->
Pictures of the installation for the permanent light level measurement which we found already installed and fully cabled in SW Bottom. The left picture showes the optical splitter, and the right picture shows the octopus hooked up to GLINK fibers.


<!-- Date: Thu Jun 8 10:23:37 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030>5V Enables are ON.  Alarmes Ignored.  </td></tr></td></table>
<!-- Author: Mark -->


<!-- Date: Thu Jun 8 12:45:28 2006 -->
<h3>More Studies of Busy Timeouts from Coldstart</h3> 
 
During the quiet time this morning we decided to study the Busy  
Timeouts we have been seeing when running Coldstart.  We began by running ColdStart with the detectors off (so we are only reading out FIB headers).  In 5000 events we did not see the error.  Next we took the ISL to standby and ran ColdStart with the ISL/L00 VRBs and FIBs.  With this configuration we were able to reproduce the Busy TO errors.  The error corresponds to VRBs in all three VRB crates filling up their buffers.  The next step was to run coldstart with the Software EVB included.  In this configuration we also saw the errors.  Then we tried running with the Hardware EVB and L3, and no longer saw the errors.  This seems to indicate that the problem is in the crate cpu, which is reading out events in the default configuration or with the SEVB, as opposed to the  EVB cpu which is reading out data when we run with the HEVB.   Next we tried reseting the crate cpus for b0svx06/07/08 and running with the default configuration and the SEVB.  In both cases we still saw the errors.  Finally we decided to unload the Clock Cloning Card module (ccc1.o) from the crate cpu.  After this we no longer saw the Busy Timeout errors.   When we reloaded the ccc1.o module, however, the errors did not return, so it is not entirely clear how removing the module helped.  The current situation is that we are unable to reproduce the Busy Timeout errors and we have turned off the ISL as quiet time will soon be ending.  Our best theory is that someting is going kaka in the readout code for the VRBs in the crate cpu, possibly due to a memory leak in the run control code.  Our plan is to run ColdStart for a while with the detector off and see if we can get back to the error state.
<!-- Author: Sebastian/Ankush/Marcel/Mark -->
<!-- Comment: Thu Jun  8 17;08;11 comment by...Mark -->
We ran ColdStart for ~200,000 event with the detector off.  No sign of our Busy TO errors. 
<!-- Date: Thu Jun 8 12:45:58 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030>5V Enables are off.</td></tr></td></table>
<!-- Author: Ankush/Mark -->



<!-- Date: Thu Jun 8 17:55:23 2006 -->
<h3>ACNET on the web</h3> 
 
<p>Ignacio pointed out this website to me.  You can run an ACNET console as a JAVA application from the web !!  So you can check the beam from home.  Give it a spin at: 
<a href="http://www-bd.fnal.gov/controls/public/linux-console.html"> 
http://www-bd.fnal.gov/controls/public/linux-console.html</a>.</p>
<!-- Author: Ankush & Ignacio -->




<!-- Date: Thu Jun 8 19:53:25 2006 -->
<center><a href='/elog/notebooks/silicon/Thu_Jun__8_2006_195158.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8687' ></a><a href='/elog/notebooks/silicon/Thu_Jun__8_2006_195239.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8689' ></a><a href='/elog/notebooks/silicon/Thu_Jun__8_2006_195251.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8691' ></a><a href='/elog/notebooks/silicon/Thu_Jun__8_2006_195303.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8693' ></a></center>
<!-- Author: Ankush -->
<!-- Comment: Thu Jun  8 19;57;22 comment by...Ankush -->
<h4>SVXMon Strip PLots for e182 after COSMICs running</h4>

<p>Last night, Mark & Sasha put the Z side chips in but turned DPS OFF.  To compensate, they raised the thresholds for those chips. Looking at the SVXMon Plots, the reincluded chips are working and appear no different to the R-Phi side chips.  However it appears Chip 5 was not reading any charge for the last hour of the COSMICs running.</p>

<p>When we get to normal running, the Monitoring group should check this ladder, especially as it is running with DPS OFF.</p>


<!-- Comment: Fri Jun  9 09;41;52 comment by...sasha -->
<pre>as far as I remember, r-phi side is also running with DPS off.</pre>
<!-- Comment: Fri Jun  9 10;26;20 comment by...Ankush -->
<pre>ahh...that would explain the large number of ADC counts on the R-Phi side.  But if the whole ladder has problems with DPS OFF, this may indicate some other problem.....need to think about this a bit more.

</pre>
<!-- Date: Thu Jun 8 20:01:43 2006 -->
<center><a href='/elog/notebooks/silicon/Thu_Jun__8_2006_200055.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8699' ></a><a href='/elog/notebooks/silicon/Thu_Jun__8_2006_200106.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8701' ></a><a href='/elog/notebooks/silicon/Thu_Jun__8_2006_200118.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8703' ></a><a href='/elog/notebooks/silicon/Thu_Jun__8_2006_200126.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8705' ></a></center>
<!-- Author: Ankush -->
<!-- Comment: Thu Jun  8 20;03;42 comment by...Ankush -->
<h3>SVXMon Strip Plots for e404 after COSMICs running</h3>

<p>Sasha & Mark put this ladder back in the HWDB.  Looking at the SVXMon plots, the occupancy and mean charge looks OK.  So it seems to be OK.</p>


<!-- Date: Thu Jun 8 21:09:08 2006 -->
<h3>We have a BIG problem: Potential SVT Hole for e3a!!</h3> 
 
<p>I was reviewing the bit reporter and looking at the ladders which were giving 99% errors.</p> 
 
<p>e3a4 has been returning no data at all, just the FIB header.  We already have e3a3 out of the HWDB. With 3 out of 5 ladders, this is an SVT hole.  I will ask Ops for an access to see if we can fix this. </p> 
 
<p>This ladder has been quite a troublesome ladder.  It would always trip whenever the North wall was moved but somehow overcame this problem during the shutdown.  This ladder also stopped returning data on 1st September 2005.  A FIB swap fixed it that time.</p> 
 
<p>If we get an access we shall try: 
 
<ul> 
<li>Fibre swap first: If it is a ladder problem, we can try a LL measurement.</li> 
<li>If it is a DAQ: Do a FIB and then a RX swap.</li> 
</ul> 
 
<p>This ladder is NE Top....so we may want to take 3 people. Two lifts so we can access the front and back of the crate. The third to assist in lift moving and call the control room.  We may even want to take 4 people to help move things into the control room.</p> 
 
<p>Bugger...I was really hoping to avoid this kind of last minute crap.</p>
<!-- Author: Ankush -->


<!-- Date: Thu Jun 8 21:53:23 2006 -->
<center><a href='/elog/notebooks/silicon/Thu_Jun__8_2006_214811.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8707' ></a><a href='/elog/notebooks/silicon/Thu_Jun__8_2006_214908.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8709' ></a><a href='/elog/notebooks/silicon/Thu_Jun__8_2006_214934.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8711' ></a><a href='/elog/notebooks/silicon/Thu_Jun__8_2006_215009.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8713' ></a></center>
<!-- Author: Ankush -->
<!-- Comment: Thu Jun  8 22;00;19 comment by...Ankush -->
<h3>AVDD/DVDD Voltage and Currents for e3a4</h3>

<p>The Voltage and Currents for AVDD  have been steady before the shutdown and now.  But if you look at DVDD current, the variation now is much smaller than before the shutdown.  This would be consistent with the chip not reading out.  If the chip is really not reading out either it is not getting the commands or the chip back end may be dead.</p>



<!-- Date: Thu Jun 8 21:53:52 2006 -->
<center><a href='/elog/notebooks/silicon/Thu_Jun__8_2006_215035.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8715' ></a><a href='/elog/notebooks/silicon/Thu_Jun__8_2006_215057.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8717' ></a><a href='/elog/notebooks/silicon/Thu_Jun__8_2006_215116.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8719' ></a><a href='/elog/notebooks/silicon/Thu_Jun__8_2006_215135.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8721' ></a></center>
<!-- Author: Ankush -->
<!-- Comment: Thu Jun  8 22;06;58 comment by...Ankush -->
<h3>DOIM Voltages & Currents for e3a</h3>

<p>The Voltage on the 2V DOIM Line seems to have dropped around DS-DAy 1885 (1st March 2006). But will this stop e1a4 from returning any data ?</p>




<!-- Date: Fri Jun 9 10:40:12 2006 -->
<h3>Possible store today ?</h3> 
 
<p>Willis came in earlier and said the Tev may try to put a store in today.  However a few seconds ago I head a "swoooshh" from the Silicon office....usually an indication of a quench.  This was confirmed when I went into the Control room...the Tev has just quenched.</p> 
 
<p>...so if I can hear the quench from the Silicon office, they may not put the store in today??...</p>
<!-- Author: Ankush -->
<!-- Comment: Fri Jun  9 10;41;31 comment by...Ankush -->
<p>Here is the entry from the MCR e-log:</p>

<pre>
10:36:59-   Tevatron quench - B0 low betas while sitting in squeeze. The investigation begins. - marty
</pre>


<!-- Date: Fri Jun 9 11:48:09 2006 -->
<h3>SB3W10L4 Fixed !!</h3> 
 
<p>After the Tev quench we went in for a quick access to do a fibre swap for e3a4.  However once I looked at the FTM the answer was obvious why e3a4 was not returning any data.</p> 
 
<p><b>IT WAS NOT PLUGGED IN!!!!</b></p> 
 
<p>No surprise, plugging in the fibre and the ladder is now returning data. So e3a4 is fixed and the SVT hole for e3a is gone :-)</p> 
 
<p>Let the witch hunt begin!!</p>
<!-- Author: Ankush, Mark and Sasha -->


<!-- Date: Fri Jun 9 11:51:01 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030>5V Enables are off.  They had been on for the e3a4 access and I forgot to add a comment to the elog.</td></tr></td></table>
<!-- Author: Mark -->


<!-- Date: Fri Jun 9 12:06:56 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>CAEN 5V Enables ON for SVT Test</pre></td></tr></td></table>
<!-- Author: Ankush -->
<!-- Comment: Fri Jun  9 12;32;27 comment by...Ankush -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>CAEN 5V Enables OFF</pre></td></tr></td></table>


<!-- Date: Fri Jun 9 12:48:25 2006 -->
<h3>Quick SVT Test</h3> 
 
 
<p>During the previous COSMICs running SVT09 was taken out of running due to some decision timeout by SVT.  So this crate was taken out.  Stefano was concerned there may be some problem for SVT receiving data from XFT and Silicon.  Test with XFT were OK.  So in the 30 mins of remaining quiet time I turned put 1 bulkhead to STANDBY for them .  We ran the COSMICs tape quickly and confirmed SVT is still receiving data from Silicon and XFT.  So at least the Silicon-->SVT path is still OK.</p> 
 
<p>However during the tests we could see the FIB headers were probably sufficient.  So we repeat with just FIB headers next time.</p>
<!-- Author: Ankush -->


<!-- Date: Fri Jun 9 12:54:53 2006 -->
Germany 4 - Costa Rica 2
<!-- Author: Football&#39;s coming home -->


<!-- Date: Fri Jun 9 14:02:33 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8722&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8723  width='300' align='top'></a></td><td><p>During the quick SVT test, I orignally wanted to put Bulkhead 0 to STANDBY. This you can see in the logging window.  But for some reason Bulkhead 1 went to STANDBY instead.  This is odd.</p></td></tr></table>
<!-- Author:  Ankush -->
<!-- Comment: Fri Jun  9 14;11;06 comment by...Ankush -->
<p>Here are the staements echoed by SVXINTER</p>

<pre>
svxinter-> FRI JUN 09 10:59:57 2006  setPSStatus, detector = 1, ps_n = 46, status = 2
FRI JUN 09 10:59:58 2006 Sending Request for e3a6
<em>This is e3a from the access</em>

FRI JUN 09 11:46:20 2006  setPSStatus, detector = 1, ps_n = 46, status = 1
FRI JUN 09 12:05:01 2006  setPSStatus, detector = 1, ps_n = 0, status = 2
FRI JUN 09 12:05:01 2006 Sending Request for e006
<em>This is me putting e006 to STANDBY by mistake</em>

FRI JUN 09 12:05:15 2006  setPSStatus, detector = 1, ps_n = 12, status = 2
<em>At this point I told PS-GUI to put bulkhead 0 to STANDBY but bulkhead 1 went to STADNBY instead</em>
FRI JUN 09 12:05:15 2006 Sending Request for e106
FRI JUN 09 12:05:18 2006  setPSStatus, detector = 1, ps_n = 13, status = 2
FRI JUN 09 12:05:18 2006 Sending Request for e116
FRI JUN 09 12:05:21 2006  setPSStatus, detector = 1, ps_n = 14, status = 2
FRI JUN 09 12:05:21 2006 Sending Request for e126
FRI JUN 09 12:05:24 2006  setPSStatus, detector = 1, ps_n = 15, status = 2
FRI JUN 09 12:05:24 2006 Sending Request for e136
FRI JUN 09 12:05:26 2006  setPSStatus, detector = 1, ps_n = 16, status = 2
FRI JUN 09 12:05:27 2006 Sending Request for e146
FRI JUN 09 12:05:28 2006  setPSStatus, detector = 1, ps_n = 17, status = 2
FRI JUN 09 12:05:28 2006 Sending Request for e156
Module is busy, sending code = 16
FRI JUN 09 12:05:31 2006  setPSStatus, detector = 1, ps_n = 18, status = 2
FRI JUN 09 12:05:31 2006 Sending Request for e166
Module is busy, sending code = 16
FRI JUN 09 12:05:33 2006  setPSStatus, detector = 1, ps_n = 20, status = 2
FRI JUN 09 12:05:33 2006 Sending Request for e186
FRI JUN 09 12:05:36 2006  setPSStatus, detector = 1, ps_n = 21, status = 2
FRI JUN 09 12:05:36 2006 Sending Request for e196
FRI JUN 09 12:05:38 2006  setPSStatus, detector = 1, ps_n = 22, status = 2
FRI JUN 09 12:05:39 2006 Sending Request for e1a6
FRI JUN 09 12:05:41 2006  setPSStatus, detector = 1, ps_n = 23, status = 2
FRI JUN 09 12:05:41 2006 Sending Request for e1b6
FRI JUN 09 12:06:13 2006  setPSStatus, detector = 1, ps_n = 0, status = 1
Module is busy, sending code = 18
</pre>

<p>Something is not quite right here.</p>

<!-- Date: Fri Jun 9 14:43:41 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W10L4 
<li>problem n: 1651 
<li>Status: needs_observation
<li>Type: Optical_other
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>It was noticed this ladder was not returning any data.  This would be bad as it would create a SVT hole.  However after an access to the collision hall it was discovered the fibre was not plugged in.  The fibre was plugged in and the ladder now returns data with no problems.</p>  <p>Observe this ladder during data taking to double check it is OK.  One should also check if this ladder initialises OK.  If it does, one can removed the init-readback mask.</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 Jun 9 14:45:26 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W10L4 
<li>problem n: 1500 
<li>Status: needs_observation
<li>Type: DVDD
<li>Action: PS_work
<li>entered by: amitra 
<li>description is: <p>After the shutdown, this ladder no longer trips when the north wall moves.  The reason is unknown.  Let's hope it does not return.</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 Jun 9 22:55:22 2006 -->
<h3>First "Colliding" store in</h3> 
 
<p>Just got back from the paddlers&#39 party to find the first colliding store went in.   The initial lumi was very low, ~1E30.  The losses are low.  But LOSTPB ~1KHz....for such a low lumi one would expect LOSTPB << 1KHz considering we would get LOSTPB ~3KHz for initial lumi >100E30 (x100 today&#39s initial lumi).</p> 
 
<p>MCR plan to keep the store in until 6AM and then  test their beam abort. I have left instructions via Jennifer :-) for the shift crew to put the BLM plots into the e-log after the beam is dumped.  That will give some idea of how well they are dumping the beam.</p> 
 
<p>Also it&#39s a good thing we have Jennifer riding along with the shift crew.  She is guiding the virgin aces well...that makes me sleep a little better.</p> 
<!-- Author: Ankush -->
<!-- Comment: Fri Jun  9 22;58;10 comment by...Ankush -->
<p>forgot to add the two inmportant facts:  first A4 separator sparked during shot setup but some how they managed to keep the beam in.  Also the store had to be maunally scrapped.</p>

<!-- Comment: Sat Jun 10 16;44;02 comment by...Jennifer :-) -->
Luckily, the ACEs followed the instructions left, and put in our radiation entries in the <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=387&frame=2&anchor=06:30:30.036'>
e-log</a>.
<p>
The claim that the store ended in a quench, but if these are the correct plots, we didn't see anything. Note this was an incredibly low lumi store, so it's not too suprising. However, the lost pbars were around a kHz early in the store. They also scraped manually, so maybe lack in precision is to blame.
<p>
For some reason, I cannot view the MCR e-log from home... so if someone wants to see what MCR had to say about the early morning quench, that would be nice.

<!-- Comment: Sat Jun 10 18;32;40 comment by...Ulrich -->
To view the MCR e-log from home, you have to go via 
<a href="https://b0www.fnal.gov:443/cgi/internal/elog/nph-MCRproxy.pl/000/http/www-bd.fnal.gov/cgi-mcr/elog.pl?nb=2006&action=view&page=last&scroll=true">this proxy</a>.
<p>
Otherwise, MCR does not have anything conclusive to say:
<pre>
6:21:44-  Tev Quenched F48U. Investigating.  - dln

08:14:26-  Shift Summary: Tev store spun until 0621 when it quenched F48U. No solid cause at the end of shift. 
</pre>




<!-- Date: Mon Jun 12 09:12:02 2006 -->
<h3>Week Summary</h3> 
 
<p><h4>Monday</h4> 
<ul><li>Ankush played with CCC. CCC didn't lose the clock while CDF swithed modes.</li> 
<li>FCC test stand work: Jen's PS setup is almost ready.</li> 
<li>FTM-147 was tested at FCC. Only pipes 1,4, and 6 are OK. All other pipes give errors.</li> 
</ul> 
<h4>Tuesday</h4> 
<ul><li>SVXIICON crashed in the same old way. Temporary solution is to reboot every two weeks.</li> 
<li>Access to swap RX for e001--success.</li> 
</ul> 
<h4>Wednesday</h4> 
<ul>Access and PDB work:  
<li> light level measurements for e244 showed that it's dead, it's out of hwdb; </li> 
<li>Permanent light level measurement setup for e262--- it was ready before us;</li> 
<li>studied e332 (AVDD2 abuse victim)-- still bad;</li> 
<li>e182 (also AVDD2)-- chips a4-a0 reincluded back in NN with DPS off;</li> 
<li>e060 removed from hwdb due to old unfixible problem;</li> 
<li>e564-- bit7 low problem;</li> 
<li>e404 re-included in hwdb;</li> 
<li>e420 still trips on over-current, keep out of hwdb;</li> 
<li>e154-- old BE-kludge problem on top of various bit errors; declared unfixible;</li> 
<li>More FCC PS teststand work: burn-in tests;</li> 
<li>Cosmic runs: results are to be checked;</li> 
<li>BUSY Condition on COLDSTART problem was discovered;</li> 
</ul> 
 
<h4>Thursday</h4> 
<ul> 
<li>Studies of Busy Timeouts from Coldstart--- no understanding of a cause yet.</li> 
</ul> 
 
 
<h4>Friday</h4> 
<ul> 
<li>Access to fix e3a4-- it was not plugged in!!!.</li> 
<li>Quick SVT Test-- OK.</li> 
<li>PS GUI misbehaves.</li> 
<li>First colliding store in. Low lum ~1E30. Losses at 1KHz. 
Ended in quench (reason is unknown).</li> 
</ul> 
 
</p>
<!-- Author: sasha -->