Available on CMS information server CMS NOTE 2003/000

Title:(tn_header.eps)Creator:Adobe Illustrator(r) 6.0Preview:This EPS picture was not savedwith a preview included in it.Comment:This EPS picture will print to aPostScript printer, but not toother types of printers. May 1, 2003

The validation systemfor the Barrel Muon Chambers at LNL

- The cosmic setup -

M. Bellato, E. Conti, M. De Giorgi, F. Gonella, A. Meneguzzo, M. Passaseo, M. Pegoraro, S. Vanini, S. Ventura

Dipartimento di Fisica and INFN, Padova, Italy

L. Berti, M. Biasotto, E. Ferro, M. Gulmini, G. Maron, N. Toniolo, L. Zangrando

INFN, Laboratori Nazionali di Legnaro, Italy

Abstract

The first design of a Barrel Muon Chamber composed of staggered layers of drift cells started in Padova in 1993 []. The Chambers were designed for the CMS experiment that will run in the LHC accelerator at CERN. The full production of these Chambers started two year ago in three European laboratories, and about 70 are being built in a large hall of the Laboratori Nazionali di Legnaro of INFN (LNL).

The INFN section of Padova is in charge of working out the mechanical design [], the FE electronics and LV system [], the HV system and the muon local trigger design [] for the final chamber setup.

Moreover, before the Chambers are shipped to CERN, it is necessary to test and validate their overall functionality and stability, for which a proper test system has been designed and implemented.

This note describes the experimental setup of the chamber test area at LNL and the cosmic-ray acquisition and monitor system for the on-line data analysis.

2

1 IntroductionThe first design of a Barrel Muon Chamber based on staggered layers of drift cells started in Padova in 1993 []. After eight years, the full production of the Barrel Chambers for the CMS experiment for the LHC accelerator at CERN finally started in 2001 by three European collaborators, namely Padova (sez. INFN), Aachen (RWTH), and Madrid (CIEMAT).

The muon chambers of MB3 type that form the third shell of the detector, and some special MB4 for the fourth shell are built in a hall of the Laboratori Nazionali di Legnaro of INFN. Before being sent to CERN, chambers must be tested in all functionalities for validation: after preliminary checks, a test with cosmic rays is necessary, because cosmic rays runs reproduce real working conditions and allow the on line recovery of construction problems.

A chamber for the Muon Barrel Detector [] [] consists of 12 layers of rectangular drift cells with a pitch of 42 mm by 13 mm. The cell layout aims at measuring the drift time of ionization electrons produced by incident muons. The specific electric field shape is assured in each cell by 4 electrodes on the walls and by the central wire anode; three different HV are needed to bias the cell and provide the linearity of the space-time relationship of drifting electrons. Each wire is read out by a specific designed FE chip housed in compact boards of 16 or 20 channels to accomplish the different chambers size []. The smallest chamber (MB1 type) has ~620 readout channels and the bigger (MB3 type) ~800.

The 12 layers of tubes are staggered by half a cell and grouped four by four to form 3 independent modules named SuperLayers (SLs). The two external SLs will be devoted to the precise measurements of incident particle in the bending plane and together should yield 100 micron precision in position and 1 mrad in direction; the other SL will measure the coordinate along the beam line. The wires information will be used in the first level trigger [] so the relative position of each layer and of the wires in each layer should be less then one hundred micron. The chamber is assembled by gluing the 3 SLs together with an aluminum honeycomb plate to ensure the required stiffness and increase the lever arm between the two external SLs.

To assure a constant and precise drift velocity inside the cell for ionization electrons the ArCO 2 gas mixture must be well-defined and highly pure; moreover, the chamber must work at a steady and controlled pressure.

The production and functionality of the chamber under construction must be monitorized. The construction and test of a large number (70) of chambers implies the implementation of robust and reliable tests to be used for all the 3 years foreseen for the production [].

The same data acquisition and monitor system has been used in the test beam runs performed at CERN.

2 Requirement and the LNL cosmic setup.The setup allows to verify the correctness of the following items once each chamber is assembled:

