<!-- Title: 13:15:10  Thu Nov  1 2001 -->
<!-- Crewchief: L2 crew -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
more debugging ensues


<!-- Date: Thu Nov 1 13:17:15 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-416&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-416' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-417&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-417' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-418&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-418' width='300'></a></center>
<!-- Author: hray, mattw -->


<!-- Date: Thu Nov 1 13:19:04 2001 -->
entropy has gotten too severe to run the L2 test at this point.  Finally, we get things going.  A  VME read of the hotlink latches in CLIST from LOCOS show the LOCOS in 01 crate not having good values.  The TrigMon plot verifies this - we can see all phi problems coming from crate 01.
<!-- Author: h and m -->
<!-- Comment: Thu Nov  1 13;19;54 comment by...hray -->
for this run we were using cosmics_notracks and TrigMon was showing CLIST not sending words some of the time


<!-- Date: Fri Nov 2 12:59:46 2001 -->
<pre>L2 Meeting 10/31/01 
 
MBus tests: With single track board, get data sent correctly 
over MBus. (A fixed pattern is sent, so the alpha can check the 
data directly). With two track boards and no delay, the boards 
have arbitration collisions. 
  The suggestion was made to try the boards in adjacent slots. 
There is some anecdotal evidence that this can help the collision 
problem. 
 
 
Clustering: The new firmware helps the cluster merging problem 
by reducing it by 3 orders of magnitude. For this test the merged 
clusters are created by unplugging 2 cables in the same crate. 
Will need beam data to say for sure what the error rate is. 
The wrong eta errors are now under study. 
 
Isolation: The energy errors reported previously were just an  
offline code bug. Now there is perfect agreement for the first 
energy sum. The problem of the overflow bits was fixed by 
new firmware in the Isopick cards. Now need to test the system 
at high rate. 
 
Monitoring code: It was suggested that the alpha code could check 
incoming data for reasonable values (such as eta or phi range), 
and could compare the number of Clist and Isolist clusters. 
For some errors, we would simply set the L2 Error bit, unless 
the error kept showing up. 
 
The new Magic Bus design went out for quotes. Bob DeMaat  
emphasized checking that the manufacturer could make a board 
with the 24 mil hole size needed for the press fit connectors. 
 
 </pre>
<!-- Author: Stephen -->


<!-- Date: Mon Nov 5 10:41:43 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-419&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-419  width='300' align='top'></td><td>Isolation Sum1 Et vs Expected from run 130846,  taken at 23Khz.  </a></td></tr></table>
<!-- Author: Steve Kuhlmann -->


