Periodic Advertising

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!

  • Hallo Hung Bui,

    I can't believe that this is the answer. Currently (and this is a setting I never changed, so I assume it's a kind of default), CONFIG_BT_CTLR_ADV_DATA_LEN_MAX is set to 31. This value is far away from the 60 bytes I can successfully transmit with periodic advertising.

  • Hi Axel, 
    It actually worked for me. 
    I set this CONFIG_BT_CTLR_ADV_DATA_LEN_MAX=200 

    And then can send 170Byte in my periodic advertising packet: 



    Please make sure you flashed the netcore after you rebuild (if you are using nRF53). 

  • Hi Hung Bui,

    you're right, it's working now. In this case I don't understand the meaning of CONFIG_BT_CTLR_ADV_DATA_LEN_MAX - it worked well with 60 data bytes when set to 31. Anyway, I set CONFIG_BT_CTLR_ADV_DATA_LEN_MAX=255 and can now send up to 249 data bytes, verified with the sniffer.

    But reception doesn't work any more. Here too I set CONFIG_BT_CTLR_ADV_DATA_LEN_MAX=255. The reception of the "old" 60 data bytes is ok, but 249 doesn't work at all without any error message. Maybe there is a setting for size of buf?

  • Maybe you can have a look at this case  https://devzone.nordicsemi.com/f/nordic-q-a/85571/sync-fail-for-periodic-advertisement ? CONFIG_BT_CTLR_SCAN_DATA_LEN_MAX  may need to be configured. 

    In my case I do receive the receive report but couldn't print the string normally. I have to manually printout the raw data as hex integer instead of using the bin2hex command to print the data as string. 

  • Hi Hung Bui,

    yes, now it works. I set both values, CONFIG_BT_CTLR_ADV_DATA_LEN_MAX and CONFIG_BT_CTLR_SCAN_DATA_LEN_MAX to 255. Funnily, the advertiser can handle data size up to 249 Bytes correctly, the periodic_sync receiver data size up to 245 bytes. But both values are ok now.

    I faces the same issue regarding the printing, but I will not go into this now.

    Thanks for your help!

    A last thing: It took a while finding the CONFIG_BT_CTLR_ADV_DATA_LEN_MAX and CONFIG_BT_CTLR_SCAN_DATA_LEN_MAX config options in my case. At webpage https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.9.0/kconfig/index-zephyr.html one can find probably several hundrets of options, but listed alphabetically. It would be quite nice for programmers to have consolidated lists of options, which might be of interest for some specific issues (simple advertising, extended advertising, periodic advertising and so on). Are there such lists? Otherwise, many people will ask the same questions, have extensively to search for information in fora etc. It's the same for me - the data size issue is solved now, but when I'm going forward maybe to timing issues I'm quite sure that I'll be back on search for config options. This way of programming is sometimes quite frustrating and could be eased a lot by better documentation.

Related