- electrical connections

- noise rate

- electronic performances

- cables and electronic delay

- detection efficiency

- time resolution

- uniformity of chamber response

- layer (and superlayer) mechanical accuracy

All tests must be performed under controlled gas and environmental conditions, defined working pressure and monitorized LV and HV settings.

The strict requirement depends on the fact that FE electronics and HV distribution to cells sit inside the gas volume, and any misfunctionality of any part may imply the opening of the SL itself. Furthermore, in order to fulfill a common quality level in all different production sites all detectors must have a minimum guaranteed performance on the items listed above.

In Figure 1 a schematic of the system is introduced. It is composed by the High Voltage power system controlled via net by a PC, the Low Voltage power system with slow control functions and connected to the same PC via serial

3

line, the TDC modules read via net by the DAQ system, the plastic scintillators which trigger cosmic-rays, and the gas and environmental parameters monitor system. Finally, a third PC allows the visualization and on-line analysis of the acquired data.

PCLINUX

TCP-IP

Software•DAQ control

PCLINUX

TCP-IP

Software•DAQ monitor

PCWin NT

TCP-IP

serial

Analog signals

Software•SY1527 control•LV power & SlowCtrl•environment - NI PCI6023

PMtrigger

TCP-IP

TCP-IP

Gas & Envmonitor

LV power&

SlowCtrl

HV power

TDCcrate

Figure 1: Schematic of the chamber validation system.

Figure 2: Photo of the chamber test area at LNL.

4

In Figure 2 a photo of the test area is shown: an MB3 chamber can be seen over the metal structure also housing the groups of scintillators, while on the left we can see the rack of the control system and gas distribution, the two DAQ racks, the trigger system and the rack HV and LV power sources, finally in the middle the controlling PCs and DAQ.

A remarkable cabling and grounding job of the test area has allowed to obtain a reliable experimental setup, not affected by external noise and disturbance, which guarantees repeatability and reliability of the validation tests.

Some results about the quality of the MB3 chambers obtained from the data collected using the experimental setup described in this note are presented in [].

3 Gas System and Environmental MonitorThe long life foreseen for the CMS detector and the necessary gas purity require a continuous gas flow supply system. In effect, for high detection efficiency oxygen concentration must be kept to a minimum and the same goes for nitrogen, in order to maintain stable the drift velocity inside the cell. Oxygen and nitrogen come from environment diffusion, so the measurement of the first (easier) automatically informs about the second.

Also, all validation tests must be performed under controlled gas flow and environment conditions (temperature, atmospheric pressure) and at defined and stable working pressure.

A whole rack housed the gas distribution and control system and the monitor of the environment parameters.

The gas employed is a mixture of 85% argon and 15% CO2 available in premixed bottles of 50 l at 200 bar, with a total impurity concentration certified below few ppm.

3.1 Gas distribution and control systemThe gas system for chamber tests consists of a line with maximum flow of 2 l/min with electronic control and two emergency valves in order to limit overpressure to maximum 50 mbar. The complete outline can be seen in Figure 3. The mixed gas enters a Bronkhorst flow regulator [], and is sent to the chamber after a safety valve. The second safety valve is placed downstream the chamber. The gas exhaust line is splitted in two. The first main branch goes into a regulator valve [] by means of which we can control the absolute gas pressure in the chamber and keep it steady during data acquisition. The second line feeds the oxygen meter.

CMS

MUON

CHAMBER

FLUX REGULATOR2l/min

FLUX REGULATOR100-200cc//min

O2 METER

CHAMBER’S PRESSUREREGULATING VALVE

PRESSURE LIMITER50mbar

PRESSURE LIMITER50mbar

GAS SUPPLY GAS EXAUST

GAS EXAUST

GAS IN GAS OUT

to analogread

to analogread

to analogread

to analogread

Figure 3: Schematic of the gas distribution and control system.

5

