<!-- Title: 08:37:26  Sun Nov  5 2000 -->
<!-- Crewchief: Tara Shears -->
<!-- Op1: Anyes Taffard -->
<!-- Op2: Andy Foland -->
<!-- Op3: Jean Slaughter -->
<!-- Op4: Alan Sill -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Continue to take and analyze data 
Put conclusiong into the logbook wherever possible and available 
Be ready to do calibrations immediately upon end of commissioning 
run collisions 
 
Take any special runs that are put on the whiteboard if time allows 
 
</pre>


<!-- Date: Sun Nov 5 08:48:01 2000 -->
<pre>Runlist table updated with last night runs</pre>
<!-- Author: Anyes -->


<!-- Date: Sun Nov 5 10:36:40 2000 -->
<pre>Special runs taken with readall, dps off, otherwise same as before: 
 
103558 3.5K evts  (ace forgot to exclude b0svt00 which is having problems) 
103560 210K evts   (b0svt00 removed as presently usual...) 
 
 
Then returned to neighbor, dps on once these were complete. 
</pre>
<!-- Author: AFS -->
<!-- Comment: Sun Nov  5 11;25;17 comment by...Alan -->
("Same as before" means timing=61, BW=4, 132-ns mode, DPS on, thr=5.  Note SOC was IN for these runs...)

<!-- Comment: Sun Nov  5 11;25;44 comment by...Alan -->
(SOC BW=6, thr=3)


<!-- Date: Sun Nov 5 16:03:26 2000 -->
<pre>Examined the runs 103539 (x19473) and 103532(x1946c), 
which were taken in 396 and 132 ns mode, respectively. 
Concluded that tracks found in 132 ns mode are mainly 
junk.  Tracks in 532 clearly point to the beam, while 
those in 539 clearly do not.  Tracks in 532 have a 
healthier chi-squared distribution.  Tracks in 532 have 
a higher pt. Also suspicious is that 
the pulseheight in 539 is very low.   
 
	Suspicion has fallen upon the choice of pipeline 
depth 42 / (396/132) = 14.  We will try another set of runs at 
13 and 15 to see whether we simply missed the boat.</pre>
<!-- Author: Andy, Jean, Tara -->
<!-- Comment: Sun Nov  5 18;06;53 comment by...Petar -->
<pre>You mean tracks in 539 (396ns) do not point to the beam...?

Anyway, I was watching 103539 (396 ns run) on vdf as we were
taking data (running vdf with COT tracking as a consumer), and
indeed most events had far less charge than usual.

With my understanding of the timing and what the FIB and the
chip do, our best guess of the pipeline latency *is* 14.  But this depends on where within the 
396ns interval (between the collisions) the pipeline 
advances.  If it happens one clock after the collision then
the pipeline should be 15.</pre>
<!-- Date: Sun Nov 5 16:53:12 2000 -->
<pre>Special runs to study integrator NMOS sensitivity (= preamp 
input bias current, ISEL bits 1-3): 
 
Run #    # events  ISEL1-3 => preamp input bias current value 
 
103577    10960     000     35 uA  * 
103576    27326     100     70 
103575    27774     010    105 
103571    26242     110    140 
103573    29997     001    175 
103578    21535     101    210  = nominal usual value up to now 
103574    30444     011    245 
103572    25217     111    280 
 
Note that event rate was low due to event builder problems in  
runs 103575 - 103577 (crates b0eb19 and b0eb20), either coincidentally 
or for some cause-and-effect reason not determined.  Also the 
COT thresholds were at default (i.e. special COT script was not 
run) for all of the above runs except 103578. 
 
* Note for SOC only, ISEL1-3 was 100 for this run (103577) by 
mistake...</pre>
<!-- Author: AFS, Greg V. -->


<!-- Date: Sun Nov 5 17:38:37 2000 -->
<pre>run 103581 has evidence of completely empty  
events in the event display. 
Bad timing 41 ns  </pre>
<!-- Author: Saverio and Andy -->
<!-- Comment: Sun Nov  5 18;08;10 comment by...Alan -->
Timing not changed -- see below.
<!-- Date: Sun Nov 5 17:42:54 2000 -->
<pre>I have put the 102343 calibration files into the  
production database as a test.  DON"T use the production 
database yet!!! </pre>
<!-- Author: Jean -->


