<!-- Title: 07:21:18  Mon Dec 10 2001 -->
<!-- Crewchief: L2 Death from Above  -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
More debugging etc  etc


<!-- Date: Mon Dec 10 07:25:40 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-502&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-502' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-503&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-503' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-504&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-504' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-505&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-505' width='300'></a></center>
<!-- Author: hray -->
<!-- Comment: Mon Dec 10 07;41;06 comment by...hray -->
<ul>
Some things that have happened over the past few days:
<li>Changed DCAS in slot 11 crate 05 from SN 37 to SN 02 per MT request
<li>Steve K and I discovered we had both done something silly - when we were jumpering the backplanes in l2cl crates, the P3 pin assignment for LOCOS is different from that of DCAS.   On Wed I had jumpered wrong energy bits together in crate 04, Steve jumpered ISO to a NTOW bit.  He removed his jumper Fri and a check of all TrigMon plots for runs since then ( 134356, 134357, 134358, 134360, 134361, 134363, 1344060 ) show no NTOW errors.  
<li>However, I didn't realize I had misjumpered until Sunday pm, so the above runs are kind of not worth sending through MT validation code because we'll see other errors.  
<li>Runs 134437, 134459, 134460 taken with jumpers fixed look good in CLIST and MBUS TrigMon plots.  
<li> above plots from 134459.  These are the errors I'm seeing from the ADMEM->DIRAC->DCAS plots.
<li>Middle top is DCAS vs TrigSim.  This had been working fine, so that we can now trust it.  It looks like errors have occured in the central part of the detector.
<li>Right top is DCAS-ADMEM.  Appears that the same errors are happening in the central part of the detector, so this agrees with Sim, good.
<li>Bottom is Dirac different from Sim. These are roughly the same errors seen by Dcas vs Sim.  
<li>I'm pointing this out because on run 134437 (see below) the DCAS vs sim looked fine, except for those few bit errors we know about, as well as for run 134460.  The DIRAC vs sim is all screwed up.  I know we can now trust the DCAS sim plots.  I assume the same is true of DIRAC?  (in which case corruption of data may be occuring before DCAS and not in DCAS)  
<br><br> 
we need to begin a more organized effort to compare DCAS to the ADMEM/DIRAC paths.  Maybe we should incorporate Carla's validation code into our own so we can check all of these things at once offline?  
</ul>

<!-- Date: Mon Dec 10 07:41:39 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-506&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-506' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-507&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-507' width='300'></a></center>
<!-- Author: hray -->
<!-- Comment: Mon Dec 10 07;47;05 comment by...hray -->
as mentioned above, from run 134437.  see expected DCAS errors vs sim, DIRAC vs sim not so pretty.   

<!-- Comment: Mon Dec 10 07;49;46 comment by...hray -->
above runs taken with normal L2 config - CLIST, ISO, ReCES cabled but not used, Track and SVTlist, PHYSICS[4,224] table


<!-- Date: Mon Dec 10 09:32:10 2001 -->
In my flurry of conversation with Steve K last night about jumpering crate 04 I inadvertently changed the DCAS in crate 04 not 05.  Next time an end of run occurs I will remedy this 
<!-- Author: hray -->


<!-- Date: Mon Dec 10 11:56:26 2001 -->
<pre>So, Changed DCAS: 
crate 04, slot 11 changed back to original okay board 37 
crate 05, slot 11 changed from sn 13 to sn 2 
crate 04, slot 09 changed from sn 77 to sn 10 
 
tested the electron table "for real" - and it still crashes, 
not because of photons but something in electron trigger.  
exploring now</pre>
<!-- Author: hray -->
<!-- Comment: Mon Dec 10 15;01;15 comment by...hray -->
Runs 134468 and 134471 taken after DCAS swap appear to have the HAD bit solved!


<!-- Date: Mon Dec 10 19:30:18 2001 -->
 
 
<br> 
Continue checking the L2 electron code. 
It turns out the XFT-wedge matching problem which I 
saw yesterday was caused by the XFT phi calculation in the code. 
Definition of the XTRP bit in CDF 4152 page 150 is wrong. The correct 
difinition by Matt is 
<table> 
<tr><td>            </td><td>     bit </td></tr> 
<tr><td>  segment phi  </td><td>11:3 </td></tr> 
<tr><td>  local phi    </td><td>2:0</td></tr> 
</table> 
 
