1 / 11

DOM Test Summary from String-18

DOM Test Summary from String-18. Azriel Goldschmidt, LBNL IceCube DAQ Software Meeting Oct 2002, LBNL, Berkeley. Overview. Pre-deployment Test Sequence Post-deployment “tests” Still to be done “tests”. Pre-deployment Test Sequence. DVM and Smoke tests “Get a prompt” test

patrickj
Download Presentation

DOM Test Summary from String-18

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DOM Test Summary from String-18 Azriel Goldschmidt, LBNL IceCube DAQ Software Meeting Oct 2002, LBNL, Berkeley

  2. Overview • Pre-deployment Test Sequence • Post-deployment “tests” • Still to be done “tests”

  3. Pre-deployment Test Sequence • DVM and Smoke tests • “Get a prompt” test • Low-level test: memories, etc • Mid-level tests: ADCs, DACs, HV control, single LED and flasher board • Cold tests • High-level tests: ~waveforms, discriminators • Analog output tests: HV, gain, fiber

  4. Pre-deployment tests Commentary and Lessons • Smoke+DVM: If it can’t be fixed in five minutes, it will take a LONG (NaN?) time to fix • Mature PLD (configurable with special cable) very desirable, same for boot-code • All communications tests limited to being able to operate/control DOM (proved sufficient) • DACs tests require a way to read back value (as in HV base case) to be meaningful

  5. Pre-deployment tests Commentary and Lessons (…continued) • Cold test: Important to check at various values of temperature range, not just extrema (all possible functionality should be tested) • High-level tests: were insufficient because of firmware/software limitations…cannot afford the same limitations for IceCube • Pulser injection was not available to emulate PMT waveform • Robust and reliable “surface/DAQ” system needed to ensure we are testing the DOM (!)

  6. Post-deployment “tests” • Stability: communications, rates, HV and gains • RAP tests: COMM ADC, systematics, resolution, clock stability • Time-stamping to UTC • Fast communications tests • Cross talk tests • Flashers tests • Local coincidence tests • FADC readout • Buffering:“almost IceCube data-taking style” tests

  7. Post-deployment “tests”Comments and Lessons • Anomalies could have been easily prevented if tests were available (bad ATWDs, missing connections, ringing, LC) • Weakest link: HV base • Timing: asymmetry in gains, unexpected effect from noise from HV base • Firmware development is ALWAYS more time consuming than one expects, define complete API early with ALL essential features • Flashers would benefit from more amplitude tunability (and single LED?)

  8. Post-deployment “tests”Comments and Lessons • The obvious and hardest: aim for testing conditions as close as possible to “reality” if you want to see ALL the wrinkles in hard/firm/software: temp, cable lengths, instantaneous rates, gain, DOMs/pair, etc

  9. Still to be done “tests” • Single LED: PMT transit time, SPE • Record data while communicating • Bit error rates (with fast communications) • Pedestal (with and without HV) • ATWD ping-pong (dead-time) • Feature extraction/Data reduction

  10. Evolving from an R&D effort to a true Test system • Tests evolved with R&D • Tools and systems for taking and looking and data also evolved (from excel, to perl, to paw, CAMAC, TestBoards, PC104, ISA, DOMCOMs, domboot, domtalk, domtest, domlogger, evolving applications and FPGAs, etc, etc)

  11. Conclusions • Lots of lessons gained from String-18 test experience: what to do and what not to do • We should be able to define a complete set of essential tests that ensure that requirements (for physics) are met

More Related