<!-- Title: 08:58:49  Thu Jan 12 2006 -->
<!-- Crewchief: Kevin Lannon -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>A new page for a new year</pre>


<!-- Date: Thu Jan 12 12:09:44 2006 -->
<pre>Disconnected tracer module and inserted a test clock in slot 21 
of crate b0xft07, to perform tests with sxft at B0.</pre>
<!-- Author: Paolo Azzurri & Ivan Fedorko -->


<!-- Date: Fri Jan 13 12:18:14 2006 -->
<pre>This is a report on testing we did to check the Transition boards and fiber connections during the access in early December. Once we plugged in the fibers into the transition board and Patch panel. We took a set of fibers and connected them between the patch panel and a Pulsar sitting in b0xft06. We sent a fixed pattern of walking ones in the data part of the XTC data: 
 
001 
002 
004 
008 
010 
020 
040 
080 
100 
200 
400 
800 
 
The connections were put into 3 categories which you can 
find in the second column: 
 
"G": good: We performed about 1 million captures of the above data pattern and saw no errors 
"R": recheck marginal or not sure: found some errors in 1 million          
        captures or could not configure XTC2 to send patterns 
        (not all XTC2's were installed, this is the category that     
         needs to be checked again) 
"B": broken: no data captured *and* Link LED is off and red LED  
        is on, on receiver card 
 
summary: 
 
http://www.hep.uiuc.edu/home/mendi/xft/mapping/cablemap_fibertest.pdf 
http://www.hep.uiuc.edu/home/mendi/xft/mapping/cablemap_fibertest.xls 
http://www.hep.uiuc.edu/home/mendi/xft/mapping/cablemap_fibertest.txt 
</pre>
<!-- Author: Heather and Greg -->
<!-- Comment: Sat Jan 14 12;52;04 comment by...Heather and Greg -->
here are direct links: <br>
<a href="http://www.hep.uiuc.edu/home/mendi/xft/mapping/cablemap_fibertest.pdf"> cablemap_fibertest.pdf </a> <br>

<a href="http://www.hep.uiuc.edu/home/mendi/xft/mapping/cablemap_fibertest.xls"> cablemap_fibertest.xls </a> <br>

<a href="http://www.hep.uiuc.edu/home/mendi/xft/mapping/cablemap_fibertest.txt"> cablemap_fibertest.txt </a> <br>



<!-- Date: Sun Jan 15 16:10:38 2006 -->
<pre>Beware: the test clock in b0xft07 slot 21 is now configured to send signals directly to the backplane (jumpers s2-s6 inserted).  Make sure this test clock is never inserted together with the tracer! </pre>
<!-- Author: Paolo & Ivan -->


<!-- Date: Mon Jan 16 13:51:44 2006 -->
<pre>I booked b0xft06 and the cot crates in order to test capture 
code.</pre>
<!-- Author: Jay -->
<!-- Comment: Mon Jan 16 17;37;21 comment by...Jay -->
<pre>done -- no change to crate configuration!</pre>


<!-- Date: Tue Jan 17 00:03:33 2006 -->
<pre>I took over from Jay and have started the testing of the 
XTC2->Finder connection. I have tested 3 SL7 finders: 
b0xft06, slots 18, 19, 20. I have found problems with 5 
connections. 4 I believe are problems with the XTC or TM 
board: 
 
b0cot00 slot 3 
b0cot02 slot 5 
 
These seem to send out data that is offset relative to the 
control signals.  
 
There is one fiber that has no data: 
b0cot01 slot 5B or b0xft06 slot 19G ("F" in cablemap file) 
 
The fibers have not been connected to the finder as 
described in the cablemap file or the labels. But 
they follow simple pattern that distributes the fibers 
more or less evenly to the two Finder FPGA's.  
 
The mapping depends on the Superlayer. This is 
how it is translated: 
 
SL3: 
A->A 
B->B 
C->E 
D->G 
F->L 
E->K 
 
SL5: 
A->A 
B->B 
C->C 
D->D 
E->E 
F->G 
G->K 
H->L 
 
SL7: 
A->A 
B->B 
C->C 
D->D 
E->E 
F->G 
G->I 
H->J 
I->K 
J->L 
 
To use these in Jay's capture program it is necessary to 
know the corresponding numbers: 
 
First of all, for the COT: 
A,C --> 1 
B,D --> 0 
 
For the Finder: 
A: 0 
B: 1 
C: 2 
D: 3 
E: 4 
G: 7 
I: 8 
J: 9 
K: 10 
L: 11 
 
</pre>
<!-- Author: Greg -->
<!-- Comment: Tue Jan 17 00;08;07 comment by...Greg -->
<pre>To be more specific on the testing. I am using Jay's java based program, which loads random patterns into the xtc2 card and captures them in the finder and makes a comparisons. For these tests I just check a few captures to see if the data is reasonable. Once we go through the system once like this, we will run longer tests, hopefully in parallel.
</pre>

<!-- Comment: Tue Jan 17 08;45;52 comment by...Jay -->
<pre>I would like to acknowledge Jon Wilson!  He is the principal
author of the capture code.</pre>


<!-- Date: Tue Jan 17 12:22:36 2006 -->
<pre>I am using the cot crates and xft crates 06 and 07 to run capture test.  </pre>
<!-- Author: Heather Gerberich -->
<!-- Comment: Tue Jan 17 12;32;04 comment by...Heather -->
<pre>XFT crate 07 doesn't seem to be working right now for these tests, so I released it.</pre>


<!-- Date: Tue Jan 17 18:27:30 2006 -->
<pre>We finished doing pixel driver to wire capture loop tests  on the finder modules in b0xft07 and b0xft06 with sxft and a test clock (as in the HR test stand).  We tested  
slots 3,4,5,6,7,8,9,12,15,19,20 in b0xft07   
slots 3,8,9,14,15,20 in b0xft06 
all tests OK. The test clock module is now back upstairs in the xft lab (203).  
</pre>
<!-- Author: Paolo & Ivan -->


<!-- Date: Tue Jan 17 22:33:29 2006 -->
<pre>Heather went through and tested all of the connections going to 
xft06. Here is the list of the connections that are not behaving 
in their respective categories: 
 
data misaligned or scrambled, likely TM or XTC: 
b0cot00 3 
b0cot01 14 
b0cot02 5 
b0cot02 13 
b0cot07 9 
b0cot09 5 
b0cot12 12 
b0cot18 13 
b0cot19 14 
-->I would like to try to swap an xtc card on one of 
   these TDC's and see if that fixes the problem.  
   I will request b0cot19, since the other two boards in 
   that crate have "died", and we might as well swap all 
   3 with v16 cpld firmware.  
 
channels with no data: 
09-02D/6-18A    (marked as dead fiber in December tests as well) 
11-13B/6-12H    (marked as dead fiber in December tests as well) 
10-14A/6-11H    (Heather got no data, Greg gets bad data) 
 
Since these match dead fibers from december I am guessing 
they are either broken fibers or they were not connected 
well in the collision hall. We should access these this 
week, and plug a spare into the duplicate output. 
 
Finally, we have had a lot problems with fibers connected 
to Finder input G, FIFO #7. Very often these do not read out any 
data the first few tries. I have found that if I try to read 
out the FIFO #6, which I think corresponds to the duplicate 
data, and then I go back and read FIFO #7, it miraculously 
fixes itself. I think this might be a problem with the Finder 
or Receiver card firmware. Hopefully we can learn more about 
this. 
</pre>
<!-- Author: Heather and Greg -->


<!-- Date: Wed Jan 18 15:21:04 2006 -->
<h3>SLAM Firmware Tests</h3> 
 
<p>We took some no beam tests of the slam firmware with glitch protection (version 3105).  This firmware is supposed to eliminate the low rate of bit errors we see from the SLAM.  First we took the standard default linker and nobeamdg linker test runs with v3105 loaded into all the linkers.  For these runs (201242,45,46,47), we saw no errors. 
 
<p>Next, to try to investigate whether the glitch protection was actually working, we changed the timing on one SLAM board (b0xft05, slot 9) back to a value that produced errors with the old firmware (v3104).  For run 210252, we had v3105 in b0xft05, slot 9 and saw errors at a rate of 83/153190 (0.05%) events.  For run 210260, we put v3104 back in b0xft05, slot 9 and saw errors at a rate of 43/13041 (0.33%).  For run 210261, we put the timing of b0xft05, slot 9 back to it's old setting (decimal 12,8) and saw no errors in 12994 events (with v3104).  We conclude that the glitch protection is improving the error rate by a factor ~10.  Further investigation is required to see if we can do better.
<!-- Author: K.Lannon -->
<!-- Comment: Wed Jan 18 15;35;35 comment by...K.Lannon -->
Note: I'm leaving v3105 in for now.  Our hope is to go to a newer version soon that will be appropriate for the new axial XTC timing we want to put in later this week.


<!-- Date: Wed Jan 18 20:35:14 2006 -->
<h1>fiber debugging</h1> 
 
We started debugging the fibers in the NE corner.  We determined the fiber 537/11-13B/6-12H was broken and swapped in the fiber 54a/11-99A/6-13S, which solved the problem.  For the fiber 527/10-14A/6-11H we determined that the problem is downstream of the patch panel.  We replaced the XTC in b0cot12 and thereby fixed the problems on the corresponding fibers.<p> 
 
It turns out that if we use input channel 5 instead of input channel 7 when capturing the data, many problems just disappear.  In principle those channels should be the same, but on different chips.  However it seems there is still a bug in the software.<p> 
 
There are two more broken XTCs in that rack, which I plan to swap tomorrow so that I can test the remaining four fibers in this rack.
<!-- Author: Nils, Paolo -->
<!-- Comment: Wed Jan 18 21;07;44 comment by...Nils -->
I just figured out I missed a couple of fibers that go to the other XFT crate.  I will try to take care of those tomorrow.


<!-- Date: Thu Jan 19 20:11:34 2006 -->
<h3>fiber debugging</h3> 
 
I finished with the first round of fiber debugging on the north side.  except for two fibers that give no signal and on that is losing bits, the rest of the problems seem to be XTC problems or finder input problems on channel 5.
<!-- Author: Nils -->


<!-- Date: Fri Jan 20 12:28:16 2006 -->
All SLAM boards have been loaded with a new version of the passthrough design that delays their output to the XTRP by 132ns.  This is needed for when we move to the earlier XTC copy.  The version number is 3305.  Nils will change the axial XTC timing later today.
<!-- Author: K. Lannon -->


<!-- Date: Fri Jan 20 16:16:02 2006 -->
The hardware database has been updated for the new axial XTC timing (thanks to Nils).  Eric James is completing the final step of reprogramming the TDC's to get the correct word information on the XTC data (shouldn't impact anything we'd notice, according to Nils, but we're being thorough to avoid confusion in the future).  We've asked the operations group to please take cosmic ray runs as much as possible this weekend.  They said they should be able to start this evening.  
<!-- Author: K.Lannon, Nils Krumnack -->


<!-- Date: Fri Jan 20 21:25:50 2006 -->
I did some fiber debugging today and also made a complete map of XFT fiber problems.  It is available in the file ~cdf_xft/fibers/b0all.xml.  The fibers that show errors have a # followed by a description of the error at the end.  A list of all errors can by found in the next entry.  Most of the errors are still dead XTCs or XTCs with timing shifts, but now there are also XTCs that are shifted in the other direction.  I count an XTC as dead, if I am unable to program it.  I will try to further debug those problem on Monday, i.e. swap in spare fibers for the failing fibers and replace all dead/problematic XTCs.
<!-- Author: Nils -->


<!-- Date: Fri Jan 20 21:26:15 2006 -->
<pre>Current fiber problems: 
      <Fiber SFCrate="b0xft06" SFSlot="03"  SFInput="4"   XTCCrate="b0cot07" XTCSlot="08" XTCOutput="1" />   407a 044   3    # XTC: dead 
      <Fiber SFCrate="b0xft06" SFSlot="03"  SFInput="5"   XTCCrate="b0cot07" XTCSlot="08" XTCOutput="0" />   407b 045   3    # XTC: dead 
      <Fiber SFCrate="b0xft06" SFSlot="04"  SFInput="5"   XTCCrate="b0cot08" XTCSlot="13" XTCOutput="1" />   408a 050   3    # Fiber: losing 
      <Fiber SFCrate="b0xft06" SFSlot="09"  SFInput="5"   XTCCrate="b0cot18" XTCSlot="14" XTCOutput="1" />   618a 124   5    # XTC: shifting reverse 
      <Fiber SFCrate="b0xft06" SFSlot="09"  SFInput="10"  XTCCrate="b0cot18" XTCSlot="14" XTCOutput="0" />   618b 125   5    # XTC: shifting reverse 
      <Fiber SFCrate="b0xft06" SFSlot="09"  SFInput="11"  XTCCrate="b0cot18" XTCSlot="13" XTCOutput="1" />   618c 126   5    # Fiber: losing 
      <Fiber SFCrate="b0xft07" SFSlot="09"  SFInput="1"   XTCCrate="b0cot12" XTCSlot="10" XTCOutput="1" />   612b 078   5    # XTC: shifting reverse 
      <Fiber SFCrate="b0xft07" SFSlot="09"  SFInput="2"   XTCCrate="b0cot12" XTCSlot="10" XTCOutput="0" />   612c 079   5    # XTC: shifting reverse 
      <Fiber SFCrate="b0xft07" SFSlot="09"  SFInput="5"   XTCCrate="b0cot13" XTCSlot="14" XTCOutput="1" />   613a 082   5    # XTC: dead 
      <Fiber SFCrate="b0xft07" SFSlot="09"  SFInput="10"  XTCCrate="b0cot13" XTCSlot="14" XTCOutput="0" />   613b 083   5    # XTC: dead 
      <Fiber SFCrate="b0xft07" SFSlot="10"  SFInput="2"   XTCCrate="b0cot13" XTCSlot="12" XTCOutput="1" />   415a 086   5    # Fiber: losing 
      <Fiber SFCrate="b0xft07" SFSlot="11"  SFInput="3"   XTCCrate="b0cot14" XTCSlot="13" XTCOutput="1" />   417c 094   5    # XTC: rare scrambling 
      <Fiber SFCrate="b0xft07" SFSlot="11"  SFInput="4"   XTCCrate="b0cot14" XTCSlot="13" XTCOutput="0" />   417d 095   5    # XTC: rare scrambling 
      <Fiber SFCrate="b0xft07" SFSlot="11"  SFInput="11"  XTCCrate="b0cot14" XTCSlot="11" XTCOutput="1" />   614a 098   5    # XTC: dead 
      <Fiber SFCrate="b0xft07" SFSlot="12"  SFInput="0"   XTCCrate="b0cot14" XTCSlot="11" XTCOutput="1" />   614b 098C  5    # XTC: dead 
      <Fiber SFCrate="b0xft07" SFSlot="12"  SFInput="1"   XTCCrate="b0cot14" XTCSlot="11" XTCOutput="0" />   614c 099   5    # XTC: dead 
      <Fiber SFCrate="b0xft07" SFSlot="13"  SFInput="1"   XTCCrate="b0cot15" XTCSlot="09" XTCOutput="1" />   419a 106   5    # XTC: shifting 
      <Fiber SFCrate="b0xft07" SFSlot="13"  SFInput="2"   XTCCrate="b0cot15" XTCSlot="09" XTCOutput="0" />   419b 107   5    # XTC: shifting 
      <Fiber SFCrate="b0xft07" SFSlot="13"  SFInput="5"   XTCCrate="b0cot16" XTCSlot="10" XTCOutput="1" />   616c 110   5    # XTC: dead 
      <Fiber SFCrate="b0xft07" SFSlot="13"  SFInput="10"  XTCCrate="b0cot16" XTCSlot="10" XTCOutput="0" />   616d 111   5    # XTC: dead 
      <Fiber SFCrate="b0xft06" SFSlot="15"  SFInput="10"  XTCCrate="b0cot08" XTCSlot="06" XTCOutput="1" />   633c 228   7    # XTC: shifting 
      <Fiber SFCrate="b0xft06" SFSlot="15"  SFInput="11"  XTCCrate="b0cot08" XTCSlot="06" XTCOutput="0" />   633d 229   7    # XTC: shifting 
      <Fiber SFCrate="b0xft06" SFSlot="16"  SFInput="0"   XTCCrate="b0cot08" XTCSlot="06" XTCOutput="0" />   633e 229C  7    # XTC: shifting 
      <Fiber SFCrate="b0xft06" SFSlot="16"  SFInput="3"   XTCCrate="b0cot08" XTCSlot="04" XTCOutput="1" />   634c 232   7    # XTC: shifting 
      <Fiber SFCrate="b0xft06" SFSlot="16"  SFInput="4"   XTCCrate="b0cot08" XTCSlot="04" XTCOutput="0" />   634d 233   7    # XTC: shifting 
      <Fiber SFCrate="b0xft06" SFSlot="17"  SFInput="10"  XTCCrate="b0cot09" XTCSlot="02" XTCOutput="1" />   437a 246   7    # XTC: shifting reverse 
      <Fiber SFCrate="b0xft06" SFSlot="17"  SFInput="11"  XTCCrate="b0cot09" XTCSlot="02" XTCOutput="0" />   437b 247   7    # XTC: shifting reverse 
      <Fiber SFCrate="b0xft06" SFSlot="18"  SFInput="0"   XTCCrate="b0cot09" XTCSlot="02" XTCOutput="0" />   437c 247C  7    # XTC: shifting reverse 
      <Fiber SFCrate="b0xft06" SFSlot="18"  SFInput="9"   XTCCrate="b0cot01" XTCSlot="08" XTCOutput="1" />   619a 146   7    # XTC: dead 
      <Fiber SFCrate="b0xft06" SFSlot="18"  SFInput="10"  XTCCrate="b0cot01" XTCSlot="08" XTCOutput="0" />   619b 147   7    # XTC: dead 
      <Fiber SFCrate="b0xft07" SFSlot="16"  SFInput="1"   XTCCrate="b0cot03" XTCSlot="19" XTCOutput="1" />   625a 176   7    # XTC: missing TB 
      <Fiber SFCrate="b0xft07" SFSlot="16"  SFInput="2"   XTCCrate="b0cot03" XTCSlot="19" XTCOutput="0" />   625b 177   7    # XTC: missing TB 
      <Fiber SFCrate="b0xft07" SFSlot="17"  SFInput="0"   XTCCrate="b0cot04" XTCSlot="21" XTCOutput="1" />   626b 184C  7    # Fiber: scrambling 
      <Fiber SFCrate="b0xft07" SFSlot="17"  SFInput="4"   XTCCrate="b0cot04" XTCSlot="19" XTCOutput="1" />   627a 188   7    # XTC: dead 
      <Fiber SFCrate="b0xft07" SFSlot="17"  SFInput="5"   XTCCrate="b0cot04" XTCSlot="19" XTCOutput="0" />   627b 189   7    # XTC: dead 
      <Fiber SFCrate="b0xft07" SFSlot="18"  SFInput="5"   XTCCrate="b0cot05" XTCSlot="21" XTCOutput="1" />   629a 198   7    # XTC: rare scrambling 
      <Fiber SFCrate="b0xft07" SFSlot="18"  SFInput="8"   XTCCrate="b0cot05" XTCSlot="21" XTCOutput="0" />   629b 199   7    # XTC: rare scrambling 
      <Fiber SFCrate="b0xft07" SFSlot="18"  SFInput="9"   XTCCrate="b0cot05" XTCSlot="20" XTCOutput="1" />   629c 200   7    # XTC: rare scrambling 
      <Fiber SFCrate="b0xft07" SFSlot="18"  SFInput="10"  XTCCrate="b0cot05" XTCSlot="20" XTCOutput="0" />   629d 201   7    # Fiber: losing 
      <Fiber SFCrate="b0xft07" SFSlot="18"  SFInput="11"  XTCCrate="b0cot05" XTCSlot="19" XTCOutput="1" />   431a 202   7    # XTC: missing TB 
      <Fiber SFCrate="b0xft07" SFSlot="19"  SFInput="0"   XTCCrate="b0cot05" XTCSlot="19" XTCOutput="1" />   431b 202C  7    # XTC: missing TB 
      <Fiber SFCrate="b0xft07" SFSlot="19"  SFInput="1"   XTCCrate="b0cot05" XTCSlot="19" XTCOutput="0" />   431c 203   7    # XTC: missing TB 
      <Fiber SFCrate="b0xft07" SFSlot="19"  SFInput="8"   XTCCrate="b0cot06" XTCSlot="19" XTCOutput="1" />   433a 208   7    # XTC: shifting 
      <Fiber SFCrate="b0xft07" SFSlot="19"  SFInput="9"   XTCCrate="b0cot06" XTCSlot="19" XTCOutput="0" />   433b 209   7    # XTC: shifting 
      <Fiber SFCrate="b0xft07" SFSlot="19"  SFInput="10"  XTCCrate="b0cot06" XTCSlot="18" XTCOutput="1" />   630a 210   7    # XTC: dead 
      <Fiber SFCrate="b0xft07" SFSlot="19"  SFInput="11"  XTCCrate="b0cot06" XTCSlot="18" XTCOutput="0" />   630b 211   7    # XTC: dead 
      <Fiber SFCrate="b0xft07" SFSlot="20"  SFInput="0"   XTCCrate="b0cot06" XTCSlot="18" XTCOutput="0" />   630c 211C  7    # XTC: dead 
      <Fiber SFCrate="b0xft07" SFSlot="20"  SFInput="3"   XTCCrate="b0cot07" XTCSlot="21" XTCOutput="1" />   631a 214   7    # XTC: dead 
      <Fiber SFCrate="b0xft07" SFSlot="20"  SFInput="4"   XTCCrate="b0cot07" XTCSlot="21" XTCOutput="0" />   631b 215   7    # XTC: dead 
      <Fiber SFCrate="b0xft07" SFSlot="20"  SFInput="10"  XTCCrate="b0cot07" XTCSlot="19" XTCOutput="0" />   632b 219   7    # fiber: rare losing 
</pre>
<!-- Author: Nils -->
<!-- Comment: Mon Jan 23 14;35;17 comment by...Greg -->
<pre>The following were fixed when changing the ODLD firmware back to v3:

b0cot18 slot 14
b0cot12 slot 10
b0cot14 slot 13
b0cot15 slot  9
b0cot08 slot  6
b0cot08 slot  4
b0cot09 slot  2
b0cot06 slot 19

</pre>


<!-- Date: Mon Jan 23 22:40:47 2006 -->
<pre>Ran XFT SLAM timing tests today.  
   slam version 1201, so-called "doublestuffed". 
 
Tried new version of the SLAM firmware, with linker diagnostic  
firmware. 
Took runs 210549, 210550, 210552  with this firmware. 
 
Switched back to default configuration for linkers and slams. 
Took run 210553 to make sure everything was in place.  
 
Giving XFT linkers and XTRP back to ACE. 
 
</pre>
<!-- Author: Ben -->


