<!-- Title: 15:49:26  Thu Aug 26 2004 -->
<!-- Crewchief: Pulsar folks -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>********* work during shutdown ************ 
 
(0) learn as much as we can from the beam data we took; 
 
(1) documentation & documenation  
 
* firmware 
* software (CPU algorithm/interface software, PulsarMon,  
  online/VME readout,  online diagnostic tools etc) 
* what we learned from data  
* etc ... 
 
(2) prepare for IRR (Installation Readiness Review) on Sept.27th. 
 
(3) improve firmware/software etc. and use teststand and  
    trigger room setup to continue the testing... </pre>


<!-- Date: Mon Aug 30 17:49:25 2004 -->
pulsar timing plots can be found in my <a href =  
/WebTalks/Archive/0408/040827_trig/04_040827_trig_Burkard_1_reisert_thard_040827.pdf 
> talk </a> at the trigger hardware meeting 08/27.
<!-- Author: Burkard -->
<!-- Comment: Thu Sep  2 09;39;31 comment by...Burkard -->
The link above is broken follow this new <A HREF =
http://www-cdf.fnal.gov/internal/WebTalks/Archive/0408/040827_trig/04_040827_trig_Burkard_1_reisert_thard_040827.pdf
> link </a>


<!-- Date: Mon Sep 13 15:23:03 2004 -->
<pre>Removed chassis containing passive splitters in preparation for 
move of XCES fibers.  The XCES fibers are presently coupled into  
the system at the rear of 2RR31C.  Dervin and his crew plan on  
moving them to the front of this rack sometime "soon".  Needed to  
remove passive splitter chassis to make room for the patch panels 
AND the active splitter crate. 
 
Passive splitters can be reinserted in the rack if need be later.</pre>
<!-- Author: neu -->


<!-- Date: Wed Sep 29 11:12:06 2004 -->
<pre>Steve Nahn and I did a test run with Pulsar driving L2 and Test 
Silicon SRC crate sending L1Done to the TS.  The test worked 
on the first attempt.  Steve thinks that the reason it didn't 
worked on the previous attempt before the shutdown was because 
one of the registers which tells the SRC to ignore VRB was not 
set properly.  The issue about setting registers in the TS 
to expect L1Done from the test crate should have already been 
taken care of by RC during CONFIG, so that was not the problem. 
Steve is happy that all the mysteries are resolved.  See his 
original message below: 
 
 
======================================= 
Message from Steve Nahn: 
======================================= 
Hi Cheng Ju, Ted 
  One question I asked in closed session which I should have  
asked Cheng Ju (but we were pressed for time) was if there were 
any problems that "went away" without real understanding.  I  
knew of two candidates: 1) reformatter errors - this one Ted  
said was solved by a bug fix in the FER readout code 
2) The failure of the Silicon test crate with Beam conditions 
This one really bugged me at the time, because Marcel and Rong  
really should not have pursued using the Silicon when the  
saftey check we put into the procedure failed and noone really 
understood why.  The fear was not necessarily based on high  
rate or resonance, but simply what the TS might or might not  
do when the nature of the L2 handshake is fundamentally changed 
 (like it comes from a different source), but everyone focused  
on the devils we know, rather than the ones we don't. 
I'm willing to chalk it up to pilot error somehow, but would  
like to see this test working again.  Depending on the  
timidity of the Silicon SPLs, you may want to have this crate 
usable during commissioning to try out as you change trigger  
conditions by using more and more of the Pulsar 
anyway.  Can we sit down for an hour sometime and try to  
replicate the conditions?  I'd need an hour with the test  
crate first to get it working with the TS without wasting your  
time.  Let me know when we can do this. 
 
Thanks 
 
Steve</pre>
<!-- Author: Cheng-Ju -->


<!-- Date: Mon Oct 4 13:06:58 2004 -->
<table><tr><td><a href=/elog/notebooks/l2upgrade/Mon_Oct__4_2004_130651.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-204  align='top'></a></td><td>Clock and controls coming to tstxft2 look okay.  Pictured is CDF_CLK, CDF_L1A and CDF_L1R.</td></tr></table>
<!-- Author: neu -->


<!-- Date: Mon Oct 4 13:08:53 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-205&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-206  width='300' align='top'></a></td><td>Picture of one data line and data strobes on Tx and Rx mezzanine cards.  Data looks good on both side, but as you can see below, the dump of the DAQ buffers for this event on this channel are fouled.  </td></tr></table>
<!-- Author: neu -->


<!-- Date: Mon Oct 4 13:11:16 2004 -->
<pre>Here is what the dump of the DAQ buffers looks like for the event  
pictured above: 
 
======================================================================== 
PULSAR IDPROM:  0002 094 PULSAR SLINK MERGER 
------------------------------------------------------------------------ 
DUMP NUMBER Of WORDS TO BE READ 
FPGA:  Control DataIO1 DataIO2 
DAQ0:      000     016     016 
DAQ1:      000     000     000 
------------------------------------------------------------------------ 
DUMP DATA CONTENT 
DAQ Base Address:0x  800000 
DAQ 0 
DAQ Base Address:0x  820000 
DAQ 0 
DAQ Base Address:0x  880000 
DAQ 16 
 efefefef 00000001 bebebebe 00000001 adadadad 00000001 dededede 00000001 
 efefefef 00000001 bebebebe 00000001 adadadad 00000001 dededede 00000001 
DAQ Base Address:0x  8a0000 
DAQ 0 
DAQ Base Address:0x  8c0000 
DAQ 16 
 efefefef 00000001 bebebe01 00000001 adadadad 00000021 dededede 00000001 
 efefef01 00000001 bebebebe 00000001 adadadad 00000001 dededede 00000001 
    (*)      (*) 
DAQ Base Address:0x  8e0000 
DAQ 0 
======================================================================== 
 
My channel that I am probing is channel 12 (of 16, counting from 0...the 
top channel on the bottom mezz card pair).  This corresponds to the 
2 data words marked with (*) under them in the above printout.  I expected 
this data to be "efefefef 00000001" (and the LA picture verifies  
that claim on the Tx and Rx mezz cards), so clearly there is a  
problem. 
 
</pre>
<!-- Author: neu -->
<!-- Comment: Mon Oct  4 13;14;05 comment by...neu -->
<pre>Sakari and I are looking at the debug lines at the DATAIO FPGA to
see where the DAQ buffer data gets screwed up.  More to come later...</pre>


