<!-- Title: 14:04:03  Tue Apr 17 2001 -->
<!-- Crewchief: Jong-young Chung -->
<!-- Op1: Jay Dittman -->
<!-- Op2: Evelyn Thomson -->
<!-- Op3: Richard Hughes -->
<!-- Op4: Brian Winer -->
<!-- Op5: Nate Goldschmidt -->
<!-- Op6: Ken Bloom -->
<!-- Notes: -->
<pre> </pre>


<!-- Date: Tue Apr 17 14:05:02 2001 -->
<pre>       I've just looked through the error log files from the weekend, 
from 111600 to 111302.  I see 2 bunch counter mismatch errors: 
 
between finders in b0xft02 slots 13 and 8, typically 1/500,000 events (see 
3.8 million event run 111830); 
 
between finders in b0xft02 slots 4 and 9, only once in run 111217. 
 
        I don't see any other errors, except in run 112020 where b0xft02 
failed with error code 10, which means a finder download error.  But it 
looks like another coldstart solved the problem: 
 
CT: 4/14/2001, 4:25'39" 
Partition:1 Run number: 112020 (0x1b594) 
(MLE) b0xft04:Messenger:4:26:38 AM->Setup failed with error code 10 
(MLE) b0xft04:Messenger:4:26:38 AM->Setup failed with error code 8 
(MLE) b0xft04:Messenger:4:26:38 AM->Statechange failed 
(RC) Config -> READY  <---Another coldstart??? 
(RC) Activate -> ACTIVE 
 
        ------------------------------------------------------- 
 
        I also looked at the TrigMon output.  On Friday April 13th, I see 
many errors in runs 111936 and 111941 for linker in b0xft03 slot 12 IF 3 
RAM 1 and IF 4 RAM 0 (finder chips 4a' and 4b'), where many extra bits are 
observed.  I don't see any problems in runs from 16/17th April.  Was some 
work being done around this linker at that time?  Cables plugged, 
unplugged? 
 
        I also see 1 error where a finder misses 3 pixel bits, that are 
expected from the simulation: 
 
111941/743 COSET-1 b0cot13 19 A b0xft02 17 4A 1 0000 0000 0000 0000 S 
111941/743 COSET-1 b0cot13 19 A b0xft02 17 4A 1 0000 0000 0000 0111 R 
111941/743 COSET-1 b0cot13 19 A b0xft02 17 4A 1  EWB            XXX A 0000 
0000 0000 0111 D 
 
 
and 2 errors in b0xft03 slot 14, where bit 4 is lost - Jong-young can you 
swap this board to another slot in b0xft03 to see if the error is 
slot-dependent? 
 
112294/1694 b0xft03 14 IF4 0 WORD 0 FINDER CHIP 4B' CELL 3 1111 1111 1111 F 
112294/1694 b0xft03 14 IF4 0 WORD 0 FINDER CHIP 4B' CELL 3 1111 1110 1111 L 
112294/1694 b0xft03 14 IF4 0 WORD 0 FINDER CHIP 4B' CELL 3         L      D 
112294/1694 b0xft03 14 IF4 0 WORD 1 FINDER CHIP 1A' CELL 3 1111 1111 1111 F 
112294/1694 b0xft03 14 IF4 0 WORD 1 FINDER CHIP 1A' CELL 3 1111 1110 1111 L 
112294/1694 b0xft03 14 IF4 0 WORD 1 FINDER CHIP 1A' CELL 3         L      D 
</pre>
<!-- Author: Evelyn Thomson -->


<!-- Date: Tue Apr 17 14:05:28 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre> 
Error logs 
----------- 
 
These are in ERRMON_LOGDIR/daq on b0dap* 
        grep -i "b0xft" 1116* | more 
allows you to narrow down to xft reports from run 111600 to 111699. 
 
 
TrigMon logs 
--------------- 
 
These are in /data1/consumer/runarea/TrigMon on b0dap* 
        more 111936XFTTrigger_Summary.txt 
</pre></td></tr></td></table>
<!-- Author: Evelyn Thomson -->


<!-- Date: Wed Apr 18 10:57:02 2001 -->
<pre>        Error files 
        ----------- 
        112380 b0xft04 slot 19 download of FPGAs failed, error code 8 
        112382 b0xft05 BC mismatch between slot 4 and 16 
        (4 events in a row so run was in myron mode) 
 
        TrigMon output 
        -------------- 
        Run 112382 lose pixel bits in several finders on 2 events 
        event  94,074: b0xft00 slots 6, 13 and 16 
        event  94,074: b0xft02 slots 5, 11, 16 and 17 
        event 853,495: b0xft00 slot 4 
 
 
        Serial number mismatch messages still there from board swaps 
yesterday - I guess the hardware database doesn't get automatically 
updated!  I'll update it now, 
 
</pre>
<!-- Author: Evelyn Thomson -->


<!-- Date: Thu Apr 19 11:23:46 2001 -->
<pre>Error files 
============== 
 
112439/373,219 b0xft02 BC mismatch between 13 and 8 
 
