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!

  • Hi Axel, 


    I suspect that the sniffer was not able to follow and sync with the periodic advertising from the device. 

    I did a quick test here with the periodic_sync sample and can get this log: 

    Notice the manufacturer data increment from 1 to 3 in the log. This matched with what coded in the periodic_adv sample. 

    At the beginning when I tested the example out of the box the periodic_sync always failed immediately after the sync established. I found that it might be due to too short timeout. By default it's set to 0x0a  (100ms): 
    https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/bluetooth/periodic_sync/src/main.c#L232

    But the adv interval is 1200ms. 

    So I changed the sync_create_param.timeout to 0xa00 and can follow and capture the periodic adv data. 

  • Hi Hung Bui,

    thanks for your suggestion, which at least took me a step forward.

    Now I can find some frames of type AUX_SYNC_IND, which finally also include data. But what I see again raises questions.

    First, but minor issue: As long as the varying data part (mfg_data[2] in the example) = 0, there are no data added, the data section remains empty. Data inclusion starts with mfg_data[2] = 1. Why?

    Second issue: How can I access the data to do the output myself resp. work with the data further one? Data handling for now is hidden in the stack.

    Thanks!

  • Hi Axel, 

    axel_s said:
    As long as the varying data part (mfg_data[2] in the example) = 0, there are no data added, the data section remains empty. Data inclusion starts with mfg_data[2] = 1. Why?

    I think this happens because it's a bug in the periodic_adv code. There were no call to set the data bt_le_per_adv_set_data() before the first 10 seconds sleep elapsed. See here: 

    So only after the mfg_data[2] was increased from 0 to 1 then it will be added to the advertising data. 

    You can call bt_le_per_adv_set_data() before the while loop so that you can see the 0xff ff 00 data. 

    axel_s said:
    How can I access the data to do the output myself resp. work with the data further one? Data handling for now is hidden in the stack.

    How did you print data out ? The data handling is done inside the stack but in the application you should receive the callback .recv (recv_cb() function in periodic_sync ) and you should be able to process the data there. The same way as how we print the log out as I showed in my screenshot earlier (it's from the periodic_sync code)

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

Related