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!

Parents
  • Hallo Hung Bui,

    regarding the call_backs you're completely right. I missed that point, sorry.

    But now I've some more questions, this time related to the amount of data to be transmitted.

    When I use periodic advertising, the function bt_le_per_adv_set_data() updates the data to be transmitted. Extending the mfg_data[] in the example, I found that the maximum length of mfg_data[] is 60. With length 61, data updating fails with (err -5). In BB, the whole AUX_SYNC_IND frame is of length 74 (for 60 data bytes), which is much less than the 255 octets I expect from the BT 5.0 spec.

    remark 1: In gap.h there is a constant BT_GAP_ADV_MAX_EXT_ADV_DATA_LEN = 1650, which is the data length in case of chaining the advertising according to BT 5.0. Up to now, I didn't find another constant somehow limiting the data size of a single extended advertising frame.

    remark 2: A similar behaviour I see when I skip the periodic option, going to simple extended advertising. In this case the maximum length of mfg_data[] is 55 bytes only. That this is less than with periodic advertising is ok due to the fact that I have two data elements in the packet, data and the device name (in my test case three letters only). But the general fact is identical to the periodic advertising - I would expect more data to be transmitted.

    Therefore the question: What have I to do to reach the maximum number of data bytes in the advertising frames?

    Thanks!

  • Hi Axel, 

    Please try to set CONFIG_BT_CTLR_ADV_DATA_LEN_MAX to the size you want to use. 


    It's more likely the issue on the configuration of the controller (the lower stack). 

  • 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. 

Reply Children
  • 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.

  • 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. 

Related