TrigMon files 
============= 
No errors seen!  However, sometimes the summary files show that 
0 events have gone through the XFFD and XFLD checks, while  
more than 0 events have gone through the F@L check.  Why? 
 
 
******* XFTTrigger Log File ******  
 RUN NUMBER =  112459 
 **********************************  
 **********************************  
 RUN NUMBER =  112459 
 TRGSim SUMMARY AFTER 0 EVENTS  
 **********************************  
 ********** XFFD  SUMMARY  *********** 
 **********************************  
 RUN NUMBER =  112459 
 TRGSim SUMMARY AFTER 0 EVENTS  
 **********************************  
 ********** XFLD  SUMMARY  *********** 
 **********************************  
 RUN NUMBER =  112459 
 TRGSim SUMMARY AFTER 115 EVENTS  
 **********************************  
 ********** F2L Cable  SUMMARY  *********** 
</pre>
<!-- Author: Evelyn Thomson -->


<!-- Date: Fri Apr 20 12:13:10 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-30&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-30  width='300' align='top'></td><td>Strange thing. I erased flash ram of linker #6 and download stnd1026.rbf to ram block 0 again. This changed flash ram document to "board #27 cci #65" which is one of slot 4 instead of "board # 6 cci #18"  Also you can see "is" is not there for slot 12. All other board says "board # is XX, cci # is XX" But slot 12 says     "board # XX cci # XX" </a></td></tr></table>
<!-- Author: Jong-young -->
<!-- Comment: Fri Apr 20 12;43;51 comment by...Jong-young -->
<pre>I'm sorry, Don't mind this entry.
It is because I didn't change myxft03.crate file slot 12 entry.
It was still std.nlinkerboard27,

Ignore this.</pre>


<!-- Date: Thu Apr 26 19:13:01 2001 -->
<pre>XFT -  we improved the checking of the finder and linker  
flashram design labels during a coldstart.  The checking was done  
previously but we didn't flag errors and mismatch printout only  
appeared on cpu.  This was useful since we noticed that one pixel  
chip had a version 2 design instead of a version 4 design.  This  
board was swapped in as a spare earlier this week.    
 
This code is not in the standard fer since the changes are useful  
checks but are not urgent.  We rebooted the crates so that they  
have the standard fer code loaded, then took several  
coldstarts/runs to make sure everything still worked as before.   
 
Crates are now returned to the shift crew. 
 
The new fer code will no longer reprogram the finder FPGAs from 
the flashram.  Since there is only one design on the finder, 
reprogramming from the flashram doesn't change anything.  If the 
wrong design is in the flashram then the checks above should 
catch it and we want AN ERROR!  We have updated the standalone 
code in CVS so that after a flashram download the FPGAs are 
always reprogrammed from the flashram. 
 
The linker is still reprogrammed from the flashram since there 
are two designs in the flashram - it is possible that someone 
could download the diagnostic design from block 1 and then go 
away....in this case we want to download from the block with the 
standard design.  We maybe don't need to do this every time -  
there is register on the board which tells us which block we used 
to download the board, but that seems too clever and 
complicated to put into code...</pre>
<!-- Author: Evelyn Thomson and Jong-young Chung -->


<!-- Date: Fri Apr 27 15:41:26 2001 -->
<pre>There are two "hot" spare finders in b0xft06 if needed: 
 
    b0xft06 11   IDPROM = 0014 050 Finder SL 1/3 Ver. 4.0 
    b0xft06 13   IDPROM = 0031 051 Finder SL 2/4 Ver. 4.0 
 
The flashrams have the appropriate 3-miss designs. 
</pre>
<!-- Author: Jay -->


<!-- Date: Mon Apr 30 10:43:10 2001 -->
<pre>XFT Finder BC mismatches during the first stores of 36x36: 
 
errorfile113474.log:(MLE) b0xft00:Messenger:7:33:25 PM->Event 67644: Bunchcounters in slot 13 and slot 6 disagree (at least) 
errorfile113474.log:(MLE) b0xft00:Messenger:7:33:25 PM->Runtime Error 1, Event 67644: Bunch counter mismatch, mismatch count = 1 
 
errorfile113480.log:(MLE) b0xft02:Messenger:8:33:17 PM->Event 24649: Bunchcounters in slot 13 and slot 8 disagree (at least) 
errorfile113480.log:(MLE) b0xft02:Messenger:8:33:18 PM->Runtime Error 1, Event 24649: Bunch counter mismatch, mismatch count = 1 
errorfile113480.log:(MLE) b0xft02:Messenger:8:56:58 PM->Event 154900: Bunchcounters in slot 13 and slot 7 disagree (at least) 
errorfile113480.log:(MLE) b0xft02:Messenger:8:56:58 PM->Runtime Error 2, Event 154900: Bunch counter mismatch, mismatch count = 1 
 
errorfile113483.log:(MLE) b0xft02:Messenger:10:16:33 PM->Event 284729: Bunchcounters in slot 13 and slot 8 disagree (at least) 
errorfile113483.log:(MLE) b0xft02:Messenger:10:16:33 PM->Runtime Error 1, Event 284729: Bunch counter mismatch, mismatch count = 1 
errorfile113483.log:(MLE) b0xft04:Messenger:10:11:36 PM->Event 257745: Bunchcounters in slot 13 and slot 6 disagree (at least) 
errorfile113483.log:(MLE) b0xft04:Messenger:10:11:36 PM->Runtime Error 1, Event 257745: Bunch counter mismatch, mismatch count = 1 
 
