This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Device identity list issue

I have a peripheral and central that bond with each other. Now until I had peripheral stop advertising on first connection, it was all fine. Now this peripheral needs to connect to 2 centrals. From what I understand the way device identity list works, SD will try to resolve using IRKs and return on first match. Problem is, my central connects to same peripheral twice. Is there some way to prevent same peripheral from connecting to central if it's already connected?

Parents
  • Typically the way this kind of problem is solved is by having the peripheral use two gap addresses, but that typically require some user input on the peripheral such that the peripheral will advertise with the gap address depending on which central it may want to connect to at any time. The user then would need to choose which of the two gap addresses that should be used during bonding also. I guess you may have seen some products with a '1' and a '2' switch that show which to connect to. It could still connect to two central's at the same time (altering advertisement by stop, update gap address and start advertisement at regular intervals), but the user would still need to actively choose which of '1' and '2' should be used during bonding.

    The other way I can think of this is solved is to update the whitelist before advertising, e.g. you may manipulate the whitelist by removing the already connected peer. 

Reply
  • Typically the way this kind of problem is solved is by having the peripheral use two gap addresses, but that typically require some user input on the peripheral such that the peripheral will advertise with the gap address depending on which central it may want to connect to at any time. The user then would need to choose which of the two gap addresses that should be used during bonding also. I guess you may have seen some products with a '1' and a '2' switch that show which to connect to. It could still connect to two central's at the same time (altering advertisement by stop, update gap address and start advertisement at regular intervals), but the user would still need to actively choose which of '1' and '2' should be used during bonding.

    The other way I can think of this is solved is to update the whitelist before advertising, e.g. you may manipulate the whitelist by removing the already connected peer. 

Children
  • Option 1 doesn't scale, since eventually we need 4+ connections at same time. Option 2 is something that almost currently works. I don't remove anything from whitelist but mark which peers are already connected. It doesn't work though, because if you use private random resolvable address, you can't know if you are already connected to the device that's advertising since after a period of time it will change.

  • Good point, option 1 won't scale no.

    Darkenkade said:
    It doesn't work though, because if you use private random resolvable address, you can't know if you are already connected to the device that's advertising since after a period of time it will change.

    Hmmm, can you update/prepare the whitelist (even if not used yet) when you connect to a peer?

    Edit: What I mean is the when you connect to a peer using resolvable address, it is the IRK that was used to allow the connection with the peer, so you would need to remove that specific IRK from the whitelist used next when advertising. Maybe something like that can work?

Related