<!-- Title: 13:37:10  Tue Jul 31 2001 -->
<!-- Crewchief: L2, SVT et al. -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Continued L2 debugging</pre>


<!-- Date: Tue Jul 31 13:43:00 2001 -->
<pre>L2 meeting 7/30/01 
 
Track/SVT board - will test new firmware to try and solve 
the high rate sync error 
 
Clist - Monica and Stephen will make a new fpga design that 
is synchronous and that borrows from the Track board. This  
will also be useful for the muon board. 
 
Reces - Need to establish that the SMXR is correctly strobing 
data into the boards and that the alpha is properly reading the 
data. Will make a special version of the L2_TORTURE exe for 
reading out just one reces board. 
 
 
New versions of L2 trigger monitoring code is in place and 
seems to work well. There is no longer disagreement in results 
between running it online vs offline. 
 
</pre>
<!-- Author: Stephen -->


<!-- Date: Tue Jul 31 16:06:11 2001 -->
<pre>L2 Meeting 7/31/01 
 
Track/SVT - have a possible firmware fix for the sync errors, 
based on the assumption that sync errors are due to noise 
on startload. A board in a lower slot is more likely to have 
the error. No error has been seen with the new firmware, but 
running conditions have not been stable enough to do a lot 
of testing.   Possibly a new error condition where the SVT board 
holds boss high, has been seen. 
 
Reces - Were able to do tests with 1 Reces board and found that 
SMXR does strobe data up correctly - although it is suspected 
that some cables have been swapped. 
  Also, there are many DTO's from the L2 crate during testing. 
 
The Cluster test part of TrigMon gives results that disagree 
with Monica's standalone code. Nate and Monica will look into 
the differences. 
 
The new alpha boards don't work because of failures with the 
socket which holds the CIA chip. One of the alpha boards did 
work for a while and was successfully tested before it failed. 
 
</pre>
<!-- Author: Stephen -->


<!-- Date: Tue Jul 31 16:36:53 2001 -->
We loaded in b0svt06 a temporary development version of svtvme that 
makes again the SVTY bank. Now is a fix length 9 words block. In one/two days it will contain the beam position. If b0svt06 is rebooted it will loose SVTY. We tested SVTY with FER on b0svt00 up to 3KHz, so expect no problem.
<!-- Author: Stefano & Yanwen -->
<!-- Comment: Tue Jul 31 17;13;12 comment by...Stefano -->
<strong>oooppsss
</strong>
the above did not work on b0svt06, guess we can not unload/reload svtvme_th.o while svtmon is running and without Marco I am not sure I can safely stop it completely. So will rather change svtvme development to pick the SVTY-making code at boot time.
Probably will be done by sometime tomorrow.


<!-- Date: Tue Jul 31 20:15:11 2001 -->
Track list work continues! 
<p> 
We updated the firmware to make a "clean" version of START_LOAD. 
Recall that yesterday we had only protected the state machine from such glitches at the point which allowed double-sending.  The double-sending had gone away but then we started to hang the bus with BOSS.  We tracked that down to another part of the state machine asking for START_LOAD.  When we protected *that* signal, the bus hangs went away.   We still had some residual sync problems with SVT but when we protected *all* the START_LOADs we could then take data at 17kHz in sync! 
<p> 
There's still a small fly in the ointment.  We find that XTRP always starts out of sync on a cold-start, but is 'n sync forever after an HRR.  SVT does not have this problem.   
<!-- Author: Matt, David -->


<!-- Date: Wed Aug 1 04:50:49 2001 -->
<pre> I contiued yesterday's Reces test. We ran L2 torture test 
with only one Reces board reading. We took 2 Runs (122269, 
122277). Both gives done timeout every &lt;10 events  
same as yesterday. 
 
There were three problems 
 
(1) check cable swap 
     We exchange the fibers at the Reces side and now looks 
     no problem. We need to check the cable label at the 
     SMXR side when next access 
 
(2) Contents of TL2D bank  
     Stephen made new L2 executable. It solves the problem 
     which we found yesterday.  
 
(3) Done timeout every ~10 events 
 
 We got the same done timeout as yesterday, Here is cut and 
past from Error log. 
 
(RC)   3:14:38 Config -&gt; READY 
(MLE) b0l2de00:Messenger:3:16:29 AM-&gt;VISION read failed in slot 3 
(RC)   3:16:40 Activate -&gt; ACTIVE 
16'53" 1 crate/s: b0l2de00(150),  Done TO.[RXPT] 
(MLE) b0tsi02:Messenger:3:16:50 AM-&gt;DONE timeout 
(MLE) b0tsi02:Messenger:3:16:54 AM-&gt;DONE timeout 
(RC)   3:17:41 Halt -&gt; HALTED 
17'51"  
(RC)   3:17:52 Recover -&gt; RECOVERED 
(MLE) b0l2de00:Messenger:3:17:49 AM-&gt;VISION read failed in slot 3 
(RC)   3:18:2 Run -&gt; ACTIVE 
18'11" 1 crate/s: b0l2de00(150),  Done TO.[RXPT] 
(MLE) b0tsi02:Messenger:3:18:11 AM-&gt;DONE timeout 
 
 I am not sure how correct timing in the error log is but 
the VISION read error happens even before Run to be active!! 
 
 I also looked at the timing with scope and found 
some events which alpha did not read reces. 
It is strange becase the run condition is auto L2 accept 
and alpha read reces every L2A. 
 
Anyway we need more study to understand the readout timing  
of Reces. 
</pre>
<!-- Author: masa -->


<!-- Date: Wed Aug 1 12:21:25 2001 -->
<p> 
Tracklist tests 
<p> 
Testing new firmware (7/31/01) at high rate in many stressful situations.  Found that once both tracklist boards were in sync they stayed that way indefinitely.  Run 122349 was taken with L2_RATE_TEST with the alpha cutting: 6k events at a L2A rate of 1.8 Hz (50M L1A at a rate of 15 kHz).  Both tracklist boards started in sync and did not loose it. 
<p> 
We also confirmed that XTRPlist (slot 7) will loose sync immediately after activate or HRR on occasion.  We could not find a repeatable condition on the backplane when this happens.
<!-- Author: Da5id and 1000att -->


<!-- Date: Wed Aug 1 16:40:23 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-69&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-69' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-70&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-70' width='300'></a></center>
<!-- Author: masa, kareb -->


<!-- Date: Wed Aug 1 17:02:15 2001 -->
<pre>We loooked at reces readout timing with scope 
while taking data with L2_TORTURE, tagging mode. 
Alpha gave done timeout every ~10 events as usual. 
 
Above pictures are typical displays 
(red line is L2A) 
left: The first three events after HRR. 
      L2A appears right after ST_LOAD beeing back 
      to 0, but only for first event. 
      I was triggering when ST_LOAD go down 
      I am not sure but it is likely ST_LOAD  
      was set to 1 when HALT or RESET, and 
      back to 0 after Activate. It is why  
      ST_LOAD is 1 at the left edge of the display.  
      Also L2A shows huge strange noise..     
 
right: alpha does not read reces 
 
        
 
</pre>
<!-- Author: masa, karen -->
<!-- Comment: Wed Aug  1 21;04;25 comment by...Stephen -->
<pre>The reason reces isn't read for the first (short) startload
is because it isn't processing a previous event right after
it asserts startload. Instead the code goes and gets the next
L1A and then sends startload again. It then processes the data
from the first startload including reading reces.

  </pre>
<!-- Date: Wed Aug 1 19:23:14 2001 -->
Put prom in Clist board with new firmware from Stephen and  
Monica, before starting tracklist studies.  All runs from 122420 onward should have the new firmware.  For offline analysis, run 122420 had 564k L1A and 2380 events (L2A).
<!-- Author: Matt -->


