BLE UART connection status

[Robin]

Hello Nordic Pro's,

We are developing a product based on the BLE UART peripheral.  We communicate heavily via NUS.  There are extended processes that continually send status messages over BLE via a central based device.  These processes need to continue if the system disconnects, but the messages need to resume once reconnected.  So, we need to be able to detect the connection status and not send any messages when not connected, then resume the message once connected.  I have read through most if not all of the related cases, but cannot decipher a straightforward answer.  How can I determine from within a peripheral app whether it is connected to a central device? Has anyone successfully done this? 

Thanks again,

Robin@TL

[Simonr]

Hi Robin

I'm having some trouble understanding what exactly you want.  Do you mean like a return value when the peripheral connects/disconnects to a central? Because this can be seen if connecting it to a terminal or something similar. You should also be able to implement an LED to turn on when connected and off when disconnected if that is what you are after.

If I have misunderstood what you want to achieve, please try to explain it again.

NOTE: Creating a public case would let the community come with suggestions as well, which increases the chance of someone providing I.E. a working example of what you want. We can also set this case to public mode if you'd like. Just give me the word.

Best regards,

Simon

[Robin]

Hello again Simon,

Well I believe I have tracked this down to the fact that the advertising module puts the processor to sleep after a 3 minute timeout, presumably APP_ADV_TIMEOUT_IN_SECONDS   (180).  I can't see through the advertising module documentation well enough to understand how to properly and selectively, based on the state of our application, ignore the BLE_ADV_EVT_IDLE flag.  I have commented out the line that puts the cpu to sleep, and the code keeps running, but I cannot reconnect after the timeout.  

static void on_adv_evt(ble_adv_evt_t ble_adv_evt)
{
    uint32_t err_code;

    switch (ble_adv_evt)
    {
        case BLE_ADV_EVT_FAST:
            err_code = bsp_indication_set(BSP_INDICATE_ADVERTISING);
            APP_ERROR_CHECK(err_code);
            break;
        case BLE_ADV_EVT_IDLE:
 //           sleep_mode_enter();
            break;
        default:
            break;
    }
}

Any help is greatly appreciated,

Robin@TL

[awneil]

Robin said:

the advertising module puts the processor to sleep after a 3 minute timeout,

It's not actually the Advertising Module itself which does it;  it's "your" app - when it receives the Timeout event from the Advertising Module.

Two options:

1. Set the advertising to never time out - use BLE_GAP_ADV_TIMEOUT_GENERAL_UNLIMITED;
   
   
2. Just re-start advertising on each timeout
   There'l be an "advertising start" function called somewhere early on - just call that again.

Robin said:

I have commented out the line that puts the cpu to sleep, and the code keeps running, but I cannot reconnect after the timeout.  

Indeed - with no advertising, your device cannot be seen and, therefore, you can't connect to it.

[Robin]

Mr. Neil,

Should I presume that BLE_ADV_EVT_IDLE is the flag for the timeout?  Where is this stuff documented?

[awneil]

Robin said:

Where is this stuff documented

Here:

https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v15.3.0/lib_ble_advertising.html

You can also use your IDE's 'Go To Definition' feature to find the definition of BLE_ADV_EVT_IDLE - where there should be a descriptive comment:

/**@brief   Advertising events.
 *
 * @details These events are propagated to the main application if a handler was provided during
 *          initialization of the Advertising Module. Events for modes that are not used can be
 *          ignored. Similarly, BLE_ADV_EVT_WHITELIST_REQUEST and BLE_ADV_EVT_PEER_ADDR_REQUEST
 *          can be ignored if whitelist and direct advertising is not used.
 */
typedef enum
{
    BLE_ADV_EVT_IDLE,                /**< Idle; no connectable advertising is ongoing.*/
    BLE_ADV_EVT_DIRECTED_HIGH_DUTY,  /**< Direct advertising mode has started. */
    BLE_ADV_EVT_DIRECTED,            /**< Directed advertising (low duty cycle) has started. */
    BLE_ADV_EVT_FAST,                /**< Fast advertising mode has started. */
    BLE_ADV_EVT_SLOW,                /**< Slow advertising mode has started. */
    BLE_ADV_EVT_FAST_WHITELIST,      /**< Fast advertising mode using the whitelist has started. */
    BLE_ADV_EVT_SLOW_WHITELIST,      /**< Slow advertising mode using the whitelist has started. */
    BLE_ADV_EVT_WHITELIST_REQUEST,   /**< Request a whitelist from the main application. For whitelist advertising to work, the whitelist must be set when this event occurs. */
    BLE_ADV_EVT_PEER_ADDR_REQUEST    /**< Request a peer address from the main application. For directed advertising to work, the peer address must be set when this event occurs. */
} ble_adv_evt_t;

Sometimes (too often?), Nordic's idea of "descriptive" does seem rather lacking

Also, where to find the documentation is not always obvious: it'll be in the InfoCenter somewhere - but finding it is not always so easy ...

 

[awneil]

awneil said:

Sometimes (too often?), Nordic's idea of "descriptive" does seem rather lacking

In this case, the description of BLE_ADV_EVT_IDLE is just plain wrong:

BLE_ADV_EVT_IDLE,                /**< Idle; no connectable advertising is ongoing.*/

That's not a description of the Event - that's a description of the State which is entered after the event has occurred!

EDIT

The fact that the "Indefinite" option is not referenced from any of the places where you might use it has already been noted:

https://devzone.nordicsemi.com/f/nordic-q-a/46515/fast-advertising-slow-advertising-and-indefinite-advertising/183141#183141

maybe they'll find someone soon ...

;)