When running the channel sounding example on the nrf54l15, how can one obtain the IQ values of the ranging signal?

[a9876]

When running the channel sounding example on the nrf54l15, how can one obtain the IQ values of the ranging signal?I want to obtain the IQ value and then use my own algorithm to calculate the distance.

[Edvin]

Hello,

Please see this ticket, where a user has done something similar:

 Regarding I and Q measurements on the nRF54L15 development kits 

Best regards,

Edvin

[a9876]

I can now obtain my IQ score. May I ask how to increase the speed of obtaining this score?

[Edvin]

Hello,

I don't know how you already changed your sample, but looking at the default sample, that doesn't print the values, but prints the ranges, if you remove the k_sleep() in the main loop, and replace it with a semaphore:

	while (true) {
		//k_sleep(K_MSEC(100));
		k_sem_take(&sem_new_distance_measurement, K_FOREVER);
		if (buffer_num_valid != 0) {
			for (uint8_t ap = 0; ap < MAX_AP; ap++) {
				cs_de_dist_estimates_t distance_on_ap = get_distance(ap);

				LOG_INF("Distance estimates on antenna path %u: ifft: %f, "
					"phase_slope: %f, rtt: %f",
					ap, (double)distance_on_ap.ifft,
					(double)distance_on_ap.phase_slope,
					(double)distance_on_ap.rtt);
			}
		}
		else {
			LOG_INF("No valid distance estimates available yet.");
		}

		//LOG_INF("Sleeping for a few seconds...");
	}

And then, near the top, declare the semaphore, and give it in the store_distance_estimates() (or alternatively in the ranging_data_cb())

static K_SEM_DEFINE(sem_new_distance_measurement, 0, 1);
static void store_distance_estimates(cs_de_report_t *p_report)
{
	int lock_state = k_mutex_lock(&distance_estimate_buffer_mutex, K_FOREVER);

	__ASSERT_NO_MSG(lock_state == 0);

	for (uint8_t ap = 0; ap < p_report->n_ap; ap++) {
		memcpy(&distance_estimate_buffer[ap][buffer_index],
		       &p_report->distance_estimates[ap], sizeof(cs_de_dist_estimates_t));
	}

	buffer_index = (buffer_index + 1) % DE_SLIDING_WINDOW_SIZE;

	if (buffer_num_valid < DE_SLIDING_WINDOW_SIZE) {
		buffer_num_valid++;
	}
	k_mutex_unlock(&distance_estimate_buffer_mutex);
	k_sem_give(&sem_new_distance_measurement);
}

Then it should wake up and print the new data only when it has new data.

Note that in the unmodified sample, this will sometimes print the same data as the previous round, but that is because of some median filtering done in median_inplace().

Best regards,

Edvin

[a9876]

I have modified the code according to your suggestion. Now the IQ data can be captured twice within one second. May I ask if it is possible to further increase the capture speed? What parameters need to be adjusted if we want to further improve?

[a9876]

Hello,Edvin，Can we continue to increase the speed of distance measurement?

[Edvin]

Hello,

I am not 100% certain it is possible to increase it much more. Channel sounding requires a lot of radio activity, which takes a bit of time. 

Can you, however, upload what you currently have? Then I can have a look, and try to tweak some CS parameters, to see if it is possible to speed it up. 

Best regards,

Edvin

[a9876]

channel_sounding_ras_initiator.rarI am using version 3.0.2 of ncs. The code is shown in the attachment. Thank you, Edvin.

[Edvin]

Hello,

Can you please try the following:

Decrease this:

https://github.com/nrfconnect/sdk-nrf/blob/main/samples/bluetooth/channel_sounding_ras_initiator/src/main.c#L741-L742

Decrease the ACL interval:

https://github.com/nrfconnect/sdk-nrf/blob/main/samples/bluetooth/channel_sounding_ras_initiator/src/main.c#L555

Note that if you decrease the procedure interval by "too much" there will probably not be enough time for the RAS (Ranging service) to relay the CS measurement data from the rrsp to the rreq before the next proedure starts. This will lead to dropping some of the procedures, and perhaps an effictively reduced rate of new distance estimates.

One option to combat this issue is to reduce the amount of CS measurement data of CS measurements data per CS procedure. Note that this will always be at the cost of reduced accuracy. This could be done in a dew different ways.

Reducing the number of enabled channels in the channel map by settting fewer bits here:

https://github.com/nrfconnect/sdk-nrf/blob/main/samples/bluetooth/channel_sounding_ras_initiator/src/main.c#L719

Reducing the subevent length (1) and configuring the max_procedure_len subevent len (2)

(1) https://github.com/nrfconnect/sdk-nrf/blob/main/samples/bluetooth/channel_sounding_ras_initiator/src/main.c#L744-L745

(2) https://github.com/nrfconnect/sdk-nrf/blob/main/samples/bluetooth/channel_sounding_ras_initiator/src/main.c#L740

Configuring the submode as unused here:

https://github.com/nrfconnect/sdk-nrf/blob/main/samples/bluetooth/channel_sounding_ras_initiator/src/main.c#L705-L707

(this may reduce the security of CS)

Best regards,

Edvin