Updating data in chained periodic advertising (1,650 bytes)

RE: Updating data in chained periodic advertising (1,650 bytes)

Starbuck — Mon, 27 Feb 2023 21:53:06 GMT

I'm trying to do the exact same thing you are (only using NCS v2.3.0 rc1) and I'm running into the exact same issues and have the same concerns. Just curious, were you able to resolve the issue by changing the data through multiple calls to the API?

I was going to create a new ticket, but it would be a copy of this one. Great job explaining your concerns!

Best regards,

Starbuck

RE: Updating data in chained periodic advertising (1,650 bytes)

Sukriti — Wed, 05 Oct 2022 14:13:03 GMT

Thank you so much Edvin, I will try changing the data through multiple calls to the API as you suggested.

RE: Updating data in chained periodic advertising (1,650 bytes)

Edvin — Wed, 05 Oct 2022 11:59:43 GMT

Ok, so I discussed this with our SoftDevice Controller team, and I will try to summarize it here.

As I mentioned, there is a check inside bt_le_per_adv_set_data() that returns an error if the "total_len_bytes > BT_HCI_LE_PER_ADV_FRAG_MAX_LEN".

I asked them what would be the way to do it if you wanted to change all (up to 1650 bytes) at once, which would be a reasonable thing to want to do. They replied that you can't do this. That is:

"You can change all advertising data at once, but only if the total advertising data length is less than or equal to 252 bytes. The reason you cannot use more is that if you have more than 252 bytes, the data will have to be forwarded to the controller in multiple steps due to the fact that HCI packets have a maximum packet length."

So I interpret this as: You need to change the advertising in multiple calls to bt_le_per_adv_set_data(). You can do so as fast or as slow as you like, but the HCI messages that are sent from the controller to the Bluetooth Low Energy stack can max hold 252 bytes (of payload).

So you can try to update the data in chunks of 252 bytes, and iterate through the entire advertising data set.

Best regards,

Edvin

RE: Updating data in chained periodic advertising (1,650 bytes)

Sukriti — Wed, 05 Oct 2022 06:35:58 GMT

Thank you Edvin 🙂

RE: Updating data in chained periodic advertising (1,650 bytes)

Edvin — Tue, 04 Oct 2022 10:03:38 GMT

Ok, I understand Suktiti,

It is a bit difficult to keep track when that much time passes by, and I may not be that good at reading all the previous replies in a case. Please understand that we try to handle many (!) questions every day.

I will check with our SoftDevice controller team how it is intended to update chained advertisements larger than BT_HCI_LE_PER_ADV_FRAG_MAX_LEN bytes (252 bytes). I will keep you posted.

Best regards,

Edvin

RE: Updating data in chained periodic advertising (1,650 bytes)

Sukriti — Mon, 03 Oct 2022 07:08:17 GMT

Edvin, the entire concern is about the API bt_le_per_adv_set_data(). Yes, I can send 1650 bytes of data, but this data does not get updated using this API if packet chaining comes into the picture. What you have shown here is about the extended advertising API, which I have not talked about anywhere in the entire query.

You have quoted it three times but my concern is not related to the API that you are quoting. Also, if I have to stop advertising and re-start it for updating the data in periodic advertisements as well, this essentially means that I am re-establishing the sync everytime I wish to update the data. Specification does not say this. Infact, the Bluetooth SIG explicitly states in each of its official documents, that periodic advertising events can carry varying payload.

This has not been said anywhere for extended advertisements.

I'll quote a statement from one of the SIG documents:

Advertising takes place at fixed intervals called the periodic advertising interval and the advertising data payload may change

The re-start thing that you have shown three times is nowhere written for the periodic advertising APIs. Also, I have been asking again only because there has not been a single crisp answer telling me whether at all it's possible to send unique data each time using periodic advertising events, because it is not happening right now using the bt_le_per_adv_set_data() API for large data. It only happens for small payload sizes that fit into a single PDU.

[quote userid="26071" url="~/f/nordic-q-a/92514/updating-data-in-chained-periodic-advertising-1-650-bytes/388895"]Did you try using bt_le_per_adv_set_data()[/quote]

Yes Edvin, if you read through my query properly, I have used this API only, and have talked about it multiple times.

Thanks
Sukriti

RE: Updating data in chained periodic advertising (1,650 bytes)

Edvin — Mon, 03 Oct 2022 06:41:17 GMT

Hello Sukriti,

Did you try to stop -> reinitialize -> and start the advertisements again? I don't really see that this ticket needs any reassignment.

As I have quoted 3 times now:

