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

[Brad Sawatzky]

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.

[ . . . ]
> Now, the strange thing is, what if I align the <wrong> RF packet on
> purpose in S2m, so as to line up beta?  This does indeed work -- for
> beta, that is.  This leaves S2m time avg. vs. track-x quite wrong.
> Plots 4 and

> 5 show such an effect, for the optimization of beta vs. track-x ~1.
> Plot 6 and 7 show the corresponding affect to the RF time vs. S1/S2m
> paddles.  (These plots have the label 'wrong' on them.)
> 
> I have a naive idea concerning the structure of these last two plots.
> What if the pathlength is not correct in the calculation of the RF
> time?  The RF time is calculated by (via Chiranjib's calculation):
> 
> rf =
> fmod(DL.rftime1*50e-3-1e+9*(L.s2.time[L.s2.trpad])+(L.s2.trpath+L.tr.pathl)/0.3,2/0.4985972)

fmod(
      DL.rftime1*50e-3 - 1e+9*(L.s2.time[L.s2.trpad])
       +(L.s2.trpath+L.tr.pathl)/0.3
                    ^             ^---- Speed of light in cm/ns, I guess.
                    ^---- I would have expected a '-' here.  Ex. we
                    correct for the flight-path time difference between
                    the path to the paddle vs a central ray.  Is the
                    L.s2.trpath already a difference relative to some
                    ideal/central path?
     ,
      2/0.4985972)

So, in the numerator he takes the difference between the RF time and the
paddle hit, corrects for a delta-t due to flight path difference to the
paddle that took the trigger time.  If he just divided (modulo) by the
RF period, then 'rf' would run between 0 and 2ns, giving a time offset
between the two nearest RF pulses.  The extra factor of 2 in the
denominator means 'rf' runs between 0 and 4ns -- I don't undestand why
he's doing that...

> where DL.rftime1 is the raw variable;  L.s2.time = time of hit at the S2m
> plane; L.s2.trpath = TRCS pathlength of the track to the detector plane;
> L.tr.pathl = pathlength from the target to the focal plane ( = S1?).

I think the L.tr.* entries typically use the first VDC plane as a
reference coordinate.  I'm fairly sure that the scintillators are never
used as a fiducial (by default, nothing is defined relative to their
position).

> Also, fmod takes arguments of a numerator,denominator.  The second term is
> related to the frequency of the RF pulse ~ 498MHz.  Further, I am not
> certain as to why we only take the <remainder> of this quotient?
>
> I tried getting a hold of Chiranjib concerning the explicit construction
> of the rf time, however he's quite busy at the moment.  I thought I'd post
> the formula here if anyone has any ideas.
> 
> My idea is that if the pathlength is incorrect, wouldn't we see a
> structure in the RF time vs. paddle # that is <not> a horizontal line? 
> This implies that a particular RF packet does not arrive at each paddle at
> the same time.  If so, then this may explain why we still have a jitter in
> S1 time avg. vs. track-x <even though> the RF pulses were naively aligned
> for S2m => jitter in beta.  However, I am not too certain of such ideas.

You'll get some very small jitter, but remember that 2ns at the speed of
light is a couple of feet -- unless a paddle positions in the DB files
is off by feet (ie. big typo), that's not the problem.

-- Brad

-- 
Brad Sawatzky, PhD <brads at jlab.org>  -<>-  Jefferson Lab / Hall C / C111
Ph: 757-269-5947  -<>-  Fax: 757-269-5235  -<>- Pager: brads-page at jlab.org
The most exciting phrase to hear in science, the one that heralds new
  discoveries, is not "Eureka!" but "That's funny..."   -- Isaac Asimov