<!-- Date: Mon Jan 23 23:51:46 2006 -->
<pre>      <Fiber SFCrate="b0xft06" SFSlot="04"  SFInput="5"   XTCCrate="b0cot08" XTCSlot="13" XTCOutput="1" />   408a 050   3    # XTC: losing 
      <Fiber SFCrate="b0xft07" SFSlot="05"  SFInput="4"   XTCCrate="b0cot04" XTCSlot="09" XTCOutput="1" />   604a 024   3    # XTC: rare shifting 
      <Fiber SFCrate="b0xft07" SFSlot="05"  SFInput="5"   XTCCrate="b0cot04" XTCSlot="09" XTCOutput="0" />   604b 025   3    # XTC: rare shifting 
      <Fiber SFCrate="b0xft07" SFSlot="05"  SFInput="10"  XTCCrate="b0cot04" XTCSlot="08" XTCOutput="1" />   604c 026   3    # XTC: rare off 
      <Fiber SFCrate="b0xft07" SFSlot="05"  SFInput="11"  XTCCrate="b0cot04" XTCSlot="08" XTCOutput="0" />   604d 027   3    # XTC: rare off 
      <Fiber SFCrate="b0xft07" SFSlot="06"  SFInput="5"   XTCCrate="b0cot05" XTCSlot="11" XTCOutput="1" />   605c 030   3    # XTC: rare scramble (5/10000) 
      <Fiber SFCrate="b0xft07" SFSlot="06"  SFInput="10"  XTCCrate="b0cot05" XTCSlot="11" XTCOutput="0" />   605d 031   3    # XTC: rare scramble (7/10000) 
      <Fiber SFCrate="b0xft06" SFSlot="11"  SFInput="10"  XTCCrate="b0cot19" XTCSlot="12" XTCOutput="0" />   426b 139   5    # XTC: rare scrambling (11/10000) 
      <Fiber SFCrate="b0xft06" SFSlot="11"  SFInput="11"  XTCCrate="b0cot10" XTCSlot="14" XTCOutput="1" />   610a 140   5    # XTC: rare scrambling (4/10000) 
      <Fiber SFCrate="b0xft07" SFSlot="10"  SFInput="2"   XTCCrate="b0cot13" XTCSlot="12" XTCOutput="1" />   415a 086   5    # Fiber: losing 
      <Fiber SFCrate="b0xft06" SFSlot="18"  SFInput="11"  XTCCrate="b0cot01" XTCSlot="07" XTCOutput="1" />   619c 148   7    # XTC: scrambling 
      <Fiber SFCrate="b0xft06" SFSlot="19"  SFInput="0"   XTCCrate="b0cot01" XTCSlot="07" XTCOutput="1" />   619d 148C  7    # XTC: scrambling 
      <Fiber SFCrate="b0xft06" SFSlot="19"  SFInput="1"   XTCCrate="b0cot01" XTCSlot="07" XTCOutput="0" />   619e 149   7    # XTC: scrambling 
      <Fiber SFCrate="b0xft07" SFSlot="16"  SFInput="1"   XTCCrate="b0cot03" XTCSlot="19" XTCOutput="1" />   625a 176   7    # XTC: missing TB 
      <Fiber SFCrate="b0xft07" SFSlot="16"  SFInput="2"   XTCCrate="b0cot03" XTCSlot="19" XTCOutput="0" />   625b 177   7    # XTC: missing TB 
      <Fiber SFCrate="b0xft07" SFSlot="17"  SFInput="0"   XTCCrate="b0cot04" XTCSlot="21" XTCOutput="1" />   626b 184C  7    # Fiber: scrambling 
      <Fiber SFCrate="b0xft07" SFSlot="18"  SFInput="5"   XTCCrate="b0cot05" XTCSlot="21" XTCOutput="1" />   629a 198   7    # XTC: rare scrambling 
      <Fiber SFCrate="b0xft07" SFSlot="18"  SFInput="8"   XTCCrate="b0cot05" XTCSlot="21" XTCOutput="0" />   629b 199   7    # XTC: rare scrambling 
      <Fiber SFCrate="b0xft07" SFSlot="18"  SFInput="9"   XTCCrate="b0cot05" XTCSlot="20" XTCOutput="1" />   629c 200   7    # XTC: rare scrambling 
      <Fiber SFCrate="b0xft07" SFSlot="18"  SFInput="10"  XTCCrate="b0cot05" XTCSlot="20" XTCOutput="0" />   629d 201   7    # XTC: rare scrambling 
      <Fiber SFCrate="b0xft07" SFSlot="18"  SFInput="11"  XTCCrate="b0cot05" XTCSlot="19" XTCOutput="1" />   431a 202   7    # XTC: missing TB 
      <Fiber SFCrate="b0xft07" SFSlot="19"  SFInput="0"   XTCCrate="b0cot05" XTCSlot="19" XTCOutput="1" />   431b 202C  7    # XTC: missing TB 
      <Fiber SFCrate="b0xft07" SFSlot="19"  SFInput="1"   XTCCrate="b0cot05" XTCSlot="19" XTCOutput="0" />   431c 203   7    # XTC: missing TB 
      <Fiber SFCrate="b0xft07" SFSlot="20"  SFInput="10"  XTCCrate="b0cot07" XTCSlot="19" XTCOutput="0" />   632b 219   7    # XTC: rare losing 
</pre>
<!-- Author: Nils -->


<!-- Date: Mon Jan 23 23:57:19 2006 -->
Made a lot of progress on debugging the fiber connections.  It turns out most of the problems are due to XTC/TB problems.  There are only a few fibers that are possibly broken, but those are in the upper crates and where inaccessible to me.  The finder in b0xft06/09 had to be swapped, as its input #11 was broken.  We have only 24 (out of 288) conections with errors, that seems reasonably good for the integration tests, but it doesn't get me excited.
<!-- Author: Nils -->


<!-- Date: Tue Jan 24 15:21:49 2006 -->
<pre>Moved the test fibers on finder b0xft06/21 from input 0/1 to 4/5 (6/7) to allow for remote tests of those fifos.</pre>
<!-- Author: Nils -->


<!-- Date: Wed Jan 25 19:00:35 2006 -->
<pre>OK, I did tests 1A and 1B (no beam diagnostiscs, fast passthrough and full SLAM) using only one board (to save 20+ minutes on firmware reloading).  The executive summary is that the fast nobeam diagnostics and the fast pass through seems to work.  The full SLAM design seems to be out of sync by about one CDF clock (early, I think--the XTRD always has data where the "counter" in the phi value is one higher than what was in the XFLD).  The only exception to this is chip 1, which sometimes is off by two CDF clocks.  Because we had errors with the slam design, I decided not to worry about a cosmic ray test tonight.  (I need to go write my preblessing talk.)  Details below: 
 
Along the way, I should say I learned three potentially useful things about how these runs work in Run Control: 
 
1.  There is an option to tell run control to start the run with on B0.  If you don't check this, things look really messed up.  I don't know why. 
 
2.  The frequency of L1 accepts is controlled by "Interval0" in the run control GUI.  This interval by default is set to 30 and seems to be (based on my observations) the number of CDF clock cycles between L1 accepts.  With the default setting of 30, I see the linker words march through their sequence of 6 (track, plus five numbered empties).  This is because we issue a L1 accept, wait 30 clocks, then issue another L1 accept (i.e. the 31st clock counting the first L1A as clock 0).  If I set Interval0 to 29, then I only get "7c3" out of the linkers because we issue a L1 accept, wait 29 clocks, and then issue another L1A (on the 30th clock, so the pattern has cycled 5 times and is back to "7c3" again). 
 
3.  Actually the above neat pattern is spoiled by the fact that when "Interval0" is set to 30, the pattern doesn't march along perfectly.  We seem sometime to skip some clocks.  My guess would be that the limitations of the readout rate cause us sometimes not to be ready for the next event, but I'm just guessing.  I tried increasing the interval to 3000 but this didn't seem to help. 
 
Note:  For all these runs I changed the pipeline settings on the linker in slot 4 (the one with the nobmftv2 design) as follows: 
 
Original settings (for early XTC) Input: 146    Output: 122    VME: 28 
What I used for fast linker settings (for early XTC) Input: 146    Output: 132    VME: 31 
 
Individual runs given below.  All the log files from SLAMChecker are in /home/lannon/slam_errors: 
 
Run 210696 (0x33708) 
Linker (slot 4)  nobmftv2 
Slam   (slot 5)  Forgot to change SLAM design (was 3305) 
Useless run. 
 
Run 210702 (0x3370e) 
Linker (slot 4)  nobmftv2 
Slam   (slot 5)  3405 
Errors.  Seem to be off by ~2 CDF clocks. 
 
 
Run 210704 (0x33710) 
Linker (slot 4)  nobmftv2 
Slam   (slot 5)  3405 
Checked start on B0 
Worked!  I don't know why, but I make this the default setting. 
 
Run 210706 (0x33712) 
Linker (slot 4)  nobmftv2 
Slam   (slot 5)  1201 
Checked start on B0 
Off by 1 clock.  XTRD always 1 higher than XFLD. 
 
Run 210707 (0x33713) 
Linker (slot 4)  nobmftv2 
Slam   (slot 5)  1201 
Checked start on B0 
XTRP always 1 clock higher of XFLD 
 
Run 210708 (0x33714) 
Linker (slot 4)  nobmftv2 
Slam   (slot 5)  1201 
Checked start on B0 
Interval0 29 
Only see 7c3 for XFLD.  Always see 7c4 (or 7c5 for chip 1 sometimes) in XTRD. 
 
Run 210709 (0x33715) 
Linker (slot 4)  nobmftv2 
Slam   (slot 5)  1201 
Checked start on B0 
Interval0 3000 
 
 
 
 
Brian Winer wrote: 
 
>   I have made several new test designs that we should 
>   try at B0 as soon as we can. 
> 
>   1)    /home/xft/altera/FastLinker/rbf/nobmftv2.rbf 
>        (Note this is new this morning...I found a problem 
>      with the one I sent last night.) 
> 
>     This is a no beam diagnostic for the fast linker. 
>     It sends out six different "events". One of the 
>     "events" has "tracks" in all the linkers and the 
>        other has no tracks "7C" but does have phi bits 
>     which count 0-4. 
> 
>     This design should be used when testing the 
>     full SLAM design. 
> 
>  2)    /home/xft/altera/GoodCrate/Slam60/SlamFlash/ 
>     SlamPassThruPiped_3305_3405.pof 
> 
>        This is "double stuffed" FLASH RAM file for 
>     the SLAM which has the Slow Linker and Fast 
>     Linker Pass thru designs...but *both* adjusted 
>     for the sped up XTC timing. 
> 
> 
>  Here are some tests that I think would be useful. 
> 
>     1) No beam Tests: 
> 
>        A)  Configuration: 
>          Linker:  nobmftv2.rbf 
>          SLAM:    3405 (Fastest Pass Thru) 
> 
>            System Adjustments: 
>          Linker Pipelines need to be adjusted. 
>          Two effects must be adjusted for 
>             -Fast Linker (Jason mapped these 
>              out) 
>             -Faster XTC (Nils figured these out?) 
> 
>               Test: 
>          Use Run Control to test that XFLD matches 
>          the XTRD. 
>            This will: Check the relative pipeline 
>                   depths between the XFT and 
>                   XTRP 
>            Note: I don't believe this checks whether 
>            we are aligned with the rest of the system 
>            or not. Maybe some part of RunControl 
>            checks b0 counters...I'm not sure. 
> 
>       B) Configuration: 
>          Linker:  nobmftv2.rbf 
>          SLAM:    Full SLAM design 
> 
>             System Adjustments: 
>              Same as above 
> 
>          Test: 
>          Same as above 
>          This will tell us whether the Full SLAM 
>          design is sending the data out at the 
>          same time. 
> 
>       C) Configuration: 
>          Linker: Full Fast Linker Design 
>          SLAM:   3405 (Fastest PassThru) 
> 
>          Test: 
>          With Cosmics if we get a chance...probably 
>          won't happen. 
> 
>          D) Configuration: 
>                 Linker: Full Fast Linker Design 
>                 SLAM:   Full SLAM Design 
> 
>             Test: 
>                 With Cosmics if we get a chance...probably 
>                 won't happen. 
> 
>    2) Test with Beam (e.g. end of Store) 
> 
>          A) Configuration: 
>                 Linker: Full Fast Linker Design 
>                 SLAM:   3405 (Fastest PassThru) 
> 
>             Test: 
>                 With low lum beam. 
>          *This will test the Fast Linker Design. 
>          *This will also help check the pipeline 
>           depths. 
>                 *We should verify bunch counters 
>           line up with the rest of the system. 
>          *Look at Trigger Rates. (Did any go to 0?) 
> 
> 
>          B) Configuration: 
>                 Linker: Full Fast Linker Design 
>                 SLAM:   Full SLAM Design 
> 
>             Test: 
>                 With low lum beam 
>          *Useful even without Stereo Pixels. 
>          *Should act like pass through design. 
>          *Test same features as 2A) 
> 
>          Note: If this works, we could consider 
>            leaving it in. 
> 
> 
>  So those were the thoughts I had in terms of test runs. 
>  There are probably other configurations that would be 
>  useful as well. 
</pre>
<!-- Author: K.Lannon -->


<!-- Date: Wed Jan 25 20:22:29 2006 -->
STEREOFINDER: Loaded 3-miss version of firmware<BR> 
crate b0xft06<br> 
- for boards 3-8 used second flash (bottom B) for both finders<br> 
- for boards 9-14 used second flash (bottom B) of bottom finder B<br> 
<br> 
on boards 3 and 12 can't scan JTAG<br> 
crate b0xft07<br> 
- for boards 3-8 used second flash (bottom B) for both finders<br> 
- for boards 9-14 used second flash (bottom B) of bottom finder B<br> 
on board 3  can't scan JTAG<br>
<!-- Author: ivan&apaolo -->
<!-- Comment: Thu Jan 26 10;27;19 comment by...Paolo & Ivan -->
<pre>Finished loading v3r2 10cell firmware (3-miss) on SL3 top&bottom finders, and SL5 bottom finders. Copy 2 of Flash RAMs were loaded, and will be uploaded automatically to the finder FPGAs upon a power cycle. The JTAG connection did not work on three boards: slots 3,12 crate b0xft06 and slot 3 crate b0xft07. These 3 boards were loaded using the sxft_v2 code. 
In all three cases JTAG connection error was "Unable to scan device chain. Can't scan JTAG chain"</pre>


<!-- Date: Thu Jan 26 15:59:13 2006 -->
<pre>I tried new XTC2 firmware for the capture tests on b0cot01 slot 7. The new firmware didn't work, but I did manage to get this card to work with a version of the firmware that has a different delay, so we can check of 3 more fibers off the list. We will continue trying to get a version of the firmware that works for all of the XTC2 cards.</pre>
<!-- Author: Greg -->


<!-- Date: Thu Jan 26 17:22:04 2006 -->
<pre>XFT04 crate had voltage fault. 2 of the 3 voltages were down: 
    5.2. V,  12 V.  
 
For XFT expert, these designs were not loaded: 
     slot 6  :  SL1 finder design corrupt fn1sl1_4v5.hex 
     slot 9  :  SL1/3 input design corrupt xft_inp13v3.exo 
     slot 15 :  SL4 finder design corrup fn1sl4_5v5.hex 
 
 (corrupt = the names are stored, but the download status is bad) 
 
This is the second crate (xft02 was the first) to have a power 
supply fault.    
 
Dervin plans on coming in tomorrow morning to work on this. 
 
XFT expert will plan on being here tomorrow morning to reload 
XFT finder flashrams after Dervin's work is completed.  If shot 
set up is 8 AM, then we'll plan on being here by 7 AM, since  
reprogramming could take 45 minutes if there are complications.</pre>
<!-- Author: Ben -->


<!-- Date: Fri Jan 27 09:37:29 2006 -->
<pre>There were problems loading the flashram of xft04 after the  
power supply ewas replaced.  
 
It turned out the problem was to do with the new location of the 
firmware.    
 
Originally, files were located at : 
/mnt/autofs/cdf/code-common/cdfonline/XFTbin/finder/xft_inp13v3.exo 
 
Now files are located at : 
/cdf/onln/code/cdfprod/XFTbin/finder/xft_inp13v3.exo 
 
THe tricky thing is that the original directory was visible on 
b0dap72, where xftdaq was running, but not visibile from the  
xft crate controller. 
 
One other thing that is strange is that while this new directory 
is visible from xft04 crate controller, the file isn't. 
Perhaps this is a feature: 
b0xft04-> ls "/cdf/onln/code/cdfprod/XFTbin/finder" 
   (works) 
 
b0xft04-> ls "/cdf/onln/code/cdfprod/XFTbin/finder/xft_inp13v3.exo" 
Can't open "/cdf/onln/code/cdfprod/XFTbin/finder/xft_inp13v3.exo". 
value = -1 = 0xffffffff = vmeSync + 0xff117b97 
 
But, the flashram in fact loads just fine even though you can't 
"ls" the file.  
 
 
</pre>
<!-- Author: Ben -->


<!-- Date: Fri Jan 27 14:06:01 2006 -->
<p>There is a new location for the firmware and testvectors. 
<p>Firmware: 
<p>/cdf/onln/data/cdf_xft/XFTbin 
<br> 
<p>Testvector: 
<p>/cdf/onln/data/cdf_xft/XFTtestvectors 
  
<!-- Author: Kevin Lannon -->


<!-- Date: Fri Jan 27 17:27:47 2006 -->
<pre>Loaded Scott's new v3r4 firmware on all finders in b0xft07 and b0xft06. Copy 2 of Flash RAMs were loaded (will be uploaded automatically to the FPGAs upon a power cycle). Several times the JTAG connections did not work, this was solved by rebooting the crate or restarting the PC software, or both. Still finders on slots 3 of both crates have been loaded using sxft.  
</pre>
<!-- Author: Paolo & Ivan -->


<!-- Date: Fri Jan 27 21:29:17 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030>I set up the crate tstxft2 to do XTC2->Stereo Finder capture tests.  Works error free.  Current configuration is TDC in slot 12 hooked up to Finder inputs A & B in slot 21.  If somebody needs a TDC/Finder combo in one crate, it can also be used for that.  Either using a testclock or the CDF clock.  I occasionally need the crate though and I am quite ruthless about that.</td></tr></td></table>
<!-- Author: Nils -->


<!-- Date: Fri Jan 27 21:56:16 2006 -->
<pre>I put a good TDC/XTC2 spare in slot 20 of the diagnostic crate and hooked up two of the outputs to the connectors A & B of b0xft07 slot 19 (which correspond to one of the two missing transition boards).  This is mainly for Gene so that he can run tests in run control with the newest firmware (which is only loaded for b0xft07) in run control. 
 
I ran a capture test for those connections and they look fine.  To repeat that test, type (the first line changes to capture design on the XTC and the last one changes back): 
$ XTC2FLASH b0diag01 20 /cdf/onln/home/mendi/xft/xtc2/PROM_File_ODLD_D0_KS5.hex 
$ sfcap -f b0xft07 19 0 b0diag01 20 0 
$ sfcap -f b0xft07 19 1 b0diag01 20 1 
$ sfcap -f b0xft07 19 0 b0diag01 20 0  1000 
$ sfcap -f b0xft07 19 1 b0diag01 20 1  1000 
$ XTC2FLASH b0diag01 20 /cdf/onln/home/mendi/xft/xtc2/PROM_File_6bin-D4-KS25.hex 
 
I also wrote a small utility to activate/deactivate individual inputs and show there status.  it has to be run on the crate controller.  It is located at ~nils/input.o.  It takes two or three parameters, the slot number, the input number and the desired status.  If the desired status is set to 0 (or omitted), it will just print out the current status.  Otherwise a positive value turns the input on and a negative turns it off.  The connector can be set to -1 to indicate all connectors.  The slot can be set to -1 to indicate slots 3 to 20 or to -3 (-5,-7) to indicate SL3 (SL5,SL7) slots. 
 
Examples: 
query the status of all boards: 
$ input (-1, -1) 
turn off all boards: 
$ input (-1,-1,-1) 
turn on the first input on all boards: 
$ input (-1,0,1)</pre>
<!-- Author: Nils -->


<!-- Date: Fri Jan 27 22:36:51 2006 -->
Just remembered how it works with the inputs and verified it at the teststand (this new teststand is really handy).  The signal detect bits don't go through the chip, but are routed straight through from the receivers.  Therefore I don't get the copy for the working input, but I get the signal from the otherwise ignored input to which no fiber is connected. 
<p/> 
Open question is what the firmware does with those channels.  If it decides they are invalid, or if it ignores the signal detect bit.
<!-- Author: Nils -->


<!-- Date: Mon Jan 30 11:03:08 2006 -->
We did some tests trying to turn on and off the input valid registers on the finder.  It turns out that doesn't work reliably with all finders.  b0xft07/16 seems to work though, so we hooked up the fibers from the diagnostic crates to inputs 0 & 1 of that finder.
<!-- Author: Nils, Gene -->


<!-- Date: Mon Jan 30 14:23:23 2006 -->
<pre>We just updated the XTC2 register settings in the hardware  
database so that the average timing over all XTC2's is   
consistent with the patterns we will use in the Finder.  
The next (and final) step is to calibrate the settings   
for each XTC2 card, but for that we will use the XTC2  
calibration software.  
 
Here are the 5 inner window edges that existed until now: 
92, 116, 142, 170, 197 
 
The timing we want (assuming 37 ns T0): 
92, 116, 140, 164, 188 
 
So the new register settings for the hardware database: 
4A03C83403008758100E0E0E0C0A0C0A0A29 
 
The next step is to work with Matthew and Gene to get 
card to card calibrations.</pre>
<!-- Author: Greg & Heather -->


<!-- Date: Mon Jan 30 15:42:46 2006 -->
<p>Tried to test the default fast linker design (no 3-layer tracks) plus the fast SLAM passthrough (3405) with no beam.  The tests were mostly a failure because only one fast linker design (board 9) seems to have compiled.  Any linker loaded with the design for board 9 shows all empty tracks.  However, boards loaded with other design files show strange output.  The OSU crew is looking into what went wrong with the compilation and we'll try again when we have new files. 
 
<p> On a positive note, (1) to the extent that we've tested it, the fast pass through design for board 9 seems to work just fine and (2) TrigMon doesn't choke on the v03 road files which have 0 roads listed for the 3-layer road files.
<!-- Author: K. Lannon -->


<!-- Date: Thu Feb 2 12:49:44 2006 -->
<pre>Before Shot was entered, I changed the secondary flash ram design for the linker to the fast linker design.  I accidently reprogramed wrong flash chip on b0xft03.  Reprogrammed it back to normal before shot setup was complete.  In summary, b0xft01 and b0xft05 have the fast linker design in their flash ram block 1, while b0xft03 does not.  All chips have proper design in block 0.</pre>
<!-- Author: Jonathan Efron -->


<!-- Date: Thu Feb 2 18:40:29 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-407&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-407' width='300'></a></center>
<!-- Author: Jonathan Efron -->
<!-- Comment: Thu Feb  2 18;47;26 comment by...Jonathan Efron -->
<pre> Today I was paged for the XFT around two o'clock and found the
Finder to Linker Connection canvas shows a point were every event is marked bad (above plot).  After trying to just reconnectseveral of the cables, the error was still there.
 
We then ran TrigMon over the dstream of the event.   We found that the offending cell gave the following message, over and over for different cells (0-3).
 
 
    211188/46 b0xft05 18 INPUT FORMATTER 3 RAM 1 WORD 1 FINDER  CHIP 4A'     CELL 0 0101 0000 0000 F
    211188/46 b0xft05 18 INPUT FORMATTER 3 RAM 1 WORD 1 FINDER CHIP 4A'    CELL 0 0101 1101 1111 L
    211188/46 b0xft05 18 INPUT FORMATTER 3 RAM 1 WORD 1 FINDER CHIP 4A'    CELL 0      XX X XXXX D
 
 
 Based off old diagrams of the linker board and the software that produced this error, we figured that problem is found in the b0xft05 linker slot 18, chip 4.  Is this correct interpretation of this output?
Nils informed us that the two finders that connect to this chip are b0xft00 slot 13 and b0xft04 slot20.  We are unsure whether problem is caused by the linker, the finder, or the cable.  Also of note, the TrigMon we ran over gave us a wider field of finder to linker errors (below plot?).  This was a concern for Nils.  Looking at the log file, it seems that these errors occur simultaneously during certain events.
 
Tomorrow, we will have an one hour access at about 7:30.  During that  time, Kevin and I are going to switch connections to pinpoint the problem.  Hopefully, this will not be to painful.</pre>


<!-- Date: Fri Feb 3 09:37:50 2006 -->
<pre>I have changed the register settings for the XTC2 cards: 
 
1. I have widened the first time bin by about 20 ns, changing 
   only the beginning of the window. Looking at the efficiency      
   plots it looked like it was starting at ~50 ns, and this is      
   close to where good data begins. In doing this, I think the   
   output of the data has also been shifted back by 20 ns. I also  
   changed the setting for the width of the inner four windows 
   so that they all have the same setting (nominally 24 ns), 
   this will make calibrations easier. 
 
2. Since we have been running with the sparsified readout 
   and it looks ok, Bill suggested that we can now readout 
   the xtc2 cards for every ROL=7 event, instead of one in 
   every 4 events. So I changed this as well. I also made 
   an sql script to quickly change this back in case this 
   slows down the readout. It can be found here: 
 
/cdf/onln/home/cdf_xft/xtc2/sql/xtc_fast.sql 
 
For instructions of how to run it look at sql_instructions.txt 
in the same directory. 
</pre>
<!-- Author: Greg -->


<!-- Date: Fri Feb 3 12:01:10 2006 -->
<h3> Linker and SLAM Work </h3> 
<p>There was a high error rate for finder to linker pixel matching in TrigMon noticed last store.  We were able to track this down to an unseated cable in the linker crate.  If you encounter finder to linker pixel discrepancies where all the pixels at the linker end are always set, check for the cables into the linker. 
 
<p>I'm also using this opportunity for linker and SLAM firmware tests.  In two separate no beam test runs with the fast linker and fast SLAM passthrough, I see about 0.4% of the events having an error in the b0 marker bit between the XFLD and the XTRD.  These errors always happen in xft05, slot 6, linker chips 6, 7, 8, 9, 10, and 11.  It looks like xft05, slot 6 disagrees in bunch counter and b0 marker from the other linker boards, so I guess this is a linker board and not a slam issue. 
 
