I am considering a change to the ERP which will allow significant
improvement in the ERP GC monitor system, based on an idea that Ed
Kearns had. If this change gets implemented, it may affect everyone
who uses the ERP, which is why I am posting this note generally. If
you do data analysis using the ERP or you are involved in ERP
calibrations, please read this note carefully and let me know what you
think.
As you may or may not know, the ERP GC monitor software is not able to
collect streamer tube information without reducing its efficiency for
GC buffer collection significantly, due to the limitations of the RCD
library routines used for online buffer collection. The ERP GC
monitor vetoes muons from the data stream using a time-coincidence
criterion, i.e. any hit for which another hit is within a given time
window is cut. It is tricky to make this time coincidence cut for
inter-SM muons, since ERP GC buffers from different supermodules read
out at different times. And some single-box muon hits do always slip
past the time-coincidence cuts. Offline, it's easy to veto muons
using ST info; however the monitor, which runs in real time, does not have
this information available.
To provide the GC monitor with ST info without reducing buffer
collection efficiency, Ed's idea is to plug the Bari trigger into one
of the "fake boxes" of the ERP (the fake boxes are the ERP channels
which trigger the ERP for calibration events), to make a fake "Bari
box". This would allow the monitor program (and offline analyses as
well for that matter) to pick out GC-level events which are associated
with Bari triggers, by looking for coincidences (within the ERP clock
time resolution) of real ERP GC buffer hits with "hits" in the fake
Bari boxes.
It seems that it would be pretty easy to set up a "Bari box" like
this. I've discussed this with Rich, and we don't see any obvious
problems. Apparently the timing would work out: Chris tells me that
the Bari trigger is produced within a 1 usec, and the ERP window for a
hit to register after a previous hit is 10 usecs. The "Bari box"
input could be set up to produce an Elow level trigger only, so it
wouldn't cause fake Ehigh triggers (although the Bari box would get
read out along with real Ehighs). In addition, Rich has pointed out
that we could OR in other triggers (e.g. the CSPAM) to the fake box as
well and veto GC events on these too, if we choose.
Ideally we should use a truly spare ERP channel for this purpose;
however, all available "spare" ERP channels are being used for the LED
and laser fake boxes (and T17), so we'd have to plug the Bari trigger
signal into one of the calib. channels. This could conceivably cause
problems. So far I can't think of any really insurmountable problem
caused by the Bari box, but I can imagine that the Bari box could
cause troubles for some people.
Here are some potential problems:
* There would be an extra box read out for every muon, and this box
would be one normally associated with calibration events. Software
that flags data as calibration data based on the presence of fake box
hits would have to be changed. Also, any analysis which counts up
numbers of ERP boxes hit will have to take the extra box into account.
And so on.
* The presence of fake box data all over the place may well mess up
calibration software. Possibly having different ADC levels for
"calibration fake box" and "Bari fake box" triggers could help with
this (as would be the case if the Bari trigger makes only an Elow
trigger) . Also, cables could get switched around at calibration time
if necessary. It seems to me that it should be possible to work
around any calibration problems caused by a Bari box; however I can
also imagine that it could make life a bit more painful for
calibration folks. So: calibration folks, what do you think?
* Of course, the Bari box would increase the total amount
of ERP data somewhat. This is probably not a big deal. Actually, there
are some advantages to having the GC buffers read out a bit faster.
* There may well be effects I haven't considered. For instance, could ST
problems mess things up at times perhaps?
Anyway, this isn't yet a really serious proposal for doing this; I'd
just like some feedback about what the effects of a "Bari box" would
be. So, please think about this and let me know.
Kate.