Minutes of the March 26 Background Remediation meeting
1/Organisation of the background group for the upcoming run
Tom Mattison explained what structure for the background group was proposed to the Technical Board:
-The background group will be co-chaired by Tom Mattison and Guy Wormser. It will still hold regular weekly meetings every Friday. The topics covered will include the analysis of background in terms of machine operation , the characterization and the impact of the background in BABAR. The attendance will
should mostly consist as presently of liaison people, subdetector hardware and offline contacts.
-The group formed by the liaison people will have another weekly meeting chaired by Tom Mattison at the beginning (Tom would like to be relieved of that task in the fall, any volunteer?). This meeting, (not a video one, possibly by phone) will focus on the operational and technical aspects of the liaison group work.
A report will be made at the Friday meeting and minutes available by hypernews.
2/ Continuation of EPICS readiness reports
Aaron Roodman reported that:
- A satisfactory test was made of using two CAEN voltages in parallel to feed one HV superlayer. The 40 uA limit can then be raised to 80 if need be.
- He is actively following the studies of the time characteristics of the Caen power supplies: the integration time (can spikes be detected) and delay time (can we follow machine scans)
- Concerning the extraction of OEP data (like DCH occupancy) and its shipping to MCC, there are global software issues involved. We will need to ask an expoert to report on that at a future meeting
GW reported the action items in progress
- Install the frequency to voltage converter and ship the signal to MCC. Progress will be made from Monday 29 with Terry and Guy
- Install a gating module for the DRC scaler so the EPICS readout is a count in a given time window (ie a frequency). One gating module is being bought but due to the long time delay, the idea was to borrow a spare module from the IFR at the beginning (1 channel needed). Guy will check with PG
- Ship a direct PMT signal to the protection system. Guy and Tom
PG Paolucci gave the following report:
The background project consists to install one RPC in the backward side and one in the forward side. These RPC are 2 squared meter large and are equipped with a plane of 32 strips. Each strip plane are connected to 2 Front-End Cards (FEC). One FEC is connected to 16 strip (analog inputs) and provides a digital serial output (the strip signals are amplified and discriminated) and two fast-OR ECL diff. signals. The fast-OR is the logical OR of the 16 input signals and is a time-over-treshold signals, at least 10 ns wide. The Single Counting Rate of one RPC is defined as the logical OR of the 2 fast-OR signals.
In total the background system has 4 FECs and so 4 fast-OR to acquire. The fast-OR signals will be sent to the VME scalers placed in the electronic house in the IFRMON DAQ crate. The VME scaler is enabled to count by a NIM signal generated by the VME unit time called Dual Gate Generator. It is a programmable unit providing 2 NIM gates, from 100nsec to 10sec wide. Our gate is 1sec wide and the DAQ rate is of about 1/10 Hz. The IFR system will be able to monitor the single rate of the background RPCs with a DAQ rate of about 1/10 Hz and with an error less than 1%.
Gregory was not able to attend but he send documentation:
o New event builder, due next week, will implement back
pressure at all levels of the hierarchy, including the final build
into the OEP nodes;
o User access to back pressure and dead time monitoring is now being
developed and will be available in time for the run. The decision
made, however, was to make the raw data available in a documented
format, rather than to attempt to aggregate the data within DataFlow.
Mike, Gerry Abrams, and I are discussing whether an OEP-like system
or a Detector Control IOC-like system would be best for receiving
the data. Either way, it's a more familiar and forgiving programming
environment than DataFlow, and each one comes with data archiving
and presentation tools (for OEP, DHP with histograms and scalers,
and for ODC, EPICS). Using ODC/EPICS has the additional potential
advantage of making it easy to make information available to PEP-II.
Either way, we still need help from outside the online group to
write the aggregation code and choose the quantities that will be
made available to BaBar and PEP-II operators.
o HepScaler filling and visualization tools, suitable for producing
time histories of occupancies, etc. are available or becoming
available. These tools should have reached a reasonable level of
usability by next week.
Running in a restricted mode during injection or other non-physics times:
o There's been no specific work on this. Again, the principal problem
is defining detector protection protocols that would allow only safe
forms of running in this mode. This isn't a small problem.