Hi,
somehow I did not intend to send this email which was laying in
my outbox. The situation has been detailled in the elog. I agree
with doug below and I have no reason to cliam up to 20 ns. In fact,
for all I could measure, differences are of the order of 1 ns
The flasher trigger is anyways automatically in the setup now, so we can
monitor this situation more closely.
-- ________________________________________________________________________________ Tancredi Botto, phone: +1-617-253-9204 mobile: +1-978-490-4124 research scientist MIT/Bates, 21 Manning Av Middleton MA, 01949 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^On Fri, 11 Jul 2003, Douglas Hasell wrote:
> With good statistics (>10**6 events) we can probably track global changes > in the timing. Changes for different TOF's would be more tricky but again > possible with adequate statistics. > > I can write a little macro which would do this but it really does need > large statistics. Basically the 10**6 events are divided by the 10**3 > wires so its ~3000 events per sense wire. These events have to correspond > to real tracks of course. Not noise. > > If there are large blocks of runs which would have one set of timing and/or > delays then the you can run this and compare to another large block of runs > where you think the timing and/or delays may have changed. > > --On Friday, July 11, 2003 1:46 PM -0400 Tancredi Botto > <tancredi@mitlns.mit.edu> wrote: > > > > > Hello, > > I've found a bug in the trigger gui. Depending on how the file is > > downloaded the CFD retime delays are actually not updated (note their > > are not necessarily zeroed). You have to do download form each delay > > window (download all or trig -d don't do it). It seems a software problem. > > > > The problem could have been there since last year. There are two > > consequences for our data, but probably not terrible: > > > > _ the Wch may have not been always retimed (to the tune of a few ns, 20 > > ns max) which is an issue for resolutions. > > > > - The Tof timing corrections may not have been applicable since they > > somehow "contained" this delay (this is a separate issue and hopefully > > is solved differently) > > > > > > -- > > _________________________________________________________________________ > > _______ Tancredi Botto, phone: +1-617-253-9204 mobile: +1-978-490-4124 > > research scientist MIT/Bates, 21 Manning Av Middleton MA, 01949 > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > ^^^^^^^ > > > > > > > > Cheers, > Douglas > > 26-415 M.I.T. Tel: +1 617 258 7199 > 77 Massachusetts Avenue Fax: +1 617 258 5440 > Cambridge, MA 02139, USA E-mail: hasell@mit.edu >
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:29 EST