<!-- Title: 10:14:26  Mon Jan 23 2006 -->
<!-- Crewchief: Shulamit (MPC) -->
<!-- Op1: Sebastian (SPL) -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>no beam yet, expect beam in the middle of the week.</pre>


<!-- Date: Mon Jan 23 10:34:13 2006 -->
<h3>Silicon Calendar</h3> 
 
<p>To mark off the days, there is now a Silicon Calendar in the Silicon office.</p>
<!-- Author: Ankush -->
<!-- Comment: Mon Jan 23 11;44;14 comment by...Ankush -->
<p>...for example, the new main-pager schedule has been added to this calendar...</p>


<!-- Date: Mon Jan 23 13:30:04 2006 -->
The new LA has arrived, it looks fine, but we have to wait to update the security patches before connecting it to the internet.
<!-- Author: A/S -->


<!-- Date: Mon Jan 23 15:10:14 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030>SVXDAQ doesn't work because it requires b0svx*.crate files from /cdf/code-common/cdfonline/svxii/devel/b0crates/current/ which was umnounted by Sebastian (<a href='http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=284&frame=2&anchor=12:14:51'> 
see here</a>). Sebastian, could you please fix it? 
We need to update path in system.cfg file in svx/, isl/, and fcc/ 
directories.</td></tr></td></table>
<!-- Author: sasha/ankush -->
<!-- Comment: Mon Jan 23 16;40;19 comment by...sebastian -->
working on it...

<!-- Comment: Mon Jan 23 16;56;41 comment by...Sebastian -->
Done. No need to change anything for FCC, it does not use the svxii devel area (I am at fcc and svxdaq works fine). The old files are in svxii/devel/b0crates/config2004 (new ones in current).


<!-- Comment: Mon Jan 23 19;02;07 comment by...s -->
the new files are in /cdf/onln/code/cdfprod/svxii/devel/b0crates/current
<!-- Date: Mon Jan 23 17:18:16 2006 -->
<h3>IMON stopped updating</h3> 
 
<p>The attentive monitoring ACE noticed IMON stopped updating around Jan 20.  I was in the control room and I could not work out why.  So I restarted IMON and now it seems to be OK.</p>
<!-- Author: Ankush  -->


<!-- Date: Mon Jan 23 18:08:07 2006 -->
<h3>CCC interrupts work</h3> 
 
Today Bill H and I tested the interrupts form the CCC and 
everything looks OK. We were able to catch the IRQ when the 
CCC lost either one of the inputs (BS or RF).  Bill will add the 
following to the CCC: 
<pre> 
- enable IRQ mux for the CCC (0x5) by default 
- have a register for each BS signal error 
- send a pulse to the interrupt logic when in error instead of 
  DC, this was causing too many IRQ that the CPU could not 
  follow: 
  interrupt: this is an interrupt 80                                               
  logTask: 3397 log messages lost.                                                 
  interrupt: bad vme interrupt 0                                                   
  logTask: 2538 log messages lost. 
- add a clear error register (right now one needs to reset the  
  board to clear the errors) 
</pre> 
Another issue is that the when RF is missing I get 0x40 in the status register and Bill expected 0x60 (one gets 0x20 when BS is missing). The plan is to bring a board to B0 this week or early next week. I need to find more LV Amp connectors.<br>  
<!-- Author: Sebastian -->



<!-- Date: Tue Jan 24 10:58:35 2006 -->
<h3>SB3W10L4 is back in</h3> 
 
<p>One of the ACES noticed SB3W10L4 was black in IMON.  I told we had to take it out as the North wall was out.  However, I noticed the North wall was back in.  So I put e3a4 back in with traceSilicon. I turned it back on and on the second attempt it stayed up.  I did a COLDSTART and we are back in business.</p>
<!-- Author: Ankush -->


<!-- Date: Tue Jan 24 11:55:41 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8205&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8205' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8206&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8206' width='300'></a></center>
<!-- Author: Peter Dong -->
<!-- Comment: Tue Jan 24 12;02;32 comment by...Peter Dong, Ricardo Eusebi, Anna Sfyrla, R. J. Tesarek, Jonathan Lewis, Marv Olson -->
<br><b>Diamond work during the shutdown:</b><br>
We moved the diamond at E11 so that it's closer to the beamline and mounted on a BLM so we have a direct comparison.  We worked on the electronics problems we saw and believe we found the problem: two cables were switched, so we were reading out the wrong channel before.  Many thanks for Jonathan and Marv for their work on this.  We haven't had time to test it, but we hope that we will be able to see a signal now.<br>
We also recovered the ceramics diamond by the BLMs that wasn't working.  Ricardo found the problem in the packaging and fixed it, and now we read a pedestal of < 1 pA and can see a signal from a strontium-90 source.  The diamond is reinstalled.<br>
Hopefully this means we have four working diamonds in CDF and one at E11.  We'll find out when beam comes back.  Interested parties can find the E11 diamond with ACNET variables T:LE1Q07 (instantaneous) and T:LE1V07 (one-second average).


<!-- Date: Tue Jan 24 15:30:53 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8213&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8214' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8209&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8210' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8208&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8208' width='300'></a></center>
<!-- Author: Mark -->
<!-- Comment: Tue Jan 24 15;53;32 comment by...Mark/Ankush -->
<a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=284&frame=2&anchor=12:24:02'>
Previously</a> we found in svxdaq that e182 tends to give illegal channel errors at a much higher rate when dynamic pedestal subtraction is turned on.  We decided to try turning off dps for this ladder and raising the thresholds to the average pedestal + 9.   The new thresholds (from the plot on the left) are:
<br>
<TABLE BORDER=1>
  <TR><TH>Chip<TH>Threshold
  <TR><TD>89<TD>79
  <TR><TD>88<TD>74
  <TR><TD>87<TD>73
  <TR><TD>86<TD>72
  <TR><TD>85<TD>70 
</table>
<br>
The z side is chopped for this ladder.  We added the new settings to the hardware db and took a short cosmics run to test the change.  The center and right plots compare the strip occupancy for this ladder for the old and new chip settings respectively.  They look pretty consistent with chip 85 strips reading out more often after the change.  For now we will leave the new setting in and monitor the error rates and SVXMon plots for this guy when we start taking data again.


