I am porting a peripheral project from nRF51822 on SDK 11 to nRF52832 on SDK 15. Currently I'm using15.0, with S132 6.0.0. I used the template project for an initial pattern for working with SDK 15.
One thing it needs to do is (if I have the term right): "Peripheral Advertiser", i.e.
I am having difficulty finding any simple explanation for how to do this.
Can someone give me (or give me a pointer to) a simple (or as simple as practical under SDK 15) scheme for just doing the basic keep-advertising-while-connected, switch-between-connectable-and-unconnectable function.
(I WILL be needing on-the-fly adjustment of the manufacturing field in another month or so, so info on that would also be nice. But I need the above right away.)
We made some major API changes to the scanner and advertising API to support the new BT 5 features. I was planning to make a simple example based on the template project in SDK 15.0.0 Today but ran out of time. I hope I can get it done Tomorrow.
"We made some major API changes to the scanner and advertising API..."
I see that.
I notice that, after disconnect, ble_advertising.c seems to spend some time doing directed advertising to the previous central, first fast, then slow, before opening up to others. (I haven't checked to see whether it then shuts down after another timeout.) I take it this is to give the previously connected central a crack at reestablishing the connection if the disconnect was unintentional.
That could be problematic, if other centrals don't "see" directed advertising. The idea here (and the reason we want the nonconnectable advert while the peripheral is connected) is that the other centrals should be able to detect the presence of the peripheral, even if they don't want to connect to it. Right now, when the peripheral is connected to one central (and perhaps for a while after the disconnect) the peripheral "disappears" to the others. If ble_advertising.c does behave as described, even if the unconnectable advertisement makes it stay visible while connected, it might still disappear for a while afterward, while the previously connected central gets its exclusive opportunity to reconnect.
Michael McClary at CloudLeaf said:I notice that, after disconnect, ble_advertising.c seems to spend some time doing directed advertising
This is optional. The template example only enables fast mode in advertising_init(). init.config.ble_adv_directed_enabled is initialized to '0' by default.
The advertisement module in SDK 15.3.0 includes an API for updating advertisement data on the fly. I think it should be easy to backport.
Here's my modified template project (SDK 15.0.0) which starts non-connectable advertising during connections:
With that for an example I was able to
In that example, could you explain this:
/*Application needs higher priority than BLE_ADV_BLE_OBSERVER_PRIO in this case */
#define APP_BLE_OBSERVER_PRIO 0 /**< Application's BLE observer priority. You shouldn't need to modify this value. */