<!-- Title: 09:45:54  Mon Aug 20 2001 -->
<!-- Crewchief: L2, SVT people -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
Time to start a new page  


<!-- Date: Mon Aug 20 14:49:58 2001 -->
<pre>CLIST study: 
 
plan: 
first setup the system with old CLIST firmware, take one 
run and log some data; then download the new firmware, 
and do the same. 
 
Run 124269: 
 
run configuration: saved under Ace, called CLISTEST. 
all CCAL, L1CAL, L1GL, L2DEC. trigger table L2_torture[1,143], 
softEvb. running at about 10-20 Hz. CLIST has the old firmware 
(prom). 
 
from L2Mon and LA, things look ok at this low trigger rate. 
will capture a few plots next.</pre>
<!-- Author: Ted -->


<!-- Date: Mon Aug 20 14:56:19 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-109&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-109  width='300' align='top'></td><td>magic bus words vs interface boards (L1 interface and CLIST) for run 124269</a></td></tr></table>
<!-- Author: Ted Liu -->


<!-- Date: Mon Aug 20 14:57:52 2001 -->
<pre>note: for this test, only L1 interface board and CLIST 
are plugged in. all others unplugged.</pre>
<!-- Author: Ted -->


<!-- Date: Mon Aug 20 15:01:28 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-110&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-110  width='300' align='top'></td><td>L2Mon cluster validation for this run.</a></td></tr></table>
<!-- Author: Ted Liu -->


<!-- Date: Mon Aug 20 15:06:16 2001 -->
<pre>waiting for Eric James to give me his laptop, so that 
I can download the new CLIST firmware.....</pre>
<!-- Author: Ted -->


<!-- Date: Mon Aug 20 15:27:23 2001 -->
<pre>still waiting for Eric to show up... 
try plan B, will try to use Matt's laptop 
to download the firmware.  
will end this run, for this run, CLIST 
has the prom labelled 314. this run 
establishs that the setup is good, and 
everything looks ok at low rate. 
this run has 33149 evts so far. will end 
soon.</pre>
<!-- Author: Ted -->


<!-- Date: Mon Aug 20 15:35:43 2001 -->
<pre>Matt come with his Laptop. end this run at 38980 evts. 
 
</pre>
<!-- Author: Ted -->


<!-- Date: Mon Aug 20 15:44:48 2001 -->
<pre>ftp to umaxp1.physics.lsa.umich.edu 
cd pub/sync_fifo/, download sync_42.mcs. 
 
downloaded to CLIST. let's try a new run.... 
go through parition -&gt; coldstart once. 
run number is 124276, started ... 
will check LA and L2Mon...</pre>
<!-- Author: Ted -->


<!-- Date: Mon Aug 20 16:00:41 2001 -->
<pre>opps, the L2Mon for cluster validation shows problems 
for this run (CLIST with new firmware, everything else 
identical to previous run). see next plot. 
 
will let this run continue and collect more events... 
will go to L2 meeting now... </pre>
<!-- Author: Ted -->


<!-- Date: Mon Aug 20 16:01:13 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-111&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-111  width='300' align='top'></td><td>cluster validation for this run</a></td></tr></table>
<!-- Author: Ted -->


<!-- Date: Mon Aug 20 16:05:11 2001 -->
<pre>trigger scaler DTO, HRR</pre>
<!-- Author: Ted -->


<!-- Date: Mon Aug 20 16:45:43 2001 -->
<pre>Rick T wants CCAL crates for 20 mins. end this run 
at 45258 evts.  
 
and also captured an updated cluster validation plot. 
see below. 
 
he will give the crates back soon.</pre>
<!-- Author: Ted -->


<!-- Date: Mon Aug 20 16:47:21 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-112&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-112  width='300' align='top'></td><td>cluster validation plot, updated at the end of run.</a></td></tr></table>
<!-- Author: Ted -->


