Temporary high-frequency accelerometer readings

Development 🇬🇧 Development projects with Ruuvi products
1

I have an application in mind where, for a short while (a few minutes) the sensor should be communicating its accelerometer readings multiple times per second (either via advertising or sending notifications while connected). Is there any way to achieve this currently? If not, what kind of approach could I take (which can involve customising firmware)?

1 Like
2

Hello,

I did something similar here: Releases · ojousima/ojousima.acceleration_bcast.c · GitHub Vibration Monitoring with Bluetooth Sensor RuuviTag - Part 2 - Ruuvi

There were two different operation modes defined - one for standby and one for high-performance measurement.

Tag is in sleep mode until it detects acceleration event and switches to rapid sampling on event. The tag collects data to accelerometer FIFO buffer, reads buffer in a burst, runs quick analysis broadcasts results and continues until acceleration falls below certain level for some time.

It did take some coding effort, but certainly doable. The linked code is badly out of date, it would make more sense to take current ruuvi/master and build the application on top of it.

3

Thanks for the response and linking to your code, @otso. One significant point of difference for me is that in your case the tag is deciding when to switch into the other operational mode, where as in my use case, this cannot be inferred and should be somehow prompted from a connected device.

One approach would be to connect and rapidly query a GATT characteristic, but from this thread I assume it’s not possible (without custom firmware) to trigger fresh sensor sampling via GATT queries?

4

You are right, this would require a custom firmware. The vibration monitoring part 1 Vibration Monitoring with Bluetooth Sensor RuuviTag - Ruuvi has something similar, I used the code there to collect the raw data to build part 2.

Essentially the process is to connect, give “start sampling” command and let the tag push data through TX notifications. This is a lot faster than polling a characteristic, I think 400-800 Hz is doable with 3 axis, 8 bits resolution.