<!-- Date: Mon Oct 4 13:45:02 2004 -->
<center><a href='/elog/notebooks/l2upgrade/Mon_Oct__4_2004_134339.ps'><img src='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-208' ></a><a href='/elog/notebooks/l2upgrade/Mon_Oct__4_2004_134417.ps'><img src='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-210' ></a><a href='/elog/notebooks/l2upgrade/Mon_Oct__4_2004_134428.ps'><img src='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-212' ></a></center>
<!-- Author: neu -->
<!-- Comment: Mon Oct  4 13;55;58 comment by...neu -->
<pre>So this may or may not be interesting.  Pictured on these 3 
frames are the same lines in each.  Green is CDF_L1A and purple 
and pink are CDF_L2B0 and _L2B1.  These are taken on the Rx 
card in tstxft2.

The first pic is a Myron Mode event in which L1As are 
issued on 4 consecutive events; necessarily under these 
circumstances each event would be written to its own L2 buffer 
0-3 - and that is what we see on the L2 buffer number lines, 
going from 0 to 1 to 2 to 3 (inverted) in the 132ns bins during 
which CDF_L1A is active (inverted).    

The other 2 pics are from non-MM event.  From the 2nd pic, one 
can see that the L1A lasts only one 132ns clock.  But we see 
that one of the L2 buffer lines goes low and remains low for 
quite some time.  One can see just how long it remains low in 
the last picture, which is a zoomed out version of the same 
event.  It stays low for a real long time, until the next L1A 
is issued.

I do not think this is causing my problems in Tx-Rx tests - see 
two or three entries above for CDF_CLK wrt CDF_L1A and you will
see the rising clock edge in the middle of CDF_L1A, which is
in the regime where the L2 buffer number lines are okay in the 
second pic above.  

But I wonder why this line is behaving this way.</pre>


<!-- Comment: Mon Oct  4 15;44;13 comment by...neu -->
<pre>Sakari says he has seen this problem or feature before.</pre>
<!-- Date: Mon Oct 4 15:43:25 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-217&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-218  width='300' align='top'></a></td><td>Today Sakari and I found an interesting failure mechanism  
on the Rx side.  The data strobes from the mezz card are 
getting screwed up in the DATAIO FPGA.  Here we see an  
instance of receiving six instead of the correct number of  
five strobes.  This is the likely cause for my Tx-Rx 
problems of the past few weeks.</td></tr></table>
<!-- Author: neu and sakari -->



<!-- Date: Wed Oct 6 00:28:37 2004 -->
<pre>Cheng-Ju and Burkard have put FNAL property stickers on all Pulsars and AUX cards. Here are the details: 
 
 
FNAL Tag   Serial #    Location         Description      
----------------------------------------------------------------- 
529777      00         CDF B0/202    Pulsar Aux Card (3.3V)  
529778      01         CDF B0/202    Pulsar Aux Card (3.3V)  
529779      02         CDF B0/202    Pulsar Aux Card (3.3V)  
529780      03         CDF B0/202    Pulsar Aux Card (3.3V)  
529781      04         CDF B0/202    Pulsar Aux Card (3.3V) 
529782      05         CDF B0/202    Pulsar Aux Card (3.3V)  
529783      06         CDF B0/202    Pulsar Aux Card (3.3V) 
529784      07         CDF B0/202    Pulsar Aux Card (3.3V) 
529785      08         CDF B0/202    Pulsar Aux Card (3.3V)  
529786      09         CDF B0/202    Pulsar Aux Card (3.3V) 
529787      10         CDF B0/202    Pulsar Aux Card (3.3V)  
529788      11         CDF B0/202    Pulsar Aux Card (3.3V)  
529789      12         CDF B0/202    Pulsar Aux Card (3.3V) 
529790      13         CDF B0/202    Pulsar Aux Card (3.3V) 
529791      14         CDF B0/202    Pulsar Aux Card (3.3V)  
529792      15         CDF B0/202    Pulsar Aux Card (3.3V)   
529793      16         CDF B0/202    Pulsar Aux Card (3.3V)  
529794      17         CDF B0/202    Pulsar Aux Card (3.3V)   
529795      18         CDF B0/202    Pulsar Aux Card (5.0V)   
529796      19         CDF B0/202    Pulsar Aux Card (5.0V)  
529797      20         CDF B0/202    Pulsar Aux Card (5.0V) 
529798      21         CDF B0/202    Pulsar Aux Card (5.0V)   
529799      22         CDF B0/202    Pulsar Aux Card (5.0V)   
                        
