›

problems with low sampling frequency on iOS

edleeedlee
edited May 2016 in iOS
I am trying to set a low sampling rate of <10Hz on the BMI160 on the RG MetaWear with the latest firmware. I'm doing this as specified in the documentation using






accelerometer.sampleFrequency = sampleFrequency;
gyro.sampleFrequency = sampleFrequency;

but I'm finding that the number of samples I'm receiving from both streaming and from logging to be inconsistent with the set sampling frequency for frequencies <20Hz. The sampling rate I'm getting is higher than expected for frequencies <20Hz and when I set it to <10Hz, I get that the gyrometer returns twice the samples as does the accelerometer. At >30Hz, everything seems to work fine.

Are arbitrary values permitted for these settings? I suppose a quick workaround would be to downsample a higher frequency that seems to be working, but this wouldn't be useful for logging long times where memory would become a limitation.

Comments

  • EricEric
    I believe it's a bug with how the sensor needs to be configured for ODR less than 12.5Hz.  Until it's fixed, you can set the ODR to a higher frequency and use the time filter to reduce the sampling rate.
  • stephenstephen
    Thats right, the sample frequency is exposed as a double to make it hardware agnostic.  See the following:

     @discussion ; The value of this property is capped to minimum and maximum values; the maximum value is determined by the maximum frequency supported by the hardware. If your app is sensitive to the intervals of acceleration data, it should always check the timestamps of the delivered MBLAccelerometerData instances to determine the true update interval.

    For the BMI160 Accelerometer it supports, 12.5, 25, 50, 100, 200, 400, 800, 1600Hz.
    For the BMI160 Gyro it supports, 25, 50, 100, 200, 400, 800, 1600, 3200Hz.
    Also, note in either case 200Hz is really the practical limit when trying to stream data.
     


  • edleeedlee
    Thanks for the clarification. Fixing it to these values solves the inconsistent rates I was getting.

    @stephen When you say 200Hz is the practical limit, do you mean 100Hz for gyrometer and accelerometer each so that the sum is 200? Or is it more complicated because of the way that data is transmitted and I shouldn't just be summing the two rates?

    Also, are there any plans to compress the transmitted information such that faster streaming rates might be possible? Or more data might be stored in memory?
  • EricEric
    edited May 2016
    The stable throughput limit is 100Hz; the 200Hz value is a mistake.

    If accuracy is not a concern, you can right shift the the acceleration data by 8 bits to compress the data down to 3 bytes.

    We have thought about ways to increase the throughput such as packing more acceleration data into each data exchange.  However, there are no immediate plans to implement any of them.
This discussion has been closed.