The oxygen measurement is made using a Zirconia Oxygen Analyzer []. The Zirconia sensor measures the oxygen content in the gas and emits a mV signal: the cell voltage rises logarithmically as the amount of oxygen in the gas falls, allowing the measurement of very small amounts (down to fractions of ppm). A Digital Display Unit amplifies and linearizes the logarithmic output of the Zirconia sensor.

The system also implements a second line with a manual flowmeter for leakage tests.

3.2 Environmental and gas monitorA system of analog sensors monitors all interesting environmental parameters: temperature, humidity and pressure. A custom rack box powers the sensors, amplifies output signals and transmits them to the 16 input-ADC board with 12-bit resolution (National Instrument PCI6023 []).

The same electronic box receives signals from flowmeters, pressure control valve and the oxygen meter, which after conditioning and buffering are sent to the acquisition board too.

All information is published by means of an Apache Web Server by a software developed with Labview that regularly reads the analog channels of the ADC board.

In Figure 4 below the schematic of the system is shown.

Environment & GasMonitor System

Temp Sensor Humidity Sensor Pressure Sensor

Flux Sensors Pvalve Sensor O2 Sensor

National InstrumentsPCI602316chs ADC board

Figure 4: Schematic of the environmental and gas monitor system.

4 HV Power systemThe high voltage system is based on a CAEN SY1527 [] power supply system housing an A876 master board that controls an A877 remote board. The system used is shown in Figure 5 below.

A876 A877+HV

-HV

LV Power

Communication

PHI2

THETA

PHI1

Junctionbox

THETA A

THETA B

PHI2 B

PHI2 A

PHI1 B

PHI1 A

to chamberSL theta

to chamber SL phi1 & phi2

6

Figure 5: Schematic of the chamber HV power and distribution system.

The A876 master board is able to control and supply up to four independent A877 remote boards. The board delivers four groups of high/low floating voltages: a positive high voltage in the range from 0 to 4200 V, a negative high voltage in the range from 0 to –2200 V, and a dual low voltage for remote boards powering. A common communication bus links the remote A877 to the A876 master board.

The A877 board delivers high voltages to the electrodes (anodes, cathodes and strips) of the muon chambers. The board provides 12 groups (MacroChannels) of floating HV outputs, each supplying two anode lines (up to +4 kV), one strip line (up to +2 kV) and one cathode line (down to –2 kV) per each layer. Anode, strip and cathode voltages are linearly programmable with 12 bit resolution; they are independent, but the anode voltage cannot exceed the corresponding strip voltage by more than 2 kV. Each macrochannel powers one layer of Phi or Theta SL.

Table 1: Channel characteristics of the A877 remote board.

Max output current (short circuit) 100A

Voltage ripple < 10mV

Voltage monitor accuracy ± 0.5V ± 0.1% of setting

Current monitor accuracy ± 10nA ± 3% of setting

The three cables out of the A877 board enter a junction box where they are split and adapted into a couple of HV custom connectors for each SL in order to match the internal granularity that is:

1 connection per 8 cells/layer for Anodes

1 connection per 16 cells/layer for Strips

1 connection per 16 cells/layer for Cathodes

The system is controlled via Ethernet, through the TCP-IP protocol and with a Windows NT PC. A software, provided by CAEN, allows access to all parameters, monitor voltages and currents, while saving the values on files.

5 LV Power and Slow Control systemThe low voltage (LV) system has been specifically designed and realized in a custom rack box to meet the front-end electronics (FE) requirements: linear and floating power sources, noisily reference voltages for the thresholds and the complete slow control functionality to monitor and set FE parameters.

A PC controls the whole module via serial interface.

5.1 LV power and slow control hardware implementationThe system (Figure 6) is composed of two functionally and electrically independent sections: a low voltage source section to power the front-end electronics and a slow control interface.

The low voltage source section is composed of linear and modular powers, which supply the 5 V and 2.5 V required by front-end electronics boards. A further couple of modules generates the +5 V and –5 V, which power the test pulse box (see section 6). All power sources are equipped with crow-bar protection and output current limiters. The voltage is adjustable to accomplish the voltage fall along the cables. All voltages are floating and the reference ground point is the chamber aluminum structure.