<p>Finally, I tried a couple tests with a partial version of the full SLAM algorithm.  I saw some errors (and I'll need to talk to  the experts for more opinions) but things looked promising.  
<!-- Author: K. Lannon -->


<!-- Date: Mon Feb 6 09:45:32 2006 -->
<pre>We went through the comparison and efficiency plots 
(from XTCMon in Trigmon) for each crate, and we found 5 cards that are behaving a bit funny: 
 
3 cards that have an absolute timing shift more than the rest, and have a significant impact on efficiency (these were 
"fixable" through calibrations): 
cot03, slot 9: -3 ns 
cot11, slot 12: +11 ns 
cot17, slot 13: -6 ns 
 
2 cards that inexplicably have low efficiency at low times: 
b0cot07, slot 18 
b0cot03, slots 19 (maybe 18 too) 
 
We would like to start the shutdown by pulling these cards 
and make sure we can flag them with our testing, before 
we start swapping all of the cards. 
 
We have now completed a rough round of calibrations 
that will be good enough for now, until we get official 
calibrations from Gene's and Matt's code. But the data 
is probably good enough to have simulation run on it, and 
check what the real efficiency and fake rates are. The 
XFTsim people are working on being able to read in the 
XTCD hits into the simulation.</pre>
<!-- Author: Greg & Heather -->


<!-- Date: Mon Feb 6 18:20:11 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>In a joint effort Peter and I consolidated our spares.  All working XFT VME spares (except for transition boards) are now sitting in the lowest crate of VME spare rack 3 (on the third floor).  The transition boards are in marked boxes on top of VME spare rack 2 & 3 (the ansley boards don't fit and for the upgrade boards there is not enough room).  The XTC spares stay in the XFT lab which is assumed to be there permanent position.  The rx and tx spares have gone missing.  All boards marked in someway as bad are now in tstxft1 and all boards in tstxft1 (except for CPU and tracer) are assumed to have problems of some sort. 
 
What follows is a count of all spares I am aware of.  Not included are spares used in teststands and not fully functional spares: 
 
Current count (VME): 
1/3 Finder: 0 
2/4 Finder: 0 
Stereo Finder: 2 
Linker: 3 
SLAM: 1 
 
Current count (transition): 
COT Ansley (2 output): 6 
COT Ansley (4 output): 5 
COT Fiber (2 output): 2 
COT Fiber (4 output): 0 
COT Fiber (4 output, terminated): 1 
1/3 Finder: 7 
2/4 Finder: 3 
Stereo Finder (no TX mezzanine): 10 
Stereo Finder (TX mezzanine installed): 6 
 
Current count (XTC): 
XTC1 (class "works"): 4 
XTC1 (class "Ok"): 9 
XTC1 (class "good"): 3 
XTC2 (class "last resort"): 5 
XTC2 (class "need testing"): 3 
XTC2 (class "not marked"): 15 
 
 
What is a little worrysome is that we have no working axial finder spares available and just as many spare unterminated fiber transition boards as we will need to complete fiber installation (and that will actually require some swapping around to get the 4 output boards to where we need them). 
</pre></td></tr></td></table>
<!-- Author: Nils, Peter -->
<!-- Comment: Mon Feb  6 23;12;33 comment by...Nils -->
I managed to revive one 1/3 and one 2/4 finder board, which had programming problems before.  I hope that will last us until the shutdown.  They are in the spares cabinet now.<p/>
Also Greg promised to bring up some more transition boards so that we have at least five spares.


<!-- Date: Tue Feb 7 08:34:42 2006 -->
Forget to make an entry about this yesterday (I only put a short notice in the main e-log).  We got a lot of errors in SL2 (1 error per event) and a drop in efficiency in the corresponding section.  A look at the simulation output showed that the boards in b0xft04 slot 6 & 7 were both gaining and losing bits.  We swapped in the two remaining spares we had, which fixed the problem.
<!-- Author: Nils, Jonathan, Kevin -->


<!-- Date: Tue Feb 7 13:00:29 2006 -->
<pre>Linker spare situation 
 
before 2/7/06: 
spares :  13,20,26  (where 26 has problem programming second flashram) 
 
i just swapped in 13, and took out 23 from crate 5, slot 6. 
 
 
 </pre>
<!-- Author: Ben -->


<!-- Date: Tue Feb 7 15:13:47 2006 -->
<pre>successfully tested fast linker + fast slam 
 
a previous problem in slot 6 xft05 turned out to be a hardware 
 problem with linker board ID #23.  (at least, it went away  
after swapping). 
 
XFT group is ready to put fast linker + fast slam in the system. 
We can program flashram to support 3L+4L tracks and 4L tracks,  
and switch between them depending on whether it is  
physics table 3 or physics table 4. 
 
Also, we've switched the naming convention of the new linker  
designs to avoid a problem with TrigSim (XFTSim) which looks 
for the string "v02" in it to run the proper firmware.  Our  
fast linker firmware will be called "v02f" with "f" for fast. 
 
  
 
</pre>
<!-- Author: Ben -->


<!-- Date: Tue Feb 7 15:14:28 2006 -->
<pre>Switched the naming convention of the new linker  
designs to avoid a problem with TrigSim (XFTSim) which looks 
for the string "v02" in it to run the proper firmware.  Our  
fast linker firmware will be called "v02f" with "f" for fast. 
 
</pre>
<!-- Author: Ben -->


<!-- Date: Tue Feb 7 15:43:19 2006 -->
<pre>======================================================== 
Summary of designs currently loaded in Linkers & Slams: 
======================================================== 
 
Linkers ( for crate xft01, slot 4) 
flashram 0 -  b11_r_0p2_v02.rbf  - slow linker - physics table 3X 
flashram 1 -  b11_r_0p2_v02f.rbf - fast linker - physics table 4X 
 
Slams 
flashram 0 - 3305  with slow linker - physics table 3X 
flashram 1 - 3405  with fast linker - physics table 4X 
 
 
To switch between physics tables 3X and 4X,  
 
1) changing linkers is just an sql command : 
cd ~xft/oracle 
sqlplus bjk@cdfonprd 
    @fastLinker_0p2_v02f.sql; 
        or  
    @slowLinker_0p2_v02.sql; 
 
 
2) changing slams is done by an xftdaq reprogam from flashrams : 
cd ~xft/xftdaq 
cp system.cfg.slam system.cfg 
xftdaq 
  open connection 
  write all 
  boards -> slamboards 
  select all boards 
    
   reprogram from page 0  (for physics 3.X, 3305) 
          or 
   reprogram from page 1  (for physics 4.X, 3405) 
 
---------- 
 
Default (page 0) is physics table 3.X  
   - both slams and linkers will load these designs 
</pre>
<!-- Author: Ben -->


<!-- Date: Wed Feb 8 19:20:51 2006 -->
<pre>XFT Test runs tonight: 
 
before 211400 - running slow linker designs 
211400 <= fast linker <= 211403 
 
211400 - has old pipleline lengths - bunch counter problems 
211401 - has new pipeline lengths - no bunch counter problems  
211402 - " - more statistics 
211403 - has XSLD banks readout every event for xft01, slot 5 
         files copied to OSU:  
              /grbdata3/users/CDF/run2/look_area/XSLD 
 
after 211403 - running slow linker designs 
</pre>
<!-- Author: Ben, Kevin, Jonathan -->
<!-- Comment: Wed Feb  8 19;22;39 comment by...Ben -->
<pre>For runs >= 211403 :

Note, all slams except b0xft01, slot 5 :
flashram 0 - 3305  with slow linker - physics table 3X 
flashram 1 - 3405  with fast linker - physics table 4X 

b0xft01, slot 5:
flashram 0 - 3307  with slow linker - physics table 3X 
flashram 1 - 3407  with fast linker - physics table 4X 
</pre>


<!-- Date: Fri Feb 10 21:34:55 2006 -->
<pre>I ran a capture test today on the west half of the COT to investigate the problems in SL6.  I found two cables that are suspicious in that they are occasionally late by one CDF clock.  It is a little strange as it is a difference in error rate whether I read out all finders or just one cable.  I'm still pondering about what to do, but it might be worthwhile to swap the corresponding XTCs. 
 
The complete results: 
 
b0cot00 (CONWT-3):  
 
b0cot01 (CONWT-2):  
25507/b0cot01/16/A/b0xft02/05/02/E[108/100]: 0x0002 high 
->b0xft02/04/06[99/100]: 0x0020 high 
 
b0cot02 (CONWT-1): watch out for stereo boards  
25527/b0cot02/08/A/b0xft02/07/11/C[10/1]: 0x20000 low 
25528/b0cot02/08/B/b0xft02/07/12/D[10/1]: 0x20000 low 
->b0xft02/08/08[10/1]: 0x20000 low 
25521/b0cot02/11/A/b0xft02/06/09/A[60/100]: 0x0020 high  
->b0xft02/05/13[0/100] 
 
b0cot03 (COSWT-1):  
25533/b0cot03/08/B/b0xft02/08/04/F[13/10000]: 0x0200 high  
->b0xft02/09/00[0/10000] 
 
b0cot04 (COSWT-2):  
25547/b0cot04/06/B/b0xft02/11/04/F[168/1000]: 0x0004 high  
 
b0cot05 (COSWT-3):  
25636/b0cot05/08/B/b0xft04/05/04/F[80/10000]: 0x4000 high  
->b0xft04/06/00[317/10000]: 0x4000 high  
25640/b0cot05/18/D/b0xft04/04/10/B[47/1000]: 0x0008 high  
 
b0cot06 (COSWB-1): 
25669/b0cot06/12/B/b0xft04/09/10/B[77/1000]: B0 sometimes 1 CDF clock late  
25665/b0cot06/14/B/b0xft04/08/10/B[820/1000]: B0 sometimes 1 CDF clock late  
 
b0cot07 (COSWB-2): 
25682/b0cot07/11/A/b0xft04/11/11/C[92/10000]: 0x0100 high  
25674/b0cot07/15/A/b0xft04/09/11/C[77/1000]: 0x4000 high 
 
b0cot08 (CONWB-2):  
 
b0cot09 (CONWB-1):  
 
</pre>
<!-- Author: Nils -->


<!-- Date: Wed Feb 15 12:00:11 2006 -->
<pre>Latest list of fiber problems: 
      <Fiber SFCrate="b0xft06" SFSlot="04"  SFInput="5"   XTCCrate="b0cot08" XTCSlot="13" XTCOutput="1" />   408a 050   3    # XTC: losing 
      <Fiber SFCrate="b0xft06" SFSlot="04"  SFInput="7"   XTCCrate="b0cot08" XTCSlot="13" XTCOutput="1" />   408a 050   3    # XTC: losing 
      <Fiber SFCrate="b0xft06" SFSlot="04"  SFInput="11"  XTCCrate="b0cot09" XTCSlot="14" XTCOutput="1" />   609a 052   3    # XTC: dead 
      <Fiber SFCrate="b0xft06" SFSlot="05"  SFInput="0"   XTCCrate="b0cot09" XTCSlot="14" XTCOutput="1" />   609b 052C  3    # XTC: dead 
      <Fiber SFCrate="b0xft06" SFSlot="05"  SFInput="1"   XTCCrate="b0cot09" XTCSlot="14" XTCOutput="0" />   609c 053   3    # XTC: dead 
      <Fiber SFCrate="b0xft06" SFSlot="05"  SFInput="5"   XTCCrate="b0cot09" XTCSlot="13" XTCOutput="0" />   609e 055   3    # losing 
      <Fiber SFCrate="b0xft07" SFSlot="10"  SFInput="2"   XTCCrate="b0cot13" XTCSlot="12" XTCOutput="1" />   415a 086   5    # Fiber: losing 
      <Fiber SFCrate="b0xft07" SFSlot="16"  SFInput="0"   XTCCrate="b0cot03" XTCSlot="20" XTCOutput="0" />   624e 175C  7    # disconnected 
      <Fiber SFCrate="b0xft07" SFSlot="16"  SFInput="1"   XTCCrate="b0cot03" XTCSlot="19" XTCOutput="1" />   625a 176   7    # XTC: missing TB 
      <Fiber SFCrate="b0xft07" SFSlot="16"  SFInput="2"   XTCCrate="b0cot03" XTCSlot="19" XTCOutput="0" />   625b 177   7    # XTC: missing TB 
      <Fiber SFCrate="b0xft07" SFSlot="17"  SFInput="0"   XTCCrate="b0cot04" XTCSlot="21" XTCOutput="1" />   626b 184C  7    # Fiber: scrambling 
      <Fiber SFCrate="b0xft07" SFSlot="18"  SFInput="5"   XTCCrate="b0cot05" XTCSlot="21" XTCOutput="1" />   629a 198   7    # rare data & control scrambling (306/1000) 
      <Fiber SFCrate="b0xft07" SFSlot="18"  SFInput="7"   XTCCrate="b0cot05" XTCSlot="21" XTCOutput="1" />   629a 198   7    # rare data & control scrambling (340/1000) 
      <Fiber SFCrate="b0xft07" SFSlot="18"  SFInput="8"   XTCCrate="b0cot05" XTCSlot="21" XTCOutput="0" />   629b 199   7    # XTC: rare data & control scrambling (32/10000) 
      <Fiber SFCrate="b0xft07" SFSlot="18"  SFInput="9"   XTCCrate="b0cot05" XTCSlot="20" XTCOutput="1" />   629c 200   7    # XTC: rare data & control scrambling (171/1000) 
      <Fiber SFCrate="b0xft07" SFSlot="18"  SFInput="10"  XTCCrate="b0cot05" XTCSlot="20" XTCOutput="0" />   629d 201   7    # losing 
      <Fiber SFCrate="b0xft07" SFSlot="18"  SFInput="11"  XTCCrate="b0cot05" XTCSlot="19" XTCOutput="1" />   431a 202   7    # XTC: missing TB 
      <Fiber SFCrate="b0xft07" SFSlot="19"  SFInput="0"   XTCCrate="b0cot05" XTCSlot="19" XTCOutput="1" />   431b 202C  7    # XTC: missing TB 
      <Fiber SFCrate="b0xft07" SFSlot="19"  SFInput="1"   XTCCrate="b0cot05" XTCSlot="19" XTCOutput="0" />   431c 203   7    # XTC: missing TB 
      <Fiber SFCrate="b0xft07" SFSlot="20"  SFInput="10"  XTCCrate="b0cot07" XTCSlot="19" XTCOutput="0" />   632b 219   7    # XTC: losing 
</pre>
<!-- Author: Nils -->


<!-- Date: Fri Feb 17 16:54:27 2006 -->
<pre>The current (2/17) design of the SLAM board has on page 0 the fast linker pass through and on page 1 the appropiate even and odd full slam designs.  There are four scripts for the current state of the slam boards.  Currently, the only way to switch designs is by using xftdaq 
 
I have made four differant sql scripts to deal with the hardware db cards.  They are located in ~cdf_xft/oracle. 
 
fullSlam.sql: 
 
   This script switches the slamflash ram version to the full odd/even design as well as setting the optimal slam pipe line length. 
 
fastSlamPipeline.sql: 
 
Similar script, except that it does the above for the fast Linker passthrough mode. 
 
offlineCard.sql: 
 
Turns the ONLINEFLAG variable to off for all SLAM cards. 
 
onlineCard.sql. 
 
Turns the ONLINEFLAG variable to on for all SLAM cards.  THIS TAKES A FEW MINUTES. 
</pre>
<!-- Author: Jonathan Efron -->


<!-- Date: Sun Feb 19 17:09:59 2006 -->
We took two test runs with only muon triggers and different 
COT thresholds: 
<br><br> 
COT stereo thresholds set to 205mV: <br> 
<a href="http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER=211879">211879</a> x33BA7 TEST_XFT_MUON [4,784,600] 193,182 events	 
<br><br> 
COT stereo thresholds set to 205mV and dE/dx disabled on superlayers 1 and 2: 
<br> 
<a href="http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER=211880"> 
211880</a> x33BA8 TEST_XFT_MUON [4,784,600] 158,330 events 
<br><br>
<!-- Author: Greg Veramendi -->
<!-- Comment: Thu Mar  2 12;21;39 comment by...Greg -->
<pre>I created SAM dataset definitions for these runs:
xft_run211879
xft_run211880
</pre>
<!-- Date: Tue Feb 21 15:17:53 2006 -->
<pre>We changed the design for linker crate xft01 slot 4 page1 to 
b11_nobmftv3.rbf.  A new diagnostic design 
 
We changed the design for slam crate xft01 slot 5 to the improved passthrough mode.  It only has information in page0.  The new design should reconcile the differance between columbus and b0.  the linker pipe line length is now 0x80.  The flashram version is the same</pre>
<!-- Author: Jonathan Efron and Kevin Lannon -->
<!-- Comment: Wed Feb 22 11;54;35 comment by...Jonathan Efron -->
<pre>I changed the design on all linkers page1 design to include the appropiate version3 design.  The differance between this design and version2 is that the fake tracks should have all the fake words be insync.  

The appropiate sql script was also made.  It is found in ~cdf_xft/oracle/fastLinker_nobmftv3.sql</pre>


<!-- Date: Fri Feb 24 16:08:31 2006 -->
<pre>Loaded Scott's new firmware v5r1 on stereo finders on crates b0xft07 and b0xft06. 
Boards on slots 15 & 16 of b0xft07 are missing (not loaded). 
Extra board on slot 21 of b0xft06 loaded with 18+18. 
</pre>
<!-- Author: Paolo Azzurri -->



<!-- Date: Fri Mar 3 17:38:25 2006 -->
<pre>SLAM board in b0xft05 slot 19 had timing issues. Before the timing dip switches were 
 
00000100 00001000 
 
The new setting is now 
 
00000110 00001000 
 
The previous error was corrected.</pre>
<!-- Author: Jonathan Efron -->


<!-- Date: Mon Mar 6 19:54:37 2006 -->
<pre>I took the last remaining stereo finder from the spare cabinet and put it into tstxft2 in a vain effort to revive my teststand.  However I am still experiencing some weird problems that seem XTC related.</pre>
<!-- Author: Nils -->


<!-- Date: Fri Mar 10 17:16:15 2006 -->
Fixed the tstxft2 teststand.  After swapping boards around for a while it just started working again.  From now on, I can again debug capture test problems in that crate.  
<!-- Author: Nils -->


<!-- Date: Sun Mar 12 15:14:15 2006 -->
<pre>I just updated the official version of xftmod v2_1 with the latest               
changes in CVS.                                                                  
                                                                                 
There are several updates.  The main ones are:                                    
 - server-side updates for the new XTC2 combined 6-bin/ODLD design                  
 - server-side updates for stereofinderboard flashram programming                
 - java updates for finderboard, stereofinderboard, and SLAM programming         
                                                                                 
The server-side code will be picked up when the front-end crates                 
are rebooted next time. 
 
All of the XFT crates (b0xft00-07) plus tstxft1 and tstxft2 are                  
currently configured to use xftmod v2_1.                                         
</pre>
<!-- Author: Jay Dittmann -->


<!-- Date: Tue Mar 14 14:22:04 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030>I found some more finders with bad inputs.  I replaced them, but I had to use the finder in b0xft06 slot 21 for that as well.  That slot is empty now.</td></tr></td></table>
<!-- Author: Nils -->


<!-- Date: Wed Mar 15 08:14:50 2006 -->
<pre>List of known fiber problems: 
      <Fiber SFCrate="b0xft06" SFSlot="04"  SFInput="5"   XTCCrate="b0cot08" XTCSlot="13" XTCOutput="1" />   408a 050   3    # Jumper: losing 
      <Fiber SFCrate="b0xft06" SFSlot="04"  SFInput="7"   XTCCrate="b0cot08" XTCSlot="13" XTCOutput="1" />   408a 050   3    # Jumper: losing 
      <Fiber SFCrate="b0xft07" SFSlot="20"  SFInput="10"  XTCCrate="b0cot07" XTCSlot="19" XTCOutput="0" />   632b 219   7    # backplane: losing 
 
Notacibly shorter, isn't it?  Dervin will replace the fiber which is giving the problem in b0cot08 (one of the short fibers on the first floor) and I will further investigate the problem in b0cot07 sometime later this week.  I should point out here that none of the problems we encountered yesterday was due to the long fibers running from the collision hall to the first floor.  So these don't seem to be dying on us.</pre>
<!-- Author: Nils, Heather -->


<!-- Date: Wed Mar 15 14:49:34 2006 -->
<pre>If anyone is looking for (/trying to use) the TDC/xtc2 + transition card that was in slot 19 of the tdc diagnostic crate they are all now in slot 16 of tstmuon1. 
 
</pre>
<!-- Author: Gene -->
<!-- Comment: Wed Mar 15 16;36;34 comment by...Gene -->
<pre>change of plan, the TDC/xtc2 and transition card are back in diag01 slot 19 as before.</pre>


<!-- Date: Thu Apr 6 14:29:06 2006 -->
<pre>I've loaded all stereo finders in b0xft06 and b0xft07 with Scott's new firmware v5r5. 
Finder chip flashrams copy 2 are loaded with the latest v5r5 files. 
Finder chip flashrams copy 1 are loaded with the previous v5r1 files. 
Copy 2 files (v5r5) are now downloaded to the finder fpga's. 
L2 pulsar flashrams are loaded with the latest v5r5 files and they are downloaded to the L2 pulsar fpga's.  
The finders have been loaded via vme, the L2 pulsars through the jtag chain.</pre>
<!-- Author: Paolo Azzurri -->


<!-- Date: Thu May 11 11:06:46 2006 -->
<pre>I found some time to run axial capture tests this week.  There are a couple of new problems that seem worth investigating. 
 
b0cot00 (CONWT-3):   
 
b0cot01 (CONWT-2):   
25512/b0cot01/11/B/b0xft02/04/12/D[none] 
->b0xft02/05/08[42/10000]: 0x0080 high 
25507/b0cot01/16/A/b0xft02/05/02/E[598/10000]: 0x810a high  
->b0xft02/04/06[31/10000]: 0x0020 high  
 
b0cot02 (CONWT-1): watch out for stereo boards   
25527/b0cot02/08/A/b0xft02/07/11/C[10/1]: 0x20000 low  
25528/b0cot02/08/B/b0xft02/07/12/D[10/1]: 0x20000 low  
->b0xft02/08/08[10/1]: 0x20000 low  
25521/b0cot02/11/A/b0xft02/06/09/A[47/100]: 0x0048 high 
->b0xft02/05/13[0/100] 
 
b0cot03 (COSWT-1):   
25533/b0cot03/08/B/b0xft02/08/04/F[370/10000]: 0x0200 high   
->b0xft02/09/00[90/10000]: 0x0200 high 
 
b0cot04 (COSWT-2): 
25547/b0cot04/06/B/b0xft02/11/04/F[349/1000]: 0x0004 high   
 
b0cot05 (COSWT-3):   
25636/b0cot05/08/B/b0xft04/05/04/F[3/100]: 0x4000 high   
->b0xft04/06/00[54/100]: 0x4000 high   
25640/b0cot05/18/D/b0xft04/04/10/B[253/100]: 0x000c high   
 
b0cot06 (COSWB-1):  
 
b0cot07 (COSWB-2):  
25674/b0cot07/15/A/b0xft04/09/11/C[14/10000]: 0x4000 high  
 
b0cot08 (CONWB-2):   
25630/b0cot08/12/A/b0xft04/12/09/A[none] 
->b0xft04/11/13[640/1]: stuck to 0x31377 
25629/b0cot08/17/A/b0xft04/12/02/E[none] 
->b0xft04/11/06[31/10000]: 0x0100 high 
 
b0cot09 (CONWB-1):   
 
b0cot10 (CONET-3):  
25489/b0cot10/06/A/b0xft00/20/07/B[38/100]: slips  
25482/b0cot10/10/B/b0xft00/18/10/E[60/100]: 0x2000 high  
->b0xft00/19/05[0/1000]  
25479/b0cot10/11/A/b0xft00/18/07/B[1299/10000]: 0x2880 high  
25497/b0cot10/16/A/b0xft00/19/03/H[328/100]: 0x0001 high  
->b0xft00/20/00[0/100]  
25493/b0cot10/18/A/b0xft00/18/02/G[375/1000]: 0x0080 high  
25494/b0cot10/18/B/b0xft00/18/03/H[40/1000]: 0x0200 high  
->b0xft00/19/00/[41/1000]: 0x4200 high  
 
b0cot11 (CONET-2):  
25502/b0cot11/16/A/b0xft00/21/01/F[none]  
->b0xft00/20/04[122/100]: 0x0020 high  
 
b0cot12 (CONET-1):  
25580/b0cot12/06/A/b0xft02/15/10/E[183/100]: 0x002c high  
->b0xft02/16/05[none] 
 
