...

• 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

Third Meeting

April 28, 2022

• DAQ wants: a run trigger (always running), acq-width, DAQ trigger.  NEW: Image needs to be timestamped with the DAQ trigger timestamp.
  • action item for DAQ: if we're running "normally" (no integration) what needs to change on the DAQ end?
  • need to have run trigger timestamp in the data passed back
  • acq_width has a precision of 10ns (detector clock).  small compared to 1us time between shots, so should be precise enough to identify shots, even with clock-domain-crossing jitter
• Dionisio looked at HR longer integration times: boards have just arrived back.  perhaps done in next 2 weeks.
• Lorenzo looked at M longer integration times: could only study up to 20us because firmware hard to change.  measured noise and pedestal shift and extrapolate.
  • when can he go to longer times? needs prototype board. few months.
  • andy wants to distinguish at the 1 photon level, ideally half photon level.  800eV photon is 200electrons.  Georgi was 285eV, so 85 electrons so 2-sigma above the 35 electrons lorenzo predicts at 400us integration time.  Georgi is OK with it since they're not interested in single photon information when integrating.
  • may have better noise performance with next-gen boards
• Andy Aquila use-case: metric: number of photons per pulse times rep rate (number of photons per second)
  • spectrometer is only use case
  • expects shorter integration times
  • low fluence (1 photon per pixel per shot) (~100 photons per 1000 pixels).  integrating over 100-300 shots would be fine.  maximum occupancy is one photon per pixel per shot.
  • probably run at 300kHz max
  • dionisio: in high gain 400us (high gain), less in medium gain
• Georgi use-case:
  • is it beneficial to integrate?  maybe not.  Chris K. argues yes: since the beam rate helps so much, vs. the noise penalty
  • not important to see single photons
  • important to know which pulses contributed to image
• For deadtime vs. framerate: always have readout deadtime
  • livefraction=(integrationtime-20us)/(150us(readout time)+24us(presampletime)+integrationtime)
• there may be limitations on what the accelerator will allow the experiments to do vis-a-vis beam-kicking (e.g. the dump can't take the full beam-rate)
• could timing system put sequence in the config object?  can't trivially put the sequence-generating-code in the config object, but can see the result: the event codes in the timing-system data.

To do list:

• epixHR noise measurements vs. integration time
• Longer term (months) epixM noise measurements vs. integration time
• make sure not too much has to change for DAQ between integrating-mode and "normal" mode
  • camera shouldn't change
  • just have to switch between running a sequence and normal running

DAQ Timestamping Requirements

...