The monitor and slow control system are implemented by a custom board based on a PIC 16C73 microprocessor [] that realizes the I2C interface, integrates an ADC, and supplies an 8 bit logical port with I/O direction of each line individually configurable. The board generates moreover the threshold voltages for the FE electronics of the three SLs, using an 8 bit DAC with I2C interface and operational amplifiers for buffering. A common 1.5 V reference voltage is generated together with the independent thresholds with 100mV of full scale. In order to minimize all possible interferences the I2C bus of the PIC is optoisolated in both directions. A custom board supplies this subsystem with the necessary power.

The system is controlled by a PC running Windows NT via serial interface; obviously, the serial bus is also

7

optoisolated, guaranteeing optimal isolation of the whole module.

Figure 6: Schematic of the Low Voltage power and Slow Control system.

5.2 The slow control softwareA C++ program running on a desktop PC using Windows operating system controls all test operations on front-end electronics. On startup it finds the current hardware configuration, i.e. the number of 16 or 20 channels FE boards in each superlayer, which correctly respond to the computer request. Each board is represented by a led, whose colour represents its status. A configuration text file is used to set the serial port, data directory, PIC reference voltage, and threshold setting.

A user-friendly interface allows to monitor the system parameters at a glance. The main panel is divided in chamber, superlayers and board panel. The superlayer panels display the board power voltages and the board average and maximum temperature. When these values are off limits an optical alarm is activated. The board box displays the FE chip (MAD) temperatures and the masks status of the selected board. The main panel allows to set mask at channel, board, superlayer and chamber level, and controls the threshold setting and the fast mask lines.

A second window displays the mask status of the whole chamber channel by channel. The user can control the I2C activation for test purposes manually; otherwise it is automatically activated by the program only when necessary, in order to reduce unwanted noise.

The program performs two tests regarding MAD temperature and single channel mask.

A button on the superlayer panel activates a process that reads the MAD temperatures. The results are displayed in two charts, temperature distribution, and trend as a function of the mad.

The single channel mask test is used to check the TDC channel mapping and the slow mask functionality. It also allows to verify the correct addressing of each front-end board with respect to its position inside the superlayer. After all channels are enabled and DAQ and test pulse are started, each channel is masked one by one in sequence with a defined time delay. If we plot the number of counts in the TDC as a function of channel number, the expected

8

result is described by a ramp.

Figure 7: Main window of the front-end control and monitor.

6 Test Pulse generation and distributionThe data analysis requires a reference t0 time independent from cables length and electronics delays. A proper system generates this reference time by triggering all acquisition channels in a same precise time: a charge of about 30 fC is injected via a series capacitor at the beginning of the electronic readout chain.

The schematic of the test pulse system generation and distribution is shown in Figure 8: two ECL signals trigger two groups of test pulse lines with minimal time jitter inside each group (below 1 ns). Signals reach the chamber through coaxial cables with the same length. Each cable is then split inside the SL, thus serving 4 boards. Test pulse trigger signals are generated by the DAQ control system.

9

Figure 8: Schematic of the generation and distribution of the test pulse signals.

7 The DAQ trigger systemThe trigger for DAQ is provided in two independent ways: the first with plastic scintillators for cosmic rays acquisition, the second with a free running pulse generator for noise and test pulse studies setting up to utilize all the data transmission bandwidth.

MB3 chamber

Scint 4group

Scint 1group

Scint 5group

Scint 6group

Scint i group

PM Left

PM Left

PM Right

PM Right

Scintillator up

Scintillator down

Phi FETh

eta

FE

Scint 4group

Scint 1group

Scint 5group

Scint 6group

Top view

Lateral viewPhi2Phi1

Theta

Figure 9: Schematic of the scintillators trigger system.

The cosmic trigger setup consist of 4 groups of scintillators (Scint1, Scint4, Scint5 and Scint6) placed under the chamber table each one made with 2 parallel slices of plastics scintillators read out in both sides by individual photomultipliers (PM). There are two scintillator groups parallel to the Phi wires, placed 50 cm underneath the table plane (Scint1 and Scint4, 250X27 cm2 area, 2 cm thick). The other two are parallel to the Theta wires (Scint5 and Scint6, 300X20 cm2 area, 2 cm thick), about 90 cm underneath the table plane. Scint5 is near the front-end side of the Phi superlayers, the Scint4 is near the Theta front-end side.