529800      0000       CDF B0/202    Pulsar board (proto-type)  
529801      0001       CDF B0/202    Pulsar board (proto-type)  
529802      0002       CDF B0/202    Pulsar board (proto-type)  
529803      0003       CDF B0/202    Pulsar board (proto-type)   
529804      0100       CDF B0/202    Pulsar board (thin board)  
526805      0101       CDF B0/202    Pulsar board (thin board)   
529806      0102       CDF B0/202    Pulsar board (thin board) 
529807      0103       CDF B0/202    Pulsar board (thin board)  
529808      0104       CDF B0/202    Pulsar board (pre-product) 
529809      0105       CDF B0/202    Pulsar board (pre-product) 
529810      0106       CDF B0/202    Pulsar board (pre-product) 
529811      0107       CDF B0/202    Pulsar board (pre-product) 
529812      0108       CDF B0/202    Pulsar board (pre-product) 
529813      0109       CDF B0/202    Pulsar board (pre-product) 
529814      0110       CDF B0/202    Pulsar board (pre-product) 
529815      0111       CDF B0/202    Pulsar board (pre-product) 
529816      0112       CDF B0/202    Pulsar board (pre-product) 
529817      0113       CDF B0/202    Pulsar board (pre-product) 
529818      2018       CDF B0/202    Pulsar board (production)  
529819      2019       CDF B0/202    Pulsar board (production) 
529820      2120       CDF B0/202    Pulsar board (production) 
529821      2121       CDF B0/202    Pulsar board (production) 
529822      2122       CDF B0/202    Pulsar board (production) 
529823      2123       CDF B0/202    Pulsar board (production) 
529824      2124       CDF B0/202    Pulsar board (production) 
529825      2125       CDF B0/202    Pulsar board (production) 
529826      2126       CDF B0/202    Pulsar board (production)  
529827      2127       CDF B0/202    Pulsar board (production) 
529828      2128       CDF B0/202    Pulsar board (production)   
529829      2129       CDF B0/202    Pulsar board (production)  
529830      2130       CDF B0/202    Pulsar board (production)  
529831      2131       CDF B0/202    Pulsar board (production)   
529832      2132       CDF B0/202    Pulsar board (production) 
529833      2133       CDF B0/202    Pulsar board (production)  
529834      2134       CDF B0/202    Pulsar board (production) 
529835      2135       CDF B0/202    Pulsar board (production) 
529836      2136       CDF B0/202    Pulsar board (production)  
529837      2137       CDF B0/202    Pulsar board (production)  
529838      2138       CDF B0/202    Pulsar board (production)  
529839      2139       CDF B0/202    Pulsar board (production)  
529840      2140       CDF B0/202    Pulsar board (production)  
529841      2141       CDF B0/202    Pulsar board (production)  
529842      2142       CDF B0/202    Pulsar board (production)  
529843      2143       CDF B0/202    Pulsar board (production)   
529844      2144       CDF B0/202    Pulsar board (production)   
529845      2145       CDF B0/202    Pulsar board (production)  
529846      2146       CDF B0/202    Pulsar board (production)  
529847      2147       CDF B0/202    Pulsar board (production)  
529848      2148       CDF B0/202    Pulsar board (production)  
529849      2149       CDF B0/202    Pulsar board (production)   
529850      2150       CDF B0/202    Pulsar board (production)  
529851      2151       CDF B0/202    Pulsar board (production)  
529852      2152       CDF B0/202    Pulsar board (production) 
529853      2153       CDF B0/202    Pulsar board (production)  
529854      2154       CDF B0/202    Pulsar board (production)   
529855      2155       CDF B0/202    Pulsar board (production)  
529856      2156       CDF B0/202    Pulsar board (production)  
529857      2157       CDF B0/202    Pulsar board (production)  
529858      2158       CDF B0/202    Pulsar board (production)   
529859      2159       CDF B0/202    Pulsar board (production)   
529860      2160       CDF B0/202    Pulsar board (production)   
529861      2161       CDF B0/202    Pulsar board (production)   
529862      2162       CDF B0/202    Pulsar board (production)   
</pre>
<!-- Author: Ted -->


<!-- Date: Wed Oct 6 00:33:39 2004 -->
<pre> 
The following 2 Pulsars + 1 AUX card are picked up by Fermi 
Shipping on Oct.5th, and they will be shipped to INFN-Pisa. 
The two Pulsars have P3 connectors. 
 
 
FNAL Tag   Serial #    Location         Description 
-------------------------------------------------------- 
529792         15      Pisa        Pulsar Aux Card (3.3V) 
529808         0104    Pisa        Pulsar board (pre-production) 
529829         2129    Pisa        Pulsar boar(production) 
</pre>
<!-- Author: Ted -->


<!-- Date: Wed Oct 6 15:08:43 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-219&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-219  width='300' align='top'></a></td><td>Debugging the "6-strobe" problem seen in Tx-Rx setup in  
teststand.  We have seen the problem now on 2 boards, 2122  
and 2147, in 2 crates, tstxft2 and tstl2trg2.   
 
Pictured is the data strobes before the FPGA (green) and  
after synchronization within the FPGA (yellow).  Clearly  
the problem is arising in the FPGA.  </td></tr></table>
<!-- Author: sakari and neu -->


<!-- Date: Wed Oct 6 16:29:25 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-220&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-220  width='300' align='top'></a></td><td>A new failure mechanism not yet seen.  This one is from board 0002 in tstl2trg2.  Here we see many events with 5 standard strobes followed by one event with at least 12 
strobes coming from the Tx.  This appears to be a Tx problem since the "many strobes" instance occurs upstream of the FPGA in the strobes received at the mezz card (yellow) as well as those in the FPGA itself (green and blue).</td></tr></table>
<!-- Author: neu and sakari -->


<!-- Date: Wed Oct 6 21:26:06 2004 -->
<pre>A simple protection was put in to protect against glitches Chris and Sakari saw on the data strobe for RECES. Initial test shows that it works, and we will leave it running over night to  
see if it really works. 
 
if this really works, then next thing is to finish the reces zero suppression firmware initial testing in the teststand, and move 
the new firmware into trigger room. 
 </pre>
<!-- Author: Sakari and Ted -->
<!-- Comment: Wed Oct  6 22;22;38 comment by...Ted -->
<pre>before I went home, I took a look at the test again, and it is
still error free (been running for a few hours). looks like this
fix is very promising... and may also fix the problems we saw with the beam data long ago. 
now we will need to look for next level problems, if there is any.</pre>


<!-- Comment: Thu Oct  7 15;31;05 comment by...Ted -->
<pre>the overnight run has no error. Sakari started another run at
high rate. now this run is at more than 14M events, no single
error occured.</pre>
<!-- Date: Wed Oct 6 23:08:26 2004 -->
<pre>while working on the Reces glitch problem, I talked to Vadim and 
Sakari about the Iso problem, and looked over the firmware (in the common lib). It looks like a simple problem to me. since this is the only place variable is used in the firmware, I would like say a few words here in the e-log. 
 
looks like the possible cause of the problem is in the implementation of a counter which keeps track of how many events left in the FIFO (to inform SLINK formatter to send the event). The counter value is declared as a *variable*(as an integer with range from 0 to 7) in the firmware, and the logic is very simple: 
 
if (EOEin =1), count = count + 1; 
if (EOEout=1), count = count - 1; 
 
the problem here is that the logic assumes that EOEin and EOEout will never be high at the same time (the same clock tick). This is likely true for most cases (and may explain why it works in all other cases), but could happen in the RECES case where many events are empty events and they arrive quickly after L1A. if one relative large event followed right after an *almost* empty event, there is a chance (time window) the EOE for the previous event could get out the FIFO at the same time the EOE for the next event comes into the FIFO. this doesn't happen often (very rare), and it depends on the event size as well as the L1A rate/patterns. this may explain why it happens more often in beam but much harder to reproduce it in L2 torture and teststand. 
 
the fix should be very simple: 
 
if (EOEin =1 and EOEout=0), count = count + 1; 
if (EOEout=0 and EOEout=1), count = count - 1; 
(if both high, do nothing). 
 
