Reading nearables' accelerometer/orientation with lower interval and latency on iOS

BLE Beacons
1

I’m doing some research and tinkering with ‘naked’ estimote sticker. I want to make a clickable sticker as a trinket/necklace and depending on orientation and pushed button, trigger different actions on my iOS background app.

I noticed Estimote SDK is probably not good enough for me for couple reasons:

  1. change of orientation events have too big delay for me - seems like they only get advertised after ~1 sec once sticker is completely not moving - even small movement while holding in hand too often makes orientation ‘Unknown’. In my situation there might be small movement so easier for me implement my own orientation detection via accelerometer.

  2. Even if I setup advertisement interval on my sticker to 100ms and startRanging via ESTNearableManager it keeps polling sticker at around 1 fps. Is there any way to get accelerometer data at higher rate on iOS?

  3. iPhone and sticker battery lifeis very important for me, as well as low latency. If I make ‘motion only advertising’ with small advertiging interval (e.g. 100ms for low latency) I will still burning battery quite fast - I will be wearing this as necklace or trinket so moving a lot. I want to have a cake and eat it too, I know.

Instead I tried to go deep down to CoreBluetooth. Beside, so far I prototype push button as pulling in and out battery. This allows me to get iOS Core Bluetooth wake-up call on connection and disconnection to sticker thus saving battery life both on sticker and phone. However there is no information how to get raw accelerometer or orientation data via Core Bluetooth. Also I noticed when I put battery inside sticker, it is advertising RSSI immediately, however motion and temperature only after ~13 sec.

TLDR;
The questions are:

  1. Is there any way to get accelerometer data at higher rate than 1fps on iOS? Setting sticker advertisement interval at 100ms seems still not enough.

  2. Is there some way to decrease delay when motion data are being advertised when Nearable has just been powered/turned on (e.g. switched battery). If not, is this software or hardware limitation? Is it possible some future software update will improve it?

  3. When I tested Estimote SDK polling RSSI and accelerometer, and at one point removed battery, Estimote SDK kept feeding me with last advertisement data. Is there some way to figure out (via Estimote SDK) that sticker has been shutdown (is not advertising)? So far was only able to do that using Core Bluetooth and connecting to sticker.

2

It looks like 2 out of 3 problems you’re having could be easily solved by simply dropping down to the Core Bluetooth layer to get raw, “non-rate-limited” packets. Nearable protocol is documented here:

This should make it fairly easy to implement the appropriate Core Bluetooth scanning/parsing. (CBCentralManager + scanForPeripherals with an empty Services filter + centralManager:didDiscover:advertisementData:rssi: delegate + CBAdvertisementDataManufacturerDataKey)

We’re seriously considering releasing (open-sourcing?) our Core Bluetooth parsers for use cases like these, where the higher level abstractions like rate limiting or caching packets turn out to be more of a nuisance than helpful (: