Page History
...
- 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
- 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.
...
Overview
Content Tools