errorfile113485.log:(MLE) b0xft00:Messenger:3:34:18 AM->Event 682745: Bunchcounters in slot 13 and slot 7 disagree (at least) 
errorfile113485.log:(MLE) b0xft00:Messenger:3:34:19 AM->Runtime Error 1, Event 682745: Bunch counter mismatch, mismatch count = 1 
errorfile113485.log:(MLE) b0xft00:Messenger:3:57:17 AM->Event 807812: Bunchcounters in slot 13 and slot 11 disagree (at least) 
errorfile113485.log:(MLE) b0xft00:Messenger:3:57:17 AM->Runtime Error 2, Event 807812: Bunch counter mismatch, mismatch count = 1 
errorfile113485.log:(MLE) b0xft00:Messenger:4:32:43 AM->Event 1000805: Bunchcounters in slot 13 and slot 10 disagree (at least) 
errorfile113485.log:(MLE) b0xft00:Messenger:4:32:43 AM->Runtime Error 3, Event 1000805: Bunch counter mismatch, mismatch count = 1 
errorfile113485.log:(MLE) b0xft00:Messenger:4:53:45 AM->Event 1115236: Bunchcounters in slot 13 and slot 10 disagree (at least) 
errorfile113485.log:(MLE) b0xft00:Messenger:4:53:45 AM->Runtime Error 4, Event 1115236: Bunch counter mismatch, mismatch count = 1 
errorfile113485.log:(MLE) b0xft02:Messenger:3:19:45 AM->Event 603921: Bunchcounters in slot 13 and slot 7 disagree (at least) 
errorfile113485.log:(MLE) b0xft02:Messenger:3:19:45 AM->Runtime Error 1, Event 603921: Bunch counter mismatch, mismatch count = 1 
errorfile113485.log:(MLE) b0xft02:Messenger:3:32:47 AM->Event 674562: Bunchcounters in slot 13 and slot 10 disagree (at least) 
errorfile113485.log:(MLE) b0xft02:Messenger:3:32:47 AM->Runtime Error 2, Event 674562: Bunch counter mismatch, mismatch count = 1 
errorfile113485.log:(MLE) b0xft02:Messenger:4:21:50 AM->Event 941521: Bunchcounters in slot 13 and slot 9 disagree (at least) 
errorfile113485.log:(MLE) b0xft02:Messenger:4:21:50 AM->Runtime Error 3, Event 941521: Bunch counter mismatch, mismatch count = 1 
errorfile113485.log:(MLE) b0xft02:Messenger:4:45:06 AM->Event 1068670: Bunchcounters in slot 13 and slot 8 disagree (at least) 
errorfile113485.log:(MLE) b0xft02:Messenger:4:45:06 AM->Runtime Error 4, Event 1068670: Bunch counter mismatch, mismatch count = 1 
errorfile113485.log:(MLE) b0xft02:Messenger:4:49:45 AM->Event 1093837: Bunchcounters in slot 13 and slot 8 disagree (at least) 
errorfile113485.log:(MLE) b0xft02:Messenger:4:49:45 AM->Runtime Error 5, Event 1093837: Bunch counter mismatch, mismatch count = 1 
errorfile113485.log:(MLE) b0xft04:Messenger:1:54:23 AM->Event 218857: Bunchcounters in slot 13 and slot 10 disagree (at least) 
errorfile113485.log:(MLE) b0xft04:Messenger:1:54:23 AM->Runtime Error 1, Event 218857: Bunch counter mismatch, mismatch count = 1 
 
errorfile113486.log:(MLE) b0xft00:Messenger:6:08:52 AM->Event 210505: Bunchcounters in slot 13 and slot 9 disagree (at least) 
errorfile113486.log:(MLE) b0xft00:Messenger:6:08:53 AM->Runtime Error 1, Event 210505: Bunch counter mismatch, mismatch count = 1 
errorfile113486.log:(MLE) b0xft00:Messenger:7:14:19 AM->Event 509254: Bunchcounters in slot 13 and slot 9 disagree (at least) 
errorfile113486.log:(MLE) b0xft00:Messenger:7:14:19 AM->Runtime Error 2, Event 509254: Bunch counter mismatch, mismatch count = 1 
errorfile113486.log:(MLE) b0xft02:Messenger:6:15:13 AM->Event 240002: Bunchcounters in slot 13 and slot 6 disagree (at least) 
errorfile113486.log:(MLE) b0xft02:Messenger:6:15:13 AM->Runtime Error 1, Event 240002: Bunch counter mismatch, mismatch count = 1 
errorfile113486.log:(MLE) b0xft02:Messenger:6:30:57 AM->Event 312982: Bunchcounters in slot 13 and slot 5 disagree (at least) 
errorfile113486.log:(MLE) b0xft02:Messenger:6:30:57 AM->Runtime Error 2, Event 312982: Bunch counter mismatch, mismatch count = 1 
errorfile113486.log:(MLE) b0xft02:Messenger:7:12:49 AM->Event 503173: Bunchcounters in slot 13 and slot 7 disagree (at least) 
errorfile113486.log:(MLE) b0xft02:Messenger:7:12:49 AM->Runtime Error 3, Event 503173: Bunch counter mismatch, mismatch count = 1 
errorfile113486.log:(MLE) b0xft02:Messenger:7:13:58 AM->Event 507823: Bunchcounters in slot 13 and slot 7 disagree (at least) 
errorfile113486.log:(MLE) b0xft02:Messenger:7:13:58 AM->Runtime Error 4, Event 507823: Bunch counter mismatch, mismatch count = 1 
errorfile113486.log:(MLE) b0xft04:Messenger:5:52:59 AM->Event 138221: Bunchcounters in slot 13 and slot 8 disagree (at least) 
errorfile113486.log:(MLE) b0xft04:Messenger:5:52:59 AM->Runtime Error 1, Event 138221: Bunch counter mismatch, mismatch count = 1 
errorfile113486.log:(MLE) b0xft04:Messenger:6:44:50 AM->Event 376827: Bunchcounters in slot 13 and slot 7 disagree (at least) 
errorfile113486.log:(MLE) b0xft04:Messenger:6:44:50 AM->Runtime Error 2, Event 376827: Bunch counter mismatch, mismatch count = 1 
 