<!-- Date: Mon Aug 20 17:07:51 2001 -->
<pre>Rick T finished rebooting CCAL crates.  
I will take another run with hardware event 
builder, to increase the trigger rate. 
everything else will be the same as previous run. 
 
take L3 subfarm 8 - 15. the other half are taken 
by shift crew.</pre>
<!-- Author: Ted -->


<!-- Date: Mon Aug 20 17:30:55 2001 -->
<pre>the new run number is 124284. from L2Mon, 
the valid clusters in TL2D vs expected are 
all messed up. hmm...  
see plot below. 
 
Bill B. needs CCAL for calibration, for 20 mins. 
so end this run and give him all CCAL crates. 
end this run at 308980 events. 
</pre>
<!-- Author: Ted -->


<!-- Date: Mon Aug 20 17:38:43 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-113&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-113  width='300' align='top'></td><td>this is the cluster validation plot for  last run. will try take another run again after I get CCAL crates back.</a></td></tr></table>
<!-- Author: Ted -->


<!-- Date: Mon Aug 20 18:34:36 2001 -->
<pre>took another run (run #)124290. the same thing. 
Steve K. is here. so will use the setup for  
IsoList test from now.</pre>
<!-- Author: Ted -->


<!-- Date: Mon Aug 20 18:38:14 2001 -->
<pre>Summary of CLIST test today: 
 
CLIST (with new firmware) is happy at low trigger rate  
(~10Hz or so), but not happy at higher rate (~300Hz or so). 
 
 
</pre>
<!-- Author: Ted -->
<!-- Comment: Mon Aug 20 21;37;44 comment by...Ted -->
<pre>actually at low rate(~10Hz L1A), CLIST with new firmware
had problems with eta and phi distribution, the valid
cluster looks ok.</pre>
<!-- Date: Mon Aug 20 18:45:33 2001 -->
<pre>start a new run for Steve K. unplugged CLIST, 
plugged in IsoList. otherwise, the setup is the same.</pre>
<!-- Author: Ted -->


<!-- Date: Mon Aug 20 19:20:16 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-114&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-114  width='300' align='top'></td><td>just found something very strange. for run 124291, which is for IsoList,  CLIST was unplugged. but from L2Mon, clutser validation still thinks there are data from CLIST ...? as if CLIST is still in the crate... what is going on with the L2Mon software for CLIST? could someone take a look?</a></td></tr></table>
<!-- Author: Ted -->


<!-- Date: Mon Aug 20 19:40:12 2001 -->
<pre>Steve K finished his test. I will take another run with 
CLIST again (but with old firmware), and restart the L2Mon,  
the idea is to compare old and new firmware at high rate 
(I didn't have a chance to test the old firmware at higher 
rate earlier with the same setup). 
 
unplug IsoList, plug back CLIST (remove jumper in the back). 
now CLIST has the old firmware. restart L2Mon, everything else the same.  
 
this run number is 124295. looking from L2Mon, cluster validation 
looks ok and we are running at 300 Hz or so.  
 
</pre>
<!-- Author: Ted -->


<!-- Date: Mon Aug 20 19:58:14 2001 -->
XTRP/SVT/L2 studies 
<p> 
Took 4M events CALIB_CONTINUOUS, Myron Mode, 1kHz L1A, only 
XTRP+SVT, no (S)EVB.  Never saw XTRP pipes out of sync; 
never saw SVT/XTRP mis-sync.  Most likely no tracks in 
any of these events. 
<p> 
Took 300K events L2_TORTURE, no (S)EVB, ~1kHz L2A, no L3, no 
tracks.  No sync problems seen inside XTRP or at SVT input. 
<p> 
Put L3/EVB back, but we had to drop SVT, because shift crew 
is reading out muon crates.  SVT will still see data and 
TSI signals.  
<!-- Author: Bill, Matt, Nathan -->
<!-- Comment: Mon Aug 20 20;34;35 comment by...B,M.N -->
<p>
Ran for a while (124296), wanted to change prescales, but we
couldn't pause, because R_C ran out of memory.  
<p>
Started 124297.  Increased prescales to get O(1%) 
deadtime, nice L2B usage.  Took 87K events.
<p>
Started 124298, with XTRP sending fake tracks from its
RAM pipes.
Buffer usage(%)=65/22/7/3, L1A=24kHz, readout=140Hz.


<!-- Comment: Mon Aug 20 20;37;46 comment by...B,M,N -->
<p>
Event 40521 (or a bit before) XTRP has one pipe out of whack, but
SVT hasn't seen a sync error yet.  (Usually it takes a while 
longer.)