All PMs are powered by a CAEN SY127 system controlled and monitored by a PC via a serial interface.

10

PM Left Up

PM Right Up

discriminator Mean Timer

Scint UP

PM Left Down

PM Right Down

AND

Scint DOWN

Fan In/Out

TDC

Scint 1

Scint 6

Scint 5

Scint 4

OR

Cosmics Trigger

Timer UnitTP Trigger

Figure 10: Schematic of the trigger logic.

A block scheme of the trigger logic is sketched in Figure 10: two kinds of trigger are allowed; the first is built from a logical OR of the 5 scintillator groups and the second is generated by a double timer unit used in free running mode at 500 Hz frequency. The two trigger types can be selected via software or manually. In the first case each scintillator is read at the two ends by two photomultipliers (PM in the scheme). After the discriminator, the two signals from the PMs are fed into a mean-timer module [], which yields the mean time of the two signals. Then the two mean times of each couple are put in coincidence. The cosmic-ray trigger is given by the logical OR of the AND of each couple. Synchronization respect cosmic signals and time jitter determination are described in details in ref. []. Signals of all PMs and each trigger group are recorded with one of DAQ TDC modules [] and used in the analysis offline. The available trigger rate is about 150 Hz for cosmic acquisitions and up to 500 Hz for test pulse runs limited by DAQ system transmission bandwidth.

8 Chamber monitor software for DAQTo record the chamber characteristics and run conditions (superlayers ids, high voltage setup, front-end thresholds, environment parameters, etc.) automatically run by run on the data itself, a software running on a Windows PC, developed in Labview and successively compiled, has been interfaced with the DAQ monitor and control software (JRCS). The monitor software stores such information in an XML [] file, which is then published through an Apache Web Server.

The software controls the acquisition trigger type (cosmics or test pulse) via the digital port of the 6023 PCI board and informs the DAQ for event data classification: noise, cosmic rays or test pulse.

The limited number of TDC modules does not allow the acquisition of whole chamber in a single run so we group channels in significant regions, each having its own map: whole Phi1 and Theta SLs (map PHI1), whole Phi2 and Theta SLs (map PHI2), left halves of Phi1 and Phi2 and whole Theta (map A), and right halves of Phi1 and Phi2 and whole Theta (map B).

11

byte0 C

Chamber type (MB1..MB4)

Trigger Type (TP/C-0/1)

TPN Mp

byte1

Chamber numberMap A/B

Mc

byte2

theta number

Positive/Negative chamber

S

byte6 HV anode (LS 8bit, 10V step)

byte7 HV cathode (10V step)

byte8 HV strip (10V step)

byte9 Vth (100 mV fs)

byte10 Temp (0..64, .25 step)

byte11 P (872..1128 mbar)

byte12 Humidity (100% fs, 0.5 step)

byte14 O2 (MSB, 20% fs, 1ppm step)

Event Type (C/N/TP)

byte3

phi1 numberbyte4

phi2 number

byte5 A

Flag HV (sl1, sl2, sl3)

HV anode (MSB)Flag TH (sl1, sl2, sl3)

Flag global

Map PHI1

byte15 O2 (LSB, 20% fs, 1ppm step)

TT

byte13 Flux (100% fs, 0.5 step)

byte16 Pvalve (872..1128 mbar)

Figure 11: Information stored in the header of the run database.

A special little board with I2C interface is externally added to each SL during the assembly procedure and removed after chamber test in order to save SL identification number by setting binary switches. In this manner, SL ids can be read by slow control monitor software and automatically pass to the DAQ.

To save all interesting information on chamber status in the same file of TDC data we compact the information on 20 bytes of the database header of each run. The Figure 11 shows the information saved in the run header and their structure and accuracy. The header is passed preformatted to DAQ JRCS via the XML file.

