I’ve been developing a GATT profile for RuuviTag, essentially this provides connectable access to RuuviTag with 2-way communication channel between application and tag.
Right now the application is in extremely fluid development state and will consume battery quickly.Development firmware can be obtained from my github fork.
The profile contains standard BLE sig service for environmental data. Right now work for device information service, battery level service and transmission power service is underway.
In addition there will be support for de-facto standard Nordic UART service, which can send and receive any 20 byte long information over bluetooth.
There is no reasonable standard for acceleration data, so I’m still trying out how different implementations are usable.Currently there is “IMU Service” which contains a format byte and most recent X-Y-Z accelerations, but I feel that this does not match all usecases. User might be interested in average, impulse or peak of acceleration over certain period, for example. I’d be happy for any ideas on what you’d want to see with acceleration service.
On receiver side I’ve implemented a quick proof-of-concept web bluetooth site which can connect to RuuviTag and graph acceleration. Code is on github and site is available here. Please note that you must have web bluetooth enabled on device and I’ve tested it out only on Android 6.0.1 / Chrome
Other features can be tested with nRF Connect, for example.
Very interesting @otso, this is definitely something that is needed and takes Ruuvitag to next level. We have been working usecases tgat need acceleration data for a good time so I can share my opinions on this. Here is just a list of usecases we have worked on:
Detection if device has been “still” for X amount of seconds
Detection if object is impacted with force over X
Detection of total accelaration during X seconds
Mainly in our usecases it is enough to get acceleration data for last second, if device is able to do more than one measurement per seconds, then that data would be average value. In some usecases we only need data if acceleration is over X value. Usually we have two tags, one that is still and other one that is moving, so that we able to calculate differences between them. But sometimes we need to calculations based on information from only one tag.
Thank you for the detailed usecases.
Maybe we could define timestamped “acceleration events” such as
“acceleration over X starting at T1 ending at T2” to cover being “still”, even in environment with vibration.
“Impulse with total acceleration over X at moment T”
The interface to configure the thresholds and to read results needs to be carefully considered, I’ll come up with a proposal and some examples ASAP.
Detect if the devices goes from still to some sort of small movement/vibration. Here I guess one would like to determine a noise floor for which all acceleration below is considered “still” and accelerations above (with some hysteresis) is considered movement.
Measure acceleration in all three dimensions and integrate to get velocity in a specific direction. This is more of a special case and to make it even more tricky the Tag will in our case also be rotating (hence a gyroscope is also needed). I think a set sample frequency of about 200 Hz or more is also a requirement.
The second point is a special case that probably not should be taken into account now but to easily set a fixed sample frequency would be nice.