<!-- Comment: Mon Aug 20 20;42;42 comment by...nmb -->
<p>
Did H/R/R to resync.  Then after event ~72K, SVT saw a sync
error, and XTRP pipes for boards 0-3 are all off by one.
<p>




<!-- Date: Mon Aug 20 21:45:54 2001 -->
<pre>Isolation Monday:  The confusion over Clique Done happening 
within 100 ns of a Clique Seed in next event appears fixed. 
Moddone was being set much more reliably as well, it was 
hard to find a failure but I managed to.  Overall at  
scope level the performance looked good,  but...  
1) There were two cases where both the L1 and Iso boards stopped sending data (only boards in crate).  I didn't investigate further, HRR fixed it.  2) Iso data still out-of-sync even 
in runs where both boards appeared to send data consistently. 
I need to correlate Clique Seed with IsoList Dstrobes to  
see this better. </pre>
<!-- Author: Steve K -->


<!-- Date: Tue Aug 21 00:07:11 2001 -->
We are sending data stand-alone from SVT crates to both XTRPlist and SVTlist.  So far, we're sending one track per event to 
SVTlist and just an end-event word to XTRPlist; later, we'll 
add XTRP pseudo-tracks. 
<p> 
Running L2_RATE_TEST trigger table, we stayed in sync (XTRPlist 
vs SVTlist) for 5000 events, then got out of sync, as reported 
by minicom from Alpha.  This was at ~1kHz L1A. 
<p> 
Running at ~10Hz, we are still in sync after 6300 events, but 
it's getting sort of boring. 
<p>  
<!-- Author: Bill, Ted, Matt -->
<!-- Comment: Tue Aug 21 00;17;21 comment by...Bill & Ted -->
14K events at 75 Hz, no problem.  We notice that we are only
using one TSI buffer.


<!-- Comment: Tue Aug 21 00;58;56 comment by...Bill & Ted -->
50K events at 350 Hz, OK.
<p>
700 Hz, almost instantly out of sync.
<p>
500 Hz, 800K events sync OK.
<p>
600 Hz, first time were out of sync by about 5-10 events from the outset, then we did Matt's trick of doing a double coldstart on just l2de00, and we were OK for 100K+ events; end run.
<p>
660 Hz, still OK after 45K+ events.


