samples: bluteooth: CS ranging requestor sample #18921

sean-madigan · 2024-11-15T16:35:08Z

Add Channel sounding ranging requestor sample with distance estimation algorithm.

NordicBuilder · 2024-11-15T16:36:15Z

CI Information

^{To view the history of this post, clich the 'edited' button above}
Build number: 5

Inputs:

Sources:

more details

Github labels

Enabled	Name	Description
	ci-disabled	Disable the ci execution
	ci-all-test	Run all of ci, no test spec filtering will be done
	ci-force-downstream	Force execution of downstream even if twister fails
	ci-run-twister	Force run twister
	ci-run-zephyr-twister	Force run zephyr twister

List of changed files detected by CI (0)

Outputs:

Toolchain

Version:
Build docker image:

Test Spec & Results: ✅ Success; ❌ Failure; 🟠 Queued; 🟡 Progress; ◻️ Skipped; ⚠️ Quarantine

❌ Toolchain
❌ Build twister
❌ Integration tests

Note: This message is automatically posted and updated by the CI

This is a utility function to help extract useful parts of the ranging data provided by the ranging requestor service. Signed-off-by: Sean Madigan <[email protected]>

NordicBuilder · 2024-11-15T17:10:29Z

You can find the documentation preview for this PR at this link. It will be updated about 10 minutes after the documentation build succeeds.

Note: This comment is automatically posted by the Documentation Publish GitHub Action.

This sample can be used to set up a Channel Sounding Initiator with the GATT Ranging Requestor client. It can connect to Channel Sounding Reflector with Ranging Responder sample to request CS Ranging Data from. A simple distance estimation algorithm is included. This uses the same logic as the Zephyr Channel Sounding sample. Signed-off-by: Sean Madigan <[email protected]>

olivier-le-sage · 2024-11-18T09:35:18Z

If possible I think we should use mode 3 here. There's no disadvantage to using it (as long as it's supported on both sides), so I expect it would be more useful to customers than using mode 2 + 1

olivier-le-sage · 2024-11-18T09:36:49Z

include/bluetooth/services/ras.h

