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

Connection attempt after advertisement type has changed

Hi, I'm in the process of systemizing a protocol for a product where we have the need to use different types of advertisements. There is one periodic connectable advertisement message with a longer period used for establishing a connection tonthe device. In the periods in between connectable advertisements we need to send som additional advertisement messages as non-connectable beacon messages. The way I understand it is that the application needs to manage this itself. That is,

  1. start sending connectable advertisement and stopping it,
  2. set a timer for the adv interval,
  3. send non-connectable advertisements with a lower interval,
  4. timer callback is triggered where we go back to 1.

The first question is: Is the above method or something similar the way to go when multiple concurrent advertisements are needed? I know that the time-slot API is also an option but what we are trying to achieve is a protocol that I would like to keep HW agnostic.

Secondly I'm wondering what happens if a Central device wants to connect after receiving an advertisement message? the way I understand it is that the connection request will be sent in the peripherals RX slot in the next advertisement event. The problem I see is that it will not receive a connectable advertisement message but several non-connectable advertisement messages before the next long period connectable advertisement. Will the connection attempt fail or will it wait until next connectable advertisement from the same device?

  • Hi,

    Is the above method or something similar the way to go when multiple concurrent advertisements are needed?

    Yes, this is a common approach.

    Will the connection attempt fail or will it wait until next connectable advertisement from the same device?

    As long as connectable advertisement occurs within the timeout it should be no problem. It could be that some central implementations handle this differently, but as mentioned it is a common approach and I do not recall reading about any such issues.

Related