Multiple Advertisements Using the Timeslot API

[Cory Mast]

Hello,

I am currently designing a project that will advertise as two different beacons simultaneously using the Timeslot API. I have successfully implemented the nRF51-multi-role-conn-observer-advertiser example on GitHub and by using the nRF Master Control Panel application on android I can successfully see both advertisements. The problem is that I am noticing some irregularities in the waveform when I run the Timeslot advertisement alongside the SoftDevice advertisement. If i make the call to sd_ble_gap_adv_start() by itself I get an ideal waveform and if I make the call to btle_hci_adv_enable(BTLE_ADV_ENABLE) by itself I again get the ideal waveform. If I make both calls together, I get the irregularity. I have attached a screen capture from my oscilloscope to show the irregularity.

I have set up my Timeslot advertisement to advertise at a rate of 100ms and my SoftDevice to advertise at a rate of 1285ms

static void timeslot_advertiser_init(void)
{
btle_cmd_param_le_write_advertising_parameters_t adv_params;

/* we use software interrupt 1 */
btle_hci_adv_init(SWI1_IRQn);

/* BLE on-air address */
static ble_gap_addr_t ble_addr;

uint32_t err_code = sd_ble_gap_address_get(&ble_addr);
   APP_ERROR_CHECK(err_code);


memcpy((void*) &adv_params.direct_address[0], (void*) &ble_addr.addr[0], BTLE_DEVICE_ADDRESS__SIZE);

/* want to maximize potential scan requests */
adv_params.channel_map = BTLE_CHANNEL_MAP_ALL;
adv_params.direct_address_type = BTLE_ADDR_TYPE_RANDOM;
adv_params.filter_policy = BTLE_ADV_FILTER_ALLOW_ANY;
adv_params.interval_min = BLE_ADV_INTERVAL_100MS;
adv_params.interval_max = BLE_ADV_INTERVAL_105MS;

adv_params.own_address_type = BTLE_ADDR_TYPE_RANDOM;

/* Only want non-connectable requests */
adv_params.type = BTLE_ADV_TYPE_NONCONN_IND;

btle_hci_adv_params_set(&adv_params);
}

The waveform irregularity appears to occur about once every second.I am having difficulty understanding where this irregularity comes from and how to remove it. Any help you could provide would be greatly appreciated.

I am using the S110 SoftDevice version 7.1.0 and SDK 7.2.0

Thank You,

Cory

[Asbjørn]

I'm not sure what it is that you are seeing as irregularities. In the screen shot above it seems like the radio is advertising on three channels four times within a short time frame. Is this what you have in mind or am I missing something?

[Cory Mast]

I use the term irregularity because the radio should only advertise one time on all three channels, not the four seen above. I believe I have tracked down to issue to be related to the SoftDevice blocking advertisements. If I schedule another radio advertisement with normal priority for some time greater than the initial 100ms, the radio seems to behave as expected by only advertising once on all three channels. I have also noticed that the maximum timeslot length I can achieve is about 940ms. Does any of that seem correct or did I just get lucky and achieve the desired result with the improper method?

Thanks!

[Asbjørn]

So this occurs only if you use timeslot advertisements with 100 ms or less intervals? If you set it to more than 100 ms you don't see the 4 advertisements? The maximum timeslot length will depend on your BLE link/advertisement. If you have shorter time between each Softdevice advertisement, you timeslot will be shorter as well to fit in between them. You say this occurs about once a second. How are they placed in time compared to the regular softdevice advertisements? Are they regular right in front/after the softdevice?

You can a timeslot of 940 ms, so you should get 9 time slot advertisements inside that frame, do you see this and is it just one of them that are behaving differently?

[Cory Mast]

After much investigating I believe I finally understand the timeslot well enough to update with a response.

It appears that if the advertisement interval of the soft device and the timeslot interval are too close together, and even if they are spaced far apart, there is the chance that the soft device and the timeslot advertisement can collide. When this was happening, my event handler was aborting the timeslot and then ordering another timeslot advertisement. I believe the multiple advertisement burst was occurring when my code would order another timeslot advertisement while still being blocked by the soft device and attempt to abort and order and then abort and order until it finally wasn't being blocked any more. By using the extend functionality of the timeslot api i was able to overcome this problem.

Thank you for your help and great support!

[Ulrich Myhre]

Great that you found a solution! I wonder though, why isn't just changing the advertising data regularly enough for your implementation? Do you require very different advertising parameters for the two beacons?