b0cot13 (COSET-1):  
25596/b0cot13/09/B/b0xft02/17/02/G[70/1000]: 0x8000 high  
 
b0cot14 (COSET-2):  
 
b0cot15 (COSET-3):  
25698/b0cot15/05/B/b0xft04/15/02/G[75/100]: 0x2002 high  
25710/b0cot15/13/B/b0xft04/15/07/B[16/100]: slips  
 
b0cot16 (COSEB-1):  
25730/b0cot16/15/A/b0xft04/17/06/A[6/100]: 0x20000 low  
->b0xft04/16/11[5/100]: 0x20000 low  
25731/b0cot16/15/B/b0xft04/17/07/B[26/100]: 0x20000 low, 0x0004 high  
 
b0cot17 (COSEB-2):  
 
b0cot18 (CONEB-2):  
 
b0cot19 (CONEB-1):  
25456/b0cot19/10/A/b0xft00/15/10/E[53/10000]: 0x0100 high  
->b0xft00/16/05[none] 
25474/b0cot19/15/A/b0xft00/17/03/H[194/1000]: 0x2060 high  
->b0xft00/18/00[126/1000]: 0x2060 high  
 
 
 
25416/b0cot00/14/A/b0xft00/11/02[48/10000*]: 0x0001 high 
->b0xft00/10/06[100/10000*]: 0x0001 high 
25506/b0cot01/17/D/b0xft02/04/04/F[11/10000*]: 0x0040 high 
->b0xft02/05/00[none] 
25669/b0cot06/12/B/b0xft04/09/10/B[99/10000*]: 0x0004 high 
25682/b0cot07/11/A/b0xft04/11/11/C[326/10000*]: 0x5008 high 
25388/b0cot08/10/B/b0xft00/05/10[11/10000*]: B0 sometimes 1 CDF clock late 
25564/b0cot11/06/A/b0xft02/13/10/E[60/1000*]: 0x4000 high  
->b0xft02/14/05[60/1000*]: 0x4000 high  
25565/b0cot11/06/B/b0xft02/14/06/A[none] 
->b0xft02/13/11[60/1000*]: 0x0040 high  
25562/b0cot11/07/A/b0xft02/13/08/C[109/1000*]: 0x0060 high  
25563/b0cot11/07/B/b0xft02/13/09/D[63/1000*]: 0x0008 high  
25588/b0cot12/15/A/b0xft02/15/03/H[155/1000*]: 0x2440 high  
->b0xft02/16/00[80/1000*]: 0x2440 high  
25595/b0cot13/09/A/b0xft02/17/01/F[70/100*]: 0x2000 high  
->b0xft02/16/04[none]  
25694/b0cot15/07/B/b0xft04/14/01/F[none]  
->b0xft04/13/04[20/100*]: 0x0040 high  
25736/b0cot16/12/A/b0xft04/18/07/B[159/10000*]: 0x0900 high  
25740/b0cot17/07/A/b0xft04/19/01/F[57/10000*]: 0x0480 high  
->b0xft04/18/04[none] 
25435/b0cot18/09/D/b0xft00/13/07/B[202/10000*]: 0x0208 high  
25449/b0cot18/17/B/b0xft00/14/01/F[125/1000*]: 0x0002 high 
->b0xft00/13/04[125/1000*]: 0x0042 high 
25469/b0cot19/18/B/b0xft00/16/01/F[24/1000*]: 0x2000 high  
->b0xft00/15/04[10/1000*]: 0x0001 high 
</pre>
<!-- Author: Nils -->


<!-- Date: Thu May 18 18:47:22 2006 -->
<pre>Ran a capture test on the stereo finders.  After resetting the XTC2s I found no more errors.</pre>
<!-- Author: Nils -->


<!-- Date: Sun May 21 17:39:21 2006 -->
<pre>I played around a little and made three little scripts to load up the complete detector with an event.  All the scripts are located in ~cdf_xft/load_event. 
 
The first script is called make_files and it creates the pattern files for all the XTCs from one master file.  The master file has one line for each hit in the format "<sl> <cell> <wire> <time>".  If your master file is callled input you call it like: 
$ ./make_files input 
 
The second script is called set_patterns and it takes all the individual pattern files and loads them into the corresponding XTCs.  You call it like: 
$ ./set_patterns 
 
The third script is called add mask and contains all the stereo masks and allows you to add the hits corresponding to one of the masks.  Let's say your master file is called input and you want to use the mask with the index 42 in cell 100 of both SL 3 and 7: 
$ ./add_mask input 3 100 42 
$ ./add_mask input 7 100 42 
 
This script also lets you specify to omit individual hits, just attach their wire number: 
$ ./add_mask input 5 100 42 3 5 7 11 
</pre>
<!-- Author: nils -->


<!-- Date: Thu May 25 14:05:04 2006 -->
<pre>We are running a test where we load patterns into  
XTC2's and then run them through the finders and SLAM.  
 
The files for this are stored in b0doorway.fnal.gov:~cdf_xft/load_12events 
 
A typical command for one of the cot slots was : 
cd ~cdf_xft/load_12events 
loadxtc b0cot01 14 FirstEventOn.sf FirstEventOn.sf 
 
 
One file has 12 events of data where only the first event 
has data.  The other file has 12 events of data where only  
the second event has data.  12 events is 1/3 of a turn.  
 
 
run 216787 (0x34ed3) :  we have loaded XTC2 with  		   
                        FirstEventOn.sf on all the fibers. 
                        This means that the first event of  
                        each 12 events will have all ffff's. 
                        Note b0cot12 is not responding. 
                        (source load.commands.evt1) 
                          
			The results of comparing Stereo finder 
                        to slam are at 
                     ~cdf_xft/load_12events/results/fffbc0.log            
 
run 216788 (0x34ed4) :  we have loaded XTC2 with  
                        SecondEventOn.sf.  All fibers should  
                        be sending data on every 2nd event out  
			of 12. 
                        cot12 is still not on. 
                        (source load.commands.evt2) 
 
			The results of comparing Stereo finder 
                        to slam are at 
                     ~cdf_xft/load_12events/results/fffbc3.log            
 
run 216797 (0x34edd) :  same as above. but now cot12 is on. 
                       so all fibers should be sending data on  
                       second event of each third of a turn. 
</pre>
<!-- Author: Ben & Jonathan -->


<!-- Date: Wed May 31 09:41:39 2006 -->
We used the last two days to test the Stereo finders with test patterns.  For that we loaded the XTCs up with a series of events, of which one event is on and the other events are of.  The findings are that for all of the Finders this seems works, in the sense that if all input hits are on, all output pixels are on as well.  However Finder 112 doesn't see any input hits and Finders 108, 109, 111, 117 have problems with their BCs.  Indepently of this Scott verified that we should expect that the Finder is sending out the same pixels that are reported in the L2 buffers.<p/> 
 
We starting cosmics running with COT high voltage on last night.  For that we are using our special cosmics trigger table that has an extra paralell trigger path, which is a subset of an existing path, but requires SLAM confirmation.  Currently both of them are running at the same rate.  We still have to validate, whether that is due to the trigger table logic, or because the SLAM confirms every track it finds.<p/> 
 
The immediate plans for the Finder include: 
<ul> 
<li>investigate why finder 112 doesn't see hits.</li> 
<li>investigate why some finders have BC problems.</li> 
<li>generate different firmware designs for different SLs using 1-miss logic.  currently we are using SL7 3-miss designs for every SL</li> 
<li>test the mask finding algorithms of the finders by loading patterns corresponding to a single mask into the XTCs</li> 
</ul><p/> 
 
For the SLAM, Brian will be coming out today to work on it.  We put in a request with operations for that, asking for the COT, XFT and possible XTRP crates.  According to the main shift log they are working on it right now.<p/> 
 
The datasets that are currently believed to be the best to use are: 
<ul> 
<li>run 217088 is the cosmics run taken from Tuesday to Wednesday (last night) and should be good for testing.</li> 
<li>run 217039 uses pattern sending mode to turn all the events on.  For this run we read out all XFT crates and the XTRP crate on every event and we put the linkers in a special mode to send fake tracks into the SLAM.  The data is only in the look area, so everyone who wants to use it, should copy it.</li> 
<li>run 217040 uses the same configuration, but with all events off</li> 
<li>runs 217019, 217020, 217021, 217022, 217024, 217027, 217030, 217033, 217035, 217036, 217037, 217038 are the same configuration, but with only the first (the second, the third...) event in each bunch train containing hits</li> 
</ul>
<!-- Author: Nils -->


<!-- Date: Wed May 31 12:52:28 2006 -->
<pre>Run 217111 ACTIVATE: RunSet: SLAMINSTALL Trigger: PHYSICS_3_07 [3,761,610] bc = 30 - efron x2162  
 
all entries good except for 1c.  1c == all zeros 
 
 
RunSet: SLAMINSTALL  Trigger: PHYSICS_3_07 [3,761,610] bc = 33 
1c 2b 3a all zeros.  others are good 
 
 bc =33 again 
1b,1c,2a,2c all zeros.  3c shows headers and footrs in middle of event. 
 
RunSet: SLAMINSTALL  Trigger: PHYSICS_3_07 [3,761,610]217114 bc =36 
 
217115 bc =36 
 
</pre>
<!-- Author: Jonathan Efron -->


<!-- Date: Wed May 31 23:43:40 2006 -->
There is not much to report for the day, except that for tomorrow we are now also planning to do some tests on the connection of the Finder crates to L2.
<!-- Author: Nils -->


<!-- Date: Thu Jun 1 15:55:54 2006 -->
<H3> SLAM Debugging </H3> 
 
<p> Yesterday, we hooked a logic analyzer up to the SLAM board in slot 19 of b0xft01.  We then started trying runs with various settings and managed to accomplish the following: 
<ul> 
<li> Timed in the L1 pipeline without relying on the auto-synching feature, so the readout works right away rather than needing to wait for a L1A on B0. 
<li> Determined that we could make the pipelines work reliably by shifting the timing on the SLAM boards by 6 clocks.  This is consistent with what we had discovered by comparing the teststand timing to the timing at B0. 
<li> For reasons unknown (or at least not well understood by me) we do no get the stereo pixel data for the first event in the train of 12 bunches. 
<li> Saw that some stereo finder fibers sometimes skip a random event in the first train of 12 immediately after an HRR.  This missing event causes the SLAM pipeline for that fiber to become permanently out of synch for that run (pipelines are empty or at least misaligned for those fibers).  Scott has reproduced this in his teststand and is looking for a fix. 
</ul> 
 
<p> Since yesterday, we have a new version of the SLAM firmware that correctly sets the shifted timing correctly from the hardware database.  Today, we tested this new firmware by taking runs in which XTC sent out patterns where for one event, all hits (and therefore all pixels) are turned on and for the other 11 events in the train, no hits are sent.  We stepped this through the full 12 bunches in the train (i.e. turned on and looked at the first event, second, etc.)  We also set the interval for sending L1 accepts so that we sent 3 L1 accepts per turn (i.e. one for each train).  So, for example, we would look at bunches 0, 53, and 106 in the same run.  This lets us map out the behavior of the system through the full 36 bunches using only 12 runs. 
 
<p>These runs were taken with the 8 GeV SLAM firmware (has a limited  number of roads that confirm only > 8 GeV tracks over a limited phi range).  This firmware also the best version of the function pixel pipeline that we have.  The linker was put into diagnostic mode so that it put a track on every linker in every event.  Note: Not all of these tracks were > 8 GeV, so not all would be confirmed, even with all the pixels on.  Furthermore, the limited road set doesn't cover all possible phi values, so not every > 8 GeV track should be confirmed either. 
 
<p>With the setup described above we took the following set of runs: 
<p>Common settings for all runs: 
<ul> 
<li>Interval0 = 52 (CDF clocks between L1A) 
<li>pipeline offset (in SLAM) = 0x6 (timing shift for SLAM boards) 
<li>SLAM pipeline = 0x20c572 (lots of different things packed into one register) 
<li>Full "partial road" SLAM design, v2003 
<li>Linker Diagnostic, nobmftv4.rbf 
</ul> 
<p>Note below: CalibInterval determines the BC for the first L1A.  CalibInterval=27 corresponds to BC 0. 
<br><br> 
<table border="1" cellpadding="2" cellspacing="2"> 
<tbody> 
<tr> 
<td>Run<td>CalibInterval<td>BC values expected<td>XTC patterns 
<tr> 
<td>217246<td>27<td>0,53,106<td>FirstEventOn.sf 
<tr> 
<td>217243<td>30<td>1,54,107<td>SecondEventOn.sf 
<tr> 
<td>217247<td>33<td>2,55,108<td>ThirdEventOn.sf 
<tr> 
<td>217257<td>36<td>3,56,109<td>FourthEventOn.sf 
<tr> 
<td>217259<td>39<td>4,57,110<td>FifthEventOn.sf 
<tr> 
<td>217261<td>42<td>5,58,111<td>SixthEventOn.sf 
<tr> 
<td>217262<td>45<td>6,59,112<td>SeventhEventOn.sf 
<tr> 
<td>217263<td>48<td>7,60,113<td>EigthEventOn.sf 
<tr> 
<td>217264<td>51<td>8,61,114<td>NinthEventOn.sf 
<tr> 
<td>217265<td>54<td>9,62,115<td>TenthEventOn.sf 
<tr> 
<td>217266<td>57<td>10,63,116<td>EleventhEventOn.sf 
<tr> 
<td>217267<td>60<td>11,64,117<td>TwelvethEventOn.sf 
</tbody> 
</table> 
 
<p>We now need to analyze these runs offline.  After taking these runs, we put the linker back into its default mode (regular firmware) but left the SLAM with its the partial roads full SLAM design firmware.  We turned the COT and XFT crates over to Nils.<br>
<!-- Author: K.Lannon, J.Efron -->


<!-- Date: Thu Jun 1 17:34:08 2006 -->
<pre>The XTRP is now ready for stereo confirmation.  The new mapping code is in and running happily.  I verified that we fully replicate the maps with the offline emulation.  The mapping code is backward compatible, so it will work fine with existing tables and the SLAM in pass-through mode.   If we get a chance at cosmics with the system, we should run cosmics_3d_v3, which has several stereo confirmed triggers in it.</pre>
<!-- Author: KPitts -->


<!-- Date: Thu Jun 1 18:32:15 2006 -->
<pre>Finder->Pulsar tests: 
 
Took two quick runs 217301, 217302 with XTCs all ON. Checked online  that L2 finder pixels are filled with 'f'. Will check if the data captured by Pulsar is adequate.  
 
</pre>
<!-- Author: Andrew Ivanov -->
<!-- Comment: Wed Aug 23 20;24;05 comment by...Jonathan Efron -->
<pre>Here are the significant errors in run 221920 in order of errors seen:

xft05  slot 19 chip 1  7c0-&gt;5c0 (pt bit 6) in the linker-&gt;slam connection

xft01  slot 9 chip 1  7c0-&gt;5c0 (pt bit 6) in the linker-&gt;slam connection

xft01  slot 11 chip 7  7c0-&gt;7e0 (pt bit 2) in the linker-&gt;slam connection (error takes a no track to an undefined track)

xft03  slot 15 chip 7,9,11  7c0-&gt;7c2 (phi bit 2) in the slam-&gt;xtrp connection  (pin error only one of this type seen.)


xft01  slot 11 chip 7  7c0-&gt;7e0 (pt bit 2) in the linker-&gt;slam connection (error takes a no track to an undefined track)
</pre>
<!-- Date: Thu Jun 1 18:47:07 2006 -->
I took a special test pattern run 217303.  In this run for the first few cells of SL7 I loaded the hits corresponding to one mask each.  Analyzing this run should allow me to have a first glimbs at the segment finding in the stereo finder.
<!-- Author: Nils -->


<!-- Date: Fri Jun 2 11:32:25 2006 -->
swapped the boards in slot 10, 11, 12 between b0xft06 and b0xft07.
<!-- Author: Nils -->


<!-- Date: Fri Jun 2 12:02:25 2006 -->
finder chip b0xft07/19B is not loaded correctly
<!-- Author: Nils -->


<!-- Date: Fri Jun 2 13:39:21 2006 -->
<H3>Stereo Finder to SLAM Checks</H3> 
 
<p>We now have a SLAM design that puts the data valid signal from all nine fibers onto the debug lines so that we can compare the behavior of these signals to what we see on the scope.  We took a series of runs where we looked at the data valids from the stereo finder for the first 12 events after an HRR and then checked the contents of the L2 buffers on the SLAM using xftdaq.  We used the SLAM in b0xft01, slot 19, but we sometimes had different fibers plugged into it. 
 
For the first set of runs, the correspondence between Stereo Finder channels and SLAM channels is as follows: 
<br><br> 
<table border="1" cellpadding="2" cellspacing="2"> <tbody> 
<tr><td>SLAM Channel<td>Stereo Finder Channel 
<tr><td>1a<td>06-06-B 
<tr><td>1b<td>06-07-A 
<tr><td>1c<td>06-07-B 
<tr><td>2a<td>06-12-B 
<tr><td>2b<td>06-13-A 
<tr><td>2c<td>06-13-B 
<tr><td>3a<td>06-18-B 
<tr><td>3b<td>06-19-A 
<tr><td>3c<td>06-19-B 
</tbody> 
</table> 
<p> Results: 
<br><br> 
<table border="1" cellpadding="2" cellspacing="2"> <tbody> 
<tr><td>Trial<td>Missing Data Valids from Stereo Finder<td>Bad Fiber Pipelines on SLAM 
<tr><td>1<td>1a<td>1a,2a 
<tr><td>2<td>1a<td>1a,2a 
<tr><td>3<td>1a,2a<td>1a,2a 
<tr><td>4<td>1c,3b<td>1a,2a,3b 
<tr><td>5<td>1a,1b,1c,3b<td>1a,1b,1c,2a,3b 
<tr><td>6<td>1a,1b,1c<td>1a,1b,1c,2a 
<tr><td>7<td>1a,1b,2b,3b<td>1a,1b,2a,2b,3b,3c 
<tr><td>8<td>1b<td>1b,2a 
<tr><td>9<td>1a<td>1a 
<tr><td>10<td>1a,1b,2c<td>1a,1b,2a,2c 
</tbody> 
</table> 
 
For the next set of runs, we swapped in the channels from the SLAM in slot 17 of b0xft01 
<br><br> 
<table border="1" cellpadding="2" cellspacing="2"> <tbody> 
<tr><td>SLAM Channel<td>Stereo Finder Channel 
<tr><td>1a<td>06-06-A 
<tr><td>1b<td>06-06-B 
<tr><td>1c<td>06-07-A 
<tr><td>2a<td>06-12-A 
<tr><td>2b<td>06-12-B 
<tr><td>2c<td>06-13-A 
<tr><td>3a<td>06-18-A 
<tr><td>3b<td>06-18-B 
<tr><td>3c<td>06-19-A 
</tbody> 
</table> 
<p> Results: 
<br><br> 
<table border="1" cellpadding="2" cellspacing="2"> <tbody> 
<tr><td>Trial<td>Missing Data Valids from Stereo Finder<td>Bad Fiber Pipelines on SLAM 
<tr><td>1<td>1a,1c<td>1a,1c,2a,2b,3c 
<tr><td>2<td>--<td>2a,2b,3c 
<tr><td>3<td>1b,1c,2c<td>1b,1c,2a,2b,2c 
</tbody> 
</table> 
 
Finally, we swapped 2a with 1c and 2b with 2c and took one run 
<br><br> 
<table border="1" cellpadding="2" cellspacing="2"> <tbody> 
<tr><td>SLAM Channel<td>Stereo Finder Channel 
<tr><td>1a<td>06-06-A 
<tr><td>1b<td>06-06-B 
<tr><td>1c<td>06-12-A 
<tr><td>2a<td>06-07-A 
<tr><td>2b<td>06-13-A 
<tr><td>2c<td>06-12-B 
<tr><td>3a<td>06-18-A 
<tr><td>3b<td>06-18-B 
<tr><td>3c<td>06-19-A 
</tbody> 
</table> 
<p> Results: 
<br><br> 
<table border="1" cellpadding="2" cellspacing="2"> <tbody> 
<tr><td>Trial<td>Missing Data Valids from Stereo Finder<td>Bad Fiber Pipelines on SLAM 
<tr><td>1<td>1a,3a<td>1a,1c,2c,3a 
</tbody> 
</table> 
 
<p>So, to conclude, when we have a missing data valid in the stereo finder, we always see the SLAM pipeline off.  There are also cases in which the SLAM pipeline is bad almost every time (even when the stereo finder data valid is not missing).  These cases seem related to stereo finder channels (i.e. when we swap fibers at the SLAM, it follows the fiber). 
 