<!-- Date: Sun Nov 5 17:48:56 2000 -->
<pre>Repeat 396-ns mode runs.  (Note svxdaq was used to switch into 
396 mode before coldstart, then also to switch shifted BX from 
116 to 114 after coldstart.  java svxii.configure was used between 
runs to set pipeline latency.) 
 
Run    latency 
103580     14    repeat to check that it still doesn't work 
103581     42    just to be sure that this also doesn't work 
103582     15    best guess now -- turns out to be right!!! 
 
We see hits at latency 15!  This study was done at bandwidth 4, 
will now switch to bandwidth 7 for long run...  </pre>
<!-- Author: AFS, JS, Andy, Tania, Saverio (+ Mary and Petar by phone...) -->
<!-- Comment: Sun Nov  5 18;23;34 comment by...Petar -->
<pre>103580 (396 w/14) -- faint hits... Looks like one after collision
103581 (132 w/42) -- haven't looked yet
103582 (396 w/15) -- lots of charge; with COT tracks it seems
	that there are lots of hits close to tracks ==> looks OK.

My theory of what is happening: we spent a lot of time optimizing
which crossing we are reading out in 132 mode (so that we can 
set the pipeline latency to 41 or 42).  We also spent a lot of
time checking out where the falling edge of the FE clock is
in the 132ns mode running, so that it happens just before the
collision.  (NB: I'm not sure we actually found it, but it must
be pretty close.)

However, it just dawned on me that once we switch to the 396ns
integration mode, it's not so clear which FE clock edge (out
of three, or at least two that we tackled before) disappears.
I assumed that it will be the one after the collision.  But that
would yield the latency of 14.  Since the latency is obviously
15, the FE clock before the collision is the one that disappears,
and the one ~100 ns after the collision is the one that stays.
This would result in the latency of 15!

If true, this model would result in *exactly* the same charge
distributions as the 132ns running.  So 
(1) it can easily be tested, and 
(2) we can't learn anything about the charge collection in
    the 396ns mode, since we are integrating over exactly the
    same time as in the 132ns mode (which is given by the
    time between the collision and the next FE clock).
   
I hope I'm wrong... But in case I'm not, it's unfortunately 
to late to fix the SRC for this shot (requires changes to the
firmware and thus burning another prom...).

However, at least we are aware of the problem and we know
what to do about it.
</pre>
<!-- Comment: Sun Nov  5 18;42;47 comment by...Alan -->
If true, we can check this by changing from (3*19)+4 ns delay
to (0*19)+4 ns pretty easily by changing the shifted BX value...
<!-- Comment: Sun Nov  5 18;45;42 comment by...Alan -->
This would be 20 instead of 116, right?  (Then subtract 2 to yield
18 as the value to be put into the shifted BX number after coldstart.)
<!-- Comment: Sun Nov  5 18;48;29 comment by...Alan -->
Never mind, this would do the wrong thing.
<!-- Date: Sun Nov 5 17:58:35 2000 -->
<pre>SOC chip parameters changed for upcoming 396 running: 
  BW set to 7. 
  DPS off 
  Read All so I don't have to figure out peds. 
This should be the config for the remainder of the store.</pre>
<!-- Author: David Stuart -->
<!-- Comment: Sun Nov  5 18;09;08 comment by...AFS -->
Rest of B4 left in neightbor mode...


<!-- Date: Sun Nov 5 18:14:31 2000 -->
<table><tr><td><a href=/elog/notebooks/barrel4/Sun_Nov__5_2000_181428.ps align=top><img src=/elog/gifs/ghost64.gif  width='56' align='top'></td><td>Run 103582 event 49947 Two (or 3 ? ) tracks on-line in SVX 396 ns FECLOCK, BW = 4</a></td></tr></table>
<!-- Author: Saverio and Stefano -->