Thus needed to chenge, 
<br> uint32 maskSeg = 0xff8; 
<br> uint32 segPhi = (tl2dPhi & maskSeg)>>3; 
<br> uint32 maskMini = 0x007; 
<br> uint32 miniPhi =((tl2dPhi & maskMini));  
<br> 
<br>		   
After this change, trigger rate looks better. 
I ran through 3k events, and obtained the following results. 
<br> 
<table border=2 cellspacing=0 cellpadding=1 align=center> 
<tr bgcolor=white> 
<th align=center>Bit #</th><th align=center>Level 1</th><th align=center>Level 2</th></tr> 
<tr bgcolor=white> 
<td align=right>0</td><td align=left>1/L1_CEM4_PT4_v-1 (306)</td> 
<td align=left>2/TEST_L2_CEM16-PT8_v-1 (192)</td> 
</tr> 
<tr bgcolor=white> 
<td align=right>1</td><td align=left>1/L1_CEM8_PT8_v-1 (1968)</td> 
<td align=left>2/TEST_L2_CEM4_PT4_v-1 (192)</td> 
</tr> 
<tr bgcolor=white> 
<td align=right>2</td><td align=left>1/L1_EM8_v-1 (2886)</td> 
<td align=left>2/TEST_L2_CEM8_PT8_PS4_v-1 (1422)</td> 
</tr> 
<tr bgcolor=white> 
<td align=right>3</td><td align=left>1/L1_PEM8_MET15_v-1 (1494)</td> 
<td align=left>2/TEST_L2_EM10_PS1000_v-1 (2316)</td> 
</tr> 
<tr bgcolor=white> 
<td align=right>4</td><td> </td> 
<td align=left>2/TEST_L2_EM18_ISO3GEV_v-1 (78)</td> 
</tr> 
<tr bgcolor=white> 
<td align=right>5</td><td> </td> 
<td align=left>2/TEST_L2_PEM20_ISO10PER_v-1 (54)</td> 
</tr> 
<tr bgcolor=white> 
<td align=right>6</td><td> </td> 
<td align=left>2/TEST_L2_TWO_EM16_v-1 (102)</td> 
</tr> 
</table> 
 
<br>(1)There is still unexpected 3/4 reduction for the L2 8 GeV electron trigger.  
<br>(2)By cdf 4718, the L2 iso photon trigger (bit 4) should have 0.4% reduction (27microb to 100nb), 
however the result shows only 3% (2886 to 78). Similar difference in diphoton (bit 6). 
I need to check this again by using the L3 tagged L1 EM8 trigger sample. 
 
 
<p> I also calculated the processing time, and here is 
averaged time through 3k events. 
<br>Read data from memory: 23.4 micros 
<br>Trigger decieion     : 9.87 micros 
<br>store data to TL2D   : 22.1 micros 
<br> Note that I prerequire the L1 trigger bit for making 
the input data file, the trigger decision time can be biased. 
  
<!-- Author: masa -->
<!-- Comment: Mon Dec 10 23;29;07 comment by...masa -->
<pre>The reduction of L2 8 GeV electron trigger was caused by
the Had/EM<0.125 cut, because Had/EM in L2 was calculated from
culstered energy. If we don't apply Had/EM in L2, L1 and L2
bit shows ~100% agreement.</pre>


<!-- Date: Tue Dec 11 13:12:09 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-508&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-508' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-509&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-509' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-510&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-510' width='300'></a></center>
<!-- Author: hray -->
<!-- Comment: Tue Dec 11 13;15;33 comment by...hray -->
Rates and deadtimes from run 134524 with TEST_ELECTRONS_PHOTONS[6,226] with alpha in tagging mode.  Using all detector possible (no wcal 05).  I put alpha into tagging mode via RC.  When run started the normal scroll of prescales and In tagging mode didn't occur in minicom.  Instead saw "In stopped state.  Bits 0c 0x5f77f, Bits 18 0x100, Bits 14 0x0.  Buffer number 2, load buffer 2".  It says in DAQMON that we are tagging and accepting events, so did something change recently in Alpha in regards to tagging mode?  This run collected 140K events.


<!-- Date: Tue Dec 11 13:16:15 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-511&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-511' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-512&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-512' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-513&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-513' width='300'></a></center>
<!-- Author: hray -->
<!-- Comment: Tue Dec 11 13;18;37 comment by...hray -->
From run 134523 with Alpha in cutting mode with TEST_ELECTRONS_PHOTONS[6,266].  Before CS I changed the Alpha to tagging mode using the prompt ~jsm/alpha command.  When activated I didn't see the typical scroll of prescales and tagging message.  DAQMON showed the Alpha was indeed cutting. Halt at ev 17450 to again put alpha in tagging with ~jsm command.  RR and don't see any change in DAQMON.  Do another HRR, still no change in DAQMON - still cutting.  End run to change to tagging via RC.


