• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 1214 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.

Original question:

BLE Indications

RTOS/CC2642R: BLE Indications - how to tell which char received an ACK?

Koby Fruchtnis28
Intellectual 690 points
Part Number: CC2642R

Tool/software: TI-RTOS

Hello.

I have 2 characteristics that can send indications (The central can activate indications on both of them).

The peripheral can send indications on any one of them at any time.

I need to know that each message sent was received, by capturing the BLE ACK received from the central.

 

The problem:

I'm capturing the ATT_HANDLE_VALUE_CFM event in SimplePeripheral_processGATTMsg, but I can't tell which char it relates to.

I tried to cast the gattMsgEvent_t.msg to handleValueInd (part of the gattMsg_t union), but all values there are 00000.

Is there anyway to know which char is responsible for this message?

  • 0
    TI__Genius 11535 points
    Hi Koby,

    I'm a little confused on what you are trying to do, can you clarify? Normally if you have a characteristic with an indication or notification, you can setup the callback in SimplePeripheral_SetParameter() by using GATTServApp_ProcessCharCfg(). You can look at how the Simple Peripheral examples handles notifications in simple_gatt_profiles.c.

    You can also look at the GATTServApp Module section of the BLE5 Stack User's Guide: dev.ti.com/.../gatt.html
  • 0 in reply to Jessica H.
    Intellectual 690 points

    Hello Jessica.

    I will try to clarify.

    My code already sends indications, and they are received OK by the central. Both my characteristics send indication without problem.

    I'm trying to differentiate between ACKs received after sending these indications, in order to know to which characteristic the ACK is related.

    Since I have 2 characteristics I'm sending indications from, both of them receive ACKs from the central, which sends the ACK for each indication received by it.

    As said before, the ACK received by the peripheral generates an  ATT_HANDLE_VALUE_CFM event, captured by my SBP task.

    However, that event alone is not enough to tell which characteristic this ACK belongs to.

  • 0 in reply to Koby Fruchtnis28
    TI__Genius 11535 points
    Hi Koby,

    Why are you trying to do this in your application? Most of this gets handled in the link layer. Also the last characteristic to send the indication will be the one that the ACK belongs to.
  • 0 in reply to Jessica H.
    Intellectual 690 points

    Clarification attempt #2 :

    Suppose I have 2 char's with indications.
    Char' A is for receiving commands via WRITE and sending back "command complete" via INDICATE.
    Char' B is for sending a data via INDICATE. And not just a single INDICATE. I sometimes have several KB of data to send, so I send hundreds of indications in a row.
    To send the CHAR' B's indications as fast as possible, I send them chained to each other.
    To do that, I wait for the ATT_HANDLE_VALUE_CFM message, received by the SBP task, and from there call SimplePeripheral_SetParameter to set the CHAR's new value and send it via another indication.

    But, the ATT_HANDLE_VALUE_CFM message can also arrive after sending Char' A INDICATE, and calling SimplePeripheral_SetParameter in that case will be erroneous.

    The SDK doesn't allow me to know the CHAR source of the ATT_HANDLE_VALUE_CFM.

    I can manually keep track of the last CHAR that has sent an indication, to know when I can call SimplePeripheral_SetParameter, but I hoped the SDK will provide information on the source of the ATT_HANDLE_VALUE_CFM, instead of me keeping track of that "last-char-to-send-indicate" info.

    Keeping track of the "last-char-to-send-indicate" doesn't help in all cases - it prevents me from responding to any commands coming from CHAR' A, until the data sending from CHAR' B has completed. That is because the "last-char-to-send-indicate" record keeping will get complicated due to race conditions.

  • 0 in reply to Koby Fruchtnis28
    TI__Genius 11535 points
    Hi Koby,

    I am looking into this and will get back to you. Which SDK are you using?
  • 0 in reply to Jessica H.
    Intellectual 320 points

    simplelink_cc26x2_sdk_2_10_00_44
    Thanks
    Koby

  • 0 in reply to Koby Fruchtnis14
    TI__Mastermind 25045 points
    Hi Koby,

    Would you mind sharing your peripheral project so we can run a few tests with it.

    Thanks and apologies for the delay.

    Best regards,

    David
  • 0 in reply to DavidL
    Intellectual 690 points

    Hello David,

    I'm sorry, but the project is proprietary and it is not possible to post it.

    Creating a demo project demonstrating the issue will take several hours, a period of time I can't invest at the moment.

    Are there specific code snippets you would like to see, to help clarify the issue?

    thank you

    Koby

  • 0 in reply to Koby Fruchtnis28
    TI__Mastermind 25045 points

    Hi Korby,

     There is no need to share you project, we put together a similar example and after looking into the ATT Indication Confirmation Packet, the ATT Payload does not include the attribute handle.

    So we can not decode which char was the one acknowledged. You might want to look into how our OAD works software-dl.ti.com/.../oad.html, this could give you another alternative on how to send big chunks of data in a reliable way.

      Best regards,

       David

  • 0 in reply to DavidL
    Intellectual 320 points

    I hope an update to the API will be included in the next SDK release, since it seems important to know which char was ack'ed.

    As for using the OAD as an example:

    I saw that the TI E-OAD android app reaches transfer rates of 2.5KB/sec, while my transfer method reaches 6.5KB/sec using the "nRF connect" Android app, so I will not switch to the OAD method for now.

    thank you

    Koby