ble_event and ble_event_handler

[Owlman]

I'm new to Bluetooth LE, Python and C. I have the S130 python examples for heart rate testing. I am attempting to modify the heart rate collector code to act as our central device which can read and write data to a TI based peripheral.

The example seems to connect, then loop notifications. In my scenario this seems like a good place to add a few read and write commands. Here's what I don't understand: how is the ble_evt_handler never "NONE" and what/when does it get set? Also how does the ble_event.header.evt_id ever become something other than CONNECT when its only called once?

Do I even need to worry about setting up on_write and corresponding read in this case since I'm not doing a hrm?

[Petter Myhre]

If you are using the SoftDevice handler library you set the BLE event handler with softdevice_ble_evt_handler_set().

The SoftDevice uses software interrupt 2 (SWI2_IRQHandler) to tell the application that an event is ready to be pulled. In this interrupt routine intern_softdevice_events_execute() is called which pulls the events from the SoftDevice and calls the previously set BLE event handler.

Also how does the ble_event.header.evt_id ever become something other than CONNECT when its only called once?

I'm not sure why you would think it is only called once. It is called every time the SoftDevice has a BLE event for the application.

For example if you do a GATTC Characteristic or Descriptor Value Read by calling sd_ble_gattc_read() the application will get the BLE_GATTC_EVT_READ_RSP event.

When you get this event the ble_gattc_evt_read_rsp_t struct will contain information about the read operation:

/**@brief Event structure for @ref BLE_GATTC_EVT_READ_RSP. */
typedef struct
{
  uint16_t            handle;         /**< Attribute Handle. */
  uint16_t            offset;         /**< Offset of the attribute data. */
  uint16_t            len;            /**< Attribute data length. */
  uint8_t             data[1];        /**< Attribute data, variable length. */
} ble_gattc_evt_read_rsp_t;

You don't need to handle events that never will occur, events that don't contain information you need, or events that don't need a respons.

[Owlman]

Thanks for clearing up many things. I interpreted the ble_event.header.evt_id being called once because in the python def main code it was called once, but as you stated the event triggers every time a BLE event occurs. I think what is still confusing is in Python. Procedurally speaking if there is no visible way to pass an event to ble_event parameter in the def ble_evt_handler it should always be none based on appearance in how the code is laid out.

Actually def log_message_handler is the same way. It has two parameters in the function but when called there aren't any. Again I don't know the particular quirks of python to understand why this is.

[Petter Myhre]

No problem :) Maybe you could accept my answer by clicking the grey circle next to it? I'm not too familiar with Python myself, but if you have a specific question you can add it here. Maybe someone can answer :)