30 likes | 120 Views
Trigger and DAQ – some notes external vs internal has impact on DAQ synchronization needs external trigger ensures to large extent that eventIDs are the same in the CU and ancillary systems
E N D
Trigger and DAQ – some notes • external vs internal has impact on DAQ synchronization needs • external trigger ensures to large extent that eventIDs are the same in the CU and ancillary systems • with external trigger the systems can run with parallel DAQ and simply be synchronized offline by merging separate data-streams (note that g-tagger already has a working DAQ, while TRD has to be written from scratch) – see slide 3 for an example. The beam structure is relevant for this operation and is such that we might be able to setup a complete chain of analysis/merge using the idle time between spills • some events can be lost or badly assigned even with external trigger (high level of buffering in the CU, probably also true for g-tagger readout) - a simple way to overcome this issue and synchronize the data streams is to record the start-spill signal from PS/SPS to assign events to each spill, and merge data streams only for events whose time stamps within a given short time window • will need a way to either veto ancillary systems when the CU is busy or make sure the time based sync work with high efficiency (in my experience it should; the AGILE calibration is now going on in Frascati; synchronization betweeen AGILE and the photon-tagger is based on GPS time stamps) • internal trigger is useful to study self-trigger performance vs beam rate does not need any external reference system for synchronization • internal trigger needed to measure CU self-trigger efficiency? • if CU is operated in self-trigger we only need to compare # of events with an external system of scintillators (time-stamps are enough?) • can we do the same study by operating in external trigger and study the trigger primitives inside the GASU (TKR 3-in-a-row, CAL-LOW, CAL-HIGH) for each external trigger?
Hardware needs • Electronics • goal: develop readout scripts on a small-scale system (1TKR-1CAL-1GASU) to be assembled asap (TKR16, CAL-module, GASU), can start w/o GASU for learning how to read CAL but willrequire a GASU for final readout (the sooner the better) • EGSE TEM and TEM/PS in Italy are good for CAL readout? Who can we contact to cross-check that? Do we need a PDU? • organize visit of key people to SLAC (Luca B. et al for INFN, Claus for SLAC?) • Mechanics – possible integration scenarios • full integration in Italy • development of support/rotation mechanics for CU with mass simulators (can start very soon! The same mechanics can probably be used for strict integration) – then strict integration of modules at SLAC using SLAC facilities • In any case will need 4x1 grid and mass simulators at INFN asap • organize visit of key people to SLAC (Sandro, Saggini, Bellardi for INFN, Fouts for SLAC?)
Particles ~400ms Magnet cycle Intensity Possible setup for acquisition SPS master cycle ~14s (details depends on SPS setup – we may have 2 spills/cycle) can we do this within spills? To what extent? Offline beam test N-tuple SVAC basic n-tuple + ancillary data (at least part ID and E) Ancillary recon (g-TAG recon work within spills) part ID: g/e-/p/p g energy (dE/dX?) Ancillary raw data stream 1536 Strips PH (4 Si planes) Max 32 straw tubes PH Few PMs Event Time-stamp PS/SPS spill signal time-stamp g-TAG TRD Cerenkov Data streams merge event time-stamps within given window for every spill (as defined by PS/SPS spill signal) LAT recon External trigger Internal trigger • Ancillary systems Online externaltrigger efficiency trend • tagger/TRD diagnostics Tracks in tagger Si beam profiles Si hit multiplicity Si PH distribution …. LDF file CU Online TKR, CAL standard plots Meaningful plots for specific study (backsplash, PSF ….) CU