Page History

...

- impact from the sequencer itself minimal
  o previously waited 5*8.4ms between camera shutter-open and burst-start
    but this could be optimized for LCLS2.
  o andor shutter-open ("exposure start") is done all in hardware
  o andor has a "clear mode" but then can't run at 120Hz
  o since it's all hardware we likely could reduce it significantly
- expect inefficiency to be dominated by readout (3ms?)
- andor key idea: last burst shot (or a programmed sequence event after the last burst shot could , which is cleaner, but this has the wrong timestamp?) will send the TTL to trigger the readout (have
  to  to delay this appropriately by timing it in).  if we use the last burst shot, have to delay it a little bit so readout starts after the pulse arrives: one does this in two ways: (1) delay with a TPR setting, or (2) delay readout in the camera with the "exposure time" setting (perhaps preferred because it works in single-shot or low-beam-rate mode without a sequence)
  o plus: works with the current IOC
- next burst runs automatically.  insert enough time to cover the readout time
  plus jitter (but jitter should be microseconds?).  we think the jitter
  on the transfer time (due to the OS) doesn't matter:  in principle next
  exposure could overlap transfer of data over usb.
- readout time depends on all the usual params: ADC speed, ROI, FVB...
- there is a PV that estimates the camera readout time (this is
  "Acquisition Period" from SDK on the upper right of main panel (was 0.018s
  in 32 partial-vertical-binning mode).  FVB is 0.006s.  This is an
  over-estimate because it includes usb data-transfer time.  Maybe
  the SDK has a number that doesn't include data-transfer time.  Otherwise
  we have to try to calculate it ourselves somehow

...