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?

[Hung Bui]

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. 

[SHMoon]

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,.

[Hung Bui]

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. 

[SHMoon]

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...

[Hung Bui]

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.