Large “virtual” read only characteristic?

[machine]

I would like to create a large “virtual” read only characteristic that does not fully exist in memory. I understand that large characteristics are transferred in chunks of about 22 bytes at a time and I would like to dynamically control the contents of that chunk.

For example: I have a large dataset that resides on an external storage device (i2c eeprom). I have a small 22 byte buffer exists in RAM (can be larger if needed). The client reads the large value in 22 byte chunks by specifying an offset. I want to copy 22 bytes from external storage into the RAM buffer. Then the S110 SD transfers that 22 byte chunk from RAM to the client. So the 22 byte RAM buffer acts as a “window” into the large external storage.

It seems pretty straight forward but I have not been able to get this to work.

I have tried using the BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST event 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. But the external dataset cannot fit into RAM (that's why it is external). I tried setting the ble_gatts_rw_authorize_reply_params_t “update” field to zero but that does not work.

I want to be able to set only the 22 bytes that are being transferred without having a RAM buffer that is the full size of the “virtual” dataset. Since only 22 bytes are actually used during each read operation only 22 bytes should be needed.

Is there a way to accomplish this task using the Nordic SDK?

[RK]

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.

[machine]

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).

[RK]

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.

[Hung Bui]

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.

[machine]

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!