<!-- Title: 17:48:26  Tue Mar  9 2004 -->
<!-- Crewchief: Pulsar folks -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Here we are trying to recover the previous e-log entries 
lost due to e-log problems in the past two days. 
and then continue from there. Burkard found it on one of 
the online machines we viewed last time. (but we still lost 
the page before this one). Ted will do the recovery. 
 
</pre>


<!-- Date: Tue Mar 9 17:49:27 2004 -->
<pre> 
     The ISO pattern received on two fibers.  
I use a slightly modified version of the RECES Tx. 
 
(but the picture is lost. Vadim, you can post it agian. TL)</pre>
<!-- Author: Vadim -->


<!-- Date: Tue Mar 9 17:50:58 2004 -->
<pre>Thu Feb 26, 01:13:50: 
 
 
 
We are taking some test runs splitting fibers  
ISOLIST: ISOPICK 0 (TAXI)  
MUON: PREMATCH 1,2,3,4 (HOTLINK)  
 
details of the tests we do are given below  
 
 
04/02/25 fiber splitter test  
 
run 179362  
COT HV down, SVX HV down, time for pulser guys to have some fun  
 
L1A 2400 Hz  
L2A   40 Hz  
L3A   20 Hz  
 
 
start: 22:15  
- first 10 minutes establish some base line  
  no error ISOLIST   
  no error Pulsar Muon  
 
action 22:25 HALT  
- pull ISOPICK 0 and reconnect, while HALTED  
  RECOVER, RUN  
  no error ISOLIST  
  no error Pulsar Muon  
 
action 22:50 HALT  
- put ISOPICK 0 on metall barrel to 62.5 fiber  
  splitt all 4 MUON PM: 1,2-&gt;beige BOX  
                        3,4-&gt;white BOX  
      no error         ISOLIST  
      no error         Pulsar Muon  
 
23:05  
end run to giv COT and MUON crates to BB.  
 
 
start a new run  
 
take new base line  
 
action 23:17    HALT  
- put ISOPICK 0 through white splitter box  
                       &gt;&gt; enable slot 16 in L2_PULSAR (not in partition)  
 
    no error         Pulsar Muon  
    ISLOLIST error  (860 evt: 0/860 6/240 0/240 0/240)  
 
 
 
run ended to turn COT again, starting 1.5 h testrun for Bill Badgett  
 
start a new run for Bill  
splitter status:  
  MUON PM: 1,2-&gt;beige BOX,   3,4-&gt;white BOX  
  ISOPICK 0 use purple splitter 50 mu  
 
was good for 750 mon events trying to get more statistics  
 
 
1am  
run 179365  
now we get some more stats for the purple splitter  
 
now at ~1500 events looking good 
 
 - Vadim/Burkard  
</pre>
<!-- Author: recovered by Ted -->


<!-- Date: Tue Mar 9 17:52:07 2004 -->
<pre>Mon Mar 1 10:49:59 
 
Last Thursday I changed the setup in crate tstl2trg2:  
 
Slot BoardType  Board#       clocks  mezzanine cards/aux   
  4   SLINK Rx    0108        50/40  LDC: 2 ODIN, 2 HOLA(UC)  
  7   SLINK Tx    0103        50/40  AUX 5V ODIN LSC  
  9   SLINK Tx    0112        64/40  AUX 5V ODIN LSC  
 11   SLINK Tx    0110        64/40  AUX 3.3V HOLA(UC) LSC   
 13   SLINK Tx    0003        50/40  AUX 3.3V HOLA(UC) LSC  
 17   MUON  Tx    0106(w/oP3) 80/40  Hotlink Tx (12,13,14,15)  
 19   MUON  Rx    0104        80/20  Hotlink Rx ( 7, 8,15,16)   
   
 
 - Burkard</pre>
<!-- Author: recovered by Ted -->
<!-- Comment: Tue Mar  9 17;52;36 comment by...recovered by Ted -->
<pre>- Mon Mar 1 17:08:49 comment by...Frans/Sakari/Burkard --  

We replaced the pair of ODIN(CERN) LSC/LDC some with the new HOLAs (CERN) LSC/LDC. Cards work
fine. Tried HOLA(UC) -&gt; HOLA(CERN) but that did not work, investigating.

