Some issues about direction-finding

RE: Some issues about direction-finding

Simonr — Thu, 18 Nov 2021 13:32:03 GMT

Good news. This issue has already been encountered by one of my colleagues here, and it has been fixed in the upstream Zephyr main branch.

Best regards,

Simon

RE: Some issues about direction-finding

Simonr — Wed, 17 Nov 2021 09:20:59 GMT

Hi again

Sorry about the late reply, but I agree that this sounds strange and that the CTE report here should follow the PER_ADV_SYNC. I have asked the developers internally and I'm waiting for a reply as I don't have a good explanation for you.

Best regards,

Simon

RE: Some issues about direction-finding

Marcous — Mon, 15 Nov 2021 11:44:27 GMT

1. For this question, I do lay the two beacons close to each other. I am sorry to hear that you don't officially provide any solution to the connection problems. But I do try to change the code and testbench (I mean the environment ) to improve the situation.

2. This question is somehow made by a bug in my individual code, and I have already fixed it. And it is true that recv_cb and cte_recv_cb should callback together.

And I get a new question here:

When I do multi-sync Direction Finding ( say three beacons simultaneously), I printf the log information about recv_cb and cte_recv_cb in the terminal window.

PER_ADV_SYNC[0]: [DEVICE]: E3:7F:07:20:00:0B (0x70), tx_power 127, RSSI -29, CTE AOA, data length 0, data:
CTE[0]: samples count 45, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -290

PER_ADV_SYNC[1]: [DEVICE]: E2:7F:07:20:00:0B (0x84), tx_power 127, RSSI -30, CTE AOA, data length 0, data:
CTE[0]: samples count 45, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -300

PER_ADV_SYNC[2]: [DEVICE]: E0:7F:07:20:00:0B (0x98), tx_power 127, RSSI -32, CTE AOA, data length 0, data:
CTE[0]: samples count 45, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -320

Here I show each of the three beacons' data_cb and cte_cb callback's response, note the highlighted numbers, in recv_cb, when I do the function bt_le_per_adv_sync_get_index(sync), I do can get the correct index of the synchronized device which is sending the data. However, in the cte_cb, when I do the same function, no matter how many devices I have already created synchronization, the results are always zero. But I can guarantee that the cte_recv_cb callback following the recv_cb is just from the same device's broadcasting.

Following is my code with recv_cb and cte_recv_cb

static void recv_cb(struct bt_le_per_adv_sync *sync,
                    const struct bt_le_per_adv_sync_recv_info *info,
                    struct net_buf_simple *buf)
{
    char le_addr[BT_ADDR_LE_STR_LEN];
    char data_str[BT_GAP_ADV_MAX_EXT_ADV_DATA_LEN];

    bt_addr_le_to_str(&(info->addr), le_addr, sizeof(le_addr));
    bin2hex(buf->data, buf->len, data_str, sizeof(data_str));

    printk("PER_ADV_SYNC[%u]: [DEVICE]: %s, tx_power %i, "
	       "RSSI %i, CTE %s, data length %u, data: %s\n",
	       bt_le_per_adv_sync_get_index(sync), le_addr, info->tx_power,
	       info->rssi, cte_type2str(info->cte_type), buf->len, data_str);
}

static void
cte_recv_cb(struct bt_le_per_adv_sync *sync,
            struct bt_df_per_adv_sync_iq_samples_report const *report)
{
  printk("CTE[%u]: samples count %d, cte type %s, slot durations: %u [us], "
           "packet status %s, RSSI %i\n",
           bt_le_per_adv_sync_get_index(sync), report->sample_count,
           cte_type2str(report->cte_type), report->slot_durations,
           packet_status2str(report->packet_status), report->rssi);
}

RE: Some issues about direction-finding

Simonr — Fri, 12 Nov 2021 14:13:07 GMT

Hi Marcous

1. How is the environment you're testing in? Are the two beacons you are using laying close to each other? If so they are prone to interfere with one another I would think if they advertise over one another. I'm sorry, but we don't have too much information or specific suggestions to strengthen a connection in a multiple-sync scenery as of yet. It could be that your antenna array is prone to multipath fading as well, and if so you will have to take care of that in the SW.

2. These can't be expected to be called together as they come from different places in the code. At least in the connectionless_rx sample project. The sync callback will only be called when the scanner syncs up to an advertiser I think, while the data_cb reports whenever there is a data callback.

Best regards,

Simon