conversation with Dan Damiani on Sept. 23, 2022

to estimate duty cycle for RIX burst-mode running

andor deadtime estimate optimistic estimate (assuming 3MHz (0.33us per pixel) ADC clock and a vertical shift time of 7.3us (both settable in IOC window):

For a full image: (2048columns*512rows*0.33us)+(512rows*7.3us)=0.35s

if we integrate for 1s in full-image mode, "deadtime" is 0.35s/(1+0.35)=26%

For an FVB image: (2048columns*1row*0.33us)+(512rows*7.3us)=4.4ms

if we integrate for 10ms in FVB mode, "deadtime" is 4.4ms/(10ms+4.4ms)=30%

factors that can make the above too optimistic:

  • extra deadtime after readout before listening to trigger (can overlap transfer-to-host with new exposure).  can burst FVB data at 920Hz, but not sustainable (only 120Hz).  data gets buffered on camera.
  • settling time after exposure before charge-shifting ("clamp" setting?)
  • horizontal shift time between each digitization: 3MHz might be optimistic

there is a PV that tells the acquisition time (includes the readout time: most that you can sustain, but not burst).  might be too pessimistic because it includes readout time.

may have to determine empirically or by reading the manual in detail

there are comments/measurements in an ioc file (xmitdelay.db file) about measurements that were done (including readout time).  this was done to get the timestamping working in the controls-way of understanding delays in camera responses.

  • No labels