For now rule is that LSCs only talk properly to LDC of same type:
ODIN       -&gt; ODIN
HOLA(UC)   -&gt; HOLA(UC)
HOLA(CERN) -&gt; HOLA (CERN)</pre>

<!-- Comment: Tue Mar  9 17;53;11 comment by...recovered by Ted -->
<pre>


-- Mon Mar 1 21:06:56 comment by...Ted --  

The CERN HOLAs have a different clock speed,
so they are not compatible with the current four UC HOLA
prototypes.This was simply due to the component availibility.
there is no design problem. I thought that I have told you
guys this, but looks like I didn't make it clear enough. 


-- Thu Mar 4 11:14:37 comment by...Frans & Burkard --  

We changed then clock setup of the SLINK Rx board (slot 4, 0108) to 80/40</pre>


<!-- Date: Tue Mar 9 17:54:12 2004 -->
<pre>Mon Mar 1 19:03:59 
 
CLIST error rate with (middle region) and without (left and right regions) LVDS splitter.  
 
 - Vadim  
 
(but the pic is missing. TL)</pre>
<!-- Author: recovered by Ted -->


<!-- Date: Tue Mar 9 17:55:30 2004 -->
<pre> 
 Wed Mar 3 10:40:25  
 
Fiber splitter work, here the brief summary:  
 
CLIST fibers are splitted now through the new box using purple splitters  
      this works, we did not see any CLIST errors sofar  
MUON  we completed the setup through the white splitter boxes  
      but we ran into trouble with that: we saw massive bit errors on    
      two fibers, we also believe that the other fibers were pretty   
      much on the edge.  
      We moved the MUON fibers back and now have them directly plugged  
      into the L2 MUON Pulsar again. System is up and running fine. 
 
 - Burkard </pre>
<!-- Author: recovered by Ted -->


<!-- Date: Tue Mar 9 17:56:44 2004 -->
<pre> Wed Mar 3 16:36:01  
 
Status of IsoList splitting:  
 
Installed IsoList fibers feeding into splitter box.  Fibers   
coming out of the splitter box were staged last night.    
 
Received permission from shift crew to plug in the fibers; saw  
immediately L2 Timeout - ModDone not detected from IsoList.    
After removing splitters from data path and reverting back to   
old fibers, errors disappeared.  
 
So, new hardware introduced (splitters, additional length and new  
fibers) caused problems.  The culprit is one of these.  Loss   
measurements were made on the splitter+new fiber combos:  
 
    Fiber Channel     Loss(dB)  
    -------------     --------  
        master          3.76  
        0               3.21  
        1               3.76  
        2               3.86  
        3               3.41  
        4               4.24  
        5               3.91  
 
So there are no open connections, although there are some lossy  
channels.    
 
We need to verify that data actually arrives at the receiver end  
of the fiber chain.  To do this we could use a pulsar board fed  
by the new fibers that are meant to feed the isolist board in   
the default system.  
 
 - neu (jdl and br)  
 
 </pre>
<!-- Author: recovered by Ted -->


<!-- Date: Tue Mar 9 17:58:17 2004 -->
<pre> 
   Thu Mar 4 13:50:57  
 
     Screen dump of Pulsar L2toTS to Trigger Supervisor protocal. 
 
 - Sakari and Cheng-Ju 
-- Thu Mar 4 14:11:24 comment by...Sakari and Cheng-Ju --   
 
Today we have successfully tested the L2toTS sparky firmware. 
In this setup, the Pulsar L2toTS board sits in the test-stand 
TS crate.  A FRED card (also in the TS crate) sends the L1A 
signal to the trigger supervisor based on the random PMT 
signal (sparky) from the trigger room.  A second random 
signal is sent to the Pulsar board via L1 trigger bits from 
FRED.  L2toTS board listens on the L1 trigger bit and  
decides whether to send a L2A or L2R to the trigger supervisor. 
 
In this firware, we have added an articifical ~350ns delay 
in sending the L2 decision to trigger supervisor (otherwise 
the decision is sent too fast and the TS stalls).  In the 
final system, this delay should be removed since the L2 
processing time would provide the natural delay needed. 
 
