This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Some issues about direction-finding

Hi, I am Marcous. Currently, I am working on the direction-finding demos. To be specific, I am developing my own application with locators connecting with multiple beacons meanwhile.

Here are two questions I counter recently,

1. When I just connect the locator with only one beacon, no matter how long the interval of the advertising is, (from 0x0020 (40ms) to 0x0320 (1000ms)), the connection hardly break down, where the algorithm in the locator side goes into the callback function of term_cb and inform me the sync is terminated.

However, when I add just one more beacon, the connection becomes weak, if I set the interval to a small value, say 100ms, there is a high opportunity that either connected beacon loses synchronization with the locator. On the contrary, if I set the interval to like 1000ms, the situation changes a lot, at least they don't disconnect regularly.  My question is, is there anything I can do to strengthen the connection in multiple-sync scenery. 

2. I am not sure whether my second question has any relationship with multiple-sync issues. But I found that occasionally, in sync_callback function, data_cb and sync_cb functions do not always call back together. The data_cb function always calls back, but the sync_cb  function sometimes does not necessarily follow data_cb function callback. In more serious cases, only data_cb  function will call back, the sync_cb  function will not, but I have enabled the enable_cte_rx function.

Parents
  • 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

  • 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);
    }

Reply
  • 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);
    }

Children
No Data
Related