This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Large “virtual” read only characteristic?

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?

Parents
  • 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.

  • 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!

Reply
  • 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!

Children
No Data
Related