For reasons of compactness, only one value for threshold, anode, cathode and strip voltage is recorded for the whole chamber. A system of flag bits (3 bits for threshold and 3 for HV voltages) allows to understand if the saved value is the same for all SLs. A seventh bit (the global flag) is the logical OR of the previous flags or it is on if, for some special reason, the saved information do not describe the chamber status completely.

That is a very efficient and simple way to integrate all necessary information in the data files: environment and chamber conditions are joined to data in a same file.

9 The Data Acquisition SystemThe Data Acquisition System is based on the CMS DAQ layout [], which is quite general and can be adapted to almost any kind of experiment [] []. Two general software frameworks have been developed over the CMS model. The XDAQ framework [] provides the basic behavior of the single components (readout units, event manager, builder and filter units) and the communication protocols to synchronize the readout and to read and merge events. The JRCS framework [] provides a Java based software infrastructure for Run Control functionality, including the interface to the XDAQ components and a Graphical User Interface with the basic facilities to control and monitor the DAQ.

9.1 Structure of DAQ systemThe CMS muon chamber validation DAQ (DT DAQ) structure is shown in Figure 12.

The main components are the Readout Unit (RU), the Event Manager (EVM), the Builder Unit (BU), and the Run Control.

12

Figure 12: The LNL CMS muon chamber validation DAQ.

The purpose of the Readout Unit is to read events from the front-end electronics, buffer them locally and serve them to the Builder Units upon request. The Event Manager assigns event identifiers to trigger signals, serves these identifiers to the BUs upon request and commands the RU to read data from the front-end electronics.

A generic I/O PMC module [] programmed to handle an interrupt source (the trigger) and two synchronization lines (system busy and trigger veto) manages the trigger. The EVM and RU blocks are implemented together and run on a Motorola PowerPC board (MVME2400, MPC750 processor), housed in a VME crate in order to access the front-end TDCs (32 channels KLOE TDC [] modules).

As shown in Figure 13, a custom board, controlled by a PC via the PCI 6023 digital port, selects the trigger type that drives the PMC module, triggers test pulse lines and generates delayed and synchronized common stop signals needed to TDC modules. Also a simple logic takes care of PMC Busy and Veto signals for pausing the acquisition during moving TDC data to PC.

PMC

module

33 shielded cables of16 twisted pairs

18 modules of 16+16 channels TDC

TCP-IP

VME crate

Trigger and TP custom unit

Cosmics TriggerTP Trigger

4 channels custom delay unit

TP2 trigger

18 equalized TDC common stop lines

PMC Veto

PC WinNTPCI 6023 Digital Port

PC LinuxDAQ control

scintillators signals

TP1 trigger

Trigger

Veto

Busy

MB3 Chamber

PMC BusyPMC Trigger

13

Figure 13: Details of the EVM/RU unit, trigger control logic and TDC modules.

Test pulse lines are triggered, if enabled by the DAQ control software, at a fix delay after the trigger (about 2 s) for a user-defined number of initial events (usually 2000).

All necessary delays are generated using a precise, four channels, analog module in order to reduce time jittering to a minimum.

9.2 The RU/EVM softwareThe RU/EVM software, running on the real time operating system vxWorks, is based on the XDAQ framework, which provides the generic behavior, while the interface to the front-end electronics, the readout operation and the trigger management are specific to the DT DAQ. The purpose of the Builder Unit is to receive buffers of events from the RU through the Event Builder Network (a Fast Ethernet switch), to format and then send them to the Filter Units for filter and storage purposes. BU and FU blocks are implemented together and run as a single multithreaded process on a commodity PC hosting the Linux operating system. The BU/FU software is based on the XDAQ framework, which provides the generic behavior, where the FU output has been specialized in order to store events, at the same time, on the Objectivity [] object oriented database, and on flat files. The storage of event on the Objectivity Database has been implemented by using the CMS ORCA (Object Oriented Reconstruction program for CMS Analysis) software framework []. Thus, events are immediately available to the monitor system that is based on the same framework.

