BLE Motion Service

[jones139]

Verification

• [X] 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)

[jones139]

I have implemented the idea of buffering the accelerometer values within MotionService, and was a bit surprised that I am still only getting a 10Hz sample frequency. I have delved back into the code a bit further, and I don't think it is working like I was expecting - Am I right that we are just polling the accelerometer within the SystemTask loop? When I saw the accelerometer was running at 100Hz, I assumed it would be interrupt driven, or at least in a high speed task of its own.

So I think that to achieve a higher sample frequency we have a few options:

• Update the Bma421 driver to use the chip's FIFO buffer, and have Process() download all of the data from the FIFO and add it to an accelerometer data buffer.
• Create a separate task that is running at say 25 Hz which polls the accelerometer and populates a buffer.
• Use the chip's interrupt service to tell us when the FIFO is full and download the contents to a buffer when required.

The interrupt version is the neatest, but I am less confident about how to implement an Interrupt Service Routine in Infinitime without breaking something else. I think adding a separate task to poll at the required frequency is the simplest, but I am not sure what polling frequency we will manage with it. Enabling the on-chip FIFO and polling that in System Task would probably need the least code changes.

Does anyone have a preference for how to do it?

[FintasticMan]

I would say using the internal FIFO and polling in the SystemTask loop would be the best option, but I'd be open to other options. #1145 implements using the FIFO for smoothing.

[jones139]

If someone has already got the internal FIFO working, then I agree that using that and polling it from SystemTask sounds like the simplest way of doing it - I'll give that a try.

[jones139]

It seems that with the latest version of InfiniTime we are very very short of RAM - is that right? I am trying to allocate a 32x3x2byte array (=192 bytes plus a few more for pointers) and I am getting a build failure on memory overflow. If I reduce it to 3x3x2 bytes it builds, reporting 98.44% RAM usage. I have tried disabling some of the default apps, but this does not seem to affect it - does anyone know what I can do to free up some RAM from the default InfiniTime build?

[FintasticMan]

You'll want to change the heap size to be smaller in the FreeRTOS config. At the moment, the heap is taking up almost all of the RAM not used for the stack, so if the stack gets bigger, there isn't enough space.

[jones139]

Excellent, thank you for getting back to me so quickly!

[jones139]

You'll want to change the heap size to be smaller in the FreeRTOS config.

Ah, you have to delete the build folder and re-build from scratch for changes to FreeRTOSConfig.h to take effect - this might be another change to the CMake files in #1960.