<br><br><div class="gmail_quote">On Wed, May 26, 2010 at 12:10 PM, Brad Sawatzky &lt;<a href="mailto:brads@jlab.org">brads@jlab.org</a>&gt; wrote:<br><blockquote class="gmail_quote">
<div class="im">On Mon, 17 May 2010, David Flay wrote:<br>
<br>
&gt; So, over the past few days I&#39;ve gone back and looked at the RF time vs.<br>
&gt; paddle # in S2m.  As you were mentioning, if we align the &lt;correct&gt; RF<br>
&gt; packets in this plot (see plot 1), we should, in theory, end up with a<br>
&gt; level line in the S2m time average vs. track-x.  If we consider plot 2,<br>
&gt; which shows the S2m time avg. vs. track-x, we see a level line (for the -x<br>
&gt; values -- I only played with those paddles here, to show the effect).<br>
&gt; While this is good, beta vs. track-x is still incorrect.<br>
&gt;<br>
&gt; It should be noted that I&#39;ve determined that 2ns = 38.57 arbitrary units<br>
&gt; (in the DB coefficients).  This allows me to switch RF packets quickly to<br>
&gt; see the results in the S2m time avg. vs. track-x.<br>
&gt;<br>
&gt; Now, we can consider RF time vs. S1 paddle number.  I&#39;ve played with the<br>
<br>
</div>You don&#39;t want to do this.  The RF time should only be used to fine-tune<br>
the S2m paddle timing.  There is no a priori &quot;correct&quot; RF pulse.  The<br>
right pulse is whichever one gives you a result that is most consistent<br>
with the physics you are using to calibrate your system (beta=1<br>
electrons, in our case).<br>
<br>
The order of operations should be this:<br>
  1 Pick the middle paddle in S2m, I&#39;m going to choose paddle 6.  It<br>
    doesn&#39;t really matter -- this is the just the paddle I am going to<br>
    use as my alignment reference.  If you histogram the uncorrected<br>
    timing for paddle 6 &#39;t_6&#39; you should see a self-timing spike<br>
    generated when the particle passes through that paddle and hence<br>
    carries the trigger timing.  Add and offset to the DB to align that<br>
    self timing spike to channel 1000 (or any other convenient channel).<br>
    If you re-analyze and histogram the corrected paddle 6 timing &#39;t_6c&#39;<br>
    then the self timing spike should land in bin 1000.<br>
<br>
  2 Now align the S2m paddles to each other by looking for electrons<br>
    that fire two adjacent/overlapping paddles.  For example, if paddles<br>
    6 and 7 fire both fire for one trigger, then one paddle will carry<br>
    the trigger timing (ie. its time will land in its self-timing spike),<br>
    and the second paddle with come in at a time<br>
      dt_7,6 = t_7 - t_6c<br>
    Since the same particle fired both paddles simultaneously, and they<br>
    both had the same trigger, then dt_7,6 is a measure of the timing<br>
    offset between the cabling for the two paddles.  Add the appropriate<br>
    correction to the paddle 7 offset so that the _corrected_ t_7 timing<br>
    for those adjacent hits is centered on bin 1000 in t_7c.<br>
<br>
  3 Now repeat, but look at<br>
       dt_7,8 = t_8 - t_7c, then<br>
       dt_8,9 = t_9 - t_8c,<br>
       . . .<br>
       dt_7,6 = t_6 - t_7c, then<br>
       dt_6,5 = t_5 - t_6c, ...<br>
<br>
  4 When complete, then the S2m time for every trigger should land<br>
    in a tight gaussian centered on channel 1000.<br>
<br>
<br>
  5 Now you can start looking at correcting S1[paddle] - S2m_corrected.<br>
    Compute the flight path between the two paddles involved in the<br>
    track: S1_a and S2_n.  Since you have constrained the physics such<br>
    that the particles have beta=1 (this is one of your assumptions),<br>
    you can compute the dt you expect.  Histogram the dt you actually<br>
    get:<br>
      dt = tS1_a - t_S2_n_corrected<br>
    and add an offset to S1_a to align the difference to match your<br>
    computed dt.  If you then histogram<br>
      dt_c = tS1_a_corrected - t_S2_n_corrected<br>
    then you should get a nice, narrow peak around the delta_t that<br>
    matches the physics in the detector.<br>
<br>
  6 Repeat for all of the S1 paddles.<br>
<br>
Once finished, it will not matter which paddles are hit, you should<br>
always get an S2m-S1 = delta_t that reflects a beta=1 particle<br>
travelling between those two planes.<br>
<br>
You can fine-tune the S2m timing by looking at (S2m_corr[paddle] -<br>
RF_time) only AFTER step 4.  Doing so will let you remove some of the<br>
error that accumulates as you walk your correction from the central<br>
paddle down to the edge.<br>
<br>
Note that real life is a little more complicated since the paddles have<br>
a non-zero length.  Particles that hit the paddle near the left PMT will<br>
fire the left PMT faster than particles that hit near the right PMT.<br>
That issue is removed by using the the sum (or average) of the two PMT<br>
TDC values as the &quot;paddle time&quot; that I use above.<br></blockquote><div><br>Thanks -- I have been working on something similar to this -- I plotted each paddle&#39;s time average subject to a cut on the paddle&#39;s central region in the S2m plane -- as best as I could get it -- I was trying to get a region of the paddle that had no overlap, and make sure those timing peaks were the same.  This would&#39;ve been the basis of my talk tomorrow.<br>
<br>In any case, I&#39;ve found that while most timing peaks (of the time averages of the paddles)  were ~61ns, some were off by 1ns.  So, I can go ahead and correct those.  But of course this will throw the RF time out of whack, as those are &lt;currently&gt; aligned.  If I can only move in RF by 2ns increments, then the time averages will always be off by some amount (~1ns).  -- this is what I&#39;ve been contemplating until your response <br>
<br>I did not look at the overlap yet -- I wanted to look at that next (what you were talking about above).   <br><br>Regarding that S1 RF plot -- I didn&#39;t use it for anything, I just had my code plot it; I was just curious to see what it looked like and wanted to ask if there was any real significance to it, as I didn&#39;t see anything<br>
<br>I&#39;m gonna take a closer look at what you&#39;ve mentioned, as my central-region cut theory breaks down pretty quickly -- I have code  to create &#39;virtual paddles&#39; to look at the overlap; but maybe it&#39;s better/easier to implement the cuts you mentioned -- looking at events that fire neighboring paddles -- I was thinking requiring both TDCs to fire, as opposed to a geometrical cut, as the geometrical cut doesn&#39;t necessarily require both paddles to fire.   <br>
</div></div><br clear="all"><br>-- <br>-----------------------------------------------------------<br>David Flay<br>Physics Department<br>Temple University<br>Philadelphia, PA 19122 <br><br>office: Barton Hall, BA319<br>phone: (215) 204-1331<br>
<br>e-mail: <a href="mailto:flay@jlab.org">flay@jlab.org</a> <br>            <a href="mailto:flay@temple.edu">flay@temple.edu</a><br><br>website: <a href="http://www.jlab.org/~flay">http://www.jlab.org/~flay</a><br>              <a href="http://quarks.temple.edu">http://quarks.temple.edu</a><br>
-----------------------------------------------------------<br><br><br>