bt_le_per_adv_sync_create

HI

I am currently using the 3.0.0 SDK's periodic_sync_conn and periodic_adv_conn examples.

In the periodic_adv_conn example, I have configured 100 subevents.

Below is the source code from the periodic_sync_conn example:

err = bt_le_scan_start(BT_LE_SCAN_ACTIVE, NULL);
if (err) {
printk("failed (err %d)\n", err);
return 0;
}

err = k_sem_take(&sem_per_adv, K_FOREVER);
if (err) {
printk("failed (err %d)\n", err);
return 0;
}
printk("Found periodic advertising.\n");

printk("Creating Periodic Advertising Sync");
bt_addr_le_copy(&sync_create_param.addr, &per_addr);
sync_create_param.options = 0;
sync_create_param.sid = per_sid;
sync_create_param.skip = 5;
sync_create_param.timeout = 0x3000;
err = bt_le_per_adv_sync_create(&sync_create_param, &sync);
if (err) {
printk("Failed to create sync (err %d)\n", err);
return 0;
}

printk("Waiting for periodic sync\n");
err = k_sem_take(&sem_per_sync, K_FOREVER);

After scanning and detecting the extended advertising packet, the example calls bt_le_per_adv_sync_create to establish synchronization. However, I've noticed that the sync_cb callback only gets triggered when subevent 0 is received. For other subevents, the sync_cb function is not called. Why is this happening? The device has to continuously listen for a long time until subevent 0 arrives before the synchronization creation stops.

Thanks

  • Hi,

    This seems to be in line with the Bluetooth Core Specification Version 6.0, Vol 6, Part D, section 4.8 Scanning for periodic advertisements, Figure 4.8 Periodic scanning. The procedure is to first do an extended scan, until reception of the AUX_ADV_IND, and then do the create sync in which the link layer waits for the AUX_SYNC_IND from the given device, in order to do the synchronization and then report back when the sync is established.

    Also, from what I understand, technically, at the point when you call bt_le_per_adv_sync_create(), the link layer is no longer listening nor following subevents. Since following subevents requires setting up a sync object, this is not done unless you explicitly make the call for it. When you make that call, it is then too late to follow the rest of the subevent train. The alternative would be if the stack automatically set up sync objects for all periodic advertisements, but that would certainly bring problems of its own, which is why neither the specification nor our implementation does so.

    It is analogous to connections, where first you scan for advertisements. When an advertisement is found from a device to which you want to connect, you then scan with the intent to connect to that given device (through referring to the Bluetooth address). The connection is then initiated on the next advertisement received from the device to which you want to connect.

    Regards,
    Terje

  • I'm not familiar with the Bluetooth protocol stack.

    1. Are you saying that after calling the bt_le_per_adv_sync_create function, we must wait until subevent 0 to establish synchronization?

    2. Is it because subevent 0 contains specific information that is necessary for establishing synchronization, and other subevents do not contain this information?

  • Hi,

    During normal scanning, the scanner does not listen to periodic advertising subevents at all. It only listens for the main events.

    The scanner (when just scanning) does however report on all periodic advertisements (the main events, not the subevents), so that you can decide, from the application, whether to synchronize or not with the particular periodic advertiser. The scanner does not, in this state, listen for any subevents at all. It only listens for main advertisements.

    When you choose, from the application, to synchronize to a given periodic advertiser, the scanner will start scanning again, but this time in a state where it will synchronize with a given periodic advertiser. On the next reception (from that particular advertiser) it will synchronize, and then call the callback. This must necessarily be (at the earliest) on the next advertisement, and not an advertisement in the past. (The advertisement which produced the report which you reacted to for initiating synchronization, is at this point an advertisement in the past.)

    Regards,
    Terje

Related