• State Verified Answer
  • Replies 2 replies
  • Subscribers 73 subscribers
  • Views 1072 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 200198
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

MAX MTU NRF51

Chocol8

Hello,

I am writing this question in reference to this question. I was asked to be more specific about my question by my colegues. I do understand that this is a duplicate unfortunately I was asked to get a specific confirmation from Nordic SC. The question is: is there any way to send more than 23 bytes size (20 bytes for user use) packet of BLE from NRF51 series SoC while using one of Nordic semiconductors softdevice (stack)?

Best regards

  • +1

    Hi,

     

    Yes, there is a way to, from the application point-of-view, send more than MTU_SIZE amount of bytes in one go. The functionality is named "Queued write", which is also commonly named "Long write".

    This is normally not a function that you want to use, especially if high bandwidth is crucial in your application. Here's the explanation of this feature from the Core v4.2 specification:

    The purpose of queued writes is to queue up writes of values of multiple attributes in a first-in first-out queue and then execute the write on all of them in a single atomic operation.

     

    This function is aimed towards altering several attributes in a "big bang" update, like disabling/enabling all notifications in an application. Think synchronous motor applications, where you can get a signal to turn off all motors with the same event instead of waiting for several events and handling this start/stop in the application state machine.

     

    A queued write operation on-air consists of two commands:

    * prepare write

    * execute write

     

    The central will do a given number of "prepare write" command over-air, and finally "execute write".

    Underneath the hood, this has more overhead compared to manually segmenting your buffer into 20-byte chunks and sending them like a normal write command.

    Each "prepare write" will consist of a header with opcode/handle/value offset, which reduces your overall throughput.

    If you use this function to send 200 bytes to one characteristic, this means that your current consumption will be higher compared to using normal write, and you will also have to calculate the total length based on the opcode/handle/value offset.

    All-in-all: Not recommended unless you use the feature as intended, which is updating several characteristics in one operation.

    Best regards,

    Håkon

Related
Terms of service