<!-- Date: Tue Dec 11 13:19:50 2001 -->
L2 torture tests.<p> 
Took multiple runs with: L2_TORTURE [3,226]<br> 
with SVTlist, XTRPlist, Clist, ISOlist, reces in L2de<br> 
with L3, all CCAL and WCAL, L1/L2cal, L1gl, L2de, SVT, XTRP, and scalers<br> 
extral = 1, and nosvx<p> 
<b>134537</b> tagging with L1A=L2A=240Hz, 99% dead, 4 full buffers, no errors<br> 
<b>134538-134543</b> cutting with L1A about 20kHz, L2A about 50 Hz, and 20% dead, 4 buffers in use.  No chronic errors from any board except SVTlist.  SVTlist was losing sync such that its bc would skip one ahead of XTRPlist.  This is consistent with SVTlist double sending in one event.  However, by capturing traces on the backplane with the error flag set to 144 in the alpha, we saw that in the event immediately proceeding the error flag, SVTlist clearly did not send two events, because the number of dstrobes was consistent with only 1 event worth of data.  See scope trace below.  This happened with both SVTlist 07 and 08, and a PAUSE/RESUME in rc would fix it.  We also found that this only happened when SVTlist could send 1 track/event.  The error was not observed in 2 track/event data.
<!-- Author: Matt -->


<!-- Date: Tue Dec 11 13:36:51 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-514&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-514  width='300' align='top'></td><td>Scope trace on the error event.  YELLOW = start_load;  GREEN = boss; PURPLE = dstrobe; PINK = ERROR FLAG.  From  run 134543 with SVT sending only 1 track/event to L2.  In this  scenario, SVTlist would lose sync almost immediately.   However, in this trace, SVTlist (sending last) clearly  sent only 1 dstrobe, which is 1 track + ee.  2 events  worth of tracks would have required 2 dstrobes.</a></td></tr></table>
<!-- Author: Matt -->


<!-- Date: Wed Dec 12 14:33:03 2001 -->
Last Friday evening, Marco removed spy buffer monitoring from 
SVT crate startup script, to investigate the cause of crate 
CPU crashes during data-taking runs.  Marco has now reduced 
the maximum packet size of smart sockets data sent out during 
a run; he expects this change to eliminate the crashes. 
<p> 
I have re-enabled the "svtStart" command in the "startup.svt" 
boot file.  Let's keep an eye out for SVT crate CPU crashes. 
<p>  
<!-- Author: Bill A -->


<!-- Date: Wed Dec 12 20:07:48 2001 -->
Tracklist studies.<p> 
The SVTlist sync error seen yesterday was reproduced running L2_TORTURE[3,226] with SEVB, L1gl, L2de, L1/L2cal, SVT (nosvx = faketrack1), and XTRP (extra1 = 1).  The default configuration was XTRPlist slot 9, L1int slot 10, SVTlist slot 12, Clist slot 14, reces slots 15-18, and ISOlist slot 20.  The sync loss was also seen in XTRPlist when it was moved to slot 12.  However, only the SVT/XTRPlist board in slot 12, with Clist in slot 14 would have this problem.  Moving Clist to slot 7, or moving SVTlist to slot 7 would not reproduce the error.<p> 
The error itself is that two START_LOADs before the alpha would pull the error flag, SVTlist would send 2 events worth of data, 34 and 68 usec after START_LOAD, respectively.  After the first round of data, SVTlist would not raise its MOD_DONE line.  This suggested that the board fell out of the state machine after sending its data, at which point the default is to start the SM logic again.  If another buffer was waiting, the board would send the next event after the counter had gone through another 34 usec.<p> 
This was traced to the state where the SM waits for DDONE to return after sending DSTROBE, POD1 = 11 on the LA captures below.  New firmware elimitating a possible race condition between the SM clearing its states and DDONE returning was designed and tested.  It was able to run smoothly under conditions that quickly caused SVT/XTRPlist to lose sync: 1 track/event, L1A=23kHz, the board in slot 12.  With 2 tracks/event and rates up to 17 kHz we were not able to reproduce the error.
<!-- Author: Stephen, David, Matt -->


<!-- Date: Wed Dec 12 20:12:24 2001 -->
<center><a href='/elog/notebooks/l2/Wed_Dec_12_2001_201155.ps'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-516' ></a><a href='/elog/notebooks/l2/Wed_Dec_12_2001_201206.ps'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-518' ></a></center>
<!-- Author: Matt -->
<!-- Comment: Wed Dec 12 20;17;17 comment by...Matt -->
<b>Left plot:</b> the bad event, where the "waiting for DDONE" state (POD1 = 11) is never reached.  At this point when all other states are cleared in the SM, it falls back to its initial state and begins the logic again.  <b>Right plot:</b> the good event, another 34 usec after the signals in the bad plot.  This time the SM successfully arrives in the wait state.