<!-- Comment: Tue Aug 21 01;19;06 comment by...By -->
760 Hz, 100K events, OK.  (Used Matt's trick again.)
<p>
at 1.5 kHz, sync fails consistently after ~10 seconds 
(a few runs in a row, even using Matt's trick).
<p>
By the way, Matt's trick should cure case of being out of
sync from very beginning, but should have nothing to do
with sync error starting after many events.
<p>


<!-- Comment: Tue Aug 21 01;31;07 comment by...b,t -->
<p>
With one buffer, we die within a couple of seconds at 400 Hz, but OK at 300 Hz.  With four buffers we died fairly quickly at
1500 Hz but were OK at 1000 Hz.  With two buffers, we died after
~20 seconds at 500 Hz.  We have a hint of a pattern, but not
fully consistent.



<!-- Date: Tue Aug 21 03:03:22 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-115&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-115  width='300' align='top'></td><td>looking at the backplane signals, under normal running condition when there is no bc mismatch: here is a scope picture showing(from top to bottom) start_load, L1A, dstroble, boss. where the first ds is from XTRPlist, the 2nd from SVTlist, as expected (ingore the labels on the picture). but for runs with bc mismatch or out of sync, the 2nd ds is very often missing. see next picture.</a></td></tr></table>
<!-- Author: Bill & Ted -->


<!-- Date: Tue Aug 21 03:07:20 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-116&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-116  width='300' align='top'></td><td>this one shows the 2nd ds missing (compare to previous one, and see comments there), and alpha time out (start_load will last for 600 us), indicating SVTlist didn't sent data for this L1A/start_load.</a></td></tr></table>
<!-- Author: Bill & Ted -->
<!-- Comment: Tue Aug 21 03;10;13 comment by...B&T -->
<pre>opps, wrong picture. it is the same as the other one.
the right one is below.</pre>


<!-- Date: Tue Aug 21 03:11:17 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-117&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-117  width='300' align='top'></td><td>this is the right picture, see comments above.</a></td></tr></table>
<!-- Author: Bill & Ted -->
<!-- Comment: Tue Aug 21 03;18;01 comment by...Bill&Ted -->
<pre>Matt looked at mod_done signal for SVTlist in this case,
and it is not set.</pre>


<!-- Date: Tue Aug 21 07:55:05 2001 -->
Trying to rehabilitate the L2 crate<p> 
Plugged in XTRPlist (slot 7), SVTlist (11), and L1 (12) with only XTRPlist and L1 cabled.  All slots above 13 were unjumpered.  Started a run with L2_RATE_TEST and calib continuous L1 triggers.  The alpha hung after 4780 events with the error:<p> 
Error: Number of svt words is -176<br> 
   Setting Number of svt words to 288<p> 
which is odd as SVTlist was not even cabled.  Message from alpha_check:<p> 
Error: Alpha is no longer processing at spot 7: Started Handshake with TSI<br> 
 TSI handshake bits are 4ffd0001<br> 
 TSI startload bits are 10101c6<br> 
 TSI MODDONE bits are 4197fcff<br> 
 Number of words for TL2D, buffer 0: db000000<br> 
 Number of words for TL2D, buffer 1: ffffffff<br> 
 Number of words for TL2D, buffer 2: fffffffb<br> 
 Number of words for TL2D, buffer 3: 30000<p> 
Try again, this time with all slots jumpered correctly and all three boards cabled.  Taken 20k events so far with no problems.  I will try and integrate b0l2de00 back into shift runs the next time they stop.
<!-- Author: Matt -->


<!-- Date: Wed Aug 22 12:48:59 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-118&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-119  width='300' align='top'></td><td>An indescribably stupid arrangement of $35000 worth of irreplacable SVT hardware.</a></td></tr></table>
<!-- Author: Ashmanskas -->


<!-- Date: Wed Aug 22 12:49:37 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-120&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-121  width='300' align='top'></td><td>Inconceivable, part 2</a></td></tr></table>
<!-- Author: Ashmanskas -->

<!-- Date: Wed Aug 22 13:07:38 2001 -->

<p>
As shown in this photo,
<p>
<a href=
'/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=16&frame=2&anchor=12:48:59'>
(photo) </a> 
<p>
I just found 7 SVT boards balanced in about the most precarious way I
could imagine, above the test stand.  I find it hard to understand the
moviation for this arrangement of $35000 worth of irreplacable hardware.
<p>
I sent an e-mail several weeks ago to everyone working on SVT, documenting
a rearrangement of the test stand that allows us to test every kind of SVT
board and also provides ample free slots for other kinds of tests.  Nobody
argued with that message.  My motivation was to make the test stand a
place where a suspect board could be quickly tested in an environment
similar to that of a real crate.  In particular, I wanted to be able to
run in the test stand the Hit Finder tests that were used to test the
boards when they first arrived in Chicago.  Matt Baumgart has been working
on integrating these tests into the svtvme library, so that anybody can
run them easily.
<p>
I believe I left the test stand in a state that would suit everyone's
needs, and until this morning I thought it was working.  If you think the
test stand arrangement does not suit your needs, please send comments to
svt@fnal.gov before moving boards.  Cables of course can be moved at any
time.
<p>
Now that we need to plug everything back in, I'll take this opportunity to
move the AMS/AMB/AMB to the left side of the crate, and the XTFA/B/B to
the right side of the crate, which makes more sense, but wasn't possible
before we received the second backplanino.
<p>
-Bill
<p>

<!-- Author: Bill -->


<!-- Date: Wed Aug 22 14:21:31 2001 -->
Yesterday data showed SVTD to have data in blocks 3 and 4 instead
of 1 and 2. Confusing a few people. This was traced to minbank
numbers having changed in the Hardware DB. My fault haveing not
checked things after Bill added two more SVT_L2 cards at my
request. Things should be fixed now. Next time RC is started
and SVT_FITTER_06 is booked SVTD should have again SVT data in
block 1 and XTRP data in block 2.
<!-- Author: Stefano -->



<!-- Date: Wed Aug 22 21:01:35 2001 -->
<pre>I have fixed the bugs in  Amboard #25 and Amboard #23 (NOT 
in AMboard #26, it works!). 
For Amboard #25 : 2 amplugs (#317, chip1,2,5,6 -1536 errors 
at r/w op; #383, chip 0 -165 erors at r/w op) 
for Amboard #23 : only one chip (#2) has 1 error at r/w op! 
I have changed amplugs for Amboard#25: 
#317(BAD) to new one #576 
#383 (BAD) to new one # 249 
and for Amboard #23: 
#575(BAD) to new one #318 
After this replacement both  Amboards  passed the tests 
by Am_test_vme and Amtest_data_loop program.</pre>
<!-- Author: Alexei -->


<!-- Date: Thu Aug 23 15:24:26 2001 -->
<pre>Isolation Thursday:   Looked at many things with  
Isolation this morning with John, Bill, and Bob.   
Didn't find a smoking gun.   They are implementing  
some possible firmware improvements this afternoon and we hope 
to try again Friday.    
 
We ran with Softevb and tsid has the wrong buffer number,  
is there any way to get the buffer number in a  
different way?</pre>
<!-- Author: Steve Kuhlmann -->


<!-- Date: Thu Aug 23 19:11:20 2001 -->
svtvme library updated to reflect Simone's XTFB hold-enable 
changes.  Ran svtvme_update script after cvs commit, so  
code will be different (in a hopefully trivial way) next  
time crates reboot.  
<!-- Author: Bill -->


<!-- Date: Fri Aug 24 12:09:36 2001 -->
Took out SVT crates for test needet to fill SVDD with data from SVTbeam finding package.
<!-- Author: marco  -->
<!-- Comment: Fri Aug 24 19;33;13 comment by...marco  -->
<pre>Done....

In summary: 
+ all wedges should be enabled again
+ SVDD filled with whatever number SVTbeam will provide
+ enabled FerError use in svtvme
+ some debug code installed in svtspymon 
+ HF_ISPY spydumps disabled to reduce data output (?)
+ reduce console output when spymon starts</pre>
<!-- Date: Fri Aug 24 17:50:51 2001 -->
<pre>This is an Entry for AMS Boards: 
 
AMS 2(wedge 0xB, svt05)) stopped outputing any data after several events, then assert "HOLD", and went to illegal state(0xffff).   
 
Swapped it with AMS 7(wedge 0xA, same crate), then the problem just disappeared. 
 
Stefano:"Rebuild all the AMS boards from scratch.." 
 
While, seriously, heaven knows where is the problem. Board itself? Bad connection at the back plane?  
 
Next time the board stands up, it need to go to test stand for a detailed check.  
 
sigh...,  most of the  cases were that the boards just turned happy when they arrived test stand..  
 
Heaven knows..  
    
</pre>
<!-- Author: Yanwen  -->



<!-- Date: Sat Aug 25 00:46:44 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-122&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-122' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-123&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-123' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-124&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-124' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-126&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-126' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-125&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-125' width='300'></a></center>
<!-- Author: Masa -->


<!-- Date: Sat Aug 25 01:52:19 2001 -->
<pre> 
I analysed the Reces run with special trigger table. 
This table triggers with 8 GeV photon, 4 GeV electron 
minimum bias (50k ps), and crossing (1M prescale) as default. 
We took three runs (124470, 124471 and 124472) with all ccal, cot, 
l1cal, xft, xtrd, fred, l2cal, l2decision, and hardware evb. There  
were only 4 reces boards and a clist in the l2 crate. Of course we are 
in L2 tagging mode. Two Reces trigger thresholds were set to be 3 GeV  
(0x384) and 8 GeV (0x7d0). 
 
 Run 124470 was took with default prescale. Fred L1 rate was ~140 Hz.  
We had DTO every 500-2000 events as we saw before. 
 Then we changed the L1 prescale, 10 for 4 GeV ele, 10 for 8 GeV photon, 
and 500k for mb. The L1A rate was down to ~ 14 Hz. We took run 124471 ,  
5k events without any DTO. 
 In Run 124472, we changed the one of the Reces trigger thresholds to be 
zero for making sure we were taking reasonable data. It looked ok. 
 We also confirmed the SMXR - fiber - Reces system by using the 
stand alone code, and found only the ccal11 (wedge 33-35) had problem. 
 
 The plots above are some results from Run 122471. 
TL2D occupancy corresponds to the reces trigger occupancy obtained by 
looking at the TL2D trigger bits. CESD occupancy corresopnds ro the 
simulated trigger occupancy obtained from CES raw data bank. 
TL2D-CESD maching and missmathing plots are also here. 
 
 Mismatchings in the wedge 33-35 were what we expected from our  
stand-alone-code test (probably caused by bad SMXR) and those in the wedge  
12-14 were caused by the hot channels in detector itself (see CESD occupancy).  
Otherewise the data looks very nice. After masking these bad wedges, I obtained  
the last figure. Top plot is 4 wire sum ADC distribution (black),  
after requireing 3 GeV trigger bit (red) and 8 GeV trigger bit (blue). 
The bottom plot shows the really nice efficiency trun-on curves.  
The disagrement between the trigger bit and CESD information is a few % level.    
 
 I also analysed Run 124470. It was many DTO, however, I found the TL2D-CESD  
matching was fine enough. 
 
 In summary, we confirmed our system (shower max detector -&gt; smxr -&gt;  
reces -&gt; alpha) working fine with 10 Hz of L1A (=L2A) rate. With 100 Hz,  
we had DTO every ~ 500 L1A, however the reces trigger bits were  
still read correctly by alpha. 
 
 
   
 
 
  
  
 
 
</pre>
<!-- Author: Masa, Karen -->


<!-- Date: Sat Aug 25 07:16:56 2001 -->
<pre>Isolation Friday:  Found a problem at high-rate 
on the IsoPick card,  which creates the partial energy 
sums from DCAS and sends them to IsoList.   It was 
not sending as many partial sums as there were seeds,  
causing Isolist to get out-of-sync.   Firmware 
changes on Monday then we'll be back... </pre>
<!-- Author: Steve, John, Bill, Bob -->


<!-- Date: Sun Aug 26 03:44:12 2001 -->
SVT-L2 studies<p> 
With only SVT and L2 we were able to exactly reproduce the problem reported <a href= 
'/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=15&frame=2&anchor=02:26:26'>previously</a> where SVT would send a long gap before end event in the same event that SVTlist sent several thousand tracks to the alpha and hung the processor.  Usually this problem only occurs when SVX is sending real tracks to SVT (beam conditions).<p> 
It appears that the long gap between DS and end event from SVT is not responsible for the 1000s of DSTROBEs from SVTlist.  The hang condition came from SVT sending a fraction of a track (e.g. 3 words + end packet) and then at least 1 other full track in one event.  The gap simply masked this effect.<p> 
Sending a track fraction by itself did not result in a hang.  Sending multiple full tracks with gaps in between them or with a long gap before end event did not result in a hang.  The next time SVX + SVT is in the run, we will search for partial tracks coming up the SVT-L2 cable.
<!-- Author: Matt and Bill -->


<!-- Date: Sun Aug 26 03:59:00 2001 -->
Today on evening shift we noticed a strange occurence: on roughly 1/2 of the HRRs done for BUSY or DONE timeouts (usually for non-L2 related reasons), after the first HRR no events would be processed and the scalers would report 100% of either L2 readout or L2 deadtime.  A second HRR was needed to clear this.  The other 1/2 of the time the run would begin as usual.  We were not able to reproduce this with just L2 and 2 SVT crates by looking for a hang after a HRR: HRR always recovered the first time.
<!-- Author: Matt -->
<!-- Comment: Sun Aug 26 03;59;31 comment by...Matt -->
and Nate!


<!-- Date: Mon Aug 27 19:57:43 2001 -->
<pre>with Matt's kind help (who burned the prom), we can now test the 
new CLIST firmware. the one we are testing now is fif_adder_3_15. 
L2 crate has CLIST, L1 interface, 4 Reces boards plugged in. 
we are testing the firmware while shift crew is taking data 
for other studies. good run starts at run 124818. Plots 
from L2TrigMon for cluster validation look ok. the first 
bad event (# of valid clusters in TL2D off by one) showed 
up at around 10K events. other than that, the plot for 
valid cluster look ok. so far this run has 55640 events.</pre>
<!-- Author: Ted and Matt -->


<!-- Date: Mon Aug 27 20:06:01 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-127&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-127  width='300' align='top'></td><td>CLIST cluster validation plot for run 124818. this is with the new firmware fifo_adder_3_15. this run ended due to Pbar losses.</a></td></tr></table>
<!-- Author: Ted -->


<!-- Date: Mon Aug 27 20:49:18 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-128&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-128  width='300' align='top'></td><td>run124822 ended around 42K events (for SVX study). this is how cluster validation plots look.  it will be hard to get a long run this time as SVX expert is here doing SVX timing study (they need short runs with different settings).  Steve K should be here at 9pm for Isolist study. I will wait for him and will leave the CLIST new firmware on the board, and will ask shift crew to include L2decision crate in the run tonight to get more statistics...   Steve M: I will leave the old prom under the alpha  workstation.</a></td></tr></table>
<!-- Author: Ted -->


<!-- Date: Mon Aug 27 21:48:59 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-129&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-129  width='300' align='top'></td><td>finally got a long run, with 110K L2A. run 124824. here is cluster validation plots. there are some events with valid clusters less than expected (by one). overall look better than the old firmware.  Steve K. is here for IsoList study. so CLIST will be unplugged. after he finishes his study, CLIST will be plugged back in again. I have asked shift crew to include L2 crate in the run for tonight so that we can get more statistics for the new CLIST firmware (version: fifo_adder_3_15).</a></td></tr></table>
<!-- Author: Ted -->


<!-- Date: Mon Aug 27 23:09:28 2001 -->
<pre>New firmware for IsoPick was apparently a success,  
number of clusters sent to Isolist matched number of 
DCAS seeds at 100 Hz rate.  I also never saw startload timeout,  
meaning the Moddone problem may be fixed.  Isolist 
still became outofsync based on the scope.  I need to  
look at the data closely before saying more. 
Runs 124825-828 had Clist out and Isolist in.  Clist 
is back in now and Isolist out.</pre>
<!-- Author: Steve K -->