Automatic connection to closest device

[RakeLund]

We have a system with a central device and a peripheral both based on nrf5340. The central device is also a Broadcast source and the peripheral is also a Broadcast sink in addition to the ACL connection. The current firmware version has a hardcoded name for the peripheral to look for and connect to to get the system up and running automatically, but this won't work in the long run as we would like the system to be more flexible. 

We can use a standard method of scanning for nearby devices and a user chooses a peripheral to connect to. But ideally we would like an automatic connection to the peripheral when it gets close to the central. 

I had an idea of using the RSSI to determine which devices are closest to each other in the event of several central devices or several peripherals being close. The central device could measure the RSSI values and choose the one with the strongest signal, as this will likely be closest, but in the event of 2 central devices I'm not sure how this would work. I assume it would be a bit random which central is able to initiate a connection first?
I was thinking about setting a treshold RSSI value for when the central can initiate a connection, but how far apart would the centrals then need to be to be able to reliably make the right choice (of getting the closest peripheral/central pair to connect)? I know RSSI is not a super reliable measurement, but maybe it would be good enough if we can set the treshold at a quite high signal strength and set some limitations on how close together two centrals can be?

I've also been looking a little bit into the distance toolbox and it seems that there are some more accurate ways of measuring distance where we could let the peripheral find out which central it is closest to and do direct advertising. Would this require a lot of extra resources from our devices? I am not sure if it's realistic to be able to integrate this in our LE Audio devices.

I will of course do some experimenting myself (and have already started), but would be great to have some input on the most realistic solutions if possible

[Amanda Hsieh]

Hi, 

You're correct that RSSI can be used to determine proximity, but it's not always reliable. I think you can check out my colleague's suggestion in this post and this post. 

As for distance measurement, you can take a look at this Bluetooth: nRF Distance Measurement with Bluetooth LE discovery sample which also supports nRF5340. I would double-check with the developer for compatibility with the LE Audio implementation.  

Regards,
Amanda H.

[RakeLund]

Hi again!  

I did have a look at the links you sent when you replied, but forgot to give you a reply, sorry! The first link is broken, not sure what it was supposed to link to. 

I looked into the distance measurement toolbox, but I don't really think it's a good match with LE Audio unless it is only used before enabling the broadcast source.

I have experimented with using RSSI values and used the mode of the values as recommended by bluetooth SIG https://www.bluetooth.com/blog/proximity-and-rssi/. This seems to work quite well for connecting automatically when a peripheral is close to the central device (within ~1m).
The downside is that for it to work we have to spend some time collecting samples to have something to filter before initiating the connection. This is not really an issue when our device is only focusing on scanning, but while the broadcast audio is active the broadcasting seems to take most of the bluetooth radio capacity (or MCU capacity?) and I only receive 1 advertisement packet every 1-2 seconds. 

Is this expected behavior when combining advertising and scanning? Should it theoretically be possible to get more advertisement samples quicker without stopping the audio broadcast or is this as good as it gets? 

[Amanda Hsieh]

Hi, 

Not sure I understand this correctly or not. Would you like to do the scan on the broadcaster while broadcasting?

Since our broadcaster's default setting is using 48KH 96kbps stereo channel output and retransmission time = 2 (which means 120bytes x 3 times per channel per 10ms), this would occupy a lot of airtime. You could lower the bitrate, e.g., using 48kbps or 32kbps, which makes the payload size smaller, so we have more time for scanning, but that will also lower the audio quality.

Could you elaborate in more detail about your use case? It is very likely the radio capacity that is limiting. You can also reduce the number of retransmissions to 1 (a total of 2 transmissions), and also check the MCU load just to be sure using standard Zephyr tools.

-Amanda H.

[RakeLund]

I would like to be able to scan for a peripheral to set up an ACL connection while the audio broadcast is running.

I think the current bitrate is 32kbps actually I'll check, and I'm not sure about the number of retransmissions, so I'll have a look at that as well. Is this set by a configuration parameter or should it be part of the application code?

As far as I've understood it earlier, it should be possible to run more than one audio broadcast channel at the same time, but does this mean that this will also be hard to achieve in practise because of how much airtime one stream occupies?

[Amanda Hsieh]

This is very similar to our default setting in broadcaster:

As we can see, the broadcast stream occupied more than 40 % of airtime. So Lowering the retransmission time and bitrate could help.