the other feature I saw is that the variable is declared outside the process, it should be declared within the process. unlike signals, variables are only available within the process and only known within the process, with immediate assignment. it behaves very differently(compare to signals). but looks like the compiler didn't complain (it should), we should move the declaration into the process. 
 
in any case, this will be the only place where we use variable 
in the firmware. we should try not to use variables at all in the firmware (my past experience at LBL: it is easy to introduce subtle problems with variables... and it happened to some best engineers I knew). 
 
will see if this will fix the Iso problem.</pre>
<!-- Author: Ted -->



<!-- Date: Fri Oct 8 10:12:09 2004 -->
<pre>Bill's important comment in the main e-log: 
 
-------------------------------------------------------------------------------- 
 Thu Oct 7 19:30:16  
The global Level 2 configuration (in the Trigger   
Supervisor crate) can now be overridden by   
the user via specifying the L2ProcessorSelect   
mask in the RunSettings window's central scroll panel.  
 
The mask represents up to eight inputs for making   
a Level 2 decision;  with the bit 1, the TS will   
expect decisions and handshakes from that L2   
DecisionMaker.   Generally this value will only   
be changed by experts!   So don't worry if you   
don't know the spigot assignments.  
 
All stored run settings have been updated to   
default to the current L2 alpha processor providing   
the decision.   Note that RunControl still will   
require the L2DecisionMaker (alpha, pulsar, ghostbuster)   
to be present in the run, else an error will be   
generated.  
 
Have asked DAQ Ace to restart RunControl to   
test out.  
 
 - W.Badgett :: (run 187893) </pre>
<!-- Author: Ted -->


<!-- Date: Tue Oct 12 19:32:34 2004 -->
<pre>Sakari has finished the initial successful testing of the Reces zero-suppression firmware in teststand room... it is now ready to be tested in the trigger room. He also added timing information at the Control FPGA output, and tested it. </pre>
<!-- Author: Ted for Sakari -->


<!-- Date: Tue Oct 19 17:15:11 2004 -->
<pre>Quick HOW-TO to check the registers on the L2 PULSAR CRATE (b0l2pu00) 
 
1) To check the registers on an on-line machine: 
 
cd /mnt/autofs/cdf/people3/reisert/pulsar/tools/ 
 
&gt;vxtest b0l2pu00 
&gt;vxexec b0l2pu00 "scanCrate2()" 
 
2) Power down the crate. 
 
--Change firmware of a PULSAR board if applicable-- 
 
3) Power up the crate. 
 
4) Run same commands again 
 
&gt;vxtest b0l2pu00 
&gt;vxexec b0l2pu00 "scanCrate2()" 
(see below for output) 
 
================================================= 
 
On 2004 October 19 firmware changes made to PULSAR SVT board.   
 
slot 03: IDPROM: 0040 001 TRACER__V2.1A 
 
slot 05: IDPROM: 0016 086 PULSAR MUON RX 
Readonly regs - CTRL: 04408060, DataIO1: 08407020, DataIO2: 08407020 
 
slot 07: IDPROM: 0018 094 PULSAR SLINK MERGER 
Readonly regs - CTRL: 02408190, DataIO1: 08410060, DataIO2: 08410060 
 
slot 09: IDPROM: 0034 094 PULSAR SLINK MERGER 
Readonly regs - CTRL: 02408190, DataIO1: 08410060, DataIO2: 08410060 
 
slot 11: IDPROM: 0002 094 PULSAR SLINK MERGER 
Readonly regs - CTRL: 02408190, DataIO1: 08410060, DataIO2: 08410060 
 
slot 13: IDPROM: 0004 092 PULSAR SVT RX 
Readonly regs - CTRL: 05410180, DataIO1: 09407280, DataIO2: 09407280 
 
slot 15: IDPROM: 0028 093 PULSAR SLINK TX 
Readonly regs - CTRL: a0406300, DataIO1: 08407230, DataIO2: 08407230 
 
slot 17: IDPROM: 0061 096 PULSAR TS INTERFACE 
Readonly regs - CTRL: 0a408200, DataIO1: 09408210, DataIO2: 09408210 
 
slot 19: IDPROM: 0012 094 PULSAR SLINK MERGER 
Readonly regs - CTRL: 02408190, DataIO1: 01408210, DataIO2: 01408210 
 
slot 21: IDPROM: 0014 094 PULSAR SLINK MERGER 
Readonly regs - CTRL: 02408190, DataIO1: 01408210, DataIO2: 01408210 
 
</pre>
<!-- Author: Shawn Kwang -->


<!-- Date: Tue Oct 19 18:19:14 2004 -->
<pre>Changes to the SVT RX firmware from version 05408210 to 05410180: 
S-LINK formatter will start sending data out as soon as it starts to arrive, not after the data for one event is fully received.</pre>
<!-- Author: Sakari -->


<!-- Date: Tue Oct 19 18:23:26 2004 -->
<pre>Use Burkard's script to set default configuration after power cycling b0l2pu00. 
~reisert/pulsar/tools 
./vxb0l2pu00 
See Pulsar Commissioning Tools document for more info. 
 
This is still necessary, but will be changed for the future firmware versions.</pre>
<!-- Author: Sakari -->


<!-- Date: Thu Oct 21 18:07:04 2004 -->
<pre>What follows is a chronicle of the signal characteristics into,  
within and out of the Active Splitter circuit.   
 
We are seeing a curious feature in that - despite measuring the  
output light strength of the AS circuit to be stronger than or  
equal to that of the TAXI mezzanine card Tx drivers - the output  
waveform of the AS has an amplitude approximately half  
the size of an un-split signal.  This feature contributes to the 
failure of the cascade test (driving a chain of active splitter  
circuits).   
 
One should note that this circuit has been tested in normal  
running setup for VLTN signal, with XCES patterns in the  
teststand and in beam running driving pulsar boards, and no 
significant problems have been identified.   
 
The pertinent question is: how can the amplitude of the output  
waveform be half of an unsplit signal, while we measure that the 
light yield on the channel is comparable or greater than the   
unsplit signal?  </pre>
<!-- Author: neu -->


<!-- Date: Thu Oct 21 18:10:06 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-221&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-221  width='300' align='top'></a></td><td>This is a comparison of the signal shape from one of our Tx mezzanine cards received at a Rx mezz card (pink) and at the AS circuit (green).  While the amplitudes are similar, the DC offsets are completely different (+2.2V at the Rx mezz card, -3.2V at the AS).  </td></tr></table>
<!-- Author: neu -->


