Inconsistent transmission time between my dev kit and nRF connect PC app and Android app.

[william.ely]

I'm using nRF connect 2.5 on PC and the latest Android app on a Pixel phone. My firmware is based on SDK 15.1 and soft device 6.1.0. I am using nRF52840-DK boards.

My firmware uses notifications to transmit a block of test data that is about 30 kB in size when a certain characteristic is written to. This works fine when I use the nRF connect PC app but when I use the nRF connect app on my phone it takes much longer. Our phone app development team has reported that it is taking them almost a minute to receive the same block of test data. Is there something I can do to make sure that the data transfer is as fast as possible? Is there something that my phone app team can do?

This is the debug output when the process takes over 45 seconds:

<debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x1.
<debug> nrf_ble_gatt: Updating data length to 251 on connection 0x1.
connectedpp:

<debug> app: Sending PHY Update

<debug> nrf_ble_gatt: Data length updated to 123 on connection 0x1.
<debug> nrf_ble_gatt: max_rx_octets: 123
<debug> nrf_ble_gatt: max_tx_octets: 123
<debug> nrf_ble_gatt: max_rx_time: 1096
<debug> nrf_ble_gatt: max_tx_time: 1096
<debug> app: ATT MTU exchange completed. central 0xF7 peripheral 0xF7

<debug> nrf_ble_gatt: ATT MTU updated to 247 bytes on connection 0x1 (response).
<debug> app: Data len is set to 0xF7(247)

<debug> app: ATT MTU exchange completed. central 0xF7 peripheral 0xF7

<debug> app: PHY update rejected. PHY set to 1 Mbps.

<debug> app: PHY update rejected. PHY set to 1 Mbps.

<debug> app: Connection interval updated: 0x6, 0x6.

<debug> nrf_ble_gatt: Peer on connection 0x1 requested a data length of 123 bytes.
<debug> nrf_ble_gatt: Updating data length to 123 on connection 0x1.
<debug> nrf_ble_gatt: Data length updated to 123 on connection 0x1.
<debug> nrf_ble_gatt: max_rx_octets: 123
<debug> nrf_ble_gatt: max_tx_octets: 123
<debug> nrf_ble_gatt: max_rx_time: 1096
<debug> nrf_ble_gatt: max_tx_time: 1096
<debug> app: ATT MTU exchange completed. central 0xF7 peripheral 0xF7

<debug> app: Connection interval updated: 0x24, 0x24.

<debug> app: Connection interval updated: 0x18C, 0x18C.

This is the debug output when the process takes 4 seconds:

<debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x1.
<debug> nrf_ble_gatt: Updating data length to 251 on connection 0x1.
connectedpp:

<debug> app: Sending PHY Update

<debug> nrf_ble_gatt: Data length updated to 27 on connection 0x1.
<debug> nrf_ble_gatt: max_rx_octets: 27
<debug> nrf_ble_gatt: max_tx_octets: 27
<debug> nrf_ble_gatt: max_rx_time: 328
<debug> nrf_ble_gatt: max_tx_time: 328
<debug> app: ATT MTU exchange completed. central 0xF7 peripheral 0xF7

<debug> app: PHY update rejected. PHY set to 1 Mbps.

<debug> nrf_ble_gatt: ATT MTU updated to 247 bytes on connection 0x1 (response).
<debug> app: Data len is set to 0xF7(247)

<debug> app: ATT MTU exchange completed. central 0xF7 peripheral 0xF7

<debug> nrf_ble_gatt: Peer on connection 0x1 requested a data length of 251 bytes.
<debug> nrf_ble_gatt: Updating data length to 251 on connection 0x1.
<debug> nrf_ble_gatt: Data length updated to 251 on connection 0x1.
<debug> nrf_ble_gatt: max_rx_octets: 251
<debug> nrf_ble_gatt: max_tx_octets: 251
<debug> nrf_ble_gatt: max_rx_time: 2120
<debug> nrf_ble_gatt: max_tx_time: 2120
<debug> app: ATT MTU exchange completed. central 0xF7 peripheral 0xF7

<debug> app: Connection interval updated: 0x18, 0x18.

[awneil]

Take a look at the connection parameters that are being granted by the phone app ...

[william.ely]

So the phone app needs to request the same transmission parameters as the nRF connect PC app?

[awneil]

No. The Peripheral app requests what it would like; the Central decides what it will grant.

What the Central grants is (largely?) down to the OS - there doesn't seem to be much control available to the app, and the OS logic is not documented.

Sometimes, disconnecting and immediately reconnecting will give different results!

Results can & do differ from device to device.

This has been discussed many times before.

[william.ely]

It turns out that the reason for the long transmission time was a delay inserted between notifications. I had FREERTOS defined in my sdk_config.h file. Once I took that out the notification delay went away. I will try defining FREERTOS in the project settings like in the demo. i imagine there is a good reason why it was defined there:).