• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 52 subscribers
  • Views 619 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.

RTOS/CC2640R2F: Receive the Ack from INDICATIONS in characteristic.

Leoni Mota Loris
Expert 1225 points
Part Number: CC2640R2F
Other Parts Discussed in Thread: CC2640, BLE-STACK

Tool/software: TI-RTOS

* Setup:

- cc2640r2f acting as a peripheral BLE.

- Simplelink 1.40.00.45.

- Custom services and characteristics including a characteristic with WRITE | READ | INDICATE properties.

* Question:

- Whenever I receive an INDICATION from my cc2640 peripheral, I send a confirmation (Ack) from my host (GATT Client, or server).

But it looks like this Ack does nothing inside the peripheral stack (such as resend the indication if not ack was received) because I can still communicate with other characteristics as well as the indication (it looks like it is working just like an notification)

Do I need to manually implement the logic for "resending the indication whenever no ack was received" or is it supposed to be handled by the stack BLE?

Cheers.

  • 0
    TI__Guru 57865 points
    Hi Leoni,
    The indication need to be ACKed by the application, per specification. There is no mechanisms in the BLE-Stack.
  • 0 in reply to J Lindh
    Expert 1225 points
    What is the difference then? It looks like they're the same (notification, indication), even though they are not supposed to be the same.
  • 0 in reply to Leoni Mota Loris
    TI__Guru* 81491 points
    Hi Leoni,

    When an indication is sent from the GATT Server device, the GATT Client device will automatically ack. This is the difference between indication and notification.

    If you want your GATT Sever application to do something when the ACK is received, you must catch it in the application thead (GATT message).

    In the Bluetooth Core Spec, all connection event packages that are lost are re-sent by the stack. This is true both for indication and notification packets (and ACK packets). You do not need to implement this.
  • 0 in reply to Marie H
    Expert 1225 points

    Ok.

    My host (GATT client, the one that starts a connection) does not implement the automatic Ack, but I can send this Ack.

    I just need to be sure that when:

       * I send this Ack (from the host), AND

       * the Peripheral (cc2640 or gatt server or sensor sending data) with an INDICABLE characteristic changes its value

    I am going to RELIABLY receive the indication (at least it needs to be more reliable than notification).

    Cheers.

  • 0 in reply to Leoni Mota Loris
    TI__Guru* 81491 points
    Hi Leoni,

    The order is opposite of what you describe:
    1) The caracteristic changes value (for whatever reason)
    2) An Indication packet is sent from the GATT Server (peripheral device)
    3) When the indication is received on the GATT client (central device), the ack packet is sent.

    You should be able to reliably receive the indication packet but you should also be able to reliably receive notification packets. If you're having issues you can look at:
    - Is the RF environment too busy (too many re-tries)
    - Is your out-packet buffer large enough to handle all the packets your application is queuing? (See MAX_NUM_PDU in the BLE-Stack User's Guide)
    - Is your conenction interval too long? Are you queuing up too many packets between each connection event?
    - It can also be helpful to use a BLE sniffer to get an idea about where the packets are lost.
  • 0 in reply to Marie H
    Expert 1225 points
    Ok.
    I will check each of the points you made and then, I will reach you guys in the forum again.
    Thank you.
    Cheers.