areaDetector for ADCs How to deal with 1D data Tom Cobb

Why would we put ADCs through areaDetector? Reuse existing plugins (HDF5, ROI, Process, Stats) Driver parameters aren’t too dissimilar (ADC produces timestamped chunks of multichannel data) Mark has already done it (quadEM module) I’d like to take that approach but modularise it further

What has DLS done? Dtacq 1MHz 16-bit ADC connected to BPM 1s averages of A, B, C, D, X, Y, I 1s FFT of X, Y, I with max freq Averaging 100 FFTs and writing to HDF5 continuously Writing full X, Y, I data to file on demand

What useful plugins could we write for ADCs? FFT plugin (already written) – Do FFT on multi channel data stream with windowing options BPM calc plugin (already written) – Produce X, Y and Intensity arrays given geometry of BPM Reframe plugin – Concatenate or split NDArrays – Allow further binning Event plugin – Assign one channel to monitor for events (e.g. Rising/falling edge with threshold, hysterisis) – Event can act as trigger with Nsamples or Gate, Pre and Post options – Allows arbitrary gate/trigger for any ADC where latency is not critical (i.e. Postmortem, extracting features for further processing) EPID plugin?

What decisions do we need to make? What does each dimension mean for an ADC? – X dim = chan, Y dim = time allows easy concatenation and makes sense from arbitrary buffer length point of view – X dim = time, Y dim = chan allows easy processing on a channel by channel basis (used in quadEM) How big should buffers be? – For very small buffers NDArray adds big overhead – Bigger buffers makes feedback applications difficult Do we keep data as Int at underlying sample rate, or convert to Float64 ASAP? Is it an ADDriver or an asynNDArrayDriver or another base class?