Secondary channel index in extended advertising using nRF Connect SDK

RE: Secondary channel index in extended advertising using nRF Connect SDK

Sukriti — Wed, 15 Jun 2022 18:20:19 GMT

Thanks a lot for looking into this Simon! Shall wait for the update in the next version..

RE: Secondary channel index in extended advertising using nRF Connect SDK

Simonr — Wed, 15 Jun 2022 08:58:05 GMT

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.

RE: Secondary channel index in extended advertising using nRF Connect SDK

Sukriti — Mon, 13 Jun 2022 12:37:22 GMT

Hi Simon,

I have attached the trace. Are you able to access it? Or should I post screenshots instead?

devzone.nordicsemi.com/.../Wireshark-Trace.zip

RE: Secondary channel index in extended advertising using nRF Connect SDK

Simonr — Mon, 13 Jun 2022 11:36:02 GMT

Oh, I see. Yes, we can see this behavior on our side as well. Thank you for specifying your issue. This is a channel mapping done in the link layer, so it's not configurable I'm afraid, but I agree that this sounds like an issue as they shouldn't always have the same pattern. I have asked the developers internally now, and I'm currently waiting for a response from them. I'll keep you updated.

Can you upload the full sniffer trace of the "only channel 25" advertisements for us as well?

Best regards,

Simon

RE: Secondary channel index in extended advertising using nRF Connect SDK

Sukriti — Fri, 10 Jun 2022 19:10:32 GMT

Hi Simon!

Thank you so much for attaching the screenshot. This just made things a lot clearer to me and made me realize that I did not provide you the full background.

So basically, I am advertising data that changes dynamically with time. For this, I set the number of events in the advertising data set to 1. For advertising each extended advertising event with updated data, this advertising data set gets re-configured, allowing exactly one event to take place. This ensures that any unique data does not get advertised more than once.

With the number of advertising events inside the advertising set restricted to 1, this is the sniffer screenshot:

As you can see, the Auxiliary PDUs are always transmitted on the same channel, indexed 25.

Looking at your results with Hung's code, I increased the number of events in my code from 1 to 3. This is what I obtained at the sniffer then..

Now, here, I observed a pattern. The Auxiliary chain channel index changed from 25 to 20 and then to 6 in the first three extended advertising events. After this, the advertising data set got re-configured, and the next three extended advertising events also followed exactly the same pattern of secondary channels 25 -> 20 -> 6.

Next, I also checked the secondary channels with Hung's code, and this was the output:

Here, the advertising data set got configured only once, in the beginning, and all the events were advertised without the set getting re-configured. Clearly, upon set configuration, the first extended advertising event uses the secondary channel 25, the next one uses 20, next uses 6 and so on.. Exactly the same sequence of secondary channels.

Now as far as I understood, whenever I'll configure an advertising set, the secondary channels are going to change for every extended advertising event following this specific pattern that I showed in the previous two examples. I was re-configuring the advertising data set for sending out each extended advertising event and this is why the entire Auxiliary chain always used channel index 25.

But, in nRF5 SDK also, I had used the exactly same approach of setting the number of events in an advertising set to 1 and then re-configuring the advertising set for each extended advertising event. But as you can see in the figure attached below, there is no fixed pattern and in fact, the packets within the Auxiliary segment are also advertised on different channels, unlike nRF Connect SDK where the entire auxiliary chain uses the same secondary channel.

Is there a way to achieve this type of randomization in nRF Connect SDK? If not, is it at least possible to not have a fixed pattern of secondary channels inside the advertising data set? I would definitely not want to advertise the entire data on the same channel.

I hope I conveyed everything clearly. Waiting for your response!

Thanks,

Sukriti

RE: Secondary channel index in extended advertising using nRF Connect SDK

Simonr — Fri, 10 Jun 2022 08:40:22 GMT

After a quick test on our side, we did not see this issue. Every different chained advertisement changes the channel, and there shouldn't be a configuration to set a specific channel AFAIK. This test was done with the project Hung uploaded in your last ticket.

To me it sounds like you get channel 25 as the auxiliary channel no matter what you do, is that correct? If so, can you upload the full sniffer trace here so we can take a look? If it's the case that you're just worried that one channel is used for the entire chained advertisement, then that is expected, as each chained advertisement will "choose" a channel to send the entire chain on, and then it should choose another channel for the next chained advertisement.

Also, what nRF Connect SDK version are you using for your project? We tested in v1.9.1.

Best regards,

Simon