[d2n-analysis-talk] Beta vs. Track-x, RF time

[David Flay]

On Wed, May 26, 2010 at 12:10 PM, Brad Sawatzky <brads at jlab.org> wrote:

> On Mon, 17 May 2010, David Flay wrote:
>
> > So, over the past few days I've gone back and looked at the RF time vs.
> > paddle # in S2m.  As you were mentioning, if we align the <correct> RF
> > packets in this plot (see plot 1), we should, in theory, end up with a
> > level line in the S2m time average vs. track-x.  If we consider plot 2,
> > which shows the S2m time avg. vs. track-x, we see a level line (for the
> -x
> > values -- I only played with those paddles here, to show the effect).
> > While this is good, beta vs. track-x is still incorrect.
> >
> > It should be noted that I've determined that 2ns = 38.57 arbitrary units
> > (in the DB coefficients).  This allows me to switch RF packets quickly to
> > see the results in the S2m time avg. vs. track-x.
> >
> > Now, we can consider RF time vs. S1 paddle number.  I've played with the
>
> You don't want to do this.  The RF time should only be used to fine-tune
> the S2m paddle timing.  There is no a priori "correct" RF pulse.  The
> right pulse is whichever one gives you a result that is most consistent
> with the physics you are using to calibrate your system (beta=1
> electrons, in our case).
>
> The order of operations should be this:
>  1 Pick the middle paddle in S2m, I'm going to choose paddle 6.  It
>    doesn't really matter -- this is the just the paddle I am going to
>    use as my alignment reference.  If you histogram the uncorrected
>    timing for paddle 6 't_6' you should see a self-timing spike
>    generated when the particle passes through that paddle and hence
>    carries the trigger timing.  Add and offset to the DB to align that
>    self timing spike to channel 1000 (or any other convenient channel).
>    If you re-analyze and histogram the corrected paddle 6 timing 't_6c'
>    then the self timing spike should land in bin 1000.
>
>  2 Now align the S2m paddles to each other by looking for electrons
>    that fire two adjacent/overlapping paddles.  For example, if paddles
>    6 and 7 fire both fire for one trigger, then one paddle will carry
>    the trigger timing (ie. its time will land in its self-timing spike),
>    and the second paddle with come in at a time
>      dt_7,6 = t_7 - t_6c
>    Since the same particle fired both paddles simultaneously, and they
>    both had the same trigger, then dt_7,6 is a measure of the timing
>    offset between the cabling for the two paddles.  Add the appropriate
>    correction to the paddle 7 offset so that the _corrected_ t_7 timing
>    for those adjacent hits is centered on bin 1000 in t_7c.
>
>  3 Now repeat, but look at
>       dt_7,8 = t_8 - t_7c, then
>       dt_8,9 = t_9 - t_8c,
>       . . .
>       dt_7,6 = t_6 - t_7c, then
>       dt_6,5 = t_5 - t_6c, ...
>
>  4 When complete, then the S2m time for every trigger should land
>    in a tight gaussian centered on channel 1000.
>
>
>  5 Now you can start looking at correcting S1[paddle] - S2m_corrected.
>    Compute the flight path between the two paddles involved in the
>    track: S1_a and S2_n.  Since you have constrained the physics such
>    that the particles have beta=1 (this is one of your assumptions),
>    you can compute the dt you expect.  Histogram the dt you actually
>    get:
>      dt = tS1_a - t_S2_n_corrected
>    and add an offset to S1_a to align the difference to match your
>    computed dt.  If you then histogram
>      dt_c = tS1_a_corrected - t_S2_n_corrected
>    then you should get a nice, narrow peak around the delta_t that
>    matches the physics in the detector.
>
>  6 Repeat for all of the S1 paddles.
>
> Once finished, it will not matter which paddles are hit, you should
> always get an S2m-S1 = delta_t that reflects a beta=1 particle
> travelling between those two planes.
>
> You can fine-tune the S2m timing by looking at (S2m_corr[paddle] -
> RF_time) only AFTER step 4.  Doing so will let you remove some of the
> error that accumulates as you walk your correction from the central
> paddle down to the edge.
>
> Note that real life is a little more complicated since the paddles have
> a non-zero length.  Particles that hit the paddle near the left PMT will
> fire the left PMT faster than particles that hit near the right PMT.
> That issue is removed by using the the sum (or average) of the two PMT
> TDC values as the "paddle time" that I use above.
>

Thanks -- I have been working on something similar to this -- I plotted each
paddle's time average subject to a cut on the paddle'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've been the basis of my talk tomorrow.

In any case, I'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 <currently> 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've been contemplating until your response

I did not look at the overlap yet -- I wanted to look at that next (what you
were talking about above).

Regarding that S1 RF plot -- I didn'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't see anything

I'm gonna take a closer look at what you've mentioned, as my central-region
cut theory breaks down pretty quickly -- I have code  to create 'virtual
paddles' to look at the overlap; but maybe it'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't necessarily require both paddles to fire.


-- 
-----------------------------------------------------------
David Flay
Physics Department
Temple University
Philadelphia, PA 19122

office: Barton Hall, BA319
phone: (215) 204-1331

e-mail: flay at jlab.org
           flay at temple.edu

website: http://www.jlab.org/~flay
             http://quarks.temple.edu
-----------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.jlab.org/pipermail/d2n-analysis-talk/attachments/20100526/e0d1d5d7/attachment-0001.html