This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Why I cannot see data on my phone app even when notifications enabled on both TX and RX characteristics in my server side code ?

Hello

I have an interesting problem from the ble_app_uart example modified to work with spis. 

ble_nus.c code

// Add the RX Characteristic.
    memset(&add_char_params, 0, sizeof(add_char_params));
    add_char_params.uuid                     = BLE_UUID_NUS_RX_CHARACTERISTIC;
    add_char_params.uuid_type                = p_nus->uuid_type;
    add_char_params.max_len                  = BLE_NUS_MAX_RX_CHAR_LEN;
    add_char_params.init_len                 = sizeof(uint8_t);
    add_char_params.is_var_len               = true;
    add_char_params.char_props.write         = 1;
    add_char_params.char_props.write_wo_resp = 1;
add_char_params.char_props.notify = 1;              /* TSP */
    add_char_params.read_access  = SEC_OPEN;
    add_char_params.write_access = SEC_OPEN;
add_char_params.cccd_write_access = SEC_OPEN;      /* TSP */
    err_code = characteristic_add(p_nus->service_handle, &add_char_params, &p_nus->rx_handles);         /* TSP */
    if (err_code != NRF_SUCCESS)
    {
        return err_code;
    }

    // Add the TX Characteristic.
    /**@snippet [Adding proprietary characteristic to the SoftDevice] */
    memset(&add_char_params, 0, sizeof(add_char_params));
    add_char_params.uuid              = BLE_UUID_NUS_TX_CHARACTERISTIC;
    add_char_params.uuid_type         = p_nus->uuid_type;
    add_char_params.max_len           = BLE_NUS_MAX_TX_CHAR_LEN;
    add_char_params.init_len          = sizeof(uint8_t);
    add_char_params.is_var_len        = true;
    add_char_params.char_props.notify = 1;

    add_char_params.read_access       = SEC_OPEN;
    add_char_params.write_access      = SEC_OPEN;
    add_char_params.cccd_write_access = SEC_OPEN;

    return characteristic_add(p_nus->service_handle, &add_char_params, &p_nus->tx_handles);       /* TSP */
    /**@snippet [Adding proprietary characteristic to the SoftDevice] */
}

In the ble_nus.c code (above) I modified to enable notifications (both on RX and TX characteristic) from the peripheral (nRF device) side and because of these changes, I see the below (phone screenshots) on my nRF Connect app Attribute Table. But when I enable notifications on both characteristics, I do not see the data in my temp_ble_tx buffer (from my main.c { below } inside the spis event handler) which is what I need to see on my nRF Connect app. Anyone knows how to resolve this so I can see my data on the app? 

void spis_event_handler(nrf_drv_spis_event_t event)
{

static uint8_t temp_ble_tx[BLE_NUS_MAX_DATA_LEN];
uint32_t err_code;


if (event.evt_type == NRF_DRV_SPIS_XFER_DONE)
{
spis_xfer_done = true;

strcat((char *)temp_ble_tx, (char *)m_rx_buf); /* TSP */

     err_code = ble_nus_data_send(&m_nus, temp_ble_tx,  &length, m_conn_handle);

....

....

RX characteristic properties : Write, Write w/o Response , Notify

TX characteristic properties : Notify 

      ----->             

Parents
  • I am not sure it is a good idea or straight forward to change the logic of the NUS service by changing a characteristic that was by default intended for a handle for the peer to write to, to a characteristic that should now be used in the opposite direction with notification. It seems here that you already have a proprietary characteristic that can notify data, why not just add a small header to that packet to identify the type of notification data that is in the packet? I do not see a clear advantage of having multiple proprietary notifications, they will any case be sent in the order they are written to the softdevice over the BLE link. If you need a second characteristic to notify data I think I would recommend to add a new characteristic to avoid possible issues with the state machine in the NUS service. 

    Best regards,
    Kenneth

Reply
  • I am not sure it is a good idea or straight forward to change the logic of the NUS service by changing a characteristic that was by default intended for a handle for the peer to write to, to a characteristic that should now be used in the opposite direction with notification. It seems here that you already have a proprietary characteristic that can notify data, why not just add a small header to that packet to identify the type of notification data that is in the packet? I do not see a clear advantage of having multiple proprietary notifications, they will any case be sent in the order they are written to the softdevice over the BLE link. If you need a second characteristic to notify data I think I would recommend to add a new characteristic to avoid possible issues with the state machine in the NUS service. 

    Best regards,
    Kenneth

Children
No Data
Related