<!-- Date: Wed Aug 1 19:47:00 2001 -->
<p> 
Tracklist studies 
<p> 
More runs with L2_RATE_TEST in cutting mode.  XTRPlist goes out of sync roughly 1/2 of all coldstarts, on the first event.  We used the alpha debug monitor to look at the bc's from XTRPlist and SVTlist.  Generally, the tracklist board would repeat a 
series of sequential bc's not related to the system bc's before starting with the correct ones.  Then it would remain behind the SVTlist bc by the exact number of events it had given the sequential bc's.  For example, in the first 9 events in run 122424 the bc's went: 42, 43, 44, 45, 42, 43, 44, 45, 0,... at which point the XTRPlist board stayed 8 bc's behind SVTlist, which had started with bc = 0 on the first event. 
<p> 
This happened with XTRPlist recording wrong bc's and then being 8, 2, 7 and 11 events behind the SVTlist bc in various runs.  In 1 run SVTlist showed similar behavior, recording bc's in order from 97 to 110 before getting to the correct bc's, and then remaining 14 events behind the rest of the system.
<!-- Author: David and Matt -->



<!-- Date: Thu Aug 2 11:56:31 2001 -->
<pre>L2 Meeting 8/1/01 
 
Some discussion on determining where the problems are e.g. 
backplane noise, alpha, interface boards, systems sending to 
interface boards.  Recent problems seem to be backplane noise 
(on TTL lines) causing problems in the interface boards firmware. 
The noise can be protected against by changing the firmware. 
At this point it is not clear how much time should be spent 
studying noise in the bottom crate. We'll probably wait until 
we have an identifiable noise problem that cannot be fixed in 
firmware. 
 
The Track/SVT boards had glitch protection put on the start_load* 
line in the fpga. This seems to have solved the sync error  
problems and the board holding boss high problem.  There 
is still a problem that the track board goes out of sync much 
of the time at the beginning of the run and sometimes right 
after HRR. Once it is in sync, however it stays in sync. 
The problem may be that the XTRP board doesn't clear its fifos 
on Recover. 
 
We need Error handling code in the alpha to find when boards 
are out of sync and pull CDF_ERROR. 
 
 
 
Reces: The cable swap and alpha code changed fixed the problem 
of the data being wrong. There is still the DTO problem which 
is caused by some VME interaction between the alpha and the crate 
controller. 
 
L2 code was just put into CVS. Instructions for code writers will 
be written soon.</pre>
<!-- Author: Stephen -->

<!-- Date: Thu Aug 2 16:40:24 2001 -->
I changed the readout for SVTD bank from the
L2/if board in SVT final crate (b0svt06) from
200 words fixed lenth to variable length.
Now the SVTD bank in each event should terminate
exactely at the EndEvent word.
<br>This variable length readout has been tested, but not
extensively, nor recently. SVT "monitors" please be
aware of this and report any problems to SVT/if board
people (Jane,David,Matt).
<!-- Author: Stefano -->


<!-- Date: Thu Aug 2 16:40:25 2001 -->
I changed the readout for SVTD bank from the
L2/if board in SVT final crate (b0svt06) from
200 words fixed lenth to variable length.
Now the SVTD bank in each event should terminate
exactely at the EndEvent word.
<br>This variable length readout has been tested, but not
extensively, nor recently. SVT "monitors" please be
aware of this and report any problems to SVT/if board
people (Jane,David,Matt).
<!-- Author: Stefano -->



<!-- Date: Thu Aug 2 16:58:13 2001 -->
<p> Tracklist studies <p> With no printout from the alpha, we successfully observed START_LOAD, BOSS,and DSTROBE on the backplane in the first events from several runs where either XTRPlist or SVTlist (or both) started out of sync with TFRD on the first event.  These events looked perfectly normal.  When the boards started out of sync they followed exactly the same pattern as we observed in our <a href= 
'/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=14&frame=2&anchor=19:47:00'>previous entry</a>.  
<p> Nathan Eddy reported that he thinks XTRP itself is not working properly, especially during coldstart.  This could explain some of these problems.
<!-- Author: Matt and David -->

<!-- Date: Thu Aug 2 18:44:38 2001 -->

I would like to try to move the B0 SVT test stand closer to a "production"
state.  I think we have often stated a goal for the test stand to be the
minimal set of hardware needed to test one of every kind of SVT board.  I
interpret this to mean one CPU, one Test Clock (to emulate TRACER
behavior), one Spy Control, one GSTM (to feed a Hit Finder), one Hit
Finder, one Merger, one AM Sequencer, two AM Boards, one Hit Buffer, one
Track Fitter, one XTFA, two XTFB, and a test board for XTFA L1 inputs.  
The test stand now contains those items.  There is unfortunately only one
"backplanino" in that crate, when two backplanini are needed if we want to
test XTFA/B and AMS/B at the same time.  Stefano will attempt to have one
more sent from Pisa. 

<p> 

The order of the boards is currently as follows:

<p> 

<pre>
   1 CPU (68K)
   2 TestClk
   3 Spy Control
   4 test board for XTFA L1 inputs
   5 free
   6 HF
   7 Merger
   8 XTFA
   9 XTFB
  10 XTFB
  11 HB
  12 TF
  13 GSTM (motherboard)
  14 GSTM (daughterboards)
  15 GSTM (granddaughterboards)
  16 free
  17 AMS
  18 AMB
  19 AMB
  20 free
  21 free (or GhostBuster for now)
</pre>

<p>

I think it is good to leave slots 20,21 open for boards that may need to
be probed or programmed.  I would have preferred to put the AMS/AMB/AMB on
the left side of the crate, but the only backplanino is currently there,
and Simone is still working on XTFA/B firmware tweaks.

<p>

I moved HF 25, XTFA 2, and Merger 26 from the test stand to the storage
locker.  Merger 26 used to be the pseudo-XTFA, but has now been
reprogrammed as a Merger, with Standard_2001 firmware.  I moved AMS 13,
TestClock 62 (thanks to Fred Lewis), and a GSTM into the test stand.

<p>

It would be nice to have some real tests running here: the cold start
code, a random test, each board's test code, etc.

<p>

<!-- Author: Bill -->


<!-- Date: Fri Aug 3 04:44:18 2001 -->

<pre>

---------- Forwarded message ----------
Date: Fri, 03 Aug 2001 04:42:22 -0500 (CDT)
From: Bill Ashmanskas <ashmansk@HEP.UCHICAGO.EDU>
To: svt@fnal.gov
Cc: saltzberg@fnal.gov
Subject: SVT this shift

Please look at tonight's owl shift's main shift logbook.

(a) There is definitely a problem with the data sent by XTRP, as David has
noted for a while.

(b) I don't understand why certain SVT wedges are seeing sync errors (all
the time, which is different from XTRP sync, which is OK initially and
then goes wrong).  Looking at every spy buffer of every Merger would
probably narrow this down.  (Any takers?)

(c) I unplugged the SVT->L2 cable, to stop L2 from complaining.  David,
feel free to re-plug it.

(d) I have left SVT in a pretty dysfunctional configuration.  When SVX is
included, it will now look for sync problems, but will not find any
tracks, since XTRP is ignored.  Also, much silicon is currently ignored.
Alex, feel free to figure it out!

(e) I had to disable the pulling of CDF error, so that we could take data.

(f) Someone should call Nathan Eddy in the morning.

-Bill

</pre>

<!-- Author: Bill -->
<!-- Comment: Sat Aug  4 16;59;04 comment by...David -->
<pre>Not just me, Matt too.</pre>
<!-- Date: Fri Aug 3 16:24:49 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-71&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-71' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-72&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-72' width='300'></a></center>
<!-- Author: Peter Wittich -->
<!-- Comment: Fri Aug  3 16;33;00 comment by...Greg, Matt and Peter  -->
<p>Looked at two address lines in L2 decision crate.  the difference between the two plots is that the trace labelled A0 is address line 0 on the MBus in the first plot, while it is A1 in the second plot.  Sorry about the mislabel.
</p>

<p>The L1Interface board does appear to assert a higher logic low level than the CList board.  the pullup is set to 3V, the logic high level that all boards asser appears to be the same at 3.5 V (not shown) and L1interface's low is at ~800mV while CList's is closer to 40 mV (see second plot.)</P>

