1 / 19

Preliminary Results from eDHCAL Pre-Tests at CERN - Calice Collaboration

This presentation summarizes the early results of eDHCAL detector tests conducted at CERN by the Calice Collaboration. Topics covered include detector configurations, testing setups, data acquisition procedures, performance evaluations, and initial findings related to muon efficiency, data quality, and event analysis. The presentation emphasizes the experimental setup, data collection methods, challenges encountered, and promising outcomes achieved during the testing period.

arissa
Download Presentation

Preliminary Results from eDHCAL Pre-Tests at CERN - Calice Collaboration

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. Vincent Boudry LLR, École polytechnique CALICE Collaboration meetingU. of Manchester 08/09/2008 Pre-results for the CERN PS testsof the eDHCAL

  2. Warning!! • “Old Style” Adventurous Test period • Analogic Logbook • Do-It-Yourself style • very few shiftees • Team crew • Robert • Imad • Marc • Emmanuel • Vincent EVERYTHING should be labelled ”VERY PRELIMINARY”

  3. Detectors eDHCAL TB pre-results— Calice Coll. Meet. @ U. of Manchester 08/09/2008 • 4 (5) 8×32 cm² GRPC • Semi-Digital HCAL (GRPC)‏ • High granularity (1 cm²), • 2 thresholds • ILC-like electronics • embedded ReadOut Chips with memory • low consumption (power pulsing)‏

  4. Beam periods V Imad eDHCAL TB pre-results— Calice Coll. Meet. @ U. of Manchester 08/09/2008 • PS T10 initially 10—17 july • ⇒ 17—24 july with the EUDET telescope • + 3 additional days in agreement with DEPFET • PS T9: 28/07 — 04/08

  5. T10 & T9 Set-ups eDHCAL TB pre-results— Calice Coll. Meet. @ U. of Manchester 08/09/2008 • V Imad

  6. T9 Set-Up eDHCAL TB pre-results— Calice Coll. Meet. @ U. of Manchester 08/09/2008 • Programme: • Test of a wide RPC: 100×35cm² • readout with 4 PCB ⇒ ~32×32cm² of readout (1cm² pads)‏ • Complement Pion data with 1 + 2 λ of W • Readout chip testing: burst mode, power pulsing • Status • Installed • Commissioning (gas) & waiting for stable beam...

  7. Data taking (DAQ)‏ • CERN PS T10 & T9: 0.4s spill every 48 or 33s (day/night cycles). • low part density (punch through π's)‏ • 4 HardRocs managed by 1 FPGA × 3-5 • Running mode: single event with auto trig + BUSY logic & automatic RAMFULL recovery (⊃ BUSY signal)‏ • USB readout: LabView (R. Della Negra) + libDhcal (C. Jauffret) • asynchroneously RO of all cards (”LabView thread”)‏ • 2 commands: • polling on each card (”every ms”)‏ • readout order • Data re-formated on PC for a fixed length (~ for ”memory allocation”)‏ • Storage as such in binary files • dominated by 0's ⇒95% of reduction by std bzip2

  8. DAQ Performances: Bad start • “modified set-up for electronic tests, modified for TB” • last minute changes (command reduction, RAMFULL clearing)‏ BUT working!!! • Maximum rate 5 ➚ ~20 Hz for a low volume of data(≤100Hz: single board with no data) • event for muons / punch through pions ⇒ dominated by noise • maximum volume/card: • 20 kbit × 4: 80 kBits @ 1 MHz ⇒ ~ 8 ms • Speed limited by the USB connection establishement ~16ms, • due partly to the the preparation of data (no pipelining)‏ • USB link: ➚ 1 MB/s with one card • not fully understood... ”Much better than expected”

  9. Data volume • Very successful data taking: • T10: ~260k trigerred evts taken in 10 days • (+ 500k of noise events)‏ • T9: ~80k triggered events • In addition: Analog readout of 1 of the boards (??? events)‏

  10. First results eDHCAL TB pre-results— Calice Coll. Meet. @ U. of Manchester 08/09/2008 muon • Efficiency (single punch through π's)‏ • 0 → 45º • Shower developpement(with SS plates): π's pion

  11. Data Quality eDHCAL TB pre-results— Calice Coll. Meet. @ U. of Manchester 08/09/2008 • Basic ROC parameters • pile size • # hits • ... • Timing • asdf • sdaf

  12. DHCAL single event + auto-trig DAQ signals — EDAQ meeting 24/06/2008 (EVO) • All the hits (thr0 OR thr1) are recorded with a timestamp • on RAM full (128 evts) of one of the ROC the memory is cleared • The timestamp (== BC ID @ 5 MHz) is local to each card • Reset on Card Reset OR RAMFull • A counter @ 40 MHz in the FPGA measures the time difference between the last internal trigger (of any of the ROC) and the external trigger • The ext. trigger stops the acquisition and the data is transferred from the ROC to the PC time = (BC-LastBC) × τBC – DiffCounter × τDiffCounter

  13. DHCAL single event + auto-trig eDHCAL TB pre-results— Calice Coll. Meet. @ U. of Manchester 08/09/2008 Card 3 Card 3 ASIC # (4 / Card)‏ Card 2 Card 1 time

  14. DHCAL single event + auto-trig DAQ signals — EDAQ meeting 24/06/2008 (EVO) time = (BC-LastBC) × τBC – DiffCounter × τDiffCounter time ASIC # (4 / DIF)‏

  15. Analog data eDHCAL TB pre-results— Calice Coll. Meet. @ U. of Manchester 08/09/2008 Asics No real work done yet No combined digital/analog R/O Pedestals Ped subtracted

  16. Data with EUDET pixel telescope eDHCAL TB pre-results— Calice Coll. Meet. @ U. of Manchester 08/09/2008 • 2 independent DAQ's • → Shift of 1 evt • small surface: 7×7mm² • Track precision: ~5 μm (???)‏ • Thank to JRA?? People

  17. Data with EUDET pixel telescope eDHCAL TB pre-results— Calice Coll. Meet. @ U. of Manchester 08/09/2008 • Correlation seen (once) for 1 run between 2 pixels Preliminary • Proof of possibility • Need some Clean-up • multiple tracks • multiple hits • ... • And real analysis

  18. Data format & storage: • Binary storage NEEDS some markup & redundancy in case of pbms • zero suppression → no fixed length... • Consistency of Data: • number words in headerS (all headers) & possibly versionmany versions for testing • End word ⇒ recovery possible • Eventually CRC ? ⇒ local/missing bits • Internal counters!!! (trigger numbers)‏ • Idem for all stage of data (DIF)/event (was missing here) ADDITIONAL: possibility to verify FW versions at all stages ⇒ ⊃ list of commands • Exemple mixing of events: • asynch. readout of cards ⇒ event mixing (10% of total)‏ • evt 1: card 2, 3, 1; evt2; card 2; evt 1: card 4; evt 2: card 4,3,2, .... • ⇒ recovery using a “trigger counter” on the cards

  19. Learning from the 1rst DHCAL TB DAQ signals — EDAQ meeting 24/06/2008 (EVO) “First experience with a detector embedded RoC with local memory in test beam” Set-up: • CERN PS T10 & T9: 0.4s spill every 48 or 33s (day/night cycles). • low part density (punch through π's)‏ • 4 cards of 4 HardRocs managed by 1 FPGA • Running mode: single event with auto trig + BUSY logic & automatic RAMFULL recovery (⊃ BUSY signal)‏ • USB readout: LabView (R. Della Negra) + libDhcal (C. Jauffret) • asynchroneously RO of all cards (”LabView thread”)‏ • 2 commands: • polling on each card (”every ms”)‏ • readout order • Data re-formated on PC for a fixed length (~ for ”memory allocation”)‏ • Storage as such in binary files • dominated by 0's ⇒95% of reduction by std bzip2

More Related