BLE Long write

[darren]

My Setup: Nordic is the Server, Android is the client.

I have read many, many forum posts about doing long reads/writes. Virtually everyone says you cannot do long writes. Instead you have to do a sequence of 20 byte writes.
devzone.nordicsemi.com/.../

I've also looked into Android API, and found that they do long read under the hood but do not support long write. I can only send 20 byte at a time. This is just what the forum posts have said.

HOWEVER, what I don't understand is how Noric Master Control Panel successfully executes long write. I can load up a 50 byte message and pass it over the Android App version of MCP. Is there something utilized in the MCP that I have missed, or cannot get access to in Android?

I cannot believe there is no way to write large streams of data from a phone to a BLE chip. It must be that I've missed something.

Thanks for your help!

[Ulrich Myhre]

Hi Darren,

There is a feature in BLE that goes by names like "long write", "queued writes" and "prepared writes". This feature lets you write multiple 20-byte chunks of data simultaneously, even across multiple characteristics. It works by sending multiple "Prepare Write Requests" (which have their full data echoed back in the "Prepare Write Response") followed by a final "Execute Write Request" that includes a flag saying "Write now" or "Cancel". I guess this is what the MCP is doing.

You should have the same functionality in Android by using beginReliableWrite() followed by a number of writeCharacteristic() calls and finalized with executeReliableWrite().

[Ulrich Myhre]

If this is for throughput purposes, I'm afraid long writes will not be very useful to you. You have to wait for a response to each Prepare Write Request before you can send the next one, often limiting you to 1 packet per connection interval. Your initial question was how the MCP might be doing this, and long writes is one way it might be.

If you want better throughput, you can gain a tiny bit by using long MTUs (currently not supported in our SoftDevices) where the header is only included in the first PDU, giving you a few extra bytes of data for every packet thereafter. The intention of reliable writes is to queue up some data by sending it, then write all of it atomically by saying "Execute" (or cancel, discarding all the data you sent). This allows you to e.g. update a long text field without having it in a corrupted state at any point, or write to all CCCDs simultaneously.