BLE Long write

RE: BLE Long write

Aleksander Nowakowski — Mon, 20 Jul 2015 12:30:26 GMT

Some chart: infocenter.nordicsemi.com/index.jsp

RE: BLE Long write

Aleksander Nowakowski — Mon, 20 Jul 2015 12:27:58 GMT

In the nRF Master Control Panel you may change the write type, if a characteristic allows for WRITE_NO_RESPONSE or WRITE_REQUEST by clicking on the row with blue title "Write type". Write request must be used.

RE: BLE Long write

Aleksander Nowakowski — Mon, 20 Jul 2015 12:24:56 GMT

Hi, let me write an answer, not a comment. Reliable write is not the same as long write. On Android it is enough to call writeCharacteristic(...) with data longer than 20 bytes to make it work. It should work on nRF Master Control Panel. Android will take care of it automatically. The firmware must be prepared to received long write. I'm not sure but perhaps WRITE_RESPONSE is required for the char. I'm not an expert in the firmware side but it works with some apps and does not with others, so the difference must be there, I guess. The BLE_EVT_USER_MEM_REQUEST and BLE_EVT_USER_MEM_RELEASE is what you need to handle in the firmware. Here you'll find an example: github.com/.../ble_app_hrs---LongWrite

RE: BLE Long write

Aleksander Nowakowski — Mon, 20 Jul 2015 12:13:24 GMT

Hi, reliable write is not the same as long write. On Android it is enough to call writeCharacteristic(...) with data longer than 20 bytes to make it work. Android will take care of it automatically. The firmware must be prepared to received long write. I'm not sure but perhaps WRITE_RESPONSE is required for the char.

RE: BLE Long write

Ulrich Myhre — Thu, 04 Jun 2015 23:40:24 GMT

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

RE: BLE Long write

darren — Thu, 04 Jun 2015 14:30:38 GMT

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?

RE: BLE Long write

Ulrich Myhre — Wed, 03 Jun 2015 07:53:22 GMT

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.

RE: BLE Long write

darren — Wed, 03 Jun 2015 00:56:08 GMT

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.

RE: BLE Long write

darren — Mon, 20 Apr 2015 15:14:23 GMT

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

RE: BLE Long write

Ulrich Myhre — Sun, 19 Apr 2015 21:01:19 GMT

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

RE: BLE Long write

shibshab — Fri, 17 Apr 2015 05:51:38 GMT

Long write (called prepared write in the softdevice documentation) is supported up to 512 bytes in the nRF51 using s110 softdevice.

Note that the length of the characteristic needs to be correct for the client to perform the performed write action.

RE: BLE Long write

darren — Thu, 16 Apr 2015 21:47:52 GMT

I also had a custom service and characteristic i was communicated with. I don't know that it was a long write, but I entered 50 bytes in a row and saw them all go through. Its possible that was the prepareReliable and writeReliable with offsetting mentioned elsewhere. At this point i installed handshake characteristics, saying the buffer is cleared, write some more. that way its just a FSM sending and rx'ing. its less ideal, but a temporary work around.

RE: BLE Long write

Matthias — Thu, 16 Apr 2015 20:27:07 GMT

I decompiled the android app and I think it does not really support long write but could be wrong. Have you seen it working?

RE: BLE Long write

Matthias — Thu, 16 Apr 2015 20:25:08 GMT

That is true. But long write is a concept where the splitting and reassembly is handled by the api. Sorry, I converted this comment to an answer by mistake. It is a pitty there is no mobile Support for this site :(

RE: BLE Long write

shibshab — Thu, 16 Apr 2015 13:47:21 GMT

20 bytes is the limit of data packets in BLE 4.0 specification yes.

RE: BLE Long write

Matthias — Wed, 15 Apr 2015 18:26:47 GMT

Darren, I tried to test the MCP long write while sniffing with the PCA10000, but my custom device crashes with messages greater than 20 bytes. Could you tell me the service you have tested it with?

RE: BLE Long write

darren — Tue, 14 Apr 2015 16:52:58 GMT

To be fair, I only have access to the Android side, but i do know there is prepareReliableWrite() type methods in android: link. Perhaps this is what is going on. I will go see if I can implement something with this.

Why is there not a longer write to be able to do data dumps? Is this a design decision of BLE?

RE: BLE Long write

shibshab — Tue, 14 Apr 2015 13:44:19 GMT

Have you seen the link layer packets that the MCP app generates when it sends the 50 byte message?

Could it be that it divides the message into smaller packets without you noticing?