• State Not Answered
  • Replies 49 replies
  • Subscribers 64 subscribers
  • Views 7756 views
  • Users 0 members are here
Attachments (2) Download All
Nordic Case Info
  • Case ID: 267225
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE lost messages

NikTheNordicUser

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
  • 0

    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

  • 0 in reply to Karl Ylvisaker

    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 

  • 0 in reply to NikTheNordicUser
    NikTheNordicUser said:
    uint32_t err_code2 =ble_nus_data_send(&m_nus,send_buffer3, &length3, m_conn_handle);  line 910
    APP_ERROR_CHECK(err_code2); line 911

    Thanks. So, now we know both which function that returned the error, and which error it returned.
    Looking into the source code of ble_nus_data_send, we see that it forwards error codes from sd_ble_gatts_hvx. Then we check why the sd_ble_gatts_hvx would return the NRF_ERROR_RESOURCES error, the exempt from the API Reference reads:

    NRF_ERROR_RESOURCES Too many notifications queued. Wait for a BLE_GATTS_EVT_HVN_TX_COMPLETE event and retry.

    So we know that we need to wait for an BLE_GATTS_EVT_HVN_TX_COMPLETE event before we queue more data for transfer. We also read from the note section that the hvx_queue size can be changed to accommodate for more samples queued for transfer before the NRF_ERROR_RESOURCES is generated.
    What is your current size of BLE_GATTS_HVN_TX_QUEUE_SIZE_DEFAULT?
    If you know how many notifications will be queued between each connection event, you could set this buffer to at least be able to hold this number of notifications (plus a couple more for good measure in case of re-transmissions).

    NikTheNordicUser said:
    can you show me how i need to use it and wherre i need to place this event please.

    The ble_evt_handler is passed all the SoftDevice events. You could implement the logic for the BLE_GATTS_EVT_HVN_TX_COMPLETE here.

    Best regards,
    Karl

  • 0 in reply to Karl Ylvisaker
    Karl Ylvisaker said:
    What is your current size of BLE_GATTS_HVN_TX_QUEUE_SIZE_DEFAULT?

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

    Karl Ylvisaker said:
    You could implement the logic for the BLE_GATTS_EVT_HVN_TX_COMPLETE here.

    is it possible to maybe show me how ? please

  • 0 in reply to NikTheNordicUser
    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

  • 0 in reply to Karl Ylvisaker
    Karl Ylvisaker said:
    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.

  • 0 in reply to NikTheNordicUser
    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

Reply
  • 0 in reply to NikTheNordicUser
    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

Children
Related

core_v2_widget.Hide()