<!-- Date: Thu Oct 21 18:13:01 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-225&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-225' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-226&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-226' width='300'></a></center>
<!-- Author: neu -->
<!-- Comment: Thu Oct 21 18;20;02 comment by...neu -->
<pre>Left: Purple is the input to the comparator on the AS; this is 
the analog signal we receive at the Rx after its DC offset is 
removed - 300mV centered now on -25mV (rather than -3.2V as at 
Rx part).  Green is the output of the comparator; note that this 
is the inverted output - so though it appears that there is some 
propogation delay, it is a mirage.  

Right: Green is the input to the 4-line receiver; this should be 
the same as the output of the comparator - and indeed it is.  
Purple is the output of the 4-line receiver; again note the 
inversion - after 2 inversions we are back to our input 
waveform.  The size is important here: the output is a 1V 
amplitude signal centered on -1.25V.  </pre>


<!-- Date: Thu Oct 21 18:23:31 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-227&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-227  width='300' align='top'></a></td><td>Kind of ratty, but green is output signal probed at Tx optical part on AS, pink is output signal probed at Tx optical part on Tx mezzanine card.  Note the difference in the offsets - -1.25V (green, AS) versus +3.5V (pink, Tx mezz card).</td></tr></table>
<!-- Author: neu -->
<!-- Comment: Thu Oct 21 18;36;09 comment by...neu -->
<pre>Note that when comparing things at two different Tx's, one should
really compare the current across the device - it is after all 
an LED and its response is determined by the current.  This was 
done by measuring the voltage across some known resistance in 
series with the Tx cathode:

          AS: R=60ohm  (R6)  V=1.7V  =&gt; I= 0.028A
Tx mezz card: R=33ohm (Rx_7) V=0.4V  =&gt; I= 0.013A

Interesting - this is consistent with the light strength 
measurements.</pre>


<!-- Date: Thu Oct 21 18:38:15 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-228&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-228' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-229&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-229' width='300'></a></center>
<!-- Author: neu -->
<!-- Comment: Thu Oct 21 18;41;19 comment by...neu -->
<pre>Left (pink): this is what the output of the AS circuit looks
like at the optical Rx part on the Rx mezz card.  Amplitude is 
around 120mV but centrered on +2.2V.

Right (green): this is what the output of the AS circuit looks 
like when it is received into another AS circuit.  Similar 
amplitude to pink plot (120mV) but cenetered on -25mV or so.  

Rick, this is one of the comparisons we discussed today.   </pre>


<!-- Date: Thu Oct 21 18:42:36 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-230&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-230' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-231&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-231' width='300'></a></center>
<!-- Author: neu -->
<!-- Comment: Thu Oct 21 18;45;56 comment by...neu -->
<pre>Here is the real confusing comparison!

Right pic is just a zoomed-in version of the left.  

These are measurements on the Rx mezzanine card comparing a
channel whose signal was not split (pink) with one that was
actively split (yellow).  One can see that there is the ~same DC 
offset on the Rx side, but that the amplitude is smaller for the 
actively split signal (200mV versus 350mV). </pre>


<!-- Date: Thu Oct 21 18:47:07 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-232&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-232' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-233&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-233' width='300'></a></center>
<!-- Author: neu -->
<!-- Comment: Thu Oct 21 18;52;10 comment by...neu -->
<pre>This is a comparison to look at the influence of the current
across the AS Tx on output signal.  These waveforms were 
measured at the Rx mezz card.  Right is just a zoomed-in version
of the left pic.

Purple is 30ohm current limiting resistor on the Tx, yellow 
is 60ohm...one can see that by going to 60ohm, one reduces 
not only the DC offset of the outgoing signal, but also the
amplitude - although the amplitude change is not large.  

Could one insert a tiny resistor in place of the 30ohm and see 
if we recover the appropriately sized output signals?  But what 
about the argument that we coiuld be flooding too much light 
into the Rx's (per the light meter readings)?</pre>


<!-- Date: Thu Oct 21 18:54:08 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-234&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-234' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-235&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-235' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-236&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-236' width='300'></a></center>
<!-- Author: neu -->
<!-- Comment: Thu Oct 21 19;02;37 comment by...neu -->
<pre>Open your browser nice and wide for this one...it makes it 
easier to understand this description.

The left-most plot is the output of the AS measured at the Rx 
mezz card on a standard channel that is actively split with 
60ohms (yellow - should be same as above) versus that of a 
channel that is -3.5dBm reduced before input to the AS.  The 
reduction was accomplished using a passive splitter.  This
shows that we do not have a significant signal deformation if 
the AS is confronted with an ultra-weak input channel. 

The center plot compares the same actively-split benchmark 
signal (yellow) versus an actively split signal that is then
passed through the -3.5dBm passive splitter.  This is a sanity
check to see if we see a signal redux on the Rx mezz card
where we expect to - and indeed we do.  Note however that both
the DC offset and amplitude are different unlike the comparison
in which we loook at a split versus unsplit received signal.

The right plot is a picture of the same actively split benchmark
versus passively split signal.  Again, signal DC offset 
reduction - amplitude should reappy be compared to unsplit 
signal above.</pre>


<!-- Date: Thu Oct 21 19:03:03 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-237&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-237  width='300' align='top'></a></td><td> </td></tr></table>
<!-- Author:   -->
<!-- Comment: Thu Oct 21 19;04;18 comment by...neu -->
<pre>This is a picture of what the Rx sees on the actual RECES electronics in the alpha crate.  This is consistent with 
what the TAXI pulsar mezz card sends out.  </pre>


<!-- Date: Thu Oct 21 19:05:39 2004 -->
<pre>So that is a compendium of pictures I have been looking 
through for the past several days.  I do not know how to  
reconcile the light output measurements with the amplitude.</pre>
<!-- Author: neu -->


<!-- Date: Mon Oct 25 10:53:26 2004 -->
<pre>HWDB change: ShowerMax board in b0l2pu00 slot 7 was marked  
ONLINEFLAG=0; slot 9 was marked ONLINEFLAG=1; slot 11 remained  
ONLINEFLAG=0. 
 
Currently we are driving actively-split data to slot 9, and I would  
like this to be readout when possible.</pre>
<!-- Author: neu -->


