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

[David Flay]

Hey Brad,

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
calibration constants in the db_L.s1.dat file, and they do <not> affect
this plot.  However, the alignment of the RF time vs. S2m paddles <does>. 
See plot 3 -- this shows RF time vs. S1 paddles (aligned due to alignment
of RF time vs. S2m paddles.  Note: plot 3 is from the same calculations
made to produce plots 1 and 2.)  I believe this happens as the timing of
S1 is based on that of S2m.

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)

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?).

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.

Dave

P.S. -- I've been considering to try to re-optimize the time avgs. and
offsets (for S2m) using Vince's code, after having the RF times aligned to
the proper RF packets, thinking maybe since the RF packet is aligned
correctly, it may influence the outcome of the calibration => remove the
jitter in S1 time avg. vs. track-x.  I'll take a shot at this tonight, and
we'll see what happens.

-------------------------------------------------
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 --------------
A non-text attachment was scrubbed...
Name: rf_s2m_20676_5_15_10.png
Type: image/png
Size: 33351 bytes
Desc: not available
Url : https://mailman.jlab.org/pipermail/d2n-analysis-talk/attachments/20100517/6caf7365/attachment-0007.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: beta-track_20676_5_17_10.png
Type: image/png
Size: 45021 bytes
Desc: not available
Url : https://mailman.jlab.org/pipermail/d2n-analysis-talk/attachments/20100517/6caf7365/attachment-0008.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scint_rf_s1_right-packet_20676_5_17_10.png
Type: image/png
Size: 28963 bytes
Desc: not available
Url : https://mailman.jlab.org/pipermail/d2n-analysis-talk/attachments/20100517/6caf7365/attachment-0009.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: beta-track_wrong_20676_5_17_10.png
Type: image/png
Size: 46901 bytes
Desc: not available
Url : https://mailman.jlab.org/pipermail/d2n-analysis-talk/attachments/20100517/6caf7365/attachment-0010.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scint_toffs_wrong_20676_5_17_10.png
Type: image/png
Size: 46216 bytes
Desc: not available
Url : https://mailman.jlab.org/pipermail/d2n-analysis-talk/attachments/20100517/6caf7365/attachment-0011.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scint_rf_s1_wrong_20676_5_17_10.png
Type: image/png
Size: 28316 bytes
Desc: not available
Url : https://mailman.jlab.org/pipermail/d2n-analysis-talk/attachments/20100517/6caf7365/attachment-0012.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scint_rf_s2m_wrong_20676_5_17_10.png
Type: image/png
Size: 34371 bytes
Desc: not available
Url : https://mailman.jlab.org/pipermail/d2n-analysis-talk/attachments/20100517/6caf7365/attachment-0013.png