<br><br><div class="gmail_quote">On Tue, Nov 23, 2010 at 6:14 PM, Brad Sawatzky <<a href="mailto:brads@jlab.org">brads@jlab.org</a>> wrote:<br><blockquote class="gmail_quote">
On Fri, 19 Nov 2010, David Flay wrote:<br>
<br>
> I've gone back to looking at the raw S2m TDCs, and upon taking a<br>
> closer look at these on log scale, it's clear that there is a shoulder<br>
> structure to the immediate right of each self-timing peak in the right<br>
> TDCs (right = red, left = blue). The same may be said of the left<br>
> TDCs. The main peak of the left TDCs also have a significant width to<br>
> them.<br>
<br>
Interesting plots.<br>
<br>
You need to cut out the EDTM pulses -- I don't see that in your cutlist.</blockquote><blockquote class="gmail_quote">
<br>
A tail/shoulder at longer times on the L pmts could be driven by<br>
time-walk. Note that _all_ structure outside the self-timing peak<br>
around bin 1950 in the S2m R pmt spectra must either:<br>
1) be noise and/or secondary particles -- ie. that paddle can not have<br>
generated the trigger, or<br>
2) if you know that paddle did generate the trigger (say, because none<br>
of the other paddles have any hits), then the wrong hit from the<br>
multi-hit is TDC being stored in L.s2.rt[], or<br>
3) this is not really a T3 trigger and something else is generating<br>
the trigger timing (ie. DL.evtypebits is being constructed<br>
incorrectly).<br>
<br>
The nice sharp spikes around bin 1950 in the red histos are the events<br>
where that paddle (R pmt) carried the trigger timing.<br>
<br>
Those are the peaks that should be aligned to a common bin in the<br>
corrected histos. Note that you need to align the single-PMT spike, not<br>
the average ([R+L]/2) time for S2m. The aligned Right-PMT_S2m time<br>
"L.s2.rt_c[x]", where x is the paddle that generated the trigger, should<br>
be your reference time when you align s1 later, not the average paddle<br>
time.<br></blockquote><div><br></div><div>I've aligned these guys (the right PMTs only) -- see attached histos. <br><br>These (corrected) times were derived from the raw TDC histograms. I chose a paddle as a reference (index 7, paddle 8) and aligned the R PMT times to that value.<br>
<br>The results are as follows (in ns):<br><br>S2mRMean[0]: 61.3362 S2mRSigma[0]: 0.1129<br>S2mRMean[1]: 61.3055 S2mRSigma[1]: 0.0946<br>S2mRMean[2]: 61.3105 S2mRSigma[2]: 0.1139<br>S2mRMean[3]: 61.3396 S2mRSigma[3]: 0.0956<br>
S2mRMean[4]: 61.3093 S2mRSigma[4]: 0.1061<br>S2mRMean[5]: 61.3222 S2mRSigma[5]: 0.0954<br>S2mRMean[6]: 61.3022 S2mRSigma[6]: 0.1038<br>S2mRMean[7]: 61.3138 S2mRSigma[7]: 0.1029<br>S2mRMean[8]: 61.3174 S2mRSigma[8]: 0.0978<br>
S2mRMean[9]: 61.3111 S2mRSigma[9]: 0.0977<br>S2mRMean[10]: 61.3187 S2mRSigma[10]: 0.1086<br>S2mRMean[11]: 61.3201 S2mRSigma[11]: 0.0996<br>S2mRMean[12]: 61.3155 S2mRSigma[12]: 0.1105<br>S2mRMean[13]: 61.3603 S2mRSigma[13]: 0.1037<br>
S2mRMean[14]: 61.3638 S2mRSigma[14]: 0.1083<br>S2mRMean[15]: 61.2838 S2mRSigma[15]: 0.0991<br><br>These results come from a Gaussian fit centered on 61 +/- 1 ns. <br><br>The third plot shows the (corrected) R PMT TDC signals, with a binning of 0.05ns/bin. <br>
<br></div><blockquote class="gmail_quote">
<br>
Note that the width of the blue peak around bin 1800 should be driven by<br>
the time it takes for light to propagate across the bar to the L pmt.<br>
If the LHRS acceptance is uniformly illuminated it should have a flat<br>
top (ie. a rectangular 'peak' with a width that is equal to<br>
index_refraction*bar_length/c<br>
not a Gaussian like in your plots. Perhaps this is an e-P elastics run?<br>
(The width will also be smeared by the timing resolution of the TDC:<br>
0.5ns/bin for 1877s.)</blockquote><div><br></div><div>the DB lists these TDCs as 1875's with a resolution of 0.05ns/bin. The run for those plots was production, 4-pass, p = 0.60 GeV. <br></div><div> </div><blockquote class="gmail_quote">
</blockquote><blockquote class="gmail_quote">
Note that the averaged paddle time "(R+L)/2" does _not_ remove the<br>
propagation time broadening in S2m since the R PMT is the one that<br>
generates the start time at the TDC. In principle, you could apply a<br>
propagation time correction to both the right and left PMT timing based<br>
on where the tracking says the particle intersected with the bar and<br>
remove the propagation time effect. In practice, at least for us, it's<br>
not worth the effort.<br>
<br>
Because the position-correlated time offsets are not removed from<br>
S2m_ave[] (and can not be removed without using tracking information),<br>
you are stuck with them in S1 as well. Because of this, I recommend you<br>
ignore all timing information from the Left PMTs in both S1 and S2m.<br>
You should still require that both PMTs see a hit within a reasonable<br>
time window (this requires that both PMTs on the bar see light within a<br>
physically relevant time window event, which will suppress noise).<br>
<br>
I sketched out some math on the timing calculations. If you haven't<br>
seen this kind of thing before, it really helps when you're trying to<br>
make sense of what you're seeing. See the attached scan and drop me a<br>
line if you have questions. When I write b:{0,t}, I mean that b can<br>
vary between 0 and t nanoseconds, depending on where the particle hits<br>
the bar.</blockquote><div><br>Thanks, this makes things clear & easier to understand <br> <br></div><blockquote class="gmail_quote">
Assuming that no-hit events show up in bin zero (suppressed on these<br>
plots), then I would say the blue spike at ~4100 is due to the left-side<br>
PMT carrying the trigger timing. That should be impossible for a good<br>
particle unless there is a hardware cabling error. If the spike is just<br>
random coincidences (ie. junk), then height of the spike suggests a L+R<br>
coincidence windows of 100 bins == 50ns. That seems a little wide to<br>
me, but it's hard to judge factors of two off the plot. (Basically, you<br>
assume a flat randoms distribution and ask yourself how many bins' worth<br>
of background have piled up in the spike on the right. Then convert the<br>
#bins to ns and that is your coincidence overlap.)<br>
<br>
If, however, there is a spike at 4100 in the red histo too (hidden<br>
behind the blue), then I would guess that those are really the no-hit<br>
events (ie. no hits in that channel within the TDC window setting).<br>
The fact that they show up in a single bin is a consequence of the<br>
analyzer assigning some fixed value to such no-hit events (ie. 0?) and<br>
the formula used to convert and correct the common-stop TDC data to<br>
nanoseconds in your histogram. This assumption would mean there should<br>
not be any hits in bin zero though -- that needs to be checked.<br></blockquote><div><br><br>
From this third plot, there are no events in the bin for 0 ns. <br></div><div><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/%7Eflay">http://www.jlab.org/~flay</a><br> <a href="http://quarks.temple.edu">http://quarks.temple.edu</a><br>-----------------------------------------------------------<br>
<br><br>