<!-- Date: Wed Dec 12 20:23:42 2001 -->
<table><tr><td><a href=/elog/notebooks/l2/Wed_Dec_12_2001_202324.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-523  align='top'></td><td>The SM logic with the new firmware to eliminate the  potential race between DDONE (POD1 = 10) arriving and S3_OUT (POD1 = 8) being cleared.  Both are necessary to get to the  S3_WAIT state (POD1 = 11).  In this case S3_OUT is held  until S3_WAIT is asserted, whereas previously S3_OUT could  be dropped before DDONE returns.  In the latter case, we  would never make it to S3_WAIT.</a></td></tr></table>
<!-- Author: Matt -->


<!-- Date: Thu Dec 13 12:52:31 2001 -->
The testpoints from the SVTlist FPGA on the above 3 LA plots are as follows:<p>  
<TABLE border> <TR><TH>SVTlist signal</TH><TH>LA pin</TH></TR> 
<TR><TD>START_LOAD_CLEAN</TD><TD>0</TH></TR> 
<TR><TD>S0_OUT</TD><TD>1</TD></TR> <TR><TD>S1_IN</TD><TD>2</TD></TR> 
<TR><TD>S1_OUT</TD><TD>3</TD></TR> <TR><TD>S2_IN</TD><TD>4</TD></TR> 
<TR><TD>S2_OUT</TD><TD>5</TD></TR> 
<TR><TD>WE_ARE_BOSS</TD><TD>6</TD></TR> 
<TR><TD>S3_IN</TD><TD>7</TD></TR> 
<TR><TD>S3_OUT</TD><TD>8</TD></TR> 
<TR><TD>DSTROBE</TD><TD>9</TD></TR> 
<TR><TD>DDONE</TD><TD>10</TD></TR> <TR><TD>S3_WAIT</TD><TD>11</TD></TR> 
<TR><TD>CLEAR_S3WAIT_LATCH</TD><TD>12</TD></TR> <TR><TD>S4_IN</TD><TD>13</TD></TR> 
<TR><TD>S4_OUT</TD><TD>14</TD></TR> 
<TR><TD>DONE_OUT</TD><TD>15</TD></TR> 
</TABLE BORDER><p> 
The remaining pods were on the backplane.
<!-- Author: Matt -->


<!-- Date: Thu Dec 13 13:31:52 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-524&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-524  width='300' align='top'></td><td>Thanks Monica!</a></td></tr></table>
<!-- Author: Steve Kuhlmann -->


<!-- Date: Thu Dec 13 18:34:47 2001 -->
<pre>Summary of L2CAL work for the day: 
 
1) added a delay to SEED_SEL sent from LOCOS to CLIQUE to get away from the time the (eta,phi) bits change in Isolation. It seems to help the isolation eta problem (see plot above) 
 
2) tried CLIQUE SNO 2 in the system; works fine with FPGA version 111601 but gets out of sync with 121101. After going back to old PROM, CLIST is still not sending any data to the alpha. Pushing CLIQUE SNO 2 in and out seems to help. Leave CLIST SNO 2 in. 
 
3) stuck low HAD(2) bit in tower (phi,eta)=(21,3) is not solved by swapping DCAS or cable from DIRAC to DCAS. Must be upstream of 
DIRAC. 
 
4) verified that when CLISTMON complains about loss of sync because EOE buffer bits disagree with MB buffer bits, the buffer coming with the clusters for that event are actually OK. Also, when Steven disables that message, the data from CLIST are still always in sync.</pre>
<!-- Author: monica -->
<!-- Comment: Thu Dec 13 20;22;21 comment by...Steve Kuhlmann -->
<pre>Later in the shift e-log it was reported there was trouble with Isolist and it was unplugged.  It was likely due to the change of code mentioned in #4,  since a mismatch of EOE buffer
bits on Isolist triggers a piece of firmware that thinks 
it is trying to recover sync.  It was 
masked by the L2 Timeout/HRR that Clist used to generate due to
the same signal.  As Peter Wittich was putting new Iso
error checking code into the alpha,  this firmware was 
going to change anyway.  But in the meantime will work with
Mich. folks to find a happy medium.</pre>


