Buffers and sampling frequency

Buffers and sampling frequency

[David Frey]

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

Re: Buffers and sampling frequency

[Jonathan Cameron]

On Wed, 14 Nov 2018 09:36:42 -0800
David Frey <dpfrey@gmail.com> wrote:

> Hi,
Hi David,

> 
> 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):

Yeah. This is an annoyingly common hardware design.  To my mind it's overkill
as the chances of any software actually taking full advantage of different
frequencies of data is fairly low.

Also note that typically sampling frequency controls have additional side
effects in terms of filtering etc which apply to data not coming through
the fifos.

> 
> > 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.

Indeed you are correct on that but there are ways of handling this if
it actually matters enough.

> 
> 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?

So, when we first met devices that did this sort of tagged data (which
as you have observed doesn't fit with our data model at all), we did
exactly what you say and had drivers only support a shared data rate
across all their data types (basically don't use the tagged modes).

There is however, one bit exception in tree which offers another (more
complex path), the lsm6dsx.  In that case we actually register multiple
iio devices, one per data type, handle the complexity of bringing them
up appropriately and then push data to the right iio device dependant
on the tag.  I've always been in two minds about this.  One side effect
is you loose the implicit association between channels of different types
and have to align the data using timestamps in userspace which is ugly,
but if we need to support it that is the only way to do it in a model
where we don't carry meta data in the buffer.

Now to support this in the bmi160 which supports (I believe) the
headerless mode already, we would have to continue supporting a single
device, but could potentially have additional auxilliary devices on which
channels can be enabled if you want to have the data with header mode
with uneven sampling frequencies.  It can be done, but it'll make for
a somewhat unexpected userspace interface which is perhaps not a good
thing.  

So the question is whether your question is abstract, or you have a
real usecase that needs the uneven sampling?  Or have you just spotted
a bug with how it currently works and want to fix that (so the frequencies
are in lock when the buffer is enabled?)

> 
> Thanks,
> David

Jonathan

Re: Buffers and sampling frequency

[Medenblik, H.J.W. (Henk)]

Hi Jonathan,

I was triggered by this mail because here was something mentioned about
metadata in FIFO's and the use within iio.
I am currently designing some FPGA functionality and originally I also
wanted to use metadata in front of the actual payload data of my IIO
device (which is a radar acquisition system).
Therefore I was wondering if there never have been a request to support
a metadata feature in the iio framework. Is this because of complexity
or does it have another reason?
In my case I would like to add this metadata to inform the user with
formatting of the payload data but it would also give us a manner to
include hardware timestamps which can be used to correlate with other
captured data  (from other sensors).

With kind regards
Henk

On 16-11-18 18:17, Jonathan Cameron wrote:
> On Wed, 14 Nov 2018 09:36:42 -0800
> David Frey <dpfrey@gmail.com> wrote:
>
>> Hi,
> Hi David,
>
>> 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-BMI1=
60-DS000-07.pdf):
> Yeah. This is an annoyingly common hardware design.  To my mind it's over=
kill
> as the chances of any software actually taking full advantage of different
> frequencies of data is fairly low.
>
> Also note that typically sampling frequency controls have additional side
> effects in terms of filtering etc which apply to data not coming through
> the fifos.
>
>>> In contrast, the header mode is intended for situations where flexibili=
ty
>> in the data structure is required, e.g. when sensor run at different ODR=
s 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.
> Indeed you are correct on that but there are ways of handling this if
> it actually matters enough.
>
>> 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?
> So, when we first met devices that did this sort of tagged data (which
> as you have observed doesn't fit with our data model at all), we did
> exactly what you say and had drivers only support a shared data rate
> across all their data types (basically don't use the tagged modes).
>
> There is however, one bit exception in tree which offers another (more
> complex path), the lsm6dsx.  In that case we actually register multiple
> iio devices, one per data type, handle the complexity of bringing them
> up appropriately and then push data to the right iio device dependant
> on the tag.  I've always been in two minds about this.  One side effect
> is you loose the implicit association between channels of different types
> and have to align the data using timestamps in userspace which is ugly,
> but if we need to support it that is the only way to do it in a model
> where we don't carry meta data in the buffer.
>
> Now to support this in the bmi160 which supports (I believe) the
> headerless mode already, we would have to continue supporting a single
> device, but could potentially have additional auxilliary devices on which
> channels can be enabled if you want to have the data with header mode
> with uneven sampling frequencies.  It can be done, but it'll make for
> a somewhat unexpected userspace interface which is perhaps not a good
> thing.  =

>
> So the question is whether your question is abstract, or you have a
> real usecase that needs the uneven sampling?  Or have you just spotted
> a bug with how it currently works and want to fix that (so the frequencies
> are in lock when the buffer is enabled?)
>
>> Thanks,
>> David
> Jonathan
>

This message may contain information that is not intended for you. If you a=
re not the addressee or if this message was sent to you by mistake, you are=
 requested to inform the sender and delete the message. TNO accepts no liab=
ility for the content of this e-mail, for the manner in which you use it an=
d for damage of any kind resulting from the risks inherent to the electroni=
c transmission of messages.