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

BLE Long write

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!

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

Reply
  • 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().

Children
  • Thank you. I will go look into this. This could be a great help in speeding up the data transfer. Thanks!

  • I'm still working on this. Is there some way you can post example code for this? I can write the android side code, but I don't know how to set up the nordic to allow for the prepared writes. There is so much confusion about this on the internet I am just totally lost. I really need to rewrite my application because the data rate without long write is just unacceptable. It takes seconds to send tiny string messages. Please refer me to example source code to set up my nordic to allow for writing multiple 20-byte chunks.

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

  • Ulrich, Thank you for your response. Help me understand what sort of max throughput I can acheive. I saw this page and thought I might be able to get to a couple of kb/s. Is that not possible?

  • Write commands and notifications do not require any response, and can be sent pretty fast. The S110 SoftDevice supports up to 6 packets per connection interval, but might be limited by the central if the central has less. This gives a maximum throughput of 6 packets * 20 bytes every connection interval. The minimum connection interval is 7.5ms, but this is not supported in all centrals either. iOS can be negotiated down to 11-something ms with some tricks, and Android should support 7.5ms (but have fewer packets per interval). The theoretical maximum is 128kpbs (16kB/s). See some examples here: devzone.nordicsemi.com/.../

Related