<!-- Date: Tue Oct 26 16:27:47 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-239&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-239  width='300' align='top'></a></td><td>More information on the signals transmitted from the TAXI  
Tx mezz card.  This is a measure of the Tx signal on both  
sides of R3_7 on the Tx mezz card.  </td></tr></table>
<!-- Author: neu -->


<!-- Date: Wed Oct 27 21:20:12 2004 -->
<pre>Jonathan and I have cleaned up the LVDS cabling in the L2 
decision and Pulsar crate.  The splitter board is now moved 
from the top alpha crate (slot 20) to the lower alpha crate 
(slot 17).  </pre>
<!-- Author: Cheng-Ju -->


<!-- Date: Wed Nov 3 13:09:04 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-240&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-241' ></a><a href='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-242&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-243' ></a></center>
<!-- Author: neu -->
<!-- Comment: Wed Nov  3 13;14;25 comment by...neu -->
<pre>New drive scheme - top trace is unsplit signal, bottom is split 
signal using new driver. Right plot is just zoomed in version of 
the left to get better loook at the rise and fall times.   

We see that an unsplit signal(top) has about a 275mV AC amplitude 
with rise and fall times around 9ns.

However while the split signal with new drive (bottom) has an 
amplitude of nearly the same size - around 250mV - we see that
the rise and fall times are grossly exagerated (~25ns for fall
time - not measured in the picture, but you can see it).</pre>


<!-- Comment: Wed Nov  3 13;26;44 comment by...neu -->
<pre>More critical - the driven output does not really resemble the 
input, but this could be due to several different reasons.</pre>
<!-- Date: Wed Nov 3 13:15:08 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-246&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-247' ></a><a href='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-244&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-245' ></a></center>
<!-- Author: neu -->
<!-- Comment: Wed Nov  3 13;21;03 comment by...neu -->
<pre>Top is unsplit, bottom is split using standard drive scheme.  
Again, right is zoomed in version of left plots.

The unsplit signal is still the same of course (275-300mV, rise/fall time of 9ns).

But this split driven output signal is a bit smaller, about 200mV.
The rise and fall times are comparable to an unsplit signal (about 9ns).

Notw that all these measurements were taken at the output of the 
Agilent Rx part on the Rx mezzanine card.</pre>
<!-- Date: Wed Nov 3 13:17:02 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-252&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-253' ></a></center>
<!-- Author: neu -->
<!-- Comment: Wed Nov  3 13;25;36 comment by...neu -->
<pre>So here is what the output signal looks like for unsplit (again, it 
is the top waveform) versus a 3-circuit cascade (bottom). 

While the unsplit is still of course unchanged (275mV and 9ns)
the 3-channel cascade is slightly different from the single channel
drive setup depicted immediately above.  The 3-channel cascade 
has an AC amplitude of about 175mV versus 200mV for 1 channel.

Sorry I have no zoomed in version for this, but one can read off
a measurement of the rise time for the 3-channel cascade of 11ns, 
which is not terribly different than 9ns.

This setup does not induce VLTN when tested on the bench here at 
Penn.

</pre>



<!-- Date: Wed Nov 3 18:02:00 2004 -->
<pre>slot 03: IDPROM: 0040 001 TRACER__V2.1A 
 
slot 05: IDPROM: 0016 086 PULSAR MUON RX 
Readonly regs - CTRL: 04408060, DataIO1: 08407020, DataIO2: 08407020 
 
slot 07: IDPROM: 0018 094 PULSAR SLINK MERGER 
Readonly regs - CTRL: 02408190, DataIO1: 08410060, DataIO2: 08410060 
 
slot 09: IDPROM: 0034 094 PULSAR SLINK MERGER 
Readonly regs - CTRL: 02408190, DataIO1: 08410060, DataIO2: 08410060 
 
slot 11: IDPROM: 0002 094 PULSAR SLINK MERGER 
Readonly regs - CTRL: 02408190, DataIO1: 08410060, DataIO2: 08410060 
 
slot 13: IDPROM: 0004 092 PULSAR SVT RX 
Readonly regs - CTRL: 05411010, DataIO1: 09407280, DataIO2: 09407280 
 
slot 15: IDPROM: 0028 093 PULSAR SLINK TX 
Readonly regs - CTRL: a0406300, DataIO1: 08407230, DataIO2: 08407230 
 
slot 17: IDPROM: 0061 096 PULSAR TS INTERFACE 
Readonly regs - CTRL: 0a408200, DataIO1: 09408210, DataIO2: 09408210 
 
slot 19: IDPROM: 0012 094 PULSAR SLINK MERGER 
Readonly regs - CTRL: 02408190, DataIO1: 01408210, DataIO2: 01408210 
 
slot 21: IDPROM: 0014 094 PULSAR SLINK MERGER 
Readonly regs - CTRL: 02411010, DataIO1: 01408210, DataIO2: 01408210 
 
Updated Slink Merger firmware for Pulsar in slot 21: 
- New Data Source ID. 
- New Slinkformatter.  
Updated SVT RX in slot 13: 
- New Slinkformatter.</pre>
<!-- Author: Sakari -->


<!-- Date: Mon Nov 8 14:08:44 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-256&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-256  width='300' align='top'></a></td><td> </td></tr></table>
<!-- Author:   -->


<!-- Date: Mon Nov 8 14:09:40 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-254&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-254' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-255&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-255' width='300'></a></center>
<!-- Author: neu -->
<!-- Comment: Mon Nov  8 14;18;59 comment by...neu -->
<pre>A few more studies of the optical signals.  Right is zoomed
version of the left plot.

Green is an unsplit signal at the Rx mezz card.
Purple is a signal with 1 passive splitter in its path (thus
introducing a ~-3dBm loss).  Pink is two passive splitters
in the path (a ~-6dBm loss).  

One can see from this that both the AC and DC components of the 
light change when using the passive splitter.   When one passive 
splitter is employed, the AC reduction is about 50%.  But the 
relationship is not really linear - the reduction in the AC for 
2 passive splitters (pink) is much larger than 50% wrt 1 
passively split signal (purple). 

Here are the numbers:

                Unsplit   1PS    2PS
                =======   ===    ===
Strength (dBm)   -18.5    -21.4  -25.8
DC (V)            2.0     1.8    1.6
AC (mV)           260     120    40

