Softdevice Controller: TX with 100% duty cycle scanning in v2.3

RE: Softdevice Controller: TX with 100% duty cycle scanning in v2.3

Elfving — Tue, 20 Jun 2023 11:48:53 GMT

Hi Jordan,

Sure thing! This will be DRGN-19197.

Regards,

Elfving

RE: Softdevice Controller: TX with 100% duty cycle scanning in v2.3

JordanYates — Mon, 19 Jun 2023 06:46:30 GMT

Can you please provide a DRGN number so that I can see when a fix lands in sdk-nrfxlib?

RE: Softdevice Controller: TX with 100% duty cycle scanning in v2.3

Hung Bui — Tue, 30 May 2023 10:16:24 GMT

Hi Jordan,

Yes it's about right that the change/bug might have introduced in SDK v2.0.
Most likely the fix won't be able to make it to 2.4 but it will be fixed in 2.5.

RE: Softdevice Controller: TX with 100% duty cycle scanning in v2.3

JordanYates — Sat, 27 May 2023 05:01:56 GMT

Thank you for the update Hung. I will admit I didn't re-test v2.2 after I made the change to updating the advertising set instead of recreating it. I am quite confident that the single event mode worked fine on v1.9.4 when recreating the set each time, but I've had much less testing with any other configuration.

RE: Softdevice Controller: TX with 100% duty cycle scanning in v2.3

Hung Bui — Fri, 26 May 2023 07:25:33 GMT

Hi again Jordan,

The team has confirmed that it's a bug in our controller. A fix will be implemented in the future release. But we afraid that it will not come in nRF Connect v2.4 as it's coming out very soon.
For now, our suggestion is to either use 2 events instead of 1 when you increase the length of the advertising set. Or use dummy data so that the length of the advertising data doesn't change.

I'm not so sure why you don't see the same issue when in SDK v2.2 as the information I got from the team is that this bug has been there for a long time. I did a test with your code (changing length of adv packets) in SDK v2.2 and saw the same issue.

RE: Softdevice Controller: TX with 100% duty cycle scanning in v2.3

Hung Bui — Thu, 25 May 2023 13:05:04 GMT

Hi Jordan,
We are getting deeper inspection about the issue and will get back to you when we have any update. There could be something wrong with the scheduling of larger adv packet on the first event.

RE: Softdevice Controller: TX with 100% duty cycle scanning in v2.3

JordanYates — Wed, 24 May 2023 08:06:05 GMT

> The actual number of started advertising events is however reduced if the advertiser accepts a CONN_REQ/CONN_IND. The amount of packets that appear on air may also be affected if an advertising event is prematurely closed due to for instance an coexistence interface.

This is obviously not what we are seeing here. No devices are connecting to the advertiser, there is no other interface that could be triggering co-existence. The sample application works until NCS v2.2.

> Advertising data is not intended to be used as a way of sending arbitrary data by design. It's more of sending repeated data or for establishing connection. You may have to deal with packet loss due to collision because they don't have any way to sync the communication. In addition, power consumption can be high because your device(s) has to scan all the time.

We are well aware of the limitations of advertising data, and we do not use it expecting 100% packet throughput. It is a cheap mechanism to broadcast device state in an unstructured, mobile network that can also be observed by phones. I am unaware of any other Bluetooth mechanism that would allow receiving data from 100's of devices in a 1 second listen window.

Bluetooth mesh appears to be a sinking ship (even ignoring provisioning hell).
PAwR looks to be amazing for getting data back to a gateway device, but little help for peer-to-peer communication.

RE: Softdevice Controller: TX with 100% duty cycle scanning in v2.3

Hung Bui — Wed, 24 May 2023 07:29:21 GMT

Hi Jordan,
I got the information from the team that:

The actual number of started advertising events is however reduced if the advertiser accepts a CONN_REQ/CONN_IND. The amount of packets that appear on air may also be affected if an advertising event is prematurely closed due to for instance an coexistence interface.