<p>Looking back to the log book, we see this behavior back to June 18, when the 245-&gt;2245 switch was made. This corroborates stephen's theory that the drivers are somehow the cause of the levels being different. However, the board worked fine until this point, so it seems unlikely that this is the cause. </p>


<p>We looked at A0-A7 during a run where trigmon reported failures in TFRED-TL2D problems were occuring, and all bits for L1Interface were solidly at its low level.</p>
<!-- Date: Fri Aug 3 16:27:19 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-73&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-73  width='300' align='top'></td><td>TL2D-TFRD mismatch in bits 48-63.</a></td></tr></table>
<!-- Author: Greg and Matt -->
<!-- Comment: Fri Aug  3 16;32;47 comment by...Matt -->
Runs taken with Physics_0_00 and Physics_0_01 had similar errors, so this doesn't look like a trigger table dependent problem.



<!-- Date: Fri Aug 3 18:00:34 2001 -->
Power cycled L2 decision after run 122646 to see if this cures the L1 interface board problems.
<!-- Author: Matt -->



<!-- Date: Sat Aug 4 19:37:17 2001 -->
After power cycling the crate, the L1 interface board worked properly until run 122676, in which it showed the same error pattern as seen <a href= 
'/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=14&frame=2&anchor=16:27:19'>above</a>.  It seemed to work properly after that run until the end of the store (run 122695).
<!-- Author: Matt -->


<!-- Date: Sun Aug 5 04:18:35 2001 -->
<pre>I was paged tonight ~3 am b/c l2de00 crate was giving lots of TO's and they were unable to run.  SVT cable is still unplugged.  Of course, once I got here and minicom-ed in, everything worked.  One slightly disturbing thing - I was looking at the l1 board and the pretty lights weren't flashing (ie nothing happening), but the run was continuing to accumulate events, and the aces told me they were running fine.  (run 122748)  Aside from telling the aces to HRR/cold start/possibly press reset button on crate, is there anything else we can do for now to decrease the frequency of these TO's?  </pre>
<!-- Author: hray -->
<!-- Comment: Sun Aug  5 21;04;52 comment by...Matt -->
I checked the online TrigMon root file and ran over the A-stream events offline for run 122748 and the L1 interface board data looks fine.  Perhaps the LED is burnt out?
<!-- Date: Sun Aug 5 18:28:18 2001 -->
<p> 
Investigating L2 problems that occured throughout the <a href= 
'/cgi/elog/elog.pl?nb=2001&action=view&page=549&frame=2&anchor=08:48:08'>day shift</a>. 
<p> 
Took several runs with all the calorimeters, all L1CAL, L1GLOBAL, all L2CAL, L2DECISION, SCALERS, SVT06-07, all XFT, XTRP, and L3.  Attempted to reproduce either the 'alpha no longer processing' errors or the <a href= 
'/cgi/elog/elog.pl?nb=2001&action=view&page=549&frame=2&anchor=10:38:08'>strange deadtimes</a> from L2 with the Physics_0_01[15,168] trigger table.  Interface boards in and cabled were Clist, L1, XTRPlist, SVTlist and 4 reces. 
<p> 
Took run 122782 with the softevb at 8 Hz L1A and L2A (alpha tagging) and 17kHz L1A/2 Hz L2A (cutting) with L2_RATE_TEST: everything worked fine.  Took run 122791 with Cosmics_All[2,165] with L1A and L2A rates of 20 Hz to try different triggers and get some clusters: everything worked fine.  Took run 122794 with Physics_0_01[15,168] with L1A and L2A rates of 1.7 Hz to check the deadtime: deadtime was 0% for Level 2. 
<p> 
Conclusion: the conditions that L2 was running under during beam (many triggers, L2 rates of several hundred Hz, multiple tracks from SVT and XTRP) couldn't be reproduced with only bc and cosmic triggers.  I suggest that the next time we have beam all of the L2 experts be present.
<!-- Author: Matt -->


<!-- Date: Sun Aug 5 20:56:25 2001 -->
<a href= 
'http://www.physics.ucla.edu/~mworcest/level2withbeam.html'> 
http://www.physics.ucla.edu/~mworcest/level2withbeam.html</a> 
<p> 
Questions, comments, and suggestions welcome.
<!-- Author: Matt and David -->


<!-- Date: Mon Aug 6 12:10:45 2001 -->

FYI, Nathan Eddy and I plan to take XTRP and SVT at 13:00 today, to try to
reproduce with test patterns the end-event-word problem seen in this
weekend's beam data between XTRP and SVT/L2.  This has been cleared with
the shift crew.

<!-- Author: Bill -->



<!-- Date: Mon Aug 6 12:34:52 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-74&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-74' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-75&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-75' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-76&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-76' width='300'></a></center>
<!-- Author: Matt -->
<!-- Comment: Mon Aug  6 12;40;11 comment by...Steve K and Matt W -->
<p>
Plugged ISOlist into slot 15.  These plots are from run 122848; alpha tagging; Cosmics_All trigger table; all other boards (L1, Clist, SVTlist and XTRPlist) behaving normally.
<p>
Three cases on the backplane: (1) ISOlist raises MOD_DONE immediately on START_LOAD going low and doesn't send data. (2) ISOlist sends data and raises MOD_DONE. (3) ISOlist doesn't send data but never raises MOD_DONE.  In this case the alpha times out after 60 usec.

<!-- Date: Mon Aug 6 17:57:51 2001 -->
<pre>

We discussed the issue of XTRP synchronization with SVT and L2 at today's
L2 meeting, and agreed to make a request for beam time.  This is a
contingency, in case we aren't able to understand the cause of the problem
without beam.

(a) During the first runs, SVT will watch (without pulling CDF_ERROR) to
see whether the XTRP/SVT synchronization problem can be reproduced.  This
can happen parasitically, probably with or without the silicon.

(b) If the problem is present, we would like ~30 minutes of dedicated run
time, with L2 and L3 accepting every event and writing to a single stream,
preferably on disk. The time needed may be more or less than 30 minutes,
depending on how often we can make the problem occur (which should be
predictable from the earlier parasitic runs).

For this test run, we would like the L1 accept rates high enough that
there is some deadtime, but to be able to set the prescales so that the
deadtime is not enormous, so that there is a non-trivial pattern of Level
2 buffer occupancies and delays between Level 1 accepts.  Other than that,
I don't think we're too picky about the trigger table.

Bill Ashmanskas and Nathan Eddy should be present for this run.  Having
Matt Worcester here also would be helpful.

-Bill

</pre>
<!-- Author: Bill -->



<!-- Date: Mon Aug 6 21:04:51 2001 -->
<p> 
SVT/XTRP/L2 syrchronization studies 
<p> 
We attempted to reproduce sync problems between XTRP and 
SVT/L2.  We first tried booking XTRP+SVT, without L1, but 
were not able to produce a mismatch (as detected by the 
Merger in b0svt07/slot 10).  Then, after L2 meeting, and 
after IsoList tests ended around 18:00, we added L1, L2, 
and some calorimeter crates.  We were unable to make the 
problem happen with L2_RATE_TEST at 17kHz L1A rate.  We 
noticed that the L1A were pretty evenly spaced every 
50us, which seemed too easy, so we switched to 
INTEGRATION_SUMET_5, which gave us the L1A pattern we 
wanted--nice random distribution of L1A spacing.  We still 
did not see the problem.  Once we saw one BC mismatch 
between XTRP and SVT, but it didn't match the profile we 
were looking for (i.e. repeating one of the past four BCs). 
Although SVT and XTRP were in agreement on BC, L2 reported 
some disagreements, described below. 
<p> 
From the point of view of the L2 tracklist boards, we saw the same pattern of sync errors in both SVTlist and XTRPlist as seen <a href= 
'/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=14&frame=2&anchor=19:47:00'>previously</a>, where a board would generate a repeating pattern of incorrect bc's from the first event (e.g. 152, 153, 154, 152, 153, 154,...), and then fall behind the rest of the system.  If this did not happen on the first event, it did not happen at all.  We saw this in  both L2_RATE_TEST with the alpha cutting and in INTEGRATION_SUMET_5 with the alpha tagging.  This did <b>NOT</b> correspond to the disagreements between XTRP and SVT that Nathan and Bill were searching for.  This suggests that there is another sync problem that is internal to the tracklist boards or in the alpha itself.
<!-- Author: Bill, Nathan, Matt -->


