Modification History of AMANDA TWR

Menu:     Modification history for summer 03/04     Modification history for summer 02/03

       In 2003/2004, we had two primary objectives.  The first was to increase the data throughput so that the TWR system can trigger at much higher rates than in the previous year, and the second was to investigate possible hardware solutions to allow the formation of software triggers.  The system overview describes the system and changes to the TWR system in 2004.   The TWR04 is now reading at a trigger rate of 150 Hz ( and majority logic M=18), which is approximately double the rate (~90Hz) of the previous year.  Simulations show that detector sensitivity for physics objectives with low backgrounds can be doubled if the trigger rate is doubled.  Low background science objectives include the search for neutrinos from GRBs, the search for EHE diffuse neutrinos, and episodic emission from point sources. In essence, the AMANDA-II detector is 2x better than it was last year for these science goals.  The TWR readout is capable of 230 Hz of deadtimeless readout, but data traffic is prohibative at this time.  

• Last year, we demonstrated that the TWR system achieves an integrated dynamic range of 5000 photoelectrons by including the afterpulses from the initial burst of cherenkov light.   Timo adjusted the delay so  that there is better uniformity in the readout so that every channel provides ~7us for the observation of afterpulses. The second objective was to initiate tests of the hardware for software trigger development.  Wolfgang tested new FPGA firmware from SIS, the company that supplies the TWR modules.  The new firmware performs feature extraction in the TWR itself, prior to the readout by the DSP, so the VME bus can handle the continuous stream of waveform fragments and ultimately build an event within one or more cpus.

• Hardware and Firmware upgrades in 2003/2004:  The RIO3 VME cpu (300MHz) in the master crate was replaced by a VME to PCI bridge, which connects to a Compac DL380 dual cpu, running at 1.4 GHz.  The local hard disk capacity was increased to 140GB, which provides local storage for about 3 days of data.   Instead of performing the feature extraction within the RIO3 cpu, the current system uses new firmware, written by Wolfgang Wagner,  in the DSP (digital signal processor) to extract features in the waveform.  Therefore, the PC computer can spend more of its resources building events instead of extracting features in the waveforms.  During 2003, we developed more efficient requirements for the waveform extraction routines so that the bytes/event decreased by a factor of ~50% relative to TWR03.  The waveform extraction routine was streamlined to fit in the DSP memory limitations.    The MBS software used in TWR03 to readout the data did not support the VME-PCI bridge, thus new software was written to readout the data and write to local disk.  Consequently, TWR04 operation and interaction with the muon-DAQ is more straightforward than TWR03. Operators can add one sentence comments to the log file (which contains error information diagnostics as well), so users can describe the purpose of the run.  We also made additional improvements to the TWR04 system.  First, the trigger distribution is distributed via the VME backplane rather than the logistically cumbersome NIM fanouts. It also improves long term reliability.   We increased the number of active channels to 597, up from 576 in TWR03.  This now includes all functioning OMs with the exception of those on string 17.  We have a more complete stock of spare components and replacement modules compared to last year.  Timo M. adjusted the programmable trigger delay in the TWR system so  that there is better uniformity in the readout. Therefore, every channel provides ~7us for the observation of afterpulses.

•  Software and Data Handling upgrades in 2003/2004:   The prodigious amount of data generated by the TWR system strained the data handling procedures in 2003.  Therefore several upgrades to the data handling procedures were implemented this summer season.  The TWR merging software was extensively re-written to alleviate data traffic on the network in BOS.  The TWR data file names now contain timing information that indicates the start and termination time of each file.  Instead of reading the whole file to determine this information, the merger software has quick access to this critical information.  The merger first selects only the high priority events ( this year, high priority events are selected when the number of OMs with waveforms is larger than 120) to reduce the data traffic generated by the TWR. TWR-specific monitor files are produced by the initial filtering program which is available for display by the AMANDA monitoring software written by Jens Ahrens.  The merged data format has been changed to include the baseline level of each fragment, which gets appended to the end of every fragment.  Finally, the raw TWR data is automatically compressed by the SDLT tape drive, so no cpu-intensive gzipping is required.   While not specific to TWR, a new batch queuing system was installed this season so that filtering, merging, and archiving are distributed to all available computers in BOS.  Therefore, computer resources are more fully utilized and TWR specific processing is more easily accomplished.  At this point, the computer resources are sufficient to handle all of the data related tasks in 2004.  There are sufficient SDLTs to provide 1 complete record of all data acquired in 2004.
  

• 597 OM channels (nearly all usable channels - no OMs on string 17)
• 6 VME crates containing 14 TWR, 1 DSP, 1 VME to VME optical bridge
• M=18 trigger from DMAD (no string, no SPASE;  we expect to include multiple trigger next season as a fallback to software trigger)
• Trigger rate ~ 150 Hz, virtually no dead time
• Data rate - 68GB/day uncompressed, 34 GB/day with hardware compression on the SDLT drive
• TWR data archived to SDLTs (~100 GB/tape)
• High multiplicity merged data sent via satellite (1 GB/day);  N_OM in event >120
• Pre-scaled M=24 merged data sent via satellite ( 2.5% of the M=24 triggers)
• 1 raw data file containing M=18 triggers

Modification History for summer 02/03:

12/30/03 Removed AM-A, installed VME crates for TWR system. Installed TWR DL380 computer on network. Installed 576 lemo cables between TWR and SWAMPS and ORBs. Connected to fast out.

1/23/03 Installed crate 5 of TWR system. Re-arranged ~40 lemo cables to each channel. Removed cables from string 17, dead OMs, and optical channels that are now readout as electrical.

1/30/03 Solved problem with occasional crashing of TWR system Problem was in DSP code

2/05/03 Read-out of all channel implemented in MBS. (Prior to this only 4 VME crates of TWR channels were read-out, even though 5 VME crates were connected to channels.

2/07/03 Added two TWR modules to bring the number of channels to 576. Re-mapped cables to ~30 OMs to include Strings 1 and 2.

2/11/03 Discovered that many waveforms were exact duplicates. Error traced to logic of DSP code. New code developed by SIS and Karl Heinz on 2/11, implemented by W. Wagner, 2/11. New code was certified to work by W. Wagner on 2/11.

2/12/03 Discovered error which caused blank waveforms on approximately 30% of the valid waveforms. Error randomly affected all OMs. Problem traced to improperly set bit in TWR (this was a new bit that was not documented in the manual we have at pole. It was only discovered in conversations with SIS. The latest manual has this discription).

2/13/03 Adjusted thresholds of each channel so that P/V (using integrated charge) is visible, if possible. Prior to this the electrical thresholds were 180mV, much too high. The reason for the initial high values was to keep the data rates small. Adjusted delay in start time for each TWR module. Goal: set delay so trigger peak (the narrow line in LE distribution that is generated when the OM is the module that forms the M=24 trigger) in each OM is about 3us after the beginning of the waveform.

2/14/03 Put TWR system in final state for winter operation.