Note that the line with 2 passive splitters did not pull VLTN - 
meaning that one should be able to drive the Rx mezz card 
with 40mV on top of 1.6V.  </pre>


<!-- Date: Mon Nov 8 14:19:21 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-256&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-256' width='300'></a></center>
<!-- Author: neu -->
<!-- Comment: Mon Nov  8 14;22;35 comment by...neu -->
<pre>This is a comparison of an unsplit signal and an actively split
signal received at the Rx mezz card.  The relevant numbers:

                  Unsplit        AS
                  =======       ====   
strength(dBm)      -18.5        -11.7
DC (V)             1.9           2.4
AC (mV)            265           200
delta_t (ns)               15
t_rise (ns)        7              7
t_fall (ns)        11             11

 </pre>

<!-- Comment: Mon Nov  8 14;25;37 comment by...neu -->
<pre>Another note: I went back and cascaded passive splitters on the
input side to the AS.  With V_thresh = 10mV, the AS is capable
of splitting signals at -22dBm, but pulls VLTN for an input
signal at -25dBm.  Note that in the system we have not channels
below ~-20dBm. </pre>


<!-- Date: Mon Nov 8 14:44:17 2004 -->
<pre>One RECES card has the output pins of its Rx parts exposed, so 
I scanned these channels to look at how their AC and DC  
components behave with and without active splitting. 
 
                             Unsplit       Actively Split 
Channel    Strength(dBm)  DC(V)  AV(mV)     DC(V)  AC(mV) 
-------    -------------  -------------     ------------- 
  12           -15.6       1.8    380        2.0    150 
**13           -15.7       1.6    250        1.8    140   
  14           -15.2       1.7    375        2.0    170 
  15           -15.4       1.7    350        2.0    170 
  16           -15.5       1.6    340        2.0    160 
 *17           -19.7       1.5    140        2.0    170 
  18           -17.7       1.6    220        2.1    170 
  19           -16.2       1.6    300        2.0    180 
  20           -15.0       1.7    400        2.0    160 
  21           -15.4       1.6    380        2.0    160 
  22           -17.5       1.6    230        2.1    160 
 *23           -20.2       1.6    125        2.2    160 
 
As one can see channels East 17 and 23 are particularly weak.  
But when actively split the input signals are in fact enhanced - 
which is a nice feature if we were near threshold.   
 
All split signals looked crisp and clean, with good rise and  
fall times. 
 
East 13 is a problem channel that - by using the AS as a  
diagnosis tool - I was able to isolate to the RECES card.  The  
experts will be notified. 
 
But what one should take away from this table is that the  
actively split signals are pretty predictable regardless of the  
input signal sizes: 160mV or so on top of 2V.  And from the  
above entries, we know we can split input signals to our Rx mezz  
cards that are as small as -21dBm (120mV on 1.6V) and probably  
even a bit smaller but certainly we get failures at -25dBm.  
 
</pre>
<!-- Author: neu -->


<!-- Date: Tue Nov 9 08:17:43 2004 -->
<table><tr><td><a href=/elog/notebooks/l2upgrade/Tue_Nov__9_2004_081727.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-259  align='top'></a></td><td>TrigMon occupancy plot for Run 2A system.  In this pic, West0-15 are actively split.  This is a short run - but in general single-bit errors occur on West 7,10,11. West 14 has problems at a higher rate, the origin orf which is upstream frm the AS.  But these high rate problem last week were cropping up on West 11.  I think SMXRs have been shuffled a bit during CPR install.   I'll re-measure the light yield on this channel</td></tr></table>
<!-- Author: neu -->
<!-- Comment: Tue Nov  9 08;18;39 comment by...neu -->
<pre>Oh yes - by the way, I had swapped the input fiber to the AS with West 15 - that is why the "West-14-problem" in thie pic is appearing on West 15.</pre>


<!-- Date: Tue Nov 9 14:56:52 2004 -->
<pre>Optical splitter installation for the complete set of 48 ShowerMax   
channels into L2 is complete.  Now we need to take some test runs,  
L2T.  Waiting for some resources.  
 
Many thanks to Dervin Allen for his good ideas and great work.</pre>
<!-- Author: neu -->


<!-- Date: Tue Nov 9 22:40:13 2004 -->
<pre>Checkout of AS install: it appears that there are 3 flaky AS  
channels - 1W, 3E and 14E.  13E is still AFU but we have previous  
knowledge that that channel is bad at RECES Rx.   
 
I can try swapping out AS cards and inspecting the signal behavior 
on the suspect circuits. 
 
Single-bit-error rate is very small and scattered.  Need to look  
and see if this error mechanism is occupancy-dependent.    
 
</pre>
<!-- Author: neu -->
<!-- Comment: Wed Nov 10 12;00;04 comment by...neu -->
<pre>Swapped in another AS card for the circuit driving 1W.  The same
failure mechanism was exhibited - this decreases the likelihood
that a faulty AS circuit is the culprit.  Could/should try other 
AS circuits to see if any "work" for this channel.  Also, should 
do this exercise on all 3 bad channels.  

Optical power measurements show that each of these channels is 
pumping out a healthy amount of light: all channels between -14 
and -16 dBm, and control channels reproduced old values.

These 3 channels are behainv like our old friend E13, which is 
known to be a RECES Rx problem.  One cannot attribute the errors 
on 1W, 3E and 14E to this same type of problem until one looks 
with a scope at the signals at various points.  Will do so later
today.

</pre>


<!-- Date: Thu Nov 11 15:53:00 2004 -->
<pre>Updated firmware in b0l2pu00 
 
slot 03: IDPROM: 0040 001 TRACER__V2.1A 
 
slot 05: IDPROM: 0016 086 PULSAR MUON RX 
Readonly regs - CTRL: 04408060, DataIO1: 08407020, DataIO2: 08407020 
 
slot 07: IDPROM: 0018 088 PULSAR RECES RX 
Readonly regs - CTRL: 02411110, DataIO1: 08410080, DataIO2: 08410080 
 
slot 09: IDPROM: 0034 088 PULSAR RECES RX 
Readonly regs - CTRL: 02411110, DataIO1: 08410080, DataIO2: 08410080 
 
slot 11: IDPROM: 0002 088 PULSAR RECES RX 
Readonly regs - CTRL: 02411110, DataIO1: 08410080, DataIO2: 08410080 
 
