Re: XSPRESS3 / InternalTrigger / AcquireTime

[Matt Newville via Tech-talk <tech-talk at aps.anl.gov>]

Hi John,

On Wed, Aug 26, 2020 at 8:59 AM John Dobbins via Tech-talk <tech-talk at aps.anl.gov> wrote:

All,

FYI.

I noticed that on the xspress3 with internal trigger selected the AcquireTime rolls over for times greater than ~ 53 seconds.

The ADC sample time is 12.5 nS.  It appears the AcquireTime is converted to a 32-bit integer of ADC samples.  12.5nS * 2^32 = 53.7 seconds.

Setting an AcquireTime of 60 seconds generates an exposure of ~ 7 seconds.

Apologies if this is reported elsewhere and I missed it.

Yes, I would call this a known behavior.   For sure, that is the maximum acquire time for a single frame, and there is no problem collecting many more than 53 seconds worth of data with multiple frames.  I believe the 32-bit number-of-time-bins is a feature of the Xspress3 driver, and not a feature of the Epics interface.   I also believe it is not uncommon for cameras/detectors to actually have both minimum and maximum exposure times.

That being said, the Epics interface could detect if one asks for a count time longer than 53 seconds and internally break that up into multiple shorter frames before posting the data.   I think no one really using the Xspress3 has really needed a single  60+ second exposure (as opposed to 4 15 second exposures or whatever) to make that a priority, but I doubt it would be hard to do.  Most of the complaints I hear are on the other end: why can't it reliably stream data at 10 kHz.

Cheers,

--Matt