Long running Android scanning in background.

RE: Long running Android scanning in background.

Jason — Sat, 07 Dec 2019 20:21:30 GMT

Hi Hung,

I've been busy creating a new Android+iOS app that uses google Flutter and google Firestore cloud backend. The cloud database overcomes the range problems I was having. My device is in direct body contact so it sometimes gets very low signal range due to the signal being absorbed by the body.

I also made a new device prototype with the example provided in examples\ble_peripheral\ble_app_hrs. I then made another version based on examples\ble_peripheral\experimental\ble_app_multiperipheral. I thought it would be nice to allow the device to maintain connections with several phones simultaneously, (it's not crucial to the product.)

I notice the 2 examples are quite different. ble_app_hrs uses the advertising module (ble_advertising_init + peer manager etc) while the ble_app_multiperipheral example calls the soft device functions directly (sd_ble_gap_adv_start etc) . I'm not sure which is better to proceed with.

The reason I am writing to you is because in your reply you said :-

Can you tell me what parameters I should use to get connections like this? Either for the ble_app_hrs example or for the bel_app_multiperipheral example (or another example!)

I've been reading the design guidelines from Apple and the parameters seem crucial to achieving long battery life.

I assume I just need to set the right values for these #defines (from the ble_app_multiperipheral example)

#define APP_ADV_INTERVAL                64                                      /**< The advertising interval (in units of 0.625 ms; this value corresponds to 40 ms). */
#define APP_ADV_DURATION                BLE_GAP_ADV_TIMEOUT_GENERAL_UNLIMITED   /**< The advertising duration (180 seconds) in units of 10 milliseconds. */

#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(100, UNIT_1_25_MS)        /**< Minimum acceptable connection interval (0.5 seconds). */
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(200, UNIT_1_25_MS)        /**< Maximum acceptable connection interval (1 second). */
#define SLAVE_LATENCY                   0                                       /**< Slave latency. */
#define CONN_SUP_TIMEOUT                MSEC_TO_UNITS(4000, UNIT_10_MS)         /**< Connection supervisory time-out (4 seconds). */

#define FIRST_CONN_PARAMS_UPDATE_DELAY  APP_TIMER_TICKS(20000)                  /**< Time from initiating event (connect or start of notification) to first time sd_ble_gap_conn_param_update is called (15 seconds). */
#define NEXT_CONN_PARAMS_UPDATE_DELAY   APP_TIMER_TICKS(5000)                   /**< Time between each call to sd_ble_gap_conn_param_update after the first call (5 seconds). */
#define MAX_CONN_PARAMS_UPDATE_COUNT    3                                       /**< Number of attempts before giving up the connection parameter negotiation. */

I've already added some test code to create a timer to call advertising_start() intermittently. Assuming that this would be better than constant advertising. I was going to set the timer to advertise once every 2 minutes just to avoid wasting energy but I'm not sure what is best. Any advice is greatly appreciated.

Thanks for your help

-Jason

RE: Long running Android scanning in background.

Jason — Wed, 02 Oct 2019 19:09:05 GMT

Thank you for the excellent response. I will begin making the necessary changes.

RE: Long running Android scanning in background.

Hung Bui — Tue, 01 Oct 2019 13:53:02 GMT

Hi Jason,

I think keeping the device and the phone in connection could be a better idea. Scanning continuously (or with timing like what you described) consume the phone's power. And on some phones with combo chip the antenna is shared between Wifi and Bluetooth making it harder to utilize two of them at the same time.

Regarding your questions:

1. Target the latest one, and set minimum to the lowest possible (depends on the features you use)

2. Yes. Using a connection would be more stable and you can guarantee that the phone won't kill the scanning service.

For example you can configure a connection with 0.5 second interval and 1 minutes timeout. You can configure the slave latency so that you only need to wakeup and response to the central every 30 seconds. I think it would consume much less compare to your plan of sending 10 advertising packet every 2 minutes (each advertising event would require 3 packets sent)

Keeping a connection to a phone is quite basic and I don't think you would have problem with most phones.

3. I have forwarded your code to our app team, here is their feedback:

Scanning is battery hungry on the phones as well. New Android versions don't allow for long lasting background scan without a filter.

Connection is much better approach for all use cases event determining location (beacons).

Regarding his code:

Use Service, not IntentService
No need to keep the context, service IS a context
With useHardwareBatchingIfSupported(false) they are not using offloaded batching, the library emulates it using cpu, which drains battery
For bg scanning they should use low power mode, not low patency
They should use scanning with an intent, not a callback.

4. No. Better with scanning with an intent or at least a filter and low power mode. Newer phones may kill scanning after a few minutes.