It however doesn't explain why changing the size of the advertising set causing the first advertising event not being sent. I will check with them a little bit more.

Advertising data is not intended to be used as a way of sending arbitrary data by design. It's more of sending repeated data or for establishing connection. You may have to deal with packet loss due to collision because they don't have any way to sync the communication. In addition, power consumption can be high because your device(s) has to scan all the time.

Could you give more information about how many devices in the network and the topology here ? Maybe a mesh network or the new PAwR (periodic advertising with response) could fit your application .

RE: Softdevice Controller: TX with 100% duty cycle scanning in v2.3

JordanYates — Wed, 24 May 2023 00:01:53 GMT

Our application is a general framework that is intended for communicating arbitrary binary payloads at arbitrary times.
Therefore the size of each "packet" is more or less random, as is the desired timing.

Simply changing the number of advertising events to 2 is not a good solution from our perspective as it doubles both the power consumption and the RF congestion.

RE: Softdevice Controller: TX with 100% duty cycle scanning in v2.3

Hung Bui — Tue, 23 May 2023 12:49:23 GMT

Hi Jordan,

I can see that when the length of the advertising data changed and if there is only one advertising event per set, I do see that we having issue with that.
I will have to check internally with the team to see why that happens.

But I do see that if the number of advertising event is increased to 2 for example, I can see the different advertising data with different length. Or if length of the advertising set doesn't change then I don't see any problem.

Could you give some more information about your application ? What's the requirement for the advertising data ? Maybe periodic advertising is a better solution ?

RE: Softdevice Controller: TX with 100% duty cycle scanning in v2.3

JordanYates — Tue, 23 May 2023 11:09:25 GMT

In addition to my earlier comment, I am providing a slightly modified main.c file that demonstrates the issues I describe.

The advertising set is only created once, but on each iteration the length of the manufacturer data is swapped between 4 and 7 bytes. As you can see from the attached wireshark screenshot, only the shorter packets are ever received.

devzone.nordicsemi.com/.../7367.main.c

RE: Softdevice Controller: TX with 100% duty cycle scanning in v2.3

JordanYates — Tue, 23 May 2023 04:32:04 GMT

Thanks for the suggestion. Unfortunately on my side it looks like re-using the advertising set simply shifts the problem around. While most packets are indeed received reliably now, there are others that are never being seen by my second device (which uses 100% duty cycle scanning).

This isn't surprising IMO as your suggestion is not really a fix. There is no reason why the first time an advertising set is used data should not be transmitted (as you saw). This configuration worked until v2.2, and implies some internal logic error has been introduced, which I am hitting in different scenarios as we play with configurations. I am also still seeing this issue on the most up to date version of sdk-nrfxlib (c856a2e1).

The original reason for creating/deleting the set each time was as a workaround to https://devzone.nordicsemi.com/f/nordic-q-a/79398/softdevice-hard-fault-advertising-flash-contents-on-extended-advertising

RE: Softdevice Controller: TX with 100% duty cycle scanning in v2.3

Hung Bui — Mon, 22 May 2023 12:24:45 GMT

Hi Jordan,

Thanks for the code. I did a quick test here and I found that even if I comment out bt_le_scan_start() I still don't see the advertising packet very often.

But if I don't delete the advertising set. I can have a reliable result:
Here is my modification :

printk("Bluetooth initialized\n");

	err = bt_le_scan_start(&scan_param, scan_cb);
	if (err) {
		printk("Starting scanning failed (err %d)\n", err);
		return;
	}

	struct bt_le_adv_param *adv_param = BT_LE_ADV_PARAM(BT_LE_ADV_OPT_USE_IDENTITY | BT_LE_ADV_OPT_EXT_ADV, 
														BT_GAP_ADV_FAST_INT_MIN_1, BT_GAP_ADV_FAST_INT_MAX_1, NULL);
	struct bt_le_ext_adv *adv;

	struct bt_le_ext_adv_cb adv_cb = {
		.sent = bt_adv_done
	};
		printk("TX: %d\n", mfg_data[2]);

		/* Create advertising set */
		err = bt_le_ext_adv_create(adv_param, &adv_cb, &adv);
		if (err) {
			printk("Failed to create advertising set (err %d)\n", err);
			return;
		}

		/* Set the advertising data */
	
