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

Identify characteristic on_tx_complete event

I have two characteristics inside a same service - one characteristics notifies periodically and another on demand. I call sd_ble_gatts_hvx to send notifications with appropriate value handles.

When notification is complete, I get on_tx_complete event. Inside this event handler, how can I find out which characteristics's notification was complete?

I don't have the handle for the characteristics that completed notification. I am looking at the ble_gatts_evt_hvn_tx_complete_t structure in ble_gatts.h which has only the count of completed notifications.

I am using nRF52840, SDK 14.0.2 and soft device 5.0.0.2_alpha

  • That's true, only count parameter is provided. The idea is probably following:

    • Notifications are queued and pushed out strictly sequentially, there is no way that one which would be queued later goes over radio earlier.
    • If you have data ready then you should be pushing them through as soon as any TX_COMPLETE event happens. At this point it shouldn't matter what packet went out.
    • If you have two queues on application level then you need to decide on priorities yourself. Again it shouldn't matter which went out, you simply need to view (G)ATT Tx queue inside Soft Device as short extension of your global queue of application messages you want to get out.

    Does it make sense?

  • Yes. But what if I want to do different actions based on which characteristics's notification was complete.

    For example, if a on-demand notification was complete, I want to transition to state_1 and if periodic notification was complete, I want to transition to state_2. I can maintain flags on the application side, but I was looking if the events posted by the stack would tell me which characteristic got notified via a characteristic handle.

  • Well it would be handy but again my hypothesis is that this event comes straight down from LL or L2CAP layer because that's where PDUs are acknowledged by the other side and assembly/reassembly of ATT messages is done. So I'm afraid you will really need to manage your priorities on APP layer. On the other side it should be easy: what goes out is always the first in the queue so if your get TX_COMPLETE event with count 3 you know that first three went out. If you really care which were these then you need to somehow remember the sequence and do some logic around it on your side.

Related