[Hallc_running] Suggestion to shorten NPS readout interval from 400 to 200 nsec

[hamlet at jlab.org]

                 Peter,

does this not mean we have to optimize the position of the coincidence
window after every kinematic changes? Could we have efficiency lost ?

                   Best wishes, Hamlet.

> Background: we have been generally running considerably less beam current
> than in the NPS and SIDIS proposals (mostly planned for 30 muA). As a
> result, we are getting anywhere from 2 to 10 times less events than
> we hoped for.
>
> There are several factors that limit which current we use:
> a) keep anode current in average of NPS columns 0 and 1 below 30 muA
> b) keep data rate low enough that no crate exceeds 80 MB/sec. Since the
> crates all have roughly the same rates, we need to be well below
> 400 MB/sec to avoid this happening to any of the 4 and a half VME crates
> (one of the 5 is only half-populated). Last night we did a 30 minute
> run at 300 MB/sec with no trips. I think there is general agreement
> that keeping the rate below 200 MB/sec is acceptable.
> c) keeping the trigger rate low eneough to avoid significant computer dead
> time corrections, as well as exceeding the maximum transfer rate of data
> from the hall to the mass storage system.
>
> For most of the settings for the rest of the experiment, factor c) will
> be the limit that we reach before factors a) and b). Since the event size
> (and hence computer live time and transfer rates) are largely determined
> by writing out the NPS FADC data, we can gain up to a factor of two
> in what current we run by reducing the readout time for the FADC.
>
> At present, we have a readout window of 400 nsec.
>
> We only analyze events in a 100 nsec time window.
>
> But we need to readout over an interval longer than 100 nsec in order
> to catch the long tails of some pulses.
>
> A resonable compromise as far as I can tell would be to shorten the
> readout interval from 400 to 200 nsec.
>
> To keep the window centered on the coincidence time peak, we would
> reduce the time by 75 nsec on the back end, and 125 on the front end,
> as far as I understand.
>
> I propose that the experts get together on Tuesday after the Moller run
> and implement this change, after taking one run with the 400 nsec
> window, so we can make sure thaat no good data is being lost. As
> far as I understand, the experts include Alex, Wassim, Ben, and Sanguang.
>
> As I understand, only the config file(s) need to be changed: no knobs
> on the crates need to be turned.
>
>
> Prof. Peter Bosted
> email: bosted at jlab.org
> phone: (808) 315-1297 (cell)
> P.O. Box 6254, Ocean View, HI 96737
>
> _______________________________________________
> Hallc_running mailing list
> Hallc_running at jlab.org
> https://mailman.jlab.org/mailman/listinfo/hallc_running
>