Bluetooth advertising timeout needs to be modified

RE: Bluetooth advertising timeout needs to be modified

Edvin — Fri, 03 Feb 2023 09:05:45 GMT

Hello Craig,

Glad to hear it sorted out. I didn't test it, but I can't tell why it didn't work with your implementation of the ad[] struct. Perhaps there is something with the way the data parameter is set. It is the fact that the data variable inside ad[] is a pointer that is throwing you off, I think (at least it throws me off).

You can try doing something like this:

    uint8_t test_data[1] = {BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR};
    test_ad[0].type = BT_DATA_FLAGS;
    test_ad[0].data_len = 1u;
    test_ad[0].data = test_data;
    LOG_INF("test_ad[0] = 0x%02x", test_ad->data[0]);

I tried the way that you did initially, and it printed "test_ad[0] = 01", which will trigger the timeout since 0x01 = BT_LE_AD_LIMITED (and also your flags will be wrong).

Best regards,

Edvin

RE: Bluetooth advertising timeout needs to be modified

craig.goldman — Fri, 03 Feb 2023 04:23:40 GMT

Testing done.

I put a breakpoint in after "ad_is_limited(ad, ad_len)". The function is returning 'true'. When I examined the variable holding the advertising data, it looked wrong.

I modified the code to follow your suggestion and used "BT_DATA_BYTES" macro to load the struct bt_data with the advertising flags. RE-tested the code and Bluetooth no longer times out.

Edvin, thank you for help.

This case can be closed.

-Craig

RE: Bluetooth advertising timeout needs to be modified

craig.goldman — Thu, 02 Feb 2023 15:02:18 GMT

Edvin,

That is an excellent suggestion. There may be a one-day delay in getting this done, since I am committed to a meeting most of the day.

-Craig

RE: Bluetooth advertising timeout needs to be modified

Edvin — Thu, 02 Feb 2023 09:49:23 GMT

It looks like this format is a bit different to how it is implemented in our samples. It may work just fine, but it is difficult for me to say exactly why it behaves like it does based on this snippet. Can you please try to debug/add logging to see whether ad_is_limited() returns true inside bt_le_adv_start()?

	if (ad_is_limited(ad, ad_len)) {
		k_work_init_delayable(&adv->lim_adv_timeout_work, adv_timeout);
		k_work_reschedule(&adv->lim_adv_timeout_work,
				  K_SECONDS(CONFIG_BT_LIM_ADV_TIMEOUT));
	}

I suggest you figure out why the timer is started (lim_adv_timeout_work, adv_timeout), rather than figuring out whether it is restarted.

As far as I can tell, bt_le_adv_update_data() doesn't start/restart the advertising. It just updates the data that is used for advertising, so I don't think this will reset any timers.

The only way I see that "Failed to stop advertising" is printed to the log is inside adv_timeout(), and the only way this is triggered is from k_work_init_delayable(&adv->lim_adv_timeout_work, adv_timeout); inside the check for ad_is_limited().

Best regards,

Edvin

RE: Bluetooth advertising timeout needs to be modified

craig.goldman — Wed, 01 Feb 2023 16:27:31 GMT

Thank you for the respone but I don't use BT_LE_AD_LIMITED - just BT_LE_AD_GENERAL and BT_LE_AD_NO_BREDR

My advertising data looks like the following...
advertData[0].type = BT_DATA_FLAGS;
advertData[0].data_len = 1u;
advertData[0].data = (const void*)(BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR);
advertData[1].type = BT_DATA_NAME_COMPLETE;
advertData[1].data_len = 7u;
advertData[1].data = "Sensor";

(The actual device name string in the application is constucted from using the device serial number.)

I would rather disable the timeout, but other less desirable solutions could be used.
Do you know if the timeout re-starts if I periodically call "bt_le_adv_update_data"?
Is there a callback on advetising stop which I could use to re-start the advertising?

-Craig

RE: Bluetooth advertising timeout needs to be modified

Edvin — Wed, 01 Feb 2023 14:12:09 GMT

