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

BLE lost messages

Hi, as part of my project i have 2 nordic 52dks one as a pheripheral (sending) and on as a client (recieving). where i am sening a buffer of 8, in the order

buffer[0] = 10

buffer[1}= X gyro lsb

buffer[2] = X gyro msb

buffer[3] = y gyro lsb

buffer[4] = y gyro msb

buffer[5] = z gyro lsb

buffer[6] = z gyro msb

buffer[7] = 36   //terminator $

however sometimes i seem to lose a byte over ble such that the next byte received will be less and hence the order is correupted thus making processing rather and unpredictable for a large sample size like 1000000 samples.

how may i ensure that my ble settings are correct such that i ensure to limit this issue.

my code was based of the examples ble_app_uart and ble_app_uart_c for the peripheral and client respectivly.

thank u in advance 

Parents
  • Hello,

    however sometimes i seem to lose a byte over ble such that the next byte received will be less and hence the order is correupted thus making processing rather and unpredictable

    No byte is lost over the BLE link, it is not possible as the protocol uses the CRC field to verify that the contents of the packet is uncorrupted and received as it was sent. If the CRC does not match, the packet is discarded and not acknowledged - leading to a re-transmission of the same packet.
    If you would like to confirm the communication happening on-air between the devices you could use the nRF Sniffer tool to trace the communication and read the individual packet contents.

    How is your handling / processing of the received data? How are you alerted to the seemingly corrupted data? Have you checked whether the corrupted values could be what the peripheral intended to send?

    Looking forward to resolving this issue together!

    Best regards,
    Karl

  • Firstly i would like to thank you for your reply, and for the sniffer, is there any documentation on how to install this please?

    The way im checking that the data is being missed is through the uart terminal of the client (recieving) board and also i have a matllab script that is reading serially aswell. to check this i sent known data meaning sending 8 bytes (hex) 10-16 and a terminator 36.

    and as u can see in the first colomn its fine but then in the second colom the 12 didnt send or be recieved which will therefore mess up my data 

Reply
  • Firstly i would like to thank you for your reply, and for the sniffer, is there any documentation on how to install this please?

    The way im checking that the data is being missed is through the uart terminal of the client (recieving) board and also i have a matllab script that is reading serially aswell. to check this i sent known data meaning sending 8 bytes (hex) 10-16 and a terminator 36.

    and as u can see in the first colomn its fine but then in the second colom the 12 didnt send or be recieved which will therefore mess up my data 

Children
  • however wat i also noticed that if i increase the sending buffer to 20 bytes the missed message does not happen as often as with the 8 bytes

  • NikTheNordicUser said:
    Firstly i would like to thank you for your reply

    No problem at all, I am happy to help!

    NikTheNordicUser said:
    for the sniffer, is there any documentation on how to install this please?

    Yes, there is a README file in the zip folder you can download at the bottom of the sniffer's product page. It describes how to get the sniffer up and running.
    It is a powerful tool to wield when developing BLE applications, and I highly recommend giving it a try! :) 

    NikTheNordicUser said:
    The way im checking that the data is being missed is through the uart terminal of the client (recieving) board and also i have a matllab script that is reading serially aswell. to check this i sent known data meaning sending 8 bytes (hex) 10-16 and a terminator 36.

    Then it sounds to me like your peripheral (transmitting) might fail one of its call to queue data for sending. How have you implemented error handling (specifically for the NRF_ERROR_RESOURCES error) for the error codes returned by ble_nus_data_send?
    It sounds to me like you might be filling up your notification TX buffer, which leads to an error when calling the send function to queue the next piece of data for sending, and then the application just moves on - practically just skipping the data that failed to queue. Could this be the case?

    Best regards,
    Karl

  • im not sure if i understood.. apologies.. is there a way from the handler that i can set some sort of flag that can indicate that a ble transfer has been done please.

    also the way that i am sending the data is as follows

  • NikTheNordicUser said:
    also the way that i am sending the data is as follows

    I cant see anywhere that you are checking what the returned error code of the ble_nus_data_send function is. This is what I suspected in my previous comment, I should have been more explicit.
    Please add an APP_ERROR_CHECK(err_code) following your call to ble_nus_data_send, to see if the call succeeded.

    Please also ensure that you hade DEBUG defined in your preprocessor defines, like shown in the included image.


    This will print a detailed debug message to your logger, if a non-NRF_SUCCESS error is passed to an APP_ERROR_CHECK.

    Please make sure to always check your returned error codes. If there are other places in your code where you are not checking them, please go back and add an error check.
    The returned error codes are critically important to understand issues during development, and for handling run-time errors when the application is deployed.

    Please do this, and let me know what is printed to your logger when the issue occurs.

    Best regards,
    Karl

Related