<!-- Date: Mon Aug 6 21:26:11 2001 -->
<pre>Isolation system tests.   Earlier today Matt  
took some runs with Iso in and saw that the  
data from all the other boards was fine,  but 
Isolist was not setting Moddone all the time so 
Startload would have to timeout.  When we started 
running this was happening about 5-10% of the  
Startloads.   We checked the Clique Seed and 
Clique EventDone signals on the DCAS backplane  
at the same time as Startload and Moddone, and 
saw that the lack of Moddone happened in events 
with a cal trigger and also in events without one. 
There is very little in common in the logic  
in these two cases,  the only thing that could 
make both happen is if Clique EventDone did not make it 
into relevant circuit on Isolist (this comes from  
the IsoClique card after receiving on the DCAS 
backplane).  This would also cause the card to  
go out of sync,  so maybe we're only chasing one 
problem and not two.  We put the 2nd Isolist card 
in the crate which has many wires soldered on, and 
saw that indeed Clique EventDone was not  
consistently making it to the relevant part of the  
Isolist logic.  It WAS on the DCAS backplane  
consistently,  so we replaced the IsoClique-&gt;Isolist 
fiber, and also tried the spare IsoClique,  neither 
fixed the problem.  Looking at internal IsoClique 
signals perhaps uncovered the problem,  the  
EventDone signals did not behave as expected.  
A review of that logic is underway...    </pre>
<!-- Author: Steve K and Bill H. -->


<!-- Date: Mon Aug 6 21:32:14 2001 -->
<pre>L2 Meeting 8/6/01 
 
1. Check out Matt's new web page, noted in entry above. It 
is very useful for keeping track of runs. 
 
2. The Alpha had two failures this weekend. One was the usual 
Alpha no longer processing errors which is usually due to  
one of the boards sending data even when start_load is turned  
off. The alpha code will have another mod made to try and make 
things more robust against crashing - although this condition 
will likely end up with corrupt data in the TL2D bank for at 
least the next event.   
  The second problem was large deadtime from L2. This is likely 
because the Alpha was printing a debug message to the minicom 
window due to a board failure (such as BC mismatch between the 
SVT and Track boards). A note will be sent to the aces for how 
to check for and deal with this problem. 
 
3. XTRP-SVT synchro tests are ongoing. See entry above. 
 
4. Isolist works better than before, but still will ocasionally 
get out of sync. (See entry above). 
 
5. L1 board shows flaky behavior with some runs okay and others 
with part of the data corrupted. It is suggested that the problem 
is the "new" 2244 drivers can't sink enough current to drive 
the data and address bits to logic low levels. This will 
be investigated more and the other L1 board with the old drivers 
will be tried. 
 
6. Reces needs to test all 4 boards with new alpha code, as well 
as figure out the swapped cables. 
 
7. The plan. 
  Monday - continue Iso and XTRP-SVT tests. 
  Tuesday - Reces, L1, XTRP-SVT cont.. 
  Wed. Clist, Reces/DTO problems. 
  Thurs. Clist, .... 
 (We will request time with beam as needed - especially if 
errors cannot be reproduced standalone.) 
 
8. The new version of the alpha boards have problems with the 
bga socket. The D0 board had the socket replaced directly with  
the chip, and has been succesfully tested.  
 
9. It was a long meeting and I must have forgotten something....  </pre>
<!-- Author: Stephen -->


<!-- Date: Tue Aug 7 08:33:29 2001 -->
<pre>Placed the L1 interface board (SN01) with the old-style 
drivers in the top crate. Will look at the noise 
this might re-introduce on the backplane later  
with Peter.  Also, we will have to watch TrigMon  
over several days to see if the 16 bit bad data 
problem goes away. 
 
 </pre>
<!-- Author: Greg -->


<!-- Date: Tue Aug 7 08:35:47 2001 -->
<pre>Unmasked the CDF_ERRORR line in b0l2de00. 
Don't be suprised if you get errors!</pre>
<!-- Author: Greg -->


<!-- Date: Tue Aug 7 16:51:12 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-77&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-77  width='300' align='top'></td><td>Reading all Reces boards!</a></td></tr></table>
<!-- Author: masa, karen -->


<!-- Date: Tue Aug 7 17:06:20 2001 -->
<pre> 
 (1) We went to pit and confirmed that the cable labels at the SMXR side 
were correct. So we conclude that it was again caused by the miss labeling 
of the cables. 
 
 (2) We took data with L2_TORTURE trigger table which reads all 4 Reces boards. 
