Excalibur Detector device

[stan-dot]

It's used for grid scans. Will explore more details to provide a better description.

It looks like it used currently at i07, i13-1, i14, i18

source - confluence page for Excalibur

[stan-dot]

also p29 (?) https://confluence.diamond.ac.uk/display/~gnx91527/Excalibur+Information

[stan-dot]

Device capacities

• deadtime
• supported trigger times
• trigger mode
• usually 1 minute for timeout - hardcoded, it's not variable

can reuse OdinMetaListener, writer, etc, but no EigerFan
nodes is also uncertain`

odin-detector type

it's different from Eiger
AreaDetector interface, talks to hardware and the filewriting and plugin chain - handled in ODIN.

Excalibur is an image detector - 2500 by 2500 pixels.
as it acquires it processes with FrameReceivers, next to FrameProcessers.

Also burst mode is important

# also BURST? = if to receive 1k frames, with external - with a click and after the first signal the 1000 times 
# excalibur will have those of xpress3
# also the same kind of detectors properties like xpress3

Will use many parameters that the EigerOdin does,such as cam and argming logic.


Not sure about the 'roi' *region of interest mode.

Plugin chain is next and it can do sum, compress. Most common it's sum and compression.
All of that is hard-coded in the controls part.
What daq has control over is the file writing part. Possibly with chunking. XpressOdin (B18 and I18) uses.

into 4 processes - can be batch or round robin.

top level interfaces - file writing part nad metadata writer and number of frames. All are very similar.
mostly diffraction measurements - they reotation the 360 degrees, so kind of like diffraction tomography
sometimes xpress3 is done simultaneously with excalibur as a fly scan

This goes through an external PandA trigger.
sometimes also 3d or grid.

only up to 100Hz - breaks if higher than that, there is no protection right now.
usually used at 50Hz - uniform distribution. Time-based with PandA. - evenly spaced in time.

in regards to 12 bit vs 24 bit - possibly - at 12 can go over 100Hz (data flow capacity).

Changing from one mode to the other should be very easy ( so just an endpoint).

Compression is the most important part.
self.compression = epics_signal_rw_rbv(Compression, prefix + "Compression")
this should be copied over from the AreaDetector NHDF writer in ophyd-async.
Data compression
BLOSC for compression https://github.com/Blosc/c-blosc

[stan-dot]

tagging @jacobfilik and @GDYendell - request for comments

[stan-dot]

FastCS is a core requirement, likely towards the end of 2024.

https://github.com/DiamondLightSource/eiger-fastcs

https://github.com/DiamondLightSource/FastCS