Extended Advertising - reception and data size

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?

Parents
  • Hi

    Okay, that sounds strange if you didn't make any changes to the project (or the transmitter). I'll set the case to waiting then. Let me know when you come back and what the status is.

    Best regards,

    Simon

  • Hi Simonr,

    meanwhile, the old periodic examples are running well again, don't know why, and I started to work on extended advertising. I found that I can receive up to 227 Byte of data (transmitted with the modified periodic advertiser as mentioned above, which means also with the data structure used there). This border comes from the net_buf_simple_max_len, which is 229 by default. I wonder why such numbers can occur, and I will have to find a way to extend this buffer size, so I can transmit more than 227 Byte. Without a separate AD element with a name, i.e. without the BT_LE_ADV_OPT_USE_NAME option in the advertiser, I can send 249 Byte of data. This is the number I try to receive too, or at least the 245 Byte I receive with periodic advertising.

    Why are there different numbers for data size in advertising and scan/reception?

Reply
  • Hi Simonr,

    meanwhile, the old periodic examples are running well again, don't know why, and I started to work on extended advertising. I found that I can receive up to 227 Byte of data (transmitted with the modified periodic advertiser as mentioned above, which means also with the data structure used there). This border comes from the net_buf_simple_max_len, which is 229 by default. I wonder why such numbers can occur, and I will have to find a way to extend this buffer size, so I can transmit more than 227 Byte. Without a separate AD element with a name, i.e. without the BT_LE_ADV_OPT_USE_NAME option in the advertiser, I can send 249 Byte of data. This is the number I try to receive too, or at least the 245 Byte I receive with periodic advertising.

    Why are there different numbers for data size in advertising and scan/reception?

Children
No Data
Related