<p>Note: Also there was one case (unfortunately I don't seem to have the exact channel recorded) in which one stereo finder channel was missing ALL the data valids!
<!-- Author: K.Lannon, J.Efron -->


<!-- Date: Fri Jun 2 23:18:44 2006 -->
After a hard day of work, I finally got it nailed.  I now verified that I load the XTCs correctly from the list of hits.  Also I have a piece of code (based on Gene's code), that reads out the XSFD bank and fills the hits and pixels in a tree with the correct cell numbers.  Also segment finding looks promising, but I will have to test it in detail tomorrow.  At least I now have a better understanding of where the hits and the pixels of the bank are located in phi.
<!-- Author: Nils -->


<!-- Date: Sat Jun 3 18:03:01 2006 -->
It turns out that for Finder 103 the pixel buffers in Chip B are malfunctioning.  They read a constant sequence of 0x128,0x000.
<!-- Author: Nils -->


<!-- Date: Sat Jun 3 21:22:52 2006 -->
Today I took a number of runs for the XFT to validate the segment finding in the stereo finders.  For that I loaded a hit pattern corresponding to a different mask every 10 cells in SL7 (the other SLs don't have the correct patterns programmed in yet).  Now I need to analyze them.  That is a little tricky, we don't have the correct test software yet.  At least I understand the format of the mask file now...<p/> 
Interesting are the runs 217401 and 217402, the later one has three misses for each mask.  If somebody understanding the simulation could look at those as well it would be great.  At the moment I'm basically trying to interpret what I see by manually comparing to the mask file.
<!-- Author: Nils -->


<!-- Date: Sun Jun 4 16:31:44 2006 -->
<pre>I swapped Stereo Finder duplex fibers for xft7 slot 13 A1,2 and xft7 slot 13 A3,B1.  They were in the wrong positions</pre>
<!-- Author: Jonathan Efron -->


<!-- Date: Sun Jun 4 17:36:01 2006 -->
I have put the new 3414 firm ware in all the slam cards and the ran a series of tests.  The new firm ware is supposed to be able to correct possible missed data valids during a run's first train.  The parameters for these runs were 
 
<ul> <li>Interval0 = 52 (CDF clocks between L1A) <li> calibInterval = 30 (2nd bunch of each train). <li>pipeline offset (in SLAM) = 0x6 (timing shift for SLAM boards) <li>SLAM pipeline = 0x20c571 (lots of different things packed into one register) <li>pass through design, v3414 <li>Normal linker </ul> 
Half the runs were taken with full pixel on and half off. 
<BR> 
I recorded three items.  The failing datavalids on the full train, the L2 buffers at the end of the event, and analyzing offline the XSLD banks of the first twenty events.  
<BR> 
What I observed is that  
 <ul> <li> That after an initial data valid missing bit in the first event (as to be expected with missing data valid bit), later events displayed the correct pixel data 
<li> In previous runs, we observed problems in the "2A" line.  We read from the banks either all 2222s or 8888s, even though there appeared to be no problems with the data valid.  When I looked in the Stored XSLD banks, these items were not there.  In one run, 217443, I did observe these repeating banks.  Apparently the data valid from the stereo finder is turned off later in the event, and stays off.  A copy of this run is availble on the online machines at ~cdf_xft/load_12events/results/seriesFFFd.log .  Furthur study is needed. 
</ul> 
 
Note: during the study I noticed that two Stereo Finder ouput finders were switched (corrected), and that XFT05 slot 7 is not taking data.
<!-- Author: Jonathan Efron -->


<!-- Date: Tue Jun 6 12:19:07 2006 -->
<pre>loaded a new diagnostic (nobmv5.rbf) firmware on b0xft01 slot 4 finder 1.  It is a bad design.  It produces no tracks or none trackes (7c0).  Hopefully a replacement will be ready soon.</pre>
<!-- Author: Jonathan Efron -->


<!-- Date: Tue Jun 6 17:31:59 2006 -->
Swapped out some finders and swapped some other finders around.  I hope I updated all of the flashrams accordingly.
<!-- Author: Nils -->
<!-- Comment: Wed Jun  7 09;50;23 comment by...Paolo Azzurri -->
<pre>Loaded flashrams for swapped finders, and downloaded current (6.0-6.1) firmware to the finder chips. </pre>


<!-- Date: Thu Jun 8 00:46:27 2006 -->
<pre>This evening, we took several cosmic ray runs with the COT at full 
voltage and the solenoid on.   The entire XFT system was included 
in these runs.   The run numbers are 
 
   217686 and 217694 using COSMICS_3D_v2 
   217714 using COSMICS_3D_v3. 
 
 
Both of these trigger tables have triggers that only demand a 
1.5GeV axial XFT track.  Then there are additional triggers that 
demand stereo confirmation.   In these runs, about half of the 
axial triggers also passed the stereo confirmation trigger.  Take 
a look at the e-log to see a couple of event pictures. 
 
 
For the files in the look area (not the entire runs) I filtered 
off the events that satisfied the 1.5GeV axial track trigger.  The 
files can be found on fcdfsgi2: 
 
/cdf/data05/s2/xft/cosmic/filter_35257_xft.root 
                          filter_3525e_xft.root 
                          filter_35272_xft.root 
 
 
At this point, it is still unclear exactly how the system was 
configured for these runs.  For example, what masks were loaded 
in the finders?   I am unable to locate this information in the 
XFT e-log.   It would also be helpful to know exactly what we 
expect from the data.  For example, is the XSLD bank expected 
to contain all "good" information?  does it include both axial 
track information and stereo pixel information?   It would be 
very helpful to document this information in the e-log, so that 
people who want to look at the data are not wasting their time 
on features that are already known. 
</pre>
<!-- Author: KPitts -->


<!-- Date: Thu Jun 8 07:34:01 2006 -->
<pre>Hear is the status of the Finders, as it was for the cosmics running last night:  All finders were loaded with the latest (1-miss) firmware version for their respective SL.  The latest firmware version includes a fix for the problem with the missing events after an HRR.</pre>
<!-- Author: Nils -->
<!-- Comment: Thu Jun  8 09;11;04 comment by...Nils -->
SL5 was using the 3-miss set

<!-- Comment: Thu Jun  8 09;33;37 comment by...Jonathan Efron -->
<pre>For this cosmics run, from the shift e-log last night: 
Linkers running a standard design. 
SLAMs were running a full slam version with a modified slam confirmation timing. Will not affect axial track output to xtrp </pre>


<!-- Comment: Thu Jun  8 14;09;10 comment by...Nils -->
I stand corrected.  All SLs use 3-miss designs.
<!-- Date: Thu Jun 8 10:41:16 2006 -->
<pre>
Loaded new diagnostic linker design on block 1 of all linker boards. Here is Richard Hughes' description. 
<BR> 
/cdf/onln/data/cdf_xft/XFTbin/linker.diagnostic/nobmftv5.rbf 
		this file has all linker chips (except linker chip 1) modified with the new  
		diagnostic design.  Linker chip 1 has the old diagnostic design (no 
		good reason for this - I just forgot to modify the fcf file, which 
		points at the old design sof). 
In this diagnostic design, we can set 36 different tracks for 
		a single turn (3 trains * 12 tracks per train).  The design is 
		setup so that it just continually loops overs these 36 tracks, 
		such that the same track will show up in the same bunch every 
		turn. 
		If you look at genDiagTracks.C, you will see where you can set the 
		values of the pt bins you would like for these 36 tracks. 
		 
		The design is setup so that it pumps out specific data for each of 
		the 158 crossings per turn.  But only 36 of them have valid track 
		data (i.e. each track is *not* sent 3 times).  The rest are empties, but 
		with tags to help us see if it is an "empty" (no track during a train) 
		or an abort gap event.  Note that the code also prints out what  
		bunch crossing number should go with each track. 
		 
		In this same area is the output of running this script (codeFrag.txt). 
		The first few lines are: 
link_out_temp[107][12..0] = H"8bb";   -- bc 0 ptbin(hex) 5f signed 47 ptval 1.520000 phi 0 
link_out_temp[108][12..0] = H"101";   -- bc 1 empty 47  phi 1  
link_out_temp[109][12..0] = H"201";   -- bc 2 empty 47  phi 2  
link_out_temp[110][12..0] = H"800";   -- bc 3 ptbin(hex) 0 signed -47 ptval -1.520000 phi 0 
link_out_temp[111][12..0] = H"101";   -- bc 4 empty -47  phi 1  
link_out_temp[112][12..0] = H"201";   -- bc 5 empty -47  phi 2  
		 
		You see that for the linker, track #107 corresponds to bunch crossing=0.  I have 
verified that this behaves correctly with run control, and I got the 
correct results in the output formatter pipeline for bc=0,1,53,54,106,107. 
		 
For the script in its current form, I have a +/- 10 Gev track in bc's 24 and 27, 
you can modify the list of "ptbinSigned" array values as necessary. 
		 
		 
 
For an initial test of the first train of the slam, here is what I found for the pt bin of tracks: 
 
bc 0 = 5f 
bc 3 = 0 
bc 6 = 58 
bc 9 = 7 
bc 12 = 4e 
bc 15 = 11 
bc 18 = 44 
bc 21 = 1b 
bc 24 = 3a 
bc 27 = 25 
bc 30 = 30 
bc 33 = 30 
bc 36 = 0  (abort gap) 
</pre>  

<!-- Author: Jonathan Efron -->
<!-- Comment: Thu Jun  8 20;23;15 comment by...Ben Kilminster -->
<pre>I made files which contain XTC2 hits corresponding to 144 tracks each with Pt 1.52 GeV, 
spaced in phi by 2.5 degrees.   

If one had a diagnostic linker design which put 1.52 GeV tracks in 
local phi of 0 for each linker,  one would expect to stereo confirm 
every other linker track :  
0 deg -&gt; confirmed
1.25   -&gt; not confirmed
2.5     -&gt;  confirmed
...


Since Richard's diagnostic design has alternating 1.52 GeV linker tracks, 
and -1.52 GeV linker tracks, I'd expect to see the following :

bc 0:   tracks confirmed in every other linker
bc 1:   empty
bc 2:   empty
bc 3:   tracks not confirmed
bc 4:   empty
bc 5:   empty
bc 6:   tracks confirmed in every other linker


Richard, the procedure to do this is :

1)  set up a run with XFT finders, linkers, (& xtrp if you want)
2)  don't include the COT in the run (The "Start" from RC reconfigures the XTCs)
3)  reset the fibers by doing :
	source ~cdf_xft/fibers/reset_xtc
4)  load the 144-track events onto the XTCs :
	cd ~cdf_xft/load_event
	./make_files PluPt1.52.144tracks.dat
	# the following loads the patterns onto the XTCs
	./set_patterns
	# now the XTCs will be constantly sending out hits for these tracks every event


~Ben
</pre>


<!-- Date: Fri Jun 9 09:56:29 2006 -->
A initial look of the confirm bits of the cosmic run availble at the  
<a href=  
'http://glast2.mps.ohio-state.edu/efron/41'> Ohio State E-log </a>
<!-- Author: Jonathan Efron -->


<!-- Date: Fri Jun 9 11:36:29 2006 -->
<pre>Summary of XFT SLAM testing : 
 
The goal of these tests was to check for tracks and stereo segments in SLAM pipeline  
for a set of well-defined tracks that were input using a linker diagnostic design, and  
for a set of XTC2 hits which corresponded to the tracks.  
                       
The linker was loaded with a diaghnostic design with the following structure 
bc 0 :   1.52 gev track in phi 0 for each linker 
bc 1 :   phi marker 1 
bc 2 :   phi marker 2 
bc 3 :    -1.52 gev track in phi 0 for each linker  (every 1.25 degrees) 
bc 6 :    1.95 gev track in phi 0 for each linker 
bc 9 :    -1.95 gev track in phi 0 for each linker 
bc 12 :   3.14 gev track in phi 0 for each linker 
bc 15 :   -3.14 gev track in phi 0 for each linker 
bc 18 :   -3.14 gev track in phi 0 for each linker 
bc 21 :   4.68 gev track in phi 0 for each linker 
bc 24 :   -4.68 gev track in phi 0 for each linker 
bc 27 :   9.14 gev track in phi 0 for each linker 
bc 30 :   -9.14 gev track in phi 0 for each linker 
bc 33 :   192  gev track in phi 0 for each linker 
bc 36 :   -192  gev track in phi 0 for each linker 
 
then abort gap, then two other trains with different pt tracks 
 
 
Run 217891 :   XTC2's were loaded so that the first bunch out of every 12 had  
                       a 1.52 GeV track in every other linker at phi=0:  0 deg, 2.5 deg,  
                       5.0deg, ... for a total of 144 tracks 
                       One would only expect the first bc=0 to have a confirmed track  
                       in every other linker board according to the linker diagnostic design 
                       above. 
 
Run 217893 :  (in look area) 
                       The 12-event structure of the XTC2 hits is the same as the first train  
                       of the linker diagnostic.  There are 144 tracks per event in every  
                       other linker.  So there should be confirmed tracks in  
                       everry other linker for every event in the first train (bc=0, 3, 6, ...) 
 
Run 217897 :  (in look area) 
                       Here we have the same structure in the finders as the first train of 
                       the linker diagnostic design,  but now there are only 2 tracks per  
                       event instead of 144 tracks.  The tracks are at phi = 0, and  
                       phi = pi.  So there should be two confirmed tracks per event for the  
                       first 12 events in a turn. 
 
We are analyzing the results now. 
 
 
 
 
 </pre>
<!-- Author: Ben & Jonathan & Jason & Kevin & Richard -->


<!-- Date: Sat Jun 10 08:57:37 2006 -->
We had the first store of run 2b last night.  The XFT stereo finder crates were included and working except for one finder (from a first glance).  However there was a problem with the axial system.  Basically the axial finders were producing a large number of errors all over the place.  I am not quite sure yet, as to what could cause such a problem and how to diagnose it.  All the ideas I have right now are not particularly good ones.  
<!-- Author: Nils -->


<!-- Date: Tue Jun 13 13:18:31 2006 -->
<pre>Since we swapped so many XTC cards during the shutdown, we 
removed the card-dependent XTC calibrations from february, and 
for the data taken June 12-13, all of the XTC cards have the 
same settings. So if anyone uses this data for performance studies,  
the efficiency might be a little lower. Once this store is dropped 
we will put in new card to card calibrations for the store 
that is supposed to come in the afternoon/evennig of June 13 (tonight).</pre>
<!-- Author: Greg -->
<!-- Comment: Fri Jun 16 10;06;19 comment by...Greg & Heather -->
<pre>XTC2 data can be considered calibrated and ready as of run 218220.
 </pre>


<!-- Date: Fri Jun 16 17:13:37 2006 -->
Updated all the finders to the 1-miss firmware.  The capture test software is broken, so I couldn't check it out.
<!-- Author: Nils -->


<!-- Date: Fri Jun 16 19:19:17 2006 -->
<pre>After looking through 2 years of e-logs to figure out which  
SLAM dipswitch settings were being used in which boards, I  
realize that incremental log messages are not that efficient. 
So here are all the SLAM board dipswitch settings to the  
best of my knowledge : 
 
xft 01 : 
slot 5   -  def 
slot 7   -  def 
slot 9   -  def 
slot 11  - Richard 
slot 13  - def 
slot 15  - def 
slot 17  - def 
slot 19  - def 
 
xft 03 : 
slot 5   -  
slot 7   - Richard 
slot 9   -  
slot 11 
slot 13  - Richard 
slot 15  - Richard 
slot 17 
slot 19 
 
xft 05 : 
slot 5   -  Ben      (Ben RULES !!@!!!) 
slot 7   -  Richard 
slot 9   -  Richard 
slot 11  -  Richard 
slot 13  -  def 
slot 15  -  def 
slot 17  -  def 
slot 19  -  Richard 
 
</pre>
<!-- Author: Ben Kilminster -->
<!-- Comment: Fri Aug 11 14;32;00 comment by...K.Lannon -->
<p>Def = 8,8 = 8 ns?
<p>Ben = 4,8 = 6 ns?
<p>Richard = 12,8 = 10 ns?
<p>xft05, slot 7 has gone back to "def"
<p>xft05, slot 19 has been changed to "Ben."  Was for a little while 6,8 ("Jonathan"?)
<!-- Comment: Wed Aug 23 23;12;36 comment by...Jonathan Efron  -->
<pre>b0xft05, slot 19 has been changed to "Default". 

b0xft01, slot 9 has been changed to "Richard"</pre>
<!-- Comment: Wed Sep 13 09;46;05 comment by...Jonathan Efron -->
<pre>b0xft05, slot 5 setting were at default settings, not "ben" settings.  Testing "Richard" setting to get rid of 7c0 -&gt;5c0 problems on the board</pre>
<!-- Date: Fri Jun 16 20:10:05 2006 -->
<pre>We are investigating a problem in which XSLD (SLAM tracks bank) 
disagrees with XTRD (XTRP tracks bank) at a rate of 180/4000 
events = 4.5 % error rate. 
 
This error was occurring in beam data in XFT crate 05, slot 05, 
and showing up in TrigMon. 
 
We are able to reproduce the errors offline with our SLAMCheck code. 
 
In 218411 (beam data) we saw XSLD-&gt;XTRD errors for 76/3685 events: 2% error rate. 
 
In 218458 (linker diagnostic) we see 300/12000 errors: 2% error rate. 
 
The error consistently adds "0x200" to the XSLD data : 
    XSLD    XTRD 
    dd0 -&gt;  fd0 
    5d0 -&gt;  7d0 
    2800 -&gt; 2a00 
 
 
To solve this problem: 
 
1)  We first tried changing SLAM dipswitch settings in run 218454 
 from "Ben settings" (4,8) to "Richard settings" (12,8).  This 
did not change the error rate of XSLD-&gt;XTRD, but did introduce 
errors between XFLD-&gt;XSLD.   We expected this because the 
dipswitch settings effect the track input delay.   So we 
switched back to "Ben settings" before 218458. 
 
2)  Next, we tried to switch to the passthrough design on this 
one board.  However, the particular file previously loaded into 
 the flashram (SLAM_Jun7_even_3414.pof) didn't have a passthrough 
design in page 1.  So we erased the flashram and loaded crate 5, 
slot 5 with SLAM_8GeV_Jun6_even_3414.pof which has an old full 
slam design, but the same passthrough design. 
 
In 218473, with this run in passthrough, 
we find the error reduced by a factor of 3 to : 
    76/10,300 = 0.7%. 
 
The error rates are still that 0x200 gets added to the XSLD data 
word. 
 
 
However, we've been noticing in our diagnostic tests, 
these same errors in a few other boards: 
xft 01, slot 19 :   26/11000 =  0.2 % 
xft 03, slot 19 :   72/11000 =  0.6 % 
 
 
We check the Trigmon plots for the most recent beam data run 
(run 218426), and there are no errors in these boards. So 
either these problems are new, or they only exist in our 
diagnostics tests.  We will keep an eye on these 
 
In 218478, we do a longer 70 K run to check the error rate : 
We get an error rate of : 
 
xft 01, slot 19 :   0/71000 =  0 % 
xft 03, slot 19 :   0/71000 =  0 % 
xft 05, slot 5  :   739/71000 =  1 % 
 
So the errors on the other boards went away, but our bad board 
is still bad even in passthrough mode.  From Trigmon reference 
plots, we expect errors of this type to be at most 0.2%. 
 
 
3) We decide to swap the SLAM board.  We have only one spare on 
hand. The rest are at OSU.  ( We will get some more out here.) 
 
We remove SLAM V2 #20 from xft05 slot 5, and 
replace with SLAM V2 #28.  We reprogram VME chips and SLAM chips. 
 
 
We took a quick run (218504) with the new SLAM board in 
crate 5, slot 5 : 
error rate = 39/6000 =  0.65 %. 
 
We take a run 10 times longer (218508) to verify this rate : 
error rate =  346/52000 = 0.65%. 
 
These errors all add 0x200 to the XSLD. 
 
 
We have been running with a trigger interval of 300 
(Interval0 = 300) for our recent tests. 
 
We will try a run (218517) with Interval0 of 30. This will allow 
us to test the error rate at a faster readout speed, and will 
also test different tracks at different boards. 
 
We find errors in another board now also : 
xft05, slot 5 :   52/10000 = 0.5 % 
xft01, slot 19 :  26/10000 = 0.25 % 
 
All of these errors are a 0x200 getting added to XSLD. 
 
 
For the time being we are done. 
 
Conclusions: 
 
   1)   There is an error where 0x200 gets added to data words 
    in the process of going from SLAM to XTRP (XSLD -&gt; XTRD). 
    This results in track Pt increasing, and an increased 
    trigger rate.   In beam data, this was a 5% error rate. 
 
    2)   We can reproduce this error by inputting tracks into 
    Linkers and running through linker -&gt; slam -&gt; xtrp. 
    We see an error rate of 0.6 %. 
 
    3)  This error does not follow the SLAM firmware. 
    It exists in passthrough and in full slam designs. 
 
    4)  This error does not follow the SLAM board. 
    It exists with two different SLAM boards in the same slot. 
 
    5)   Unless we get a better idea, this error seems to be 
    related to either the slot, or the connection to the XTRP. 
    We checked the SLAM -&gt; XTRP cable connector, and it looks 
    fine.  There are no bent pins.   In the process of switching 
    dipswitch settings,  we disconnected and connected the 
    XTRP cable many times, and the errors persisted, so it is 
    not a loose XTRP connection. 
 
 
We are hoping the error rate will be smaller in the  next 
beam data run.  It seems to be random whether there are errors 
in a run or not : 
 
Run 218426 :  5% in board 5     (4K events) 
Run 218424 :  no errors         (3K events) 
Run 218423 :  no errors         (1K events) 
Run 218418 :  no errors         (7K events) 
Run 218410 :  0.6% in board 5   (3K events) 
 
 
Who knows what the answer may be for the next run ? 
 
</pre>
<!-- Author: Ben Kilminster & Jonathan Efron -->


<!-- Date: Fri Jun 16 20:25:16 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-411&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-411  width='300' align='top'></a></td><td>Here is the 5 % XFLD -> XTRD error. 
XFLD and XSLD are consistent.  
But XTRD has 0x200 added to XSLD words in board 5. 
</td></tr></table>
<!-- Author: Ben Kilminster -->


<!-- Date: Thu Jun 22 15:16:51 2006 -->
I ran a capture test on the stereo finders.  No errors in 250 events.
<!-- Author: Nils -->


<!-- Date: Fri Jun 23 20:50:02 2006 -->
I tried to update the hardware database to contain the correct firmware id for the XFT stereo finders.  However doing so, causes constant heap corrupt errors in the crates, so I changed it again to an incorrect version.
<!-- Author: Nils -->


<!-- Date: Thu Jun 29 20:53:43 2006 -->
<pre>we swapped the stereo finders in b0xft06/19 and b0xft06/20 for testing the L2 interface.</pre>
<!-- Author: Nils, Andrew -->


<!-- Date: Fri Jun 30 21:53:40 2006 -->
Switched over stereo finders to new firmware with new bank format.  Tested bank format and at first glance it is Ok.  Took two runs with the stereo finders alone.  Run 219355 is normal and run 219356 is myron mode.
<!-- Author: Nils -->


<!-- Date: Wed Jul 5 11:40:22 2006 -->
<pre>Updated the prescale readout of the XTCs to 4.  A new run should be started to pick up these settings.  (runs after 219477 should have these settings)</pre>
<!-- Author: Heather & Greg -->


<!-- Date: Tue Jul 11 15:26:52 2006 -->
<pre>We've loaded the VME and Level2 chip designs on all the stereo finders with Scott's v7r0 firmware by hand (laptop + JTAG).  Then we reprogrammed the A2 and B2 flashrams on all the boards with the v7r0 finder chip firmware.</pre>
<!-- Author: Jon, Greg -->


<!-- Date: Wed Jul 12 12:19:57 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-412&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-412  width='300' align='top'></a></td><td>Here is some graphical evidence that the system is more or less working.  This is from the analysis of run 0x33a19 and it 
shows that we find stereo pixels in close proximity to tracks 
found by level 3.</td></tr></table>
<!-- Author: M Jones -->


<!-- Date: Wed Jul 19 16:09:39 2006 -->
Loaded /home/xft/altera/GoodCrate/Slam60/SlamFlash/SLAM_July19_odd_3416.pof on the SLAM board in b0xft01, slot 19.  This firmware is identical to the default firmware except that there are different outputs sent to the debug header (monitored by the logic analyzer).  We have already been able to make some progress in understanding what we see on the logic analyzer and are compiling a new version of firmware that seems to address the problem in the teststand.
<!-- Author: K.Lannon -->


<!-- Date: Fri Jul 21 16:51:33 2006 -->
<pre>Updated the firmware in the L2 chip in the Stereofinders.  Both b0xft06 and b0xft07.  Made sure that the finder chip firmware was correct in all boards, and did a capture test (XTC -&gt; SF-Wire), with no errors.  Greg then ran tests with b0xft06 and 7 and the L2 pulsar crate using run control, and that was fine too.  So we gave the crates back to the control room.</pre>
<!-- Author: Jon Wilson -->


<!-- Date: Tue Jul 25 10:01:54 2006 -->
<p>After power outage, had to download flashrams on the following Axial Finders: 
<ul> 
<li> xft00, slot 10, Input chip 
<li> xft00, slot 19, Input chip 
<li> xft00, slot 20, Input chip 
<li> xft02, slot 11, Pixel chip 
<li> xft02, slot 14, SL4 chip 
<li> xft02, slot 18, Input chip 
<li> xft02, slot 19, SL4 chip 
<li> xft04, slot 6, Input chip 
</ul> 
 
<p>It took two tries to get xft02, slot 19 loaded but I think that's because I accidentally unbooked the finder crates and the shift crew tried to get them.
<!-- Author: K.Lannon -->


<!-- Date: Tue Jul 25 12:16:44 2006 -->
<pre>I swapped all SL7 finders with their neighbors, i.e. 15&lt;-&gt;16, 17&lt;-&gt;18, 19&lt;-&gt;20.  This should enable us to tell which of these problems are problems of a particular finder board and which are other kinds of problems.</pre>
<!-- Author: Nils -->


<!-- Date: Tue Jul 25 17:47:43 2006 -->
<H3>SLAM Studies</H3> 
 
<p>We tried the following tests today with the SLAM. 
<ul> 
<li> We updated the SLAM firmware to versions 2005 (even) and 2106 (odd).  Firmware version 2005 has a fix for a state machine problem causing errors in stereo pixels.  2106 also has this fix, but it has a shift in the timing of the output of the XTRP that we hoped would address the SLAM to XTRP errors we've been seeing. 
<li>  After changing this firmware, we had errors on xft05 slots 7 and 19.  In slot 7, the 3rd pt bit on chips 1, 3, and 5 was stuck low (every event), consistent with the recent SLAM to XTRP problems we have been having.  For slot 19 we were seeing errors with the 4th pt bit being high in about 1/3 of the events for chip 6.  The slot 19 error could be consistent with a "glitch."  Both boards with errors with errors had "non-standard" dipswitch settings (slot 7 = 12,8; slot 19 = 6, 8; standard = 8,8). 
<li>  We tried switching both slots 7 and 19 to "standard" timing.  This had no effect on slot 7 and made slot 19 worse. 
<li>  We tried switching slot 19 to 4,8.  The problem went back to it's previous level. 
<li> We tried switching back to firmware version 2105.  This fixed the problem with slot 19, but slot 7 still had errors. 
<li> We tried swapping XTRP cables (at the SLAM) between slots 5 and 7.  The problem stayed with the XTRP board. 
</ul> 
 
<p> After all this, we contacted the XTRP and they are investigating on their end.
<!-- Author: K.Lannon -->


<!-- Date: Thu Jul 27 17:11:24 2006 -->
<pre>We updated the XTC2 card calibrations in the hardware database.  They will be picked up on the run after run 220589. These will fix problem seen in the top TrigMon XTCD CO plot.</pre>
<!-- Author: Heather & Greg -->


<!-- Date: Fri Jul 28 09:16:08 2006 -->
Unplugged the first two fibers on b0xft06/18.  Swapped fibers on b0xft06/19 and b0xft06/20.  This should help us to debug the problems in b0xft06/20.
<!-- Author: Nils -->


<!-- Date: Fri Jul 28 19:40:24 2006 -->
Temporarily spread out the fiber of b0xft06/20B to six different finders (run 220604), but now they are all back were they belong.
<!-- Author: Nils -->


