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

[bosted at jlab.org]

Hamlet,
   The coincidence time window does not change with NPS angle.
It does change with distance from target, but only shifts
by 20 nsec goinf from 3 m to 9.5 m (the ep elastic setting).
    This is small compared to the proposed readout width of 200 nsec.
    Peter

>                  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
>>
>
>
>