Stay connected to Medical BLE device in background

Question

Created 4h

Replies 1

Boosts 0

Participants 2

I work for a large medical device company.

We have a 1st party BLE enabled medical device that must be very battery efficient. To this end, if a connection is lost, the BLE radio is powered down after 60 seconds and will only turn back on when a physical button on the device is pressed.

I've been tasked with connecting to the device, staying connected to the device, and being able to retrieve data from the device upon a timed action. For instance, this could include a data read and transmission while they sleep. The key part of this is staying reliably connected for extended periods of time.

This is a BYOD setup, and we cannot control power profiles.

I would very much appreciate any information, recommendations, and/or insights into solving this problem.

Thanks!

Boost

Answer 1

Engineer OP

Apple

33m

The ability to stay connected to a BLE device is not something that can be enhanced via an app.

A whole lot will depend on the hardware, like antenna design; environment, like distance, RF interference; materials between the two devices; and various connection parameters including but not limited to the power profiles.

Assuming you have no control whatsoever on any of these, the only thing you can do in the app is to make sure you are able to connect as quickly as possible when (not if) the connection drops.

This means you need to make sure you have implemented Bluetooth State Restoration, so your app gets relaunched even if the app has been terminated in the background by the system.

The document Performing Long-Term Actions in the Background explains how to implement this.

The second thing you need to do is to make sure you issue a connectPeripheral command as soon as your app gets the callback that the connection has dropped. It is advisable to keep the CBPeripheral object from the last connection and send a connect command directly instead of starting over with a scan, and then issuing a connect command once discovered. This will make the reconnection a bit faster.

Assuming you also don't have any control over the advertising interval for this device for the 60 second power on window, knowing what the interval is will make it possible to estimate the time to discovery and whether the 60 seconds will be enough. If the device is advertising at the slowest recommended rate of 1285 ms intervals, if you use the connect command instead of scan, the reconnection should be possible in the 60 seconds window if you app is in the background.

If the device is not advertising at one of the recommended intervals, or your app is not attempting to reconnect directly, but is needing to scan first, then it is unlikely that the 60 seconds would be enough, assuming the developers also tried to save power while advertising.

In any case, if there are issues reconnecting in 60 seconds, knowing the various connection parameters, and whether there is a possibility to change them along with Tx power would be useful to create a viable strategy.

Argun Tekant /  WWDR Engineering / Core Technologies

0