• State Suggested Answer
  • Replies 13 replies
  • Answers 1 answer
  • Subscribers 75 subscribers
  • Views 1024 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 332611
Options

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)

  • 0 in reply to yzhu

    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

  • 0 in reply to Elfving

    Thanks for the update, I appreciate your efforts on finding the solution!

    Elfving said:
    Are you using the provided channel IDs when calculating these results,

    Yes, I am using the provided channel IDs, so some of the blue dots are claimed to be 0 in (N,0,0,0,0), and some are actually 0 in the case it is (0,0,0,0,0). Here shows plots from the same data set but with channel 5 and 10 highlighted for your reference

    Another strange fact I found is, for this data set, starting from channel 12, the dots tend to gather around two centrals gradually (none of channel 0~11 shows pattern like that, but every in channel 12~36 has the issue), although this might be an unrelated problem, but I will provide some plots just in case you have any thought.

    Note that I also tested other positions, it seems to be a common issue when the channel number increases, only with difference of in which channel you start to notice the separation.

  • 0 in reply to Elfving

    Hi Elfving,

    We tried to use a ST processor as the TX, with CTE train length set to 4, here are some log messages from direction_finding_connectionless_rx:

    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...
PER_ADV_SYNC[0]: [DEVICE]: A0:AC:7E:00:00:00 (public) synced, Interval 0x0404 (1285 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 21, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -510
CTE[0]: samples count 45, channel ID 23, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -510
CTE[0]: samples count 45, channel ID 11, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -480
CTE[0]: samples count 45, channel ID 12, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -490
CTE[0]: samples count 45, channel ID 28, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -510
CTE[0]: samples count 45, channel ID 19, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -520
CTE[0]: samples count 45, channel ID 8, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -490
CTE[0]: samples count 45, channel ID 14, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -520
CTE[0]: samples count 45, channel ID 18, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -510
CTE[0]: samples count 45, channel ID 18, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -510
CTE[0]: samples count 45, channel ID 34, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -520
CTE[0]: samples count 45, channel ID 6, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -490
CTE[0]: samples count 45, channel ID 18, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -510
CTE[0]: samples count 45, channel ID 11, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -480
CTE[0]: samples count 45, channel ID 4, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -500
CTE[0]: samples count 45, channel ID 25, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -510
CTE[0]: samples count 45, channel ID 15, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -540
CTE[0]: samples count 45, channel ID 6, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -480
CTE[0]: samples count 45, channel ID 13, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -500
CTE[0]: samples count 45, channel ID 31, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -500
CTE[0]: samples count 45, channel ID 9, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -480
CTE[0]: samples count 45, channel ID 12, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -520
CTE[0]: samples count 45, channel ID 14, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -510
CTE[0]: samples count 45, channel ID 30, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -520
CTE[0]: samples count 45, channel ID 18, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -510
CTE[0]: samples count 45, channel ID 35, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -520
CTE[0]: samples count 45, channel ID 28, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -550
CTE[0]: samples count 45, channel ID 12, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -510
CTE[0]: samples count 45, channel ID 10, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -470
CTE[0]: samples count 45, channel ID 23, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -490
CTE[0]: samples count 45, channel ID 22, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -490
CTE[0]: samples count 45, channel ID 19, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -480
PER_ADV_SYNC[0]: [DEVICE]: A0:AC:7E:00:00:00 (public) sync terminated
Periodic sync lost.
Start scanning...success
Waiting for periodic advertising...
success. Found periodic advertising.
Creating Periodic Advertising Sync...success.
Waiting for periodic sync...
PER_ADV_SYNC[0]: [DEVICE]: A0:AC:7E:00:00:00 (public) synced, Interval 0x0404 (1285 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 31, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -480
CTE[0]: samples count 45, channel ID 7, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -470
CTE[0]: samples count 45, channel ID 32, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -480
CTE[0]: samples count 45, channel ID 18, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -480
PER_ADV_SYNC[0]: [DEVICE]: A0:AC:7E:00:00:00 (public) sync terminated
Periodic sync lost.
Start scanning...success
Waiting for periodic advertising...
    As you can see, channel ID within a single CTE train are 4 different numbers for ST processor. Now it looks like RX is actually working as expected, and direction_finding_connectionless_tx is having some issue. Do you have any idea on that?

  • 0

    It is a BLE controller bug on transmitter side. I reproduced the bug on Zephyr and reported it to Zephyr Project #79671, a patch has been introduced in #79818 and verified.

    Note that separation issue I mentioned in this post has gone in test after applying the patch, but higher chan_idx still shows larger offset (details can be found in #79671), which might be another problem after all.

  • 0 in reply to yzhu

    Hello again,

    Thanks for the help identifying one of the issues here, as well your patience with this case. I have had this case a bit on hold since I assumed I would need help from the team to move on here.

    Regarding what you said here in the github issue about the new plots, are you necessarily seeing that the offsets are higher chan_idx? Could you expand a bit on how you are seeing it? I am not sure if I am seeing that myself.

    Regards,

    Elfving

Related
Terms of service