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
