Reading a subset of data on a BLE server

RE: Reading a subset of data on a BLE server

Joe Merten — Wed, 28 May 2014 11:06:48 GMT

Unfortunately, the attachment has been lost, isn't it?

RE: Reading a subset of data on a BLE server

Jim — Thu, 26 Sep 2013 13:04:21 GMT

Ah, I see. Not surprising then that the naming comes from a committee. :-)

RE: Reading a subset of data on a BLE server

Carles — Thu, 26 Sep 2013 13:00:34 GMT

FYI, I would have called the two flavors of reading something like "read static" (your default), and "read dynamic" (where I implement the code to compute the result). This is similar to how you can implement accessors in languages like C#, Java, or Scala. They can be just values, or you can write code to dynamically compute the value.

Thanks for the suggestion, but one of the core tenets of our API is "use the wordings of the Bluetooth spec whenever possible". The Bluetooth specification uses "authorization" for this particular use case, and hence we adopted the same nomenclature.

RE: Reading a subset of data on a BLE server

Jim — Thu, 26 Sep 2013 12:58:33 GMT

Yes, I came across this last night, and now have it working. I hadn't noticed it before because I'm not currently thinking of securing the communications, and rd_auth seemed like a security mechanism. It does precisely what I want. Thanks.

FYI, I would have called the two flavors of reading something like "read static" (your default), and "read dynamic" (where I implement the code to compute the result). This is similar to how you can implement accessors in languages like C#, Java, or Scala. They can be just values, or you can write code to dynamically compute the value.

RE: Reading a subset of data on a BLE server

Carles — Thu, 26 Sep 2013 06:21:17 GMT

In the meantime, is there a way to get an event when the server gets a read from a client?

What you are looking for is called "Read Authorization".

The attached MSC should help you out.

To create a characteristic with read authorization set the following bit:

ble_gatts_attr_md_t :: rd_auth

when calling:

sd_ble_gatts_characteristic_add()

So, combining rd_auth on your side with usage of Read Long Characteristic Values (aka Read Blob) you could simply do this:

<- Read_Blob_Req(offset = 0) -> Read_Blob_Resp(first 20 bytes of data) <- Read_Blob_req(offset = 20) -> Read_Blob_Resp(bytes 20 to 40) ...

RE: Reading a subset of data on a BLE server

Jim — Wed, 25 Sep 2013 19:05:02 GMT

I'll take a look.

In the meantime, is there a way to get an event when the server gets a read from a client?

RE: Reading a subset of data on a BLE server

Ole Morten — Wed, 25 Sep 2013 16:11:09 GMT

I'd say that the "Bluetooth way" of doing this is using a Control Point characteristic to which the Client writes which data period or interval it's interested in, and then letting the Server send the actual data as either Notifications or Indications on a Data characteristic.

This scheme is implemented by for example the Glucose Profile and Service, so its profile document could be a useful place to start. The profile document is here, and the service document here.

RE: Reading a subset of data on a BLE server

Jim — Wed, 25 Sep 2013 13:12:04 GMT

I want this to support arbitrary lengths, so option 1 doesn't really scale well.

I'm not sure what rd_auth does for me.

I'm thinking what I'll do is have a separate characteristic that lets me set up the value for the next read, kind of like writing to a read pointer.

I would still like to get notified after the read happens, so I can increment the pointer and set up the next read. Is there a way to register for read notifications?

RE: Reading a subset of data on a BLE server

Carles — Wed, 25 Sep 2013 07:49:16 GMT

Hi there,

I want to allow a client to be able to read a specific portion of this data rather than having to transfer all 2048 bytes (which I can't anyway).

There is no "official" way to read buffers from a server that are longer than 512 bytes (the maximum length of a characteristic value).

You have several options to achieve that:

Create 4x characteristics (since each characteristic can only be 512 bytes long) and use VLOC_USER to make each of those point to a quarter of your historical data. Then the client can use read long operations on all those characteristics to obtain the data
Create a single characteristic, and mark it rd_auth = 1. Then every time your client asks for data you are free to provide the data you want with sd_ble_gatts_rw_auth_reply()

Carles