slot 13: IDPROM: 0004 092 PULSAR SVT RX 
Readonly regs - CTRL: 05411100, DataIO1: 09407280, DataIO2: 09407280 
 
slot 15: IDPROM: 0009 090 PULSAR CLUSTER RX 
Readonly regs - CTRL: 0b411100, DataIO1: 07411090, DataIO2: 06411020 
 
slot 17: IDPROM: 0061 096 PULSAR TS INTERFACE 
Readonly regs - CTRL: 0a411030, DataIO1: 09408210, DataIO2: 09408210 
 
slot 19: IDPROM: 0012 094 PULSAR SLINK MERGER 
Readonly regs - CTRL: 02411100, DataIO1: 01411040, DataIO2: 01411040 
 
slot 21: IDPROM: 0014 094 PULSAR SLINK MERGER 
Readonly regs - CTRL: 02411100, DataIO1: 01411040, DataIO2: 01411040 
</pre>
<!-- Author: Sakari -->


<!-- Date: Wed Nov 17 02:58:15 2004 -->
<pre>We finally got the system running tonite. CES is through with 1 channel into the ces merger (ch2). here is the readout config. The run is 189723 
 
 
Name:        Seqnce CTRL1  CTRL2  DIO1_1 DIO1_1 DIO1_1 DIO1_1 NCHAN  BTBRD   ROL 
============ ====== ====== ====== ====== ====== ====== ====== ====== ====== ====== 
MERGER_CES       17     -1      0     -1     -1     -1      0      1     81      0 
  
L2TOTS           15      1      3     -1      2      0      0      1     96      0 
  
CLUSTER          13     -1      0     -1     -1     -1     -1      8     81      0 
  
SVT              11     -1     -1      0      0      0      0      1     81      7 
  
MUON              3     -1      0      0      0      0      0      1     81      7 
  
CES_0             5     -1      0     16      0     16      0      1     81      7 
  
MERGER_SLINK     21     -1      0     -1     -1     -1      0      1     81      0 
 
 
 
with this we get 750\mu sec 
 
 
</pre>
<!-- Author: sakari,vadim -->
<!-- Comment: Wed Nov 17 03;04;59 comment by...vadim -->
<pre>ran through 15M L1A 

per online monitoring: so far so good</pre>

<!-- Comment: Wed Nov 17 12;14;36 comment by...Ted -->
<pre>Vadim and Sakari:  good work! now it is time to get the system
back again... keep going.</pre>


<!-- Date: Wed Nov 17 17:40:20 2004 -->
<pre>Updated Slink Merger firmware in b0l2pu00. 
 
slot 03: IDPROM: 0040 001 TRACER__V2.1A 
 
slot 05: IDPROM: 0016 086 PULSAR MUON RX 
Readonly regs - CTRL: 04408060, DataIO1: 08407020, DataIO2: 08407020 
 
slot 07: IDPROM: 0034 093 PULSAR SLINK TX 
Readonly regs - CTRL: a0406300, DataIO1: 08410080, DataIO2: 08410080 
 
slot 09: IDPROM: 0018 093 PULSAR SLINK TX 
Readonly regs - CTRL: a0406300, DataIO1: 08410080, DataIO2: 08410080 
 
slot 11: IDPROM: 0032 093 PULSAR SLINK TX 
Readonly regs - CTRL: a0406300, DataIO1: 08410080, DataIO2: 08410080 
 
slot 13: IDPROM: 0004 092 PULSAR SVT RX 
Readonly regs - CTRL: 05411100, DataIO1: 09407280, DataIO2: 09407280 
 
slot 15: IDPROM: 0009 090 PULSAR CLUSTER RX 
Readonly regs - CTRL: 0b411100, DataIO1: 07411090, DataIO2: 06411020 
 
slot 17: IDPROM: 0061 096 PULSAR TS INTERFACE 
Readonly regs - CTRL: 0a411030, DataIO1: 09408210, DataIO2: 09408210 
 
slot 19: IDPROM: 0012 094 PULSAR SLINK MERGER 
Readonly regs - CTRL: 02411170, DataIO1: 01411040, DataIO2: 01411040 
 
slot 21: IDPROM: 0030 094 PULSAR SLINK MERGER 
Readonly regs - CTRL: 02411170, DataIO1: 01411040, DataIO2: 01411040 
 
Slink Merger firmware has an updated Slink formatter and improved data flow. Default input selection is now all inputs enabled. 
</pre>
<!-- Author: Sakari -->


<!-- Date: Wed Nov 17 20:06:17 2004 -->
<pre>Updated Slink Merger DataIO firmware. 
 
slot 03: IDPROM: 0040 001 TRACER__V2.1A 
 
slot 05: IDPROM: 0016 086 PULSAR MUON RX 
Readonly regs - CTRL: 04408060, DataIO1: 08407020, DataIO2: 08407020 
 
slot 07: IDPROM: 0034 093 PULSAR SLINK TX 
Readonly regs - CTRL: a0406300, DataIO1: 08410080, DataIO2: 08410080 
 
slot 09: IDPROM: 0018 093 PULSAR SLINK TX 
Readonly regs - CTRL: a0406300, DataIO1: 08410080, DataIO2: 08410080 
 
slot 11: IDPROM: 0032 093 PULSAR SLINK TX 
Readonly regs - CTRL: a0406300, DataIO1: 08410080, DataIO2: 08410080 
 
slot 13: IDPROM: 0004 092 PULSAR SVT RX 
Readonly regs - CTRL: 05411100, DataIO1: 09407280, DataIO2: 09407280 
 
slot 15: IDPROM: 0009 090 PULSAR CLUSTER RX 
Readonly regs - CTRL: 0b411100, DataIO1: 07411090, DataIO2: 06411020 
 
slot 17: IDPROM: 0061 096 PULSAR TS INTERFACE 
Readonly regs - CTRL: 0a411030, DataIO1: 09408210, DataIO2: 09408210 
 
slot 19: IDPROM: 0012 094 PULSAR SLINK MERGER 
Readonly regs - CTRL: 02411170, DataIO1: 01411170, DataIO2: 01411170 
 
slot 21: IDPROM: 0030 094 PULSAR SLINK MERGER 
Readonly regs - CTRL: 02411170, DataIO1: 01411170, DataIO2: 01411170 
 
DataIO Slink Merger: Removed debug pins. 
Seemed to cause board dependence.</pre>
<!-- Author: Sakari -->