nRF Connect SDK release notes 1.2.0 - removed concurrent BLE scan/advertise?

RE: nRF Connect SDK release notes 1.2.0 - removed concurrent BLE scan/advertise?

navigator — Mon, 24 Feb 2020 21:56:57 GMT

That helps, thanks phun!

A nice benefit of the nordic move to open source is the details on the playground commits. I just pulled up the commit notes on the throughput example itself and found the following, which supports your idea that it was a bug -- preventing it from achieving the expected performance.

Jan 21, 2020 commit 47256ac

Fix throughput test not achieving the expected throughput.
The occurred because the scanner was active during the throughput test
as bt_le_create_conn had already been called when the slave connection
was established.

It was not possible to cancel this connection object in the connecting
state because the same object is used to reference the slave connection.

This happens because the test is trying to establish connections in both
master and slave role at the same time. This use case is not supported
by the zephyr host, and can lead to connection object confusion as two
contexts are connected to the same bluetooth device. The API
bt_conn_lookup_addr_le does not work for this scenario.

Also fixed issues where wrong variable was used for err, mixing u8_t and
int, as well other cases where err was checked without being assigned,
or should have been checked.

https://github.com/NordicPlayground/fw-nrfconnect-nrf/commits/master/samples/bluetooth/throughput

RE: nRF Connect SDK release notes 1.2.0 - removed concurrent BLE scan/advertise?

phuntimes — Mon, 24 Feb 2020 18:33:56 GMT

There's a lot to unpack here. 1st, let's establish for the record that this is not an "optimization" issue. This is an issue of compatibility arising from the Bluetooth LE spec, Zepyhr, and nRF Connect SDK. Looking at the release notes:

Changed the Bluetooth: Throughput sample to prevent it from running Bluetooth LE scanning and advertising in parallel. The feature to establish a connection in both master and slave role at the same time is not supported by the Zephyr Bluetooth LE Host.

The BLE spec says that a device in 2 (disjoint) piconets may be a slave in one and a master in the other (but not a master in both). A device is not required to support this topology, which is is what the later sentence means.

In the throughput sample, the release notes imply the throughput app is configured as the master (of the Data connection), which you can see in the sample output:

***** Booting Zephyr OS 1.12.99 *****
[bt] [INF] hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
[bt] [INF] hci_vs_init: HW Variant: nRF52x (0x0002)
[bt] [INF] hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 1.12 Build 99
[bt] [INF] bt_dev_show_info: Identity: c5:ca:14:98:3b:90 (random)
[bt] [INF] bt_dev_show_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0x05f1
[bt] [INF] bt_dev_show_info: LMP: version 5.0 (0x09) subver 0xffff
Bluetooth initialized
Advertising successfully started
Scanning successfully started
Found a peer device c5:6f:8a:38:95:27 (random)
Connected as master

If the radio also allocates a time window to listen for advertisements, it is now simultaneously in the slave role in a separate piconet (consisting of the Advertiser, the master, and all other scanning devices, the slaves).

Now, 2nd, even if it was supported, it is not desirable (see my original reply) and is more a "bug" than an "optimization".

RE: nRF Connect SDK release notes 1.2.0 - removed concurrent BLE scan/advertise?

navigator — Fri, 21 Feb 2020 03:19:19 GMT

Yes, I completely agree if the change was made simply for optimization purposes. However the release notes imply it was done for a different purpose... due to support for a feature in the Zephyr OS, so I wonder about that.

RE: nRF Connect SDK release notes 1.2.0 - removed concurrent BLE scan/advertise?

phuntimes — Fri, 21 Feb 2020 00:55:26 GMT

Bluetooth radios use time-division multiplexing. If the radio has to allocate a time window for scanning and advertising while it's trying to test throughput, well that's not going to be a very accurate measurement of bandwidth, is it? In the throughput sample, the scanning and advertising functions of the BLE stack are temporarily disabled while characterizing. The throughput sample really has nothing to do with the other sample "Bluetooth: Scan & Advertise" other than any common code related to scanning and advertising.