InfiniTimeOrg / InfiniTimeOrg/InfiniTime

BLE Motion Service

Open
#1,949 7 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
C
Stars
3.4k
Forks
1.1k
PR merge metrics
No merged PRs in 30d

Description

Verification
  • I searched for similar issues (including closed issues) and found none was relevant.
Introduce the issue

I have been experimenting with the BLE Motion Service - I was very pleased to see you have implemented this, because I was about to look into the code to work out how to do it myself, thank you!
I have spotted a couple of things that I would like to fix, but wanted to check if these are intentional first:

  • I think the units of x, y, z acceleration are in raw accelerometer counts? I wonder if we should report them in milli-g (which will fit into a 16 bit integer still) - I noticed this when I tried changing the accelerometer rage and the values changed.
  • I am only managing to receive data to my Android app at about 10 Hz, even though the accelerometer is running at 100Hz by default - I wonder if this is because we are only sending a single measurement at a time and there is a connection overhead?
Preferred solution

I'd suggest that we:

  • Convert the accelerometer signal into units of milli-g (as a 16 bit integer) - probably at the driver level as this is where the instrument range is set.
  • Maintain a small buffer (18 byte) of accelerometer signals (x1, y1, z1, x2, y2, z2, x3, y3, z3) and only notify subscribers when that buffer is full so we download three data points at once rather than one - I am managing at least 25 Hz transfer rate on a BangleJS using this method. I suggest 18 bytes because I think there is a 20 byte limit in some BLE implementations, and I would want to keep all the x,y,z values of a particular measurement together and not split them. (25Hz is all that I want from the service - I would need to down-sample if we transferred at 100Hz).

But was it implemented in the current way on purpose for a reason I have missed? Are many people using the BLE motion service, because changing the units might break their apps? (I could do the conversion to milli-g on the phone, but I am trying to have all of my data sources use the same unit).

Version

1.13.0 (or rather my modified version that keeps the BLE services running when the watch screen switches off (https://github.com/OpenSeizureDetector/InfiniTimeSD)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the BLE Motion Service and the accelerometer driver, then inspect how acceleration units and notifications are currently handled. The issue proposes milli-g values in 16-bit integers and batching three measurements into an 18-byte buffer; done would require those changes while assessing compatibility with existing apps.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
embedded-iot, networking
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.