<!-- Date: Tue Nov 6 07:59:06 2001 -->
<ul> 
several runs taken over yesterday am/this am.  Trying to examine CLIST recent new and improved errors.   
<br> 
<br> 
These runs were taken with only b0l2cl crates, l2de crate, running in calib continuous with L1Int board removed from de crate, only CLIST in crate, cosmics_noTracks[3,205].  at some point during these runs I would disconnect top cable in b0l2cl01 dcas slot 9.  these runs were taken AFTER Matt and I found a tracklist board holding BOSS high.    
<li>130954 - trigger on BOSS, BOSSREQ, DSTROBE at 3.7 V on scope, never see trigger.  SLOAD looks healthy.  LA shows L1A and EOE, clique buffer #, wclock, wen0 and wen1 seen.  No internal signals seen.  No MB words.  Pull cable in DCAS.  Now see internal signals.  Triggers on scope now work at 3.7 V 
<li>130967 - start with cable pulled.  see MB CLIST sending 3 words most of the time, 1,2 rest of time.  See ~0 MB words (purple bars) at 0,4,5,6,8,12  
<li>130978 - change LOCOS 10 to LOCOS 8 to see if phi errors seen mainly in 01 crate go away.  Still see L1A,EOE, internal signals on CLIQUE every few L1A.  for cluster merging the new LOCOS appeared to help a little, but no changes elsewhere 
<li>130983 - change LOCOS 8 to LOCOS 5 (other spare).  no change 
<li>130994 - change LOCOS 5 back to LOCOS 8 (yes, really 8) because it appeared to do the best of all 3 (although improvements aren't that great) 
<li>try running with new CLIST (SN2).  doesn't work - no signals on LA, or scope. 
<br> 
<br> 
now, tried reloading all DCAS FRAM with older, non-cluster merging friendly file. still using cosmics_notracks[3,205] 
<li>131087 - run with all calorimeter, no cables pulled.  things still look bad 
<li>131088 - go back to config used yesterday - only L2CL crates, only CLIST in de crate, calib continuous.  unplug connector in 01, top of dcas in slot 9.  see improvements in the sense that the majority of eta, phi, ntowers, and clusters seen are same as expected, but still have a lot of errors 
<li>131093 - add back in all cal crates, still have cable unplugged.  add in L1.  now sometimes see no l1 mb words, as well as no clist words.  MANY MANY DTO from l2de with INTERNAL BUFFER TOO SMALL and clist sending large amounts of information!! 
</ul> 
<!-- Author: hray -->


<!-- Date: Wed Nov 7 08:52:23 2001 -->
<pre>I am taking the SVT to run standalone diagnostics on the Associative Memories. 
I expect to be done in a couple of hours.</pre>
<!-- Author: Luciano -->
<!-- Comment: Wed Nov  7 11;23;44 comment by...Luciano -->
<pre>I'm done with the SVT.

I ran standalone tests for the AM and I found errors in the following AM boards:

crate 03 slot 10 id 12 plug 01:774
crate 05 slot 09 id 07 plug 05:843

I swapped the two AMplugs with new ones and now everything looks OK.
I could not test AMboards in crate 01 slots 18,19 because Merger at slot 16 is missing (to make a temporary path for analizer cables).

The status of all AMboards is posted (as usual) at:
/svtdaq/amtest/</pre>
<!-- Date: Wed Nov 7 10:52:30 2001 -->
<pre>L2 Meeting Notes 
11/2/01 
 
- L2 Entropy test showed that entropy still exists. The Clist  
board failed to send data about half the time. The other boards 
worked fine. 
 
- MBus Test uses SVT to send a fixed data pattern to the alpha, 
which the alpha can directly check in memory. One board worked 
fine, with 2 boards and no delay, then bus arbitration problems 
immediately showed up. Need to capture some scope traces both 
with and without bus collisions. 
 
- Plan for MBUS testing. 5 backplanes will be produced and  
initially inspected at Michigan. These will be taken to Fermilab 
where 3 of the backplanes will be stuffed with connectors. 
One of the backplanes will stay at B0 for tests; first using  
the transition cards for termination. This will allow a direct 
comparison of the old and new bus with respect to crosstalk 
problems. The TTL level termination can then be added to the 
backplane to see if that has an effect. At Michigan, studies 
will be done to find a suitable values for the RC termination. 
A fully stuffed backplane will then be brought from Michigan to  
Fermilab. 
 
11/5/01 
  Isolation worked well at 23KHz with tracklist and Clist 
boards removed. Energy sum agreed although there were errors 
in the number of clusters plot, with clusters being dropped. 
A comparison to the number of clusters in Clist needs to be done. 
 
  Clist is no longer working reliably, in that for many events it 
no longer sends any MBus words. 
 
  One of the Tracklist boards seemed to hold boss high during 
one of the tests. This board needs further investigation. 
 
MBUs test - plan to do an overnight run with SVT sending fixed 
data to the alpha. </pre>
<!-- Author: Stephen -->


<!-- Date: Wed Nov 7 11:07:37 2001 -->
<pre>Summary of L2 work on Mon and Tuesday. 
 
Multi-alpha tests were done with 2 alphas in the crate. One 
of the alphas would check the data that had arrived in the 
other alpha on every event. Both boards would send the decision 
to the TS. This was running the L2_TORTURE_v-3 table at 17KHz 
with just the L1 and SVTlist board. I could run for a long time 
with no errors. When I added the Clist board, I encountered 
problems - partly due to Clist misbehaving. 
  I think the problem is that the code in the two alphas  
get out of sync because that 2nd alpha doesn't know when  
start_load is being sent. The 2 alphas are in sync in sending  
the L2 decision, because of the handshake protocol with the TS. 
Essentially there is a state where the alpha is polling for 
the global L2 decision. This doesn't have a timeout. I need 
a similar polling state (without a timeout) where the 2 alphas 
get in sync with regard to the data being loaded.  
 
 Reces tests: I did a quick Reces DTO test in the lower crate. 
Using the same conditions that had previously generated a DTO 
error, I had no DTO errors. That is because of Arnd's new readout 
code which does a retry in case of a VME Berr. I did not get the  
LA attached to see if in fact the BERR was occuring and that 
the retry was successful. It still remains to be seen what the 
overhead is in the readout time for dealing with the BERR and 
retry. 
 
 The Clist behavior was studied. It seems clear that the correct 
signals are coming from the Locos/Clique boards but that Clist 
doesn't correctly respond to start_load. This is most likely a 
bad solder connection on the board, since the same firmware 
worked well before.</pre>
<!-- Author: Stephen -->


<!-- Date: Wed Nov 7 11:12:42 2001 -->
<pre>Status of boards at B0. 
There are now 4 Alphas at B0, all of which have been used 
succesfully in single Alpha tests. 
Boards D-1, D-2, D-3 are the new alpha boards. Board C-1 is 
the original pre-production board which has been at B0 for the 
last 1.5 years. This board needs to operate in the mode where 
the fifos are disabled while data is being written to them over 
the MBUS.  
D-1 is in the upper crate and has been there since late this  
summer. D-3 is now in slot 3 in the lower crate. D-2 and C-1 
are sitting in spare slots in the lower crate. The ethernet 
cards work for each board. 
 
 Both Clist boards are back in Michigan for repair. We will also 
be bringing all the LOCOS boards back to Michigan to apply a  
fix for the cluster eta problem.</pre>
<!-- Author: Stephen -->



<!-- Date: Wed Nov 7 19:37:04 2001 -->
We have been checking svtsim against svt for some runs in late September / early October.  We tracked some discrepancies in 
wedges 10 and 11 down to the following two problems: 
(a) all four fibers behind hf_w10_b0b1 (crate 5, slot 4) were 
unplugged; (b) the bottom fibers for hf_w11_b0b1 and hf_w11_b2b3 
(crate 5, slots 13 and 14) were exchanged.  We fixed both of 
these problems. 
  
<!-- Author: Bill & Marco -->


<!-- Date: Wed Nov 7 22:09:35 2001 -->
There is one Hit Finder (#31, hf_w00_b0b1, crate 0 slot 4) whose 
hits (as recorded in the Track Fitter output written to SVTD) 
tend to differ by a fraction of a strip from the svtsim hits, 
and whose long-cluster flag sometimes differs, too.  It doesn't 
look like a bit error, as the problem is not localized to one 
input stream.  It looks as if the board were misconfigured.  I 
checked that the cold start routine doesn't do anything special 
when it processes that Hit Finder, that the board has the right 
firmware loaded, and that the HF passes the 
GSTM/HF random-data test in the test stand.  I also checked  
that I can correctly read and write its memories when it is in 
the real crate.  It is possible, but not trivial, to do a data-flow test in the 
real crate, so I will not do that for now.   
Unfortunately, because of its huge size, the HF input spy buffer data 
are not captured to disk. 
If the problem persists, I'll try reading that board's output directly into a 
debug bank.  
<!-- Author: Bill -->
<!-- Comment: Wed Nov  7 22;17;49 comment by...B -->
I'm looking at run 128449



<!-- Date: Wed Nov 7 22:26:53 2001 -->
<pre>L2 Meeting 11/7/01 
 
Multialpha tests were successful in running with 2 alphas and 
the SVT and L1 boards. However, the alpha code needs to be 
modified slightly to work robustly with 2 boards. See entries 
above for more details. 
 
The DTO problem while reading Reces was tested in a standalone 
way and the problem doesn't show up anymore now that Arnd put 
the retry back into the code. Peter will talk to Arnd about 
trying to measure the impact on the readout time of having the 
retry after a VME BERR. 
 
The tracklist board which had seemed to hold boss high last week 
was checked out and didn't exhibit a problem. All of the  
tracklist boards will be checked out to have reliable spares. 
 
(Info on Clustering from talking to Monica after the meeting) 
The cluster merging and eta errors are due to a related effect 
which Monica can reproduce in the teststand at Michigan. It 
has to do with propagation of signals on the backplane. The 
cluster merging problem was greatly improved by changing the 
DCAS firmware. It can likely be improved even more by extending 
the delay put into the firmware. Fixing the eta problem requires 
changes to the locos board. All the locos boards will be taken 
to Michigan to have a fix applied.</pre>
<!-- Author: Stephen -->


<!-- Date: Thu Nov 8 16:02:12 2001 -->
Matt and I spent some more time setting up L2 backplane evaluation tests on the old MB backplane in anticipation of the new backplane, in the upper level 2 crate.  We implemented the following: 
 
<li>sending complex patterns through the SVT and checking them in the alpha. In this case, a file with 1000 tracks over many events was being sent. 
<li>Sending SVT data but writing it to the XTRP base address. This allows us to have two SVTList boards sending data on the mbus at the same time, but writing it to a different location in the alpha for testing. Matt set one of the SVTlist boards to zero delay, and we also have L1interface sending data at the same time. The system appears to run reliably in this configuration. 
 
<p>Both of these tests are successful. We're going to let this run for a long time in the configuration with L1Interface, 2x SVTList (writing to different locations in the alpha) and data from SVT, with on-0the-fly checks in the alpha, and see if we see any errors in many 100K events.
<!-- Author: Peter Wittich -->
<!-- Comment: Thu Nov  8 19;32;50 comment by...Matt -->
<pre>Ended run 131284 with no errors in 1.23m events.  One speculation is that L1int and SVTlist 07 (no delay) ran without colliding for so many events is that they were in adjacent slots (10 and 11, respectively).  SVTlist 03 with the delay was in slot 7. </pre>


<!-- Date: Fri Nov 9 14:51:52 2001 -->
L2 tracking tests:<p> 
L2_TORTURE[3,205] with L1gl, L2de, SVT06-07, XTRP, and scalers<br> 
XTRPlist 5, L1int, SVTlist 6, and 4 reces in L2de<br> 
extra1 = 1; nosvx = stephen1<p> 
<b>131385</b>  tagging, L1A=L2A=100 Hz, 99% dead, all 4 buffers full.  No errors in TrigMon.<p> 
<b>131388</b>  cutting, L1A=17 kHz, L2A = 3 Hz, 0% dead, buffers 0 and 1 each at 50%.  L1 and SVTlist: no errors.  XTRPlist had track mismatches and lost sync.  Was not able to tell if the sync loss was in XTRP or L2.<p> 
<b>131390</b>  cutting, L1A=17 kHz, L2A = 3 Hz, 0% dead, buffers 0 and 3 each at 50%.  Swapped XTRPlist 3 in for XTRPlist 5.  After 9m L1A, saw sync loss again.  Fixed by HRR.  Also had this run stop about 5 times with: "Error: Number of L1 words sent   is 0" in minicom, but NO associated L2 timeout in rc!  HRR recovered from these errors as well.
<!-- Author: Matt -->
<!-- Comment: Sat Nov 10 16;38;26 comment by...Stephen -->
<pre>The L2_TORTURE_v-3 executable doesn't have the L2 timeout 
error handling code. That is to allow running without Clist.
The Error of the number of L1 words being 0 is a real error.
That error check has been around for awhile and is in most 
executables.</pre>
<!-- Date: Fri Nov 9 17:06:15 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-420&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-420  width='300' align='top'></td><td>Run 131390.  Plot of Ntracks in TL2D vs XTRD when the  system was running in sync.  We still see a number of single  track errors between TL2D and XTRD.  We saw this in both  of the tracklist boards: 3 and 5.</a></td></tr></table>
<!-- Author: Matt -->



<!-- Date: Sat Nov 10 16:53:07 2001 -->
<pre> L2 Meeting 11/9/01 
 
Reces tests - (see entry in e-log). Masa tested all 4 Reces  
  boards with a 2KHz L1A rate, but a 200Hz L2A rate (due to 
  readout deadtime as L2 was accepting every event). At this 
  rate, there would be a DTO error with the "Alpha no longer 
  processing" error. This is likely due to an MBUS arbitration 
  fix that needs to be applied to the alpha. At 200HZ, L1A rate, 
  the system ran fine with no DTO errors. Thus it looks like 
  Arnd's code has fixed the original problem. 
  Masa will do more Reces tests on Sunday to test the Reces  
  channels.  
 
Clist - The Clist board was checked at Michigan and worked just 
 fine. Heather will take the board back to CDF and test them 
 over the weekend. 
 
MBus test - with  2 SVT boards sending to different addresses and 
  the L1 board sending data. Test ran for 1M events with no  
  errors. We will need to move this test to the lower crate once 
  collisions start. A single Merger board in the lower crate 
  could be a data source, but it doesn't respond to L1A. The 
  Alpha could write over VME to the Merger board after each  
  L1A to have the data sent out by the Merger board. The other 
  option is to have 2 additional SVT boards in the lower crate. 
 
(Info from after the meeting.) The PO for the MagicBus was  
finally sent to the company.</pre>
<!-- Author: Stephen -->


<!-- Date: Sun Nov 11 15:02:03 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-421&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-421  width='300' align='top'></td><td>Isolation system calculates 5 sums,  with the intent to use the smallest energy of the 5 sums to avoid  leakage from the EM shower.  So far the focus has been getting sum 1 (the Run I sum using the closest 8 towers) working.   After fixing offline bugs,  here are the other 4 sums in the 23 Khz run taken last Sunday. </a></td></tr></table>
<!-- Author: Steve Kuhlmann -->


<!-- Date: Sun Nov 11 15:55:38 2001 -->
<pre> I checked the Reces channels.  
 
 (1) I ran TEST_RECES trigger table with few Hz of L1A 
rate.I found 6 bad channels which are exactrly the same  
channels as which we saw before shutdown. 
 
  West phi=6--9 
  East phi=9-11 
 
 (1) When I swapped the fibers of these bad channels to good 
channels, the bad channel did not move. Thus it is not 
the SMXR problem, but Reces problem.  
 
 (2) When I ran the stand alone code to strobe fake data 
from SMXR to Reces, West phi=6--8 were OK. East phi=9-11 
didn't even respond for this (they also used to be ok before 
shutdown). 
 
 (3) Just reading/writing to the Reces memory by diagnostic 
code have no problem. 
 
 I need some more studies to understand the problem.</pre>
<!-- Author: masa -->


<!-- Date: Sun Nov 11 22:45:24 2001 -->
<ul> 
I've been trying to look into this CLIST problem.  CLIST SN1 appears to work fine in MI, but here it's started having problems - sending out 0 MB words some portion of the time, which now seems to be directly related to events with 0 energy. 
<li>Friday PM I plugged LOCOS back in and CLIST into L2de crate, thinking it would be used that night.  Turns out the ace left a Rick Run config running all night. 
<li>Sat AM I came in for a few hours, plugged in CLIST only (greg had L1), no other boards in the crate.  took a run with only l2de and l2cl, calib continuous, cosmics_notracks[3,205], cable unplugged.  131480, still see problems, nothing done in MI helped 
<li>Sun PM trying to probe into CLIST problems.  Running with L1 and CLIST only in crate.  Run 131644 going when I came in, ended with 260 K.  Cosmics, all ccal and wcal.  L1 always sends 1 word, CLIST sends 0 most of time (green), 1 rest of time (blue).  no phi problems, eta on small scale at TL2D 0 TC2D 6->17 eta.  ntow and cluster merging problems still. 
<li>LA shows events which don't send info on MB - only have L1A, EOE and DDONE* signals on CLIST breakout board.  See RCLK, FIFO_EMPTY*, LOC_REQ, LOC_BOSS, MB_DONE_OUT held Low and CLIQUE_END held High for these events.  Try to follow the important signals (LOC_REQ, LOC_BOSS, FIFO_EMPTY) through chips on board 
<li>First try to look at stuff from K12, the FIFO controller.  Pins are so incredibly tiny that I can't get any sort of probe to connect/wrap around the pins. 
<li>Move on to other chips.  FIFO_EMPTY on N7-66, LOC_BOSS on B18-9.  Tried to put connectors on LOC_REQ S13-7 and LOC_BOSS S17-7  but the pins are messy enough that the connector won't stay put.  These are the only other chips, aside from K12 FIFO controller, that these signals go through.  They then go to the SMT2 connector. 
<li>below are two plots.  The one shows the signals (16=FIFO_EMPTY, 17=LOC_BOSS) when the 0 MB word condition is met.  The other one shows the siganls when things look good.  For the good and bad picture the LOC_BOSS and FIFO_EMPTY signals are NOT present 
</ul>
<!-- Author: hray -->
<!-- Comment: Sun Nov 11 23;01;28 comment by...hray -->
clist has been used in slot 13 since it was brought back from MI, just in case the slots 14 and 15 were getting "overused"



<!-- Date: Sun Nov 11 23:13:44 2001 -->
<center><a href='/elog/notebooks/l2/Sun_Nov_11_2001_231315.ps'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-427' ></a><a href='/elog/notebooks/l2/Sun_Nov_11_2001_231323.ps'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-429' ></a></center>
<!-- Author: hray -->
<!-- Comment: Sun Nov 11 23;16;33 comment by...h -->
trace 16 = FIFO_EMPTY, 17 = LOC_BOSS.  The fact that these two traces haven't showed up for events w/wout MBUS words could mean that the connections aren't good enough on the pins to read the signals.  This is probally pilot error



<!-- Date: Mon Nov 12 07:47:34 2001 -->
<center><a href='/elog/notebooks/l2/Mon_Nov_12_2001_074659.ps'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-431' ></a><a href='/elog/notebooks/l2/Mon_Nov_12_2001_074720.ps'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-433' ></a></center>
<!-- Author: hray -->
<!-- Comment: Mon Nov 12 07;49;13 comment by...hray -->
run with ccal,pcal,wcal, cosmics no tracks, only clist and l1 in de crate, no cables pulled, old fram in dcas.  after eta fix to locos.  odd new result - tl2d always sees 0 eta. no phi errors


<!-- Comment: Tue Nov 13 08;39;43 comment by...hr -->
woah - doesn't appear to have any phi entries, which does NOT mean no phi errors.  so TC2D as well as TL2D aren't seeing Phi????
<!-- Date: Mon Nov 12 09:03:50 2001 -->
<table><tr><td><a href=/elog/notebooks/l2/Mon_Nov_12_2001_090341.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-435  align='top'></td><td>run with no trigger, just l2cl and l2de, only clist in l2de cable pulled in slot 9 top, crate l2cl01.  </a></td></tr></table>
<!-- Author: hray -->


<!-- Date: Mon Nov 12 10:59:40 2001 -->
<center><a href='/elog/notebooks/l2/Mon_Nov_12_2001_105844.ps'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-437' ></a><a href='/elog/notebooks/l2/Mon_Nov_12_2001_105904.ps'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-439' ></a></center>
<!-- Author: hray -->
<!-- Comment: Mon Nov 12 11;01;59 comment by...hray -->
From run 131692.  moved clist to l2de01 crate.  now running with iso in slot 6 and clist in slot 13, calib continuous, cable unplugged in l2cl01 slot 09 top.  here clist is always sending out MB words, the correct number, but the ntow, eta, phi plots aren't very happy.  this run was without the LA attached.  The backplane signals looked _exactly_ the same as above on the scope.  those were taken looking at the transition board traces