Hi, I'm trying to add triggered buffer support to the bmi160 IMU driver and a question came up that I don't know the answer to. The driver defines an x, y, z channel of type IIO_ACCEL and an x, y, z channel of type IIO_ANGL_VEL. Then within each of these channel definitions, info_mask_shared_by_type is set to: BIT(IIO_CHAN_INFO_SCALE) | BIT(IIO_CHAN_INFO_SAMP_FREQ) This means that the driver allows for a different sampling frequency on the accelerometer and gyro components. The chip has a hardware FIFO and the chip is configurable whether the FIFO is in headerless or header mode. In header mode the header tells the reader the structure of the data. Here's a relevant snippet from the datasheet (https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BMI160-DS000-07.pdf): > In contrast, the header mode is intended for situations where flexibility in the data structure is required, e.g. when sensor run at different ODRs or when switching sensors on or off on the fly during operation. Do IIO buffers support the case where multiple channels are enabled that have different ODRs (sampling frequencies)? It seems to me like the client on the receiving end of the buffer will receive samples of a fixed size equal to the sum of the sizes of all the enabled channels and that the client can only look at which channels are enabled. They can't distinguish which channels are populated in the current sample. Am I correct about this limitation? If so, what is the suggested behavior by the driver? Should the channel definitions be changed so that sampling frequency is info_mask_shared_by_all? Or should I do something like use iio_buffer_setup_ops.validate_scan_mask to validate that the sampling frequency is equal for all channels specified by the scan_mask? Thanks, David
