1 / 2

Trigger and DAQ – some notes external vs internal has impact on DAQ synchronization needs

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

mirari
Download Presentation

Trigger and DAQ – some notes external vs internal has impact on DAQ synchronization needs

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. 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?

  2. 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

More Related