Regarding I and Q measurements on the nRF54L15 development kits

Hi Nordic Support Team,

I'm currently experimenting with Channel Sounding using a couple of nRF54L15 boards. 

I am trying to obtain raw I and Q samples so that I may analyze it on my computer. 

To do so I modified the example Bluetooth: Channel Sounding Initiator with Ranging Requestor to print the I/Q samples out to the console. I changed the function `ranging_data_get_complete_cb` as follows:

static void ranging_data_get_complete_cb(struct bt_conn* conn, uint16_t ranging_counter, int err) {
    ARG_UNUSED(conn);

    if (err) {
        LOG_ERR("Error when getting ranging data with ranging counter %d (err %d)", ranging_counter, err);
        return;
    }

    LOG_DBG("Ranging data get completed for ranging counter %d", ranging_counter);

    /* This struct is static to avoid putting it on the stack (it's very large)
     */
    static cs_de_report_t cs_de_report;

    cs_de_populate_report(&latest_local_steps, &latest_peer_steps, BT_CONN_LE_CS_ROLE_INITIATOR, &cs_de_report);

    net_buf_simple_reset(&latest_local_steps);
    net_buf_simple_reset(&latest_peer_steps);
    k_sem_give(&sem_local_steps);

    cs_de_quality_t quality = cs_de_calc(&cs_de_report);

    for (uint8_t ant_path = 0; ant_path < cs_de_report.n_ap; ant_path++) {
        for (uint8_t tone = 0; tone < 80; tone++) {
            printk("%u %u %f %f %f %f\n", procedure_number, tone, (double)cs_de_report.iq_tones[0].i_local[tone],
                   (double)cs_de_report.iq_tones[0].q_local[tone], (double)cs_de_report.iq_tones[0].i_remote[tone],
                   (double)cs_de_report.iq_tones[0].q_remote[tone]);
        }
    }
    procedure_number++;

    if (quality == CS_DE_QUALITY_OK) {
        for (uint8_t ap = 0; ap < cs_de_report.n_ap; ap++) {
            if (cs_de_report.tone_quality[ap] == CS_DE_TONE_QUALITY_OK) {
                store_distance_estimates(&cs_de_report);
            }
        }
    }
}

When run, this is the output that is produced:

0 0 -27.000000 -40.500000 19.500000 -55.500000
0 1 8.666664 -35.999996 -32.999996 -27.333328
0 2 56.666668 7.000000 -74.000000 18.333332
0 3 74.000000 -30.666664 -92.666664 -12.000000
0 4 9.666660 -70.666664 -37.999992 -57.333332
0 5 100.000000 35.000000 -110.000000 53.000000
0 6 -105.000000 -6.000000 108.000000 -57.000000
0 7 -103.000000 19.000000 120.000000 10.000000
0 8 65.500000 80.500000 -42.500000 106.000000
0 9 44.000000 -99.000000 -67.000000 -109.000000
.
. [Omitting several lines for clarity]
.
0 71 42.333328 34.333332 -84.666664 -10.999996
0 72 -34.000000 -45.500000 58.500000 -22.000000
0 73 -99.500000 13.500000 101.000000 55.500000
0 74 0.333332 -32.999996 3.666666 -40.333328
0 75 0.000000 0.000000 0.000000 0.000000
0 76 0.000000 0.000000 0.000000 0.000000
0 77 0.000000 0.000000 0.000000 0.000000
0 78 0.000000 0.000000 0.000000 0.000000
0 79 0.000000 0.000000 0.000000 0.000000
 

Where the first number is `procedure_number` (corresponds to the number of times `ranging_data_get_complete_cb` was called), the second number is the `tone` index and the other 4 are `i_local`, `q_local`, `i_remote` and `q_remote`, respectively.

I have several questions based on observing the data:

Question 1:

What units are `i_local`, `q_local`, `i_remote` and `q_remote` measured in? I have assumed that it is in degrees, but I cannot find any indication of this in include/bluetooth/cs_de.h.

Question 2:

Why are some of the readings of `i_local`, `q_local`, `i_remote` and `q_remote` measured as 0?

Parents
  • Hi Ignatious

    I'm so sorry, but your ticket fell through our cracks. I'll handle it from here and we'll try to get you sorted.

    1. This is raw IQ data (not degrees) and is described in the Bluetooth core specification on the section of IQ data.

    2. 0 could be because the ranging wasn't completed or if the buffer overflows or similar I believe. In short it could be multiple reasons for this.

    Best regards,

    Simon

  • Dear Simon,

    Thank you very much for your response!


    1. I see. It seems that according to the BLE v6.0 Core Specification Vol 6 Part H, Section 4.6 they are complex numbers.

    "Each measurement within T_PM results in a single PCT value expressed as complex
    number I+jQ."

    So according bluetooth/cs_de.h are they complex numbers encoded as 32-bit float values, yes?

    2. These '0' readings keep happening on the same indices. I noticed that according to bluetooth/cs_de.h these correspond to the tones. If I am understanding this correctly, this corresponds to the 79 CS channels that are used for channel sounding? If we look at the indices that are missing data and observe the forbidden channels for CS, the indices that are "missing" correspond to 2 less than the channel number (a.k.a it seems that the index 0 in Nordic's implementation refers to measurements made in channel 2 (2404Mhz) and not channel 0 (2402 MHz) as in the BLE spec). I may be completely off the mark here, what do you think, Simon?

    Regards,

    Ignatious 

Reply
  • Dear Simon,

    Thank you very much for your response!


    1. I see. It seems that according to the BLE v6.0 Core Specification Vol 6 Part H, Section 4.6 they are complex numbers.

    "Each measurement within T_PM results in a single PCT value expressed as complex
    number I+jQ."

    So according bluetooth/cs_de.h are they complex numbers encoded as 32-bit float values, yes?

    2. These '0' readings keep happening on the same indices. I noticed that according to bluetooth/cs_de.h these correspond to the tones. If I am understanding this correctly, this corresponds to the 79 CS channels that are used for channel sounding? If we look at the indices that are missing data and observe the forbidden channels for CS, the indices that are "missing" correspond to 2 less than the channel number (a.k.a it seems that the index 0 in Nordic's implementation refers to measurements made in channel 2 (2404Mhz) and not channel 0 (2402 MHz) as in the BLE spec). I may be completely off the mark here, what do you think, Simon?

    Regards,

    Ignatious 

Children
No Data
Related