We have driven the system at L1A~40Khz and L2A~400 hz without 
any problem.  It is still going strong after 55M L2 accepts. 
 
</pre>
<!-- Author: recovered by Ted -->


<!-- Date: Tue Mar 9 17:58:54 2004 -->
<pre> 
   Thu Mar 4 15:04:07  
 
 - neu 
-- Thu Mar 4 15:22:57 comment by...neu --   
 
Many splitter tests were performed over the past couple days.  We 
were lucky enough to have a large part of CDF with real beam data  
but with no COT, no SVX.   
 
I tested a total of five XCES channels with the purple splitter: 
 
    - east 12  
    - east 20  
    - east 21 
    - east 22 
    - east 23 
 
These were chosen with insight from Masa as representative  
channels from two different default pre-exisitng error rates.   
MT claims east 23 is the worst case scenario in the default  
system. (Aside: should be something like ~0.1% error, but I am  
not sure what the denominator is in that number; checking with  
Masa.) 
 
In the plots, channel number is along the x-axis; "east"  
corresponds to bits 16-31 on the y-axis.   
 
For the pictured run, 179638, I had 4 splitters in the 
system: east channels 20,21,22,23.  As one can see the east 23 
has higher occupancy with the splitter in the data path(left  
plot, high and low thresholds).  The other 3 channels have no  
such occupancy increase.  Mismatch rates(right plot, again high  
and low thresholds) have some increased rate as well, but these  
plots suffer from low stats.   
 
These can be compared to a more recent run (179642, pictured  
below) in which the splitter on east 23 is removed and only 3  
splitters are in the system (east 20-22).   
 
So the splitter increases the total occupancy and mismatch rate  
in one of the five channels tested so far.  Channel east 12 was  
tested yesterday with no adverse effects introduced by the  
splitter.</pre>
<!-- Author: recovered by Ted -->


<!-- Date: Tue Mar 9 17:59:25 2004 -->
<pre> 
   Thu Mar 4 15:24:22  
 
 - neu 
-- Thu Mar 4 15:25:10 comment by...neu --   
 
Running without east 23 split.</pre>
<!-- Author: recovered by Ted -->


<!-- Date: Tue Mar 9 17:59:55 2004 -->
<pre>Thu Mar 4 16:57:06  
 
With the real system, it looks like the splitters behaved  
differently than in the teststand area. This makes one  
wonder how clean the fiber connections are with the real  
system. With Pulsars, we keep the fiber connections clean   
by always using the dust caps on all our optical components  
whenever they are not in use. It is certainly possible   
that some of the problems we encountered with real system   
could be due to "dirty" connections in the system.  
I believe that Dave Saltzberg was trying to get others to  
pay attention on fiber cleaning a year ago...  
 
In any case, I have just added a link on Pulsar web page   
to the Pocket Guide from Agilent on cleaning procedures,   
you can find it in the &lt;a 
href="http://hep.uchicago.edu/~thliu/projects/Pulsar/Pulsar_general.html"&gt; Pulsar General 
Information&lt;/a&gt; page (right below RECES information). 
 
 - Ted 
-- Thu Mar 4 17:00:16 comment by...Ted --  the link is here . </pre>
<!-- Author: recovered by Ted -->


<!-- Date: Tue Mar 9 18:00:42 2004 -->
<pre> Fri Mar 5 13:53:47  
 
light yields on the Muon fibers   
use  spare fiber (PM12) in the loop back  
 
#   F#   dB  
 0  MB01 0.42  
 1  MB02 0.37  
 2  MB03 0.78  
12  PM01 0.57  
 
 3  MB04 0.35  
 4  MB05 0.44  
 5  MB06 0.42  
13  PM02 0.94  
 
 6  MB07 1.37  
 7  MB08 2.16  
 8  MB09 2.01  
14  PM03 0.60  
 
 9  MB10 0.73  
10  MB11 0.45  
11  MB12 0.50  
15  PM04 0.59  
 
We do not see a correlation between these measurement and the fiber which missbehaved (1 MB02) 
 
 - Sakari/Burkard </pre>
<!-- Author: recovered by Ted -->


<!-- Date: Tue Mar 9 18:02:43 2004 -->
<pre> Fri Mar 5 21:39:56  
 
