AMANDA-II TWR (Transient Waveform Recorders) System Overview




Goals of the TWR System
Architecture
Merging, Filtering, Archiving, and Satellite Transfer
Monitoring
Technical Specifications

The Transient Waveform Recorder system has 4 primary goals:

  1. Extend the integrated dynamic range by approximately a factor of 100 compared to the standard AMANDA DAQ (the muon-DAQ).
  2. Reduce the "discriminator" thresholds to 10-15mV for optical channels This improves the 1pe detection efficiency.
  3. Track baseline oscillations to reduce susceptibility to conditions that cause flary runs, or individual noisy PMTs due to inevitable drifts in baseline DC levels of the amplifiers.
  4. Develop software triggers to replace hardware DMAD majority and string trigger.

Future Goals of TWR system

  1. Replace RIO3 with faster PCI to VME bridge. This should lead to deadtimeless operation at 200 Hz.
  2. Verify performance of TWR data by comparing with mu-DAQ data. If TWR data gives the same or superior results, then de-commission muon-DAQ next season.
  3. Reduce PMT voltage and amplifier gains (SWAMP, ORB, ORM) to increase instanteneous dynamic range. This requires that the TWR system trigger by software, or replacing DMAD with modules that can go to lower threshold.
  4. Implement and test software triggers.

TWR System Architecture:

TWR configurationThe TWR system in 2003 consists of 72 TWR (SIS3300) distributed in 5 VME crates. Each TWR crate is connected to master crate via optical bridges. These bridge modules also contain a DSP for crate-level data processing. The DSP is controlled by FPGA codes developed by SIS and K.H. Becker. The TWR modules store 128 events in local memory. When the memory is full, two things happen: (1) a signal is sent to MBS software via the GSI trigger board to start readout of the TWRs, and (2) the TWRs switch to a new memory bank so data readout by MBS does NOT interfere with continued data taking by the TWR.

A Rio3 cpu in the master crate collected the data from the optical bridges, performs feature extraction, and event merging. It then writes the data to local disk in the ML380 Linux PC, which is transfered by polechomper to BOS automatically.

The TWRs digitize continuously, but data is only written to local memory if a trigger is seen. The trigger is provided by the DMAD, set to M=24. We do not read out string and SPASE triggers. If the muon-DAQ is FIRST triggered by the string trigger (which is expected since it can form earlier), then the muon-DAQ GPS and TWR GPS will be different by several microseconds.

The event times are determined by GPS clock. The GPS clock system was completely re-vamped in Jan 2003. We replaced 5 individual clocks with a GPS distribution system, developed by K. Sulanke (DESY). The signals from one GPS (time messages, 1 PPS, 10 MHz) are replicated and distributed to the new VME interface cards, developed by H. Leich (DESY) The VME interface was programmed to generate veto signals during the transmission by a VLF antenna installed about 2km from AMANDA-II. VLF transmits for 1 minute every 15 minutes at precise time intervals.

Merging, Filtering, Archiving, and Satellite Transmission:

Raw data from the TWR DAQ is transfered to BOS where it is merged with data from muon-DAQ. The combined data is filtered to reduce the amount of data transfered over the satellites. The reduced data subset consists of the following type of events (M is simple majority logic). The majority logic is calculated from Nch in the muon DAQ F2K files).

The merging and filtering process generates about 1 GB/day. The merged data is sent to a directory that is accessed by polechompter. The data is put in queue for transmission over satellite, but its priority is low compared standard muon daq data. Polechomper accesses the raw data and writes it to SDLTs. Due to lack of tapes, we are only making 1 copy of the TWR raw data this season. We are not archiving the merged data.

The merger program processes events at 90 events/sec per cpu, which is not much faster than the raw rate. To reduce the time to merge data, the merger first selects M=80 events before attempting to merge. Due to the low rate of M=80 events, the merging requires XX hours to process 24 hours of run time.

Polechomper checks for new files on the TWR-PC disk every 10 minutes. If a new file is detected, it is transfered to BOS via 1 GB optical link between MAPO and BOS.

Monitoring: The TWR raw data structure is converted to ROOT structures in the merging process. This allows the TWR data to be piped through the normal monitoring process this season. Several important histograms are produced to help the WOs verify normal operation and identify problems.

Technical Specifications:


 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Steve Barwick 
Last modified: Oct 30 2003