<!-- Date: Tue Jan 24 16:23:44 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W8L2 
<li>problem n: 1469 
<li>Status: needs_observation
<li>Type: Chip_other
<li>Action: Chip_bit_changes
<li>entered by: mhartz 
<li>description is: Having seen that turning dps off in svxdaq greatly decreases the illegal channel errors for this ladder, we decided to turn dps off online and raise the thresholds by the average pedestal value for each chip.  We checked the ladder by running cosmics and it looks ok.  We should keep a close eye on this ladder when we start taking data again. 
<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: Tue Jan 24 16:41:16 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W1L2 
<li>problem n: 2 
<li>Status: needs_observation
<li>Type: AVDD2
<li>Action: Diagnosis_update
<li>entered by: mhartz 
<li>description is: Checked the z side for this ladder (which was lost in 1/14/06) quench in svxdaq.  It runs fine in NN and RA modes.  This ladder is not chopped in the hardware db, so we should monitor it during data taking. 
<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: Tue Jan 24 17:36:33 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W1L3 
<li>problem n: 65 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Tested this ladder in SVXDAQ. No errors in RA mode. See bit5 low error in chip a3 if switch to NN mode. Changing R-driver value 4->7 didn't help---rate is about the same. See the same problem in data.  Problem is persistent, but the error rate is <1%. There are no errors in recent cosmic runs. This is a known and old problem, so consider declaring it 'fixed' if rate doesn't go up after a week of running with beam. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W1&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jan 24 17:59:40 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W3L2 
<li>problem n: 1136 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: The problem happens only occasionaly. But the error rate is >70%. Run this ladder in SVXDAQ (~5K events each case): RA--no errors; NN-- no errors; NN with e131 & e132 only-- no errors; NN with e131 & e132 only, and readout length set to 2500-- no errors. Any ideas? Continue to keep an eye on it. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W3&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jan 24 18:14:48 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W6L4 
<li>problem n: 345 
<li>Status: needs_work
<li>Type: Optical_other
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: The problem is still there and can be reproduced in SVXDAQ. Changing r-driver values makes no good.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W6&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jan 24 18:22:03 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W10L0 
<li>problem n: 1612 
<li>Status: needs_work
<li>Type: No_Init
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Still no-init in SVXDAQ. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W10&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jan 24 18:31:24 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W11L0 
<li>problem n: 1613 
<li>Status: needs_work
<li>Type: No_Init
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Still no init read back problem in SVXDAQ, but ladder runs OK. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W11&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Jan 24 18:49:52 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>I got this errors when tried to do a cold start.  
We asked B.B. if there were any funny tests going on at the same time, but there weren't any. 
  
----------------------------------------------------------- 
 
Attention !!!. FERML_SRC_FATALITY ERROR !!!  
  
 SRC Fatality Error for b0svx06: Sl 6 L2A w/o L1A 2 L1A to Buff  
  
 - HALT the run      
 - record any relevant information in e-log      
 - RECOVER - RUN  
 
 
 -------------------------------------------------------------  
  RXPT Error for crate/s:  
    b0svx06 </pre></td></tr></td></table>
<!-- Author: sasha/ankush -->


<!-- Date: Tue Jan 24 18:52:55 2006 -->
iMon got stuck. The error message is "WARNING: reader: in: connection dropped"
<!-- Author: sasha/ankush -->


<!-- Date: Tue Jan 24 19:39:06 2006 -->
<h3> SVX massive trip </h3> 
While the SPL on-call was indisposed, the entire SVX tripped. This is the current state of knowledge: 
<ul> 
<li>Basically all of SVX tripped on DVDD overcurrent</li> 
<li>At bit before, the ISL SRC reported L2 w/o L1A</li> 
</ul>  
This smells like clock, however the SRC error registers were wipped by Lady Mitra while configging. So we dont' have any means of really knowing for sure, what happened. 
The SRC is happy now, so we'll turn things back on.
<!-- Author: Ankush, Sasha and Marcel -->
<!-- Comment: Tue Jan 24 21;25;02 comment by...Sebastian -->
sorry, no baterries in the pager. cell phone would have worked though, the number is listed in the phone list (310-7557). Is is possible that svxdaq and rc where trying to talk to the SRC at the same time?
<!-- Comment: Tue Jan 24 21;27;54 comment by...s -->
mmm, may be the cell phone was without signal? 
<!-- Comment: Tue Jan 24 21;33;02 comment by...Ankush -->
Yep,the Cell phone jumped straight to voice mail.  Maybe one day this US will catch up with the rest of the world and have propper cell phone connections. A cell phone call from England to India is perfect.  While a cell phone call from England to USA is what a call to India used to be like.


<!-- Comment: Wed Jan 25 09;58;10 comment by...Marcel -->
it is interesting to note, that the trip was rather quick, unfortunately, IMON died in the process, so there was no history available to look at. Given the fact, that the backend went first, I would suspect TEV RF to be the prime candidate, but without any traces, this is just a hypothesis. Looking at some previous SRC freakouts like the infamous Schlachtfest of February 2004, it does not look like a SRC thing but a clock thing. <br>
It seems, we have these glitches more frequently, if the TEV is off (see e.g.  
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=210&frame=2&anchor=08:41:48'>
here </a>), but that could be faint memory of an old man as well . So doing some data mining in the SI elog is certainly a good idea. 



<!-- Comment: Wed Jan 25 12;56;17 comment by...Sebastian -->
The CLK problems will be better debugged with the CCC (which has registers for different signal errors). However, I do not thing this was a CLK problem, but may be the SRC got into a bad state if RC and svxdaq where talking to it at the same time.
<!-- Date: Tue Jan 24 20:10:49 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8216&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8216  width='300' align='top'></a></td><td> </td></tr></table>
<!-- Author:   -->
<!-- Comment: Tue Jan 24 20;15;50 comment by...Ankush, Marcel, Sasha -->
<h3>IMON after the SVX Trip</h3>

<p>This was state of IMON just after SVX Tripped.  L00/ISL were fine.  So as mentioned in the previous entry, this intially points to a problem with the SVX SRC.  However the SRC error from ISL also hints at some other central problem. Also anecdotal evidence shows SVX is more sensitive to clocks problems.  It was suggested to crawl through the e-logs and see if there is any correlation for between clock glitches and if the Tev was off.</p>



<!-- Date: Tue Jan 24 20:45:56 2006 -->
<h3>SVX Back Up</h3> 
 
<p>So powering the detector back up was the usual start-stop.  But the detector is up again. We did a COLDSTART for 5000 evetns with no problems.  This was followed by run wedge e05 with SVXDAQ and looking at the histograms.  The histograms looked normal. So eveything seems to be fine....except the AVDD for e012 has stayed persistently PINK. The current is at 590.0 and the lower IMON limit is at 655.0.</p>
<!-- Author: Ankush -->


