• Created by Unknown User (phansson), last modified on Mar 18, 2014

Webex meeting for those not at SLAC: https://confluence.slac.stanford.edu/display/hpsg/Webex+connection+details

Agenda
  • News
  • DAQ configuration -  doc  
  • 1st/gimp L4-6 module discussion
    • Module behavior - link
    • Module testing results - link
  • JLab integration meeting 11am next Friday (replaces this meeting)
  • AOB



Minutes

 

DAQ configuration discussion

 

EVIO related

 - The full DAQ configuration will be saved to the data stream in a special evio bank in the beginning of a run

 Q (to Sergey):  The configuration will be saved as a text string in a “pre start” evio bank?

  •  SVT DAQ wants to dump/inject a “status” data to the data stream. What is the best option?
    •  Opt. 1: Save in every SVT event header. 

      Q (to Ben):  What is the size of the “status” data from SVT? Maybe it will be too large overhead to save for every SVT event.

    • Opt. 2: Save in new evio bank every X events (X ~1Hz)

      Q (to Sergey):  Can we save a “status” evio bank every X events only or do evio need the “status” bank for every event? If so, should we save an empty bank?

 

SVT DAQ configuration

 

  •  SVT control ROC pulls SVT DAQ configuration from file path in CODA run DB and parses configuration
  • SVT configuration will be a xml file specified as #include svt_daq.xml in the daq configuration file
  • CODA run mode decides what file path to use: we have to prepare a configuration file for normal running and calibration
  • We have to manually keep track of xml configuration files.
  • Rest of DAQ parsers have to ignore the SVT DAQ xml configuration

    Q (to Sergey):  Is there a size limit to the configuration file?
    Q (to Sergey): Do we have the option to pull SVT configuration from a separate DB or do we prefer to stick to the text file based method outlined above?

 

Logging/retrieving configuration

 

  •  The whole configuration will be in the data stream in the pre start evio bank in the beginning of run.
  • We will need to write programs to parse the pre start evio bank and parse the string to xml format.
  • Run time DB is likely not available

 

 

 Monitoring of “status” 


  •  We will have scripts that parses the data stream and “picks” out the “status” evio bank
    • Opt. 1 Use C++ scripts that parses to xml and write code to display the output
    •  Opt. 2 Use java monitoring (of ET ring if possible to pick out “status” bank efficiently)

 

Conditions DB

 

  • Need scripts that parses the data stream (running on evio files) and fills conditions DB through JAVA API. 
SVT Calibration

 

  • Baseline/pedestal calibration
    • CODA run mode selects “SVT baseline” configuration run mode (fixed, slow, rate triggers)
    • The SVT configuration pulled configure SVT without threshold applied
    • SVT needs slow fixed rate of triggers
       
  • Gain/pulse shape calibration
    • SVT needs slow fixed rate of triggers
    • Opt. 1 One CODA run mode for every calibration *step*
      • 0-7 for gain calibration, 0-64 for pulse shape
      • Each step has a different SVT configuration
      • We would need to take up to 64 runs. 

      Q (to Sergey):
      Can this be automated at higher level in CODA?
      Can we iterate through the calibration *steps* in pre-start level (send down different flags to change configuration) and SVT will keep a event header flag to now later what was happening at that event?

 

 


  • No labels