The configulatuion was with ccal, L1, L2, xtrp and svt + hardware evb. 
It gave DTO every events, however, we did see with the scope  
that Alpha read all Reces boards. (See above picture. Actually the gif  
file was crashed but you can see 12 ddone's correspond to read Reces).  
 
 Then we changed the L1A rate to be ~10 Hz by changing the L1 prescale 
while pausing the Run imediately after run starting. Note that since we used 
the hardware evb, there were almost no deadtime  under the configulation. 
We succeed to take 5K data without DTO, and TL2D contents looks reasonable. 
However when we looked at the timing with scope, we have never seen the 
evidence that alpha read Reces... We were pretty confused. 
We want to continue the study with Stephen on Wednsday afternoon. 
 
</pre>
<!-- Author: masa, karen -->


<!-- Date: Tue Aug 7 18:12:55 2001 -->
<pre>I stopped spymon on SVT05, and tested the fer codes, which is modified to change the SVTY bank format.  Asked the ace to run it with hardEVB for a while. Note that I haven't update the cvs repository. Next reboot of the crate will lose the changes.  
 
Run number is 123039</pre>
<!-- Author: Yanwen -->


<!-- Date: Tue Aug 7 19:22:20 2001 -->
<pre>RECES is pulling CDF_ERROR! 
See accompanying scope pictures. 
</pre>
<!-- Author: Greg, Matt, David, Bill -->
<!-- Comment: Tue Aug  7 19;35;10 comment by...same as above -->
Note that we started by removing all boards (except tracer).
Nothing pulled CDF_ERR* when we had the alpha, XTRPlist, SVTlist,
Clist, and L1List.   When we plugged in the Reces closest to the
alpha, we repeatably had the problem.  We are leaving Reces out
for now.
<!-- Date: Tue Aug 7 19:32:47 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-79&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-79  width='300' align='top'></td><td>The  yellow trace is from the backplane.  It is not a TTL level so is probably a glitch.  This then shows up as a TTL signal on CDF_ERR*.</a></td></tr></table>
<!-- Author: same as above -->



<!-- Date: Tue Aug 7 20:49:37 2001 -->
<p> 
XTRP/SVT/L2 matching studies 
<p> 
Took run 123082 with XTRP, SVT06-07, and L2DECISION; XTRP was sending fake tracks to SVT and L2.  Both SVTD and TL2D were reading out the track list and bunch counter from XTRP.  TrigMon reported 1 bc mismatch and ~20 mismatches between track list data in XTRD and TL2D in about 3220 events.  Between TL2D and SVTD TrigMon reported a large number of errors, but this may be because the SVTD accessors used in the TrigMon code have problems with data in XTRD format. 
<p> 
Hand scanning the first 10 events in the run showed no mismatches between the track list or bc's in SVTD-TL2D-XTRD.
<!-- Author: Nathan, Bill, Matt -->


<!-- Date: Tue Aug 7 21:05:30 2001 -->
We took a few runs using XTRP, SVT, and once L2, to check what 
XTRP sends on the LVDS cables to the 2nd floor.  Nathan  
configured XTRP in "RAM pipe" mode, which requires setting the 
RC "extra 1" value to 1 and loading some RAMs via CDFVME  
between cold start and activate.  It was also necessary to check 
the "token" state on each pipeline in a CDFVME XTRP expert menu to check that everybody saw "2", and if not, to rerun the cold start.  (If this succeeds, then XTRP sends in RAM pipe mode what Nathan expects it to send, at least according to several hand 
scans of SVT spy buffer data examined during pauses in the run.)  This 
was all a feature of the "RAM pipe" test mode, which plays out 
fake tracks from internal XTRP RAMs, and not anything that would 
affect the coldstart in normal data taking. 
<p> 
SVT was configured (a) to pull CDF error if the wrong BC came up the cable and (b) to write the XTRP track list directly into 
the SVTD bank.  This allows us to check the data sent upstairs 
by the XTRP clock/control board against the data read out from 
the individual data boards into XTRD. 
<p> 
Run 123021 was taken in this configuration, with XTRP+SVT. 
We used the SEVB, calib continuous, auto L2A. 
<p> 
For run 123082, we also added L2DE00, so that we could check 
the data path into TL2D, and used L2 processor + physics trigger table.  In this case, the XTRP data are 
expected to match exactly what are in XTRD and SVTD; the SVT 
data should match in BC but otherwise are unrelated fake data. 
<p> 
In neither of these runs (nor in numerous earlier runs using 
XTRP+SVT alone) did we ever see a BC disagreement between XTRP 
and SVT's internal calculation from the CDF backplane signals. 
Thus, we will still need an inclusive test run with beam to 
track down the extra end-event words sent to the 2nd floor  
during beam conditions. 
<p> 
Matt was able to monitor the progress of run 123082 in real 
time.  He reported ~15/3000 events disagreeing in number of 
XTRP tracks between TL2D and XTRD, and one event disagreeing 
in BC.  TrigMon reports 2/3 of events have BC mismatch between 
SVTD and TL2D, but this seems to be contradicted by an initial 
hand scan of the data. 
<p> 
We will follow up here with results of various offline analyses. 
<p>
<!-- Author: Bill, Nathan, Matt -->
<!-- Comment: Tue Aug  7 22;38;35 comment by...Bill -->
<p>
<pre>

I looked at XTRD and SVTD for run 123082.  I have not yet had time to look at TL2D.  SVTD and XTRD agree perfectly for all 7708 events, with these exceptions:

event 20: xtrp card 8 has bc=18, expect 53
event 242: xtrp card 5 has bc=6d, expect 18
event 315: xtrp card 5 has bc=26, expect 51
... I won't bother reporting these anymore ...
event 423: one track has one bad curvature bit
event 921: same
event 2398: svt sees 2 tracks, expect 3; there are
BC errors in events 2396 and 2399 within XTRP
event 2528: one BC error, one track with a few bad bits
event 2744: ditto
event 4190: one track with bad bits; one track not seen by SVT
event 5014: ditto
events 5977, 5980: different kind of BC error?
6103: one bad track, one bad BC


</pre>


<!-- Date: Wed Aug 8 00:03:34 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Paged by ace. svt00 and svt03 are complaining: 
 
TRACER: VISIONopen Name=geo32:/slot=2 
TRACER: done enabled 
stderr: TRIG_svt_coldstart 
FER_E_SVT, (info) hc=4252591880 mc=1660345829 
sc0(slot3,spy_w00w01): hwSet=nosvx 
hf(slot4, hf_w00_b0b1): mapSet=default hwSet=nosvx wedge=0 
hf(slot4, hf_w00_b0b1): channelMask=0x0 streamMask=0x0 streamKill=0x3ff 
 
BEWARE!! 
 openBoard called for 35 (HF) but is 31 (AMB) 
FER_E_SVT, hf(slot4, hf_w00_b0b1): unexpected board type in ID PROM 
 
  svtvme_hf_coldstart returns -200 
 
It looks like two HF have existential problems: 
one (b0svt00 slot 4) thinks to be an AM board,  
the other (b0svt03 slot 4) thinks to be an inexistent  
board type. 
 
Someone changed something somewhere without letting someone 
else knowing? Maybe playing with the ID proms or with 
the configuration software?!?? 
 
Don't think it's indispensable to solve the problem at this time at night without beam, but I think this is an indication that we should have much better policies for letting know the person 
in charge what's being changed (maybe a logbook entry?). 
 
I'll tell the ace to leave SVT out for the night. 
If someone has an explanation for this, please let me know!</pre></td></tr></td></table>
<!-- Author: Alex -->


<!-- Date: Wed Aug 8 00:07:16 2001 -->
<pre>Ok, ok... just noticed that the RUN led in both HF 
were lit.... so I decided that I wanted them to reload 
their firmware. Unplugged the two boards and plugged 
them back. Now everything works fine and i am giving 
back the crates to the ace. 
 
Can someone (Bill?) explain what happened?</pre>
<!-- Author: Alex -->
<!-- Comment: Wed Aug  8 13;03;04 comment by...Bill -->
Interesting.  Earlier in the day, I ran one of my old (hopefully
soon to be obsolete) HF test programs to check the firmware
version in b0svt00/4 and b0svt03/4.  This program must have
inadvertently left the HF in a bad state, which is a bit of a
surprise to me.  If you need to do a firmware reload of a HF
by remote control, simply write BOOT to the BRAIN register, i.e.
write a 3 to address 0, then wait about 20 seconds.  Sorry about
that, and good work identifying the problem.  (I'm sure you
would have telephoned if you hadn't figured it out, which also
would have been fine.)


<!-- Comment: Wed Aug  8 13;05;39 comment by...Bill -->
If you're wondering technically how this can happen, it is that
the part of the ID PROM that does not depend on the DIP switches
(i.e. which HF is this one) is stored in the FRAM, which can only
be read when the FRAM is in "read array" mode.  It is nearly
always in "read array" mode, but it is possible to do VME
operations that leave it in another mode.  When the board does
a "boot", it asserts a reset pin on the FRAM, which puts the
FRAM into read mode even if VME commands have left it in a bad
state.  So a boot is sufficient but almost never necessary.



<!-- Date: Wed Aug 8 14:43:56 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-80&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-80  width='300' align='top'></td><td>Number of tracks in XTRD vs XTRP tracks in TL2D.</a></td></tr></table>
<!-- Author: Matt -->
<!-- Comment: Wed Aug  8 15;06;28 comment by...Matt -->
Plot from run 123082 taken <a href=
'/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=14&frame=2&anchor=21:05:30'>yesterday</a>.  There are two distinct errors.
<p>
(1) In the three events with more tracks in XTRD than in TL2D (triggers 2398, 4190, and 5014), the TL2D tracklist agrees with the tracklist written out in the SVTD bank.  So the problem is on the XTRP end of the cable: somehow XTRP never sent those tracks.  
<p>
(2) The pattern of events with more tracks in TL2D than XTRD does not agree with the tracklist in SVTD, and is therefore on the L2 side of the cable.  The data in TL2D suggests that the XTRPlist board sent 5 repeated tracks in an extra magic bus word to the alpha: the tracks always repeat in sets of 5 tracks (only in events with > 5 tracks), and the number of magic bus words agrees with the number of XTRP tracks sent (i.e 24 tracks = 5 mb words).

<!-- Date: Wed Aug 8 17:23:30 2001 -->

<p>
<pre>

Analyzed all 7708 events recorded in run 123082

In 7645/7708 events, xtrd, svtd(copy of xtrp data), and tl2d have same tracks

In 3590/7708 events, correct BC is recorded in wrong word in TL2D

In every event, BC recorded in TL2D (both SVT and XTRP) is correct,
though about half of the time, it is in 5th word from end instead of
3rd word from end of SVT data section; I think this is connected to
the fact that the reported number of tracks is always even.  (Good
thing it's a 2-track trigger?!)

In 31/7708 events, one XTRP data board reads out wrong BC.

In 59/7708 events, there were extra tracks in the TL2D bank that were not
present in either SVTD or XTRD.

In 4/7708 events, the SVTD and TL2D track lists agreed, but did not
agree with XTRD.  These include a corrupted curvature field in one 
track on events 423, 921; one missing track on events 2398, 4190.

Track list disagreements:

xtrp svtd tl2d disagree for event 40
svtd: 20a000 20a0c0 20a180 20a240 20a300 20a3c0 20a480 20a540 20a600
xtrd: 20a000 20a0c0 20a180 20a240 20a300 20a3c0 20a480 20a540 20a600
tl2d: 20a000 20a0c0 20a180 20a240 20a300 20a000 20a0c0 20a180 20a240 20a300 20a000 20a0c0 20a180 20a240 20a300 20a000 20a0c0 20a180 20a240 20a300 20a3c0 20a480 20a540 20a600
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 119
svtd: 205000 2050c0 205180 205240 205300
xtrd: 205000 2050c0 205180 205240 205300
tl2d: 205000 2050c0 205180 205240 205300 205000 2050c0 205180 205240 205300
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 139
svtd: 20b000 20b0c0 20b180 20b240 20b300 20b3c0 20b480 20b540 20b600 20b6c0
xtrd: 20b000 20b0c0 20b180 20b240 20b300 20b3c0 20b480 20b540 20b600 20b6c0
tl2d: 20b000 20b0c0 20b180 20b240 20b300 20b3c0 20b480 20b540 20b600 20b6c0 20b3c0 20b480 20b540 20b600 20b6c0 20b3c0 20b480 20b540 20b600 20b6c0
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 140
svtd: 20c000 20c0c0 20c180 20c240 20c300 20c3c0 20c480 20c540 20c600 20c6c0 20c780
xtrd: 20c000 20c0c0 20c180 20c240 20c300 20c3c0 20c480 20c540 20c600 20c6c0 20c780
tl2d: 20c000 20c0c0 20c180 20c240 20c300 20c3c0 20c480 20c540 20c600 20c6c0 20c3c0 20c480 20c540 20c600 20c6c0 20c3c0 20c480 20c540 20c600 20c6c0 20c3c0 20c480 20c540 20c600 20c6c0 20c780
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 146
svtd: 208000 2080c0 208180 208240 208300 2083c0 208480
xtrd: 208000 2080c0 208180 208240 208300 2083c0 208480
tl2d: 208000 2080c0 208180 208240 208300 208000 2080c0 208180 208240 208300 208000 2080c0 208180 208240 208300 2083c0 208480
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 147
svtd: 209000 2090c0 209180 209240 209300 2093c0 209480 209540
xtrd: 209000 2090c0 209180 209240 209300 2093c0 209480 209540
tl2d: 209000 2090c0 209180 209240 209300 209000 2090c0 209180 209240 209300 209000 2090c0 209180 209240 209300 2093c0 209480 209540
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 241
svtd: 205000 2050c0 205180 205240 205300
xtrd: 205000 2050c0 205180 205240 205300
tl2d: 205000 2050c0 205180 205240 205300 205000 2050c0 205180 205240 205300
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 315
svtd: 20b000 20b0c0 20b180 20b240 20b300 20b3c0 20b480 20b540 20b600 20b6c0
xtrd: 20b000 20b0c0 20b180 20b240 20b300 20b3c0 20b480 20b540 20b600 20b6c0
tl2d: 20b000 20b0c0 20b180 20b240 20b300 20b3c0 20b480 20b540 20b600 20b6c0 20b3c0 20b480 20b540 20b600 20b6c0 20b3c0 20b480 20b540 20b600 20b6c0
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 418
svtd: 20c000 20c0c0 20c180 20c240 20c300 20c3c0 20c480 20c540 20c600 20c6c0 20c780
xtrd: 20c000 20c0c0 20c180 20c240 20c300 20c3c0 20c480 20c540 20c600 20c6c0 20c780
tl2d: 20c000 20c0c0 20c180 20c240 20c300 20c3c0 20c480 20c540 20c600 20c6c0 20c3c0 20c480 20c540 20c600 20c6c0 20c3c0 20c480 20c540 20c600 20c6c0 20c780
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 423
svtd: 206000 2060c0 206180 20c240 206300 2063c0
xtrd: 206000 2060c0 206180 206240 206300 2063c0
tl2d: 206000 2060c0 206180 20c240 206300 2063c0
classification: XTRP sent bad data

xtrp svtd tl2d disagree for event 914
svtd: 205000 2050c0 205180 205240 205300
xtrd: 205000 2050c0 205180 205240 205300
tl2d: 205000 2050c0 205180 205240 205300 205000 2050c0 205180 205240 205300 205000 2050c0 205180 205240 205300 205000 2050c0 205180 205240 205300
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 917
svtd: 205000 2050c0 205180 205240 205300
xtrd: 205000 2050c0 205180 205240 205300
tl2d: 205000 2050c0 205180 205240 205300 205000 2050c0 205180 205240 205300 205000 2050c0 205180 205240 205300
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 918
svtd: 206000 2060c0 206180 206240 206300 2063c0
xtrd: 206000 2060c0 206180 206240 206300 2063c0
tl2d: 206000 2060c0 206180 206240 206300 206000 2060c0 206180 206240 206300 206000 2060c0 206180 206240 206300 2063c0
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 921
svtd: 207000 2070c0 207180 207240 207300 2073c0 207480
xtrd: 207000 2070c0 207180 205240 207300 2073c0 207480
tl2d: 207000 2070c0 207180 207240 207300 2073c0 207480
classification: XTRP sent bad data

xtrp svtd tl2d disagree for event 1029
svtd: 20c000 20c0c0 20c180 20c240 20c300 20c3c0 20c480 20c540 20c600 20c6c0 20c780
xtrd: 20c000 20c0c0 20c180 20c240 20c300 20c3c0 20c480 20c540 20c600 20c6c0 20c780
tl2d: 20c000 20c0c0 20c180 20c240 20c300 20c3c0 20c480 20c540 20c600 20c6c0 20c3c0 20c480 20c540 20c600 20c6c0 20c3c0 20c480 20c540 20c600 20c6c0 20c3c0 20c480 20c540 20c600 20c6c0 20c780
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 1247
svtd: 207000 2070c0 207180 207240 207300 2073c0 207480
xtrd: 207000 2070c0 207180 207240 207300 2073c0 207480
tl2d: 207000 2070c0 207180 207240 207300 207000 2070c0 207180 207240 207300 207000 2070c0 207180 207240 207300 207000 2070c0 207180 207240 207300 2073c0 207480
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 1266
svtd: 20c000 20c0c0 20c180 20c240 20c300 20c3c0 20c480 20c540 20c600 20c6c0 20c780
xtrd: 20c000 20c0c0 20c180 20c240 20c300 20c3c0 20c480 20c540 20c600 20c6c0 20c780
tl2d: 20c000 20c0c0 20c180 20c240 20c300 20c3c0 20c480 20c540 20c600 20c6c0 20c3c0 20c480 20c540 20c600 20c6c0 20c3c0 20c480 20c540 20c600 20c6c0 20c780
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 1272
svtd: 207000 2070c0 207180 207240 207300 2073c0 207480
xtrd: 207000 2070c0 207180 207240 207300 2073c0 207480
tl2d: 207000 2070c0 207180 207240 207300 207000 2070c0 207180 207240 207300 2073c0 207480
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 1273
svtd: 20c000 20c0c0 20c180 20c240 20c300 20c3c0 20c480 20c540 20c600 20c6c0 20c780
xtrd: 20c000 20c0c0 20c180 20c240 20c300 20c3c0 20c480 20c540 20c600 20c6c0 20c780
tl2d: 20c000 20c0c0 20c180 20c240 20c300 20c3c0 20c480 20c540 20c600 20c6c0 20c3c0 20c480 20c540 20c600 20c6c0 20c3c0 20c480 20c540 20c600 20c6c0 20c780
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 1339
svtd: 20b000 20b0c0 20b180 20b240 20b300 20b3c0 20b480 20b540 20b600 20b6c0
xtrd: 20b000 20b0c0 20b180 20b240 20b300 20b3c0 20b480 20b540 20b600 20b6c0
tl2d: 20b000 20b0c0 20b180 20b240 20b300 20b3c0 20b480 20b540 20b600 20b6c0 20b3c0 20b480 20b540 20b600 20b6c0 20b3c0 20b480 20b540 20b600 20b6c0
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 1340
svtd: 20c000 20c0c0 20c180 20c240 20c300 20c3c0 20c480 20c540 20c600 20c6c0 20c780
xtrd: 20c000 20c0c0 20c180 20c240 20c300 20c3c0 20c480 20c540 20c600 20c6c0 20c780
tl2d: 20c000 20c0c0 20c180 20c240 20c300 20c3c0 20c480 20c540 20c600 20c6c0 20c3c0 20c480 20c540 20c600 20c6c0 20c780
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 1341
svtd: 206000 2060c0 206180 206240 206300 2063c0
xtrd: 206000 2060c0 206180 206240 206300 2063c0
tl2d: 206000 2060c0 206180 206240 206300 206000 2060c0 206180 206240 206300 2063c0
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 1342
svtd: 207000 2070c0 207180 207240 207300 2073c0 207480
xtrd: 207000 2070c0 207180 207240 207300 2073c0 207480
tl2d: 207000 2070c0 207180 207240 207300 207000 2070c0 207180 207240 207300 207000 2070c0 207180 207240 207300 207000 2070c0 207180 207240 207300 2073c0 207480
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 1380
svtd: 205000 2050c0 205180 205240 205300
xtrd: 205000 2050c0 205180 205240 205300
tl2d: 205000 2050c0 205180 205240 205300 205000 2050c0 205180 205240 205300 205000 2050c0 205180 205240 205300 205000 2050c0 205180 205240 205300
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 1835
svtd: 208000 2080c0 208180 208240 208300 2083c0 208480
xtrd: 208000 2080c0 208180 208240 208300 2083c0 208480
tl2d: 208000 2080c0 208180 208240 208300 208000 2080c0 208180 208240 208300 208000 2080c0 208180 208240 208300 208000 2080c0 208180 208240 208300 2083c0 208480
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 1836
svtd: 209000 2090c0 209180 209240 209300 2093c0 209480 209540
xtrd: 209000 2090c0 209180 209240 209300 2093c0 209480 209540
tl2d: 209000 2090c0 209180 209240 209300 209000 2090c0 209180 209240 209300 209000 2090c0 209180 209240 209300 209000 2090c0 209180 209240 209300 2093c0 209480 209540
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 2024
svtd: 207000 2070c0 207180 207240 207300 2073c0 207480
xtrd: 207000 2070c0 207180 207240 207300 2073c0 207480
tl2d: 207000 2070c0 207180 207240 207300 207000 2070c0 207180 207240 207300 207000 2070c0 207180 207240 207300 2073c0 207480
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 2027
svtd: 207000 2070c0 207180 207240 207300 2073c0 207480
xtrd: 207000 2070c0 207180 207240 207300 2073c0 207480
tl2d: 207000 2070c0 207180 207240 207300 207000 2070c0 207180 207240 207300 207000 2070c0 207180 207240 207300 207000 2070c0 207180 207240 207300 207000 2070c0 207180 207240 207300 2073c0 207480
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 2028
svtd: 208000 2080c0 208180 208240 208300 2083c0 208480
xtrd: 208000 2080c0 208180 208240 208300 2083c0 208480
tl2d: 208000 2080c0 208180 208240 208300 208000 2080c0 208180 208240 208300 208000 2080c0 208180 208240 208300 208000 2080c0 208180 208240 208300 208000 2080c0 208180 208240 208300 2083c0 208480
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 2205
svtd: 205000 2050c0 205180 205240 205300
xtrd: 205000 2050c0 205180 205240 205300
tl2d: 205000 2050c0 205180 205240 205300 205000 2050c0 205180 205240 205300
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 2206
svtd: 206000 2060c0 206180 206240 206300 2063c0
xtrd: 206000 2060c0 206180 206240 206300 2063c0
tl2d: 206000 2060c0 206180 206240 206300 206000 2060c0 206180 206240 206300 2063c0
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 2207
svtd: 20b000 20b0c0 20b180 20b240 20b300 20b3c0 20b480 20b540 20b600 20b6c0
xtrd: 20b000 20b0c0 20b180 20b240 20b300 20b3c0 20b480 20b540 20b600 20b6c0
tl2d: 20b000 20b0c0 20b180 20b240 20b300 20b3c0 20b480 20b540 20b600 20b6c0 20b3c0 20b480 20b540 20b600 20b6c0
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 2208
svtd: 20c000 20c0c0 20c180 20c240 20c300 20c3c0 20c480 20c540 20c600 20c6c0 20c780
xtrd: 20c000 20c0c0 20c180 20c240 20c300 20c3c0 20c480 20c540 20c600 20c6c0 20c780
tl2d: 20c000 20c0c0 20c180 20c240 20c300 20c3c0 20c480 20c540 20c600 20c6c0 20c3c0 20c480 20c540 20c600 20c6c0 20c3c0 20c480 20c540 20c600 20c6c0 20c780
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 2398
svtd: 203000 203180
xtrd: 203000 2030c0 203180
tl2d: 203000 203180
classification: XTRP sent bad data

xtrp svtd tl2d disagree for event 2493
svtd: 206000 2060c0 206180 206240 206300 2063c0
xtrd: 206000 2060c0 206180 206240 206300 2063c0
tl2d: 206000 2060c0 206180 206240 206300 206000 2060c0 206180 206240 206300 206000 2060c0 206180 206240 206300 206000 2060c0 206180 206240 206300 2063c0
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 2528
svtd: 205000 2050c0 205180 205240 27c300
xtrd: 205000 2050c0 205180 205240 205300
tl2d: 205000 2050c0 205180 205240 27c300 205000 2050c0 205180 205240 27c300 205000 2050c0 205180 205240 27c300
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 2529
svtd: 206000 2060c0 206180 206240 206300 2063c0
xtrd: 206000 2060c0 206180 206240 206300 2063c0
tl2d: 206000 2060c0 206180 206240 206300 206000 2060c0 206180 206240 206300 206000 2060c0 206180 206240 206300 206000 2060c0 206180 206240 206300 2063c0
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 2532
svtd: 206000 2060c0 206180 206240 206300 2063c0
xtrd: 206000 2060c0 206180 206240 206300 2063c0
tl2d: 206000 2060c0 206180 206240 206300 206000 2060c0 206180 206240 206300 2063c0
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 2533
svtd: 207000 2070c0 207180 207240 207300 2073c0 207480
xtrd: 207000 2070c0 207180 207240 207300 2073c0 207480
tl2d: 207000 2070c0 207180 207240 207300 207000 2070c0 207180 207240 207300 207000 2070c0 207180 207240 207300 207000 2070c0 207180 207240 207300 2073c0 207480
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 2536
svtd: 209000 2090c0 209180 209240 209300 2093c0 209480 209540
xtrd: 209000 2090c0 209180 209240 209300 2093c0 209480 209540
tl2d: 209000 2090c0 209180 209240 209300 209000 2090c0 209180 209240 209300 2093c0 209480 209540
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 2538
svtd: 20b000 20b0c0 20b180 20b240 20b300 20b3c0 20b480 20b540 20b600 20b6c0
xtrd: 20b000 20b0c0 20b180 20b240 20b300 20b3c0 20b480 20b540 20b600 20b6c0
tl2d: 20b000 20b0c0 20b180 20b240 20b300 20b3c0 20b480 20b540 20b600 20b6c0 20b3c0 20b480 20b540 20b600 20b6c0 20b3c0 20b480 20b540 20b600 20b6c0
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 2570
svtd: 20a000 20a0c0 20a180 20a240 20a300 20a3c0 20a480 20a540 20a600
xtrd: 20a000 20a0c0 20a180 20a240 20a300 20a3c0 20a480 20a540 20a600
tl2d: 20a000 20a0c0 20a180 20a240 20a300 20a000 20a0c0 20a180 20a240 20a300 20a000 20a0c0 20a180 20a240 20a300 20a3c0 20a480 20a540 20a600
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 2743
svtd: 205000 2050c0 205180 205240 205300
xtrd: 205000 2050c0 205180 205240 205300
tl2d: 205000 2050c0 205180 205240 205300 205000 2050c0 205180 205240 205300 205000 2050c0 205180 205240 205300 205000 2050c0 205180 205240 205300 205000 2050c0 205180 205240 205300
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 2744
svtd: 206000 2060c0 206180 206240 206300 20c3c0
xtrd: 206000 2060c0 206180 206240 206300 2063c0
tl2d: 206000 2060c0 206180 206240 206300 206000 2060c0 206180 206240 206300 206000 2060c0 206180 206240 206300 20c3c0
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 4117
svtd: 207000 2070c0 207180 207240 207300 2073c0 207480
xtrd: 207000 2070c0 207180 207240 207300 2073c0 207480
tl2d: 207000 2070c0 207180 207240 207300 207000 2070c0 207180 207240 207300 207000 2070c0 207180 207240 207300 2073c0 207480
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 4184
svtd: 20b000 20b0c0 20b180 20b240 20b300 20b3c0 20b480 20b540 20b600 20b6c0
xtrd: 20b000 20b0c0 20b180 20b240 20b300 20b3c0 20b480 20b540 20b600 20b6c0
tl2d: 20b000 20b0c0 20b180 20b240 20b300 20b3c0 20b480 20b540 20b600 20b6c0 20b3c0 20b480 20b540 20b600 20b6c0
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 4186
svtd: 206000 2060c0 206180 206240 206300 2063c0
xtrd: 206000 2060c0 206180 206240 206300 2063c0
tl2d: 206000 2060c0 206180 206240 206300 206000 2060c0 206180 206240 206300 2063c0
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 4187
svtd: 207000 2070c0 207180 207240 207300 2073c0 207480
xtrd: 207000 2070c0 207180 207240 207300 2073c0 207480
tl2d: 207000 2070c0 207180 207240 207300 207000 2070c0 207180 207240 207300 207000 2070c0 207180 207240 207300 2073c0 207480
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 4190
svtd: 20c000 20c0c0 20c180 20c240 20c300 20c3c0 20c480 20c600 20c6c0 20c780
xtrd: 20c000 20c0c0 20c180 20c240 20c300 20c3c0 20c480 20c540 20c600 20c6c0 20c780
tl2d: 20c000 20c0c0 20c180 20c240 20c300 20c3c0 20c480 20c600 20c6c0 20c780
classification: XTRP sent bad data

xtrp svtd tl2d disagree for event 4635
svtd: 20a000 20a0c0 20a180 20a240 20a300 20a3c0 20a480 20a540 20a600
xtrd: 20a000 20a0c0 20a180 20a240 20a300 20a3c0 20a480 20a540 20a600
tl2d: 20a000 20a0c0 20a180 20a240 20a300 20a000 20a0c0 20a180 20a240 20a300 20a3c0 20a480 20a540 20a600
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 4636
svtd: 20b000 20b0c0 20b180 20b240 20b300 20b3c0 20b480 20b540 20b600 20b6c0
xtrd: 20b000 20b0c0 20b180 20b240 20b300 20b3c0 20b480 20b540 20b600 20b6c0
tl2d: 20b000 20b0c0 20b180 20b240 20b300 20b3c0 20b480 20b540 20b600 20b6c0 20b3c0 20b480 20b540 20b600 20b6c0 20b3c0 20b480 20b540 20b600 20b6c0
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 5014
svtd: 20b000 20b0c0 20b180 20b240 20b300 20b3c0 20b480 20b600 20b6c0
xtrd: 20b000 20b0c0 20b180 20b240 20b300 20b3c0 20b480 20b540 20b600 20b6c0
tl2d: 20b000 20b0c0 20b180 20b240 20b300 20b3c0 20b480 20b600 20b6c0
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 5101
svtd: 205000 2050c0 205180 205240 205300
xtrd: 205000 2050c0 205180 205240 205300
tl2d: 205000 2050c0 205180 205240 205300 205000 2050c0 205180 205240 205300
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 5102
svtd: 206000 2060c0 206180 206240 206300 2063c0
xtrd: 206000 2060c0 206180 206240 206300 2063c0
tl2d: 206000 2060c0 206180 206240 206300 206000 2060c0 206180 206240 206300 206000 2060c0 206180 206240 206300 2063c0
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 5507
svtd: 20a000 20a0c0 20a180 20a240 20a300 20a3c0 20a480 20a540 20a600
xtrd: 20a000 20a0c0 20a180 20a240 20a300 20a3c0 20a480 20a540 20a600
tl2d: 20a000 20a0c0 20a180 20a240 20a300 20a000 20a0c0 20a180 20a240 20a300 20a3c0 20a480 20a540 20a600
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 5508
svtd: 20b000 20b0c0 20b180 20b240 20b300 20b3c0 20b480 20b540 20b600 20b6c0
xtrd: 20b000 20b0c0 20b180 20b240 20b300 20b3c0 20b480 20b540 20b600 20b6c0
tl2d: 20b000 20b0c0 20b180 20b240 20b300 20b3c0 20b480 20b540 20b600 20b6c0 20b3c0 20b480 20b540 20b600 20b6c0
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 5977
svtd: 206000 2060c0 206180 206240 206300 2063c0
xtrd: 206000 2060c0 206180 206240 206300 2063c0
tl2d: 206000 2060c0 206180 206240 206300 206000 2060c0 206180 206240 206300 206000 2060c0 206180 206240 206300 2063c0
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 5978
svtd: 207000 2070c0 207180 207240 207300 2073c0 207480
xtrd: 207000 2070c0 207180 207240 207300 2073c0 207480
tl2d: 207000 2070c0 207180 207240 207300 207000 2070c0 207180 207240 207300 207000 2070c0 207180 207240 207300 2073c0 207480
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 5981
svtd: 207000 2070c0 207180 207240 207300 2073c0 207480
xtrd: 207000 2070c0 207180 207240 207300 2073c0 207480
tl2d: 207000 2070c0 207180 207240 207300 207000 2070c0 207180 207240 207300 2073c0 207480
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 5982
svtd: 208000 2080c0 208180 208240 208300 2083c0 208480
xtrd: 208000 2080c0 208180 208240 208300 2083c0 208480
tl2d: 208000 2080c0 208180 208240 208300 208000 2080c0 208180 208240 208300 208000 2080c0 208180 208240 208300 2083c0 208480
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 6103
svtd: 209000 2090c0 209180 209240 205300 2093c0 209480 209540
xtrd: 209000 2090c0 209180 209240 209300 2093c0 209480 209540
tl2d: 209000 2090c0 209180 209240 205300 209000 2090c0 209180 209240 205300 209000 2090c0 209180 209240 205300 209000 2090c0 209180 209240 205300 209000 2090c0 209180 209240 205300 2093c0 209480 209540
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 6104
svtd: 20a000 20a0c0 20a180 20a240 20a300 20a3c0 20a480 20a540 20a600
xtrd: 20a000 20a0c0 20a180 20a240 20a300 20a3c0 20a480 20a540 20a600
tl2d: 20a000 20a0c0 20a180 20a240 20a300 20a000 20a0c0 20a180 20a240 20a300 20a000 20a0c0 20a180 20a240 20a300 20a3c0 20a480 20a540 20a600
classification: TL2D extra tracks

xtrp svtd tl2d disagree for event 7015
svtd: 207000 2070c0 207180 207240 207300 2073c0 207480
xtrd: 207000 2070c0 207180 207240 207300 2073c0 207480
tl2d: 207000 2070c0 207180 207240 207300 207000 2070c0 207180 207240 207300 207000 2070c0 207180 207240 207300 207000 2070c0 207180 207240 207300 2073c0 207480
classification: TL2D extra tracks

</pre>
<p>

<!-- Author: Bill -->
<!-- Comment: Wed Aug  8 17;30;56 comment by...Bill -->
Oops, I misclassified (by hand) event 5014.  Sorry, Matt!



<!-- Date: Wed Aug 8 18:56:30 2001 -->
<pre>Time for a new L2 e-log page</pre>
<!-- Author: L2, SVT et al. -->