<!-- Date: Tue Jan 24 20:49:59 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8217&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8218  width='300' align='top'></a></td><td> </td></tr></table>
<!-- Author:   -->
<!-- Comment: Tue Jan 24 20;56;24 comment by...Ankush -->
<h3>AVDD for e012</h3>

<p>This plots shows the AVDD current history for e012. But I noticed the current would return to its nominal value after doing SET DEFAULTS in SVXDAQ but not with CONFIG from run control.  So the first bump around 20:30 is after a SET DEFAUTLS for this ladder.  A point to note is the this ladder initialised with no errors after the first SET DEFAULTS.  However after the second SET DEFAULTS, the ladder returned errors after SET DEFAULTS. (BTW: This ladder has INIT READBACK masked in the HWDB). After closing SVXDAQ and then doing a CONFIG from run-control, the AVDD current returns to its lower value.</p>

<!-- Comment: Tue Jan 24 21;15;46 comment by...Ankush -->
<p>Well I just ran e012 again.  I did a SET DEFAULTS from SVXDAQ and the current jumped back to 755.  I then went to RC and did a CONFIG. This time the AVDD current was stable and did not jump down  to 590.  I then went to ACTIVATE and ran for 5,000 events.  After the 5,000 events the AVDD current stayed stable.  So I guess this ladder got a little upset and seems to be happy again.</p>




<!-- Comment: Wed Jan 25 09;21;23 comment by...Marcel -->
No init readback is a usual feature from an AVDD2 failure.




<!-- Date: Wed Jan 25 10:19:48 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8219&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8219' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8220&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8220' width='300'></a></center>
<!-- Author: Marcel -->
<!-- Comment: Wed Jan 25 10;34;39 comment by...Marcel -->
We may not have IMON, but we have this. Powerful allies Ben's ntuples are. There is a huge spike in DVDD, also pretty quick, because it was not recorded for every ladder in SVX. Given the CAEN trip time (mus) it was however slow enough to be recorded for some ladders, which might point to missing KeepAlives (the come every 270 ms, if I recall right) 
Anyway, this is what tripped the thing. The AVDD lines are quiet, there is not a similar spike structure. A quick look at ISL did not show any similar behaviour, so it seems to be concentrated on SVX. 
Anyway, that gives at least a bit deeper insight.

<!-- Comment: Wed Jan 25 10;44;05 comment by...Qui-Gon -->
270 <b>μs</b><>

<!-- Comment: Wed Jan 25 10;58;51 comment by...Master Kenobi -->
At least somebody is reading the elog even if he is dead ..
how does it feel to talk with that blue aura around you ?


<!-- Date: Wed Jan 25 11:06:49 2006 -->
<h3>BitBooster Candidates</h3> 
 
<p>As part of the shutdown preparation, I went through the e-log and problem DB to find ladders we had marked as BitBooster candidates.  Surprisingly, many of these initial candidates have either been fixed or furher investigation has shown the problems lies with the chip.</p> 
 
<h4>Initial Candidates</h4> 
 
<ul> 
<li>e393: Low light levels. Bit 3 stuck low</li> 
<li>f024: Light Level measurement show Bit 2 has gone</li> 
<li>e182: Bit 2 low with respect to other bits. However data taking shows bits 3 & 7 are high.</li> 
<li>e0B4: Bit 5 was stuck low.</li> 
<li>e080: Bit 2 low & Bit 5 problems</li> 
<li>e564: Had low light levels</li> 
<li>fa30: Bit 1 error</li> 
<li>e1a0: Bits 1 & 2 are low</li> 
</ul> 
 
<p>After checking the problem database and looking at the recent entries, the following were either fixed or were chip problems.</p> 
 
<h4>Removed from BitBooster candidate list</h4> 
<ul> 
<li>e182: Did an RX swap with the RX of e181.  The errors dropped   significantly but returned when the ladder was put into NN mode.  This indicates a chip problem.</li> 
<li>fa30: The Bit 1 error went away.</li> 
<li>e1a0: Bit errors went after a VRB swap.</li> 
</ul> 
 
<h4>Real BitBooster Candiates</h4> 
<li>e393 => fib06, SW Bot : Only read candidate</li> 
<li>f024: Bit 2 looks completly dead.  So unlikely BitBooster will help.</li> 
<li>e0B4: Earlier entries indicate the bit problem lies with the FIFO on chip 8a.  Need to reinvestigate this before we think about making it a BitBooster Candidate; fib00, NW Top</li> 
<li>e080: Entries in the elog suggest a chip problem.  Need to reinvestigate. fib02; SW Bot</li> 
<li>e564: The bit problems were fixed by adjusting the DOIM voltages.  However this ladder started giving problems again after the recent quench.  Needs investigating.  fib06, SW Bot</li> 
</ul>
<!-- Author: Ankush -->


<!-- Date: Wed Jan 25 11:25:31 2006 -->
<br> 
<b>Problems at FCC teststand:</b> today I came to FCC to test the CCC newest firmware changes (see <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=285&frame=2&anchor=18:08:07'> 
here</a>), but could not boot the MVMEs of the teststand. Both hung after showing the vxworks banner. These CPUs are booting from fndaut-fw, at the moment I could ping fndaut-fw, but could not log into it because I do not have an account. However after talking to Bill B and Steve F (FCC) it became apparent that fndaut-fw was having problems (Steve could not log into it). We are now waiting for it to be rebooted.. had to submit a helpdesk ticket to get it done! 
 
  
<!-- Author: Sebastian -->
<!-- Comment: Wed Jan 25 14;38;08 comment by...Sebastian -->
The teststand is working again, it was just a problem with fndaut.


<!-- Date: Wed Jan 25 17:04:13 2006 -->
We changed the sql scripts (the second time I do this, see  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=284&frame=2&anchor=20:37:06'> 
here</a>) to point to the new data area: 
/cdf/onln/data/svxii/caencontrol/PSfiles. So traceSilicon is working again (from the svxii account from the b0dasvx0X machines or from your account in any online machine). 
  
<!-- Author: Ankush/Sebastian -->

<!-- Date: Wed Jan 25 17:24:09 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W4L4 
<li>problem n: 709 
<li>Status: unfixable
<li>Type: BIAS
<li>Action: Removed_hdwdb
<li>entered by: amitra 
<li>description is: <p>Just tried to BIAS this ladder again.  Same problem: it trips on BIAS overcurrent.  At 5V Bias the Bias current >5000 uA.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W4&layer=L4">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Wed Jan 25 18;14;21 comment by...Ankush -->
<pre>Tried to see if this ladder was feeling better.  Along the way we discovered the path problems in the traceSilicon SQL scripts.  

But this ladder is still bad; trips on Bias overcurrent.  It is now back out of the database.</pre>