[quote user="craig.goldman"]The Noridic SDK allow the programmer to define advertising modes which include how timeout is handled.
("ble_advertising_config").[/quote]

Ah, you are talking about the nRF5 SDK when you say "Nordic SDK". I understand. (In some cases Nordic SDK can mean nRF Connect SDK, while Zephyr SDK is referred to as the pure Zephyr SDK (which is a standalone code base without nRF Connect SDK).

Regarding your question:

I see. This is not triggered in most (any?) of our samples, but I see that there is a timeout functionality that is started in bt_le_adv_start() if ad_is_limited() returns true. This returns true if the BT_LE_AD_LIMITED flag is set.

So if your advertising data is set up something like this:

static const struct bt_data ad[] = {
	BT_DATA_BYTES(BT_DATA_FLAGS, (BT_LE_AD_LIMITED | BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR)),
	BT_DATA(BT_DATA_NAME_COMPLETE, DEVICE_NAME, DEVICE_NAME_LEN),
};

Try to remove the BT_LE_AD_LIMITED, so that you are left with this:

static const struct bt_data ad[] = {
	BT_DATA_BYTES(BT_DATA_FLAGS, (BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR)),
	BT_DATA(BT_DATA_NAME_COMPLETE, DEVICE_NAME, DEVICE_NAME_LEN),
};

Then, the advertisements will not time out. Alternatively, if you want to change the duration of the timeout you can either leave the BT_LE_AD_LIMITED in, and configure the timeout by adding this config to your prj.conf:

CONFIG_BT_LIM_ADV_TIMEOUT 60

(change 60 with the number of seconds you want to use. The range is 1 to 180 seconds).

If you want something longer than 180 seconds, you should remove the BT_LE_AD_LIMITED, and start a timer to stop the advertisements manually.

The log warning "Failed to stop advertising: 0" looks very much like a bug from Zephyr. It looks like it was supposed to check the return value (err) before printing that. If it is printed with the value 0, it means that it successfully stopped the advertisements.

Best regards,

Edvin

RE: Bluetooth advertising timeout needs to be modified

craig.goldman — Tue, 31 Jan 2023 18:51:08 GMT

Unfortuantely, the application requires specialized hardware connected to the nRF52840 to run; it is also 1000's of lines of code (not including SDK and Zephyr library files) spread over 56 files.
If needed, I can send the file which calls "bt_le-adv_start".

I believe advertsiing has stopped for two reasons
* I am using the J-Link RTT Viewer to monitor code logging.
I get the following log entry: 00> [00:00:54.335,479] <wrn> bt_adv: Failed to stop advertising: 0
The source of this is in "adv.c" following a call to "bt_le_adv_stop"; the error code of 0 indicates success
(BTW this is a really poor debugging message to get on success.)
* I am using NRF Connect App running on an iPAD to monitor advertsing and to connect to the running code.
If I start NRF Connect after I get the warning message, I view no advetrtisements from the device.
If I start NRF Connect earlier, I can see the bluetooth advertisements on NRF Connect screen.

The Noridic SDK allow the programmer to define advertising modes which include how timeout is handled.
("ble_advertising_config"). I was referring to the documentation for "ble_advertising_start" which can select one of those modes. I do not see an API specifically for changing the advertising timeout.

Please remember that I am starting bluetooth advertising using "bt_le_adv_start", which is a Zephyr library call.
This was used in the Nordic UART Service example I followed to create the application.

Thank you
-Craig

RE: Bluetooth advertising timeout needs to be modified

Edvin — Tue, 31 Jan 2023 12:00:35 GMT

Hello,

By default the BLE advertisements doesn't time out in NCS (unless that changed recently). Are you sure they time out? How do you know that it does? What do you observe? Is it possible to send the application that you are currently working on so that I can have a look?

[quote user=""]I've noticed that the Nordic SDK has functions which allow for changing of the timeout value; can I mix Zephyr API calls and Nordic SDK API calls?[/quote]

What API do you refer to?

Best regards,

Edvin