Efficient Dynamic Advertising Message

[Jeremy]

We are implementing a small battery powered BLE advertiser using the nRF51822 with an odd requirement that the advertising data needs to change between each advertisement.

Our current approach is to create a timer with the same duration as the advertising interval, and in the timer_timeout_handler modify the advertising data using the ble_advdata_set call. This works almost all of the time, but because the actual advertising timer is buried in the BLE stack, it is essentially asynchronous relative to our timer leaving to the occasional cycle where the same data will be sent twice, or the advertising data will be updated a second time before it transmits.

Additionally, it seems like there will be a small power overhead cost incurred to wake the chip up and update the advdata when that doesn't happen at the same time as the advertisement, though this may be less of a concern then I am thinking. We are working off a coin cell, so every drop counts.

What I would like to do is move the ble_advdata_set call to the ble event handler and have it update the advdata in an event driven fashion. We currently have a ble event handler registered, I just don't know if there is an event I can hook to that will achieve what we are looking for. It could be something that is called right before a broadcast, or immediately after, just something that is called every time an advertising packet is sent out.

static void on_ble_evt(ble_evt_t * p_ble_evt)
{
    ble_advdata_t newAdvData;

    switch (p_ble_evt->header.evt_id)
    {
        ????:
            newAdvData = generateNewData();
            ble_advdata_set(&newAdvData, NULL);
            break;
        default:
            break;
    }
}

Thanks!

[buslik]

Try to use BLE_GAP_EVT_TIMEOUT

[RK]

Don't see how that would be applicable here. That's the callback you get when you've advertised for the lengthy of time you set in the start call without connection and advertising has then been stopped. For constant advertising that parameter is usually set to zero, in fact apart from limited advertising it's usually set to zero, so you never get that callback. The original poster is looking for a per advertising event callback.