<!-- Date: Thu Jan 26 10:03:49 2006 -->
<pre>Logic analyzer has been upgraded for the latest windows updates (security patches). 
It can be accessed from a remote machine using microsoft remote desktop or the equivalent linux application.</pre>
<!-- Author: Shulamit, Sebastian, Ankush -->
<!-- Comment: Thu Jan 26 11;53;00 comment by...sebastian -->
Thanks to JJ for the help.
<!-- Comment: Thu Jan 26 12;11;51 comment by...Ankush -->
<pre>The LA IP address is: 131.225.242.26

If you have Win-XP or rdesktop for Linux you can log into the LA.  </pre>
<!-- Comment: Thu Jan 26 12;27;51 comment by...s -->
The ip will change, it's doing dhcp. Also, according to JJ only one user can connect to it at a time. 
<!-- Comment: Thu Jan 26 13;27;36 comment by...Ankush -->
<p>I've installed rdesktop on b0sili02 in my area.  If you want to have a spin on the LA goto b0sili02 and type:
           ~mitra/bin/rdesktop -f 131.225.242.26 </p>

<p>But as Seb pointed out the IP address can change as the LA is on DHCP.  If end up buying the scope rdesktop will be installed in a more appropiate area.</p>
<!-- Date: Thu Jan 26 11:44:18 2006 -->
Having updated SVXMon for the new online machines, we tested it with a short cosmics with silicon run, 210749.  It ran without any problems, and the plots looked ok.  We just have to keep an eye on it when we start taking physics data again.
<!-- Author: Ankush/Mark/Kaori -->

<!-- Date: Thu Jan 26 11:50:31 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W2L3 
<li>problem n: 683 
<li>Status: needs_longterm_monitoring
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>During the comics test I noticed the Bias line for this ladder went pink.  I just check the bias history and there was suddent jump.  So I'm going to push the upper IMON limt up a bit.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>579.957</td><td>579.957</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>675.0</td><td>700.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Thu Jan 26 11:57:15 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8221&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8221  width='300' align='top'></a></td><td> </td></tr></table>
<!-- Author:   -->
<!-- Comment: Thu Jan 26 11;58;42 comment by...Ankush -->
<h3>Bias Current for e123</h3>

<p>This is the ladder with the pinhole whihc was confirmed last week.  So the current going up a little bit; hence the change in the upper IMON bias limit.</p>


<!-- Date: Thu Jan 26 12:05:28 2006 -->
Status of CCC: the error registers look fine, but now the interrupt does not work. Before the interrupt was a DC until it was cleared (not very nice), but by changing it to a pulse it stopped working. Needs more work by Bill H to debug.
<!-- Author: Sebastian -->



<!-- Date: Thu Jan 26 12:58:53 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: The problem with chips 0,2,4 is still there (seen in SVXDAQ). Changing r-driver has no effect.  
<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: Thu Jan 26 13:15:27 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W1L2 
<li>problem n: 1586 
<li>Status: needs_access
<li>Type: Unknown
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Classic bit4 problem. It can be reproduced in SVXDAQ (changing r-driver values has no visible effect), and it's seen on all chips. So, we can do a fiber swap when opportunity arises. 
<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 Jan 26 13:20:11 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W1L3 
<li>problem n: 184 
<li>Status: needs_work
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Wrong CAP_ID for chips 0,1,4, and 5 is still there (can be reproduced in SVXDAQ).  
<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: Thu Jan 26 13:35:27 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W5L1 
<li>problem n: 1182 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Both bit_error and CAP_ID (see previous entry) are still there and can be reproduced with SVXDAQ. I tried to play with r-driver values  with no success, though. Need to try ISEL bits next time.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W5&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jan 26 14:09:47 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W5L2 
<li>problem n: 853 
<li>Status: needs_work
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Tried to reproduce CAP_ID error with SVXDAQ again---no success. The error rate is ~96% during data taking and ~30% during recent cosmic runs (210,267; 210,392; 210,601). I guess if detector is powered the conditions in SVXDAQ (in NN mode) should be similar to those during cosmics. So, I powered the wedge and and run it in SVXDAQ under various conditions--- no success again. It's weird, we see errors in cosmics but not in SVXDAQ. So, I'm wondering what else can different between these two conditions? Need to check if settings are the same in database and svxdaq.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Thu Jan 26 16;12;26 comment by...Shulamit, Sebastian -->
<pre>Tested this ladder with Sebastian - 
we increased the rate in svxdaq in order to see what is the error rate we get. Ran at 500Hz and 4kHz - no errors in normal mode or nearest neighbor mode.</pre>
<!-- Comment: Thu Jan 26 16;49;01 comment by...Master Kenobi -->
You should also keep in mind, that the readout of ISL is only happening with L2A rate. Is chip 98 giving any sensible data while running with SVXDAQ ? <br> 
Because from DS Errmon, it looks like there is only chipID CapID coming out of it.

<!-- Date: Thu Jan 26 14:20:19 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W0L2 
<li>problem n: 1616 
<li>Status: needs_work
<li>Type: BXing_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: The BXing_error is still there and can be reproduced in SVXDAQ. What is interesting is that the error occurs only with first few events if I ran the entire wedge. However, if I include only two ladders, the error rate is much higher (~10%). The error is also not seen in cosmics. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jan 26 14:25:51 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W0L2 
<li>problem n: 1621 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Incident
<li>entered by: sasha 
<li>description is: During investigating BXing_error on this ladder in svxdaq, I also see 'OO Sequence' error from chip14 in NN mode (no errors in RA mode). 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jan 26 14:36:55 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W2L3 
<li>problem n: 1608 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: CAP_ID error is still there and can be reproduced in SVXDAQ. It's also seen in recent cosmic run (210392). 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B0W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Jan 26 15:08:29 2006 -->
After yesterday's <b>web server upgrade</b>, the PS converter stopped working. However after a few email exchanges with Jason H (thanks), it is working again. So please let me know if you find problem with our web tools.
<!-- Author: Sebastian -->




<!-- Date: Fri Jan 27 11:29:16 2006 -->
<h3>CCC work</h3> 
The first phase of the CCC commisioning id done. At FCC 
a second (special) CCC card provides the CDF clock signals 
(both RF and the beam structure) to the CCC that connects to the 
SRC (simulating the real system). These simulated signals are the real RF and BSYNC signals from the TeV CLK system. The CCC  
was tested in the following cases: 
<ul> 
<li> Driving the SRC with silicon with internal and external clocks. 
<li> Disconnected CLK signals to test when the CCC changes CLK 
mode (both RF and BS were disconnected). 
<li> Tested interrupts and error registers. 
</ul> 
The CCC provides a separate register for RF, AG, SYNC, BX and BZ errors, which hopefully will help understand if the sporadic mysterious  trips are related to clock problems. The next step is to test the CCC at the B0 teststand. 
  