<!-- Date: Sat Jul 29 14:53:47 2006 -->
I just ran a bunch of capture tests XTC -> SF, in order to debug a problem that occured when you ran a capture test using just one COT crate, but not if you used all the COT crates.  It seems to be debugged.<br> 
<br> 
Finally, I ran a test (100 iterations) on each COT crate in succession.  3 of the crates saw some errors in a single iteration, but since I was using a software partition, it may be that there were spurious triggering signals coming in during my test.  I ran those three crates again, twice, with no errors.  So I think all is well.<br> 
<br> 
I will probably update the cdf_xft account to use the latest version (v3_0) of my code on Monday.  This will break any scripts which used the older version of the capture test (v2_0).  Probably only Nils is affected.
<!-- Author: Jon Wilson -->


<!-- Date: Sat Jul 29 15:09:55 2006 -->
Ok, I just talked to Nils, who gave the go-ahead on updating my capture test code in the cdf_xft account.  Now, when you log in, sfcap is aliased to the new code.  To get back to the old code:<br> 
 
<pre>setup -r /cdf/onln/home/cdf_xft/SFCapture/v2_0 -M ups -m SFCapture.table SFCapture</pre> 
The new code has slightly different command line syntax.  If you run it with no arguments, then it prints a (hopefully very informative) usage statement, but I'll give an example anyway:  From ~cdf_xft,<br> 
 
<pre>sfcap -T XTC SF-Wire -V random -x fibers/b0cot15.xml -i 10</pre> 
Would run a capture test from all the XTCs in b0cot15 to their corresponding Stereofinders.  It would do 10 iterations of random data.<br> 
<br> 
The old fiber files are now in fibers/v2_0/, and the new fiber files are in fibers/
<!-- Author: Jon Wilson -->


<!-- Date: Mon Jul 31 15:45:27 2006 -->
<pre>One of the 2/4 finder boards had a blown fuse.  I swapped it with the working spare.  I put a new fuse on the original board, it didn't blow, so I declared the board a good spare.</pre>
<!-- Author: Nils -->


<!-- Date: Mon Jul 31 16:26:39 2006 -->
<pre>Removed 1/3-Finder 002 from the system, because it was giving problems in cell 0.</pre>
<!-- Author: Nils -->


<!-- Date: Thu Aug 3 08:21:42 2006 -->
<p>Yesterday we noticed two high rate errors in SLAM to XTRP link: 
<ol> 
<li>  xft05, slot 5, pt bit 5 stuck high for chips 7, 9, and 11.  This problem had been present in the past, but 
it had been absent since 6/23 until at least 7/27.  Because this problem actually affects trigger rates, I doubt 
it came back much before today without someone noticing. 
 
<li>  xft05, slot 7, pt bit 2 stuck low on chips 1, 3, and 5.  This problem as first noticed 7/11 and has been 
pretty constant since then. 
</ol> 
 
<p>Both problems go into XTRP board 5. 
 
<p>Because problem #1 was more serious and because the luminosity was low, we pursuaded the ops manager to let us 
work on it (start of evening shift yesterday).  We started playing with it during a silicon D-mode calibration, so we used the linker diagnostic 
design to send fake tracks because the rest of the DAQ was unavailable.  Here is a summary of what we saw: 
 
<dl> 
<dt>Run 220874: <dd>Reference run in diagnostics mode.  xft05, slot 5 problem no longer present.  xft05, slot 7 still there. 
 
<dt>Run 220881, 220884: <dd>Swapped XTRP cables between slots 7 and 11 at SLAM end.  The "xft05, slot 7" problem stays 
with XTRP board.  Also pick up some new error associated with XTRP databoard 6 (now connected to xft05, slot 7): 
a problem with a phi bit on chips 0, 2, and 4.  I reseated the connector at the xft05, slot 7 (connected now to 
XTRP 6) and this new problem went away.  This rules out the SLAM as a source of this problem. 
 
<dt>Run 220888: <dd>Swapped the XTRP cables at the XTRP end between databoards 5 and 6.  The "xft05, slot 7" problem 
stays with the XTRP board.  This rules out the cable as a source of this problem. 
 
<dt>Run 220895, 220896: <dd>Put the SLAM cables back.  Swapped the XTRP data boards 5 and 6.  We get 4 problems now: 
<ul> 
<li>  <b>Problems 1 and 2:</b> xft05, slot 5, chips 6, 8, 10 (short bit stuck high) and chips 7, 9, 11 (pt 5 stuck high) 
<li>  <b>Problem  3:</b> xft05, slot 7, chips 6, 8, and 10: pt bit 3 stuck high 
<li>  <b>Problem  4:</b> xft05, slot 11, chips 1, 3, and 5, pt bit 2 stuck low. 
</ul> 
Problems 1 and 3 had not been seen before and went away when I reseated the XTRP cable in xft05, slot 7 and 
Chris reseated the XTRP databoards.  Problem 2 is the same problem in xft05, slot5 that we wanted to diagnose 
but couldn't because it disappeared when we started the diagnostic runs.  Problem 4 is the problem that used to 
be on xft05, slot 7 and moved when Chris swapped the databoards.  This suggests that this last problem was 
related to the XTRP. 
</dl> 
<p>Unfortunately, the xft05, slot 5 problem remains a mystery.  It doesn't seem likely to be an XTRP data board 
problem because it persisted after a databoard swap.  Unfortunately, we cannot verify whether it was a SLAM or 
cable problem because it wasn't present during some of our other swaps.  As I understand it, this problem is 
consitent with a loss of connection on the XTRP (because the output is high, right?). 
 
<p>At this point, because we'd burned enough luminosity, we gave the crates back to the shift crew and let them 
carry on with the errors as they are.  I actually haven't stopped to check whether what we saw in the last 
diagnostic run carried over to data taking.  I think Chris was looking at that.  Perhaps he will comment. 
 
<p>Additional information at: 
<ul> 
<li><a href="http://glast2.mps.ohio-state.edu/lannon/10">Detailed problem list</a> 
<li><a href="http://glast2.mps.ohio-state.edu/lannon/11">XFT to XTRP map</a> 
</ul>
<!-- Author: K.Lannon -->


<!-- Date: Thu Aug 3 15:22:26 2006 -->
Ran a long capture test XTC->SF-Wire on the entire system today during the access.  No errors.  The relevant part of the output is:<br> 
<pre><F> Iterations: 173 Errors: 0 
<T> Thu Aug 03 15:18:44 CDT 2006</pre>
<!-- Author: Jon Wilson -->


<!-- Date: Thu Aug 3 18:02:35 2006 -->
<h3> SLAM to XTRP Work </h3> 
 
<p>After working for a long time, we made all the problems that we could find go away.  For more details, see   
<a href="http://glast2.mps.ohio-state.edu/lannon/13">here</a>
<!-- Author: K.Lannon, J.Efron, C.Marino -->


<!-- Date: Mon Aug 7 16:27:22 2006 -->
<pre>The St. Finder firmware has been updated with v7r1 (Finder FPGA) ,  
and v6r0 (Pulsar FPGA). The hardware settings for St. Finder were updated to reflect these changes. We took a test run, did a few HRRs and rebooted the crates from the Run Control. The crates are given back to the Control Shift Crew now.</pre>
<!-- Author: Andrew Aron Alison -->


<!-- Date: Tue Aug 8 13:57:40 2006 -->
<pre>I just added to the XFT howto page instructions for running an XTC to SF capture test, and for programming the Stereofinders by using JTAG.  They are items 17 and 18 under "XFT Hardware FAQ".</pre>
<!-- Author: Jon Wilson -->



<!-- Date: Fri Aug 11 15:09:22 2006 -->
<pre>I ran some tests using the old Corelis software on the axial finders in tstxft1.  The results are in the ~cdf_xft/corelis_logs.  13 or 24 is superlayer, and then the next two digits are the serial number of the finder. 
 
The serial numbers I tested, and the text from any stickers on them, are: 
 
27 SL 1/3 no sticker 
06 SL 1/3 Passed Input capture & finder-linker | error light on in normal design 
18 SL 1/3 bit errors?         Finder chip dead? 12 Jun 05 
04 SL 1/3 no sticker 
02 SL 1/3 bad? 31 Jul 06 NK 
31 SL 1/3 no sticker 
 
07 SL 2/4 no sticker 
32 SL 2/4 no sticker 
05 SL 2/4 WH Teststand use 
01 SL 2/4 no sticker 
23 SL 2/4 Problem with 1 miss SL4 chip? 
03 SL 2/4 (not a sticker) This is Nils' spare that he brought me to test. 
</pre>
<!-- Author: Jon Wilson -->


<!-- Date: Thu Aug 17 13:43:56 2006 -->
I started testing of the spare Finders today.  Result: 6 with known problems and 8 that need to be tested with beam.
<!-- Author: Nils -->


<!-- Date: Thu Aug 17 13:44:57 2006 -->
<pre>I loaded a new deadwire list provided by Bob Wagner.  It contains dead wires for the stereo SLs.  In addition I masked the fibers that were braking the one finder chip.</pre>
<!-- Author: Nils -->


<!-- Date: Sat Aug 19 17:38:02 2006 -->
<p>Loaded all SLAM boards with the following firmware: 
<ul><li>SLAM_2108_odd_3416.pof 
<li>SLAM_2008_even_3416.pof 
</ul> 
<p>This has a fix for the small bug in the fiber clocks and the tracklist fiber output firmware.  I checked this firmware with two different sets of patterns (bunch 0 and 1) using the linker no beam diagnostic firmware.  There were a small rate of stuck B0Marker bits in xft01, slots 19 an xft03, slot 19 with bunch 0, but we've seen strange effects like that before when doing certain linker diagnostic patterns.  I'm declaring this a success, although we'll have to watch what happens when the store goes in.
<!-- Author: K.Lannon -->
<!-- Comment: Sat Aug 19 20;24;35 comment by...K. Lannon -->
During Cosmic runs, the stuck B0 problem was much worse than in testing.  Note, the cosmic runs were taken with the COT off, so all linker chips were sending "no track".  Although this wasn't a critical problem, I switched the two problem boards to pass through just to keep the shift crew from having to deal with the errors.  The errors went away when I put the crates in pass through.

<!-- Comment: Sat Aug 19 22;12;44 comment by...Jonathan Efron  -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>If you use a slam passthrough design, it is vital to change the axial pipeline length by one unit lower.  If you use the passSlam.sql script, this is done automatically.  

If the change is not made, the readout will be 132 ns off and the wrong information will be associated by chip.</pre></td></tr></td></table>


<!-- Date: Sun Aug 20 23:06:32 2006 -->
<pre>I switched XFT 01 , slot 11 to passthrough mode version 3416  
at 10:30 pm 8/20/06, for runs &gt;= 221806. 
 
In the next data run 221808, the largest  
XTRP errors are ~ 2% (7/400 events).  
 
So passthrough mode (or a butterfly flapping its wings in Japan)  
has gotten rid of the 10% errors.  
</pre>
<!-- Author: Ben Kilminster -->


<!-- Date: Mon Aug 21 14:38:19 2006 -->
<pre>I loaded a new firmware into the Finders on Saturday.  Here are a few lines of SQL that came handy on the occasion: 
 
select CR_CRATENAME, SLOT, STEREOFIRMWAREIDA, STEREOFIRMWAREIDB  from CARDS where CARD_TYPE='XFTSTEREO' and CR_CRATENAME like 'XFT_FINDER_%'; 
 
update CARDS set STEREOFIRMWAREIDA = -2013039564, STEREOFIRMWAREIDB = -2013039308 where CARD_TYPE='XFTSTEREO' and CR_CRATENAME like 'XFT_FINDER_%' and slot &gt; 2 and slot &lt; 9; 
update CARDS set STEREOFIRMWAREIDA = -2013039404, STEREOFIRMWAREIDB = -2013039276 where CARD_TYPE='XFTSTEREO' and CR_CRATENAME like 'XFT_FINDER_%' and slot &gt; 8 and slot &lt; 15; 
update CARDS set STEREOFIRMWAREIDA = -2013039372, STEREOFIRMWAREIDB = -2013039116 where CARD_TYPE='XFTSTEREO' and CR_CRATENAME like 'XFT_FINDER_%' and slot &gt; 14 and slot &lt; 21; 
</pre>
<!-- Author: Nils -->


<!-- Date: Wed Aug 23 18:32:15 2006 -->
<pre>We have loaded all the XFT slam boards with new version 2008. 
This firmware decouples clocks on the input and output,  
and also has some longer latch times to try to avoid errors from  
signal edges. 
 
This firmware also features a L2 output on fiber 7A.  
 
First,  we tested this version on 3 boards known to have ~10% error rates. 
We saw that the error rate reduced to 0/500 events on all but one board.   
On this board, one of the segments had as error rate of 2/500.    This is  
run 221918. 
 
This error rate we deemed acceptable, and we then load all the slam boards  
with this version. 
 
The next run was 221920.  Here on TrigMon the largest error rate is 60/1800. 
This is for board xft05, slot 19.   
 
The next biggest errors are 45/1800 on xft01, slot 9. 
 
We are investigating these errors offline to detemine if they are the type which  
create tracks, destroy tracks, or alter tracks. 
</pre>
<!-- Author: Ben & Jonathan & Jason -->



<!-- Date: Wed Aug 23 20:28:08 2006 -->
<pre>&lt;pre&gt;Here are the significant errors in run 221920 in order of errors seen, they correspond with the errors on the Consumer plots: 
 
 
xft05  slot 19 chip 1  7c0-&gt;5c0 (pt bit 6) in the linker-&gt;slam connection 
 
xft01  slot 9 chip 1  7c0-&gt;5c0 (pt bit 6) in the linker-&gt;slam connection 
 
xft01  slot 11 chip 7  7c0-&gt;7e0 (pt bit 2) in the linker-&gt;slam connection (error takes a no track to an undefined track) 
 
xft03  slot 15 chip 7,9,11  7c0-&gt;7c2 (phi bit 2) in the slam-&gt;xtrp connection  (pin error only one of this type seen.) 
 
 
xft01  slot 11 chip 7  7c0-&gt;7e0 (pt bit 2) in the linker-&gt;slam connection (error takes a no track to an undefined track) 
 
we were able to fix the major error on xft05 slot 19 by switching the dipswitch settings to default design 
&lt;/pre&gt; 
</pre>
<!-- Author: Jonathan Efron -->
<!-- Comment: Wed Aug 23 23;13;32 comment by...Jonathan Efron  -->
<pre>I finally was able to fix the error on xft01 slot 9 chip by switching the dipswitch settings.</pre>


<!-- Date: Wed Aug 23 23:19:06 2006 -->
<pre>For the slam flash ram version 200a/210a the new slampipelength is 0x270272</pre>
<!-- Author: Jonathan Efron  -->


<!-- Date: Thu Aug 24 16:34:42 2006 -->
Today I swapped the transition board in b0cot01 and loaded firmware v7r3 into the Finders.
<!-- Author: Nils -->


<!-- Date: Thu Aug 24 17:07:51 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-413&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-413' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-414&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-414' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-415&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-415' width='300'></a></center>
<!-- Author: Peter Wilson -->


<!-- Date: Thu Aug 24 17:16:38 2006 -->
<p> A series of Scope screen captures of CDF_CLK in the linker crates as seen with a differential probe on the backplane.  The top trace is the trigger which is form a PECL reciever chip inserted in the back of slot 2 of B0XFT01. </p> 
 
<p> Left: CDF_CLK at slot 11 in each of the crates showing that the signal shape is very similar in the 3 crates.</p> 
 
<p> Middle: Zoom in on slot 11 traces showing that crate to crate variation in clock edge time is very small (<1ns). </p> 
 
<p> Right: CDF_CLK at slots 3, 11 and 19 in crate b0xft05.  This shows skew accross the crate which is approximately 7ns total.  This is typical.</p> 
 
<p> No evidence of a clock problem in the Linker crates</p>
<!-- Author: Peter Wilson -->


<!-- Date: Tue Aug 29 19:59:14 2006 -->
<pre>Jonathan and I updated the SLAM to a new version -- design 200B and 210B. We think this new version will improve linker --&gt; Slam --&gt; xtrp communication. 
</pre>
<!-- Author: Jason -->


<!-- Date: Wed Aug 30 00:14:54 2006 -->
<pre>Design 200b did not work. Here are some brief comments: 
 
Errors between the linker and slam tend to be in two types: 
 
1) 7c -&gt; 7e (note that 7e is an invalid track pt). These used to be the dominant source of error. In 200b they're only runner up to the second kind of error 
 
2) 7c -&gt; 5c (1.7 GeV track). These are the errors that pile up in linker chip one using the 200b design.  
 
The increase in type two errors is why I chose to move the firmware back to 200a from 200b. Data taking with 200b at low luminosity did not create fatal problems. But these are the kinds of errors that could lead to problems, especially at high luminoscities. I didn't feel comfortable leaving this buggy design in for the next store. We should be able to learn a lot from the data we have. 
</pre>
<!-- Author: Jason -->


<!-- Date: Thu Aug 31 02:09:44 2006 -->
<pre>Tonight we tested designs 200C and 200D  
 
200D produced a large amount of errors when I put it in xft05 slot 5.  
 
200C produced no errors at all in xft 03 slot 9 
 
I put 200C in all boards and I'm running with beam to see what kinds of results I get.  
 
Right now I see several tracks where the pt bits are stuck, ie 0x7c --&gt; 0x7e. At track of 0x7c is 'no pt', a track of 0x7e is 'invalid pt'. I don't think there's a distinction between the two. I'm waiting for more statistics to see if this is the only kind of error we see. If it is and the trigger remains unaffected by it then I will leave 200c in the boards.</pre>
<!-- Author: Jason -->


<!-- Date: Thu Aug 31 04:13:07 2006 -->
The 200c design is roughly equivalent to the 200a design. The main difference is the rate of bit errors of the form 0x7c --> 0x7e. 200c has a higher rate of these kinds of errors. I decided to switch boards back to 200a since 200a has a smaller overall error rate.  
 
Currently, all crates are loaded with the 200a design. 
 
plots and slamchecker logs can be found (with comments) 
<a href="http://glast2.mps.ohio-state.edu/slaunwhj/74">here.</a>
<!-- Author: Jason -->


<!-- Date: Thu Aug 31 17:54:40 2006 -->
Installed a new deadwire list that I generated from data.
<!-- Author: Nils -->


<!-- Date: Fri Sep 8 17:47:31 2006 -->
<pre>In crate xft03, slot 13, we removed board 22 and put in board 20.  This was to solve a problem with a single bit on a single fiber.  
 
We've tested the new board with the XTRPTEST run configuration. There was no beam in the machine and the COT was off. The test told us that there were no errors between this board and the XTRP for empty tracks. 
 
We also ran XTRPTEST with the linker diagnostic design. We see no errors between the linker and the slam, or between the slam and xtrp for 50k events. This means the board we have in the system now is at least as good as the old board. 
 
We're waiting for data to find out if the fiber transmission problem we were trying to address was resolved by the swap.</pre>
<!-- Author: Jason, Kevin, and Brian -->
<!-- Comment: Sat Sep  9 08;21;41 comment by...Brian -->
<pre>Check of Trigmon this morning seems to indicate that the single bit problem is nolonger present. So swapping this board seem to do the trick.  Board 22 should go back to OSU for diagnosis of this bit problem (simple inspection of the board did not reveal anything)</pre>


<!-- Date: Mon Sep 11 17:08:24 2006 -->
<pre>Brian and I are trying a "200F" design in the even boards. We are hoping this design will clean up the &lt;a href="http://glast2.mps.ohio-state.edu/slaunwhj/060908_095514/XFT_9-8.pdf"&gt;fiber pipeline&lt;/a&gt; problems we see in the even boards. 
 
We've run for ~15 minutes (no silicon) and Trigmon tells us the new design looks better in xft03 slot 05. We didn't get to run as quick as we wanted because the COT tripped during CLC repairs. 
 
We've uploading all *even* boards with the 200F design right now. 
</pre>
<!-- Author: Jason -->
<!-- Comment: Mon Sep 11 17;26;16 comment by...Jason -->
<pre>Even upload failed. We're upload all boards. It's longer than we want but we're confident we'll see a change.
</pre>

<!-- Comment: Mon Sep 11 17;49;23 comment by...Jason -->
<pre>We ended up hardwiring the upload. It took all of our time but it worked. The new design is in there. I'm carrying the XFT pager if there are any problems. 

</pre>

<!-- Comment: Tue Sep 12 08;27;56 comment by...Brian -->
<pre>Checking TrigMon this morning shows that the firmware change was successful. All the errors on SL3 Fiber A are gone!</pre>



<!-- Date: Tue Sep 19 18:57:49 2006 -->
<center><a href='/elog/notebooks/xft/Tue_Sep_19_2006_185535.ps'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-417' ></a><a href='/elog/notebooks/xft/Tue_Sep_19_2006_185552.ps'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-419' ></a></center>
<!-- Author: Jason. Plot on the left is Stereo Finder to slam problems from 9/11/2006. Plot on the right is problems from tonight. Nils and I looked at this too see if the recent firmware change in the finders was causing an problems.  -->
<!-- Comment: Tue Sep 19 19;02;10 comment by...Jason -->
<pre>xft05 slot 5 is having serious finder communication issues (on the order of 0.2 problems per event). It looks like these problems have been persisting for ~ 1 week. Maybe new slam firmware will fix it. I have a new version to try this evening.

</pre>


<!-- Comment: Wed Sep 20 11;38;48 comment by...Jonathan Efron  -->
<pre>It seems that when I changed the timing dipswitch settings on b0xft05 slot 5, I miswired the fibers.  I fixed the problem before the new store on September 20th.  </pre>
<!-- Date: Wed Sep 20 00:34:40 2006 -->
<pre>Starting to test the 2010 SLAM firmware. We hope this will resolve some of our low-level problems.</pre>
<!-- Author: Jason -->
<!-- Comment: Wed Sep 20 02;11;13 comment by...Jason -->
<pre>The test went well.

* No increase in linker -&gt; slam errors in this new version

* No increase in stero finder -&gt; slam errors

* No decrease in errors either -- xft05 slot 5 is hosed for finder communication

* The XSLD monitor confirmation bit sim plot is now completely full of errors. We need to move to a SlamMacro that grabs slope info.

* I paged silicon and asked them if we could include SI in the run again.

I'll double check this in the morning and see that things still look ok.</pre>


<!-- Comment: Wed Sep 20 12;57;19 comment by...Jason -->
<p>Everything looks great for <a href="https://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER=223369"> run 223369</a>. xft05 slot 05 even looks better this run... but I'm still skeptical that the new firmware fixed that problem.</p> 


<!-- Date: Tue Sep 26 18:40:45 2006 -->
<p>We updated the SLAM firmware to version 2011/2111.  This is the version which uses (hopefully) the correct slope definition for low pt stereo confirmation.  We tested the linker->slam->XTRP transmission and found no errors (aside from an XTRP error which has nothing to do with the SLAM). 
 
<p>Additionally, we updated the SLAM GUI to better handle loading even and odd firmware designs.  The changes have been committed to CVS and will be propagated to the default version as soon as I coordinate that with Jay. 
<br>
<!-- Author: K.Lannon, J.Efron, J.Slaunwhite -->


<!-- Date: Wed Sep 27 15:32:02 2006 -->
<pre>&lt;p&gt;&lt;b&gt;XFT Linker Crate Trouble&lt;/b&gt;&lt;/p&gt; 
&lt;p&gt;We had trouble with xft01, xft03, xft05. They would fail config and refuse to be sheparded by the run control of the daq ace. I took them into a seperate run control and and they passed all transitions just fine. Run control did not display the vxterminal login to the crates -- it looked like it couldn't connect, but then the shepard succeeded. I power cycled the crates and had the daq ace restart RC. Things look ok now.&lt;/p&gt;</pre>
<!-- Author: Jason -->


<!-- Date: Thu Sep 28 20:07:01 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-421&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-421  width='300' align='top'></a></td><td>I updated the calibrations of the tim bins of the XTCs in the hardware database.  This should fix the inefficinecy in COT01 slot06.</td></tr></table>
<!-- Author: Heather -->


<!-- Date: Tue Oct 17 15:23:43 2006 -->
<pre>I tried to take calibration runs with the cot tdcs and xtc2's using Matthew Jones setup. I tried two runs: 225821 had only COT00 and 225288 included all the COT crates. I think no hits were recorded in the COTD and XTCD banks, so we will probably need to try the test again tomorrow. The purpose is to calibrate the xtc's without needing beam data. </pre>
<!-- Author: Heather -->


<!-- Date: Fri Oct 20 12:13:36 2006 -->
<pre>I updated the time bin edges in the XTC2s based on a calibration run (run 225288).  These will take effect with a "refresh from hardware database".  This should be done before taking real physics 
data. This is the first time we have tried to use the COT-XTC calibration (as opposed to real beam data) to set the time bin edges of the XTC's.</pre>
<!-- Author: Heather -->