* @note When updating the advertising data while advertising the advertising
* data and scan response data length must be smaller or equal to what
* can be fit in a single advertising packet. Otherwise the
* advertiser must be stopped.

It says in the declaration of the function you are trying to use. It is not possible to use bt_le_ext_adv_set_data() to update more than a single packet unless you stop the advertisements, and restart it.

Did you try using bt_le_per_adv_set_data()? As far as I can tell, it doesn't say that there are any length limitations on this call. However, the advertisement (old or new) can not be connectable, scannable nor anonymous.

Best regards,

Edvin

RE: Updating data in chained periodic advertising (1,650 bytes)

Sukriti — Sat, 01 Oct 2022 15:44:36 GMT

Hi Edvin!

Hope you're back now.

We invested a lot of time in framing the query properly, but sadly, nobody has dedicatedly attended the query. Can you please assign this to someone who can look into it properly? It's been over two months now.

If not, please let me know. I'll open a fresh ticket.

Thanks,

Sukriti

RE: Updating data in chained periodic advertising (1,650 bytes)

Edvin — Tue, 06 Sep 2022 21:38:27 GMT

Hello,

Yes, as I mentioned in the previously reply, it says in the description/documentation of the declaration of that function in bluetooth.h in the declaration for bt_le_ext_adv_set_data(), line 989 -> 1025:

/**
 * @brief Set an advertising set's advertising or scan response data.
 *
 * Set advertisement data or scan response data. If the advertising set is
 * currently advertising then the advertising data will be updated in
 * subsequent advertising events.
 *
 * When both @ref BT_LE_ADV_OPT_EXT_ADV and @ref BT_LE_ADV_OPT_SCANNABLE are
 * enabled then advertising data is ignored.
 * When @ref BT_LE_ADV_OPT_SCANNABLE is not enabled then scan response data is
 * ignored.
 *
 * If the advertising set has been configured to send advertising data on the
 * primary advertising channels then the maximum data length is
 * @ref BT_GAP_ADV_MAX_ADV_DATA_LEN bytes.
 * If the advertising set has been configured for extended advertising,
 * then the maximum data length is defined by the controller with the maximum
 * possible of @ref BT_GAP_ADV_MAX_EXT_ADV_DATA_LEN bytes.
 *
 * @note Not all scanners support extended data length advertising data.
 *
 * @note When updating the advertising data while advertising the advertising
 *       data and scan response data length must be smaller or equal to what
 *       can be fit in a single advertising packet. Otherwise the
 *       advertiser must be stopped.
 *
 * @param adv     Advertising set object.
 * @param ad      Data to be used in advertisement packets.
 * @param ad_len  Number of elements in ad
 * @param sd      Data to be used in scan response packets.
 * @param sd_len  Number of elements in sd
 *
 * @return Zero on success or (negative) error code otherwise.
 */
int bt_le_ext_adv_set_data(struct bt_le_ext_adv *adv,
			   const struct bt_data *ad, size_t ad_len,
			   const struct bt_data *sd, size_t sd_len);

Where the note that I referenced in the previous reply is particularly relevant.

So for chained advertisements to update, you need to stop the advertisements, set the data as if you set it the first time, and then restart advertising.

FYI: I will be out of office for the next 3-4 weeks. Please open a new ticket for follow up questions, as I will not be able to monitor my DevZone tickets.

Best regards,

Edvin

RE: Updating data in chained periodic advertising (1,650 bytes)

Sukriti — Mon, 05 Sep 2022 09:12:28 GMT

Thanks Edvin. Just to make things clearer, we are trying to update the data in periodic advertising events using the API bt_le_per_adv_set_data(). The data is larger than the capacity of a single packet. We tested what the declaration of bt_le_ext_adv_set_data() suggests, but this does not work for bt_le_per_adv_set_data().

I would again like to highlight the fact that the data gets updated using the bt_le_per_adv_set_data() API when the data fits in a single packet, even without the need of stopping extended advertising. But as the data becomes large (chain PDUs have to be used), this does not work. The chains are advertised successfully if we don't update the data.

RE: Updating data in chained periodic advertising (1,650 bytes)

Edvin — Mon, 05 Sep 2022 08:33:49 GMT

Typically, there is a separate API to update the advertisements after you have started advertising. I am not that familiar with the extended chained advertisements, and I am a bit confused as of what API you are currently using (there are a lot of different snippets in your original post), but I see that in one snippet, you are trying to use bt_le_per_adv_set_data() in your main loop. I don't see an API that is obviously intended to update the chained advertisements, but I see in the declaration of bt_le_ext_adv_set_data() that it says:

 * @note When updating the advertising data while advertising the advertising
 *       data and scan response data length must be smaller or equal to what
 *       can be fit in a single advertising packet. Otherwise the
 *       advertiser must be stopped.