Tonight for the first time we got the fiber splitting for muon  
path working (still waiting for more statistics to test the   
robustness of the splitting). We have tried in a systematic  
way to understand the problems encountered in the past.  
To make the long story short, the problems encountered in   
the past was due to one bad fiber (from splitter to L2 muon  
Pulsar input in the L2 decision crate).   
 
 
More details below:  
 
(0) First we cleaned up all fiber connections for the muon  
path, done with the "Inert Dusting Gas" ENVI-RO-TECH 1671-10S  
from TECHSPRAY. This includes all optical connectors on  
the Pulsar side, the splitter boxes, and downstair muon  
matchboxs.  
(1) Then we identified that the short fiber0 for MB01  
(the top channel) from splitter box to the L2 muon Pulsar   
input is bad. we replaced with a "white color" fiber for   
now (Jonathan, please forgive us for this temp arrangement).   
(2) Fiber MB08 and MB09 from downstair were measured with higher  
light loss compared to others, see measurements above this entry.  
So we replaced them with two PM spare fibers. This also tells  
us that in the future when we lay fibers for splitting, we should  
also include some spares.  
(3) All fibers are splitted now with the "white box" SVX/SVT  
type splitters, except MB02 and MB03. For the later two, we  
HAD to use the purple splitters from Net Optics. The splitting  
was done for these two channels in such a way that the output  
of the purple splitters go directly into Pulsar inputs.  
The existing short fibers between the splitter box and Pulsar  
for these two channels are problematic, and we need to test them  
more carefully later or simply replace them (they are not  
used right now).  
(4) From (3), it became clear to us that we will need to   
use purple splitters from Net Optics for the muon paths.  
(5) All unused fiber connections are protected with dust caps.  
(6) we started a new run 179679 (cosmics) to get higher  
statistics, to test the robustness of this setup. if no  
problem found, we plan to leave the setup for the upcoming  
stores. If it is rock solid, then we have a solution to the  
muon fiber splitting and will then order more purple   
fiber splitters.   
(7) At the time of writing, ACE already stoped the run 179679  
and started shotsetup. The run ended at ~ 70K L3A. no error  
in TrigMon for muon. We will see how the splitting behave  
with actual beam data taking. 
 
 - Burkard and Ted 
-- Sat Mar 6 00:34:09 comment by...Burkard and Ted --   
 
Turns out that the splitting didn't work with beam, even though 
it works with cosmic and shot setup runs. See &lt;a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=195&frame=2&anchor=23:26:27.486'&gt; 
 
shift e-log entry here&lt;/a&gt;. Since the splitting 
works reliably in the teststand mode, we need to think harder 
on what is the real difference with the real system... it is 
now clear that we should at least go with the new  
purple splitters from Net OPtics for the muon path,  
but the question is: is that good enough and how do we 
prove it before we order more? 
 
 
 
-- Sat Mar 6 00:40:20 comment by...Burkard and Ted --   
 
forget to mention that we removed all splitters right after 
we found the errors, and now there is no more error, see 
&lt;a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=195&frame=2&anchor=00:05:32.453'&gt;shift e-log entry &lt;/a&gt;.  
 
and we will stay here to make sure  
the Pulsar muon system is back to the default happy running condition. 
 
 
   Sat Mar 6 00:43:54 here are the main shift e-log links mentioned above:  
TrigMon Pulsar plots errors with splitters, 
with beam and TrigMon Pulsar plots after removing the  
splitters  - Burkard and Ted </pre>
<!-- Author: recovered by Ted -->


<!-- Date: Tue Mar 9 18:03:57 2004 -->
<pre> Sat Mar 6 21:20:30  
 
To further understand the splitting problem for muon path, we  
did some power measurements at both (pre)matchbox outputs and  
L2 muon Pulsar inputs (without any splitter involved). During  
the process, we also tried to clean some of the channels   
with low powers at the matchbox outputs. As a   
reference, we also measured the Pulsar hotlink Tx outputs  
in the teststand room. All measurements were done with the  
system in idle mode. Here is a summary.  
 
 
Reference:  
(Pulsar Tx):  
 