<!-- Date: Sun Oct 22 19:22:21 2006 -->
<p>I swapped the stereo finder in C3P0 slot 10 with the XFT06 slot 18. Nils did a checkout. It looks like to swap resolved problems that we saw in a particluar trigmon plot. I'll post a link to the plot later.</p>
<!-- Author: Jason -->
<!-- Comment: Sun Oct 22 19;43;06 comment by...Jason -->
<p>Here is the <a href=
'/cgi/elog/elog.pl?nb=2006&action=view&page=790&frame=2&anchor=09:35:13.715'>
trigmon plot </a> that indicated a problem with slot 18.</p>


<!-- Date: Thu Oct 26 09:09:30 2006 -->
<center><a href='/elog/notebooks/xft/Thu_Oct_26_2006_090841.ps'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-423' ></a><a href='/elog/notebooks/xft/Thu_Oct_26_2006_090853.ps'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-425' ></a></center>
<!-- Author: Jason, COT plots since Bob Wagner lowered COT voltages -->
<!-- Comment: Thu Oct 26 09;39;52 comment by...Jason -->
<p>Bob Wagner <a href=
'/cgi/elog/elog.pl?nb=2006&action=view&page=801&frame=2&anchor=07:07:46.034'>
lowered COT voltages:</a>  "...so we added an extra supply for SL4, S3 quadrant D. We are now running S3 in quadrant D 110 volts low."</p>

<p>Bob translated this for me. I masked wire 3 in SL4 Cells 215 to 287. This is the last quarter of cells in SL4.</p>

<p>I'm waiting how the change impacts the plots. I'll post new plots when they're available.


<!-- Date: Thu Oct 26 10:02:17 2006 -->
<table><tr><td><a href=/elog/notebooks/xft/Thu_Oct_26_2006_100209.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-427  align='top'></a></td><td>This plot shows that the occupancy in CDF Phi > 275 has increased. This is exactly the phi region where we saw a dip in the previous run. The plots confirms that the changes I made got propogated into the system.  
<br> 
The L1 trigger rate is 25 KHz @ a luminosity of 73e30.</td></tr></table>
<!-- Author: Jason -->


<!-- Date: Mon Nov 6 19:12:05 2006 -->
<p><b>New Firmware version 0x2023</b></p> 
 
<p>Tonight, we did the following:</p> 
<ul> 
<li>I loaded version 0x2023 into the slam boards. This version requires that both slope bits be set for high-pt tracks.</li> 
 
<li>We ran cosmics for 15 minutes. There were almost no 4 layer tracks. But there weren't any meltdowns of the data path.</li> 
 
</ul> 
 
<p>Tomorrow we expect to see a store early in the day shift. We plan to do the following:</p> 
 
<ul> 
<li>Run for 1 hour at the start of the store with "all files to look area".</li> 
<li>If design 0x2023 does not prevent data taking then run with it for the rest of the store.</li> 
<li>At the end of the store change back to design 0x2011.</li> 
</ul> 
 
<p>Jonathan Lewis made special arrangements for the XFT diagnostic banks to be read out on the high-pt electron triggers. </p>
<!-- Author: Jason -->


<!-- Date: Tue Nov 7 12:48:12 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-428&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-428  width='300' align='top'></a></td><td><p><b>Firmware test during store 5052</b></p> 
<ul> 
<li>Plot on the left shows that the new design doesn't set the confirm bit as often, ie, tighter requirements.</li> 
<li>No additional communication errors in trigmon</li> 
<li>Great so far, we'll keep taking data. All of store 5052 is ours.</li> 
</ul></td></tr></table>
<!-- Author: Jason  -->


<!-- Date: Tue Nov 7 16:42:00 2006 -->
<pre>&lt;p&gt;I updated the dead wire list. The only new dead wire in SL4 is &lt;/p&gt; 
 
&lt;p&gt;&lt;code&gt;superlayer 4 cell 266 wire 3&lt;/code&gt;&lt;/p&gt;</pre>
<!-- Author: Jason -->
<!-- Comment: Tue Nov  7 16;42;34 comment by...Jason, again, this time w. html -->
<p>I updated the dead wire list. The only new dead wire in SL4 is </p> 
 
<p><code>superlayer 4 cell 266 wire 3</code></p>


<!-- Date: Wed Nov 8 09:48:10 2006 -->
<h3>Problems with flashram loading</h3> 
 
<p>We had problems with b0xft05 slot 19 flash reprogramming</p> 
 
<ul> 
<li>The reprogramming said it was successful in xftdaq</li> 
<li>When we read back the flashram version number it said it returned nonsense, like 0 or 30fe </li> 
<li>I suspected the crate controller was in a funny state. I tried reseting the crate with <code>vxlogin; reboot</code> and then <code>reset_crate</code>. That didn't work</li> 
<li>If the problem persisted after a crate reset then it was problem a hardware-level problem. So I decided to reseat the board and see if the problem went away. I reseated the board. when I came upstairs and read all the flash ram versions, slot 19 had the appropriate version.</li> 
</ul> 
 
<p>Conlusion: it looks like the gibberish coming from the flashram register was just readout gibberish. The board was successfully reprogrammed. Reseating the board in the crate solved the problem</p>
<!-- Author: Jason -->


<!-- Date: Wed Nov 8 16:53:13 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-429&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-429' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-430&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-430' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-431&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-431' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-433&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-433' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-434&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-434' width='300'></a></center>
<!-- Author: Heather -->
<!-- Comment: Wed Nov  8 17;02;51 comment by...Heather -->
<pre>Top left plot shows inefficiencies, particularly in COT01 Slot6, COT10 Slot 13, COT 16 Slot 10.  Also, there is some inefficiency in COT09 slot3.  The rest of the plots show the time bin information in each crate.  Top middle plot shows the timing is off COT01 Slot6 in a way we have seen before.  Bizarre behavior ensues for the top right plot, which is for COT09, where slot 3, time bin 5 is off by 10 ns.  Additionally, the bottom left plot is for COT10, where Slot 3 has time bins 3-5 off by about 16 ns.  The bottom right plot is for COT16, where Slot 10 is off by about 17 ns in time bin 5.  

We can not completely recalibrate the latter 3 slots because they are so far off. Instead, we have recalibrated by 7 ns for these slots and will see how things look.  We will check when we have more data whether this helped and by how much, and recalibrate again, if necessary.  </pre>


<!-- Date: Fri Nov 10 09:45:40 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-435&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-435  width='300' align='top'></a></td><td>I put in new XTC calibrations based on run 227554.  Asked Jason to "refresh from hardware data base" to pick up these calibrations.</td></tr></table>
<!-- Author: Heather -->


<!-- Date: Mon Nov 13 15:55:20 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-437&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-437' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-438&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-438' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-439&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-439' width='300'></a></center>
<!-- Author: Heather -->
<!-- Comment: Mon Nov 13 15;59;02 comment by...Heather -->
<pre>For run 227782, the xtc timings are still at -7 ns for COT10 slot 13 bins 3-5 and COT16 slot10 bin 5.  Since we are having trouble getting the timings back to "normal" over the last several days, I have put in the default timings into all XTC cards.  When we have enough data (at the end of the store) I will recalibrate based on these default timings rather than the run configuration for run 227782.</pre>


<!-- Date: Tue Nov 14 08:29:10 2006 -->
<pre>I recalibrated the XTC time bins based on data in run 227808.  We want to understand why the following slots have some time differences &lt; -7 ns for some time bins: 
 
cot09, slot  3 
cot10, slot 13 
cot16, slot 10 
</pre>
<!-- Author: Heather -->


<!-- Date: Tue Nov 14 18:09:21 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-440&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-440' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-441&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-441' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-442&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-442' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-443&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-443' width='300'></a></center>
<!-- Author: Heather -->
<!-- Comment: Tue Nov 14 18;13;51 comment by...Heather -->
<pre>cot09, slot  3, bin 5 is off by -5 ns
cot10, slot 13, bin 3-5 is off by -6 to -7 ns
cot16, slot 10, bin 5 is off by -8 ns

It is unclear why this is the case.  The calibrations from earlier should have set these to +9ns.  I'm trying one more time to calibrate out this problem.  If it does not work, then we will need to switch out the xtc cards.  </pre>


<!-- Date: Mon Nov 20 14:50:48 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-444&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-444' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-445&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-445' width='300'></a></center>
<!-- Author: Heather -->
<!-- Comment: Mon Nov 20 14;54;06 comment by...Heather -->
<pre>I recalibrated the timings of the XTC2 cards primarily for the inefficiency seen in COT01 Slot6.  It seems that whenever there is a power glitch or power cycle, this card gets out of time.  I believe this card has been changed so I do not know what the problem is.</pre>


<!-- Date: Sun Dec 3 10:20:42 2006 -->
Loaded the new firmware version from the secondary finder flashram.  However they will not power up with that version, so we will have to load it into the primary flashram at some point.
<!-- Author: Nils -->
<!-- Comment: Mon Dec  4 17;23;19 comment by...Nils -->
<pre>To complete this:  I loaded version 1.0 in the secondary flashram, while the primary flashram contains the version 7.7.  The only difference is how they deal with the L2 part (hopefully).</pre>

<!-- Comment: Mon Dec  4 17;24;12 comment by...Alison -->
<pre>New firmware versions for the stereo finders are: v1r0 for the L1 chips and v7r0 for the L2 chip. Preliminary results show that the new firmware does not affect in any way the L1 path. The L2 path seems to be greatly improved with repect to previous versions but still a few bugs need to be fixed.</pre>


<!-- Date: Mon Dec 4 17:25:33 2006 -->
<pre>Current XTC problems.  We currently have three XTCs that are suspected to cause problems downstream: 
COSWT-3 slot 18 (SL6, cell 152-159): Rev C 
COSWB-1 slot 12 (SL6, cell 232-239): Rev C 
COSWT-3 slot 8 (SL2, cells 84-91): Rev C 
 
I will try to swap them before leaving for christmas.</pre>
<!-- Author: Nils -->


<!-- Date: Tue Dec 5 18:03:26 2006 -->
<pre>Store 	5106 used the "dual slope" Slam configuration algorithm in all but one board (b0xft01 slot 13).  This configuration should reduce the efficiency and fake rake of the CMX trigger</pre>
<!-- Author: Jonathan Efron  -->


<!-- Date: Tue Dec 5 23:29:19 2006 -->
We finally managed to install a new TrigMon version in the control room (thanks to Kevin, Heather and Kaori).  The great new features are the incorporation of the dead wire list and the ability to turn plots with too many errors red.  This last feature is intended to make the life of the CO much simpler.  Unfortunately this is currently still in the tuning phase, and sensitive to statistical fluctuations for at least the first hour of each run.<p/> 
 
So if anybody sees the plots turn red, don't panic, but don't ignore them either.  Check whether the error rate is consistent with a single event error (a cell can have up to 12 errors in a single event).  
<!-- Author: Nils -->


<!-- Date: Wed Dec 6 14:45:28 2006 -->
<pre>5th december 10pm: Swapped cards between XFT06 and XFT07. The slots we switched were 5,9 and 18. The problems we were seeing appeared in crate 7 slot 9 and crate 6 slot 5 and 18. 
Overnight: took data with new cards in 
Today: saw that swapping slot 9 between crates moved the problem to the other crate -&gt; Likely to be a problem with the board. 
Aron and I switched out slots 9 and 18 from crate 6 with cards from the test crate (not using the SL5 card which we think might have problems). Marked those boards bad for L2. 
With next store will will be able to tell if problems have gone away or not. 
Problems with slot 5 only appeared later in the store and were not found in the 3000 events available. We left that board as is.</pre>
<!-- Author: Alison -->


<!-- Date: Wed Dec 6 17:11:06 2006 -->
Since the problem we were seeing with xft06 slot 18 did not move away with the finder (i.e. the problem persisited when the finder from xft07 slot 18 was put into xft06 slot 18), we will also try swapping out the transition board. 
In particular, I swapped the transition board in xft06 slot 18 with the transition board in c3po (test crate) slot 10.  Since xft06 was power-cycled for this work, I re-downloaded the L1 firmware from the second flashRAM.
<!-- Author: Aron -->


<!-- Date: Thu Dec 7 15:16:27 2006 -->
<pre>Swapping the finders and swapping the transition boards did not solve the problems for the 2 remaining slots (5 and 18 in crate 6). 
The problem in slot 9 is fixed (new board). 
Next idea: mask on some wires in the DeadWireList.txt 
Nils explained how it worked and we masked off: SL3 cells 224-231 (all 12 wires) and SL7 cells 8-15. 
Restarted the run and problems with SL3 slot 5 did not appear again (but always would appear only after a certain amount of time). 
Problem with SL7 slot 18 did not go away but rate seems to be lower. 
Masked off SL7 cells 0-7 for next run but only 600 events in that run and no problems seen anywhere. Waiting for more data to see if problem persists or not.</pre>
<!-- Author: Alison + Nils -->


<!-- Date: Thu Dec 7 22:29:39 2006 -->
I swapped the XTCs in b0cot06/12, b0cot05/08 and bocot05/18.  I removed the corresponding channels from the dead wire list.
<!-- Author: Nils -->


<!-- Date: Fri Dec 8 10:28:33 2006 -->
Swapped the finder in b0xft04 slot 5 in an attempt to fix a problem in the error plot.
<!-- Author: Nils -->


<!-- Date: Fri Dec 8 10:48:01 2006 -->
<pre>The problems with SL3 slot 5 crate 6 is back. 
I changed the DeadWireList.txt file to remove the old masked cells (224-231) and masked off different ones (216-223). This could solve the problem. 
Conclusion: need LOTS of statistics and higher lumi to see if this problem comes back again or not. 
Next time the run is re-started the changes should be incorporated.</pre>
<!-- Author: Alison -->
<!-- Comment: Fri Dec  8 10;50;23 comment by...Alison -->
<pre>Maybe run 229763 but maybe not. Hard to tell who won betwen the database upload and the run being re-started. I think I got there in time but not sure...</pre>

<!-- Comment: Fri Dec  8 10;58;15 comment by...Alison -->
<pre>Problem appeared after run 229759, activated at 8.02 AM. Maybe this is the problem Nils has just been fixing (see main e-log)</pre>

<!-- Comment: Fri Dec  8 14;10;35 comment by...Alison -->
<pre>Run 229763 did not have previous corrections to dead wire list I don't think (still errors).
Run 229764 does have changes and there are no errors again over 2800 events.
Check again at high lumi next store.</pre>


<!-- Comment: Mon Dec 11 14;30;48 comment by...Alison -->
<pre>Store 5115: inital lumi 74e30 (low initial lumi).
First run (229877) no errors over 2560 events.</pre>
<!-- Comment: Mon Dec 11 14;44;20 comment by...Alison -->
<pre>tore 5116: inital lumi 120e30 (still pretty low).
First run (229928) no errors out of 2460 events.</pre>
<!-- Comment: Tue Dec 12 08;56;48 comment by...Alison -->
<pre>Store 5118: initial lumi 166e30 (high enough!)
First run (230005) no errors out of 2400 events.</pre>
<!-- Comment: Tue Dec 12 13;50;30 comment by...Alison -->
<pre>Store 5188:
Runs 230007, 230008, 230009, 230010 all show no errors over ~2500 events in the look area.
I declare that we are sure about which XTCs need to be changed and that I am sure that my code seems to be doing the right thing!</pre>
<!-- Date: Fri Dec 8 20:13:29 2006 -->
Removed the one masked XTC in SL2 from the deadwire list.  Apparantly that problem was solved, when I swapped the Finder.
<!-- Author: Nils -->


<!-- Date: Sat Dec 9 12:15:46 2006 -->
I now loaded version 1.0 into the primary flashram of the stereo finders.  This is the version, we have already been using for a little while, and now it will finally be the default on power up.
<!-- Author: Nils -->




<!-- Date: Mon Dec 11 19:01:17 2006 -->
<pre>Checked T2FD vs TP2D data banks (finders vs pulsar banks): 
After accounting for "known" differences (header and trailer structure as well as unused bits in mask section) no differences were found.  
These plots will allow us to de-bug any potential problems between the finders and the pulsars.</pre>
<!-- Author: Alison -->


<!-- Date: Mon Dec 11 21:56:51 2006 -->
We swapped the two offending TDCs in SL6, unfortunately that didn't solve our problem there.
<!-- Author: Nils -->




<!-- Date: Tue Dec 19 09:51:13 2006 -->
<p>New TrigMon error thresholds in XSFMonitor and XSLMonitor.  I think these are more reasonable: 
 
<p>XSFMonitor 
<ul> 
<li> scaleErrorXTCD_XSFD: 5e-2 (was 1e-4) 
<li> scaleErrorDataSim: 1e-2 (was 1e-4) 
</ul> 
 
<p>XSLMonitor: 
<ul> 
<li> scaleErrorPixel: 1e-2 (was 1e-4) 
<li> scaleErrorTrack: 1e-2 (was 1e-6) 
<li> scaleErrorConfirm: 1e-2 (was 1e-6) 
</ul> 
 
<p>In fact, all except the XTCD_XSFD error canvas rarely gave errors, even with the extremely tight thresholds given.  There is some strange behavior where I frequently see the XTCD_XSFD error canvas reading >= 2% errors.  I'm not sure if this is a problem.
<!-- Author: K.Lannon -->


<!-- Date: Tue Dec 19 19:23:39 2006 -->
<H2> Dual Slope firmware test</H2> 
 
<p> Today I am testing version 2024/2124 of the SLAM firmware.  This is the version that has the "dual slope" confirmation with a restricted pt range.  Before my test, the SLAM boards were running version 2011/2111. 
 
<p> Steps taken: 
<ol> 
<li> Request crates from shift crew and book. 
<li> Start 3 separate xftdaq windows to load firmware in b0xft01, b0xft03, and b0xft05 separately.  Note:  xftdaq in the cdf_xft account was broken so I had to use a private version (source code matches what is in the head of CVS). 
<li> Update the Hardware database using the fullSlam_dualhighptOff.sql script in ~cdf_xft/oracle. 
<li> Start a "dual slope off" test run (230593).  Dead time ~ 1.5% at start. 
<li> TrigMon crashes with SVTSim error.  Suspect missing silicon is to blame.  Disable SVTSim and SVTDMonitor and restart.  Works. 
<li> With 200 events observe error rate of ~ 1.5%. 
<li> End run to go to dual slope "on" configuration. 
<li> Update the Hardware database using the fullSlam_dualhighpt.sql script in ~cdf_xft/oracle. 
<li> Start new run with dual slope "On" (230594).  Dead time ~1% at start.  Observe TrigMon error rate of ~ 5% after 700 events. 
<li> Undo changes to TrigMon tcl and have CO try to figure out why it wasn't running in the first place. 
<li> Inform shift crew to leave this configuration to end of store. 
</ol> 
 
<p>In the first run (230593) I saw a ratio of regular "3D" CMX trigger to regular CMX triggers of 306/441 ~ 69%.  In the second run, I saw a ratio of "3D" CMX triggers to regular CMX triggers of 200/354 ~ 56%.  So, I conclude that the dual slope was (probably) only enabled for the second run, as expected. 
 
<p> I will leave the XFT in this configuration and return at store termination to put it back to the default firmware/DB settings. 
<!-- Author: K.Lannon -->


<!-- Date: Tue Dec 19 21:46:30 2006 -->
<H2>Conclusion of Dual Slope Test</H2> 
 
<p> I am now back returning the SLAM to its original configuration, taking the following steps: 
<ol> 
<li> Took linker crates from shift crew. 
<li> Started downloading firmware version 2011/2111 using three separate xftdaq windows as before. 
<li> Ran the fullSlam.sql script in ~cdf_xft/oracle to return the hardware DB to the default settings. 
<li> Test crates through config and activate and see no errors. 
<li> Return crates to shift crew. 
<li> Verify in TrigMon that there are no XFT errors (through 100 events). 
</ol> 
 
<p>The crates have been returned to the shift crew.  The following runs were taken with the dual slope firmware:  
<ul> 
<li> Run 230593 -- Dual slope bit set to "off" 
<li> Runs 230594, 230595 -- Dual slope bit set to "on" 
</ul> 
 
<p> SLAM returned to default configuration as of run 230599.
<!-- Author: K.Lannon -->


<!-- Date: Thu Jan 4 15:08:31 2007 -->
<pre>Here are some notes on the spec for the way that L2 stereo information is 
to be stored in the XTRP part of the TL2D bank.  Ultimately, this 
information should go into CDF note 4152.  The bits are to go into the 
match word that corresponds to each track (for simplicity, we will not 
touch the unused bits that are part of the actually track word).  The 
values of z5 and cotan(theta) are each stored as 10 bits.  The first 9 
bits of each are used for the absolute value (encoded as an integer) and 
the 10th bit is set to 1 if the number is negative.  The bit assignment is 
as follows: 
 
   0     Stereo algorithm attempted 
   1     Stereo track found in L2 
   2:10  Integer-encoded absolute value of z5 
   11    sign of z5 
   12:20 Integer-encoded absolute value of cotan 
   21    sign of cotan 
 
For z5 the resolution is estimated to be 1 cm, so the minimum step size is 
taken to be 0.5 cm.  The maximum value of z5 could be 122 cm. 
 
The encoding (float-&gt;integer) is: 
  coded_z5 = int(abs(z5)/0.5 + 0.5) 
  and 10th bit is set to 1 if sign(z5) is negative 
 
The decoding (integer-&gt;float) is: 
  if (coded_z5 & 0x200) { // z5 is negative 
    z5 = -(float)(0x1FF & coded_z5) * 0.5; 
  } else { 
    z5 = (float)(0x1FF & coded_z5) * 0.5; 
  } 
 
 
For cotan(theta) the resolution is estimated to be 0.1, but we have extra 
bits, so use a minimum step size of 0.005.  The maximum value of 
cotan(theta) could be around 1.85 given the COT geometry. 
 
The encoding is: 
  coded_Cotan = int(abs(cotan)/0.005 + 0.5) 
  and 10th bit is set to 1 if sign(cotan) is negative 
 
The decoding (integer-&gt;float) is: 
  if (coded_Cotan & 0x200) { // cotan is negative 
    xftCotan = -(float)(0x1FF & coded_Cotan) * 0.005; 
  } else { 
    xftCotan = (float)(0x1FF & coded_Cotan) * 0.005; 
  } 
</pre>
<!-- Author: Aron -->


<!-- Date: Thu Jan 18 14:26:11 2007 -->
<pre>I updated the dataio fpga firmware in the b0l2pu02 slot 10 (tracklist A pulsar) to version 0xb4611220. </pre>
<!-- Author: Heather Gerberich -->
<!-- Comment: Thu Jan 18 16;35;44 comment by...Heather -->
<pre>I also changed the fibers connected to pulsar A to the original fibers xft01 slot 17 to xft05 slot 7.</pre>


<!-- Date: Fri Jan 19 17:28:30 2007 -->
<pre>Between the store test:  Tried to put in tracklist pulsar B in slot 12 to test the dataio fpga firmware for both tracklist pulsars in b0l2pu02.  Wanted to use XFT crates to send diagnostic tracks to pulsars.  Test unsuccessful.  When trying to take a run got timeout errors for b0l2pu02 related to slot 12:  
 
state HaltRecoverRun 1 crate/s: b0l2pu02(151),  Done TO. [RXPT]  
 
(MLE) b0l2pu02:Messenger:Jan 19, 2007 04:42:49 PM-&gt;PULSAR VME bus Error slot=12 reading L2 buffer 0 
bytes=4 (384) (18)  
</pre>
<!-- Author: Heather Gerberich -->


<!-- Date: Sun Jan 21 19:16:56 2007 -->
<pre>In-between-store tracklist board test (repeating test from Friday): Put second pulsar in slot 12 of b0l2pu02. Put XFT crates in diagnostic mode. Sent fake tracks from xft crates to tracklist pulsars in slot 10 and 12. Looked like we successfully read data on all 4 dataio fpga's. Also took a couple runs with control fpga readout turned on and will look at these more closely later.  
 
This test was much more successful that Friday's test. I attribute this to Christopher Marino seating the board in slot 12 of b0l2pu02 for me (as he told me that he has above average muscular capabilities). However, other changes include me explicitely initializing the board in slot 12 and changing the cardEditor BASE entry from empty to -1.  
 
</pre>
<!-- Author: Heather -->


<!-- Date: Thu Jan 25 13:13:42 2007 -->
<br> 
I installed the Pulsar Merger into the slot 12 of b0l2pu02 and replaced the Aux card for the XFT Pulsar in slot 6 (XFT01). The data from the XFT01 is now duplicated with the second output connected to the Pulsar Merger.  
<br> 
In the next end of store test this will allow us to measure the actual timing between the L1Accept and the time the L2PC gets the data in.   
<!-- Author: Andrew -->
<!-- Comment: Thu Jan 25 13;30;12 comment by...Andrew -->
Don't forget to issue:
<br>
./vxwritereg b0l2pu02 12 0x0 0x18 0xe
<br>
before the test. That disables mezzannine cards 2,3 and 4.


