Changing APP_ADV_INTERVAL when scan request detected

[Jason]

Hi,

I'm making a peripheral device that needs to minimise battery usage.  

My device is essentially a beacon but it allows temporary connections to send a stream of data before closing the connection. I do not think I have enough battery to allow permanent connections that follow the apple design guidelines (220 mAh coin cell and >1 year longevity)

I was surprised to discover that android phones won't reliably connect if APP_ADV_INTERVAL is 10 seconds. With my old samsung S5 I need to reduce the interval to around 2 seconds. 

I have an accelerometer so I was planning to rapidly advertise when the user shakes the device. But maybe it would be better to change the advertising interval when a scan request is detected. Is this possible? Can I detect when my device transmits a scan response? Or is there another mechanism to support this?

Thanks in advance for your help.

-JasonR

[Mishka]

Hi,

I develop a similar app and if you don't mind would like to share some thoughts.

The time to discovery depends not only on how often the beacon advertises (the advertisement interval), but also on the scan window and the scan interval. These two options are intended to save power of the scanner, and it may happen that the advertiser sends its packet just at the moment when scanner doesn't listen. For example, if scan window is 1024 ms and scan interval is 4096 ms as defined by the Android Scan Manager, and the beacon sends a packet every 10 seconds, there's P=0.25 probability to catch the packet from the first attempt. In turn, with the broadcast interval decreased down to 2 seconds, there will be P=0.75 chances to see the packet during the first scan interval. Please note, with these settings it's possible to trap into "blind" zone when advertisements are perfectly aligned with radio off intervals.

To improve catch ratio, it's possible to either decrease the advertisement interval on the beacon, or make the scan window wider and the scan interval shorter on the Android smartphone. Of course, it's also possible to set T_adv < T_scanwindow in order to guarantee the result (there's a small probability of RF congestion though).

Regarding the scan response, as far as I know it is sent in reply to a scan request, which in order is sent in reply to a caught advertisement packet. I.e. the smartphone will be required to catch at least one advertisement before the beacon may respond with a scan response. This, perhaps, reduces significance of the scan response for this particular app.

IMHO to save the beacon battery there are basically two options:

• As you have suggested, on interrupt from the IMU do broadcast more often, probably with T_adv < T_scanwindow so the smartphone may catch it earlier and do it's job quickly.
• Alternativaly, connect the beacon as peripheral with the Slave Latency connection parameter set fairly high so the beacon can have long enough idle times between packets. The slave latency will allow the beacon to respond to the IMU interrupts quickly, but as a drawback the smartphone will have to wait for the Supervision Timeout before it can reach the beacon. Of course, if the beacon will get to the smartphone earlier, the smartphone will be able to respond immediately, and (if needed) adjust the slave response.

Kind regards,
Mishka

[Karl Ylvisaker]

Hello Mishka,

Mishka said:

I develop a similar app and if you don't mind would like to share some thoughts.

Absolutely, we're happy to hear your thoughts on the matter!

You are absolutely correct about the impact different scanning and advertising intervals will have on performance, and how they affect power consumption. This is also the reason, as far as I know, that you cant choose scanning intervals freely on Android / iOS.

I am not sure I have understood you correctly about your explanation on slave latency.
Slave latency controls the peripherals ability to skip a number of connection intervals, in the case that it has nothing to transfer.
So for example, a peripheral sensor might skip a couple of intervals if there is no update to the measurements.
This might greatly reduce the amount of empty packets being transmitted to maintain the connection, which in turn will save a lot of power.

Best regards,
Karl

[Mishka]

Karl Ylvisaker said:

I am not sure I have understood you correctly about your explanation on slave latency.
Slave latency controls the peripherals ability to skip a number of connection intervals, in the case that it has nothing to transfer.
So for example, a peripheral sensor might skip a couple of intervals if there is no update to the measurements.
This might greatly reduce the amount of empty packets being transmitted to maintain the connection, which in turn will save a lot of power.

Yeah, this is exactly what I meant. Just thinking on how to address the issue Jason have noticed in the original post:

Jason said:

I do not think I have enough battery to allow permanent connections that follow the apple design guidelines (220 mAh coin cell and >1 year longevity)