Periodic Advertising

[axel_s]

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!

[axel_s]

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!

[Hung Bui]

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

[axel_s]

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.

[Hung Bui]

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

[axel_s]

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?

[Hung Bui]

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.