errorfile113488.log:(MLE) b0xft02:Messenger:8:05:25 AM->Event 10513: Bunchcounters in slot 13 and slot 8 disagree (at least) 
errorfile113488.log:(MLE) b0xft02:Messenger:8:05:25 AM->Runtime Error 1, Event 10513: Bunch counter mismatch, mismatch count = 1 
errorfile113488.log:(MLE) b0xft02:Messenger:8:10:56 AM->Event 36393: Bunchcounters in slot 13 and slot 7 disagree (at least) 
errorfile113488.log:(MLE) b0xft02:Messenger:8:10:56 AM->Runtime Error 2, Event 36393: Bunch counter mismatch, mismatch count = 1 
 
errorfile113499.log:(MLE) b0xft04:Messenger:12:42:39 PM->Event 34736: Bunchcounters in slot 13 and slot 9 disagree (at least) 
errorfile113499.log:(MLE) b0xft04:Messenger:12:42:39 PM->Runtime Error 1, Event 34736: Bunch counter mismatch, mismatch count = 1 
 
errorfile113500.log:(MLE) b0xft00:Messenger:1:05:16 PM->Event 48531: Bunchcounters in slot 13 and slot 6 disagree (at least) 
errorfile113500.log:(MLE) b0xft00:Messenger:1:05:16 PM->Runtime Error 1, Event 48531: Bunch counter mismatch, mismatch count = 1 
errorfile113500.log:(MLE) b0xft00:Messenger:2:55:19 PM->Event 443286: Bunchcounters in slot 13 and slot 9 disagree (at least) 
errorfile113500.log:(MLE) b0xft00:Messenger:2:55:19 PM->Runtime Error 2, Event 443286: Bunch counter mismatch, mismatch count = 1 
errorfile113500.log:(MLE) b0xft02:Messenger:1:01:18 PM->Event 30264: Bunchcounters in slot 13 and slot 8 disagree (at least) 
errorfile113500.log:(MLE) b0xft02:Messenger:1:01:18 PM->Runtime Error 2, Event 30264: Bunch counter mismatch, mismatch count = 1 
errorfile113500.log:(MLE) b0xft02:Messenger:12:56:35 PM->Event 8274: Bunchcounters in slot 13 and slot 7 disagree (at least) 
errorfile113500.log:(MLE) b0xft02:Messenger:12:56:35 PM->Runtime Error 1, Event 8274: Bunch counter mismatch, mismatch count = 1 
errorfile113500.log:(MLE) b0xft02:Messenger:1:57:39 PM->Event 223101: Bunchcounters in slot 13 and slot 8 disagree (at least) 
errorfile113500.log:(MLE) b0xft02:Messenger:1:57:39 PM->Runtime Error 3, Event 223101: Bunch counter mismatch, mismatch count = 1 
 
errorfile113508.log:(MLE) b0xft00:Messenger:5:10:25 PM->Event 235661: Bunchcounters in slot 13 and slot 4 disagree (at least) 
errorfile113508.log:(MLE) b0xft00:Messenger:5:10:25 PM->Event 235663: Bunchcounters in slot 13 and slot 4 disagree (at least) 
errorfile113508.log:(MLE) b0xft00:Messenger:5:10:25 PM->Runtime Error 1, Event 235661: Bunch counter mismatch, mismatch count = 1 
errorfile113508.log:(MLE) b0xft00:Messenger:5:10:26 PM->Runtime Error 2, Event 235663: Bunch counter mismatch, mismatch count = 1 
</pre>
<!-- Author: Jay -->


<!-- Date: Mon Apr 30 11:38:09 2001 -->
<pre>Linker Input Formatter error, 
 
run 113485, 113545, 113568 
b0xft03 6 INPUT FORMATTER 4 RAM 0  
losing bit 4 
 
 b0xft03 6 IF 4 RAM 0 WORD 0 FINDER 4B' CELL 0 0000 0011 0100 F    
 b0xft03 6 IF 4 RAM 0 WORD 0 FINDER 4B' CELL 0 0000 0010 0100 L  
 b0xft03 6 IF 4 RAM 0 WORD 0 FINDER 4B' CELL 0         L      D        
 
 b0xft03 6 IF 4 RAM 0 WORD 1 FINDER 1A' CELL 3 0000 1111 1111 F  
 b0xft03 6 IF 4 RAM 0 WORD 1 FINDER 1A' CELL 3 0000 1110 1111 L  
 b0xft03 6 IF 4 RAM 0 WORD 1 FINDER 1A' CELL 3         L      D  
 
 
