Direction finding: chan_idx of CTE sent in single periodic advertising train

Hi!

I am using direction_finding_connectionless_tx/rx sample, and NCS v2.6.1 for AoA.

RX board: nrf5340 devkit + antenna

TX board: nrf5340/nrf52833 devkit

Problem Description:

I notice that within each periodic advertising, it contains 5 CTE reports, and channel id of which are N(a random number) followed by 0,0,0,0. And after calculating AoA for each report, I find that the reports with chan_idx=0 are close to each other, however the one that is not 0 has a great bias comparing to the 0 ones.

I wonder if the random channel selecting is actually working or not, because it sounds odd to me that CTE reports within a single periodic advertising train have different BLE channel id.

Configurations:

tx side: #define PER_ADV_EVENT_CTE_COUNT 5

rx side: bt_df_per_adv_sync_cte_rx_param.max_cte_count = 0 (receive continuously)

Parents Reply Children
  • Hi Elfving,

    Thanks for your quick response!

    So you are using the default unmodified samples from Nordic for this (ie. not the zephyr ones)? The only thing modified is the max_cte_count ?

    Yes, I am using the samples under v2.6.1/nrf/samples/bluetooth. And I added some additional parts to original code, like I/Q data streaming via USB serial port. I don't think those would bring the bias because I didn't modify any part of the sampling code. So I double check it just now by running the original sample only with additional printing for channel ID, it shows the same behavior. Here is the log info.

    I'm acctually allready seeing another customer here finding a similar thing, though I guess he doesn't see the same bias that you do..

    I saw that post too. The bias I mentioned would only be noticeable after calculating angle using the arccos formula as the one in white paper, where the wavelength of the CTE signal should be calculated using the channel ID and channel frequency look-up-table. The bias could be a several degrees shifting from the other samples with chan_idx=0. I guess it is hard to notice from raw signal or phase difference, you can only see the bias after the calculation.

    And that is why I doubt the channel id given by each CTE report. If assuming channel ID within the same periodic advertising train are the same (either be [N, N, N, N, N] or [0, 0, 0, 0, 0] or [M, M, M, M, M]), and some part of the sampling code mistake it as [N, 0, 0, 0, 0], the bias would show up after calculating AoA using the wavelength related formula.

    What antenna matrix are you using btw?

    I am using two patterns on an off the shelf corehw 2x2 antenna array with distance less than half wavelength.

  • I had a talk with someone in the relevant R&D team who believes all of the all channel IDs should be the same as the first one set. Maybe there something not setting the value correctly?

    I assume you are using the zephyr controller(CONFIG_BT_LL_SW_SPLIT)? Could you try with this disabled, and see if you are seeing the same thing?

    Regards,

    Elfving 

  • I had a talk with someone in the relevant R&D team who believes all of the all channel IDs should be the same as the first one set. Maybe there something not setting the value correctly?

    That makes sense, is there a quick fix for this bug? I am not that familiar with the CTE report generating procedure.

    I assume you are using the zephyr controller(CONFIG_BT_LL_SW_SPLIT)? Could you try with this disabled, and see if you are seeing the same thing?

    Yes, CONFIG_BT_LL_SW_SPLIT is enabled in hci_ipc.conf by default. I try to disable it but it seems required for receiving CTE packets.

  • Hi Elfving,

    I plot out the calculated AoA for a raw I/Q data recording with rx at a fixed position. In this test I used the 2X2 antenna for 2-D direction finding, AoA are calculated independently for the two axis, and are plotted in pair as (x_aoa, y_aoa) in degree. I marked out AoA calculated from CTE reports with channel=0 as blue dots, and the rest as red.

    As you can see, there is non-negligible bias between the dots.

  • Sorry about the wait Yue,

    Unfortunately our direction finding team is busy at the moment, and I having a hard time finding good answers for you in the meantime. 

    yzhu said:

    That makes sense, is there a quick fix for this bug? I am not that familiar with the CTE report generating procedure.

    So first of all, this seems like a bug somewhere. And the bias you are showing there does make this more evident. Are you using the provided channel IDs when calculating these results, or are you using the presumably correct first channel ID for all the results, both blue and red?

    Regards,

    Elfving