Andor Newton is one example.

Preliminary conclusion: we can make the IOC work with the shutter-closing timestamp, and timing system has the shutter-opening timestamp

Requirements:

• has to be joined to the "shutter closing" event, so it needs that timestamp (Dan says natural idea in IOC is timestamping with shutter-opening trigger).  Possible hack: use two different event-codes: one for opening the shutter (IOC ignores this one) and one for closing the shutter (IOC listens to this one for the timestamp).  
• data would contain the "shutter opening" timestamp: the makes the recorded data a more complicated structure, but maybe not: Matt points out that the timing system already has this information, so no need to complicate the data structure.

All of this requires event-code sequencing (complex).

(uncommon) Maybe not all experiments require precise timestamping: could use imprecise software triggering (python script, human doing something on keyboard?).  Dan thinks they always need to know the precise shots.

These two requirements suggest we might want to consider moving away from IOC/PV/AreaDetector reuse and use a standalone program, but maybe the hacks above would work?

RIX says they want this "in the future" (see the sub-page Integrating Detectors in RIX)

psana Design Options

(discussion on March 16, 2022)

simple timestamp example:

andor (1hz): s  4s  8 (s=start of integration)
hsd   (4hz): 12345-78 (minus=missing shot)

batch size now has to keep three things happy:
- performance/efficiency
- integrating detectors
- batching memory, which is only for small data (hopefully we can deal with this)
  o big data isn't batched, handled on event-by-event basis, and
    memory is handled naturally, so not a problem

requirement: only one integrating detector? more is OK but they have to
be synced.
- can't support conflicting requirements from 2 detectors where an
  an event has to go to two places
- verify with experimenters

timescale is Sept. 2022

option 1:
- put batching on an andor boundary (4, 8)
  o shots 1 thru 4 go to 1 EB core and 1 BD core
- user needs to specify a "special" stream file (andor, above)
- batch size becomes dynamic.
  o current batch size is fixed: default 1000, can be set by user
  o currently last batch is dynamic
- two ideas currently: chunk-size between SMD0 and EB, and batch
size between EB and BD. both are currently fixed numbers
- could use many EB cores (unlike destination callback)
- could put multiple andor images in 1 batch for efficiency

option 2:
workaround? maybe we could reuse the destination callback?
- has a limitation that we can only use 1 EB core
- Mona thinks that if "we" control destination callback then
  we can perhaps have more than 1 EB core.  SMD0 has to be in-charge

Question emailed to hutch scientists on mar 16, 2022:

As we move to higher rates we are thinking of ways we can support “integrating detectors”, e.g. a slow 1Hz camera running with a 1MHz high-speed detector (e.g. hsd) where you need to analyze precisely all 1MHz shots that contributed to the slow image (assuming that the slow device’s “shutter" is precise, which is likely not true for all devices … that’s a separate issue).

It will be difficult for us to support arbitrary integration periods for multiple detectors, e.g. detector1 integrating over shots 1,2,3 (and 4,5,6) while detector2 integrates over 1,2,3,4 (and 5,6,7,8).  We think we can support multiple detectors with one integrating at a “highest harmonic” (e.g. 1,2,3 then 4,5,6) and another simultaneously integrating in the same way, or at an integer “lower harmonic" (e.g., 1,2,3,4,5,6 then 7,8,9,10,11,12)

My question: can you let us know if you foresee that the above “highest harmonic” requirement would not be sufficient for your experiments?