• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 52 subscribers
  • Views 391 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2650MODA: Controlling the (max) transmission delay

Nenad
Prodigy 140 points
Part Number: CC2650MODA


Hi all,

Application we are developing is time sensitive and we are looking for ways to control the wireless transmission delay. In ideal case, when a packet (notification) is not sent within certain timeframe we would like to be able to discard it (as it is not useful for receiver app) and try to transmit the next packet in line. By doing so we would stay within the delay budget with the transmission (but purposely loosing/dropping packets as a trade-off).

The problem is that, and correct me if I am wrong, once a packet is forwarded to the BLE stack for a transmission (by issuing GATT_notification command) there is very little control over what can happen to it. BLE stack will try to retransmit that particular packet until supervision timeout is reached, however in this case not only that the active packet is dropped but so it the BLE connection it self. This is a bit of suboptimal scenario.

Is there a way around it? Is it possible to stop BLE retransmission after a certain amount of time and give it a new packet/value to transmit, but then drop the connection only if such a scenario repeats for defined amount of times?

Cheers,
Nenad

  • 0
    TI__Guru** 105180 points
    Hello Nenad,

    Unfortunately, your understanding is correct in that the BTLE specification does not allow the application to "flush" the packet that has been passed to the stack. You could try calling the HCI Extension Packet Error Rate API HCI_EXT_PacketErrorRateCmd after every connection event to see if there have been any CRC or missed events. This would give your some a priori insight that things are not going well at the Link Layer . However, you can't flush the previously enqued packet - your only option is to drop the connection using the HCI Extension Disconnect Immediate API.

    I hope this helps.

    Best wishes