/data1/consumer/runarea/TrigMon</pre>
<!-- Author: Jong-young -->
<!-- Comment: Mon Apr 30 11;44;55 comment by...Jong-young -->
slot 6 b0xft03 was swapped with slot 14 on Apr 17. (see above e-log)

So it is not slot dependent problem. it could be bad IF chip of linker #12 


<!-- Date: Mon Apr 30 15:04:41 2001 -->
<table><tr><td><a href=/elog/notebooks/xft/Mon_Apr_30_2001_150427.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-32  align='top'></td><td>Comparison of one track rate from Rn 1 minimum bias  (offline tracks, no additional smearing) with  trigger rates from Run 113500.  error bars are 30% (guess at lum error and broken bits in XTRP).</a></td></tr></table>
<!-- Author: Peter Wilson -->


<!-- Date: Tue May 1 15:19:46 2001 -->
<table><tr><td><a href=/elog/notebooks/xft/Tue_May__1_2001_151911.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-36  align='top'></td><td>After matching reconstructed tracks to XFT tracks by cutting on pt, then minimizing phi0, the top plot shows the delta-phi between the purportedly matched L3 and XFT tracks. The bottom plot shows this delta-phi vs global phi--evidence of beam spot shift.</a></td></tr></table>
<!-- Author: Erik Brubaker -->


<!-- Date: Tue May 1 15:24:14 2001 -->
<table><tr><td><a href=/elog/notebooks/xft/Tue_May__1_2001_152406.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-38  align='top'></td><td>(This entry should go before the previous one.) These plots compare XFT tracks to tracks reconstructed by the L3 modules. 17000 events were processed from run 113508. The top left plot histograms the number of tracks reconstructed per event in L3, with no cuts (clear) and for tracks > 1.5 GeV (yellow). The top right plot histograms the number of tracks found by the XFT. The bottom left plot shows the pt spectrum for the reconstructed tracks (note the bump at 1.5 GeV from trigger turn-on!) The bottom right plot shows the pt spectrum for XFT tracks, for 4-layer (yellow) and 3-layer (red) tracks. </a></td></tr></table>
<!-- Author: Erik Brubaker -->


<!-- Date: Tue May 1 15:28:25 2001 -->
<table><tr><td><a href=/elog/notebooks/xft/Tue_May__1_2001_152815.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-40  align='top'></td><td>After matching L3 reconstructed tracks to XFT tracks, this is a scatter plot of the delta phi between the two (in radians) and the fractional pt difference ((pt_XFT - pt_L3)/pt_L3). Clearly the two are correlated. The two legs of the X correspond to different signs of charge. Further improvements are being made to the matching algorithm...</a></td></tr></table>
<!-- Author: Erik Brubaker -->


<!-- Date: Wed May 2 10:16:41 2001 -->
<pre>Looking at linker #12 (IF 4 RAM 0) 
 
Using data from 36x36 
113485/162211 b0xft03 6 IF 4 R0 W1 F1A' CELL 0 0000 0011 1110 F 
113485/162211 b0xft03 6 IF 4 R0 W1 F1A' CELL 0 0000 0010 1110 L  
113485/162211 b0xft03 6 IF 4 R0 W1 F1A' CELL 0         L      D   
 
I fed it to xftdaq FtoL test. 
 
Event 1 b0xft02 6 b0xft03 6 1a'   Finder   3e    180     0    ffe   
Event 1 b0xft02 6 b0xft03 6 1a'   Linker   3e    180     0    ffe 
Event 1 b0xft02 6 b0xft03 6 1a'   Expect   3e    180     0    ffe                                  
 
I got '3e' correct value instead of '2e'. It passed xftdaq test. 
It only showed error when actual data taking.</pre>
<!-- Author: Jong-young -->


<!-- Date: Thu May 3 11:26:36 2001 -->
<table><tr><td><a href=/elog/notebooks/xft/Thu_May__3_2001_112626.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-42  align='top'></td><td>run111380, Linker track / Linker chip(288) certain linker chips has more tracks than others</a></td></tr></table>
<!-- Author: Jong-young Chung -->
<!-- Comment: Thu May  3 11;28;05 comment by...Jong-young -->
I tried to repeat Rechard's work, I got similar results
When I saw TrigMon output I couln't see such peaks.


<!-- Date: Thu May 3 11:30:13 2001 -->
<table><tr><td><a href=/elog/notebooks/xft/Thu_May__3_2001_113003.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-45  align='top'></td><td>run 113500, peaks are not clear as previous one. This is one of GOOD RUN run 111380 has a lot of pixel mismatches.</a></td></tr></table>
<!-- Author: Jong-young -->
<!-- Comment: Thu May  3 11;31;04 comment by...Jong-young -->
But still see repeating small peaks...


<!-- Date: Fri May 4 16:50:53 2001 -->
<table><tr><td><a href=/elog/notebooks/xft/Fri_May__4_2001_165042.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-47  align='top'></td><td>Run 111307 - track trigger bit 10 on  (4 is on if 10 is on)</a></td></tr></table>
<!-- Author: Evelyn Thomson -->
<!-- Comment: Fri May  4 16;55;32 comment by...Evelyn Thomson -->
These events have only ONE XFT 4-layer track
myron mode event flag is 1.
Track trigger bits ON.

