Hi, I agree timing is generally fine. but there does seem to be fishy
things. see the atatchment 015.eps and 150.eps.
they represent tdc difference between a positive charged particle in pad
15 and a negative charged particle in pad 0. 150.eps is left 15 with right
0 and 015.eps is left 0 with right 15.
blue is general ttl-ttr(ttr-ttl) histogram which red is the one after
coplainarity cuts. They clearly have the same shape and charactor under
cuts. I would identify the peak at low channels protons and the peak at
higher channels (larger tdc difference) deuterons since it is almost
intact under coplainarity cut.
however, right 15 with left 0 is shifted to the left by a LARGE distance.
the distance between the two peaks are both about 450 channels.
it the figure is read literally, it seems protons arrive before electrons
and deuterons arrive pad 15 only 7.5ns later than the electron at pad 0.
the spectra for left 15 right 0 combination makes much better sense
though.
Any comments?
Chi
On Wed, 9 Jul 2003, Tancredi Botto wrote:
>
> Hi peter, vitaly, and all retime/beta loving people
>
> I've finished my analysis of various cal files (not, I derive my own cal
> files with macros/tdc_offsets.C, results in results/tancredi/tdc_offsets)
> obtained for different flasher runs.
>
> I "think" it is unlikely that the retime offsets were wrong this year.
> However, compared to last year we had no meantimer in the way of the
> trigger time. Further I'd consider the tdc offsets from last year to be
> wrong for a number of reasons (for once, our startegy is now different,
> as summarized below).
>
> Then I'd really like to see the results from show_protons for an updated
> blastcal file obtained from a flasher run with and without retime
> offsets and a show_protons for no blast cal file. We want to see an
> improvements step by step. Peter, can you take care of that ???
>
>
> Here is how I based my conclusion about the retime:
>
> a) For runs 1325/1332 and 1326/1334 the offsets are the same within 0.5 ns
> see elogbook.
> b) for run 1235, compared with 1325 and 1332, about 3 and 9 channels are
> outside 1 ns. Run 1235 is "representative" of how the delays were
> downloaded this year, until the trigger gui bug was found.
> c) if the retime delays were wrong they were likely in within these
> limits. Note that all triggers downloaded this year had the right
> retime delays (until I started playing with them).
> d) In this result there is also the effect of ramping the HV's and of the
> field (which was not on in run 1235)
> e) The flasher peak has a sigma of 0.2 ns... so these shifts are really
> large systematics. We plan on keeping it on during data taking as well
>
> More comments:
>
> 1) Although reproducibility seems ok (mostly <0.5 ns) the "scale" of
> the delays units can be way off. In other words some channels respond
> in a non-linear fashion. You'll be surprised you can miss 4 ns out of
> 16 ns... but then turns out to be ok when you download 32 ns...
> 2) These conditions are how we determined our retime, so we have to
> believe the actual delays are ok, although the behaviour of the nominal
> value was never as smooth as we wanted it (and we never really
> explained that, see retime delays for channel R4t vs R4b)
> 3) The trigger gui bug at download remains.
> 4) we don't really have spare delay units and you can't really get them
> either
>
> Here's my strategy:
>
> _ our most realistic tdc offsets (and also truer to their definition)
> are obtained for flasher runs where the retime delays have been taken
> out. More over in this way you get t=0 for any detector.
>
> _ We wish with this strategy to make all proton timing peaks arrive
> at the same tdc channel (after correction)
>
> - realistically, do not expect the peaks to line up much better than +-40
> channels across L/R and for different combinations
>
> - The position can be further adjusted, mantaining the sum (time) a
> constant with chris' macro.
>
> - If we are still unhappy then I think we'll have to sharpen our "tune"
> with kinematics and apply a second channel by channel correction. It does
> not really matter "what the correction is" since you know the mass of the
> proton has to be m = p/v and tof is only used for pid. I can see having
> to this for a few analysis.
>
> - true, for the neutron we are more dependent on the timing offsets and
> 2ns is not very appealing since that can be 10% of the flight time, but
> again you can use momentum conservation to tune out p_neutron(timing) as
> well as some smart analysis with the gamma peak
>
> - Another option, with enough shielding (such as what we used on the start
> counter for CC tests) we could retime the detector for bent tracks instead
> of straight tracks
>
> -tancredi
>
> ________________________________________________________________________________
> Tancredi Botto, phone: +1-617-253-9204 mobile: +1-978-490-4124
> research scientist MIT/Bates, 21 Manning Av Middleton MA, 01949
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> On Tue, 8 Jul 2003, Peter Karpius wrote:
>
> > V-
> > OK I have calculated the offsets based on run 1326 (no delays) and
> > created an ep ntuple from runs 705-735 (missing a few). I plotted ttl-ttr
> > against ttr-ttl and things don't look good. Still trying to figure out
> > why.
> >
> >
> > Pete
> >
> > PS the macro I used to do this was proton_sum.C in
> > /home/blast/blast/pro2003/analysis/macros
> >
> > ----------------------------------------------
> > Pete Karpius
> > Graduate Research Assistant
> > Nuclear Physics Group
> > University of New Hampshire
> > phone: (603)862-1220
> > FAX: (603)862-2998
> > email: karpiusp@einstein.unh.edu
> > http://pubpages.unh.edu/~pkarpius/homepage.htm
> > ----------------------------------------------
> >
> >
>
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:29 EST