channel 0: 15.82 dbm  
channel 1: 16.25 dbm  
channel 2: 16.13 dbm  
channel 3: 16.20 dbm  
channel 4: 15.93 dbm  
channel 5: 16.14 dbm  
 
note there is no clear dependence on the clock speed   
(33MHz vs 20Mhz on Pulsar hotlink mezzanine cards).  
 
Here are the measurements with the real system:  
(note the measurement can be reproduced only within ~ +- 0.3)  
 
 
Pulsar input:             downstair:  
 
channel 0:  16.54 dbm     16.10 dbm      
        1:  17.74         18.54 dbm  18.16 clean1, 17.85 clean2  
        2:  16.30         16.60        
        3:  16.73         16.50  
        4:  15.76         15.99  
        5:  17.19         17.15      17.12 clean1, 17.11 clean2        
        6:  16.55         16.82      16.85 clean1  
        7:  17.05         16.90   
        8:  16.43         16.52  
        9:  16.86         16.66  
       10:  17.17         16.96  
       11:  16.28         15.47  
       12:  16.06         16.02  
       13:  16.36         16.22  
       14:  16.40         16.16  
       15:  16.05         16.01  
 
note that the channels which had error last night were  
channel 1 and channel 5, and their power measurements  
seem indeed somewhat higher than the others, but not really  
by much at all. In fact, channel 1 had a purple splitter  
on last night, yet it failed in the beam. We do not   
understand this, given the fact that the purple splitter  
typically has a light loss of ~3.5-4.5 db, while the whitebox  
SVX/SVT type has a light loss of 6-7 db.  
 
what's missing here are the short fibers and splitter boxes  
to the Pulsar input. In fact, we found one short fiber  
(channel 0) was bad. Looks like we will need to measure each one of them insitu, along with all 
splitters in the chain.   
 
This way we will have all the relevant numbers, hopefully   
by then we will have a better understanding. In addition,   
we will need to test our Rx in the teststand room with   
additional splitter/couplers to add more attenuation to see   
how much less light the Rx can handle. in a reliable way...  
 
 
 
 
 
 - Burkard and Ted </pre>
<!-- Author: recovered by Ted -->


<!-- Date: Tue Mar 9 18:04:32 2004 -->
<pre> 
   Sat Mar 6 22:34:46  
 
ok, to make the power meter measurements complete, we have  
just finished the rest of measurements (see above entry on  
missing measurements): measure the splitters insitu with  
exactly the same short fibers we used during beam test.  
To do the measurement, we used one hotlink Tx channel from  
the Clist Tx in the Pulsar crate in the trigger room, and  
use one reference cable to bring that signal into each  
input of splitter, and measure the power at the very end  
of cable going into Pulsar during beam test last night.  
Here is the summary:  
 
 
reference: Clist channel 0 Tx: power at output at the end  
of the reference cable: 16.32 dbm. This much power will then go  
through --&gt; short reference cable --&gt; splitter input --&gt;  
splitter output --&gt; short cable --&gt; power meter.  
 
now measure the output at the end of short fiber coming from  
splitters:  
 
channel 0: 35.78 dbm (bad cable we replaced), 25.47 dbm (white temp cable)   
channel 1: 24.33 dbm (white box), 20.62 dbm with purple splitter  
channel 2: 24.76 (white box), and 20.59 dbm with purple splitter  
channel 3: 24.90  
channel 4: 24.51  
        5: 24.83  
        6: 25.13  
        7: 25.33  
        8: 25.56  
        9: 24.86  
       10: 24.95  
       11: 24.82  
       12: 24.63  
       13: 24.82  
       14: 25.25  
       15: 24.86  
 
Note that for channel 1, we used purple splitter last night  
for beam test. it has 20.62 dbm, much better than the others,  
yet it failed in the beam while all others (except 5) did not  
fail in the same running condition. could it be that for this  
channel 1 (and channel 5), our hotlink optical Rx is more  
sensitive to the light loss? we will need to do a test in   
the teststand room to find out if we have a "weak" channel   
on that mezzanine card.  
 
 
 - Burkard and Ted </pre>
<!-- Author: recovered by Ted -->


<!-- Date: Tue Mar 9 18:05:43 2004 -->
<pre> Sun Mar 7 05:15:16  
 