Hole between 0 and 120 degrees is due to absence of xtrp boards
in xtrp crate slots 6,7,8 and 9 (each board covers 120 degrees).

Spikes are for linker chips 8,9,10,11 which is a 5 degree slice.
No track triggers from chips 0-7!!!

Problem must be IN TRACK TRIGGER since XFT information is flat
for events that came in by some other path.


(Note there are 288 linker chips in 360 degrees.  linker chip
0 is at phi=270 degrees thanks to Jonathan!)
<!-- Date: Fri May 4 16:51:40 2001 -->
<table><tr><td><a href=/elog/notebooks/xft/Fri_May__4_2001_165135.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-50  align='top'></td><td>Run 111307 - track trigger bit 10 is off (4 is off if 10 is off)</a></td></tr></table>
<!-- Author: Evelyn Thomson -->
<!-- Comment: Fri May  4 16;53;22 comment by...Evelyn Thomson -->
Flat distribution of xft tracks in phi if track trigger bits are off.

These are events with ONLY 1 XFT 4-layer track,
myron mode event flag is 1



<!-- Date: Fri May 4 17:09:52 2001 -->
<table><tr><td><a href=/elog/notebooks/xft/Fri_May__4_2001_170946.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-52  align='top'></td><td>111307 trigger table bits</a></td></tr></table>
<!-- Author: Evelyn Thomson -->


<!-- Date: Fri May 4 20:35:46 2001 -->
<table><tr><td><a href=/elog/notebooks/xft/Fri_May__4_2001_203518.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-54  align='top'></td><td>So, I tried to make plot with run 113500 (36x36) In this run, there are more trigger bit. I made similar plot as Evelyn's, but I turn off trigger bit 15, 17, 19 (L1_DIRAC_TRACK) </a></td></tr></table>
<!-- Author: Jong-young -->
<!-- Comment: Fri May  4 20;38;27 comment by...Jong-young -->
It is not clear .. ( influence of DIRAC_TRACK bit)...in this plot.


<!-- Date: Mon May 7 13:48:18 2001 -->
<center><a href='/elog/notebooks/xft/Mon_May__7_2001_134239.ps'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-60' ></a><a href='/elog/notebooks/xft/Mon_May__7_2001_134703.ps'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-62' ></a><a href='/elog/notebooks/xft/Mon_May__7_2001_134714.ps'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-64' ></a><a href='/elog/notebooks/xft/Mon_May__7_2001_134722.ps'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-66' ></a><a href='/elog/notebooks/xft/Mon_May__7_2001_134735.ps'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-68' ></a></center>
<!-- Author: Erik Brubaker -->
<!-- Comment: Mon May  7 14;01;47 comment by...Erik Brubaker -->
Except on the first page, yellow plots always contain 3- and 4-layer tracks, while green plots have 4-layer tracks only.

The first page shows the two variables used to match XFT tracks with L3 tracks: the curvature, and the phi at SL6. The initial curvature cut is very loose (|dcurv|<.33 GeV^-1). dphi(SL6) is then minimized and tracks are said to be matched if |dphi(SL6)|<.005 rad).

People might also be interested in the resolution of phi0 and pT, shown on the second page. The bottom plot shows (pt_XFT-pt_L3)/pt_L3^2.

The third page shows efficiency vs pt for the turn-on. (Inset goes out to 10 GeV pt.) The turn-on is sharper when only 4-layer tracks are considered.

The fourth page shows efficiencies vs cot theta and vs phi for tracks above 1.5 GeV.

The final page separates out the positive and negative charge tracks. With these statistics, there are no clear differences in the turn-on region between the two.

Comments and suggestions will be much appreciated!


<!-- Comment: Mon May  7 21;21;24 comment by...Evelyn Thomson -->
Resolutions will improve with correction for beamspot offset!
See slides from November commissioning run attached below


<!-- Date: Mon May 7 21:24:17 2001 -->
<table><tr><td><a href=/elog/notebooks/xft/Mon_May__7_2001_212204.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-72  align='top'></td><td>Slides from November commissioning run</a></td></tr></table>
<!-- Author: Evelyn Thomson -->


<!-- Date: Tue May 8 13:24:21 2001 -->
<table><tr><td><a href=/elog/notebooks/xft/Tue_May__8_2001_132348.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-74  align='top'></td><td>Slides from May 8 LLS meeting</a></td></tr></table>
<!-- Author: Evelyn Thomson -->


<!-- Date: Tue May 8 18:03:42 2001 -->
<pre>---------- Forwarded message ---------- 
Date: Tue, 08 May 2001 16:22:09 -0500 
From: Peter Tamburello <tamburel@fnal.gov> 
To: Evelyn Thomson <thomsone@fnal.gov> 
Subject: re: COT hit efficiencies per superlayer 
 
Here is the best information available... 
 
---------- Forwarded message ---------- 
Date: Sun, 29 Apr 2001 14:47:43 -0500 
From: Bob Wagner <wagner@fnal.gov> 
 
 
 During the recent 36x36 stores we ran the superlayers at 101.5% of 
