Sending large amounts of data over BLE

[Anonymous]

If I'm, not mistaken a BLE characteristic can only be 20 bytes long

   

Is there a way to transfer more data to the client  from a periferal? I'm not talking abount multi megabyte , but what about something like 1-2 K?

   

Is it possible ? If so, are there any samples available how to do that in PSoC BLE?

   

Thanks

   

Andy

[Anonymous]

The BLE characteristic is limited to 20 bytes in size. The Cypress apis have made reference to "extended" or "long" reads and writes, but I haven't looked at what they do and can't promise any luck on that avenue.

   

Looking online, it seems that some people implement a service containing multiple characteristics, with each characteristic holding 20 bytes of the total payload that they are wanting to send. In that way, you can essentially break up your 1-2 KB load into 50-100 20-byte chunks and send them over the radio. It would also allow you to easily request 20-byte parts of the data you are sending, rather the requesting to restart the entire transaction.

[Anonymous]

It appears that day 24 project  (called Throughput) does what I need. It sets up a characteristic with a notification,  negotiates the MTU and sends chunks of data MTU-3 size. There is also a sample how to do this using  L2CAP but I have not looked into it yet.

[Anonymous · Accepted solution]

Here is an example project/thread containing information on using the Long Characteristic Attributes; I imagine this is what you are trying to implement 🙂

   

http://www.cypress.com/forum/psoc-4-ble/write-long-characteristic-value

[Anonymous]

The data written to the characteristic in the project mentioned in the thread is 20 bytes long. I need about 2-3 k

   

Looks like day 24 is what I need. There the data size is limited by MTU-3

   

Thank you for  help
 

[Anonymous]

It sounds like you're on the right track. From a high level, whether you use L2CAP, GATT long write operations, multiple characteristics, extended MTUs, or just the standard MTU with a single characteristic, the basic procedure is to split up your data into small chunks and send each chunk in order until all data is delivered.

   

This is most simply done with a single characteristic that supports "write" and/or "notify" operations (depending on which directions the data needs to go). You can wrap the transmitted data in some extra bytes to indicate to the receiving end how much data to expect, and/or add a second characteristic for status/control transfers if necessary.

[Anonymous]

Thank you for feedback. Between L2CAP and extended MTU, as implemented in day 24 Throughput project which one yields better performance?

[Anonymous]

Another question.

   

I'm contemplating whether I should use flash to store my data or just keep it in a global array.

   

By trial and error I determined that on my CYBLE-022001-0 the global memory space is limited to about 5 K and the heap is < 1K

   

I'd appreciate some feedback on which approach to use

   

How about, if > 2K of data is required - use flash, otherwise use a 2K global array? ( At this time I don't know how much data is actually needed, so I'm guessing a bit.)

   

Thanks

   

Andy

[Anonymous]

As far as L2CAP versus MTU, my guess is that they have similar performance, but I don't know one way or the other. Whichever is lower level in the stack is "probably" higher performance when used, but with proper optimization and functionality, they should end up the same 🙂

   

The flash takes some time to store data on it, so it will have a write-time that may be a limiting factor. Looking at my CYBLE-022001-00 chip, it only has about 16kB Ram,but 128kB flash, and 512 bytes of SFlash. In my project I have almost no room for RAM due to usage, with about 2/3s of it being the BLE stack. Depending on your application 🙂 using the flash will allow holding more data, but will take time, and will only work for so many cycles before the flash burns out (100k iirc). Basically, if you absolutely need more space for data you can pump it into the flash, but I would personally try to stick with only RAM usage.

[Anonymous]

Appreciate your feedback!