To really fully understand the splitting problem,   
we went further by studing how much light   
loss can our hotlink Rx handle (i.e. to find "the edge"):   
we setup a Pulsar muon Tx and Rx pair boards in the   
trigger room Pulsar crate, and with one channel splitted  
with multiple splitters (daisy chained), and started a   
Tx-&gt;Rx run. This setup will also allow us to study the   
problem without the need of beam first. Here is what   
we learned with this setup so far:  
 
(1) first make sure Tx --&gt; directly --&gt; Rx works;  
(2) then we tested on one channel (15):   
 
    Tx --&gt; purple splitter --&gt; another purpler splitter --&gt;  
    SVXX/SVT 50 um splitter --&gt; Rx.   
    The power meter reading at the Rx input is about  
    32 dbm with Tx sending out 16dbm.   
    This test failed right away.   
 
(3) then we took one purple splitter out:  
 
   Tx --&gt; purple splitter --&gt; SVX/SVT 50 um splitter --&gt; Rx.  
   The power meter reading at Rx input is now about 28 dbm.  
   This setup works... so far, 3M events without error.  
   Note that the SVX/SVT 50 um splitter is the box handmade  
   by Ted some time ago.  
 
 
However, it will take long time to get high statistics with  
this setup to set good limit. Because of that, we took full  
advantage of the BIST capability of hotlink and did the   
following at the same time:  
 
 
 
 (2) at Ted's office, there is a standalone "desktop setup"   
to understand the problem more carefully. This is to use   
one hotlink Tx mezzanine card and one hotlink Rx mezzanine   
card, and manually enable both in BIST (build in self test)  
 mode. then use a digital scope to watch the RVS (receiving  
violation signal) while attenuate the optical signal between   
the two with multiple splitters (daisy chained to get more  
attenuation). Here is a summary:  
 
(1) hotlink Tx --&gt; purple splitter --&gt; another purple splitter  
    --&gt; whitebox SVX/SVT splitter --&gt; another whitebox   
    SVX/SVT splitter --&gt; Rx  
 
the power meter reading at Tx output is 16.5 dbm, while at  
the Rx input is 35.05 dbm! Amazingly enough, this works in  
BIST mode with 20MHz clock on (good news to CLIST!!).   
then we changed to 32MHz (like muon case which use cdfclk*4),   
and it failed right away.  
 
 
(2) then one whitebox splitter was taken out. Now the power  
meter reading at the Rx input is about 31.65 dbm. This time,  
it still works with 20Mhz clock (run many hours without error).  
With 32 Mhz clock, it doesn't work.  
 
