Handling/checking packet loss in BLE Nordic UART Service (NUS)

I'm using BLE Nordic UART Service (NUS) for streaming data packets which contains read sensor data. I need a way to check the packet loss happening for example if the other device gets slightly out of BLE range for a bit of time and then comes in range immediately. So that I can attempt to retry sending those packets again. As am just getting started with BLE what all are the possible ways in which I can do it or resources from which I can gain more information about this packet loss handling.

Thanks

Parents
  • Hi

    The Bluetooth SoftDevice guarantees delivery of all packets, unless the packet loss is so high that the link disconnects completely. 

    In other words the only consequence you should see is that it could take more time for your data to be transmitted, if they have to be retransmitted by the Bluetooth link layer because of packet loss. 

    You will get an event in the application every time one or more packets have been successfully transmitted, and if you see these events occurring less frequently (or the reported number of packets goes down) it is a sign that you are starting to experience packet loss. 

    Best regards
    Torbjørn

Reply
  • Hi

    The Bluetooth SoftDevice guarantees delivery of all packets, unless the packet loss is so high that the link disconnects completely. 

    In other words the only consequence you should see is that it could take more time for your data to be transmitted, if they have to be retransmitted by the Bluetooth link layer because of packet loss. 

    You will get an event in the application every time one or more packets have been successfully transmitted, and if you see these events occurring less frequently (or the reported number of packets goes down) it is a sign that you are starting to experience packet loss. 

    Best regards
    Torbjørn

Children
  • Hi Torbjørn,

    Thanks for the reply. 

    Im having trouble identifying which event to look for in the application to confirm the successful transmission. Can BLE_GATTS_EVT_HVN_TX_COMPLETE be considered as a confirmation of successfully transmission.

    Can we still get the  successful transmission event if we are using ble_gatts_hvx_params_t,  type as BLE_GATT_HVX_NOTIFICATION. I have heard that notification is an unacknowledged message.

    Also how to use link layer ACK to verify if there is a packet loss, in case if we are using notifications. Is it handled in the soft device or is there an option to get an event associated with it.

    Thanks

  • Hi

    tordown97 said:
    Can BLE_GATTS_EVT_HVN_TX_COMPLETE be considered as a confirmation of successfully transmission.

    Correct. This event will be triggered once one or more packets have been successfully ACK'ed by the peer device. Just keep in mind that there is a count value included in the event that tells you how many packets were sent (you won't get one event per packet, if several packets are sent in the same connection event there will just be one event sent to the application). 

    tordown97 said:
    Can we still get the  successful transmission event if we are using ble_gatts_hvx_params_t,  type as BLE_GATT_HVX_NOTIFICATION. I have heard that notification is an unacknowledged message.

    Yes. The difference between notifications and indications is that indications have to be acknowledged by the application itself, while notifications are acknowledged by the link layer directly. 

    tordown97 said:
    Also how to use link layer ACK to verify if there is a packet loss, in case if we are using notifications. Is it handled in the soft device or is there an option to get an event associated with it.

    Using ACK is not an option in the link layer, it is always enabled. In a Bluetooth connection the master will send a packet to the slave on every connection event, and the slave will respond (ack), whether or not you have any data to send. 

    When the slave sends data to the master then the next packet from the master will count as an ACK. 

    The packet header will contain some bits (labeled SN and NESN) that indicates to the peer device whether or not it received any updates, and by this it will be determined whether to retransmit the previous information, or to send the next packet from the data buffers. 

    Best regards
    Torbjørn

Related