Is a GATT server application notified of a client read?

[brianreinhold]

I looked at the following question

nrRF2 GATT attribute read callback

and it does not quite answer what I want to know.

What I need to know is do I get signaled by the nrRF2* BLE hardware when a client attempts to read a characteristic such that I can populate that characteristic with some data that I want the client to receive as a result of the read?  For example, the high level Android server has such an event - but the Renesas RL78 BLE chip does not.

The original question had a yes answer with an 'authorized' read. I am not sure if 'authorized' is a BLE thing or a Nordic thing in this context. I do not want to have to configure the read characteristic to be secured or anything special. The characteristic should only need read permission.

I was looking though the SoftDevice API and did not see any GATT event for a generic client read.  I did see the BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST event noted above but I do not really understand that. To be fair, I have just started looking at the nrRF2* and the pc-ble-driver and supporting systems as a possible use for a BLE client test suite (thus the need to have the application run on the PC using the BLE functionality on the nrRF2*). However, it is critical that the application get signaled that a client attempted to read any readable characteristic so its value can be set (and 'sent') to the client.

I would like to know if it is possible to get evented of a generic read (I assumed it was) because if it is not, all I will lose at this time is the $30 I spent on getting a few test dongles which have not yet arrived.

[Hung Bui]

Hi Brian, 

Your understanding (in your reply) is correct. I would suggest to look at the message sequence chart when you are unsure about something. The read with authorization is described here.

A characteristic with read authorization property set to 0 will not get an event when there is a read. Only those characteristic with the read authorization set to 1 will get an event. And you need to reply before the softdevice can send the read response. 

The Bluetooth spec doesn't define how exactly the read authorization should be, but it does mention a bit about it at section 3.4.4.3 Part F Vol 3 Bluetooth Core spec v5.1 : 

If the attribute value cannot be read due to permissions then an Error Response shall be sent with the error code Read Not Permitted.

The connection security authorization is something different (with error code: Insufficient Authorization.) 

Btw, what is nRF2 or nRF2* ? I guess you meant nRF52 ? 

[brianreinhold]

So just to be absolutely clear:

If I create a service that has a characteristic with permission read and a default value;

When the client reads it I WILL get an event and I can at the time of the event change that default value (or do something) such that the client gets the new value in the read response. 

If I can do that for any characteristic that has read permission then I am happy. I hope so as I have already ordered some trial dongles!

[brianreinhold]

Andy, thanks for that. I did some extensive googling and looking through the BT spec 5.0 (didn't find much there) but did find that authorization is application-specific; in other words the only thing the client knows about the characteristic is that it is readable. That is good. Here is a good link on that which states it in clear text: http://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_1_40_00_45/docs/blestack/ble_user_guide/html/ble-stack-3.x/gatt.html

I do NOT want to use the read with authorization option to authorize but to catch the client read and set the value they are going to get in the response at the time of the read. It would be a twisted way to do that but it seems many BLE chip developers don't understand that a peripheral may have some readable characteristic that changes frequently but the client may only need to access it's value infrequently. Who wants to frequently update the characteristic data base (perhaps 100s of times per second) when the client may never need to read it or only needs to read it once and a while?

For example, I had an activity monitor following the IEEE 11073 20601 cardio specialization using a relative time clock. Relative time clocks are easy to implement as they are only a sequence of ticks. One of the characteristics in this activity monitor service was the current relative time in milliseconds. All the measurements taken reported a time stamp using this relative time clock. The client, however, needs to turn this relative time into a wall clock time. It does so by reading the current relative time characteristic and looking at its current wall clock time. Then it can convert all relative time stamps in the measurements (in the future and the past) to wall clock time. But the client only needs to read the current time once per connection. When that read happens is not known. So if I can catch the read, I can set the characteristic to the current time. If one CANT catch the read, one has to update the characteristic value in the database 1000 times a second. Are you kidding??!!! But if the read with authorization allows me to pull this off, I am good!

Even the Android BLE server API allows catching ordinary reads.

[Hung Bui]

@Brian: To be able to use the dongle as the connectivity IC for the PC, you would need to run serialization on the dongle. And it requires you to implement an application on PC. We supply you with the pc-ble-driver here.

Note that this is rather advance and require you to have some experience with our SDK and stack. I wouldn't suggest to jump directly on development with serialization application. 

@Andy: i would assume here Brian is not asking about authorization when bonding and pairing, but more about authorization when a characteristic being read/write, which is not related. 

[brianreinhold]

@Hung Bui  am well aware of the serialization part and have looked at the pc-ble-driver and docs. I NEED the serialization part and NEED to run the application on the PC. I have had an ongoing discussion in this forum regarding that issue and configuring the nRF52 dongle for serialization. I have worked with a similar serialization library for the Renesas RL78 dongle but the RL78 BLE implementation has too many shortcomings (not being signaled reads is one of them) for our needs.

In the end all I want to be able to do is to intercept a client read and be able to set the value that the client gets in the response at the time of the read. If the only way to do that is to configure the characteristic with 'read with authorization' then that is fine. The client will only see that the characteristic is readable.

[Hung Bui]

I think you have all you need. I don't see any problem to implement what you described. 

[brianreinhold]

Music to my ears! The dongles should be arriving any day now .. we will see!