nRF52832 Write Command on Nordic Uart Service

[hmolesworth]

The Nordic Uart Service example in SDK14.2 with SoftDevice 5.1.0 appears to use Write Request judging by the timing which limits transmission to about 30mSecs per packet with 7.5 mSec connection interval. I am trying to change from Write Request to Write Command thus:

// "Write Command" is a write without acknowledgement and "Write Request" is write with acknowledgement.
// The ATT will automatically send ack when you transmit write request from the central device. Write
// Command on the client side should generate BLE_GATTS_EVT_WRITE(WRITE_CMD, data) event on the server

I find the following definitions, but am not finding where they are actually used:

/** @defgroup BLE_GATTS_OPS GATT Server Operations
 * @{ */
#define BLE_GATTS_OP_INVALID                0x00  /**< Invalid Operation. */
#define BLE_GATTS_OP_WRITE_REQ              0x01  /**< Write Request. */
#define BLE_GATTS_OP_WRITE_CMD              0x02  /**< Write Command. */
#define BLE_GATTS_OP_SIGN_WRITE_CMD         0x03  /**< Signed Write Command. */
#define BLE_GATTS_OP_PREP_WRITE_REQ         0x04  /**< Prepare Write Request. */
#define BLE_GATTS_OP_EXEC_WRITE_REQ_CANCEL  0x05  /**< Execute Write Request: Cancel all prepared writes. */
#define BLE_GATTS_OP_EXEC_WRITE_REQ_NOW     0x06  /**< Execute Write Request: Immediately execute all prepared writes. */

/** @defgroup BLE_GATT_WRITE_OPS GATT Write operations
 * @{ */
#define BLE_GATT_OP_INVALID                0x00  /**< Invalid Operation. */
#define BLE_GATT_OP_WRITE_REQ              0x01  /**< Write Request. */
#define BLE_GATT_OP_WRITE_CMD              0x02  /**< Write Command. */
#define BLE_GATT_OP_SIGN_WRITE_CMD         0x03  /**< Signed Write Command. */
#define BLE_GATT_OP_PREP_WRITE_REQ         0x04  /**< Prepare Write Request. */
#define BLE_GATT_OP_EXEC_WRITE_REQ         0x05  /**< Execute Write Request. */

I have the Throughput demo, but am not interpreting how to use that in the case of the Uart example. For now we wish to stay with the Uart service, although if we must change we will; any pointers would be most appreciated.

[MartinBL]

Hi,

I think there must be a misunderstanding here.

The NUS central example uses write commands. It happens in the function called ble_nus_c_string_send() in ble_nus_c.c. There you can see that the write parameter structure (write_params) is configured to use BLE_GATT_OP_WRITE_CMD. 

The NUS peripheral example on the other hand, uses notifications. It is done with the function sd_ble_gatts_hvx() and happens in the function ble_nus_string_send() at the bottom of the file ble_nus.c.

If you struggle with throughput you should look at how your BLE stack is configured. Make sure to:

1. Increase your MTU length to lower overhead on the ATT layer.
2. Use Data Length extension to lower overhead on the Link Layer (long MTUs aren't worth much without enabling DLE). 
3. To avoid the overhead caused by splitting the data up into multiple connection events it can also be and idea to increase the connection interval. This might be counter intuitive, but it allows the devices to transmit undisturbed for a longer period of time without having to "closing" and "reopening" the connection windows. 

If you are using Keil you can configure this in the Configuration Wizard:

If I remember correctly, you will get the highest throughout in the throughput example if you configure the stack to use 400 ms connection intervals, 400 ms long event lengths, and 247 bytes long MTUs. 

Note though, that it doesn't matter how you configure your stack unless the peer's stack supports the same configuration. When establishing a link, the two devices will negotiate and decide on their "least common denominator". In other words, you can never expect all devices to be capable of the same speeds. Here are two relevant blog posts:

https://www.novelbits.io/bluetooth-5-speed-maximum-throughput/

https://punchthrough.com/blog/posts/maximizing-ble-throughput-on-ios-and-android

[hmolesworth]

Indeed I had misunderstood the use of notifications, many thanks for this clarification. I am testing further using nRF53832 parts at both ends and will post any findings later; this may help with a few other posts, methinks.

[MartinBL]

Happy to help. 

Let me know how it goes.

PS: It is holiday season here in Norway right now, and the response time might be slow. 

[hmolesworth]

Does Write Command guarantee message packet delivery in the same way as Write Request? You will see I mention you in a related post I am trying to assist with.