Large “virtual” read only characteristic?

RE: Large “virtual” read only characteristic?

Hung Bui — Fri, 04 Sep 2015 08:56:44 GMT

Hi machine,

Please aware that the characteristic with bigger value size than 20 bytes, when transmitting via long read or long write will still be split into chunks of 18 bytes payload and send over the link. The largest payload size on link layer packet is still 23 bytes (5 bytes for opcode, handle, and offset)

It's just the softdevice do the pay load split processing for the application. But only long write and long read support this, not notification/indication.

I don't really understand your need of having sd_ble_gatts_rw_authorize_reply() command that don't update the value of the characteristic. If you want to have a "virtual" characteristic ( that has the size of more than 20 bytes for example) why do you need to worry if the data is updated into the value of the real characteristic on the server ?

RE: Large “virtual” read only characteristic?

machine — Thu, 03 Sep 2015 18:10:18 GMT

I found that as of SDK 8.0, a "virtual characteristic" is not supported.

Instead, the characteristic MUST be backed in full by stack or user memory. In cases where the value is stored offline or calculated on the fly, it MUST be copied to the characteristic's value memory. It can NOT simply be returned via the BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST reply.

If the characteristic is larger than the max allowed (about 500 bytes), it can be "streamed" to the client via notifications or indications.

A large characteristic can also be accessed in chunks of about 500 bytes at a time using one characteristic to specify the chunk index and another to represent the 500 byte data chunk. For example, if chunk index is 0 then the data chunk represents the first 500 or so bytes of a larger dataset; if chunk index is set 1 then the data chunk represents bytes 500-999, etc.

It would be nice if a future SDK release could allow the BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST read reply to return the data on the fly instead of requiring the data to be stored.

RE: Large “virtual” read only characteristic?

machine — Wed, 26 Aug 2015 20:24:38 GMT

Unfortunately, it seems that my original goal of implementing a "virtual" characteristic using the read authorization event is not possible with the Nordic S110 softdevice. The characteristic must be fully backed by real memory (in either the user space or softdevice space).

However, I am considering your advise of using a notification or indication to stream the data to the client on demand.

Meanwhile I will forget about sending only 22 bytes and use a maximum sized 512 byte characteristic with a "bank switching" scheme to read blocks of data at a time. It is wasteful since only 22 bytes will be sent at a time but at least it will work. Once that is working I will look into using notifications/indications to send over all of the data as an option if it proves to have more throughout.

Thanks!

RE: Large “virtual” read only characteristic?

Hung Bui — Wed, 26 Aug 2015 14:11:10 GMT

Hi Machine,

I don't really get it with this part "to set the value of the data chunk dynamically but it always copies the new data into the characteristic's value at the offset and length specified in the reply. This method requires the characteristic's value buffer to be large enough to hold the entire external dataset."

You meant you tried to write the entire data of the large "virtual" characteristic with one write request with authorization ?

Why don't you split that single write into multiple write requests, with 20 bytes chunk each. (maximum payload for a write/notification/read is 20 bytes)

In the application you can then write each 20 bytes chunk into the external RAM.

The same when you want send large data from nRF51 to the central. You can use a small 20 bytes characteristic, and update and notify its value with the 20 bytes chunks from the external memory.

RE: Large “virtual” read only characteristic?

RK — Wed, 26 Aug 2015 14:10:16 GMT

If your characteristic value is in user memory then you don't need to use read auth, you just need to tell the stack how long it is and it will return it piecewise.

RE: Large “virtual” read only characteristic?

machine — Wed, 26 Aug 2015 13:55:28 GMT

This is exactly what I already tried but it did not work. My characteristic value is in user memory and I am using read authorization. The reply data gets ignored when update=0. When update=1 the characteristic value gets overwritten with the reply data at the specified offset/length. So I cannot simply send out 22 bytes without backing it with a full size characteristic value (that will get overwritten).

RE: Large “virtual” read only characteristic?

RK — Wed, 26 Aug 2015 05:37:33 GMT

Many ways.

Easiest one is to specify the data as being in user memory not on the stack, you can then point directly to your data and it will read it right out of the memory.

Alternately if you specify the characteristic as in user memory and use the RW authorize request, it will send the 22 bytes you give it out as the reply and won't try to copy it anywhere.

I also don't remember what the 'update' flag in the reply does if you don't set it, I think it quite possibly just sends the data out and doesn't try updating anything.