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

[yzhu]

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)

[Elfving]

Hello,

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 ?

I am not doubting what you are seeing, I just want to make sure. 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..

What antenna matrix are you using btw?

Regards,

Elfving

[yzhu]

Hi Elfving,

Thanks for your quick response!

Elfving said:

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.

PER_ADV_SYNC[0]: [DEVICE]: DE:AD:BE:EF:53:40 (random) synced, Interval 0x0078 (150 ms), PHY LE 2M
success. Periodic sync established.
Enable receiving of CTE...
success. CTE receive enabled.
Scan disable...Success.
Waiting for periodic sync lost...
CTE[0]: samples count 45, channel ID 5, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -710
CTE[0]: samples count 45, channel ID 0, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -690
CTE[0]: samples count 45, channel ID 0, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -680
CTE[0]: samples count 45, channel ID 0, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -680
CTE[0]: samples count 45, channel ID 0, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -680
CTE[0]: samples count 45, channel ID 32, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -660
CTE[0]: samples count 45, channel ID 0, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -710
CTE[0]: samples count 45, channel ID 0, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -710
CTE[0]: samples count 45, channel ID 0, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -710
CTE[0]: samples count 45, channel ID 0, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -710
CTE[0]: samples count 45, channel ID 9, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -710
CTE[0]: samples count 45, channel ID 0, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -740
CTE[0]: samples count 45, channel ID 0, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -750
CTE[0]: samples count 45, channel ID 0, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -750
CTE[0]: samples count 45, channel ID 0, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -750
CTE[0]: samples count 45, channel ID 31, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -700
CTE[0]: samples count 45, channel ID 0, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -810
CTE[0]: samples count 45, channel ID 0, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -810
CTE[0]: samples count 45, channel ID 0, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -810
CTE[0]: samples count 45, channel ID 0, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -810
PER_ADV_SYNC[0]: [DEVICE]: DE:AD:BE:EF:53:40 (random) sync terminated
Periodic sync lost.
Start scanning...success
Waiting for periodic advertising...

Elfving said:

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.

Elfving said:

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.

[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?

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 

[yzhu]

Elfving said:

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.

Elfving said:

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.

*** Booting nRF Connect SDK 3758bcbfa5cd ***
Starting Connectionless Locator Demo
Bluetooth initialization...success
Scan callbacks register...success.
Periodic Advertising callbacks register...success.
Start scanning...success
Waiting for periodic advertising...
success. Found periodic advertising.
Creating Periodic Advertising Sync...success.
Waiting for periodic sync...
failed (err -11)
Deleting Periodic Advertising Sync...success
Waiting for periodic advertising...
success. Found periodic advertising.
Creating Periodic Advertising Sync...success.
Waiting for periodic sync...
PER_ADV_SYNC[0]: [DEVICE]: DE:AD:BE:EF:53:40 (random) synced, Interval 0x0078 (150 ms), PHY LE 2M
PER_ADV_SYNC[0]: [DEVICE]: DE:AD:BE:EF:53:40 (random) sync terminated
success. Periodic sync established.
Enable receiving of CTE...
failed (err -134)
Scan disable...Success.
Waiting for periodic sync lost...
Periodic sync lost.

[yzhu]

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.