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!

Parents

0 Simonr over 3 years ago

Hi

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
Cancel
Vote Up 0 Vote Down

Cancel
0 Sukriti over 3 years ago in reply to Simonr

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
Cancel
Vote Up 0 Vote Down

Cancel

Reply

0 Sukriti over 3 years ago in reply to Simonr

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
Cancel
Vote Up 0 Vote Down

Cancel

Children

No Data