Reading characteristic data in central

RE: Reading characteristic data in central

Karl Ylvisaker — Wed, 13 May 2020 13:00:58 GMT

Hello,

[quote user="Nishanth_M"]Thanks for your reply......[/quote]

No problem at all, I am happy to help.

[quote user="Nishanth_M"]Now the client gets the READ request, but how to view the data or get the data in NRF52840 which i received from the client. What I need to do now....Help me to solve this problem....[/quote]

From this I assume that you have seen the GATT Queue documentation?
As stated in the documentation, your call to nrf_ble_gq_item_add will queue a read request for execution immediately once the SoftDevice is available to do so. When the read request then is issued, the function sd_ble_gattc_read is actually called - which generates a BLE_GATTC_EVT_READ_RSP event. This event contains the data responded by the peripheral to the read request. You therefore need to make sure that your event handler handles this event, in order to receive the data.

Is this what you were looking for?

Best regards,
Karl

RE: Reading characteristic data in central

Nishanth_M — Tue, 12 May 2020 19:51:40 GMT

Hi,

Thanks for your reply......

I have tried the following:

nrf_ble_gq_req_t read_req;
    memset(&read_req, 0, sizeof(nrf_ble_gq_req_t));
    read_req.type                        = NRF_BLE_GQ_REQ_GATTC_READ;
    read_req.error_handler.cb            = gatt_error_handler;
    read_req.error_handler.p_ctx         = p_ble_lbs_c;
    read_req.params.gattc_read.handle   = p_ble_lbs_c->peer_lbs_db.button_handle;
    read_req.params.gattc_read.offset   = 0;

err_code = nrf_ble_gq_item_add(p_ble_lbs_c->p_gatt_queue, &read_req, p_ble_lbs_c->conn_handle);

Now the client gets the READ request, but how to view the data or get the data in NRF52840 which i received from the client. What I need to do now....Help me to solve this problem....

RE: Reading characteristic data in central

Karl Ylvisaker — Mon, 11 May 2020 15:13:52 GMT

Hello,

Have you looked into using notifications for this purpose?
This way, you will not have to read the buffer to discover that it is unchanged - but rather the central might receive a notification once the contents of the buffer is changed.
That way, you could also make use of "slave latency", which allows the slave to skip connection intervals if the data is not updated - significantly decreasing radio time and battery consumption.
To do this, you will need to make sure that the central device has notifications enabled.

As an example, you could see the HRS peripheral example, which uses notifications to send its heart rate measurements.
In the example, there is a timer that triggers the heart_rate_meas_timeout_handler which in turn calls ble_hrs_heart_rate_measurement_send that uses the SoftDevice function sd_ble_gatts_hvx to actually perform the notification.

For how 'notifications' work, please take a look at this message sequence chart. For how 'read' works, please take a look at this message sequence chart.

If you would like to proceed with using the read function, please see the sd_ble_gattc_read function and its documentation here.

Best regards,
Karl