Hi, I am developing a solution using IIS3DWB, I want to change the ODR from 26667hz to 13000hz, how can I do this? I am unable to find anything in the datasheet. Request support from the community. Regards, Aman

[Eleon BORLINI · Accepted solution]

Hi Aman @ABham.1​ ,

please consider that for the IIS3DWB the ODR is fixed at 26667hz and it is not possible to change it in the configuration registers. With this ODR, the maximum detectable acceleration frequency by Nyquist theorem is 13kHz. However, please note also that the MEMS mechanical cutoff frequency is 7kHz (datasheet p.19), so this is actually the maximum detectable acceleration frequency at full sensitivity. Of course, running the device up to 26.667kHz allow a noise reduction coming from oversampling.

If you are interested in reducing the ODR for a bandwidth reason, you can use the second Low Pass filter (digital LPF2, datasheet p.20) to adjust the band according to your preferences (up to 5.4kHz). Which is your target application?

On the other side, if you want to reduce the power consumption of the device (by reducing the ODR frequency), you can think to not to enable the system permanently, or to run the SPI at a lower frequency (for example 13kHz) so that you can reduce the number of clock and data edge commutations per second. In this way you will loose samples and so reduce the band (and maybe loss a little in the noise figure), but you'll reduce the operating power consumption. 

If my reply answered your question, please click on Select as Best at the bottom of this post. This will help other users with the same issue to find the answer faster.

-Eleon

[ABham.1]

Hi Eleon,

Thanks a lot for the reply. The problem is if the ODR is not configurable we need to send complete 26667 samples to the Cloud from our sensor and do the spectrum analysis. We cannot compromise in the resolution of the spectrum, we need atleast 1Hz. Increasing the number of samples means a bigger json file, lot of IoT platforms have a limit on the MQTT size. So I guess we will have to look for compression options now if we cannot change the ODR.

Regards,

Aman

[du00000001]

Receive the data @ 26667 SPS and pass them through a simple sliding average filter. Following this filter, you can "pick" every 2nd value for transmission. This might introduce a bit of aliasing error if the frequencies measured include frequencies beyond 6.5 kHz. If so, you may consider Eleon's suggestion to configure the sensor's LPF2 to 5.4 kHz.

BTW: frequency resolution per FFT is not linear (it's DC to Nyquist with nsamples values), so what's that "at least 1 Hz resolution" requirement nonsense ?

[ABham.1]

Hi, I dont really think that you understood my question, anyways i would explain again. My concern is not the bandwidth at all, i understand i can configure the bandwidth by applying LPF2. If the ODR is 26667 and i take 26667 samples and then make a FFT spectrum then i guess the resolution of the FFT bin will be ODR/N = 1Hz ( nonsense?)

The problem is if i take 6000 samples and then make an FFT then the Bin resolution will be 4.44Hz (This is not acceptable to detect gear mesh frequency for our application) and if we take 26667 samples then the JSON file becomes huge around 240Kb. Our MQTT broker on the server side cannot accept message greater than 128Kb ( now did you get my question?)

Now we will have to split the MQTT message or compress the message which takes a toll on the battery consumption of the sensor.

[du00000001]

I understood your question very well. Might be I was not sufficiently explicit, might be you are not familiar with the concepts of undersampling and/or sampling rate conversion.

• The sliding average filter I mentioned serves just to cut higher-frequency components.
• "Pick every 2nd value" results in 26667/2 samples. (OK - this does not compute. Pick the 2nd, 4th, 6th etc. - up to the 26666th filter output value.) so the 26667 samples result in 13333 values following the filter. These 13333 values still describe the signal over 1 second, just with the higher frequencies cut.
• If the higher frequencies do not matter (much), you can even further reduce the number of samples (still for the same period!) by using a more pronounced low-pass filter and by picking every 3rd, 4th etc. value.

So it was never about picking x samples with the original sample rate but about picking x samples at ODR/N (N = 2, 3, 4, ...) - reducing the number of samples to be transmitted and processed by N.

Does this transpire now ?

[ABham.1]

Hi,

Thanks a lot for the explanation, i will try to implement it, i am sure this will make our work easier.