Versions Compared

Old Version 9

changes.mady.by.user Christopher O'Grady

Saved on

compared with

New Version 10

changes.mady.by.user Christopher O'Grady

Saved on

Key

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

...

  • pedestal can change depending on configuration integration time
    • could have continuous pedestal calculation (dropped shots get strange when integrating over shots: could drop many shots to get a dark image)
  • CDS: correlated double-sampling (removed baseline)
    • Phil asks: do we need to turn this off?
    • Lorenzo says noise will take a big hit if CDS disabled (maybe not a big issue at low-rate readout?)
  • Lorenzo isn't sure detector response is fast enough to reject MHz shots (10us OK, 1us tricky).  Harder to reject strong signal than weak signal.
    • different timing domains make it more difficult?
  • Dionisio says this MHz response is a new requirement.  Should be discussed with Angelo.
  • can the epix receive beam while it's being read out? ("gating")  answer: Maybe for epixHR (although Lorenzo/Dionisio will look to see if there is a sample-and-hold that may allow this), Yes for epixM (but need to investigate a bit more: could be issues)
    • fallback is to use "burst mode" to inhibit beam during readout (less efficient)
    • matt thinks that we'll have to inhibit the beam anyhow because response is different in different parts of the window
  • maybe we send a RUN trigger at the beginning and a DAQ trigger at the end which has the "last shot" timestamp which gets attached to the image?
    • matt suggests setting acqWidth (currently 32 bits), and send down a DAQ trigger with the last-shot timestamp, and a RUN trigger with start-shot timestamp.
      • since acqWidth isn't precise Matt suggests dropping the beam to control the exposure (acqWidth clock will be tied to accelerator clock for UHR and beyond)
    • Dionisio says that dropped DAQ triggers could be problematic.  Matt's suggestion sounds better to him.
      • not a big deal to attach the second DAQ trigger timestamp to the image data
    • Lorenzo says that electronics settling time is 20-30us, so controlling the camera on timescales below that is problematic (related to Matt's comment about dropping the beam to be "conservative")
    • frame include both timestamps but the "real" one (from DAQ perspective) is the last-shot timestamp
    • want to start again as quickly as possible

...