<!-- Date: Sun Nov 5 18:15:36 2000 -->
<pre>I was running svxmon_offline for the special runs used to study 
 integrator NMOS sensitivity : 
   
 Run #    # events  	 => preamp input bias current value  
 
 103575    2200 *       105   
 103573    5000         175         
 103574    5000         245  
 103572    8800         280  
 
 * For a greater number of events I was getting this type of 
 error : 
  StorableBank::get_I2_element(): out-of-bounds exception 
  offset = 0, index = -2078061358, data_size = 217 
 Also due to the same error I was unable to run 103576. 
 The  output files(.root, .hs or .rz) are in : 
    /cdf/data05/s1/hardware/svxii/SVXMon_offline 
	 
</pre>
<!-- Author: Mircea  -->
<!-- Comment: Sun Nov  5 19;14;11 comment by...Petar -->
<pre>The fix is to put this line into your input module (be it
DHInput or FileInput):

      dropList add ISLD_StorableBank

This started happening today in the middle of the first
396ns run with latency of 15 (run 103582 which I was 
monitoring at real time).  This might indicate a problem
with the SOC -- too hot perhaps?  The bank experts should
comment...</pre>


<!-- Date: Sun Nov 5 19:27:33 2000 -->
<table><tr><td><a href=/elog/notebooks/barrel4/Sun_Nov__5_2000_192728.ps align=top><img src=/elog/gifs/ghost64.gif  width='56' align='top'></td><td>Layer-by-layer noise comparison of runs 103572 (280 uA, red) and 103575 (105 uA, blue)</a></td></tr></table>
<!-- Author: Andy -->
<!-- Comment: Sun Nov  5 19;30;20 comment by...Andy -->
<pre>Noise results from variation of the ISEL bits (Integrator
NMOS current).  It is hard to see much of a difference
except possibly on L0 Wedge 3.  

The L1Wedge2, L3W3, and L4W3 plots seem to be broken in a 
bizarre way(exactly the same in these two, and other, files);
Igor has been notified.</pre>


<!-- Date: Sun Nov 5 21:01:43 2000 -->
<pre>We ran svxMon on Run# 103584 (396 ns, latency 15). We find 
that it misses the 1st bunch crossing no. completely.  
ps file is in  
/cdf/data05/s1/hardware/svxii/SVXMon_offline/svxmon_103584.ps 
</pre>
<!-- Author: Mircea,Tania,Andy -->


<!-- Date: Sun Nov 5 21:04:14 2000 -->
<table><tr><td><a href=/elog/notebooks/barrel4/Sun_Nov__5_2000_210353.ps align=top><img src=/elog/gifs/ghost64.gif  width='56' align='top'></td><td>See ps file for this.</a></td></tr></table>
<!-- Author: Tania -->


<!-- Date: Sun Nov 5 21:22:06 2000 -->
<pre>The problem with ISLD_StorableBank seen in SVXMON is 
apparently due to some problem in the clustering code 
that makes it choke on data in the ISLD bank. Since the 
SOC is now part of the standard running, all runs have an ISLD 
bank. You will need to drop them to avoid this error. 
 
The error is not due to a problem in the SOC. At first we 
suspected that the DOIMs may be too hot and giving bit errors, 
but that is not the case. Looking at the data with independent 
code, it all looks fine. 
 
Sorry for the inconvenience of having to drop the ISLD bank 
in your tcls.</pre>
<!-- Author: David Stuart -->
<!-- Comment: Sun Nov  5 22;06;57 comment by...Alan -->
We would rather keep it and fix these problems!!


<!-- Date: Sun Nov 5 23:47:43 2000 -->
<pre>Running SiHitAnalyzer on following runs for 5000 events: 
103581 (latency 42, BW4, 132ns) 
103580 (latency 14, BW4, 396ns) 
103582 (latency 15, BW4, 396ns) 
103584 (latency 15, BW7, 396ns) 
hbook and log files will be in: 
/cdf/data05/s1/hardware/svxii/SiHitAnalyzer 
hitdata_103580,103581,103582,103584.hbook 
hitdata_103580,103581,103582,103584.log 
 
