Periodic Advertising

RE: Periodic Advertising

Hung Bui — Mon, 27 Feb 2023 15:19:42 GMT

Hi Starbuck,
Please create a new ticket if you have an issue.
You can have a look at my example here: RE: Advertising 1650 bytes of Host advertising data in an Auxiliary segment using Advertising Extensions

I sent 800 bytes using chained advertising. The trick is to split them into smaller BT_DATA.

RE: Periodic Advertising

Starbuck — Mon, 27 Feb 2023 12:58:29 GMT

Hi Hung Bui,

In my application I need to receive 600 bytes, which requires chaining the periodic advertisements. I’m using these same periodic advertising samples, but for NCS v 2.3.0 rc1.

My issue is that the network buffer in the .recv (recv_cb() function in periodic_sync ) doesn’t seem to support packets greater than 254 bytes. Do you know if there’s a Kconfig option that I need to set to be able to receive 600 bytes as 1 report?

Thanks!

RE: Periodic Advertising

Hung Bui — Wed, 25 May 2022 13:03:12 GMT

Hi Axel,

I'm not sure why it changed like that. But from my point of view AUX_CHAIN_IND is used when the length of the data exceed the maximum data to send in one packet and our stack will automatically change the advertising to chained advertising. Could you try to test with smaller data size ? Maybe the stock example when only 3 bytes are sent ?

RE: Periodic Advertising

axel_s — Tue, 24 May 2022 11:33:43 GMT

Hi Hung Bui,

meanwhile I did some tests without the periodic option. Last week there were some open points, but today I found my code behaving completely different (e.g. in the scan_recv() call-back function buf->len is always 0). Therefore, I took my periodic example from last week - and it's behaviour has changed too. Last week I found 3xADV_EXT_IND, one AUX_ADV_IND (containing the complete local name) and one AUX_SYNC_IND (containing the data). Now I find 3xAUX_EXT_IND, one AUX_ADV_IND (containing the data) and one AUX_CHAIN_IND (containing the complete local name). This is strange and quite frustrating - I already opened a separate ticket. Do you know what happened here?

Thanks, Axel

RE: Periodic Advertising

Hung Bui — Thu, 19 May 2022 12:36:08 GMT

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.

RE: Periodic Advertising

axel_s — Thu, 19 May 2022 12:17:17 GMT

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.

RE: Periodic Advertising

Hung Bui — Thu, 19 May 2022 09:24:08 GMT

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.

RE: Periodic Advertising

axel_s — Thu, 19 May 2022 09:00:33 GMT

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?

RE: Periodic Advertising

Hung Bui — Thu, 19 May 2022 07:34:30 GMT

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

RE: Periodic Advertising

axel_s — Thu, 19 May 2022 07:16:22 GMT

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.

RE: Periodic Advertising

Hung Bui — Wed, 18 May 2022 12:28:37 GMT

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

RE: Periodic Advertising

axel_s — Tue, 17 May 2022 08:30:06 GMT

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!

RE: Periodic Advertising

Hung Bui — Thu, 12 May 2022 10:52:53 GMT

Hi Axel,

[quote user="axel_s"]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?[/quote]

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.

[quote user="axel_s"]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.[/quote]

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)

RE: Periodic Advertising

axel_s — Thu, 12 May 2022 09:21:02 GMT

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!

RE: Periodic Advertising

Hung Bui — Wed, 11 May 2022 12:03:10 GMT

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.