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 

  • 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 

  • 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

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

    No problem at all, I am happy to help!

    NordicNewbee 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! :) 

    NordicNewbee 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

Related