Synchronisation between TX and RX in connectionless direction finding

[ghms]

We're trying to synchronise TX and RX in a connectionless direction finding setup. What we want to do is increment a data counter, log this on the TX timestamped, and send this as part of the periodic advertisement packet so that we can log it on the RX side and later provide the TX timestamp for data processing. We currently have `bt_le_ext_adv_start_param.num_events` set to 0 so that it just keeps sending periodic advertisement trains after initialising the Bluetooth and Direction Finding systems.

As far as I can tell, a counter is already incremented in the per_adv_counter, which is accessible from the `bt_df_per_adv_sync_iq_samples_report` whenever we receive a CTE. However, it seems like this is completely deferred to the subsystem and there is no way to access this in the TX application code. Is there e.g., an event we can listen to related to the sending of a CTE on the TX side? 

As an alternative, I've tried setting bt_le_ext_adv_start_param.num_events to 1 and doing something like this in the callback

static void adv_sent_cb(struct bt_le_ext_adv *adv, struct bt_le_ext_adv_sent_info *info)
{
LOG_INF("Advertiser[%d] sent %d", bt_le_ext_adv_get_index(adv), info->num_sent);
data_counter++;

LOG_INF("Transmitting counter %d ", data_counter);

memcpy(mfg_data, &data_counter, sizeof(uint16_t));

const static struct bt_data ad_update[] = {
BT_DATA(BT_DATA_MANUFACTURER_DATA, mfg_data, 2),
};
bt_le_adv_update_data(ad_update, ARRAY_SIZE(ad_update), sd, ARRAY_SIZE(sd));
bt_le_ext_adv_start(adv_set, &ext_adv_start_param);
}

But checking the logging from the RX, this results in no CTEs being sent. 

[Simonr]

Hi Glen

I have to ask the developers of the Direction finding sample if there is a good way to do this, but it's definitely a good question. It might take a few days to get a reply, but I'll let you know as soon as I have something.

Best regards,

Simon

UPDATE: Got a reply pretty fast. Our devs suggest that you update the data with the latest timestamp upon advertising, so the next periodic advertising will have the last known timestamp. You can use an accept list to only get reports when the data is updated. The time sync will be off by one periodic interval in this case. 10ms.

[ghms]

Hi Simon,

Thanks for the quick response! In the connectionless samples, how would you go about updating the advertisement data after setting up periodic advertising? My issue with the callback shown above is that I am not getting any CTEs on the RX side, and the approach used in the connectionless direction finding samples appear to simply set it up and then not worry about the data on the TX side.

The accept list seems like a useful tool, but the sample e.g., in Zephyr's codebase seems to be concerned with connections, is there an equivalent solution to broadcast and scanning?

Kind regards,

Glen

[Simonr]

Hi

Are you using "duplicate filtering enabled" in your project? Since it's not mentioned I'm guessing not, but I want to check nonetheless.

In terms of the accept list, you can use the BT_LE_PER_ADV_SYNC_OPT_USE_PER_ADV_LIST with bt_le_per_adv_sync_create() to have an accept list of sorts without having to connect. 

Best regards,

Simon

[ghms]

Hi Simon,

Yes, that is enabled. My sync function looks like this

static void create_sync(void)
{
    struct bt_le_per_adv_sync_param sync_create_param;
    int err;

    // printk("Creating Periodic Advertising Sync...");
    bt_addr_le_copy(&sync_create_param.addr, &per_addr);
    sync_create_param.options =
        BT_LE_PER_ADV_SYNC_OPT_FILTER_DUPLICATE | BT_LE_PER_ADV_SYNC_OPT_SYNC_ONLY_CONST_TONE_EXT;
    sync_create_param.sid = per_sid;
    sync_create_param.skip = 0;
    sync_create_param.timeout = 0xa;
    err = bt_le_per_adv_sync_create(&sync_create_param, &sync);
    if (err)
    {
        //   printk("failed (err %d)\n", err);
        return;
    }
    // printk("success.\n");
}

[Simonr]

Hi Glen

Could it be that you have made too many changes too quickly, and now don't know where the issue exactly lies now. 

Starting out with the working samples, I recommend that you do incremental updates on both TX and RX samples, then confirm the change you made works, before moving on to the next feature/implementation. For example. To get updated periodic advertising data, start testing with the periodic_adv and periodic_sync sample, then make changes to the connectionless TX/RX samples of Direction Finding and make sure that works before moving on.

I'm not able to see an obvious issue with your sync function, and it's hard to pin point what exactly is going wrong here, so I think taking a step or two back would be the right approach here.

Best regards,

Simon