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

Is there some sort of assurance that ble packets get to the application undamaged and in the correct order?

Hey Guys,

im working on some sort of application transport layer for ble and have some questions to better plan what i need and what is kind of redundant. Is it correct that in the lower layers of the ble stack there is a crc check for every packet and the packets get retransmitted in case of error? Because write_request and indications are drastically limiting the troughput so only writes and notifications should be used to send messages consisting of multiple successive send operations. So is there a chance of packetloss without recognizing it ? Chip is nRF15422 with Softdevice S310.

Thank you for your help :)

  • Yes. At the end of every link layer packet there is a 24-bit CRC.

    Every packet will be acknowledged at the link layer, so if there isn't an acknowlegdement, it will be retransmitted.

  • If you send notifications from the nRF51422 it is not possible to overwrite packet buffers. So the packet will be send until acknoledged by the peer. Bluetooth low energy uses CRC and the packet contains a sequence number and next expected sequence number to ack/nack a packet. So if you are sending data from a nordic device to another nordic device the packet will be retransmittet until received by the peer or until you get a disconnect, in case the peer moved out of range.

    For other implementations it might be possible to overwrite the tx buffers. e.g. if you are sending data from iOS to a nordic device doing multiple writes it is possible to overwrite the tx buffers in iOS. So if you are transfering a lot of data from iOS to the nordic device you should consider adding a CRC check over a given number of packets to make sure you received all the packets. e.g. our DFU service.

  • Thank you very much :) Is it correct that every sd_ble_gatts_hvx notify-operation is calling back with a ble-event and the application should wait for the BLE_EVT_TX_COMPLETE event before calling the next notify operation?

    In the File ble.h the enum says BLE_EVT_TX_COMPLETE means Transmission Complete. Does that mean that all acknowledgments and so on in the link layer are done and the packet should already be received correctly at the receiving device?

    Is there some information how often the link layer tries to retransmit the packet until he assumes the link is lost and call back with a disconnect event or is this somehow visible to the application? Sorry for that bunch of questions in one comment ;)

  • BLE_EVT_TX_COMPLETE will be generated when the packet has been transmitted and the buffer is freed. But you do not have to wait until this event before you call sd_ble_gatts_hvx again as you have multiple buffers available. If you have more data you want to transmitt you can call the hvx function until you get a BLE_ERROR_NO_TX_PACKETS, which means you are out of buffers and need to wait for the TX_Complete event until you can place the packet in the tx buffers. That is if you get the NO_TX_PACKET error you need to call HVX again to send the packet.

    If the link is lost the link layer will retransmitt the packet until the connection supervision timeout is reached.

  • Thank you :) So the BLE_EVT_TX_COMPLETE is generated everytime a packet is transmitted and a part of the buffer is freed or only when the complete buffer is freed?

Related