DAQ: Status and Plans

David Nygren

Berkeley Collaboration Meeting

March 21, 2005

DAQ Elements:ns s ms s

Hardware/firmware/Software

• DOM: Main Board + HV + flasher board• Quads, LC links, connectors, stubs,…• DOM Hub: DOR card, DSB card, SBC• Master Clock: GPS + fanout to DSB• String Processor, Triggers, EB,…

String 21 Summary

• Performance is generally excellent!• All DOMs operational, returning good data!

60 In-Ice + 16 IceTop = 76 working DOMs! All DOMs timed up to <5 ns rms! Freeze-in noise rates measured!

Downward-going ’s observed in good agreement with shower planes in IceTop!

Electrical personalities of all cables known!

DOM Main Board

• So far, performance meets expectations– Very few unexpected “features”– Clock drift: typical RAPcal t << 2ns/s

• Not yet using “final” FW/SW in DOM• Test FPGA + SW enhancements:

– Engineering format, no data compression.– Software-assisted Local Coincidence.– Dead-time close to that expected w/firmware.– Nearest-neighbor LC performing well.

DOMAPP FPGA Status• API stable• Features requested (overview) Implemented

– Data Acquisition (ATWD, FADC, …) – Data Compression (road grader)

– Calibration (Front-end Pulser, Flasher Board, …)

– Ratemeters (Count Rate, Supernova) – Communication (supplied by K.-H. Sulanke) – Local Coincidence (Simulation work in progress)

So far, above Features were simulated for basic functionality and tested on a DOMMB

DOMAPP FPGA Verification

1. Simulation; Basic functionality

2. Run on single DOMMB in IceBoot

3. Simulation; Verify specs

4. Run on DOMMB in IceBoot to verify Specs

5. HAL integration test (Arthur Jones)

6. Software integrations tests, … (Software People)

The DOMAPP FPFA can be used for software

development before items 3 and 4 are finished.

Data Compression

• Three different algorithmic approaches are being actively developed now:– “Road grader” - LBNL– “Wavelet” - PSU– “Impulse” - Bartol

• All appear to work well, with different advantages and vulnerabilities.

• Not yet clear how all this will evolve…

Quad Performance• Cross-talk effects are generally quite small.• Major exception is Q2, at top of string.

– Q2 appears to have very large cross-talk– Much better performance if one pair is quiet– Cause and problem location still unknown– Bit errors occur at ~10-5 , other quads < 10-9

– Randy Iliff leading effort to investigate issue

• Much has been learned by examining the leading edge of RAPcal pulses - (DC, RGS)

RAPcal pulses tell the story

Pre-pulse baseline =

19 samples before rising edge

Flat, low-noise baseline small rms

Tipped, distorted, noisy large rms

| |

Zero-crossing: best timing

QuickTime™ and aTIFF (LZW) decompressor

are needed to see this picture.

Q3 - Well-behaved rms distributions

QuickTime™ and aTIFF (LZW) decompressor

are needed to see this picture.

Q12 - Looks great: rms ~0.35 counts

QuickTime™ and aTIFF (LZW) decompressor

are needed to see this picture.

Q2 is Qualitatively Different: Bimodal + Outliers

Quad Cable Signals

• In 13/15 quads, the pairs display very similar RAPcal rms distributions

• U DOM baseline “bounce” (a non-distorting level shift) is significant

• T DOM and DOR “bounce” is small

• Reflections are observed at DOM end

• None of these is a serious problem

Communications: DOR DOM

• Testing @ pole verifies good communications performance: (BER = bit error rate)• BER < 10-9 before retransmission (except Q2).• Q2 not presently regarded as super-urgent issue

• Integration of GPS time information into DOR and DOMHub software has been accomplished. • All hits now corrected to UTC (<5ns).• Q2 DOMs have generally good time calibration

Surface DAQ

• Tests of DAQ components and DAQ control underway on SPTS (@PSL).

• Data and trigger message interface classes defined and implemented for complete DAQ chain (string processor to event builder).

• These classes integrated into a simple framework called:

Monolith• Consumes DOM data from FAT test archives or from running TestDAQ

(@pole).• Provides implementation framework for executing inice and icetop

triggers (running @ pole).• Producing triggered event stream files @pole for transfer by data

