Determine characteristic handle that caused BLE_GATTS_EVT_HVN_TX_COMPLETE

[Mark Bianchi]

Our nRF52832 BLE application needs to be able to send large bulk data to a phone app. We have patterned the transfers after the ble_app_att_mtu_throughput example, with data transfer notifications queued up and then the transfer continued in the BLE_GATTS_EVT_HVN_TX_COMPLETE event handler.

This is working well as it stands, however we would like to add an additional "bytes remaining" notification to be periodically sent to the phone app while the bulk data transfer is in progress. The problem we have run into is that there does not seem to be any method for determining the source (e.g., CCCD handle) that caused the HVN_TX_COMPLETE event.

Our BLE_GATTS_EVT_HVN_TX_COMPLETE handler is primarily keeping the bulk data transfer going, but occasionally must ignore the HVN_TX_COMPLETE events that come from "bytes remaining" notifies that are interspersed. Unfortunately, we haven't been able to identify a means for accomplishing this.

How can an app differentiate among multiple, different characteristics that can generate notifications, given that ble_event_t does not seem to contain such information for a BLE_GATTS_EVT_HVN_TX_COMPLETE event?

[Petter Myhre]

One way is to keep track of the order you buffer the notifications. So if you buffer one bulk, then one bytes remaining, then one bulk, then one bulk, then one bulk. And then you get a BLE_GATTS_EVT_HVN_TX_COMPLETE with count=3 you know that the first bulk, the bytes remaining and the second bulk is sent.

Another is to not use notification for the bytes remaining, but use indication instead, then you will not get BLE_GATTS_EVT_HVN_TX_COMPLETE event, but a BLE_GATTS_EVT_HVC event instead.

[Mark Bianchi]

I see what you are saying regarding tracking the order of notifications, and that makes some sense (and is simple to implement) if there is only one characteristic with notifications enabled. But it becomes much more complicated if there are more than one characteristic with notifications occurring at the same time. And worse yet, how about when two or more characteristics in different services have notifications occurring? Now the problem must be handled at a higher level than just having each service handle its own notifications.

It seems like the most robust solution would be to change the ble_gatts_evt_hvn_tx_complete_t struct to include the attribute value handle of the notify that was just completed (the hvx_params_t struct already contains this as part of the notify send via sd_ble_gatts_hvx() call). If this were the case, the SDH BLE observer event handler for each service could filter HVX events base on this handle.

Any chance this feature might get into a future SDK? Any other suggestions in the mean time?

[Petter Myhre]

I see your point. I'll bring this feedback to the developers.

At the moment I think the simplest solution is to just send notifications from one characteristic at the time. Don't send two bulks at the same time, if you can avoid it.

[Otso Jousimaa]

I just wanted to chime in and say that I'd also like to have this feature

[Richard]

Thirded - this would be very, very useful. It's often hard to control what notifications an app may be subscribing to - especially in cases where there are a mix of standard services from the SDK (battery, etc) in with your custom services.

[howard n2wx]

Fourthed. This sort of thing was the promise of the context manager...