See E-log above for more comments on these runs. 
</pre>
<!-- Author: Tania -->
<!-- Comment: Sun Nov  5 23;50;08 comment by...Tania -->
tcl file used :
/cdf/data05/s1/hardware/svxii/SiHitAnalyzer/b4tracks.tcl
Exe file used:
/cdf/home/herndon/software/b4data2/bin/IRIX6-KCC_3_3/siHitAnalyzer



<!-- Date: Mon Nov 6 00:02:41 2000 -->
<pre>Running SiTrackAnalyzer on following runs for 10000 events:  
103571, 103572, 103573, 103574, 103578 and 103582 . 
hbook and log files will be in:  
/cdf/data05/s1/hardware/svxii/SiHitAnalyzer/cmircea  
sihitan_ar{hexrunnumber}.0001phys.hbook and  
sihitan_ar{hexrunnumber}.0001phys.log. 
See E-log above for more comments on these runs. </pre>
<!-- Author: Mircea -->


<!-- Date: Mon Nov 6 00:26:44 2000 -->
<pre>SVXMon is running on partition 4. 
</pre>
<!-- Author: Koichi -->


<!-- Date: Mon Nov 6 02:48:56 2000 -->
<table><tr><td><a href=/elog/notebooks/barrel4/Mon_Nov__6_2000_024825.ps align=top><img src=/elog/gifs/ghost64.gif  width='56' align='top'></td><td>Preliminary data on bw scan (10/24). Average cluster charge and noise vs bw setting. Clusters selected using Weiming's outside-in tracking. No selection for wedge, segment and layer. Number of tracks found out of 5000 events ordered: bw1 -- 75,  bw2 -- 250, bw3 -- 220, bw4 -- 70, bw5 -- 200, bw6 -- 150, bw7 -- 50. Small statistics in bw1 and bw7 due to the COT tracking crashes.    Data taken with Matt's HitAnalyzer and tracking also present but yet not presentable.  </a></td></tr></table>
<!-- Author: Vladimir -->


<!-- Date: Mon Nov 6 02:53:09 2000 -->
<table><tr><td><a href=/elog/notebooks/barrel4/Mon_Nov__6_2000_025257.ps align=top><img src=/elog/gifs/ghost64.gif  width='56' align='top'></td><td>S/N ratio from previous plot. Statistics in Small Angle Stereo is too small- only phi and z presented. Note that timing in this bw scan was not optimized.  </a></td></tr></table>
<!-- Author: Vladimir -->
<!-- Comment: Mon Nov  6 16;43;03 comment by...Alan Sill -->
Note that these plots (as advertised) use <b>average</b> charge, not most probable value...
<!-- Date: Mon Nov 6 05:51:16 2000 -->
<pre>Just trying to squeeze the most amount out of this store... 
At Vladimir's suggestion, have taken more data with min-bias 
and calorimeter triggers (no COT since their HV's are off due 
to collimator studies) at various values of bandwidth (4, 5, 6...) 
Day shift crew please use run summary search form to find conditions. 
These data have been integrated with CDF although there is very 
little reason to do so apart from the triggers. 
 
Related note regarding run summaries:  It seems that the script 
returns "off" for the bias voltage state for all recent runs of 
the past few days even though the voltages have been on and stable 
during essentially all of that time.  Perhaps the script is pointing 
to the wrong area for the log files or otherwise broken...  Koichi 
will check...</pre>
<!-- Author: Alan Sill -->
<!-- Comment: Mon Nov  6 05;52;57 comment by...AFS -->
Note SOC set to same conditions as SVX II for these special runs
(was set to its own conditions previously).  Need to develop a procedure to check its initialization stream separately from
that of the rest of the silicon...

<!-- Comment: Mon Nov  6 06;29;30 comment by...Koichi. -->
fixed. Need to be tested.



<!-- Date: Mon Nov 6 08:08:52 2000 -->
<pre>Calibration Run. 
</pre>
<!-- Author: Koichi -->