Kevin's nominal 1.9 kV/cm settings, with the exception of SL1 and SL4 
which are at the old settings.  SL1 was not changed because of high 
occupancy, and SL4 has a problem with S0 in quad D, which looks very 
likely to be related to the cell 227 problems we have been fighting since 
last summer.  S0 is actually being run 96v below where it should be to 
prevent trips.  Anyway, a new efficiency scan was done using the event 
display for superlayers except 1 and 4.  The threshold was 225mv and the 
atmospheric pressure was 761 mmHg, as measured by the GMC's pressure 
transducer (again on the high end of it's recorded pressures).  The 
previous message is attached below, and those results are included in the 
summary table.  As before, tracks with pt > 1 GeV/c and traversing all 8 
superlayers were all scanned: 
 
Run     HV      threshold       pressure        Segments        % miss hits     % sense miss    % field miss 
111211  100%    250mv           760             148             4.6             1.9             1.6 
 
111210  100%    225             760             126             3.0             0.9             0.7 
 
113488  101.5%  225             761             134             1.2             0.6             0.4 
 
We are now in the efficiency regime where we ran the outer CTC layers in 
Run 1, so it would be nice stay here if the high voltage cooperates.  The 
present plan is to reduce the high voltage as the pressure decreases, so 
that the gain stays constant. 
 
 
 
Previous message: 
============================================================================== 
  Event Display scan to help determine COT gain and threshold settings 
 
 
Last Friday, Peter Wittich showed me the results of a study that was done 
to determine the hit usage efficiency as a function of threshold.  The 
plot showed a close to linear increase in SL6 hit usage as DTH was 
decreased down to 250mv.  From 250 to 225mv, the curve seem to roll over 
somewhat, indicating that we are likely at the "knee" of the plateau 
curve.  If my memory serves, the hit usage inreased from about 93 to 95% 
between 250 and 225mv, which is quite substantial.  Peter thinks that the 
absolute normalization is not that reliable. 
 
 In order to get some feeling for the hit efficiency and noise, I scanned 
events from runs in the first set of threshold scans where thresholds in 
all layers were changed from run to run.  According to the Gas Monitor 
Chamber pressure scan, these runs were taken at about 760 mmHg, which is 
near the high end of the trypical atmospheric pressure range, so 
efficiencies will most often be somewhat better than the result of this 
scan.  Events were scanned in Run 111210 (225mv) and 111211 (250mv) using 
t0 = 140ns and an event window of 500ns.  In the scan, I only used tracks 
which traversed all 8 superlayers and for which the fit gave pt > 1.0 
GeV/c.  I ignored information as to which hits were used in the track 
finding/fitting and just counted the number of hits present in completely 
isolated superlayer segments.  Therefore, the scanned segments are heavily 
weighted toward the outer superlayers. 
 
 At 250mv, 148 segments were scanned and 82 of 1776 wires (4.6%) had no 
hits associated with the segment, 1.9% were missed when crossing the sense 
wire plane and 1.6% were missed when crossing the field plane.  At 225mv, 
126 segments were scanned and 45 of 1512 wires (3.0%) had no hits (0.9% 
loss when crossing the sense wire plane and 0.7% when crossing the field 
plane).  The sense plane and field plane crossing numbers are much more 
subjective than the total. 
 
The noise situation at 225mv was noticably worse than at 250mv, but it 
was not too bad.  Two spots were particularly more active at the lower 
threshold, SL8 near 90 degrees and SL5 near 0 degrees.  The SL8 problems 
is a "known" hottish area near where the HV ribbon cables come through the 
Faraday cage. 
 
 During the 4/17/01 access, Aseet ran up the high voltage to 101.5% of 
nominal, which we believe increases the gain by about 40%.  After three 
trips in the first 1/2 hour (one each in SL4, 6, and 8), the high voltage 
was tripless from 10:00 to 21:00.  Recall that we ran the axial layers at 
101.5% during the last 36 x 36 store in the Commissioning Run.  I propose 
that we implement this gain increase and decrease DTH to 235mv for a total 
increase in signal to threshold of 40% + 10% = 50%.  I hope that this will 
get us a little beyond Peter Wittich's knee.  My preference would be to 
leave SL1 at the old settings, since it is not involved in the trigger and 
has a much bigger problem with occupancy than efficiency. 
 
</pre>
<!-- Author: From Peter Tamburello -->


<!-- Date: Tue May 8 18:10:35 2001 -->
<pre>Hi Peter, 
 
        Each linker has 12 chips and covers 15 degrees 
 
        Each xtrp board takes input from 2 linkers, called wedge A and 
wedge B, and covers 30 degrees 
 
Chips 8,9,10,11 on a linker board correspond to 5 degrees. 
 
I saw the same thing with the higher Pt track triggerbits (17 and 18).  I 
noticed the prescale effect in the 1.5GeV trigger bit on/off. 
 
        Evelyn 
 
On Tue, 8 May 2001, Peter Wilson - Looking for hills in flatland wrote: 
 
> Hi Evelyn, 
> 
> Hmm, these results do look odd.  For the forgetful, can you 
> explain the Odd/Even Linker and chip numbers in detector 
geometry. 
> 
> Did you look at the higher Pt track triggerbits?  The 3 GeV (bit 17) had a 
> prescale of 50 and the 8 GeV (bit 19) had no prescale. 
> 
> Trigger bit 16  L1_ELECTRON_ET1.5_PT1.5/0[2] was masked because it was not 
> working correctly.  The "/0" at the end of the name means prescale of 0 which 
> means masked.  However, there was a L1_DIELECTRON_ET1.5_PT1.5 trigger (bit 
> 10). Of course your requirement of only one 4 layer track would throw out 
> these events. 
> 
> Peter 
> 
> > Hi, 
> > 
> >     I spoke with Nathan earlier - we looked at a couple of events in 
> > the 1x8 data.  The xtrp sets a dirac bit for an event with a track in 
> > linker chip 9, but it doesn't set a bit for an event with a track in 
> > linker chip 4 for example. 
> > 
> >     I've had a look at some of the 36x36 data.  The statistics are 
> > small (at most 6 events per chip) since I require only ONE 4-layer track 
> > in the event and I've only ran over 11,500 events from run 113500.  I am 
> > running over more events now, but there are some interesting patterns for 
> > the various triggers and differences between 1x8 and 36x36: 
> > 
> > *********************************** 
> > In the 36x36 data for run 113500: 
> > -------------------------------------------------------- 
> > Trigger bit 15 L1_DIRAC_TRACK_PT1.5/ prescale=250[2] ON or 
> > Trigger bit 33 L1_ELECTRON_ET3_PT3[4]                    ON or 
> > Trigger bit 35 L1_ELECTRON_ET5_PT2.5[4]          ON 
> > --------------------------------------------------------- 
> > Tracks in even linker board chips 8-11              (xtrp wedge A) 
> > Tracks in odd linker board chips 0-6 and 8-11       (xtrp wedge B) 
> > 
> > ----------------------------------------------- 
> > Trigger bit 39 CMU_HIGH_STUB_HIGH_TRACK[1] ON or 
> > Trigger bits 41,43,45,47,49,53                 ON 
> > ----------------------------------------------- 
> > Tracks in linker board chips 8-11 only (xtrp wedge A and B) 
> > 
> > --------------------------------------------- 
> > Trigger bit 16 L1_ELECTRON_ET1.5_PT1.5/0[2] ON 
> > -------------------------------------------- 
> > No events passed my cuts (due to only one xft track requirement?) 
> > 
> > ------------------------------------------------- 
> > All track, electron, muon trigger bits OFF 
> > -------------------------------------------------- 
> > Tracks in all linker chips (note that 1.5 track trigger is prescaled 
> > by a factor of 250) 
> > 
> > 
> > ******************************* 
> > In the 1x8 data for run 111307: 
> > --------------------------------------- 
> > Trigger bit 10 L1_DIRAC_TRACK_1.5[1] ON 
> > --------------------------------------- 
> > tracks in linker board chips 8-11 only (xtrp wedge A and B) 
> > 
> > --------------------------------------- 
> > Trigger bit 10 L1_DIRAC_TRACK_1.5[1] OFF 
> > --------------------------------------- 
> > tracks in linker board chips 0-7  for boards 0-5, 14-23 
> > tracks in linker chips 0-11 for boards 6-13 (no XTRP in trigger path) 
> > (no prescale on 1.5 track trigger) 
> > 
> 
 
</pre>
<!-- Author: Evelyn Thomson -->


<!-- Date: Tue May 8 18:11:43 2001 -->
<pre>I generated some test-vectors so the xtrp can test their board at speed. 
 
Yesterday Nathan and I dumped the XTRD bank for some events, particularly 
chip 4 and chip 9.  The XFT information was correct in the XTRD bank. 
However, an output bit wasn't set for chip 4. 
 
Today, Nathan stepped the event with the track in chip 4 through his board 
and said he saw the output bit was set!  Note this is not a full-speed 
test.  So I generated the events below so that we can at least use the 
Finder to Linker to Xtrp test to run events through XTRP at full speed... 
 
 
---------- Forwarded message ---------- 
Date: Tue, 8 May 2001 17:30:24 -0500 
From: Evelyn Thomson <thomsone@fnal.gov> 
To: Nathan Eddy <eddy@fnal.gov> 
Cc: Peter Wilson <pjw@fnal.gov> 
Subject: xtrp files 
 
Hi Nathan, 
 
The testvectors are (now) in the usual place 
 
        /cdf/code-common/cdfonline/XFTtestvectors/ 
 
with suffix _sgl_1xtrp.dat 
 
Select any 2 linkers and 1 xtrp board and type " 06_sgl_1xtrp " into the 
filename field: 
 
The first 40 events should be sufficient to have a track in each linker 
chip - see ~thomsone/TrackFound.txt and TrackFfound_4-lay.txt on b0dau30 
for printout on which chip the track is in and what the phi bin is. 
 
 
 
        I generated 400 events with a single muon : 
 
        pt between 9.99 and 10.01 GeV/c 
        eta between -0.5 and +0.5 
        phi between 0 and 30 degrees (1 xtrp board - both wedges) 
 
 
The tracks are only in these checking files: 
 
RecFifo_06_sgl_1xtrp.dat        chips 1-11 
RecFifo_07_sgl_1xtrp.dat        chips 0-11 
 
Sorry about the lack of tracks in chip 0 in the first file - I can redo it 
if you need that. 
 
</pre>
<!-- Author: Evelyn Thomson -->