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

[JordanYates]

After updating to the softdevice controller included with NCS v2.3.0 (nrfxlib 6d0f58448fae164cfa4d28c494d6bddf5d0d0224), I have noticed what appears to be a behaviour change.

Previously, when configuring Zephyr to scan on Bluetooth with 100% duty cycle (interval == window), extended advertising packets that were scheduled for transmission by my application would be received on a secondary device reliably. After updating, I am seeing approximately 0% of these packets (maybe 1 packet every minutes at 1Hz transmission). If I update my scanning window from 100% to 99%, the secondary device is again receiving the vast majority of the packets. In both cases, I receive no errors from the Bluetooth stack and all expected events are generated (TX done callback called with num_sent == 1).

Has there been some internal change to TX or RX scheduling in v2.3 that could account for this change in behaviour?
Perhaps related to the experimental PAwR or PAST support added?

[JordanYates]

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

[JordanYates]

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.

Fullscreen 7367.main.c Download

/* main.c - Application main entry point */

/*
 * Copyright (c) 2015-2016 Intel Corporation
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#include <zephyr/types.h>
#include <stddef.h>
#include <zephyr/sys/printk.h>
#include <zephyr/sys/util.h>

#include <zephyr/bluetooth/bluetooth.h>
#include <zephyr/bluetooth/controller.h>
#include <zephyr/bluetooth/hci.h>

static uint8_t mfg_data[] = { 0xff, 0xff, 0x00, 0x11, 0x22, 0x33, 0x44 };

static struct bt_data ad[] = {
	BT_DATA_BYTES(BT_DATA_FLAGS, BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR),
	BT_DATA(BT_DATA_MANUFACTURER_DATA, mfg_data, sizeof(mfg_data)),
};

static K_SEM_DEFINE(adv_done, 0, 1);

static void bt_adv_done(struct bt_le_ext_adv *adv,
			struct bt_le_ext_adv_sent_info *info)
{
	ARG_UNUSED(adv);
	ARG_UNUSED(info);

	k_sem_give(&adv_done);
}

void main(void)
{
	int err;

	printk("Starting Advertiser Demo\n");

	/* Initialize the Bluetooth Subsystem */
	err = bt_enable(NULL);
	if (err) {
		printk("Bluetooth init failed (err %d)\n", err);
		return;
	}

	printk("Bluetooth initialized\n");

	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
	};

	/* 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;
	}

	do {
		printk("TX: %d\n", mfg_data[2]);

		/* Swap between different lengths */
		if (ad[1].data_len % 2) {
			ad[1].data_len = 4;
		} else {
			ad[1].data_len = 7;
		}

		/* Set the advertising data */
		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;
		}

		/* Start advertising */
		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;
		}

		mfg_data[2]++;

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

[Hung Bui]

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 ? 

[JordanYates]

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.

[Hung Bui]

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 .