<!-- Date: Sat Feb 3 00:01:07 2007 -->
<pre>I attempted to perform the XFT fiber test to send data from tracklist pulsar B to pulsar A.  I used the xft crates in diagnostic mode to send tracks to the tracklist pulsars A and B.    
 
 
It looks like some data was transmitted from pulsar B to pulsar A, but it does not look right (will have to study more closely).  Will need to perform diagnostic tests.</pre>
<!-- Author: Heather -->


<!-- Date: Mon Feb 5 18:59:03 2007 -->
<pre>Regarding possible reason for Stereo tracks not being confirmed as often as we like: 
We want to totally eliminate the possibility that the data is out of sync: 
 
 
Aron and I have just sat for a while looking into all the  possibilities and drawing nice diagrams (with pink fluorescent pen even!) 
 
We concluded the following: 
1) The "bunch counter" information in the 1st word of the finders in the T2FD bank has no relevance to the "real" bunch counter (not shifted by a digit or anything) 
-&gt; Give up on comparing to T2FD 
 
2) A quick comparison to the XSFD bank shows that the XSFD and the TL2D bunch counters agree 
-&gt; We know that the data is in sync between the Finders and the Muons in the L2 PC 
 
3) We used to know (next investigation is the TrigMon problems induced by either my code or a real problem) that the T2FD and TP2D info were exactly the same. We still know that XSFD and T2FD agree (with a few exceptions where XSFD goes wrong, but 1 event out of 40'000 appeared in the TrigMon plots) 
-&gt; If TP2D is in sync with the Muons in the L2 PC 
 
4) The Muons in the L2 PC are in sync with the main TL2D bank 
-&gt; Event is all in sync wrt muon path 
 
Conclusions: 
a) The data is in sync between the TP2D and the muons in the L2 PC 
-&gt; That's not our problem 
 
b) There could still be an "out of sync" issue between the XFT  
Pulsars and the muons in the L2 PC 
-&gt; Andrew claims his code checks for this internally and would spit out an error if they were out of sync 
-&gt; I would like (just to be 100% sure) to print out the bunch counters for XFT01, 02 and 03 in the next round of tests 
-&gt; Andrew says he's already implemented it and I'll wait for the next data and look at the words directly after the Muon bunch counters 
 
So I think progress has been made on this front but there's still 1 final step to really close up that possibility. Hopefully will be done with the next set of data. 
 
Next test: check that my TrigMon code which is spitting out errors between the TP2D and the T2FD banks is doing that for no reason</pre>
<!-- Author: Alison + Aron -->


<!-- Date: Tue Feb 6 11:40:55 2007 -->
<pre>Run: 233028: No L2 PC information but Pulsar merger board in. 
Ran over all data in SAM:  events 
The run covered a large range in instantanious luminosity from about 184e30 down to 101e30 
 
Below are enclosed the plots for the timing in bins of 0.1 micro-sec. 
The first is a simple histogram 
The second shows the timing as a function of instantanious luminosity and size of the T2FD bank (which gives and idea of the occupancy of the event). 
 
The instantanious lumi plot is cut off at top sorry... 
 
Looks like the timing is independent of luminosity and occupancy.</pre>
<!-- Author: Alison -->


<!-- Date: Tue Feb 6 15:52:01 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-446&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-446' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-447&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-447' width='300'></a></center>
<!-- Author: Alison -->
<!-- Comment: Tue Feb  6 17;02;52 comment by...Alison -->
<pre>There's a mistake in theway the values are loaded, rounded down to the nearest int, hence the discreet binning. Will re-make plots soon.</pre>


<!-- Date: Thu Feb 15 14:10:50 2007 -->
The techs swapped two TDCs on Tuesday (cot09 slot13 & cot08 slot07).  The board in cot09 was previously masked high in the Finder due to problems with L2.
<!-- Author: Nils -->


<!-- Date: Wed Feb 28 18:12:17 2007 -->
 
 
   <h4>     The breakthrough in the L2 XFT commissioning </h4> 
 
    Yesterday we made one of the major breakthroughs in our quest of solving a long list of problems arisen during the L2 XFT commissioning.  <br><br> 
    We have been struggling for a few weeks now attempting to understand why the online stereo reconstruction disagreed with the offline simulation. We managed to build the offline executable based on the online library, and verified that the online software is doing stereo track reconstruction correctly so that results were in agreement with the offline simulation. We suspected that the data received  by the L2 PC was somehow not in-sync with the track information, and have performed series of L2 XFT parasitic runs with additional debugging information included into the TL2D bank. We appended a part of the XFT segments data received by the L2 PC into the output packet, and were surprised to see that the data seemed to be in-sync and was exactly as what it was supposed to be. Then we tried to verify that the data passed into the algorithms was consistent with the input XFT data as well as with what goes into the output bank. We proved that it was the case, which made the situation very confusing.   <br><br> 
    That was a conundrum: the software worked offline and returned the correct results, while online it lived its own life. Part of the problem involved in the debugging was due to the fact that unless our L2 PC was included into the data taking, the data was always going to be out-of-sync, and the stereo reconstruction should have obviously failed. That could be immediately seen since the slam confirmation bit almost always should match L2 stereo reconstruction bit. 
However, if it was included into the data taking, we couldn't do much debugging because too many printout statements into a log would cause L2 time-outs and would adversely affect the CDF data operation.<br><br> 
     While we were thinking on what minimum information we need to include into the next test, so that it would be maximally useful to locate the source of the problem, an ace issued the HRR. Our data was in-sync with the rest of the CDF data for the first few events, and luckily we had sufficient debugging information to see that the stereo reconstruction WORKED for the first few events, but started failing even before the data went out-of-sync. At that point we immediately knew where to look for a bug in the software. <br><br> 
      The L2 Stereo code requires a multi-layer unpacking. First we unpack the data received by each Pulsar, and find pointers to each Finder for each event. Next, during stereo track reconstruction we unpack the relevant Finder data (corresponding to 30deg slice in phi), and find pointers to more detailed phi-pixel and slope information. To avoid unpacking the same Finder data again, in case we need to reconstruct another track nearby, we stored that information. However, we forgot to reset it when we proceeded to the next event.<br><br> 
     That was obviously a silly bug, but especially difficult to find. On the other hand have anybody encountered *smart* bugs? <br><br> 
     We fixed the code and asked the ace to issue an HRR again, and we saw right away that the stereo reconstruction was working properly for all of the events being in-sync. We requested the L2 XFT parasitic run and later confirmed that the online stereo reconstruction is now working correctly. <br><br>
<!-- Author: Andrew Ivanov and Rob Forrest -->


<!-- Date: Fri Mar 2 10:30:44 2007 -->
Perform the XFT fiber test to send data from tracklist pulsar B to pulsar A.  I used the xft crates in diagnostic mode to send tracks to the tracklist pulsars A and B.    More Information  <a href= 
'http://www-cdfonline.fnal.gov/cgi/internal/elog/elog.pl?nb=2007&action=copyentry&page=182&time=09:40:34.121'> here </a>.  Things look ok except control A for all 7c track events.  Keeping pulsar B in slot 12 in case they let us have an end-of-store readout test. 
 
<p> Also performed L2Torture test with all readouts turned on.   Run  <a href= 
'http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER=235475'> 235475 </a>.  No significant change in deadtime from normal L2 Torture test. 
 
<p> Keeping pulsar B in slot 12 for end-of-store readout test. 
<!-- Author: Heather -->


<!-- Date: Sat Mar 10 09:03:30 2007 -->
<pre>Between-store test:  Tried new control A tracklist firmware (b5703090) which addresses zero-track events (all tracks are pt=0x7c).  Used XFT linker crates to send diagnostic tracks to b0l2pu02.  Scan of a few events shows that data (with or without tracks) in control A fpga looks good for about every other event.  Will need to investigate further this new feature of no data for every other event. 
 
Have turned off control A readout and Pulsar B readout.  Returned fibers to andrew's pulsars.</pre>
<!-- Author: Heather -->


<!-- Date: Wed Mar 14 14:45:21 2007 -->
<pre>Tuesday 6th March: New version of the TrigMon module installed in the control room. Additional modules for XFT L2 timing added and bugs fixed in old version.</pre>
<!-- Author: Alison -->


<!-- Date: Wed Mar 14 16:02:16 2007 -->
Run <a href='http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER=236517'> 236517 </a> was taken with the tracklist readout turned on.  Deadtime according to the ace was normal.  L2PULSAR_XFT_00, 01, 02 in b0l2pu02 were not included in this run due to time-out issues.  Look area file data looks great.  Will look at data in sam for more statistics.
<!-- Author: Heather -->


<!-- Date: Sat Mar 17 13:24:52 2007 -->
<pre>I put SVT_Slink_Source firmware into PUlsar A.  Sent diagnostic SVT events from b0l2pu05 (diagnostic crate) to SVT.  Data was received and checked to be correct.  Could not send diagnostic tracks from b0l2pu02, presumably because there is no clock and we would have needed to use run control. 
 
I put in the normal control A firmware and returned the pulsar to b0l2pu02 and ran a diagnostic run. It looks good, so I think the board is properly seated.</pre>
<!-- Author: Heather -->


<!-- Date: Sun Mar 18 16:21:39 2007 -->
Stefano and I did an end-of-store test where we connected the tracklist board to the SVT to receive tracks (rather than SVT receiving tracks from XTRP).  This is run <a href='http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER=236762' > 236762 </a>.   
 
<p> We find that the events get to SVT about 2 microseconds faster than from XTRP.   
 
<p> However, we also find that there are errors ~2% of the time.  1.2% of the time, the data delivers more tracks to the SVT than the SVT expects.  0.6% (or 0.06% --not sure which one) the track parameters are different than expected.  This needs to be understood. 
 
<p> The XTRP cable was reconnected to the SVT and SVT looks fine.
<!-- Author: Heather -->


<!-- Date: Tue Mar 27 12:16:36 2007 -->
<pre>Between store test: installed new firmware in tracklist pulsar A. Ran diagnostic test sending XFT tracks linkers to b0l2pu02 tracklist boards. Looks good... Going to include this crate in the next store.</pre>
<!-- Author: Heather -->


<!-- Date: Fri May 18 12:39:53 2007 -->
<pre>The XTC card on COT04 Slot15 was replaced during the access on Wednesday May 16.  The slot was giving us lower efficiency.  I checked for the run today and it looks better.</pre>
<!-- Author: Heather Gerberich -->


<!-- Date: Mon May 21 11:33:35 2007 -->
<p>There was a hole in the SL2 occupancy for the axial finder.  When we were finally paged for this (after an entire store had already basically passed), we tried the following action to fix it: 
 
<ul> 
<li> Identified the bad board as xft02, slot 8, cot SL2, cells 44-51.  Masked these channels on in the dead wire tool.  Started a new run.  The hole remained (and no extra spikes) so masking didn't seem to help.  As far as I can tell from looking at the HWDB, the masking should have worked, so it looks like the masking didn't work. 
<li> While I was driving in, Jonathan and Jonathan swapped XFT finder #10 in for #14 in slot 8 of xft02.  The made sure to change the jumper setting to match the old board.  After making this swap, nothing changed in the XFT monitoring plots.  At this point, there's no evidence that there's anything wrong with Finder #10, so we put it back in the spares cabinet. 
<li> On Nil's advice, we tried power cycling COTSWT-1 (b0cot03) to see if this fixes the problem.  It did not. 
<li> Currently, we are in access, swapping the TDC in slot 8 in b0cot03.  This is the board that Nils thinks is causing the problem. 
</ul>
<!-- Author: K.Lannon -->


<!-- Date: Wed May 23 20:21:56 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-448&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-448  width='300' align='top'></a></td><td>Since yesterday morning we observed problems in the L2 path of 2 of the finders: Crate 6 slot 15 and crate 7 slot 20. 
These are the problems we observe in run 242354. Sorry about the colours, could not get gStyle to work for some reason today.</td></tr></table>
<!-- Author: Alison -->


<!-- Date: Wed May 23 20:23:20 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-449&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-449  width='300' align='top'></a></td><td>We then tried to mask on some XTCs with Nils that seemed to be related to the problems we were seeing. Some of the problems went away for 1 of the boards but not the "edges". For the other board, the problems stayed.</td></tr></table>
<!-- Author: Alison -->


<!-- Date: Wed May 23 20:25:30 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-450&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-450' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-451&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-451' width='300'></a></center>
<!-- Author: Alison -->
<!-- Comment: Wed May 23 20;26;56 comment by...Alison -->
<pre>We (Aron and I) then swapped the boards with the spare ones in the test-stand. These boards are BAD both for L1 and L2!
 These plots correspond to the T2FD bank comparison (left) and XSFD bank comparison (right) for the 2 finder boards.
We didn't have any more spares around!!!!!!!</pre>


<!-- Date: Wed May 23 20:28:19 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-452&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-452  width='300' align='top'></a></td><td>We then put the "L2 bad" borads back in the system (at least they seem to be fine for L1). We put them back in a different slot: were xft6 slot 15 and xft07 slot 20, now xft6 slot 16 and xft07 slot 19.</td></tr></table>
<!-- Author: Alison -->
<!-- Comment: Wed May 23 20;30;20 comment by...Alison -->
<pre>The problem came back in the same place as before
-&gt; Not a problem with the boards
-&gt; Must be something to do with XTC but can't mask any more on still leaving 1 per XTC unmasked
-&gt; No idea what to do....
-&gt; Why don't we have any working spare finders????
-&gt; This is halting our L2 progress that we don't have any spares...
-&gt; Tomorrow I look in more details hopefully with Nils</pre>


<!-- Date: Sat Jun 2 23:15:46 2007 -->
<p>As requested by the shift crew, I have masked on in the dead wire database COT SL7, cells 208-215.  Apparently, there is a dead TDC corresponding to those cells.  As far as I can tell, the masking worked, although it's not easy to see.  I see that according to the history, I did modify the dead wire words for the expected stereo finder and when I look in the expert only trig mon plots, I can see a hole in XTCD plot with a corresponding spike in the XSFD plot.<br><br>  
<!-- Author: K.Lannon -->
<!-- Comment: Mon Jun  4 19;54;53 comment by...Jonathan Efron -->
<pre>The TDC was replaced (fixed) and I removed these cells from the dead wire list.</pre>

<!-- Comment: Wed Jun  6 00;07;13 comment by...Heather -->
<pre>The timing was off with the new TDC-XTC combination by about 4 ns, so I updated the calibration.  This should take effect in the next store (after run 242890).  The runs before this are good, this will just make the efficiency a little better.</pre>


<!-- Date: Wed Jun 6 22:05:58 2007 -->
<pre>Because Andrew and Alison relocated the tracklist boards from slots 10 and 12 to 16 and 18, I did some tests sending diagnostic tracks from the Linker boards to the tracklist boards.  The first tests showed that the boards were not configured properly.  I edited and tested the fer code for setting the registers.  The tracklist boards will now be configured properly after this new code is put online.  I then did another diagnostic run (243020) which I will analyze more thoroughly to ensure that everything is working properly.  The tracklist boards should still work in a run, but they will not process the complete track list.</pre>
<!-- Author: Heather -->


<!-- Date: Fri Jul 20 14:54:00 2007 -->
<pre>Updated XTC2 time bin edge calibrations based on run 245375.</pre>
<!-- Author: Heather -->


<!-- Date: Tue Oct 30 13:58:18 2007 -->
<pre>updated XTC reference histograms to allow for inefficiencies.   
Most of these inefficiencies seem to be coming from COT TDC drift 
time, not from XTC2 calibration issues.  These include Cot03 slots 
9,17; Cot11 slot12; Cot14 Slot 12; Cot15 Slot9; Cot 18 Slot13.  I 
came to these conclusions using this COT Calibration file:  
/cdf/onln/data/cdfcalib/log/runCotCtt_3_2007-10-30_08:14:30.log 
 
We may need to recalibrate some other slots: Cot01 slot6,  
Cot04 Slot15, Cot07 Slot18, Cot09 Slot13.  But we are studying 
more before we do so.</pre>
<!-- Author: Heather -->


<!-- Date: Wed Nov 7 17:18:18 2007 -->
<pre>I changed the XTC2 time bin edges for COT01 Slot6, COT04 Slot15, and COT09 Slot13.</pre>
<!-- Author: Heather -->
<!-- Comment: Wed Nov  7 17;19;40 comment by...heather -->
<pre>These were based on run 253196.  The others were kept as calibrated using run 245375.</pre>


<!-- Date: Fri Nov 9 11:26:16 2007 -->
<pre>We masked on 4 fibers from b0xft06 slot 4 (cells 192-207). 
Jonathan had swapped the XTCs (but not TDCs) on Wednesday but this did not seem to fix the problem with the L2 path in the finder. 
</pre>
<!-- Author: David, JDL, Alison -->


<!-- Date: Mon Nov 12 10:30:16 2007 -->
<pre>At the end of last week we masked on 2 XTCs.  
Over the weekend we saw that the problem with the finders getting out of sync had gone.  
I just unmasked 1 of the XTCs and we will keep an eye out to see if the problem comes back or not.  
Currently SL 3 cells 192-199 are masked on (200-207 are the ones I just unmasked).  
This should not cause operational problems as L2Stereo is still ignored from Run Control.</pre>
<!-- Author: Alison -->


<!-- Date: Mon Nov 12 10:59:59 2007 -->
<pre>I calibrated the time bin edges for COT17 Slot13 using run 253677.  </pre>
<!-- Author: Heather -->


<!-- Date: Fri Nov 30 13:43:50 2007 -->
<pre>Yesterday Koji installed the new XTCDMonitor which reads in the  
COT_T0 offsets from a file.  The XTC2 efficiency is now calculated 
taking this into account.   
 
Based on run 254553, which had this new monitoring, I updated the 
XTC2 time bin edges in the database.  This will take effect for  
runs greater than 254572.</pre>
<!-- Author: Heather -->


<!-- Date: Fri May 30 12:59:58 2008 -->
<pre>I changed the register address xx00060 in TracklistControlA (parameter SVTFILTERSETTING in cardeditor) to 1.  This should send only tracks with pt&gt;2 GeV to the SVT.</pre>
<!-- Author: heather -->
<!-- Comment: Fri May 30 13;14;53 comment by...Heather -->
<pre>Run 262823 is the first run with this configuration.</pre>


<!-- Date: Wed Jun 11 14:58:22 2008 -->
<pre>COT08 Slot13 has been masked on since November due to problems with the L2 path.  I unmasked the XTC and still saw &lt;a href='http://www-cdfonline.fnal.gov/cgi/internal/elog/elog.pl?nb=2008&action=copyentry&page=488&time=14:21:41.393'&gt; problems &lt;/a&gt;.  See other entries from day shift today for more info.  After the test, I masked the XTC back on.</pre>
<!-- Author: Heather -->
<!-- Comment: Wed Jun 11 15;03;21 comment by...Heather -->

HTML Version:  COT08 Slot13 has been masked on since November due to problems with the L2 path.  I unmasked the XTC and still saw <a href='http://www-cdfonline.fnal.gov/cgi/internal/elog/elog.pl?nb=2008&action=copyentry&page=488&time=14:21:41.393'> problems </a>.  See other entries from day shift today for more info.  After the test, I masked the XTC back on.


<!-- Date: Fri Aug 22 15:53:52 2008 -->
<pre>I masked on the following wires due causing slightly low XTC2 efficiencies: 
5  233 7 
7  385 0 --&gt;already masked on 
7  261 4 
7  262 2 
7   16 7 
 
The first 4 are associated with a behavior where the first time bin 
is fired too late.  ie.. at low leading times, late time bins are 
turned on. </pre>
<!-- Author: Heather -->


<!-- Date: Fri Aug 22 17:40:30 2008 -->
<pre>I recalibrated the XTCs based on run 266303.  I'm a little concerned about Cot12 Slot10 in run 266405, so I did not use that run.  It is the first run that I see this strange behavior.  I'll wait until the next store to see what this XTC looks like.</pre>
<!-- Author: Heather -->


<!-- Date: Mon Sep 8 14:57:14 2008 -->
<pre>We swapped b0xft06 slot 19 with slot 18. 
Slot 19 was showing bunch counter mistmatches at L2 but the L2 data agreed with the L1 data. 
We want to see if the problem moves with the board is stays with the slot. 
Slot 18 was a good one. 
 
After rebooting the crate, the firmware did not load properly for slot 7 (SL3). Re-downloading the firmware to the chip then shepherding the crate worked.</pre>
<!-- Author: David Cox + Alison  -->


<!-- Date: Tue Sep 23 10:56:34 2008 -->
<pre>b0xft06 slot 18 finder swapped with spare. 
Firmware downloads without problems. 
Shepherd once then take ~2000 events of shot setup without problems. 
We'll keep an eye on it during the beginning of the store.</pre>
<!-- Author: David / Alsion -->


<!-- Date: Tue Sep 30 10:27:16 2008 -->
<pre>I changed to using XFT 4 for data taking instead of XFT 3. I also swapped the sequence entries in the hardware database for the two pulsars.</pre>
<!-- Author: David -->


<!-- Date: Fri Oct 3 13:48:31 2008 -->
<pre>The PC is currently taking data from the XFT 4 pulsar. A test run showed no TrigMon difficulties.</pre>
<!-- Author: David -->


<!-- Date: Sun Oct 12 11:58:32 2008 -->
<pre>Per email from Bob Wagner, I made the following changes to the DeadWireList:  
 
Masked on:  
- SL8 cell 142 S11  
- SL3 cell 218 S7   
 
Unmasked:  
- SL2 cell 27 S0 to S10   
- SL2 cell 65 S11  
- SL5 cell 318 S9 and S10   
- SL8 cell 34 S0 to S3  
 
 
</pre>
<!-- Author: Heather -->
<!-- Comment: Sun Oct 12 12;08;59 comment by...Heather -->
<pre>Also, yesterday during a shot setup run (268119) there were 
problems for L2 during a shotset run for SL3, Cells 200-207,
so these channels are masked back on.  This corresponds to 
COT08 Slot13.  Jonathan had swapped this tdc-xtc pair with the in
in COT08 Slot14 on October 8,2008.  The problem stayed with the
slot

Note: We expected this since this issue has never proven to be
an XTC problem, but we had to do the check since there was no 
clear documentation provided by L2 XFT people about whether the 
problem started before or after October 15, 2007, when Jonathan
swapped the TDC for other reasons).</pre>

<!-- Comment: Sun Oct 12 21;11;43 comment by...Heather -->
<pre>In data, we had to also mask on SL3, Cells 192-199, corresponding
to COT08 Slot14.  Will need to check if the L2 problem exists
if SL3, Cells 200-207 are unmasked.  Maybe it did move with the
xtc-tdc...  Or we now have problems in the entire region.</pre>

<!-- Comment: Mon Oct 13 09;39;44 comment by...Heather -->
<pre>I unmasked SL3 Cells 200-207.  So far there are no errors in  
'1.5.1.3: XFT T2FD vs XSFD' plot.  This indicates that the L2
 problem moved with the board from Cot08 slot13 to Cot08 slot14.
This is odd because during shot setup run 268119, the errors seemed
to be in the Cot08 slot13 slot, and after I masked it on, the
errors went away.  However, we seem to run fine with this tdc/xtc
unmasked.</pre>

<!-- Comment: Mon Oct 13 09;41;25 comment by...Heather -->
<pre>Remasked
- SL8 cell 34 S0 to S3  

per Bob Wagners email.
</pre>


<!-- Date: Mon Oct 13 13:46:38 2008 -->
<pre>Tested spare XFT stereo finders. 
 
Were unable to take data with the SL3 Finder. L2 PC timeout waiting for XFT 1. At the finder the SEL READY LED was not lit. 
 
No problems observed with the SL5 Finder.</pre>
<!-- Author: David / Will -->


<!-- Date: Mon Nov 3 14:03:31 2008 -->
<pre>Swapped XFT pulsar -&gt; merger/PC inputs.  
 
XFT 1 now sends its merger inputs to where XFT 3 was. (XFT_2_2).  
XFT 3 now sends its merger inputs to where XFT 1 was. (SLINK_1_1).  
XFT 4 now sends its merger information via the slave output.  
XFT 4 now sends its information to the PC via the 2nd master output (was the 1st).  
XFT 4 now sends information to the Spare PC via the 1st master output (was the slave output).</pre>
<!-- Author: David Cox -->
<!-- Comment: Mon Nov  3 14;55;40 comment by...David -->
<pre>FT 4 now sends its information to the Main PC via the 1st master ouput. (was the 2nd master)
XFT 4 now sends its information to the Spare PC via the 2nd master output. (was the 1st
master)</pre>