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]

I've expanded the example above to update advertising data while disconnected. It's built with SDK v15.3.0. Please see attached below. 

8816.ble_app_template.zip

awneil said:

But, as previously noted, it does not work:

https://devzone.nordicsemi.com/f/nordic-q-a/41669/ble_advertising_advdata_update/183212#183212

It works, but we should have made it more clear that you need to provide a new buffer when you update the data.  

Excerpt of the code comments for the  ble_gap_adv_data_t struct:

/**@brief GAP advertising data buffers.
 *
 * The application must provide the buffers for advertisement. The memory shall reside in application RAM, and
 * shall never be modified while advertising. The data shall be kept alive until either:
 *  - @ref BLE_GAP_EVT_ADV_SET_TERMINATED is raised.
 *  - @ref BLE_GAP_EVT_CONNECTED is raised with @ref ble_gap_evt_connected_t::adv_handle set to the corresponding
 *    advertising handle.
 *  - Advertising is stopped.
 *  - Advertising data is changed.
 * To update advertising data while advertising, provide new buffers to @ref sd_ble_gap_adv_set_configure. */

Note the last line. 

awneil said:

But with Vidar Berg's code here, I no longer get the Advertising Timeout event!

Are you not getting BLE_GAP_EVT_ADV_SET_TERMINATED event on timeout?  

[awneil]

Vidar Berg said:

update advertising data while disconnected

It needs to keep updating the advertising data at all times - not just while disconnected.

Vidar Berg said:

It works, but we should have made it more clear

It could hardly be less clear!

Vidar Berg said:

Note the last line. 

It remains as clear as mud!

Please update that thread with a complete example.

Vidar Berg said:

Are you not getting BLE_GAP_EVT_ADV_SET_TERMINATED event on timeout?  

No - no event at all.

[Vidar Berg]

Please review and test the example I uploaded in my previous comment.  Just remove the code below from update_advertising_data() if you want the data to be updated while connected. 

    /* In this demo we update advertising while we're disconnected*/
    if (m_conn_handle != BLE_CONN_HANDLE_INVALID)
    { 
        return;
    }

[awneil]

I had separately tried to do it without adjusting priorities:

https://devzone.nordicsemi.com/f/nordic-q-a/47391/sdk-15-3-0-restart-non-connectable-advertising-after-timeout

But that has its own issues!

Will have a look at your latest ...

[awneil]

Vidar Berg said:

Please review and test the example I uploaded in my previous comment

I connected & disconnected, then left it connected for a while.

When I came back, this had happened:

<info> app: 8816 Template example with non-connectable advertising while connected.
<info> app: Fast advertising.
<info> app: Connected.
<info> app: Disconnected.
<info> app: Fast advertising.
<info> app: Connected.
<error> app: ERROR 8198 [Unknown error code] at main.c:478
PC at: 0x0002F33B
<error> app: End of error report

Line 478 is the APP_ERROR_CHECK at the end of sleep_mode_enter():

    // Go to system-off mode (this function will not return; wakeup will cause a reset).
    err_code = sd_power_system_off();
    APP_ERROR_CHECK(err_code);

The code is unmodified, apart from the name displayed in the startup log.

EDIT

And again - this time while advertising:

:
:
:
<info> app: Fast advertising.
<info> app: Connected.
<info> app: Disconnected.
<info> app: Fast advertising.
<error> app: ERROR 8198 [Unknown error code] at main.c:478
PC at: 0x0002F33B
<error> app: End of error report

Is this just an artefact of having the RTT logger attached?