Summary: long email, no elogbook. Retime fixed. Interesting left protons
issue...
We start by measuring the retime of all right sector scintillators,
see attached plot. We clearly see an electron peak and - for backward
scintillators - a proton peak. You can see more protons in forward
paddles, but the rate of those doesn't fall as quickly as the elastic
cross section so we conclude we (finally) see protons from the cell walls.
All channels are well timed within the usual +- 1 ns, this time
around channel 1417.5. Typical widths are 0.5 ns sigma.
We then connect the start counter to channel R16. To do this, we wire up
a "special" cable cut out such that the start counter pulse will not make
it to the retiming OR (so that the retiming OR has an unambiguous meaning:
is the meantime signal of whatever right sector was hit, but not the start
counter which would give a self timing peak).
All channels show similar spreads and widths, but land at channel 1674.6
After compensating for the different cables used (we measure their
lenghts) we are still about 11.5 ns off, or 220 channels.
This time the start counter is plugged into R16, before it was plugged
in L16.
We forget about the start counter and plug the flasher to all 32
scintillators. Flasher data line up well on the scope after the retiming
or, and also at the TDC input. We take this flasher data. For equal time
signals, the average of R16 TDC signals (top,bottom) is 326, the average
of L16 signals (top,bottom) is 529. This difference is a simply a different
offset across the two tdc channels!!! (they are also different modules)
That explains the retiming mistery. Indeed, more detailled analysis shows
that we are also fully consistent with the retime data taken for the
left sector. Those data landed on channel 1710. Our data for the right
sector with the start counter plugged on R16 (such as two weeks ago)
instead of L16 - and corrected for a 4 ns change in the user-set delays
for that channel - give a mean around channel 1700.
Plots are in the logbook.
We also note an important subtlelty relative to the issue of left side
protons. Yesterday I claimed that there was a 15 ns difference visible on
the scope between left and right sectors. Today, I had to admit there
wasn't. But indeed, yesterday I used start counter flasher data. And
again this evening it clearly shows to be in 15 ns earlier relative to all
other channels.
The signal coming from the start counter goes through the same cable lengths
as all other scintillators.
HOWEVER, the start counter itself is a short paddle (< 1m), in contrast to
a tof scintillator (ca. 1.8 mt w/o light guides). In addition the start
counter is read out by different tubes. We conclude that that and the
geometry account for a 15 ns difference.
When we try to trigger protons on the left, and so far the start
counter was also always plugged to the left but physically on the right,
we simply miss the slow protons (ca 15 ns later thant the electrons, at a
tof paddle, see this attached plot) since the start counter (with a very
fast, short path electron signal) is anticipated by 15 ns
We guess we lose the left side coinc by at least 15 + 15 + 3 ns
where the last 3 ns are a guess of the tof difference between an electron
in a tof paddle (3 mt away) and in the start counter (20 cm away).
Conclusion:
_ Our retiming data of right sector with start counter on R16 compared
very well with the left sector retiming data (start counter on R16).
_ We should go back to a start counter on the beam left, and compare data
sets for when this is connected only to L16
_ In all of this retime saga we indeed only used 2 (3) TDC channels. We
don't need a TDC calibration to say that L and R sector are timed. However
we need to measure and calibrate these TDC offsets at some point.
regards,
-- tancredi, peter
________________________________________________________________________________
Tancredi Botto, phone: +1-617-253-9204 fax: +1-617-253-9599
research scientist MIT/Bates, 21 Manning Av Middleton MA, 01949
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:28 EST