9.3 The JRCS softwareThe DAQ behavior is controlled and monitored by the JRCS software. JRCS accesses the slow control web server when a “start” command is issued. Then it retrieves the provided information, parses and sends it to the Builder Unit. The BU can store it on the Objectivity/DB together with the acquired data. Due to the huge amount of data acquired per run, the related DB are automatically moved from time to time to a permanent and safer storage system provided by the CMS farm local storage facilities [].

10 The DAQ Monitoring SystemThe monitoring system provides detailed graphical information about the acquired data, in order to interpret the physical behavior of the chamber. All geometrical information and chamber characteristics are parameterized so the monitor can be used for different chamber types. In fact, it is used at LNL for MB3 chambers, at ISR CERN store site, and for beam tests.

The monitoring system main tasks are:

testing the functionality of the electronic chain, performed sending Test Pulse signals and computing the cell occupancy, the efficiency, the accuracy and uniformity;

verifying the noise rate of the chamber in absence of trigger;

obtaining the drift time signal performances with the cosmic trigger;

activating upon request a full event display of the chamber with reconstructed tracks.

Some technical details follow. The code is written in C++, and in the official CMS software framework, so it's developed in the ORCA3.2.1 TestBeams package. The monitor Graphical User Interface is developed using Qt 2.2.1 (and other facilities of LHCXX 2.0.1 package), while histograms, vectors and other mathematical tools are taken from both the IGUANA [] package and LHCXX. In the present configuration, the monitor runs on a commodity dual processor PC, running the Linux operating system.

The monitor reads a run, i.e. a collection of stored events written by the DAQ system. The histograms are displayed or printed in different pages. The set of information read from the run can be collected in a HBOOK n-tuple for further or much detailed analysis. Furthermore, significant information, for example the mean noise rate in every layer or the mean times, can be sent to CMS database from the monitor upon request.

The monitor is organized in several sheets. Every sheet displays, for the same dataset, different histograms regarding either the whole chamber, or the single superlayer, or the layers, or the single cell.

14

Figure 14: Flow chart of the monitor software.

A sheet displays the chamber occupancy, i.e. the number of hits acquired in each cell. The monitor can display either the total occupancy, or the occupancy inside or outside a given time window.

Another sheet shows the drift time histograms, of the chamber as a whole and of every single cell. The derivative of the histogram can be computed to obtain important information, i.e. the maximum drift time. The Mean time distributions are also computed for straight tracks.

A special sheet is dedicated to processing test pulse events. The aim of test pulses is to monitor the response (electrical connection) and noise of channels. The average test pulse time and the sigma are computed and displayed.

noise plots in different layers time histogram for the whole chamber

mean-time histograms hit histograms

DAQ (from TriDAS XDAQ)

Data Base Objectivity files

Reading from DB (H2 Application)

Collectioning HITS (DTBX Analysis)

Filling Histograms (DTBX Analysis)

Display plots (DTBX Monitor, Qt, Iguana…)

Minitor Ntuple

Further analysis

Raw data

ORCA

15

Figure 15: Some examples of plots and histograms visualized by the monitor.

Finally, a sheet is dedicated to the event display (Figure 16). Hit Cells are colored event by event. The position of the muon inside the cell is computed and shown with a given user drift velocity. The muon track across the chamber is calculated through ORCA routines, which fit the set of “impact” points of the muon, and displayed.

Figure 16: Tracks reconstruction in superlayers phi.

11 Conclusions – Future plansThe system described in this note is currently used at the muon chamber production site of Legnaro to test and validate the chambers being produced there before shipping to CERN. The system is working well and meets all required Quality Control tests on chambers.

A DAQ and Monitor System mirror is also being used in the CERN stockage area to check detectors after transportation. A similar DAQ and Monitor System was also used, in October 2001, during a test beam at the GIF (Gamma Irradiation Facility) facility at CERN. In this case, a muon chamber was coupled to a new RPC detector [] to verify the simultaneous response of the two chambers. Moreover, three beam chambers were also included to get information concerning the beam position. Both DAQ and Monitor system were updated to include both the RPC and the beam chamber readout with its histograms to check the response of the new detectors. Also the event display was modified with the aim of performing a full track reconstruction that would include information from all detectors: RPC, beam chamber and muon chamber.