do {
		/* Start advertising */
		mfg_data[0]++;
		err = bt_le_ext_adv_set_data(adv, ad, ARRAY_SIZE(ad), NULL, 0);
		if (err) {
			printk("Failed to set advertising data (err %d)\n", err);
			return;
		}

		err = bt_le_ext_adv_start(adv, BT_LE_EXT_ADV_START_PARAM(0, 1));
		if (err) {
			printk("Advertising failed to start (err %d)\n", err);
			return;
		}

		/* Wait for advertising to complete */
		
		if (k_sem_take(&adv_done, K_SECONDS(1)) != 0) {
			printk("Advertising failed to complete)\n");
			return;
		}

// don't delete the advertising set

/*		err = bt_le_ext_adv_delete(adv);
		if (err) {
			printk("Failed to delete set (err %d)\n", err);
			return;
		}*/

		k_sleep(K_MSEC(1000));
	} while (1);

So instead of deleting the advertising set, I simply modify the advertising data and call bt_le_ext_adv_set_data() to update it. Then start advertising again.
I can see that the advertising is reliable:

You can see that the sniffer can capture the advertising packet every 1 seconds (almost).
I would suggest to use the nRF sniffer to track the advertising packet because the phone may not be able to do scanning at 100% duty cycle.

RE: Softdevice Controller: TX with 100% duty cycle scanning in v2.3

JordanYates — Sat, 20 May 2023 10:56:09 GMT

Sorry about the delay, but I have been able to reproduce the issue (or at least one that appears very similar).

The reproduction is not dependent on the simultaneous scanning, but instead on attempting to setup an extended advertising packet for a single transmission.

I modified the standard `zephyr/samples/bluetooth/scan_adv` to TX a single packet once a second.
The application is flashed onto a nrf9160dk_nrf52840 (not ideal but what I have on hand).
I am observing the packets with the nRF Connect app on a "Pixel 3a XL".
The attached application works as expected (advertising packets seen on phone) when built on NCS v2.1.4, but not on v2.2 or v2.3.

Packets can be observed on the phone on the newer versions if the advertising set is configured to transmit twice instead of once (`BT_LE_EXT_ADV_START_PARAM(0, 2)`)

Changing the transmission to twice also resolves the issue with my original application on a custom board scanning at 100% duty cycle.

devzone.nordicsemi.com/.../2287.scan_5F00_adv.zip

RE: Softdevice Controller: TX with 100% duty cycle scanning in v2.3

Hung Bui — Mon, 08 May 2023 13:01:10 GMT

Hi Jordan,

You are right. Sorry about that. Let me know if you can reproduce the issue on a simple application.

RE: Softdevice Controller: TX with 100% duty cycle scanning in v2.3

JordanYates — Mon, 08 May 2023 12:28:40 GMT

I can have a go trying to reproduce this in the SDK tomorrow.

The sample you linked is not particularly relevant AFAICT as it doesn't attempt to advertise at all, only scan.
It also only scans at 50% duty cycle when attempting to find devices, the line you linked is for the connection initiation phase (BT_GAP_SCAN_FAST_INTERVAL/BT_GAP_SCAN_FAST_WINDOW).

RE: Softdevice Controller: TX with 100% duty cycle scanning in v2.3

Hung Bui — Mon, 08 May 2023 11:48:14 GMT

Hi Jordan,

Have you managed to reproduce the issue with one of our samples in the SDK ?
I did a quick test with the central_hr_coded and it seems to work just fine. The scan window and scan interval was set to the same.