Impossible to modify Threshold param in "Vibration Monitor-Compare" application on SensorTile.Box

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