<!-- Author: Sebastian -->
<!-- Comment: Fri Jan 27 11;30;26 comment by...s -->
Should say that one CCC card was found to have problems, but this was known by Bill H already.


<!-- Comment: Fri Jan 27 16;49;39 comment by...Sebastian -->
<h3>Problems at B0</h3>
I brought a CCC card to test it at B0. After getting the 3.3V needed by the card, noticed that as soon as the power was up the VMESEL LED went on (together with the 5V and 3.3V which indicat that power was OK). The VMESEL LED on all the time means trouble, somehow the card thinks that it's being VME accessed all the time. No surprise that when trying to talk to the card I got VME BERR. I thought it was related to the split backplane of the teststand and removed all the boards from it. But I was still getting BERR. Called in Bill and we tried a different power supply (for the 3.3V) and tried pulling everything out of the crate (including the CPU)... still the VMESEL LED was on! (BTW I took all to FCC to double check the CCC card and it was fine).
At this point we are clueless. Decided to try again on Monday with a VME bus led display.
<!-- Comment: Fri Jan 27 16;53;41 comment by...Sebastian -->
Should note that we also tried the CCC in b0svx08, just to see the LEDs (the CCC does not do geographical addressing) and the VMESEL also was stuck on (after the test was done I did a coldstart - all OK). I am putting the teststand together again now.
<!-- Comment: Sun Jan 29 17;54;36 comment by...Sebastian -->
Today I tested the CCC in the TS teststand.. still VMESEL stuck ON. I went to FCC, setup another teststand with 3.3V (production teststand - D0's I believe) and tested the CCC, VMESEL stayed on! With a VMDIS found that the difference between the DAQ FCC teststand and this production teststand is that in the DAQ one the IRQ1 LEDs 5 and 6 and the IACK LED stay on while in the production they are OFF (in DIRect measurement). This points to the source of the problem, may be. Will talk to Bill and Vince about it tomorrow.
<!-- Date: Fri Jan 27 11:38:49 2006 -->
<h2>Controlled access report </h2> 
 
It was noticed during post quench check out that f502 started giving BXing errors. Tests during quiet time studies showed that this error occured only if f502 is included along with any other  
ladder from the same fib. However, there were no BXing errors if  
f502 was tested alone. Marcel suspected that this could be a fib problem, so we went into collision hall to investigate this. First, we swapped fibers (f502<->f501)--problem remained with the pipe indicating troubled fib. Next, we swapped the fib (fib07,slot10: board s/n 101 is OUT; board s/n 149 is IN). Apparently, the fib swap fixed the problem. 
<!-- Author: sasha/marcel/ankush -->
<!-- Comment: Fri Jan 27 12;55;08 comment by...A/M/S -->
We put the FIB in the teststand but found no errors in 1.7Mloops. 
<!-- Comment: Fri Jan 27 12;55;39 comment by...s -->
I'm stopping the test now to add the CCC.
<!-- Comment: Fri Jan 27 16;59;22 comment by...Marcel -->
Ran this ladder again , no errors seen. So the FIB is still the prime suspect.
<!-- Comment: Fri Jan 27 17;00;42 comment by...Marcel -->
<table border=0><td><tr><td bgcolor=#e0e030><b>Please close the partition after you are done using RC and Coldstart. Otherwise you are up for a nasty surprise for the next store</b></td></tr></td></table>
<!-- Comment: Sat Jan 28 21;40;26 comment by...Sebastian -->
166M loops no errors. This FIB is Ok as far as we can tell.
<!-- Date: Fri Jan 27 11:48:04 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W0/1All 
<li>problem n: 393 
<li>Status: needs_observation
<li>Type: BXing_error
<li>Action: Swap_FIB
<li>entered by: sasha 
<li>description is: We swapped the fib (s/n 101--OUT; s/n 149--IN) to fix the BXing problem with f502 (see <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=285&frame=2&anchor=14:20:19'> here</a> and <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=285&frame=2&anchor=11:38:49'> here</a>). It looks like the swap fixed the problem. Need to make observations for a week or two. <table border=1>
   <tr>
    <td>
     <b>IN:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/fibdb/DBreport.pl?serial=149">149</a>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/fibdb/DBreport.pl?prep=??">??</a>
    </td>
   </tr>
   <tr>
    <td>
     <b>OUT:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/fibdb/DBreport.pl?serial=101">101</a>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/fibdb/DBreport.pl?prep=??">??</a>
    </td>
   </tr>
  </table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W0/1&layer=All">report</a></ul>
<!-- Author: Problem DB -->









<!-- Date: Fri Jan 27 17:17:24 2006 -->
The teststand is up again, and the FIB is being tested (now only the first 3 channels to try to reproduce the errors in the system).
<!-- Author: Marcel/Sebastian -->


<!-- Date: Fri Jan 27 23:33:47 2006 -->
<pre>Hockerized crate 13 because of SVX trips of its wedges. </pre>
<!-- Author: Shulamit -->


<!-- Date: Sat Jan 28 00:34:12 2006 -->
This store (<b>4612</b>) started with low luminosity but in any case we are unable to take data, there's a CMP crate with a bad card apparently... The TEL was down in the beginnning of the store but now is up and the beam looks fine, but we have to wait for the CMP  card (and probably some L2 calorimeter problem) to be fixed. We did a coldstart to get rid of some pinkies after the hockerization.
<!-- Author: Shulamit/Sebastian -->


<!-- Date: Sat Jan 28 03:12:19 2006 -->
We are taking data now. f002 is pink on AVDD, the current dropped by 50%. We tried power cycling the wedge and that did not work. WE'll try again tomorrow. This is not a good store anyhow.
<!-- Author: Sh/S -->
<!-- Comment: Sat Jan 28 03;13;12 comment by...sh/s -->
Also note that the SVTspymon link is broken.

<!-- Comment: Sat Jan 28 04;15;15 comment by...Sebastian -->
IB0W0L2 is not giving data, and the AVDD current is low (however it 
was not giving data <b>before</b> the current became pink).
Tried a vme reset of b0fib03 to bring <b>IB0W0L2</b> back, did not work. <b>However further investigation shows that this ladder did not give data in previous recent cosmic runs, for eg: 210392, 210267.</b> But I did not find any entries in the problem DB or in the elog about it... (many be I'm too tired, so I'm going home.. but we need to look into this ladder).
<br><br>
On a separate note for our SVXMon expert, the link /cdf/onln/data/cdfdaq/consumer/results/SVXMon/svxmon_yellow.txt
is not updating. Or this file is somewhere else now?
<br>
BTW, we are still having problems with high deadtime due to hot L2 calorimeter triggers.

<!-- Comment: Sat Jan 28 08;55;16 comment by...Ankush -->
<p>I just cheked the BitReporter.  The last time this was giving data was the 14 Jan 2006; one day before the quench.  The immediate run after the quench (16 Jan 06) was part of a DMode Calibration.  Since then we have had no data.  However during the post-quench check out we went over every ladder and it did appear to be fine; the check out was done on the 15 Jan 2006.</p>

<p>So whenever this store drops we <b>have</b> to investigate this ladder; it may involve an access.  But one thing we can certainly learn from this. We have had several COSMICS runs over the last week and no body spotted this. We all take the blame here.</p>

<!-- Comment: Sat Jan 28 09;52;06 comment by...Mark -->
It looks like svxmon_yellow.txt does get updated, just not at the same rate as the root file:
<br>
< b0gateway.fnal.gov> ls -l svxmon_yellow.txt <br>
-rw-r--r--    1 cdfdaq   cdf           492 Jan 28 08:23 svxmon_yellow.txt
<br>
vs.
<br>
< b0gateway.fnal.gov> ls -l svxmon_210845_tmp.root <br>
-rw-r--r--    1 cdfdaq   cdf       8853055 Jan 28 09:15 svxmon_210845_tmp.root
<b0gateway.fnal.gov>

<!-- Comment: Sat Jan 28 10;24;13 comment by...Mark -->
Upon further reflection, it looks like svxmon_yellow.txt is written at the beginning of an SVXMon run after 1000 events have been logged.  Is that not the expected behavior.

<!-- Comment: Sat Jan 28 10;26;45 comment by...Ankush -->
Yes that's correct.  You have to collect 1,000 events before svxmon_yellow.txt is written.


<!-- Comment: Sat Jan 28 10;42;06 comment by...Ankush -->
You can see 
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=242&frame=2&anchor=14:14:44'>
here</a> and learn some rhyming slang at the same time
<!-- Comment: Sat Jan 28 10;58;36 comment by...Mark -->
Hmm, let me see if remember how to play this game.. butchers->meat hook->look?
<!-- Date: Sat Jan 28 10:39:48 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8222&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8222' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8223&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8223' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8224&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8224' width='300'></a></center>
<!-- Author: Mark -->
<!-- Comment: Sat Jan 28 10;54;14 comment by...Mark -->
Here a look at e182, for which we had turned of dps and raised the thresholds earlier this <a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=285&frame=2&anchor=15:30:53'>
week</a>.  The above plots compare the strip occupancy of: e182 before the change (left), e182 from this morning's run 210844 (middle) and e192 from 210844.  The occupancy looks reasonable.  Taking a look at the error rates, here is the summary for run 210008 before the shutdown:
<br><br><i>
SB1W8L2<br> 
        Bit Error (not 0/1) | 655 | This error was present in  655 events out of  14701<br> 
        C2 Termination | 3 | This error was present in  3 events out of  14701<br> 
        Illegal Termination | 167 | This error was present in  167 events out of  14701<br> 
        Unknown Channel | 50 | This error was present in  50 events out of  14701<br> 
        Unknown Chip Error | 356 | This error was present in  356 events out of  14701<br> 
        ff or 7f Error | 2271 | This error was present in  2271 events out of  14701</i>
<br><br>
And here it is for run 210844:
<br><br><i>
SB1W8L2<br> 
        Bit Error (not 0/1) | 1 | This error was present in  1 events out of  1244</i>
<br><br>
So it looks like this change may have been successful.


<!-- Comment: Sat Jan 28 11;09;59 comment by...Ankush -->
phew..hopefully we did fix one thing !!


<!-- Date: Sat Jan 28 11:20:44 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8225&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8225' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8226&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8226' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Sat Jan 28 11;23;11 comment by...Ankush -->
<h3>Voltage & Current History for f002</h3>

<p>According to the history plots both the AVDD Voltage and Current have been stable for quite a while.  Although we do see some entries below the norm for IAVDD for recent entries.  However this could be due to this ladder getting powered up and down.  But not suddent drops to 630mA as we are getting now.</p>


<!-- Date: Sat Jan 28 11:31:51 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8227&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8227' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8228&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8228' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8229&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8229' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8230&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8230' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Sat Jan 28 11;33;22 comment by...Ankush -->
<h3>f002 data (or lack of it!)</h3>

<p>Here are the mean charge strip plot for f002 for the 16 chips of ISL.  As you can see, the plots are empty.  This ladder is returning zero data !!!!</p>

<!-- Comment: Sat Jan 28 11;48;12 comment by...Ankush -->
<pre>just for fun I powercycled the wedge again...I was feeling lucky. But no surprise, the ladder failed to return any data.

Incidently I can't get siDumpNow to work.  Fails on B0AC++Dump.  SO I have lost the the ability to look at live raw data.  Anybody willing to share their magic with me.

Anyways, I think this ladder can only be fixed with an access.</pre>


<!-- Comment: Sat Jan 28 12;38;55 comment by...Mark -->
Looks like B0AC++Dump is not being built for the online code release for the SL machines. It still works on the old machines, however.  I would give it a try on b0dap72.
<!-- Comment: Sat Jan 28 12;39;28 comment by...Sebastian -->
f002 is not giving data, yes, as noted up <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=285&frame=2&anchor=03:12:19'>
here</a> (??). The empty histograms do not add much I think. <br>
B0AC++Dump works on b0dap72.
<!-- Date: Sat Jan 28 12:09:27 2006 -->
<h3>Trippy Electron Lens</h3> 
 
<p>While hanging out in the Control Room we have had several Electron Lens trips.  The Electron Lens came back pretty quickly and AGIGI2 stayed low; so Silicon was kept in through the Electron-lens trips.</p>
<!-- Author: Ankush -->


<!-- Date: Sat Jan 28 12:33:45 2006 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sat_Jan_28_2006_123342.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8232  align='top'></a></td><td> </td></tr></table>
<!-- Author: Ankush -->
<!-- Comment: Sat Jan 28 12;41;52 comment by...Ankush -->
<h3>Slightly dodgy : I ran f002 with SVXDAQ while there was Beam in the machine</h3>

<p>Veronica was in the control room doing a no-silicon trigger test . So I took the opportunity to have a quick look at f002 with SVXDAQ. As this is unconventional to do this with beam in the machine I asked the ACE to put Silicon to STANDBY.  My main purpose was just to see if we get any data out of f002.  So I ran SVXDAQ and f002 failed to return any data most of the time.  However look at the plot above.  You can see f002 did return some data from the first chip.  So further quiet time will be needed to see what is really wrong with the ladder.</p>


<!-- Comment: Sat Jan 28 13;23;42 comment by...Only the paranoid survive -->
it would be even more useful to paste some raw data to see what is wrong with that HDI
<!-- Date: Sat Jan 28 13:02:29 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8233&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8234  width='300' align='top'></a></td><td>Fixed Marcel's perl wrapper to SVTspy mon (the link works again), this plot shows current status.</td></tr></table>
<!-- Author: Sebastian -->


<!-- Date: Sat Jan 28 13:05:16 2006 -->
<h3>Something for the cooling people</h3> 
 
<p>Also noticed the BHW1 COT pressure is hovering close to its upper warning limit of 13.1; it currently hovers from 12.9 to 13.0.   Over the past few weeks the SVX and L00 go yellow in the IFIX global alarms page.  This keeps coming and going.  I would like to have it fixed otherwise the ACEs may start to ignore it.</p> 
 
<p>Eva (SciCo!!) and I had a look at its history.  There was a big jump in Novemebr when the Air Drier for the Acutators was moved.  But it does seem to be holding steady.</p>
<!-- Author: Ankush -->
<!-- Comment: Sun Jan 29 09;55;28 comment by...Ulrich -->
I talked about this with Eva this morning. It is not a severe problem and it would be easy to fix, but I am rather unwilling to change chiller parameters when there is no real need. I do not see the danger of aces ignoring the warning either. They are supposed to ignore transient warnings, but to react permanent yellow. If you insist, I can tweak the valve settings in the next quiet time.
<!-- Comment: Sun Jan 29 09;57;14 comment by...Sven-Goran Eriksson -->
Never change a winning team.
<!-- Comment: Sun Jan 29 10;25;00 comment by...Ankush -->
that's a fair comment...the one from Ulrich; not the one from Sven.  (You would have thought Sven would have learnt his lesson about making random comments to stangers). The tweaking can be easily dealyed to the shutdown; we have 3 months of tweaking time.
<!-- Date: Sat Jan 28 19:49:05 2006 -->
Alberto is doing some SVT tests (moving boards around to make room for new ones), everything is all right. Looks like DQMon is having problems to determine that SVXMon is running (or XMon, SVTSPYMon, etc), looks to me that DQMon is not aware of some the fileserver changes. For now we are ignoring SVXMon alarms from SVXMon (which, in any case are useless, it only complains about SVXMon not running, when in fact it is running). 
<!-- Author: Sebastian -->


<!-- Date: Sat Jan 28 21:00:18 2006 -->
TEL tripped and MCR is having problems bringing them up again. AGIGI2 increased to 16, we are in STBY waiting for MCR to fix their problems. 
<!-- Author: Sebastian -->


<!-- Date: Sat Jan 28 21:22:07 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8235&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8235  width='300' align='top'></a></td><td>TEL tripped off, could not be recovered yet, and the abort gap is filling up.</td></tr></table>
<!-- Author: Sebastian -->
<!-- Comment: Sat Jan 28 21;35;10 comment by...Sebastian -->
They are going to abort the beam... AGIGI2 is <b>25E9</b>, we should be fine.


<!-- Comment: Sat Jan 28 22;01;31 comment by...Sebastian -->
We are waiting for D0 to be ready for store termination... (apparently an expert ha to come to remove the roman pots).

<!-- Comment: Sat Jan 28 22;03;22 comment by...Sebastian -->
We just aborted with AGIGI2 reading 26E9... no pinkies in IMON!

<!-- Comment: Sat Jan 28 22;05;36 comment by...A/S -->
Did a cold start and everything looks fine.

<!-- Comment: Sat Jan 28 22;10;11 comment by...Sebastian -->
No radiation dose detected, see <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=84&frame=2&anchor=22:06:30.032'>
here</a>. 


<!-- Date: Sat Jan 28 22:16:46 2006 -->
<h3>SVXDAQ for f002...again</h3> 
 
<p>After the store was dropped I ran SVXDAQ again with the same results.  One entry commented the raw data would have been more useful to see.  Well here you go, the data for just running f002 on its own</p> 
 
<pre> 
0x00000000:  0028060f 00000000 00000000 00000000 00060000 00000000 00000000 00000000 
0x00000020:  f00279fc c2c20000 00280602 00000000 00000000 00000000 00060000 00000000 
0x00000040:  00000000 00000000 f00279fc c2c20000 0028060b 00000000 00000000 00000000 
0x00000060:  00060000 00000000 00000000 00000000 f00279fc c2c20000 00280606 00000000 
0x00000080:  00000000 00000000 00060000 00000000 00000000 00000000 f00279fc c2c20000 
0x000000a0:  0028060f 00010000 00000000 00000000 00060000 00000000 00000000 00000000 
0x000000c0:  f00279fc c2c20000 00285002 00010000 00000000 00000000 00060000 00000000 
0x000000e0:  00000000 00000000 f00235fc c2c20000 0028070b 00010000 00000000 00000000 
0x00000100:  00060000 00000000 00000000 00000000 f00235fc c2c20000 00280706 00010000 
0x00000120:  00000000 00000000 00060000 00000000 00000000 00000000 f00235fc c2c20000 
0x00000140:  0028070f 00010000 00000000 00000000 00060000 00000000 00000000 00000000 
0x00000160:  f00235fc c2c20000 00280702 00010000 00000000 00000000 00060000 00000000 
0x00000180:  00000000 00000000 f00235fc c2c20000 0028070b 00010000 00000000 00000000 
0x000001a0:  00060000 00000000 00000000 00000000 f00235fc c2c20000 00280706 00010000 
0x000001c0:  00000000 00000000 00060000 00000000 00000000 00000000 f00235fc c2c20000 
0x000001e0:  0028070f 00010000 00000000 00000000 00060000 00000000 00000000 00000000 
0x00000200:  f00235fc c2c20000 00280702 00000000 00000000 00000000 00060000 00000000 
0x00000220:  00000000 00000000 f00235fc c2c20000 0028070b 00000000 00000000 00000000 
0x00000240:  00060000 00000000 00000000 00000000 f00235fc c2c20000 
</pre> 
 
<p>As you can see, f002 returing sweet fanny adams. Not of the 16 ISL chips is talking.</p>  
<!-- Author: Ankush -->
<!-- Comment: Sat Jan 28 23;34;48 comment by...Sebastian -->
so, we are dropping readout. I guess not data in the first chip after all (?).
<!-- Comment: Sat Jan 28 23;41;07 comment by...Ankush -->
<p>As the first chip gave data from time to time (& very rarely), I was thinking the first chip in the chain was bad.  So I sparsed out the first chip in SVXDAQ.  But this has no effect.... I continued sparsing out to the second and third chip to no avail. This still points to an access to see find out what is really going on.</p>
<!-- Comment: Sat Jan 28 23;59;15 comment by...Ankush -->
<p>So I went through the whole ladder and sparsed out each chip on by one.  This has no effect. On every attempt to I had the same result: no data from the ladder.</p>

<p>I did a COLDSTART at the end to put the detector back to its default state.</p>
<!-- Comment: Sun Jan 29 12;25;22 comment by...Lt. Col. Kilgore -->
That at least looks like the pipe of the FIB is kind of working, since FIB header BXing Backend state are all there. Then the FIB times out. Anyway, without a fiber swap it is difficult to tell, what is happening there. And I would take a spare RX with me as well.
<!-- Date: Sat Jan 28 23:17:31 2006 -->
<h3>Checking the Bias Lines</h3> 
 
<p>As AGIGI2 was rather large I decided to double-check the Bias lines.  So I Bias the detector and checked every ladder was drawing current.(I now realised a quick way to do this is to read off the currents in PS-GUI.)  All the integrated ladders were drawing current except 3 L00 Ladders:</p> 
 
<ul> 
<li>LB0W2L3: Bias 0</li> 
<li>LB0W0L0: Bias 0</li> 
<li>LB1W0L3: Bias 0</li> 
</ul> 
 
<p>However these 3 ladders have a history of drawing zero current.  Looking over the recent history they have fluctated between 0.0 and 1.0; ie- 1 ADC count.  So I <em>think</em> we are OK.</p>
<!-- Author: Ankush -->
<!-- Comment: Sat Jan 28 23;36;00 comment by...Sebastian -->
These are the usual suspects, compare to <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=259&frame=2&anchor=08:39:13'>
this</a> list.
<!-- Date: Sat Jan 28 23:36:00 2006 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 430
Calibration type  : standard
Run period tag    : Jan_2006
DPS-off run       : 210906
DPS-on run        : 210907
Requested by      : Brian Mohr
Main process id   : 2862
Comment           : beam off
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->








<!-- Date: Sun Jan 29 10:18:46 2006 -->
<h3>fib07 reboot</h3> 
 
<p> 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=86&frame=2&anchor=09:04:16.246'> 
Around 9AM</a>, fib07 gave "heap corrupt".  The ACE did the right thing and rebooted the CPU. During the reboot, there were some PINKIES in IMON which the ACEs took care of. The strange thing was the error logger which came out a bit funny.  But the ACEs sorted all this out themselves.  They did a good job.</p> 
  
<!-- Author: Ankush -->



<!-- Date: Sun Jan 29 10:37:32 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8236&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8237  width='300' align='top'></a></td><td>SVT plot from last night for the beginning of store 4614. 
Initial luminosity 73.76. </td></tr></table>
<!-- Author: Shulamit -->


<!-- Date: Sun Jan 29 17:37:23 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W0L2 
<li>problem n: 1622 
<li>Status: needs_access
<li>Type: Unknown
<li>Action: Incident
<li>entered by: amitra 
<li>description is: This ladder stopped giving data from 18 Jan 2006 (may have been earlier) but wasn't noticed for a week.  The cause of failure is unknown.  Needs access to do fibre swap and then proceed with a FIB or RX swap. 
<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: Sun Jan 29 20:47:37 2006 -->
<pre>I wrote a perl script, which prints out current BIAS currents for each ladder. It is located in b0dap72///cdf/onln/home/tmaki/Silicon_BIAScurrents.pl 
 
This tool should make it easier to find problematic ladders after big quenchies etc. Ladders listed in bad_channels.txt are not printed out. The print color is changed red if the BIAS current is not greater than (reference+4.0). Reference value is the BIAS current for each ladder on 1/23/2006, detector in STANDBY. If needed, the user can edit the lists of bad channels and reference values. </pre>
<!-- Author: Tuula -->
<!-- Comment: Mon Jan 30 11;40;06 comment by...boveia -->
<pre>Shouldn't the reference be a biased detector, not a detector in standby?</pre>
<!-- Date: Mon Jan 30 08:57:26 2006 -->
The low lum store is planned for today, delayed because of problems with a wet engine. We might have an access opportunity today to look at f002.
<!-- Author: Sebastian -->


<!-- Date: Mon Jan 30 09:23:23 2006 -->
<br><b>Week Summary</b><br> 
<ul> 
<li><b>Monday</b> - no beam. IMON not updating since around the 20th, reason not clear, needed to be restarted <br> 
<li><b>Tuesday</b> - no beam. SB3W10L4 turned black in IMON, after taking it out  and including it again and running a coldstart it is back and working. <br> 
Diamond work - fixed electronics problem and recovered a ceramic diamond that didn't work. Now there are four working diamonds in CDF and one at E11. <br> 
Mark worked on e182 which gives higher error rate when dynamic pedestal subtraction is turned on, added new setting to the hardware DB and tested it.<br> Quiet time studies.<br> 
SVX tripped - probably because RC and svxdaq were talking to the SRC at the same time. Powered up the detector without special problems. <br> 
AVDD failure for e012. Ladder showed high current jumps, Ankush was investigating, now it's back to normal operation. 
<li><b>Wednesday</b> - no beam.  
<li><b>Thursday</b> - no beam yet. SVXMon updated and tested. Quiet time studies by Ankush & Sasha. <br> 
<li><b>Friday</b> - no beam. Sebastian continues working on the CCC, still problems...<br> 
Conttolled access to figure out error source for f502. Fib swap fixed the problem.<br> 
<li><b>Saturday</b> - Finally - tevatron is up again, new store(4612) with los luminosity. TEL was down and there was a CMP crate with a bad card. Beam and losses looked stable, when problems were fixed the silicon was included as well.<br> 
We noticed that IB0W0L2 is not giving data and the AVDD current is low, as noticed later this was the situation in previous cosmic runs. Tries power-cycle, VME reset, asked for access to investigate when there is the opportunity for that. 
<br> Put silicon to standby when TEL tripped and AGIGI2 was increasing. Store was aborted with AGIGI2 26. 
<li><b>Sunday</b> - New store 4614, initial luminosity ~74, silicon included right at the beginning. 
</ul>
<!-- Author: Sebastian, Shulamit -->