Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • need burst mode (no beam outside integration window)
  • daq needs to think about timestamping requirements in burst mode
  • longer integration requires better cooling (Chris K. suggests limit of 400us integration? maybe 800us? Angelo thinks above >100us for epixM could be problematic, but needs testing)
  • different running modes require different calibrations (pedestals, gains, offsets)
    • need to have set of standardized conditions to choose from (requires psana support)
  • Needed May 2023
  • Need to know if epixM needs better cooling (there are limits to what can be done)
  • Action item: test longer integration times for epixHR and epixM (400us or 800us). (2 weeks?)
  • Action item: Andy/Georgi provide a few use-cases
  • Action item: Detector group produces a list of examples that "make sense" e.g. frame rate vs. deadtime and noise issues
  • Action item: DAQ/analysis group figure out timestamping requirements in burst mode

DAQ Timestamping Requirements

Discussion with Matt, Valerio, Chris on April 14, 2022

Ascii-art timing diagram:

Code Block
------------BBBBB-----------BBBBB-------
epixtrig  R       D       R       D
hsdtrig     DDDDDDD         DDDDDDD
acqwidth    /---\           /---\

time ---->

Legend:
R=readout trigger (start acqwidth integration)
D=daq trigger (do readout)
B=beam

How flexible are we?
- The D for epixtrig has to be the same as the last D for hsdtrig because
  of Ric's EB requirement.
- B's have to contained within acqwidth
- R must come before acqwidth
- can have extra triggers with no beam after acqwidth, but doesn't help anything

when we're not running always send R to keep camera temperature stable

original proposal:
- we use the epixtrig D timestamp to label the event, and also include R timestamp in the data
- mona would use the epixtrig D timestamp to mark the end of a psana batch that gets sent to
  1 core (allows the core to sum up the appropriate events to get I0)

question: now that we're using burst mode, can we have a simpler timestamping scheme?
- matt suggested that we could look at the timing system sequence data to see when the end
  of a burst
  o minus: we already have to timestamp epix with D (no matter what). original proposal
    feels "self contained" with the epix detector. only adds complexity.

conclusion: feels like we should stick with original proposal