• State Verified Answer
  • Replies 5 replies
  • Subscribers 88 subscribers
  • Views 860 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 318127
Options

Verification method question for ble data loss

SHMoon

hello

By configuring the center and periphery of the nus, the button information of the pepheral is transmitted to the center.

And in the center, data related to the data transmission is transmitted to a separate MCU via UART.

ble = 2Mbps / UART  = 115200bps

* The problem that occurs is when button data is intermittently transmitted to the main MCU.

If it is not a ble problem, I think it is a uart communication problem.

It's too comprehensive... Is there a way or mode to verify where data is missing?

  • 0

    Hi ShMoon, 

    Bluetooth LE in general is a reliable protocol, meaning each packet will be ACked on the peer. If a packet is not arrived and confirmed at the peer device it will be retransmitted. 
    The question here is that when you are queueing your data on the Button device, if you have a buffer full do you wait for it to be ready before you continue or not. 

    Please try to narrow down where the issue would be by checking each of the communication stages. You need to verify if the central receive the data correctly via BLE or not. Then after that check if the Main MCU receive the data correctly or not. 

    You can do the verification by for example having a counter in each of the message. if you don't see the incremental (+1) in the packets you would know that there must be something missing, dropping. 

  • 0 in reply to Hung Bui

    hi

    I didn't know that ack processing was a standard feature.

    I am sending and receiving ble using the method below in the nus example.

    Is it correct that the ack you mentioned is being processed?

    * send

    do
{
err_code = ble_nus_data_send(&m_nus, gBLE_Data_key, &gLen_gBLE_Data_key, m_conn_handle);
if ((err_code != NRF_ERROR_INVALID_STATE) &&
(err_code != NRF_ERROR_RESOURCES) &&
(err_code != NRF_ERROR_NOT_FOUND))
{
APP_ERROR_CHECK(err_code);
}

} while (err_code == NRF_ERROR_RESOURCES);

    *receive

    p_evt->params in function static void nus_data_handler(ble_nus_evt_t * p_evt). It is being received through.

    We are preparing to conduct an experiment using the method you provided, where the actual data is missing.

    thank,.

  • 0 in reply to SHMoon

    Hi SHMoon, 
    I would suggest to study the BLE protocol a little bit more. The acknowledgment and flow control is handled in the link layer (SN and NESN bits)
    You can take a look at section B.II ( Acknowledgement and Flow Control) here: Bluetooth Smart and the Nordic's Softdevices - Part 2 Connection 

    On the application you will not have a callback when you send the data. But as I mentioned if the peer doesn't receive the packet the connection will be terminated. 

    You can implement a mechanism to send a notification back after the sever receives a packet if you want. 

  • 0 in reply to Hung Bui

    hi. 

    I understood BLE's ACK processing through your information.

    Thank you for the good material.

    Additional questions about the material:

    When data sent from the peripheral is not received by the central from the beginning...

    Do you retransmit from the peripheral?

    If the peripheral's transmitted data is not received by the central from the beginning, the algorithm below seems meaningless...

  • +1 in reply to SHMoon

    Hi ShMoon, 
    What do you mean by meaningless ? If the peripheral transmitted data is not received by the central, the central will not increase its sn. The central will try to transmit the same packet again because it's not ACKed. 

Related