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

[Jason]

Thank you, I appreciate the help. I'm happy to use an intensive scan to find the device and read it's most recent values. This works even with a 10 second advertising interval. They only need to connect to download the old data. which they wont do often. 

[Karl Ylvisaker]

Hello again JasonR,

Jason said:

Thank you, the scan request notifications work. 

No problem at all, I am happy to hear that you have achieved the desired functionality. 

Jason said:

I've been looking for a broken setting in my code but I cant find anything. I've been comparing my settings with other examples and not found anything obvious. I'm not sure which settings you want to see so I've attached my sdk_config.h and main,c if you could have a look. 

Between this and your recent comment to Mishka, it seems that all advertising intervals now work as intended?
Albeit the longer intervals taking longer to connect, which is as expected.

In the case that I have understood you correct and both connecting with different advertising intervals and scan request notifications now are working as intended, I do not know what you would like me to take a look at in your provided sdk_config file. You mention that you are looking for a broken setting - what are you referring to here? What unexpected behavior are you seeing? Are you getting any errors?

Best regards,
Karl

[Jason]

Hi Karl, sorry I wasn't clear. 

Should I be able to connect using nrfconnect with 10 second advertising intervals?

(Assuming that I scan when an advert is transmitted)

[Karl Ylvisaker]

Hello Jason,

Jason said:

sorry I wasn't clear. 

No problem at all, I am just trying to understand you issue better so that I may help you resolve it.

Jason said:

Should I be able to connect using nrfconnect with 10 second advertising intervals?

Yes, you should be able to connect with a peripheral device advertising with a 10 second interval, if you happen to scan when the advertisement is being sent.
However, you should also keep in mind that it is not guaranteed that you central will pick up every advertisement being sent - a packet might be lost or corrupted due to interference from the environment, for example.
Therefore, it sometimes takes multiple packets to properly receive it, and start a connection.
Be advised that the maximal advertising interval is 10.24 seconds according to BLE spec, so you are not too far from the maximum when operating with 10 seconds.

As I understood your comment to Mishka you were able to get this working with the 10 seconds advertising interval - is this not correct? Is 10 seconds not working for you?

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)