Zephyr Central to Peripheral communication

RE: Zephyr Central to Peripheral communication

Karthik p — Fri, 10 May 2024 11:24:23 GMT

Hi guys

it's funny :)that on chatting you guys created nice documentation for BLE central

grate job this helps on understanding central

thank you

RE: Zephyr Central to Peripheral communication

Edvin — Wed, 13 Jan 2021 09:02:54 GMT

Please check out the implementation in the Nordic example, foiund in NCS\nrf\samples\bluetooth\central_hr_coded, and it's notify_func:

static uint8_t notify_func(struct bt_conn *conn,
		struct bt_gatt_subscribe_params *params,
		const void *data, uint16_t length)
{
	if (!data) {
		printk("[UNSUBSCRIBED]\n");
		params->value_handle = 0U;
		return BT_GATT_ITER_STOP;
	}

	if (length == 2) {
		uint8_t hr_bpm = ((uint8_t *)data)[1];

		printk("[NOTIFICATION] Heart Rate %u bpm\n", hr_bpm);
	} else {
		printk("[NOTIFICATION] data %p length %u\n", data, length);
	}

	return BT_GATT_ITER_CONTINUE;
}

which prints:

Filters matched. Address: ef:1d:3e:56:18:9a (random) connectable: yes
Connection pending
Connected: ef:1d:3e:56:18:9a (random), tx_phy 4, rx_phy 4
The discovery procedure succeeded
[SUBSCRIBED]
[NOTIFICATION] Heart Rate 91 bpm
[NOTIFICATION] Heart Rate 92 bpm
[NOTIFICATION] Heart Rate 93 bpm
[NOTIFICATION] Heart Rate 94 bpm
[NOTIFICATION] Heart Rate 95 bpm
[NOTIFICATION] Heart Rate 96 bpm
[NOTIFICATION] Heart Rate 97 bpm
[NOTIFICATION] Heart Rate 98 bpm
[NOTIFICATION] Heart Rate 99 bpm
[NOTIFICATION] Heart Rate 100 bpm

So what you are looking for is the line:

uint8_t hr_bpm = ((uint8_t *)data)[1];

Without having checked, I see that data[0] is 6. I believe it is following the Bluetooth specification for the Heart Rate Service. I believe it is the location of the sensor, or some similar metadata. In fact, it is. Check out the implementation of int bt_hrs_notify(uint16_t heartrate) in hrs.c, which is used by the peripheral: NCS\nrf\samples\bluetooth\peripheral_hr_coded.

int bt_hrs_notify(uint16_t heartrate)
{
	int rc;
	static uint8_t hrm[2];

	hrm[0] = 0x06; /* uint8, sensor contact */
	hrm[1] = heartrate;

	rc = bt_gatt_notify(NULL, &hrs_svc.attrs[1], &hrm, sizeof(hrm));

	return rc == -ENOTCONN ? 0 : rc;
}

Best regards,

Edvin

RE: Zephyr Central to Peripheral communication

Jonas Lien — Tue, 12 Jan 2021 15:54:04 GMT

Thanks a lot for such a detailed answer, I really appreciate it and it helps clear things up. I sort of understand the callback process for service discovery now, but there's still a couple of things I'm unsure about.

If we continue one the central heart rate service example and look at the notify_func as you mentioned. First of all, what the peripheral_hr sends out is:

static void hrs_notify(void)
{
	static u8_t heartrate = 90U;

	/* Heartrate measurements simulation */
	heartrate++;
	if (heartrate == 160U) {
		heartrate = 90U;
	}

	bt_gatt_hrs_notify(heartrate);
}

Which is the simulated heartrate that we expect. However, what is displayed by the central_hr is

static u8_t notify_func(struct bt_conn *conn,
			struct bt_gatt_subscribe_params *params,
			const void *data, u16_t length)
{
	if (!data) {
		printk("[UNSUBSCRIBED]\n");
		params->value_handle = 0U;
		return BT_GATT_ITER_STOP;
	}

	printk("[NOTIFICATION] data %p length %u,\t", data, length);

	return BT_GATT_ITER_CONTINUE;
}

and corresponds to terminal output:

Alright. So my understanding is what is printed is the address that stores the data. Trying to dereference it, however, gets me no further. The data was sent as u8_t, but dereferencing it as either u8_t or u16_t (shown below) gives me the following (shown further below):

static u8_t notify_func(struct bt_conn *conn,
			struct bt_gatt_subscribe_params *params,
			const void *data, u16_t length)
{
	if (!data) {
		printk("[UNSUBSCRIBED]\n");
		params->value_handle = 0U;
		return BT_GATT_ITER_STOP;
	}

	printk("[NOTIFICATION] data %p length %u,\t", data, length);
	u8_t bleData = *(u8_t*)data;
	//memcpy(&bleData, data, sizeof(bleData));
	printk("bleData: %u\n", bleData);


	return BT_GATT_ITER_CONTINUE;
}

Output for u8_t:

Output for u16_t:

What am I doing wrong?

Looking forward once again to your answer.

RE: Zephyr Central to Peripheral communication

Edvin — Fri, 08 Jan 2021 13:36:40 GMT

Hello,

[quote user="Jonas Lien"]Is it possible for you to draw out an example of retrieving the read value from the peripheral and store it in e.g. a struct or push it to console/printk? [/quote]

That is more or less what the central_uart example does.

Look at how this example is built up:

In the connected() callback function, gatt_discover() is called with a pointer to the connection, conn.

