SLAC PEP-II
BABAR
SLAC<->RAL
Babar logo
HEPIC E,S & H Databases PDG HEP preprints
Organization Detector Computing Physics Documentation
Personnel Glossary Sitemap Search Hypernews
Unwrap page!
Det. Search
Who's who?
Meetings
FAQ
Images
Archive
Systems
Performance
Intern. region
Vertex Tracker
Drift chamber
DIRC
Calorimeter
IFR
LST
Magnet
Electronics
Trigger
Operations
Run Coordination
Contact Experts
Shift Takers Info
Operations Manual
Electronic Logbook
Ops Hypernews
Shift Signup
Check this page for HTML 4.01 Transitional compliance with the
W3C Validator
(More checks...)

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

2.1 DCH

Aaron Roodman reported that:

  1. 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.
  2. 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)
  3. 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

 

2.2 DRC

GW reported the action items in progress

  1. Install the frequency to voltage converter and ship the signal to MCC. Progress will be made from Monday 29 with Terry and Guy
  2. 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
  3. Ship a direct PMT signal to the protection system. Guy and Tom

 

2.3 IFR

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

 

2.4 TRG-ONL

Gregory was not able to attend but he send documentation:

 

DataFlow:

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.

 

OEP:

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.

 

2.5 EMC

No report but almost everything was covered last week. See in last week minutes.