(3) then one purple splitter was removed, leaving only one  
purple splitter + one whitebox splitter. The power meter reading  
at Rx input is now 28.50 dbm. With this setup and with 32 Mhz  
clock, it first worked for a few mins then error   
occurs. we found that the error rate seem to depend   
on the temperture of the cards. when power off and let   
them cool down a bit, then turn on, it will take a while before  
error occur (note there is no air cooling in Ted's office).  
This is good to keep in mind. Since with BIST (error checking  
inside hardware on-the-fly, we can test the data transfer much  
more extensively than the Tx--&gt;Rx test in the Pulsar crate   
with DAQ readout, we think that the test in the Pulsar crate  
with similar attenuation will eventually fail even though  
it works up to 2M events so far...  
 
(4) then the whitebox splitter was removed, and now we put the  
other purple splitter box back. so there are two purple splitters  
in the chain. now the power meter reading at Rx input is now  
 23.90dbm. With this setup, now it works with both 20 MHz clock   
and 32 MHz! run up to an hour by now. We will leave this running  
on Sunday and see if we can catch any error on digital scope.  
We should be able to set a limit on single-bit-error with  
this attenuation... if it works, then we know we have at least  
~4db safty margin when we use only one splitter in the system.  
 
 
To summarize, based on what we have tested so far, it looks   
that our hotlink Rx can handle light loss even with two purple  
splitters (will know for sure in 1-2 days). this means the Rx  
design is not "on-the-edge" with fiber splitting. This is good  
news. However, this doesn't mean all Rx channel are as good  
since we only tested one. we will test others soon.  
 
To conclude, we have done an extensive study about fiber  
 splitting with hotlink case (still on going). we haven't   
found any somking gun yet as why the fiber splitting beam   
test failed on two channels two nights ago, but with our   
approach and what we will learn in the next few days, we   
should be able to find the cause of the problem.  
 
we had some fun. 
 
 - Burkard and Ted  
 
   Sun Mar 7 06:31:40  
 
Plans for understanding muon splitting problem:  
 
with what we have learned so far, we have eliminated   
in a systematic way many of the possible causes   
we can think of. There is one more thing we should check  
soon: check if on the Pulsar board in the L2 decision  
crate, the two channels (channel 1&5) which failed   
in the beam test with splitting really have a "weak"  
optical receiver. This can be tested easily in a Tx--&gt;Rx  
configuration, with 2 purple splitters daisy chained to  
get additional attenuation (+~4db). If these two Rx  
were indeed "on the edge" with one purple splitter,  
then they should fail right away with two purple splitters.  
of course, we will test all channels this way for that  
Pulsar board as well...  
 
we are now waiting for non-beam time to do this test ...  
meanwhile, we are doing similar tests with another Pulsar  
in the Pulsar crate. </pre>
<!-- Author: recovered by Ted -->


<!-- Date: Tue Mar 9 18:06:41 2004 -->
<pre> Sun Mar 7 07:57:00  
 
while waiting for non-beam time, we tested another Pulsar (the  
good old Pulsar muon board) with a muon Pulsar Tx in the Pulsar  
crate. we scaned through every channel, with one purple splitter  
+ one whitebox splitter daisy chained. After this two splitters,  
the power meter reading at Pulsar Rx input is about 28dbm, which  
is about 8db below the case with only one purple splitter!  
 
we first tested channel 15 with 9.5M events, no single error.  
then we scaned through all other channels with 100K events  
per channel. All works EXCEPT channel 0 !!! This could be the  
smoking gun! looks like we indeed found one Rx channel on a   
different Pulsar with an optical Rx which is much more sensitive  
to the light loss. we tried to clean this optical Rx twice with  
gas, that didn't help. By removing the whitebox splitter   
in the chain, it works with single purple splitter,   
but clearly it doesn't have the 8db safty margin as the others...  
 
So we have found one optical Rx channel which is much more  
sensitive to light loss than others on this Pulsar board. This  
clearly indicates that it is highly likely the two channels,  
on the official Pulsar in the L2 decision crate, which failed  
beam test with splitting also have similar problem... all we  
need to do next is to wait for non-beam time and do a test  
with that Pulsar. then we should be able to nail this problem.  
 
Let's hope this is the problem... as it is very easy to fix  
and we have a well defined way to find them.  
 
we are getting very close to the cause of the problem.  
 
 
 
 - Burkard and Ted </pre>
<!-- Author: recovered by Ted -->


<!-- Date: Tue Mar 9 18:14:42 2004 -->
<pre>Note that this is an actual entry now, following the 
previous studies by Burkard and Ted. 
 
We took the mezzanine card which we found the 
channel 0 Rx couldn't handle 28dbm input power 
(in the standalone Tx--&gt;Rx testing) to 
Ted's office to do the BIST mode testing. 
turns out this Rx channel is not so bad, it  
survived 24dbm input power and there is no 
error on the RVS line. According to the data sheet, 
the receiver minimal input power is about 26dBm, 
so it is not unusal to find one which cannot 
handle 28dbm input power...</pre>
<!-- Author: Ted -->


<!-- Date: Tue Mar 9 18:20:09 2004 -->
<pre>Burkard had a chance to take the Pulsar from L2D  
crate into the Pulsar crate and did the same  
test with additional attenuation. Turns out 
that the channel 1&5 which failed in the beam 
test can still pass Tx--&gt;Rx with one purple  
splitting + one whitebox type splitter (~10db)... 
this indicates that our receivers are fine. 
he also tested all other channels on this official 
running boards, all passed the test with extra 
attenuation as described above... 
 
so after we systematically checked/tested the full 
L2 muon chain, we haven't found the actual  
smoking gun yet (as to why the splitting failed 
in the beam test for muon path)... we need to think 
harder...</pre>
<!-- Author: Burkard and Ted -->