Hi,
I know that the S132 v6 didn't support multiple advertising sets with different advertising handles. If you want to advertise with new data or different parameters, you must reconfigure the existing advertising set. Is that still true of S140 (v7.0.1), or does the S140 support multiple sets?
If not, is there any plan to support multiple sets in the future?
Thank you.
EDIT: To provide more details on potential use cases.
With the current soft device API, we can reconfigure one advertising set, so we can alternate between any set of advertising modes, which may address most simple use cases. But there are a number of use cases that could make it useful to be able to configure multiple sets.
(1) Bluetooth 5 introduced advertising sets so that the host could configure the link layer to alternately advertise different data. The Bluetooth SIG's motivation for the feature is that, "Critically, the task of scheduling and transmitting the different sets falls to the Link Layer in the Controller rather than it having to be driven by the Host, which would be far less power efficient." In other words, the link layer can cycle through different advertising PDUs while the host remains asleep.
(2) The Bluetooth Core specification states that different advertising sets may have different advertising filter policies. What that means is that we could, for example, configure one advertising set to emit general discoverable packets and another advertising set to emit directed connectable packets. That would allow the link layer to autonomously enter GAP general discoverable mode every few minutes, while operating in GAP non-discoverable mode to re-establish connections with previously paired devices.
(3) Bluetooth 5 also introduced extended advertising packets. If the device advertises with extended packets, the spec recommends that the device also take advantage of the advertising-set feature to advertise with legacy packets as well, since not all devices support the newer extended PDUs. To quote Volume 3.C.9.2 of the specification: "Some devices may only scan for advertising events using legacy advertising PDUs. It is therefore recommended that devices using advertising events with the extended advertising PDUs also use an advertising set with advertising events that use legacy advertising PDUs."
(4) Bluetooth 5's host-controller interface also exposes an API function (LE Set Advertising Set Random Address) to allow the device to advertise with different device addresses. This would be a useful feature that would allow us to configure the link layer to simultaneously advertise with a set of random private addresses, depending on the central device that we want to reconnect. That would improve the performance of establishing concurrent connections in the peripheral role. Currently, we must either (1) send the same IRK to every bonded central, but then we can't control which central we connect to. Or (2) we need to advertise with one IRK, then advertise with another IRK, and so on, which decreases the system's concurrency performance.
(5) Without having the ability to configure multiple independent advertising sets, we can't use the Bluetooth 5 periodic advertising feature, while also advertising in other modes.
