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 

  • NikTheNordicUser said:
    i found that in the ble_gatts.h (of the pheripheral code) it is set as 1

    So there is only space to queue 1 notification for transfer before you will generate the NRF_ERROR_RESOURCES.
    How many notifications do you intend to queue between each connection event?

    NikTheNordicUser said:
    is it possible to maybe show me how ? please
    Karl Ylvisaker said:
    The ble_evt_handler is passed all the SoftDevice events. You could implement the logic for the BLE_GATTS_EVT_HVN_TX_COMPLETE here.

    Add a case for this event into the ble_evt_handler, then implement the logic you would like to have happen when this event is generated. What do you intend to have happen when this event is generated?

    Best regards,
    Karl

  • How many notifications do you intend to queue between each connection event?

    umm.. im not really sure is there a max value ? My application requires for fast transfer as i mentioned in the very begining the pheripheral board contains a gyro and acc sensor which communicates via spi and this pheripheral board sits on a motor such that i measure RPM in matlab after the hex data of sensor is sent via ble to the client pcb. is there a max number of queue as ideally meanwhile i am filling up the sending buffer with the spi data i would be sending a previously filled buffer. thats why i would like to monitor the ble gatts event tx complete flag such that i can remove all delays and ensure that data is fully sent and there are no queuse before i send another buffer

    im not sure if wat im saying is understandable.

  • NikTheNordicUser said:
    im not sure if wat im saying is understandable.

    I think I get the picture, but thank you for the understanding.

    NikTheNordicUser said:
    umm.. im not really sure is there a max value ?

    I dont think there is a max value other than the physical limitations of the SoC - i.e how much RAM do you have to spare?
    However, allocating everything that you have spare is not the best approach for this. Rather, you should look at how much that will actually be transferred in each interval.
    For example, how much throughput do you need to have all the necessary sensor data sent each second, and how much latency can you have in your system?
    If you group multiple measurements together up till the MTU size, and increase the connection event lengths, you will be able to send multiple larger packets per connection interval, for instance.
    But, in order to determine what configuration you should use, you need to know more exactly how many bytes you intend to transfer, and how often you intend to transfer them.
    You could take a look at the BLE throughput tables in the SoftDevice docuementation to determine the best connection parameters and configuration for your application.

    It could also be helpful for you to check out the the Online Power Profiler to visualize how each transfer will happen, with the different connection configurations.

    Please do not hesitate to ask if any part of my answer should be unclear!

    Best regards,
    Karl

  • ok so let say i want to have this configuration 

    is it possible to be shown how or what i would need to change. also as previously mentioned i would like to remove the delay such that i make it interrupt based and use the BLE_GATTS_EVT_HVN_TX_COMPLETE event which should ensure no resetting of the mcu .

    i would like to transfer a max of 242 bytes at once if possible with an output data rate of max 400 (the sesnor supports a data rate of 2000) but this setting should be enough for my application which setting do you suggest and the connection between the pheripheral and client is always active such that if theres data is constantly sent at the set settings

  • ideally i would use a throughput of 2 PHy 

Reply Children
  • but anything i change results in the central not connecting so i am very confused at what is going on and ideally i would like to have the configuration of the fastest transfer

  •  i would like to have a similar approach to this, such that i send a packet at a tie will i recive the flag is finished

  • NikTheNordicUser said:
    as previously mentioned i would like to remove the delay such that i make it interrupt based and use the BLE_GATTS_EVT_HVN_TX_COMPLETE event which should ensure no resetting of the mcu .

    As previously mentioned you have to implement the handling for the BLE_GATTS_EVT_HVN_TX_COMPLETE event in the ble_evt_handler. For more detail please see the answer by my colleague Einar in your other ticket. If anything still is unclear on how you should proceed with this, please try to be more specific in your questions.
    Please try to implement this as I have said previously - when a NRF_ERROR_RESOURCES is returned from ble_app_data_send, have the data placed in a buffer and set a flag to indicate that the buffer holds data. Then implement the BLE_GATTS_EVT_HVN_TX_COMPLETE event that checks whether the buffer holds data, and if it does, queues it for transfer.
    Furthermore, the MCU does not have to reset when the NRF_ERROR_RESOURCES error code is returned from the call to ble_nus_data_send. This is the default error handling - you are free to implement specific error handling for your specific application, so that the device is able to handle the error without having to reset.

    NikTheNordicUser said:
    but anything i change results in the central not connecting so i am very confused at what is going on and ideally i would like to have the configuration of the fastest transfer
    NikTheNordicUser said:
    ideally i would use a throughput of 2 PHy 
    NikTheNordicUser said:
    i currently have this configuration

    The central determines the connection parameters. The peripheral may only either accept the parameters that the central send, or disconnect. If there is a mismatch between the preference of the central and the peripheral, the peripheral will send a parameter update request. This request can be declined by the central, and the peripheral may then either accept this or disconnect.
    If you with to change your connection parameters you will therefore have to change them on the central side.
    Then, you should also update the preference of the peripheral to match the changes you've made on the central side, or make sure that the peripheral does not disconnect if its preferences are not met.
    If you wish to set the connection interval to a specific number, like 50 ms, then you have to set both _MIN and _MAX to 50 ms, forcing this particular interval.

    NikTheNordicUser said:
    i would like to have a similar approach to this, such that i send a packet at a tie will i recive the flag is finished

    To send multiple notification packets back-to-back in the connection event, the event length needs to be configured to be the same as the connection interval, like mentioned directly before the throughput table you've shared a screenshot of. What is your event length?

    Try these two things, and let me know if anything is unclear, or if you encounter any issues.

    Best regards,
    Karl

Related