So try stopping the advertisement first, using

int bt_le_ext_adv_stop(struct bt_le_ext_adv *adv);

and then update, and start the advertisements again.

Best regards,

Edvin

RE: Updating data in chained periodic advertising (1,650 bytes)

Sukriti — Mon, 05 Sep 2022 04:44:53 GMT

Any update?

RE: Updating data in chained periodic advertising (1,650 bytes)

Sukriti — Thu, 01 Sep 2022 12:59:25 GMT

Hi Edvin, we are using the SoftDevice controller only. And the entire query was based on SoftDevice controller.

I mistakenly wrote Zephyr Controller in one of my previous replies. I request you to kindly look into the issue. We have been waiting for an update very eagerly.

RE: Updating data in chained periodic advertising (1,650 bytes)

Edvin — Thu, 01 Sep 2022 12:44:12 GMT

Hello,

Sorry for the late reply. Susheel is out of offfice. If you are using the Zephyr Bluetooth LE stack, I am afraid you need to reach out to them if the advertisements are not getting updated. Do you see the same while using the SoftDevice Controller?

BR,
Edvin

RE: Updating data in chained periodic advertising (1,650 bytes)

Sukriti — Mon, 22 Aug 2022 04:49:30 GMT

Gentle reminder!

RE: Updating data in chained periodic advertising (1,650 bytes)

Sukriti — Fri, 12 Aug 2022 09:52:02 GMT

We will try again and get back to you.

Any lead on the periodic advertising data not getting updated?

RE: Updating data in chained periodic advertising (1,650 bytes)

Susheel Nuguru — Fri, 12 Aug 2022 09:23:29 GMT

Maybe there is some bug in the Zephyr controller. We have tested this with our SDC controller and the pull request changes you made should have made this line to execute. If this line in itself is not executed, then something is not right. Check the code flow and conditions as to why this line did not get executed.

RE: Updating data in chained periodic advertising (1,650 bytes)

Sukriti — Fri, 05 Aug 2022 18:18:29 GMT

Hi again!

We tried what you suggested using the softdevice controller, after making the changes. We observed that the line

cp->enable |= BT_HCI_LE_SET_PER_ADV_ENABLE_ADI

never gets executed. If we add a breakpoint at this line, the code just keeps on running, it never reaches the breakpoint.

RE: Updating data in chained periodic advertising (1,650 bytes)

Susheel Nuguru — Fri, 05 Aug 2022 11:03:32 GMT

Also please check if the changes you have done are taking effect.

Put a breakpoint at line cp->enable |= BT_HCI_LE_SET_PER_ADV_ENABLE_ADI; and start your code in debugger to see if this line is being executed. Softdevice controller is qualified with this feature, so it should work.

RE: Updating data in chained periodic advertising (1,650 bytes)

Sukriti — Fri, 05 Aug 2022 10:56:46 GMT

We are using Zephyr Controller

RE: Updating data in chained periodic advertising (1,650 bytes)

Susheel Nuguru — Fri, 05 Aug 2022 10:53:18 GMT

Should have worked with the softdevice controller, are you using Zephyr Controller?

RE: Updating data in chained periodic advertising (1,650 bytes)

Sukriti — Fri, 05 Aug 2022 10:09:26 GMT

We used SDK version 2.0.0

RE: Updating data in chained periodic advertising (1,650 bytes)

Sukriti — Fri, 05 Aug 2022 10:08:48 GMT

Hi Susheel. We made the required changes to the source and header files (bluetooth.h, hci.h, adv.c and hci_core.h).

Is this all we need to do to be able to test the feature? Because we still can not see the ADI field in AUX_SYNC_IND PDUs.

RE: Updating data in chained periodic advertising (1,650 bytes)

Susheel Nuguru — Fri, 05 Aug 2022 06:25:36 GMT

Sukriti, The support for ADI feature was recently merged into the upstream zephyr. You can use this pull request into your setup and test this feature. This will end up in our coming SDK release when we pull the upstream changes into our SDK.

RE: Updating data in chained periodic advertising (1,650 bytes)

Sukriti — Tue, 02 Aug 2022 12:30:17 GMT

Hi Susheel!

Thanks for the response. We are able to send 1,650 bytes, but only constant data. We aren't able to update this data.

Thanks for looking into this. Shall wait for your response!

Have a great day! 🙂