This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Secondary channel index in extended advertising using nRF Connect SDK

Hello!!

I have explored extended advertising using both nRF5 SDK and nRF Connect SDK. Using nRF5 SDK, it is not possible to advertise 1650 bytes in an extended advertising event, hence it only uses one AUX_IND_PDU and one AUX_CHAIN_PDU to advertise 255 bytes of data. As observed at the sniffer, the advertising channels used by these two auxiliary packets are completely random. 

However, as I moved to nRF Connect SDK and again used advertising extensions, I was able to use the entire 1650 bytes of space in an extended advertising event, with the guidance of the Nordic Dev team. But now, the problem is, all the auxiliary packets are transmitted on channel index 25 only, as checked with nRF52840! As shown in the sniffer screenshot attached, all the 7 auxiliary packets use the same channel. The index is always 25, even if I use a different dev kit.

Why is this channel fixed in nRF Connect SDK? Is it possible to randomize the secondary channel selection in extended advertising?

Hope to hear from the team soon..

Thanks! Slight smile

Parents
  • Hi

    Okay, so it does indeed seem you're right. For the nRF Connect SDK we changed the implementation when adding support for periodic advertising to use a channel selection algorithm, but we didn't consider that this would make the channel selection deterministic. We will change this for future releases. Unfortunately, this is not something you can change from your end as the channel selection is done in the SoftDevice controller.

    Best regards,

    Simon

    UPDATE: A fix has been implemented, reviewed and merged, and we expect it to be available in the next NCS version.

Reply
  • Hi

    Okay, so it does indeed seem you're right. For the nRF Connect SDK we changed the implementation when adding support for periodic advertising to use a channel selection algorithm, but we didn't consider that this would make the channel selection deterministic. We will change this for future releases. Unfortunately, this is not something you can change from your end as the channel selection is done in the SoftDevice controller.

    Best regards,

    Simon

    UPDATE: A fix has been implemented, reviewed and merged, and we expect it to be available in the next NCS version.

Children
Related