...

• 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.

...

Slides from Lorenzo showing behavior of epixM noise vs. integration time (up to the 20us he could currently reach):

To Do List

• epixHR noise measurements vs. integration time (Dionisio will email out)
• 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
• next meeting will not be held until we have noise measurements from both epixM and epixHR (waiting some months for new epixM hardware).

DAQ Timestamping Requirements

...

conclusion: feels like we should stick with original proposal

Normalization for Integrating Detectors

We typically accumulate shot-by-shot measurements of intensity from BLD, for instance, to use as normalization for the exposure of the integrating detectors.  Deadtime will sometimes result in the loss of some of the events that contribute to the integrated normalization.  How do we estimate this loss?  The XPM measures deadtime, but it is not added to the science data in any way.  One possibility is to capture the total deadtime (lost events/total events) at EndRun or EndStep.  Another possibility is to capture that number for a given trigger.  That could involve adding the deadtime numbers into the timing segment level, for instance, by modifying the XPM to broadcast those numbers on the timing stream.