Hello,
I did make some changes to ntuple.C
a) The retimeOR is not C-box 0, I think it should be clear
to most that it was *never* plugged into that channel
b) Therefore ntuple.C was still filling the "rtOR" field with
a wrong value. Fixed
c) Changed slightly eep. Note we don't have (or need) a start
counter for the definition of time left, time right
Having the retimeOR in ntuple allows me to plot it. Indeed L and R
sector are very well timed together, the retimeOR always come on the
some 10 channels!!!!
The run in question here was with no field and there are no cuts. The
S/N (fast fast peak vs proton peak) has improved from the last runs
because of the slits. UNFORTUNATELY the blast power supply is down and I
only have little data (indeed very little) to show with field on.
-----------
c1.ps (1st attach) is "t_proton - t_electron"..
Rows are 12L, 12R, 13L, 13R in coinc with paddles 2,3,4,5 of opposite
sector (columns).
You can judge for yourself if protons hit symmetrically the L and R
sectors. Not very much so. The right sector detector subframe was aligned
today so having an asymmetrically closed detector should not be an excuse
anymore. Clearly this issue needs investigation
-----------
c5.ps (2nd attahc). For the boxes above (wich are LR, RL coincs) the
retime channel value. => Retiming is OK, amen.
-------------
If you blow this up in a 2D plot "T-electron vs t_proton" you can
also see the region of the coinc windo were events are effectively well
strobed (ca. 45 ns, but I did not check for all paddles)
There are some issues also over here. SOme events may not be strobed
(then they should not be there!!) or may be strobed by a third channel
(triples, which are possible in the bckg).
Careful when you analyze the "fast fast" coincs. These are
background/shower events which may not be so obvious
Have a nice weekend
________________________________________________________________________________
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