observing GATT and Advertising events?

[Allen]

Hello,

SDK51 appears to be an inconsistency with how various BLE related events are handled in the SDK. Multiple BLE event handlers may be registered using the NRF_SDH_BLE_OBSERVER macro. This is great because it enables modules to implement their own BLE event handling.

NRF_SDH_BLE_OBSERVER does not provide access to the following events:

• BLE Advertising events
• GATT events (GAP, GATTC and GATTS are...?)
• Connection Parameter events

You may provide an event handler in the init call. However this is not the same as registering a BLE event observer.

Can someone explain the rational behind this architecture? It seems that either the BLE observer should receive all events or you should have the ability to register observers.

Thanks

[Einar Thorsrud]

Hi,

By the way, I assume "SDK51" is SDK 15?. In any case this has been more or less the same for some time now, but I will assume that for now.

I am not sure I follow you. You should get all BLE events in the registered observers. You can see this from the implementation of nrf_sdh_ble_evts_poll() in components\softdevice\common\nrf_sdh_ble.c. You can also see many examples that use the various types of events you mention in the BLE event handlers.

[Allen]

SDK52 I believe is how you refer to the standard Nordic SDK.

As mentioned, there are certain events that do not go through the standard on_ble_event handlers. The most important ones are the GATT events. When the GATT is initialized you can specify a handler that will be called. If you have other handlers for those events you must forward them yourself from this registered handler. The interesting thing is that it appears that all the BLE related event IDs are unique across all the event types. Therefore there is no reason why GATT events could not be delivered to the BLE event observers.

The GATT events are important to our application because they are the only way of being notified of the MTU size and PHY speed negotiation. Since these event IDs are unique I am forwarding them to the same on_ble_evt() event handlers. The those cases take care of the event structure difference passed to the function.

[Einar Thorsrud]

Hi,

Allen said:

SDK52 I believe is how you refer to the standard Nordic SDK.

There are currently two families of SDKs provided by nordic. The nRF5 SDK, where the latest release is 17.0.2 and the nRF Connect SDK, where v1.5.0 is right around the corner. I understand you are using the nRF5 SDK, but I would be interested in knowing which version as the way BLE events are distributed is not the same for all versions. Can you please let me know which exact SDK version you are using?

Allen said:

As mentioned, there are certain events that do not go through the standard on_ble_event handlers. The most important ones are the GATT events

the NRF_SDH_BLE_OBSERVER macro is used to subscribe to all BLE events, including GATT events. To see this from code you can see the in SDK 17.0.2 the GATT module, which is created using the NRF_BLE_GATT_DEF macro. That just makes a nrf_ble_gatt_t instance, and includes NRF_SDH_BLE_OBSERVER so that the GATT module implementation subscribes to BLE events. Then looking at the implementation in components\ble\nrf_ble_gatt\nrf_ble_gatt.c you can see that it handles both GAP and GATT events. There are many other parts of the SDK that show this as well (just see for instance the handling of BLE_GATTC_EVT_TIMEOUT and/or BLE_GATTS_EVT_TIMEOUT in the ble_evt_handler() function in main.c of almost all BLE examples).

Please elaborate on how you are not getting GATT events. In short, if you get any BLE events, you will get all unless you filter some out yourself. Perhaps you can share some code snippets and show how you have done things and how you miss the GATT events.

[Allen]

Einar,

I am using SDK 17.0.2, soft device S132 7.2.0

Thank you for the explanation. All of the examples where the MTU size change is handled, the implementation responds to the NRF_BLE_GATT_EVT_ATT_MTU_UPDATED event.  Now I see this is a secondary event generated as a response to the BLE_GATTC_EVT_EXCHANGE_MTU_RSP event. To the casual user it isn't obvious that GATT isn't a unique event type like GATTC and GATTS where the only way to register to received them is to provide an event handler to the gatt init function.

GAP parameters and Advertising are BLE related processes that are triggered by BLE connection events. Therefore they are not truly a BLE protocol event.

Thank you for the explanation. It is still true that there are multiple mechanism to receive BLE related events. All actual BLE protocol events are delivered to the ble event handlers. Depending on the application you may still need to register multiple BLE event handlers via different registration methods.

[Einar Thorsrud]

Hi,

I am glad to hear you sorted it out.

Allen said:

It is still true that there are multiple mechanism to receive BLE related events. All actual BLE protocol events are delivered to the ble event handlers. Depending on the application you may still need to register multiple BLE event handlers via different registration methods.

In case anyone else reads this thread I would like to elaborate on this. As I briefly described in my previous reply, the GATT module also gets BLE events including GATTC and GATTS events by simply registering for BLE events form the SoftDevice. So you will get these by registering with the NRF_SDH_BLE_OBSERVER macro. However, you will not get events from the SDK GATT module itself this way, which are two specific events: NRF_BLE_GATT_EVT_ATT_MTU_UPDATED and NRF_BLE_GATT_EVT_DATA_LENGTH_UPDATED. (You will get BLE_GAP_EVT_DATA_LENGTH_UPDATE and BLE_GATTC_EVT_EXCHANGE_MTU_RSP from the SoftDevice in these cases).