Periodic Advertising

[axel_s]

Hi,

I recently started with nRF52840-DK, Zephyr and nRF Connect SDK (v. 1.9.1). I want to test extended advertising, that's why I use the periodic_adv example coming with thr SDK. Compiling and downloading without problems, I see in the terminal the printed outputs, mainly the counting of the simple counter in the example.

Using a Sodera sniffer, I see the three advertising frames in channels 37/38/39 of type ADV_EXT_IND, as well as the frame in one of the data channels (channel given in the advertising frames) of type AUX_ADV_IND (this frame includes too the device name I can set in the prj.conf).  What I don't see is the data, which I would expect to be in a frame shortly after AUX_ADV_IND.

When I use the periodic_sync example for reception, I'm informed too about the existence of a device with the given name (I assume that I'll receive only the data channels). But again, there is no data frame.

What have I missed to configure to be able to send data in the extended advertising?

Thanks!

[Hung Bui]

Thanks for your feedback. I faced the same challenge and couldn't find a good way of exploring those configurations. Many times it's pretty frustration especially when the source code is not available to figure out what exact condition causing the error.

I guess doing a CTRL+F at the webpage you pointed to and look for CONFIG_BT_CTLR would filter most of the Bluetooth configurations for the controller and you can start from there. 

[axel_s]

Hi Hung Bui,

meanwhile I did some tests without the periodic option. Last week there were some open points, but today I found my code behaving completely different (e.g. in the scan_recv() call-back function buf->len is always 0). Therefore, I took my periodic example from last week - and it's behaviour has changed too. Last week I found 3xADV_EXT_IND, one AUX_ADV_IND (containing the complete local name) and one AUX_SYNC_IND (containing the data). Now I find 3xAUX_EXT_IND, one AUX_ADV_IND (containing the data) and one AUX_CHAIN_IND (containing the complete local name).  This is strange and quite frustrating - I already opened a separate ticket. Do you know what happened here?

Thanks, Axel

[Hung Bui]

Hi Axel, 

I'm not sure why it changed like that. But from my point of view AUX_CHAIN_IND  is used when the length of the data exceed the maximum data to send in one packet and our stack will automatically change the advertising to chained advertising. Could you try to test with smaller data size ? Maybe the stock example when only 3 bytes are sent ? 

[Starbuck]

Hi Hung Bui,

In my application I need to receive 600 bytes, which requires chaining the periodic advertisements.  I’m using these same periodic advertising samples, but for NCS v 2.3.0 rc1.

My issue is that the network buffer in the .recv (recv_cb() function in periodic_sync ) doesn’t seem to support packets greater than 254 bytes.  Do you know if there’s a Kconfig option that I need to set to be able to receive 600 bytes as 1 report?

Thanks!

[Hung Bui]

Hi Starbuck, 
Please create a new ticket if you have an issue. 
You can have a look at my example here: RE: Advertising 1650 bytes of Host advertising data in an Auxiliary segment using Advertising Extensions 

I sent 800 bytes using chained advertising. The trick is to split them into smaller   BT_DATA.