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

Data sending of ble_app_uart question in ble_central

I example test ble_central and ble_peripheral of ble_app_uart. Radio TX and RX test is OK. It confirmed the data communications relating to uart_event_handler function.

if ((data_array[index - 1] == '\n') || (index >= (BLE_NUS_MAX_DATA_LEN)))
{
    err_code = ble_nus_string_send(&m_nus, data_array, index);
}   

when '\n' or length, should call the function ble_nus_string_send. But I have an arduino download wirelessly(nrf51822). arduino download data without the epilogue to '\n', length also is not fixed. I want to spend as data is coming. So, modified ble_app_uart. uart_event_handle function of ble_pripheral and ble_central as below.

switch (p_event->evt_type)
    {
        case APP_UART_DATA_READY:
            UNUSED_VARIABLE(app_uart_get(&data_array[index]));
            index++;
            ble_nus_string_send(&m_nus, data_array, index);
            index = 0;
       break;
....

ble_pripheral is OK. ble_central is not OK. ble_central When you send the data 10 received only one front. Where parts need to modify? Or is the source code for the modem type?

Parents
  • The regular UART part of the NUS examples uses hardware flow control, as can be read in the documentation for the example, section Initializing UART: "Note that app_uart_comm_params_t configures the application to use hardware flow control. Therefore, RTS_PIN_NUMBER and CTS_PIN_NUMBER are used as Ready-to-Send and Clear-to-Send pins, respectively."

    The Nordic UART Service (NUS) should be reliable as long as the BLE connection is not lost, and I do not see why \n should be handled differently from other characters there. Have you located where in the transfer it breaks? (I.e. at which of the three links UART, NUS and UART.) Also, are you sure that the \n character is handled correctly by both [A] and [B]?

Reply
  • The regular UART part of the NUS examples uses hardware flow control, as can be read in the documentation for the example, section Initializing UART: "Note that app_uart_comm_params_t configures the application to use hardware flow control. Therefore, RTS_PIN_NUMBER and CTS_PIN_NUMBER are used as Ready-to-Send and Clear-to-Send pins, respectively."

    The Nordic UART Service (NUS) should be reliable as long as the BLE connection is not lost, and I do not see why \n should be handled differently from other characters there. Have you located where in the transfer it breaks? (I.e. at which of the three links UART, NUS and UART.) Also, are you sure that the \n character is handled correctly by both [A] and [B]?

Children
No Data
Related