Inside gatt_discover(), it calls bt_gatt_dm_start(), with the service that it is looking for as an input parameter. Exactly how you would do it if you want to list all services, I am not sure. However, a central typically (and also in your case) knows what services it is looking for. Isn't that also the case in your case?

Now, after calling bt_gatt_dm_start, you will hopefully get a callback to discovery_complete, or whatever you called your discovery_cb.completed function.

You need to look at the definitions of

bt_nus_handles_assign()
bt_nus_subscribe_receive()

to see what they do, and implement the similar thing in your application.

Looking at the central_hrs example, which follows the implementation you have already started on, which looks to be the zephyr method (not used in NCS as far as I can see), it works in a similar fashion.

From the zephyr\samples\bluetooth\central_hr example's connected callback function:

printk("Connected: %s\n", addr);

	if (conn == default_conn) {
		memcpy(&uuid, BT_UUID_HRS, sizeof(uuid));
		discover_params.uuid = &uuid.uuid;
		discover_params.func = discover_func;
		discover_params.start_handle = 0x0001;
		discover_params.end_handle = 0xffff;
		discover_params.type = BT_GATT_DISCOVER_PRIMARY;

		err = bt_gatt_discover(default_conn, &discover_params);
		if (err) {
			printk("Discover failed(err %d)\n", err);
			return;
		}
	}

So it will start the discovery procedure for the Heart Rate Service UUID. If found, this will trigger the discover_func() callback:

static uint8_t discover_func(struct bt_conn *conn,
			     const struct bt_gatt_attr *attr,
			     struct bt_gatt_discover_params *params)
{
	int err;

	if (!attr) {
		printk("Discover complete\n");
		(void)memset(params, 0, sizeof(*params));
		return BT_GATT_ITER_STOP;
	}

	printk("[ATTRIBUTE] handle %u\n", attr->handle);

	if (!bt_uuid_cmp(discover_params.uuid, BT_UUID_HRS)) {
		memcpy(&uuid, BT_UUID_HRS_MEASUREMENT, sizeof(uuid));
		discover_params.uuid = &uuid.uuid;
		discover_params.start_handle = attr->handle + 1;
		discover_params.type = BT_GATT_DISCOVER_CHARACTERISTIC;

		err = bt_gatt_discover(conn, &discover_params);
		if (err) {
			printk("Discover failed (err %d)\n", err);
		}
	} else if (!bt_uuid_cmp(discover_params.uuid,
				BT_UUID_HRS_MEASUREMENT)) {
		memcpy(&uuid, BT_UUID_GATT_CCC, sizeof(uuid));
		discover_params.uuid = &uuid.uuid;
		discover_params.start_handle = attr->handle + 2;
		discover_params.type = BT_GATT_DISCOVER_DESCRIPTOR;
		subscribe_params.value_handle = bt_gatt_attr_value_handle(attr);

		err = bt_gatt_discover(conn, &discover_params);
		if (err) {
			printk("Discover failed (err %d)\n", err);
		}
	} else {
		subscribe_params.notify = notify_func;
		subscribe_params.value = BT_GATT_CCC_NOTIFY;
		subscribe_params.ccc_handle = attr->handle;

		err = bt_gatt_subscribe(conn, &subscribe_params);
		if (err && err != -EALREADY) {
			printk("Subscribe failed (err %d)\n", err);
		} else {
			printk("[SUBSCRIBED]\n");
		}

		return BT_GATT_ITER_STOP;
	}

As you can see, it looks for several characteristic UUIDs. This is because it has several things that it wants to discover. First, if this is the callback for the service, it will pass the test:

if (!bt_uuid_cmp(discover_params.uuid, BT_UUID_HRS)) {

meaning that the service was discovered (the first bt_gatt_discover() was called with discover_params.type = BT_GATT_DISCOVER_PRIMARY.)

Next it will try to discover the hrs characteristic, and when that is discovered in the next callback, it will try to discover the descriptor (CCC), which is used to enable and disable notifications. If you prefer this method, try to replace the UUIDs with the ones that you are looking for. First for the service, then the characteristic, and finally the descriptor that you want to enable notifications on.

When the notifications are enabled, look how it is linked to the notification callback, "notify_func", which will be called whenever a notification is received. Then you can print the data that you received using printk() from the notification callback.

Best regards,

Edvin

RE: Zephyr Central to Peripheral communication

Jonas Lien — Fri, 08 Jan 2021 10:30:57 GMT

Hi Edvin, and thanks for your swift reply!

Yes, I have tested with the nrf Connect Mobile successfully picks up the peripheral and can connect + read/write.

With regards to the central_uart link, it was a bit hard to grasp. What I struggle with, is understanding how the elaborate callback scheme works. Is it possible for you to draw out an example of retrieving the read value from the peripheral and store it in e.g. a struct or push it to console/printk?

RE: Zephyr Central to Peripheral communication

Edvin — Thu, 07 Jan 2021 11:36:39 GMT

Hello Jonas,

I see you have attached some snippets from your peripheral, but before you start working on your central, are you able to write to and read from the characteristics that you want to using a phone and the nRF Connect app as a central? Alternatively on nRF Connect for Desktop using an extra DK?

I believe that the discovery callback function (in your case "discovered()" is triggered several times, one time for each service and characteristic.

Do you see any callbacks to your discover function?

For service discovery and how to use the characteristics from a central, I would recommend that you take a look at the sample found in:

NCS\nrf\samples\bluetooth\central_uart

Best regards,

Edvin