<!-- Title: 22:43:01  Thu Apr 22 2004 -->
<!-- Crewchief: SVT group -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>It is time to have new page</pre>


<!-- Date: Thu Apr 22 22:44:49 2004 -->
<pre> Roberto and I found that beam position of SVT didn't update. 
AGain b0svt06 has no spymon process. 
I just restarted it. (using "svtStart"). 
 
 This happened twice in this week, so please  
be careful for this.</pre>
<!-- Author: Taka and Roberto -->


<!-- Date: Sat May 1 11:59:48 2004 -->
<pre>New Road Warrior test with fakehits. RW seems to work now. 
 
Next tests will be with beam and silicon.</pre>
<!-- Author: Roberto, Taka -->


<!-- Date: Sat May 1 12:38:00 2004 -->
<pre> Roberto requested to put the instruction to use the "run  
controller". Then I will do it. 
 
-- how to start  
(1) in xterm, type "setup fer" 
(2) in xterm, type "rc" 
(3) Then you have pop-up "run controler". 
 
-- how to partition 
(4) In "run controler"'s top side, you have "partitioning", 
   so you select "partitioning-&gt;select patition". 
(5) Now, you have "Partition Selector" pop up window.  
(6) You may want to choose one of blue partition (free) 
   within 0-7 (hardware partition) 
 
-- how to select the run type 
(7) In the run controler top, you have "Parameters", so  
   you select "Parameters-&gt;Select Run Configuration" with mouse 
(8) Then, you have popup window of "Type Selector" 
   you choose "DaqTest-&gt;SVT"   
(9) You have bunch of selections for SVT test, but only need 
   to choose "SVT_500HZ" 
(10) Select the "SVT_500HZ" and then push the "Select" button. 
 
-- how to set the fakehits 
(11) "Parameters-&gt;Edit or View run setting"  
(12) You have popup wondow for run table setting. 
(13) middle of the table you have "parameter" and "value" colums, 
     you need to go to "SvtMode" raw of parameter. 
(14) Fill the "hw=fakehits map=fakehits" for the Value. 
(15) and push the keyboard return key. 
(16) "File-&gt;close" of run table setting 
 
-- how to start the fakehits mode 
(17) Push the button, "Partition" in the run control below the 
    "START" green elipse 
(18) Then push the "Config" button after "IDLE" elipse (state) 
    was turned green. During this config, we downloaded the  
    constants of memories. 
(19) Finally, push the "Activate" button after the "READY" state 
    is turned green. 
 
-- how to stop, rerun the run, and finish the run control 
(20) If you push "End" button of run control (left-middle), 
    you can stop the run. 
(21) After any "IDLE" state (elipse) turned green, you can  
    restart the run following items (18) and (19). 
(22) If you finish the test, you push the "Reset" (right-top) 
    after "IDLE" state, then choose "File-&gt;Exit".of run control. 
 
-- If you have "red" state of any elipse. 
(23) You have some troubles to use run control, but symptom 
    really depends on the case. Please ask Ace shifts to recover   
    it.  
 
</pre>
<!-- Author: Taka -->


<!-- Date: Sat May 1 23:51:26 2004 -->
<center><a href='/elog/notebooks/svt/Sat_May__1_2004_234943.ps'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-187' ></a><a href='/elog/notebooks/svt/Sat_May__1_2004_235009.ps'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-189' ></a></center>
<!-- Author: Taka -->
<!-- Comment: Sat May  1 23;54;20 comment by...Taka -->
<pre>Left: good news, we don't have any 2nd peak around 50us any 
more.

right: looks strange!! for TF OSPY.
data quality for wedge#3 is OK?</pre>

<!-- Comment: Mon May  3 11;15;42 comment by...Marco  -->
<pre>That plot is done assuming a 7 word track packet and counting 
the number of EP in every given event. Is this anyhow changed by 
the Road Warrior?</pre>

<!-- Comment: Mon May  3 23;35;48 comment by...Taka -->
<pre> As far as I know, RW was tested by wedge#11.
What's going on??</pre>


<!-- Date: Wed May 5 14:38:03 2004 -->
<pre>Road Warrior test has been done with beam and silicon. 
Run number is 182410. 
 
Redundant roads for wedge 11 have the wedge number changed to 15. 
Track Fitter worked in the old (standard) configuration. 
 
Svtmon version was not the standard one, it includes changes by 
Marco so that the spydumps contain the output from the Hit Buffer 
as well as the input for the Track Fitter. 
 
