Direction finding: different performance of 1M/2M BLE PHY

[yzhu]

Hi,

I am using direction_finding_connectionless_tx/rx sample, and NCS v2.6.1 for AoA. I made some modification on the rx side to stream I/Q data via serial port, and read and calculate AoA on Ubuntu using a python script.

RX board: nrf5340 devkit + antenna

TX board: nrf5340/nrf52833 devkit

Antenna: 2 patterns with a distance of 5.3 cm

Test Env: outdoor

Problem Description:

I am evaluating the performance of DF AoA using different BLE PHY. I didn't find noticeable difference between 1M/2M, except 1M has trouble making sync when the tx is on the centre line (the symmetric axis where the phase difference should be 0)

In my test, within a similar time slot, 2M gives 1409 CTE reports while 1M only gives 231 reports. Note that other configurations are the same during the test, and both nrf5340/nrf52833 are tested as the tx device. The test was done one after the other at the same location for multiple times. Besides testing on the centre line, other angles are also tested (e.g. +-45 degree), the sync issue only occurs with 1M on the centre line.

Both 1M/2M are experiencing frequent sync creating and lost (BTW, is that abnormal?), I checked the struct bt_le_per_adv_sync_term_info.reason, it is 0x1f for all sync termination, which indicates BT_HCI_ERR_UNSPECIFIED and doesn't mean anything to me.

Has anyone met the same issue? Any thoughts will be appreciated!

[Amanda Hsieh]

Hi, 

It appears the default Controller config supports only one periodic sync, and hence, you can try with additional Kconfig options in the nrf/samples/bluetooth/direction_finding_connectionless_rx/child_image/hci_ipc.conf

You can append it to the end of that file.

CONFIG_BT_CTLR_ADVANCED_FEATURES=y
CONFIG_BT_CTLR_SCAN_AUX_SYNC_RESERVE_MIN=n

[yzhu]

Hi,

I just added the two lines to hci_ipc.conf for rx and got it tested in outdoor environment, it is not working unfortunately.

I tested both 1M and 2M PHY with both nrf5340 and nrf52833 as tx, here are the numbers of CTE reports received in 3-minutes period with the tx on the centre line.

	nrf52833	nrf5340
1M PHY	260	302
2M PHY	2679	2750

Note that PER_ADV_EVENT_CTE_COUNT=5 in tests. Distance between rx and tx is about 3ft.

As for position other than on the centre line (35 degree from centre line), both 1M and 2M are getting about 2000 reports

[Amanda Hsieh]

Hi, 

Could you test this with nRF Connect SDK 2.2 and with a totally unmodified sample?

nRF Connect SDK 2.6.1 is not supported for production for AoA receivers. We only certified one SDK for this and that was 2.2. Anything newer than that is hopefully working but no guarantees.

-Amanda H.

[yzhu]

Hi Amanda,

Thanks for that information, I didn't know that v2.2 is the only one certified SDK for AoA.

I tested both v2.2 and v2.6.1 today with the same test settings (150ms ext adv interval, PER_ADV_EVENT_CTE_COUNT=5, 3ft distance, 0/35 degree, 3-minutes), with only a counter added to cte_recv_cb for counting number of CTE received, so basically it is an unmodified sample. Both rx and tx were using nrf5340 since no difference was found in nrf52833 in previous tests.

Here are some data points on number of CTE received:

v2.6.1

	0 degree (centering)	35 degree
1M PHY	1691	5290
2M PHY	5826	5905

v2.2.0

	0 degree (centering)	35 degree
1M PHY	1057	1560
2M PHY	5731	5322

Note that these tests were repeated multiple times. And because no CTE report filter was added, lots of "CRC not OK" packets were also counted into those numbers, which makes the numbers look different from the other chart in this post.

It is surprising that v2.2 wasn't better, but actually degraded the performance of 35 degree to the same level as centering.