handling (ref. triggering workshop)

DOM Hub & DOR rev 0,1

• DOM Hubs at pole use DOR rev 0– Electrical performance very good, but…– Only 30 DOMs/Hub, not 60

• DOR rev 1 now available, ~ 20 cards– Better power switching, power filtering,…– 60 DOMS/hub– Testing procedures OK, final debugging underway– Schedule tight, if trouble occurs

• DOM Hub rev 2 now available, new SBC,…

Master Clock = GPS + Fanout

• Need high quality GPS, f/f < 10-11/s, to exceed stability of DOM local clocks

• DOM Hub Service Board (DSB) accepts GPS signals and fans out to 8 DORs

• GPS time-string error rate: ~ 1% !!– Cause unknown, seen at SPS & UW: SPTS, DFL– Jerry Przybylski (LBNL) is lead debugger

DAQ Milestones PY3

DOM MB Production: March 18

– Fabrication started ~ March 18– On track to make ≥ 900 MB for current PY – Fabrication, HASS, “Burn-in”, integration,

and test flow appears credible

DAQ Milestones PY3

DOR Rev 1 Hardware and Firmware:

March 18

16 DOR Rev 1a cards with Rev 1 FW debugged and ready for the start of MB production testing beginning March 18.

DAQ Milestones PY3

• DOR Rev 1 HW & FW for DFL FAT: March 28

A minimum of 4 DOR Rev 1’s will be delivered to PSL, along with 2 additional DOMHubs, ready for the start of the trial FAT run by March 28.

DAQ Milestones PY3

Deployment and operation of DAQ Software components on SPTS & SPLTS:

April 20

By this date, we will have deployed functional DAQ components onto these systems and performed initial network connectivity and throughput tests. This version of DAQ components will be operable under DAQ control but will not contain complete versions of experiment code. April 20.

DAQ Milestones PY3

Debug and Repair GPS Time-string at PSL & Pole: May 1

The GPS ASCII time-string is intermittently found to be corrupted when read by higher-level DAQ. This issue will be understood and a solution implemented both at the Pole and at PSL by May 1.

DAQ Milestones PY3

Unit testing of individual DAQ Software components: Present – May 20

During this period, all DAQ components will individually tested to verify their correct operation on simulated data. As components become mature, they will be tested in pairs using simulated data and Pole TestDAQ data. This period will be followed by a DAQ wide code/feature review. Present – May 20.

DAQ Milestones PY3

MB FPGA firmware (“Final FPGA”) integrated with DAQ SW: June 1

The FPGA FW will have been through an initial round of test and debug with the appropriately updated HAL and DOMapp. At this point, the new FW will be integrated with beta versions of the remaining DAQ components (i.e. all features for this year present and functional; but with additional debug and test anticipated) and begin final system integration testing in the SPTS. This will start on June 1.

DAQ Milestones PY3

Integrated version of DAQ Software on SPTS:

July 31

At this point, all DAQ components will be fully integrated into a single system and running reliably @ SPTS and SPLTS. Testing will have included both acquisition of real DOM data as well as injection of simulated and Pole TestDAQ data into the system. July 31

DAQ Milestones PY3

GPS Master Clock Distribution System

August 15

LBNL will design, build and test the Master Clock Distribution System. It is envisioned that this will be the final implementation version, sufficient to drive 95 DOMHubs at the Pole, and provide 10MHz, 1Hz and ASCII time-string to the Amanda counting house. August 15

DAQ Milestones PY3

Experiment Controls SW: August 31

The full Experiment Controls SW release will be integrated, tested and debugged to the maximum extent possible on the LBNL SPLTS prior to its being deployed on the SPTS at PSL for final integration with DAQ and Online. August 31

DAQ Milestones PY3

DAQ Software final release for operations at Pole:

September 30.

At this time, DAQ Software will have been integrated tested and debugged with On-line and Experiment Control. While bug fixes and last minute changes will be addressed as needed, this release will contain the baseline feature set for next year’s deployment. September 30.

Summary

• Last project year:– DAQ HW/FW/SW team pulled together to

make possible a rapid and detailed assessment of string 21peformance.

– Tremendous effort by all involved!

• Current project year:– Coherent plan for DAQ SW/FW exists– Must be ready for multi-string scenario!