Samples from the special spydumps (Franco's format) are also 
available (/mnt/autofs/cdf/people1/carosi/rw/hb_new*.dat and 
tf_new*.dat).</pre>
<!-- Author: Roberto -->


<!-- Date: Wed May 5 14:55:22 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-191&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-191  width='300' align='top'></a></td><td>First look at wedge occupancy for run 182410. 
Wedge 11 does not look too bad.</td></tr></table>
<!-- Author: Roberto -->


<!-- Date: Wed May 5 15:10:12 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-192&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-192  width='300' align='top'></a></td><td>Wedge occupancy from TrigMon.</td></tr></table>
<!-- Author: Roberto -->


<!-- Date: Fri May 7 18:04:53 2004 -->
Updated TF at wedge 11 for Road Warrior. 
 
The TF #12 at wedge 11 is replaced with the TF #7 at B0-test stand which has the new firware v6.1 for road warrior. 
Roberto wanted to update the TF at wedge 11, but the existant TF at wedge 11 does not have EPC2 chip, which means I am not able to update the firmware by using bit-blaster now. So I updated the TF #7 at B0-test stand, and swapped with the TF #12.
<!-- Author: Un-ki -->


<!-- Date: Sat May 8 14:11:57 2004 -->
<pre>New Road warrior test, with beam and silicon. 
 
Run number = 182490 
Initial lum. = 17 e30 
 
Spymon version with dumps for HB output and TF input has been used. 
 
As usual, spydumps both in Franco and Marco formats are available. 
 
Track Fitter for wedge 11 is the one reconfigured by Un-ki. 
Wedge=15 tracks are rejected. 
 
AMS version of the code is the new one, i.e. with no reordering 
of the roads.</pre>
<!-- Author: Roberto -->


<!-- Date: Sat May 8 14:14:03 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-193&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-193  width='300' align='top'></a></td><td>SVT processing time from spymon, run 182490</td></tr></table>
<!-- Author: Roberto -->


<!-- Date: Sat May 8 14:14:39 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-194&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-194  width='300' align='top'></a></td><td>Sector occupancy from spymon, run 182490</td></tr></table>
<!-- Author: Roberto -->


<!-- Date: Mon May 10 09:38:41 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-195&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-195  width='300' align='top'></a></td><td>Average number of the tracks in the TF-OSPY with/out ghost removal. 
You can see that ghost tracks are removed by the TF. 
It will be good to see how much timing is reduced.</td></tr></table>
<!-- Author: Un-ki -->


<!-- Date: Tue May 11 07:33:27 2004 -->
<pre>New svtvme code was committed to cvs - to enable the new TF 
features, create an .hswet file with tf_TF_LONG_CS_CUT and tf_TF_RW_CUT on/set to 1. 
</pre>
<!-- Author: Jahred -->


<!-- Date: Wed May 19 22:28:17 2004 -->
<pre> HFs at slot#13, 14 and 15 for L00 and MRG at slot#11 in b0svt07 
were electrically disconnected from VME crate. This is to clean 
up these boards for coming RW installation. 
 
 Coldstart lines in hwset for these L00 boards were just disabled 
 (i.e. "hf_l00_w4_coldStartDisable 1",  
       "hf_l00_w5_coldStartDisable 1", and 
       "hf_xtrpfake_coldStartDisable 1")  
 in order to avoid failing coldstart of b0svt07. 
 
 Only disabling might be dangerous for coming RW installation, 
so that we should consider this.  
  </pre>
<!-- Author: Taka Maruyama -->
<!-- Comment: Wed May 19 22;59;42 comment by...Taka Maruyama -->
<pre> This idea can't pass the coldstart in the cosmic ray run.
More deep consideration is needed. (e.g. svtvme code modification)
(error message: hf(slot13,hf_xtrpfake) unexpected borad type id) 

 So, HFs of L00 were put to b0svt07, again.
MRG looks OK even after disconnection, so I leave it (disconnected)
</pre>

<!-- Comment: Thu May 20 09;27;50 comment by...Taka Maruyama -->
<pre> In cosmic ray run, we use nosvx.hwset. So, this problem was 
happened. I changed the lines in "nosvx.hwset", "stephen4.hwset"
to disable the coldstart of L00 as well.
 Also, we again disconnect the HFs of L00. (slot13, 14 and 15 in
b0svt07)</pre>


<!-- Comment: Thu May 20 17;40;16 comment by...Taka  -->
<pre> This kludge technique works and we can remove the 
HFs in b0svt07. But, as described below by Stefano, 
we need to change the database of DAQ for the perfection.
</pre>
<!-- Date: Thu May 20 09:36:54 2004 -->
<pre>Date: Thu, 20 May 2004 16:29:44 +0200 
From: Stefano Belforte  
To: Takasumi Maruyama  
Subject: Re: HF slots 
 
OK, I think you need to use CardEditor to remove those 
boards from hw database, or more specifically turn them offline. 
For a start you should be able to edit the crate configuration 
in run control menu, remove those boards, see if it works, it should. 
The The CardEditro will make that operation permanent. 
I can not run R_C nor CardEditor from here, those Java windows 
are incredibiliy heavy on the remote X11. 
In other words, run_control calls coldstart for those boards 
because they are in the config, take them out of config and 
it should all be ok. No need to change code. 
This will not be true for the HF that sends fake hit, because 
of a trick that Bill put in our coldstart, that board is 
always talked to, even if it does not exist in run_control DB, 
so you can not remove it w/o changing svtvme_fer.c 
 
CardEditor is sort of self-explanatory, but you will 
need a db paswrod to change things eventually, Bill Badgett 
can help you with using it and give you pwd or do the 
changes for you, but test with r_c first. 
 
stefano 
 
Takasumi Maruyama wrote: 
&gt;   Hi, 
&gt; 
&gt;   I guess all of L00 HFs are being configured at the coldstart now. 
&gt;  If we removed the HFs at slot13, 14 and 15 physically, 
&gt;  run control complained 
&gt;  that "we don't have HFs at slots 13, 14 and 15". 
&gt; 
&gt;  Maybe DAQ code itself set these guys specifically to put the coldstart. 
&gt;  In that sense, if RW is coming, Bill Badgett will replace the code 
&gt;  from svtvme_hf_coldstart to svtvme_rw_coldstart for b0svt07 of slot13,14 and 15. 
 
</pre>
<!-- Author: Taka Maruyama -->



<!-- Date: Fri May 21 02:34:53 2004 -->
<pre> HFs at slot13, 14 and 15 at b0svt07 (for L00) 
were removed from hardware database with 
Stefano's and Bill Badgett's suggestion. I removed these cards 
physically, too. Removed cards (slot13: HF serial #16,  
slot14: #48, slot15: #43 and slot11: MRG serial #25) are all 
put to the 3rd floor's SVT collection place. 
 </pre>
<!-- Author: Taka Maruyama -->


<!-- Date: Fri May 21 15:03:39 2004 -->
<pre>All Track Fitters in B0 control room are updated for Road Warrior and long clusters (version 6.2 firmware). 
Unless we turn on switches for these functions, there should be no change.</pre>
<!-- Author: Un-ki -->


<!-- Date: Fri May 21 15:11:01 2004 -->
<pre>TF #15 at wedge 0 is swapped with TF #1 at wedge 1 
in order to check whether the the TF at wedge 0 has the source 
of the problem Alex saw in the comparison of the SVT data vs simulation.</pre>
<!-- Author: Un-ki -->


<!-- Date: Tue May 25 06:32:13 2004 -->
<pre>Got paged at about 4:30. 
 
The plan: 
 
1. Switch to JDL's test table (TEST_SILICON_TIMING_v1) and check that 
   it works 
 
2. Test the wedge by wedge timing measurements using the GB timing 
   information, taking a run where we pause and switch from one 
   SVT wedge to the other. This will be checked offline to make sure 
   that all the wedges were read out. 
 
3. Make sure that we know how to switch to single buffer mode 
 
4. Perform scope measurements of L1A - SVT-VTM - EoE timing 
   Leave the modified VTM in? 
 
Since there are no TeV studies but just a PS replacement, we will go with 
1. and 2. (with 3.) and leave 4. to the end (that will require paging 
main silicon, we don't want to trouble. 
 
We couldn't find TEST_SILICON_TIMING_v1, so we decided to switch to 3. and 
then 2. 
 
~ashmansk/bin/vme b0tsi00 write 3 0x2040 0xe0 
 
we don't seem to be able to even ping b0tsi00... moving on to switching SVT 
wedges 
 
Wedge test run is 183120. The log of the enablewedge.csh script is 
in ~cdf_svt/timing/timing_run_183120.txt 
 
We discussed with Marcel the possibility of putting the VTM board in 
but it turns out the connectors are still not in and it would require 
to take out one of the crate back covers. Since we know that the 
whole thing works, I'd rather wait for the VTM with front panel connectors 
to be ready before performing a permanent swap. 
So we didn't test the VTM on the SVT crate, since we know that all that 
is needed is to put the board in with the right probes, and the probes 
are not firm enough to have me confidently leave them hanging in the crate. 
</pre>
<!-- Author: Alex and Ivan -->


<!-- Date: Wed May 26 16:39:13 2004 -->
<pre>Ok, so we tried to take again the SVT test run. 
Run number is 183181. 
 
We are using the decoupled trigger table from 
Jonathan, TEST_SVT_TIMING [1,480,441] 
 
SVTMode hw=fakehits map=fakehits 
 
The procedure to run in single L2 buffer mode, as 
followed today: 
 
setup fer 
daq b0tsi00 
 
wait for the graphic window to show up 
DAQ -&gt; Open connection 
VME -&gt; Read/Write 
Crate: 0 Address: 18002040 Data: e0 
Hit Write 
Hit Read (to verify write operation) 
 
This enables L2 buffer 0 alone. You can check that this 
is the case by resuming data daking and checking that  
buffer 0 is taking 100% of the events. 
 
This is the sequence in which things happened: 
 
All wedge mode 
Pause 
Switch to wedge 0 
Switch to single buffer operation 
Switch to wedge 1  (my mistake) 
Halt - Switch to wedge 2  - Recover/Run 
Halt - Switch to wedge 3  - Recover/Run 
Halt - Switch to wedge 4  - Recover/Run 
Halt - Switch to wedge 5  - Recover/Run 
Halt - Switch to wedge 6  - Recover/Run 
Halt - Switch to wedge 7  - Recover/Run 
Halt - Switch to wedge 8  - Recover/Run 
Halt - Switch to wedge 9  - Recover/Run 
Halt - Switch to wedge 10 - Recover/Run 
Halt - Switch to wedge 11 - Recover/Run 
Halt - Switch to wedge 0  - Recover/Run 
Halt - Switch to wedge 1  - Recover/Run 
 
End Run 
 
We visually check that each wedge in turn 
is running: the DS led turn green only 
for the wedge that is running, since all 
the others are in hold because of the corresponding 
downstream merger input not being enabled. 
 
Unfortunately we realized this starting from 
wedge 2, therefore we didn't catch the fact 
that we accidentally skipped wedge 0 initially. 
To correct this we repeated wedges 0 and 1 at 
the end. 
 
We are happy, we see tracks, wedges are switched 
with the right sequence. We will cross check that 
this is working completely having a look at the 
data in the look area.</pre>
<!-- Author: Alex and Pierluigi -->


<!-- Date: Wed May 26 16:41:08 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-196&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-196  width='300' align='top'></a></td><td>Trigmon plot at the end of test run 183181</td></tr></table>
<!-- Author: Alex and Pierluigi -->


<!-- Date: Fri May 28 12:10:26 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-197&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-197' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-198&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-198' width='300'></a></center>
<!-- Author: jdl -->
<!-- Comment: Fri May 28 12;20;09 comment by...jdl -->
Marcel and I verified that the timing of silicon readout and SVT on a scope at the SVT crates.  In the left plot, the yellow trace is L1A, green is "G-link valid" from the hacked VTM in svt05 slot 4, and blue is end-of-event from the merger that feeds the ghostbuster.  We see that data appears at the VTM 9us after L1A.  That time can be as large as 10us becuase of pre-amp resets in the chips (Steve Nahn).  The latency of the SVT with essentially an empty detector is thus about 8us.  The data were taken with the cosmic trigger table, no beam and no HV on COT.  It would be good to measure latency across each part of the system.
<p>  
The plot on the right shows the VTM signal again in green.  The blue is EoE from the hit finder that is fed by that VTM.  I don't understand the structure.  However, I think it does show 1.6us a 1.6us latency for the HF.  My understanding is that the width of the VTM G-link Valid signal is governed by the FIB headers. 


<!-- Date: Sun May 30 19:24:53 2004 -->
<pre> 
29 Pulsar boards programmed as RW have been tested on tstsvt1. 
 
13 boards with the P3 connector and 16 without the P3. 
 
Following there is the list of tested borads with P3 connector, in the order: Pulsar group board label, SVT/RW board label, result. 
 
0001  65  ok 
2122  66  ok 
2121  67  BAD  (hold lines problems, to investigate) 
2120  68  ok 
2134  69  ok 
2128  71  ok 
2133  72  ok 
2131  73  ok 
2136  74  ok 
2126  75  ok 
2135  76  ok 
2124  77  ok 
2132  78  ok 
 
 
Following the list of NO P3 connector tested boards, same as before: 
 
2173  70  ok 
2151  79  ok 
2149  80  ok 
2141  81  ok 
2156  82  ok 
2150  83  ok 
2155  84  ok 
2153  85  ok 
2154  86  BAD (hold lines problems, to investigate) 
2144  87  ok 
2146  88  ok 
2145  89  ok 
2138  90  ok 
2152  91  ok 
2142  92  ok 
2139  93  ok 
 
Since friday, 12 NO P3 boards, programmed as RW, are in the SVT crates. They are unplugged by the system and they have the following position (SVT/RW label, crate, slot): 
 
79  b0svt08 5 
80  b0svt08 7 
81  b0svt08 9 
82  b0svt08 11 
83  b0svt08 13 
84  b0svt08 15 
85  b0svt08 17 
70  b0svt08 19 
87  b0svt07 5  
88  b0svt07 7 
89  b0svt07 9 
90  b0svt07 11 
 
Other 3 spare NO P3 programmed boards (91 92 93) are in the cart near tstsvt1. </pre>
<!-- Author: Pierluigi -->


<!-- Date: Tue Jun 1 22:43:17 2004 -->
<pre>SVT timing run for a single wedge at low luminosity. 
 
Cross check without silicon being integrated to make 
sure that L1 rates made sense was in run 183555. 
 
Run 183556 is the one that actually contains the useful 
data. Begun with all wedges enabled, 4 L2 buffers mode 
and TEST_SVT_TIMING[1,480,441] 
 
Deadtime is unbearable (90 something %).  
We switch to single buffer mode without much  
change in deadtime. 
 
We try changing the L1 prescales, but while playing with those 
Jonathan calls in and suggests to change instead the L2 
rate limits. 
No wonder that is the best solution. The diagnosis is that 
L3 logging rate is abnormally high due to the data banks 
(including Si) not being compressed. This will be fixed 
in a future version of the table: right now there is no 
L3 piece of the table that allows data compression. 
 
We then switch to Wedge 2 only with 
 
./enablewedge.csh 3 
 
Taking data since approx 10:30 with this configuration, 
at a rate which is half what we could if it wasn't for 
the L3 issue. Fairly happy with this: it will be a bigger 
issue for the high luminosity test run! 
 
</pre>
<!-- Author: Alex Marcel & the shift crew -->
<!-- Comment: Tue Jun  1 23;34;40 comment by...Alex -->
<pre>According to the run summary for Run 183556, events from Ev#78250
to Ev#181797 are single wedge (wedge 2) single buffer
mode. From Ev#181797 on we had RW board #87 inserted between
the HB and the TF in wedge 2.
That adds up to roughly 100K events for the standard wedge
configuration and about 50K events with the RW in.</pre>


<!-- Date: Sat Jun 5 17:36:35 2004 -->
<pre>SVT Road Warrior tests with fakehits: 
 
- svtvme development version, does not work. I had to use 
"current" version. 
 
- all tests with pulsars in pass mode were successful except 
for wedge 4 (pulsar in crate 8, slot 5). I tried to swap  
the pulsar with a spare (now # 91 in in crate 8, #79 is in the 
test stand) but the problem is still there. Maybe a cabling 
problem? 
 
- test with pulsars in Road Warrior look fine, but the results 
must be analyzed. Wedge 6 and 8 looked strange, the other ones 
probably are ok. 
 
</pre>
<!-- Author: Roberto -->
<!-- Comment: Sun Jun  6 16;12;02 comment by...Roberto -->
<pre>Alex found that the problem with svtvme is due to a missing
link in the update of the Linux kernel. Bill Badgett has been
notified and the problem should be fixed. Of course, svtvme
must be rebuild.</pre>


<!-- Date: Mon Jun 7 14:40:52 2004 -->
<pre>New Road Warrior test with fakehits. 
 
- svtvme problem is fixed, everything (scripts, ...) is 
working now; 
 
- pulsar boards have been tested in both pass and road warrior 
mode; 
 
- in pass mode all boards are ok except for wedge 4; 
 
- in rw mode, boards are probably ok (more analysis of the spy 
dumps is needed, but there are no strange behaviors); 
again, wedge 4 is not ok; 
 
- pulsar for wedge 4 (crate 8, slot 5) swapped again; now 
#92 is in the crate and #91 in the test stand; 
 
- one more test for wedge 4 with the new board shows that the 
problem is still there; cabling looks ok. 
</pre>
<!-- Author: Roberto -->
<!-- Comment: Tue Jun  8 12;24;36 comment by...Ted -->
<pre>Roberto:

 from what you wrote in the e-log, it seems that three Pulsar
RWs all failed in the crate 8, slot 5. this is a bit strange. before swapping in another spare, let's take a look at this together.</pre>

<!-- Comment: Tue Jun  8 12;49;02 comment by...Ted -->
<pre>I just took a look at the Pulsar#92 in crate 8, slot 5.
It looks like this board is not fully plugged in... 
of course, this may not be the cause for the problem.</pre>

<!-- Comment: Tue Jun  8 13;47;10 comment by...Ted and Roberto -->
<pre>after I showed this to Roberto, I fully plugged this board
in., around 1:40pm today. Roberto will do some standalone
testing for the other two in the teststand room.</pre>


<!-- Date: Tue Jun 8 14:07:03 2004 -->
<pre>The pulsar board in crate 7 slot 12 (wedge 1) has a blinking 
hold signal when the output cable is plugged in (and unplugged 
from the TF). This seems to happen only with long cables (&gt;3 ft). 
It does not happen with short cables. This is board #88. 
 
I have swapped the board with #93, so Ted can investigate the problem. 
The spare boards are now: 88, 79, 91. 
79 and 91 have been already in crate 8 and showed problems (even 
in passthrough mode). 
 
I have tested again board #91 in the test stand. It looks ok, 
either in passthrough mode and road warrior mode.</pre>
<!-- Author: Roberto -->
<!-- Comment: Tue Jun  8 14;34;40 comment by...Roberto -->
<pre>Board #79 looks ok too, after tests in the test stand.</pre>

<!-- Comment: Tue Jun  8 17;47;36 comment by...Ted -->
<pre>I looked into the hold problem on board#88. by probing the hold
line directly on the LVDS/TTL chip, and plug/unplug the input
cable, from time to time the hold will oscilates (with peak to peak value around 17 ns or so). and this is what is causing the LED flashing seen before. don;t know what caused this problem yet, will look into this a bit more later.

</pre>


<!-- Comment: Tue Jun 15 13;58;55 comment by...Ted -->
<pre>ok, here is what I learned so far on this issue. There are
two other Pulsars which failed production testing due to the
SVT hold line. and we replaced the LVDS/TTL chip on them,
and today they came back from High Rise and I checked the
hold line and now it works on both of them. We will replace
the LVDS/TTL chip on this board (#88) soon. Note on this
board, the hold line actually works when the cable is 
fully plugged in, but when the cable is unplugged from 
upstream, the hold signal seems to oscilates from time to time... 
that is probably why it passed the original tests. </pre>
<!-- Date: Tue Jun 8 18:47:20 2004 -->
<pre>Low luminosity test run for timing studies. 
Run 183805 
 
We want to take wedges 4 (lowest occupancy) and 10 (highest occupancy). 
Switched to single buffer and wedge 4 alone right before 
Activate 
Taking data happily with ~6% deadtime. 
18:06, trig 118038 switching to wedge 10 
At event 225766 added RW on wedge 10</pre>
<!-- Author: Alex -->


<!-- Date: Wed Jun 9 18:21:00 2004 -->
<pre>Pulsar board type ID (entered into database officially today).  
 
We have 20 different types so far. Note that Road Warrior ID 
is 083, while new Track Fitter ID is assigned 098. 
 
BOARDTYPE    DESCRIPTION  
------------ --------------------------------------------------  
081          L2 Pulsar Muon/XTRP Rx IIa  
083          L2 Pulsar SVT Road Warrior  
085          L2 Pulsar Muon/XTRP/L1 Tx or SVT XTRP-emu  
086          L2 Pulsar Muon/XTRP/L1 Rx IIb  
087          L2 Pulsar RECES Tx  
088          L2 Pulsar RECES Rx  
089          L2 Pulsar Cluster/PreFred Tx  
090          L2 Pulsar Cluster/PreFred Rx  
091          L2 Pulsar SVT Tx  
092          L2 Pulsar SVT Rx  
093          L2 Pulsar Merger Tx  
094          L2 Pulsar Merger Rx  
095          L2 Pulsar L2TS Tx  
096          L2 Pulsar L2TS  
097          L2 Pulsar L1 Scaler  
098          L2 Pulsar SVT TF  
099          L2 Pulsar test one  
100          L2 Pulsar test two  
101          L2 Pulsar Stereo Tx  
102          L2 Pulsar Stereo Rx  
 
</pre>
<!-- Author: Ted -->


<!-- Date: Fri Jun 11 00:11:43 2004 -->
<pre>More Road Warrior tests today, with fakehits and with beam. 
Some conclusions: 
 
- there was a typo in the hwset, the last three days we have 
been taking data with the Long Cluster cut un the Track Fitters 
 
- wedge 4 had a cable with problems; we have already the spare 
cable 
 
- even with a new cable, wedge 4 has problems. There are some improvements, the pulsar sends exactly the same number of words 
it receives, but in pass mode many of them are different 
 
- I have tried to move the pulsar to crate 6, slot 11, but I had 
the same problems 
 
- I was able to test the new AMS code, it looks fine with fakehits 
 
- this evening fakehits did not work, there were only EE words 
 
- test with beam was not better. There were a lot of L2 Decision 
Timeouts when all the wedges were in road warrior mode. 
There was this problem when wedge 4 was in rw mode. Occasionally 
wedges 6 and 8 gave the same problem 
 
- pulsar were in pass mode even if RW_ENABLE is set to 1 in the 
hwset 
 
Conclusion: we still have to understand wedge 4, hwset file, 
and fix the fakehits</pre>
<!-- Author: Roberto -->


<!-- Date: Fri Jun 11 15:44:47 2004 -->
<pre>There a new set of fakehits, more recent, and with 4 out  
of 5. Just put "hwset=fakehits2 map=fakehits" in the parameters 
field of SvtMode.</pre>
<!-- Author: Roberto -->


<!-- Date: Sat Jun 12 16:15:14 2004 -->
<pre>VTM card for wedge 10, barrels 2-3 replaced with the 
special card. 
 
Correct hwset loaded (typo corrected, default RW=0) 
 
Fakehits worked after rebooting all the svt crates, 
but spydumps are not written since June 10. 
The parameters for svtmon in svtb.table should be checked. 
 
AMS code version 4.0 seems to work. 
 
Wedge 4 with RW has still problems (even in passthru mode). 
In an attempt to understand the problem I have swapped the 
AMS board. Now #10 is in the crate, #11 in the cabinet, 3rd 
floor.</pre>
<!-- Author: Roberto -->
<!-- Comment: Tue Jun 15 11;09;34 comment by...Ted -->
<pre>Jonathan and i just connected a long lemo cable (~ 73 feet)
from the special VTM card (wedge 10, mentioned above)
to the back of Pulsar crate. From now on, this VTM
signal timing will be available to Pulsar SVT Rx in the
Pulsar crate. We will take some data in the near future
and try to make sense of the data.</pre>
<!-- Date: Mon Jun 14 14:43:22 2004 -->
<pre>Moved the spymon cron job from b0dap85 (which no longer exists!) to b0dap86. I see no reason why it shouldn't run OK, but I will double-check in the next day or so and make sure files are being moved correctly.</pre>
<!-- Author: Jahred -->
<!-- Comment: Mon Jun 14 16;48;26 comment by...Jahred -->
<pre>BTW, ssh and slogin to b0dap86 don't work. Use rlogin/rsh.</pre>




<!-- Comment: Thu Jun 17 12;01;55 comment by...Jahred -->
<pre>OK, it's now moved to b0dap30, hopefully for good ....</pre>
<!-- Date: Wed Jun 16 10:04:31 2004 -->
<pre>SVT timing test at Lum=3.1*10^31 
 
All data taken in single L2 buffer mode. 
Run number 184065: begin with all wedges in, to event 53645. 
Then switched to single wedge mode. Wedge enabled is  11 
(./enablewedge.csh 12). 
About 30000 events later we had abnormal termination due to 
L3 problems. 
 
Started new run 184066 in single wedge mode (w 11), 53000 events taken. 
 
Tipical dead time was 6%.</pre>
<!-- Author: Alex, Roberto -->


<!-- Date: Wed Jun 16 18:41:23 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-199&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-200' ></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-201&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-202' ></a></center>
<!-- Author: neu -->
<!-- Comment: Wed Jun 16 18;46;23 comment by...neu -->
<pre>Beam width fitter results from this afternoon's running.  Left 
is x width as a function of SVX half-barrel, right is y width.  

Fitter uses SVT track pairs to determine the x and y width and 
their errors.  By restricting tracks to pass through the same 
half-barrel we get a crude z measurement.  

Fit stability has been a major problem in the last couple weeks, 
among other more pedestrian problems.  Recently changes were 
made, tightening the track and pair selection, and these changes 
made the fits considerably more stable.  There are 2 exzcursions 
in the above plots, but these come from cleaning-house in the 
the fit statistics accumulators, basically wiping the slate 
clean and starting over.  

I'll post some more plots with errors.</pre>


<!-- Date: Wed Jun 16 23:06:26 2004 -->
<pre>SVT timing tests: 
 
L2_Pulsar in, Single L2 buffer 
 
Run 184075: all wedges 
dead time 6%, L1 rate 4kHz 
end run after 11000 events because of problems with b0tsi03 
(busy timeouts) 
 
Run 184076: all wedges 
same problem as before, end run, no events taken 
 
Run 184077 all wedges 
same problem, end run after 44000 events 
 
After talking to several experts (first L3, then DAQ, then Silicon), we tried to go back to the standard trigger table. 
That seemed to work. 
 
Before going back to the timing test, we tried the Road Warrior 
test for 15 minutes. All wedges in Road Warrior mode, except 
for W03 and W04. Run number is 184079. Histograms look ok, 
except for timing (see plots). 
 
Then with run 184080 we go back to the timing test. Single wedge 
mode (W11), L2_pulsar in, TEST_SVT_TIMING trigger table. 
55000 events taken without problems. All files to the look area. 
Dead time 6%, L1 rate 4 kHz. 
 </pre>
<!-- Author: Roberto -->
<!-- Comment: Wed Jun 16 23;27;52 comment by...Roberto -->
<pre>All the test runs files are copied to 
fcdfsgi2:/cdf/data56/s0/carosi/timing</pre>
<!-- Date: Wed Jun 16 23:08:37 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-204&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-204  width='300' align='top'></a></td><td>Timing in standard mode, run 184078</td></tr></table>
<!-- Author: Roberto -->


<!-- Date: Wed Jun 16 23:09:19 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-205&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-205  width='300' align='top'></a></td><td>Timing in Road Warrior mode, run 184079</td></tr></table>
<!-- Author: Roberto -->




<!-- Date: Fri Jun 18 13:09:24 2004 -->
<pre>SVT timing tests: 
 
runs 184195,184196,184197,184198: 12 wedges mode 
 
184198 (from ev 33139), 184199: single wedge (11) 
</pre>
<!-- Author: Roberto -->


<!-- Date: Sun Jun 20 10:04:21 2004 -->
<pre>Another short Road Warrior test. 
AMS Version 4.0 is used. 
 
Run 184235: all wedges in RW mode, except wedge 3 (passthru mode) 
Apparently the switches in the hwset file do not work very well. 
The following switches are used: 
rw_RW_ENABLE                            0 
.... 
rw_w00_RW_ENABLE                        1 
... 
rw_w03_RW_ENABLE                        0 
... 
but the pulsars seem to be all in passthru mode (address 0x18  
reads 0x2). 
Timing distribution shows again the double peak. 
 
Run 184236: switch rw_RW_ENABLE 1 is used now. 
Pulsars seem to be in RW mode (address 0x18 reads 0x3) 
Timing distributions still have the double peak. 
 
Question: could the AMS code Version 4.0 be the cause of the 
double peak?  
 
The good news is that wedges 3 and 4 seem to be fixed. 
Pulsar for w04 (crate 8, slot 5) has totally new cables. 
Pulsar for w03 in now in crate 6, slot 11 with new cables.  
The other one (crate 7, slot 16) is disconnected.</pre>
<!-- Author: Roberto -->


<!-- Date: Sun Jun 20 16:53:41 2004 -->
<pre>More Road Warrior tests today: 
 
AMS code version: 3.0 (no road reordering) 
 
Run 184238, 184239: all wedges in RW mode. 
Everything seems to work now. No double peak in timing distributions. 
Average processing time: 23.7 us 
Normal processing time at this luminosity is 26.9 us, 
so we save about 3 us. 
 
The only problems: 
- we should check the AMS code V 4; is it the cuse of the double 
peak? 
- the RW_ENABLE switch in the hwset does not work. 
Run 184237 had RW_ENABLE set to 0, but the pulsars were 
in RW mode. 
I checked the switches for the Track Fitter (Road Warrior + 
Long Clusters): they seem to work correctly (at least, the 
TF register is consistent with the setting in hwset). 
</pre>
<!-- Author: Roberto -->
<!-- Comment: Tue Jun 28 19;20;01 comment by...Alberto -->
<pre>The information of when the RW was first enabled by default was lost, but it still exits in the CDF elog.
The road warrior (RW) was enabled by default on Jun 22, run 184311.</pre>