Unable to read long characteristics when MTU is 23 bytes using nRF Connect Android APP

[RRWC]

Information about my setup:

I'm working on a product using nRF52832 with SDK 17.0.2 and Softdevice s132 7.2.0. It is a custom board.

The default configuration (peripheral side - nRF52832) negotiate BLE connection parameters as follows:

• MTU: 230 Bytes
• Data Lenght: 234 Bytes (NRF_SDH_BLE_GAP_DATA_LENGTH)
• NRF_SDH_BLE_GAP_EVENT_LENGTH: 10 (1.25 ms units)
• PHY: 2 MB
• MIN_CONN_INTERVAL: 150 ms
• MAX_CONN_INTERVAL: 180 ms
• SLAVE_LATENCY: 5
• CONN_SUP_TIMEOUT: 4000 ms

The device (nRF52832) have a custom service with multiple characteristics. Some of these characteristics can have up to 512 bytes of data available to read. The Nordic nRF Connect Android APP is used for test purposes and the reading of characteristics is performed using the "down arrow" read button available in the APP next to all characteristics configured as "read enabled". A few recent smartphone models from different brands were used in tests, all with the same results.

Normal Behavior:

When the device connects to a smartphone, the parameter negotiation ends smoothly within the specified parameters. All readable characteristics in the custom service can be read with no problems. 

Problem situation:

Multiple tests are performed to confirm proper device operation in various use cases. One of the tests requires renegotiating some of the above parameters after the connection is stablished.

The problem starts when the MTU is changed to 23 (regardless of other parameters). The negotiation of the MTU itself finishes successfully. After that, only characteristics with few bytes of data can be read. If you try to read longer characteristics a GATT 133 error is reported in the nRF Connect side and the data is not received. The nRF52832 appears to believe the data has been sent and updates the data for new readings.

The connection is not lost after GATT 133 error, it remains stable and other characteristics can be read. If the characteristics are larger than a certain amount of bytes a new GATT 133 error is reported, otherwise the data is correctly received by nRF Connect.

Is there some configuration or something that could be preventing more than a few bytes of data from being read from a characteristic when the smartphone negotiates a 23 bytes MTU?

Is there any way (or any reading mode of BLE characteristics) to automatically confirm that data has been received by the smartphone on the nRF52832? Some of the data must be erased from the device after the smartphone reads it, it would be nice to have confirmation of data delivery in the lower layers of the BLE/SDK to avoid this kind of management in my code.

Thank you in advance for your help.

[Hung Bui]

Hi RRWC, 

Thanks for the detailed information. Could you please send us the sniffer trace files ? 

I did a quick test here and found a similar issue. So that if the MTU was 23 bytes at the initial phase and the phone doesn't request a change to larger one (247 in my case) the read worked fine. It's what I observed in my first reply where I give an example of 100 bytes read and with the NRF_SDH_BLE_GATT_MAX_MTU_SIZE set to 23. 

In your case you set NRF_SDH_BLE_GATT_MAX_MTU_SIZE to 230 I assume. And then in nRF Connect app you request an ATT MTU of 23. 

The problem of this is that the ATT_MTU request should only be sent once in a connection. In your case, the phone actually request it twice. First when connected (automatically request to 230 bytes)  and then you in the app request a 2nd one with 23 bytes.

This violate the Bluetooth Spec: 

In the code for NRF52 you can find the same requirement : 

You can't call sd_ble_gattc_exchange_mtu_request() twice in a connection. 

So from my point of view it's a wrong implementation in the phone's BLE stack that it allows att exchange to be requested twice. 
Could you describe your use case on why you want to change the ATT MTU back to 23 bytes ? 

Please be aware that ATT_MTU can only be exchanged once, but the Data length extension can be changed multiple times. If you want to limit the size of the on air packets you can change the data length instead of the ATT_MTU. 

Another note is that Data length usually = ATT_MTU + 4 . This is why you see 27 bytes data length when you request 23 byte ATT MTU. It's due to the 4 bytes overhead on link layer. 

[RRWC]

Hello Hung Bui,

I'm sending the sniffer trace as requested. This file contains pre-connection advertising and all data shown in the screenshots (same trace).

BLE_23MTU_read_fail.pcapng

Regarding the MTU exchange, I'm still a bit confused. The specification says that the client should only send the MTU request once per connection. However, it was the nRF52832 that actively requested the MTU change on the first change (to 230 Bytes). Wouldn't that allow the phone to request to change the MTU once during the connection even if the device already requested it once? Just for the record, actually in my app the phone is the Client (as usual the data is on the peripheral, the nRF52832). The use of the terms Client and Server in this case leaves room for ambiguous interpretations in my opinion. I would appreciate it if you confirm that the MTU should only be exchanged once regardless of the side starting the MTU update request, although this is just to better understand the specification. I don't intend to change it more than once in my application, I will explain more of my test case below.

Regarding my test case, the ideal condition is when the MTU is 230 bytes and Data length is 234 bytes. This is what my device will request. However, these values ​​also depend on what the phone and its BLE stack decide. What I really want to test is if data transfer, internal data update and overall device operation are OK in case of 23 byte MTU and 27 byte data length being selected by the Central. I have no need nor intention to explicitly change the MTU to 23 bytes, but I would like to check compatibility with phones selecting this MTU even when the peripheral configuration allows a higher MTU.

Extending a little bit this explanation, this is a final product test (not a prototype). We have more freedom and control over the nRF52832 side so we prefer to fix bugs in the firmware side even if they are caused by wrong implementation in the other devices stack to ensure wide compatibility. However, our tests use the firmware as close to the final version as possible (exactly the same for most tests). We want to test that the final firmware version will correctly handle the 23 byte MTU request from the master with the current configuration and not to change the configuration on the nRF52832 side to test and send a different configuration to the field. Also, if the phone is able to send this request once even after the device changed the MTU before we'll look for a way to keep things working even in that scenario, if possible.

Thank you in advance,

Ricardo.

[Hung Bui]

Hi Ricardo, 

You are right. The requirement is that MTU exchange is once per client. Meaning there could be up to 2 MTU exchanges, initialize by the client on each side.

However, there is another requirement from the spec: 

This is also reflected in our API: 

In this case, the phone replied to the nRF52 with Server RX 230 in the earlier exchange and then on the 2nd exchange it request with client RX = 23 which is violating the spec. 

From what I can see in the trace, the softdevice still operate normally even with this violation that it still reply with correct read response (fragmented and then re-assembled) : 

My understanding is that the phone had an issue interpret the response and gave GATT error. 

I understand your concern that if you have no control over the peer there could be a chance that this issue may rise and you want  to have a way to check if the peer have received the data correctly. As far as I know there isn't a way to have a confirmation of a read. You can have a confirmation when you do a write (write request or write with response) but not with a read. 

What you can do is either make a server on the phone and write data from the nRF52 to the server on the phone instead of a read. Or if you want to keep it as a read, you can have an extra characteristic on the nRF52 that the phone can write a receipt when it managed to read. It can be a hash of the data of the read for example.