Updating scan response packet whilst advertising

[Mike Austin (LPI)]

In my application, I'm using the Scan Response Packet to transmit some device related information, rather than requiring Clients to connect to get this.  I'm using NCS v2.0.0 and testing on an nRF52-DK.

I'm using the following to store the scan response information, and I update the information in there whenever it changes.

static struct bt_data sd[] = {
    BT_DATA(BT_DATA_MANUFACTURER_DATA, NULL, BT_GAP_ADV_MAX_ADV_DATA_LEN-2),
};

On first boot up, when I start BLE, I make a call to:

err = bt_le_adv_start(BT_LE_ADV_CONN_LSR_AD, ad, ARRAY_SIZE(ad), sd, ARRAY_SIZE(sd));

That successfully updates the scan response packet.  But if I subsequently attempt to update the scan response packet whilst I'm still advertising, via a call to:

err = bt_le_adv_update_data(ad, ARRAY_SIZE(ad), sd, ARRAY_SIZE(sd));

Then the scan response packet doesn't change.  I'm checking the result of err after this function call, and its returning 0, which indicates that its been successful.

The only way I seem able to get the scan response packet to update correctly is if I:

1. Stop advertising
2. Update scan response packet
3. Restart advertising

Is there a way to dynamically update the scan response packet whilst advertising?  Or do I need to follow the process of stop, update, restart?

Cheers,

Mike

[Mike Austin (LPI)]

Hi Hieu,

Just stumbled across this link on DevZone.  I know its a few years old, and probably refers to the older soft devices which I'm not using, but it is basically saying you need to keep track of whether your device is advertising or connected yourself.  I had been doing this, but also had a DISCONNECTED state that I set my flag to when it disconnected.  Seems that the peripheral will automatically return to advertising once its disconnected, and so I now set my flag to ADVERTISING in my .disconnected call back.

I've come from an Infineon/Cypress background, and they have a bunch of API's you can call to get the current state of the stack, and I just assumed it was something pretty standard.

Anyway, I'll keep this in mind and just use my own flags to keep track of what's going on with my BLE stack

Cheers,

Mike