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.

[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?

[awneil]

Vidar Berg said:

Just remove the code below from update_advertising_data() if you want the data to be updated while connected

Actually, that code means that the Advertising Data is never updated after the first connection!

This is due to a bug in the original Template code - which never clears m_conn_handle after a connection!

We need to add it on the BLE_GAP_EVT_DISCONNECTED event:

/**@brief Function for handling BLE events.
 *
 * @param[in]   p_ble_evt   Bluetooth stack event.
 * @param[in]   p_context   Unused.
 */
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.");

            m_conn_handle = BLE_CONN_HANDLE_INVALID;   //  <<<<<  HERE !

            // LED indication will be changed when advertising starts.

[Vidar Berg]

I was not aware of this bug, thanks for pointing it out. Anyway, the main purpose of this demo was to show how you can use the "update" API. 

awneil said:

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

I forgot to disable timeout for the non-connectable advertisement, that's why sleep_mode_enter() got called.

sd_power_system_off() will return with an error when the chip is in debug interface mode, see emulated system OFF mode: https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/power.html?cp=3_1_0_17_1_0#unique_1199040052