SensorTile.Box: Can't modify Threshold in "Vibration Monitor-Compare" app

[francus76]

Hello,

I'm working with the Vibration Monitor use case available in the Example Apps of Steval SensorTile.Box MKSBOX1V1. I'm quite happy with how it works, but I would like to modify some parameters and here comes the problems (both modifying the already available apps and creating new ones from the scratch in the expert mode). The app consists of two steps, one creating the vibration profile of the monitored object (Vibration Monitor - Training) and the second finding the differences between the current vibration profile and the reference one to identify anomalous vibrations.

If we give a look to the settings of this example app, which is correctly working, we can see among the the parameters of the Vibrometer Accelerometer Sensor that the Output Data Rate (ODR) is set to 6666Hz and by default it can stream data over Bluetooth (otherwise it would not work with the Android app, lighting on the virtual lamp when the Sensortile.Box vibrates). However, when I click on "modify" in order to try to change the threshold value, even before making any change the app says the default output method is no more available (nor selectable). Opening the Vibrometer Accelerometer Sensor, it says that at 6666Hz, BTLE is not available. The higher frequency I can select that makes available BTLE transmission of the output is 52Hz.

Even trying to select this value, the app is not working fine, since when there is a vibration it detects the vibration after 30-40 seconds and the lamp remains on for other 30-40 seconds after the SensorTile.Box is no more vibrating.

So my question is: "how has it been created the example app, which is able to stream output data over BTLE even when  Output Data Rate of the vibrometer is set to 6666Hz? is it possible to change the threshold parameter without loosing the possibility to get the output data over BT?".

Thanks in advance,

Francesco

[Federica Bossi]

Hi @francus76 ,

In the sensortile.box apps if you want to transmit IMU data via BLE the maximum frequency is ODR=52Hz, in a simple flow with IMU as input and BLE as output.
If you choose to save the data to SDCard (no BLE stream) the ODR can be greater than 52Hz.
To store the data in SDCard, the ODR can be more then 52Hz.
The Vibration monitoring app is a different approach then before. It uses a 6666Hz as ODR but generates an FFT locally to the board, and then performs a comparison with a FFT file stored in SDCard generated previously from the vibration training app.
Via BLE it only transmits the result of this comparison by turning on the LED, it does not transmit the IMU vibration data.

Here you can find a video tutorial.

[francus76]

Hi Federica,

I have seen the tutorial and it is clear to me that the app should transmit only few data via BLE, given by the comparison on reference vibration profile FFT and current vibration profile FFT (I have indeed collected these data via USB and only few bytes are transmitted). I'm not interested in collecting the whole IMU data via BLE, just only the result of FFT compare, but if I create a new flow having as input the IMU samples at a bitrate higher than 52Hz, then calculate a 1024 FFT and then I add the FFT compare function with 511 lines to compare (with a lower threshold than the predefined one, let's say 8), I'm not able to stream via BLE the few data given by the FFT comparison, but I can only send output via USB or SD card. It seems to me that the system disables the BLE output only because the IMU samples are at high bitrate, but not considering we are not asking to stream raw data, but only the result of compare.

Sampling at 52Hz the IMU data before FFT and compare, results in an unefficient algorithm that is not able to detect correctly and immediately the vibrations. So my request was to understand if there is any trick to leave the IMU sample rate at 6666Hz (as in the example app) and continue to stream the FFT compare output via BLE (as in the example app) with a lower threshold. Thanks.

[svnnahcmaila]

It looks like the example app is using internal buffering and downsampling rather than directly streaming full-resolution 6666Hz data over BTLE. Real-time Bluetooth Low Energy bandwidth can’t actually support raw 6.6kHz streaming per axis, so the firmware likely compresses, aggregates, or processes data locally and only sends higher-level events or threshold flags over BT.

When you click modify,the app regenerates the pipeline using the standard BTLE capability checks and then correctly reports that 6666Hz streaming isn’t BT-compatible, which means the original example app probably uses custom internal logic that is lost when rebuilt through the UI.

Practically, this means the threshold itself can be changed, but it has to be done at the firmware level (pre-BT broadcast), not by altering the UI-generated model.

If you want real control over the threshold while keeping responsiveness, the most reliable approach is:
• keep the high-frequency sampling local
• evaluate threshold inside the MCU
• only transmit binary “event detected” outputs over BTLE

That way you maintain responsiveness without running into BT bandwidth limits.

[francus76]

Hi @svnnahcmaila, yes surely also the preloaded software samples the IMU data at high bitrate, calculates the FFT at 512 points and compares it with the reference FFT, saved during the training phase, using default threshold. This software sends only few data over the BTLE, but it is important to sample IMU data at high bitrate to obtain reliable output data. When you change only the threshold value, the app cannot maintain the 6666Hz sample rate of raw data (not data over BTLE) and this is a problem. I am not expert of firmware programming, so I cannot correct this problem by myself, but in my understanding it's a bug if I cannot use this device to detect lower vibrations only because I cannot change the threshold value...