How do I (simply) do a non-connectable advert on nRF52 using SDK 15?

[Michael McClary at CloudLeaf]

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.

• When unconnected it advertises normally, as a connectable peripheral.
• While connected it advertises as unconnectable (so other centrals can still SEE it), but otherwise identically.
• When the connection is ended, it reverts to the connectable advertisement.

I am having difficulty finding any simple explanation for how to do this.

• Nearly everything I found was for earlier SDKs - but advertising changed massively between 14 and 15.
  • Under 15 it seems to have switched to advertising structures managed by the soft device in the latter's storage,
  • addressed by a handle/index rather than a pointer
  • not to be modified on-the-fly, but replaced by a new one (and the old one unavailable for reuse until the soft device has finished some post processing on it)
  • The automatic turn-on of advertising on connection drop (on_disconnected()) sets the type to BLE_ADV_MODE_DIRECTED_HIGH_DUTY, rather than, say,
• The closest I did find on SDK 15 was https://devzone.nordicsemi.com/f/nordic-q-a/32824/dynamically-updating-advertising-data-in-sdk-15/126346#126346,
  • That seems to be an in-process debug of a rotating-triple-buffer scheme that is also supporting on-the-fly modification of the contents of the advertisement in other ways.
  • It also seems to involve replacing components/ble/ble_advertising/* with a roll-your-own substitute.

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.)

Thanks.

[Vidar Berg]

Hi,

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. 

[Michael McClary at CloudLeaf]

"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.

[Vidar Berg]

Hi,

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.

(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.)

 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:

ble_app_template.zip

[Michael McClary at CloudLeaf]

Thank you.

With that for an example I was able to

• get the template doing connected advertising correctly (on our board) with the basic SDK 15.0
• get the template do it with all our SDK tweaks
• get the actual project to do it corretly.

Excellent!

[awneil]

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. */

[Vidar Berg]

awneil, sorry, I see now that this comment wasn't particularly helpful. The advertisement module will start connectable advertising on BLE_GAP_EVT_DISCONNECT.  So I changed the priority to allow the app to stop the non-connectable advertising before the event gets processed by the advertisement module.  

Adv. stop in main.c->ble_evt_handler():

static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
{
    ret_code_t err_code = NRF_SUCCESS;

    switch (p_ble_evt->header.evt_id)
    {
        case BLE_GAP_EVT_DISCONNECTED:
            NRF_LOG_INFO("Disconnected.");
            // LED indication will be changed when advertising starts.

              /*Stop advertising to allow the advertising module to start 
                connectable advertising. It's not possible to change adv. params 
                on the fly, only data*/
            (void)sd_ble_gap_adv_stop(m_advertising.adv_handle);
            break;

.

[awneil]

So how do we tell that it's actually working?

Specifically, how do we tell that it's doing non-connectable advertising?

With nRF Connect on Android, I can still see advertising when it's connected to another device - but there is nothing to indicate that it's non-connectable advertising.

In fact, if I press the 'Connect' button, nRF Connect will try to connect.

[awneil]

awneil said:

I press the 'Connect' button, nRF Connect will try to connect

Like Michael McClary at CloudLeaf in the OP, my reason for doing this is so that other Centrals can still see that it's there when it's connected - so it doesn't just "disappear" - but they should know it's "busy" and, therefore, not connectable.

So is nRF Connect just being dumb in trying to connect?

Or is the advertising not actually "non-connectable"?

Or is there some Android limitation which means that apps can't tell whether advertising is "connectable" or not?

Or what??

Vidar Berg