det1:DataType_RBV PV does not report correct data type

[canismarko]

This was with version 3.2.7, so if this is fixed in 3.2.8 let me know and I'll update our IOC. I didn't see it mentioned in the release notes so I'm submitting this now.

Description

The datatype produce by the detector is either uint32 or float64 depending on whether deadtime correction is enabled. However the PV det1:DataType_RBV always reports "Int8". The HDF5 plugin reports the correct datatype, however this is not available until the plugin is primed.

Expected Behavior

The value of det1:DataType_RBV should be either "UInt32" or "Float64" depending on the value of det1:CTRL_DTC. Enabling/disabling dead time correction should update the data type.

Observed Behavior

det1:DataType_RBV is set to "Int8" at startup. Toggling dead time correction does not change the reported data type. If I set the correct datatype by caput-ing to det1:DataType_RBV, then ophyd-async and Tiled are able to exchange data properly.

Use Case

Bluesky's Tiled data API depends on knowing the datatype to properly interpret the transmitted data between server and client. Since ophyd-async cannot control whether the plugins are primed or not, it relies on det1:DataType_RBV instead of the HDF5 plugin. Data are stored properly in the HDF5 file, and read back properly by the Tiled server. However, when a Tiled client tries to reconstruct the array it receives based on the reported data type, it fails because the data type is incorrect.

[canismarko]

If this is a wontfix, I can fix it in ophyd I think, but seemed like a better thing to fix in the EPICS layer.

[newville]

det1:CTRL_DTC should not be used and should be considered deprecated. Those corrections are not reliable.

Aside: It is perfectly reasonable to question why the data is Float64. Since the max runtime to 2**32 clockticks, or 53 seconds (hopefully that changes with the 200 MHz clock!), even at maximum total count rate of 5MHz and putting all those counts into one bin, you cannot fill 32 bits of data in any actual "run". So, why the data is not always and only UInt32 is sort of baffling. Even if one was doing deadtime correction, the max value is still only ~500e6 and the precision lost by using Float32 would be at the 10s level, orders of magnitude below counting statistics uncertainties. So, the use of Float64 is a little overkill. Or, it is a good advertisement for "just always use Float64 and data compression".

Anyway, the uncorrected data should be saved with the dead-time correction factor (~ICR/OCR, but including resets) in the "DTFactor" scalar. The HDF5 should be (and is, by default) saving the non-DTC data and this value, along with other run statistics.

[canismarko]

det1:CTRL_DTC should not be used and should be considered deprecated. Those corrections are not reliable.

Good to know, I will put a step into our ophyd device to make sure this is turned off when staging the detector.

My thought when submitting this issue was whether the det1:DataType_RBV PV should actually report the correct data type, independent of whether that data type makes sense.

Given your comment about det1:CTRL_DTC being deprecated, this might not matter much. I've put a workaround into our ophyd-async support, so if it's not worth it to fix this, that's fine with me.