Extended Advertising - reception and data size

[axel_s]

Hi,

I recently started with nRF52840-DK, Zephyr and nRF Connect SDK (v. 1.9.1). I want to test extended advertising. Since there is no example of "pure" extended advertising (i.e. no periodic), I modified the periodic_adv example. Modification is quite easy: In prj.conf setting CONFIG_BT_PER_ADV=n, in main.c skipping bt_le_per_adv_set_param() and bt_le_per_adv_start(), usage of bt_le_ext_adv_set_data() instead of bt_le_per_adv_set_data(). Now extended advertising runs well. With a Sodera sniffer, I can see three ADV_EXT_IND frames in channels 37/38/39, followed by an AUX_ADV_IND frame in one of the data channels. The AUX_ADV_IND frame contains two AD elements: One with the data I want to transmit and one with the complete local name as set in prj.conf.

For reception, I use the periodic_sync example, which should support extended advertising without the periodic functionality too.

Now the questions:

My receiver calls the scan_recv function, but always I see only one of the AD elements. The buffer contains only the AD element with the local name, which is the last one in the frame (according to the sniffer raw data). There is no indication of the reception of my data in the second AD element. What have I to do to receive both (or even more) AD elements? What is the intention here - to have several calls of scan_recv for every AD element or to have a list of buffers or something else?

[Simonr]

Hi

You want to print the advertising data from more than one element, when scanning, is that right? Since the scan_recv only prints one element per call, you can either edit the function to print multiple elements from the buffer every call, or call the scan_recv() function multiple times I guess.

Best regards,

Simon

[axel_s]

Hi,

I wonder what might change since last week in the stack. Regarding the extended advertising, I don't receive any data right now. For test, I used my periodic example, which worked well last Thursday - the sniffer now shows a number of "truncated data" messages in different frames, and I see now AUX_CHAIN_IND frames, which were definitely not present last week. Are there again some funny changes regarding the data length possible for extended advertising or data handling in the stack? Frustrating...

[axel_s]

Hi Simonr,

calling scan_recv) multiple times is no option for me. It's the call-back function, the calls is done inside the stack, and I will use the stack, not modify it.

Currently (and in contrast to the situation before my initial post), when scan_recv() is called, buf->len is always 0. Since there are some other strange thing happening (I tested my periodic example from last week, and it doesn't run anymore, I found a number of things changed also in the transmitted data), I assume that there goes something wrong inside the stack. I'll have some days off anyway, so I'll test it next week and maybe I'll come back here.