ANCS Code base (bonding) with NUS and strange behaviour with nRF Toolbox

RE: ANCS Code base (bonding) with NUS and strange behaviour with nRF Toolbox

trdop — Tue, 23 May 2017 12:38:26 GMT

Thanks Petter, As it's used to say, it's the simplest things that pass to the trap ! It work this way, by handling the re-connecting on the previously bonded device reference on my side with nRF Toolbox !

RE: ANCS Code base (bonding) with NUS and strange behaviour with nRF Toolbox

trdop — Tue, 23 May 2017 11:39:50 GMT

Ok thanks, gonna try to make the adaptation on the iOS App Side, what was strange it that the Android will do the reconnection from the nRF Toolbox App. But it's maybe because, there is no ANCS and Android and it wasn't required me to accept Pairing with Bonding.

RE: ANCS Code base (bonding) with NUS and strange behaviour with nRF Toolbox

Petter Myhre — Tue, 23 May 2017 10:48:48 GMT

Ok. I think that is simply because the app itself will not reconnect, even though the is a reconnection at a system level. If this is a behavior you want, I think you must modify the app. The fix I proposed was so that the peripheral will actually send a message, which I believe it didn't before. But it doesn't help the it sends a message if there is no iOS app there to receive it. ANCS doesn't need an app, so that will work.

RE: ANCS Code base (bonding) with NUS and strange behaviour with nRF Toolbox

trdop — Tue, 23 May 2017 10:35:30 GMT

Hi Petter,

Thanks for your response,

I tried to do as you advised, but it does not work at the "re-connection" after a standby of the board and a wake up. The ANCS is well re-connected and in my settings iOS the device connects well, but from the application nRF Toolbox, the last message I received in my log of the application:

[35] 12: 26: 27.453 | Network | Thread 8 | Error Code: The connection has timed out unexpectedly.

I can always send messages to my board via nRF Toolbox; If I send the command: >LED, the corresponding LED lights up ... but not returning from the Board to the iPhone, when sending a command provided for this purpose.

Here is what I have changed in the file: ble_nus.c

/**@brief Function for handling the @ref BLE_GATTS_EVT_WRITE event from the S110 SoftDevice.
 *
 * @param[in] p_nus     Nordic UART Service structure.
 * @param[in] p_ble_evt Pointer to the event received from BLE stack.
 */
static void on_write(ble_nus_t * p_nus, ble_evt_t * p_ble_evt)
{
    ble_gatts_evt_write_t * p_evt_write = &p_ble_evt->evt.gatts_evt.params.write;

    **p_nus->is_notification_enabled = true;**
    
    if (
        (p_evt_write->handle == p_nus->rx_handles.cccd_handle)
        &&
        (p_evt_write->len == 2)
       )
    {
        if (ble_srv_is_notification_enabled(p_evt_write->data))
        {
            **p_nus->is_notification_enabled = true;**
        }
        else
        {
**//            p_nus->is_notification_enabled = false;**
        }
    }
    else if (
             (p_evt_write->handle == p_nus->tx_handles.value_handle)
             &&
             (p_nus->data_handler != NULL)
            )
    {
        p_nus->data_handler(p_nus, p_evt_write->data, p_evt_write->len);
    }
    else
    {
        // Do Nothing. This event is not relevant for this service.
    }
}

and:

uint32_t ble_nus_init(ble_nus_t * p_nus, const ble_nus_init_t * p_nus_init)
{
    uint32_t      err_code;
    ble_uuid_t    ble_uuid;
    ble_uuid128_t nus_base_uuid = NUS_BASE_UUID;

    VERIFY_PARAM_NOT_NULL(p_nus);
    VERIFY_PARAM_NOT_NULL(p_nus_init);

    // Initialize the service structure.
    p_nus->conn_handle             = BLE_CONN_HANDLE_INVALID;
    p_nus->data_handler            = p_nus_init->data_handler;
    **p_nus->is_notification_enabled = true;**

and:

uint32_t ble_nus_string_send(ble_nus_t * p_nus, uint8_t * p_string, uint16_t length)
{
    ble_gatts_hvx_params_t hvx_params;

    VERIFY_PARAM_NOT_NULL(p_nus);

**//    if ((p_nus->conn_handle == BLE_CONN_HANDLE_INVALID) || (!p_nus->is_notification_enabled))
//    {
//        return NRF_ERROR_INVALID_STATE;
//    }**

    if (length > BLE_NUS_MAX_DATA_LEN)
    {
        return NRF_ERROR_INVALID_PARAM;
    }

Thank you again, for trying to get me out of this shadow I try to do, in my opinion, something simple.

RE: ANCS Code base (bonding) with NUS and strange behaviour with nRF Toolbox

Petter Myhre — Mon, 22 May 2017 15:47:58 GMT

I suspect that this check is failing on reconnection:

if ((p_nus->conn_handle == BLE_CONN_HANDLE_INVALID) || (!p_nus->is_notification_enabled))
{
    return NRF_ERROR_INVALID_STATE;
}

Because is_notification_enabled is only set to true when the CCCD is written to true by the client:

    if (ble_srv_is_notification_enabled(p_evt_write->data))
    {
        p_nus->is_notification_enabled = true;
    }

But since you are bonded, the client will not write to the CCCD, it will expect you to have saved its state from the last connection.

You can try to remove the check, or set is_notification_enabled to true somehow, for example when you get the PM_EVT_LOCAL_DB_CACHE_APPLIED event.

RE: ANCS Code base (bonding) with NUS and strange behaviour with nRF Toolbox

Petter Myhre — Thu, 18 May 2017 12:15:38 GMT

Would it be possible for you to share your complete project so I can test it here?