We are now updating the monitor-analysis package developed in ORCA_3_2_1 to ORCA_7 framework. The first important implication is that we will thus be able to use all the resources of the most recently released ORCA reconstruction and analysis packages. Another important aspect is to be able to read DAQ flat files, both on and off

16

line, directly with ORCA routines, without saving them in Objectivity database. In the same environment, we are also developing and testing the BTI-TRACO-Trigger Board simulation. Our goal is to set up a complete monitor and analysis system for future tests, that will be useful when the data coming from both DT and Trigger Boards have to be monitored and analyzed.

17

References[] Nucl. Instrum. and Meth. A 336 (1993) 91-97, F. Gasparini et al., “Bunch crossing identification at LHC

using a mean-timer technique”.

[] CERN/LHCC 97-32, CMS TDR 3, 15 December 1997, The CMS collaboration, “CMS Muon Technical Design Report”.

[] 7th Workshop on Electronics for LHC Experiments , Stockholm, Sweden, 10 - 14 Sep 2001, CERN-2001-005, F. Gonella and M. Pegoraro, “The MAD, a Full Custom ASIC for the CMS Barrel Muon Chambers Front End Electronics”.

[] Nucl. Instrum. and Meth. A 438 (1999) 302-317, M. De Giorgi et al., “Test results of the ASIC front-end trigger prototypes for the muon barrel detector of CMS at LHC”.

[] CMS NOTE 1998/064, M. Benettoni et al., “Performance and Mechanical Tolerances Achieved with a Full Size Prototype of a CMS Barrel Muon Drift Tubes Chamber”.

[] CERN/LHCC 2000–38, CMS TDR 6.1, 15 December 2000, The CMS collaboration, “The TriDAS Project

Technical Design Report, Volume 1: The Trigger Systems”.

[] Report LNLINFN (REP) 241/99, M. Bellato et al., “Construction of the CMS muon drift chambers”.

[] CMS Note in preparation, M. Benettoni et al., “Test of CMS Muon Barrel drift chambers with cosmic rays”.

[] http://www.bronkhorst.com

[] http://www.panametrics.com

[] http://www.ni.com

[] http://www.caen.it, http://www.caen.it/nuclear/cms_muon.html

[] http:// www.microchip.com

[] Nucl. Instrum. and Meth. A 305 (1991), 488-491, A. Cavestro et al., “An analog mean-timer for long scintillation counters”.

[] Nuclear Instruments Methods Phys. Res. A 367 (1995), 418421, M. Passaseo et al., “A TDC integrated circuit for drift chamber readout”.

[] http://www.w3.org/TR/RECxml

[] Technical Proposal, N. 7, LHCC 9438, Dec 1995, CERN, The CMS collaboration, “The Compact Muon Solenoid”.

[] Report LNLINFN (REP) 185/2000, M. Bellato et al., “A Common Framework for Small Daq Systems: experience from Gasp, Prisma and CMS Experiments”.

[] Report LNLINFN (REP) 2001, L. Berti et al., “The Prisma Data Acquisition System”.

[] RealTime 99 Conference, Santa Fe, June 1999, G. Antchev et al., “A Software approach for readout and data acquisition in CMS”.

[] Proceedings of CHEP2000, M. Bellato et al., “Java Based Run Control for CMS small DAQ Systems”.

[] Proceedings of CHEP2000, G. Antchev et al., “Reconfigurable I/O interface for modern data acquisition systems”.

[] http://www.objectivity.com

[] CMS IN 1999/035, D. Stickland et al., “CMS Reconstruction Software: The ORCA Project”.

[] Proceedings of CHEP2001, C. Grandi et al., “CMS Grid Activities in Europe”.

[] http://iguana.web.cern.ch/iguana

[] http://www.ba.infn.it/~cms_rpc/activities.html