+ * must be populated with the length of the step data inside the callback.
+ * @param[in] user_data User data to be passed to the callbacks.
+ */
+void bt_ras_rreq_rd_subevent_data_parse(


did you try having a single function that parses both formats and gives a single callback ? I think it would be easier for users

it would also remove struct ras_rd_cs_subevent_step (since the mode would be a duplicate)

olivier-le-sage · 2024-11-18T09:40:43Z

samples/bluetooth/channel_sounding_ras_initiator/src/distance_estimation.c

+
+	struct ras_ranging_header *rd_header =
+		net_buf_simple_pull_mem(peer_steps, sizeof(struct ras_ranging_header));
+	(void)rd_header;


can just remove the variable?

alexstanoev-nordic · 2024-11-18T10:16:38Z

samples/bluetooth/channel_sounding_ras_initiator/src/main.c

+		err = bt_conn_set_security(connection, BT_SECURITY_L2);
+		if (err) {
+			printk("Failed to encrypt connection (err %d)\n", err);
+			return 0;


We might want to handle these failing more gracefully - perhaps disconnect the peer?

I think it is fine as is

alexstanoev-nordic · 2024-11-18T10:20:38Z

samples/bluetooth/channel_sounding_ras_initiator/src/main.c

+
+		err = bt_gatt_exchange_mtu(connection, &mtu_exchange_params);
+		if (err) {
+			printk("MTU exchange failed (err %d)\n", err);


I don't think it's worth handling the return code here, the only error code you could get is EALREADY which means the sem_mtu_exchange_done semaphore would have already been given in the MTU exchange callback.

olivier-le-sage · 2024-11-18T10:27:26Z

samples/bluetooth/channel_sounding_ras_initiator/src/main.c

+NET_BUF_SIMPLE_DEFINE_STATIC(latest_peer_steps, BT_RAS_PROCEDURE_MEM);
+static int32_t most_recent_peer_ranging_counter = PROCEDURE_COUNTER_NONE;
+static int32_t most_recent_local_ranging_counter = PROCEDURE_COUNTER_NONE;
+static int32_t dropped_ranging_counter = PROCEDURE_COUNTER_NONE;


I was hoping implementing RAS would make it easier to manage ranging counters in the app by leveraging the notifications you get from the server, wouldn't it make more sense to have something like:

array of steps storing N counters

discard array entry X if you get the data overwritten callback

set a flag in entry X when you get ranging data ready

app logic requests counters it has stored locally then processes entries where this flag is set ?

I guess what I wrote here doesn't exactly work but you'd think this overwritten notification would be useful somehow

I'm not sure exactly how to improve this currently

alexstanoev-nordic · 2024-11-18T10:31:58Z

samples/bluetooth/channel_sounding_ras_initiator/src/main.c

+static struct bt_conn *connection;
+static uint8_t n_ap;
+static uint8_t latest_num_steps_reported;
+NET_BUF_SIMPLE_DEFINE_STATIC(latest_local_steps, BT_RAS_PROCEDURE_MEM);


I don't think BT_RAS_PROCEDURE_MEM is the correct estimate here, since the local steps are storing a full bt_le_cs_subevent_step and no subevent headers

olivier-le-sage · 2024-11-18T11:27:22Z

samples/bluetooth/channel_sounding_ras_initiator/src/main.c

+#define CON_STATUS_LED DK_LED1
+
+#define CS_CONFIG_ID	       0
+#define NUM_MODE_0_STEPS       1


it might be more stable to use 2-3 mode 0 steps. Since there's no memory limitations with RAS we don't lose anything by increasing this

olivier-le-sage · 2024-11-18T11:30:17Z

samples/bluetooth/channel_sounding_ras_initiator/src/main.c

+			printk("MTU exchange failed (err %d)\n", err);
+		}
+
+		err = k_sem_take(&sem_mtu_exchange_done, K_SECONDS(5));


K_FOREVER is probably fine

olivier-le-sage · 2024-11-18T11:30:51Z

samples/bluetooth/channel_sounding_ras_initiator/src/main.c

+			return 0;
+		}
+
+		k_sem_take(&sem_remote_capabilities_obtained, K_SECONDS(5));


this can also be K_FOREVER I think ? Same for the other control procedures in the setup phase

Shouldn't take 5s? Might as well have the timeout?

peknis · 2024-11-18T11:37:41Z

samples/bluetooth/channel_sounding_ras_initiator/README.rst

+.. [#phase_and_amplitude] `Bluetooth Core Specification v. 6.0: Vol. 1, Part A, 9.2 <https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-60/out/en/architecture,-change-history,-and-conventions/architecture.html#UUID-a8d03618-5fcf-3043-2198-559653272b1b>`_
+.. [#rtt_packets] `Bluetooth Core Specification v. 6.0: Vol. 1, Part A, 9.3 <https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-60/out/en/architecture,-change-history,-and-conventions/architecture.html#UUID-9d4969af-baa6-b7e4-03ca-70b340877adf>`_


Please, place these to the links.txt (docs/nrf). See https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/dev_model_and_contributions/documentation/styleguide.html#linking

olivier-le-sage · 2024-11-18T11:50:08Z

samples/bluetooth/channel_sounding_ras_initiator/src/main.c

+	}
+
+	dropped_ranging_counter = PROCEDURE_COUNTER_NONE;
+	latest_num_steps_reported = result->header.num_steps_reported;


this is limited to 1 subevent per procedure, right?

Realised this variable was unused, but yeah I think currently only one subevent per procedure

sean-madigan · 2024-11-18T16:43:05Z

If possible I think we should use mode 3 here. There's no disadvantage to using it (as long as it's supported on both sides), so I expect it would be more useful to customers than using mode 2 + 1

Seems like it is still WIP in the controller, I can make a task to update this sample to use mode 3 when there is proper controller support

github-actions bot added doc-required PR must not be merged without tech writer approval. changelog-entry-required Update changelog before merge. Remove label if entry is not needed or already added. labels Nov 15, 2024

sean-madigan force-pushed the sample_requestor branch from d6bf442 to 91c14de Compare November 15, 2024 16:40

github-actions bot removed the changelog-entry-required Update changelog before merge. Remove label if entry is not needed or already added. label Nov 15, 2024

bluetooth: services: ras: And randing data parse function

ebdef98

This is a utility function to help extract useful parts of the ranging data provided by the ranging requestor service. Signed-off-by: Sean Madigan <[email protected]>

sean-madigan force-pushed the sample_requestor branch from 91c14de to 9fb1de6 Compare November 15, 2024 16:49

sean-madigan changed the title ~~Sample requestor~~ samples: bluteooth: CS ranging requestor sample Nov 15, 2024

sean-madigan force-pushed the sample_requestor branch from 9fb1de6 to 98d119b Compare November 15, 2024 16:52

sean-madigan force-pushed the sample_requestor branch from 98d119b to 6974806 Compare November 15, 2024 17:33

sean-madigan force-pushed the sample_requestor branch from 6974806 to 6875b7c Compare November 18, 2024 08:58

olivier-le-sage reviewed Nov 18, 2024

View reviewed changes

alexstanoev-nordic reviewed Nov 18, 2024

View reviewed changes

olivier-le-sage reviewed Nov 18, 2024

View reviewed changes

alexstanoev-nordic reviewed Nov 18, 2024

View reviewed changes

olivier-le-sage reviewed Nov 18, 2024

View reviewed changes

peknis requested changes Nov 18, 2024

View reviewed changes

olivier-le-sage reviewed Nov 18, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

samples: bluteooth: CS ranging requestor sample #18921

samples: bluteooth: CS ranging requestor sample #18921

sean-madigan commented Nov 15, 2024 •

edited

Loading

NordicBuilder commented Nov 15, 2024 •

edited

Loading

NordicBuilder commented Nov 15, 2024

olivier-le-sage commented Nov 18, 2024

olivier-le-sage Nov 18, 2024

olivier-le-sage Nov 18, 2024

olivier-le-sage Nov 18, 2024

alexstanoev-nordic Nov 18, 2024

sean-madigan Nov 18, 2024

alexstanoev-nordic Nov 18, 2024

olivier-le-sage Nov 18, 2024

olivier-le-sage Nov 18, 2024

sean-madigan Nov 18, 2024

alexstanoev-nordic Nov 18, 2024

olivier-le-sage Nov 18, 2024

olivier-le-sage Nov 18, 2024

olivier-le-sage Nov 18, 2024 •

edited

Loading

sean-madigan Nov 18, 2024

peknis Nov 18, 2024 •

edited

Loading

olivier-le-sage Nov 18, 2024

sean-madigan Nov 18, 2024

sean-madigan commented Nov 18, 2024

		.. [#phase_and_amplitude] `Bluetooth Core Specification v. 6.0: Vol. 1, Part A, 9.2 <https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-60/out/en/architecture,-change-history,-and-conventions/architecture.html#UUID-a8d03618-5fcf-3043-2198-559653272b1b>`_
		.. [#rtt_packets] `Bluetooth Core Specification v. 6.0: Vol. 1, Part A, 9.3 <https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-60/out/en/architecture,-change-history,-and-conventions/architecture.html#UUID-9d4969af-baa6-b7e4-03ca-70b340877adf>`_

samples: bluteooth: CS ranging requestor sample #18921

Are you sure you want to change the base?

samples: bluteooth: CS ranging requestor sample #18921

Conversation

sean-madigan commented Nov 15, 2024 • edited Loading

NordicBuilder commented Nov 15, 2024 • edited Loading

CI Information

Inputs:

Sources:

Github labels

Outputs:

Toolchain

Test Spec & Results: ✅ Success; ❌ Failure; 🟠 Queued; 🟡 Progress; ◻️ Skipped; ⚠️ Quarantine

NordicBuilder commented Nov 15, 2024

olivier-le-sage commented Nov 18, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

olivier-le-sage Nov 18, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

peknis Nov 18, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sean-madigan commented Nov 18, 2024

sean-madigan commented Nov 15, 2024 •

edited

Loading

NordicBuilder commented Nov 15, 2024 •

edited

Loading

olivier-le-sage Nov 18, 2024 •

edited

Loading

peknis Nov 18, 2024 •

edited

Loading