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