<!-- Date: Fri Dec 14 03:43:07 2001 -->
<pre>testing electron trigger continues 
 
 I ran the L2 test code with  Heather's test run 
(134523, 500 events).  Here is the number of the events 
which pass the L1 and L2 triggers.  "Old" means the bit   
from the input TL2D bank, and "New" is decision 
of the most recent electron code after some modification. 
 
 bit              0      1      2      3      4      5      6 
 
Old L1 bits:    423    139    500      2 
Old L2 bits:     33    417    124    359     76      0      4 
New L2 bits:     32    403    123    357    129      1      4 
 
See TEST_ELECTRONS_PHOTONS trigger table for 
trigger bit assignmemts 
 
 Isolation trigger rate is ~2 times higher, but now we are 
sure doing right thing. These can be just spike.  Small 
difference for electron triggers comes from the new XTRP 
mapping, and also by rejecting 3 Layer XFT tracks.  
The mapping is with K=8.72, sigmaK=3.66, and sigmaA=5 degree. 
One interesting check is to lower sigmaK=sigmaA=1 degree,  
then look at the L2 rate. 
 
XTRP map:        32    361    120    357    129      1      4 
 
 So ~10% effect for 4 GeV electron trigger rate, no effects for 
higher ET electrons, I guess it can be &gt;30% effect for 
2 GeV dielectron trigger. 
 
 I was also able to restore the Reces data to alpha and 
run some simple trigger codes. 
 
With Reces:      16    101     38    110     37      0      1 
 
 This is with "High" (8 GeV) threshold, and just with 
the wedge to wedge matching (not using XFT phi). 
Note the input data is not real Reces trigger bit but the 
simulated bit from the CES raw data. I guess at the next 
test, we can use the real Reces bit. The reduction factor 
 ~3 agrees with the expectation. 
 
 
</pre>
<!-- Author: Masa -->


<!-- Date: Fri Dec 14 11:11:06 2001 -->
Moved Rev B Track Fitter #8 (labeled #12) from UC to B0 SVT 
test stand.  Moved Rev A Track Fitter from test stand to B0 
spares cabinet.  Moved Merger #29 and XTFC #6 from test stand to spares 
cabinet.  
<!-- Author: Bill A -->


<!-- Date: Fri Dec 14 11:49:42 2001 -->
<big>SMXR default thresholds from the Trigger Data Base have been fixed! Please, restart Run Control to get updated values. 
</big>
<!-- Author: Alexei -->
<!-- Comment: Sat Dec 15 04;09;34 comment by...masa -->
<pre>It looks fine now, thanks</pre>
<!-- Date: Fri Dec 14 16:27:29 2001 -->
<pre>Yesterday's News 
----------------- 
 
The PIO fpga firmware was changed on the Alpha board which 
fixed the DTO problem when reading Reces. Reading out all the 
Reces boards on each L2A is now the default. That means removing 
any Reces board would cause the Alpha to either crash or have 
large amounts of deadtime as it would fail on reading Reces. 
 
I also had 2 Alphas running with beam. This basically works, 
although there is still a bug in the code which lets the Alphas 
get out of sync. This is the one remaining problem before 
we have the default configuration as 2-3 alphas, L1, Tracklist, 
Clist, Svtlist, Isolist, Reces(with readout). This is the  
goal for Jan. 4 as stated in at the L2review. 
 
We had trouble with the Isolist board as we were leaving. We had 
to pull that board to get the crate stable. Whatever isolist 
was doing was causing L2 timeout errors because the L1 board 
couldn't send its data.  
 
I replaced the SL7 part of TL2D with L1 scalers which is needed 
to get the livetime L1 rate. Bill Badgett quickly changed the  
Scaler gui and crate code and we saw that it was working properly. </pre>
<!-- Author: Stephen -->


<!-- Date: Fri Dec 14 16:50:51 2001 -->
<pre>Comment from L2 meeting on Monday and Wed. 
 (Any tests documented above are not covered) 
The major discussion was on getting the code in place for 
Jan. 4th (and beyond). 
The priority is to fully validate and test with beam the  
essential triggers for the physics table. 
These are 
Jet, Electron, Photon, HadronicB, SvtTrack.  
These will first be tested with Masa's testcode. Once that works 
we will make test physics tables (decoupled from L3) and request 
beam time next week for making these tests.  
As other triggers are written, they will be tested in the same 
way. 
</pre>
<!-- Author: Stephen -->


<!-- Date: Fri Dec 14 23:15:35 2001 -->
As of this afternoon, the tracklist boards in b0l2de00 and b0svt06 have new firmware from Dec 12.
<!-- Author: Matt -->