BLE Throughput and DFU

[David Ormand]

Our nRF52832 software detects the arrival of characteristics via writes from the Central and reformats the contents and sends them out in a UART message.

I've built an Android app to write characteristics (in this case, one 9-byte and twelve 8-byte characteristics) as fast as possible.  Following the model in the Nordic nRF Toolbox HTS project (available from Github), I have the Bluetooth stuff in an Android Service, and the specific transaction performed in an Android Activity:

Activity: Request a send of a characteristic.

Service: Wait until the Bluetooth subsystem says it was successful (callback from writeCharacteristic()).

Service: Send an Intent to the controlling activity.

Activity: Upon arrival of the Intent, request a send of the next characteristic.

I monitor the serial line with a scope.  I see the messages emerge at about 80 millisecond intervals.

This seems excessive.  I gather the Central device (Android BLE subsystem) controls the Connection Interval, but I see that the minimum for BLE is 7.5ms.  I was expecting the inter-message gap to be more in the 10-20ms range.

We note the DFU seems to ship a lot of data very fast over a BLE link.  Is DFU doing something different than above?

[David Ormand]

Update:

1. The Android would spontaneously disconnect from the nRF52 after several seconds, with a report of "onClientConnectionState() - status=59", which apparently is HCI_ERR_UNACCEPT_CONN_INTERVAL.  I left the MIN_CONN_INTERVAL at 6 (7.5ms) and moved MAX_CONN_INTERVAL to 20ms.  No more spontaneous disconnects.  No effect on characteristic arrival times.

2. I added Optional WRITE_WITHOUT_RESPONSE to the characteristics of concern.  Now the arrival time dropped to 20ms.  That's better than the 80 - 150ms I was seeing before.  Should I expect better from Android?

3. Since the 20ms in both #1 and #2 was suspicious, I attempted to reduce MAX_CONN_INTERVAL.  The arrival time went back up to 80.  Apparently, 20ms is as low as Android is willing to negotiate.

I would _still_ like to know how DFU moves so much data so fast.

[bjorn-spockeli]

Most smartphones/tablets use the 2.4GHz spectrum for both WiFi and Bluetooth, so even though the BLE specification states that the minimum allowed connection interval is 7.5ms, most smartphones/tablets will not allow you to use lower than 15-20ms in order to maintain coexistence with WiFi. So a connection interval of 20ms sounds very reasonable and I doubt you will be able to go lower. THat said, some of the newer smartphones might have improved BLE/Wifi Combo chips that allow you to use the lowest  

Hence you will see variation across different smartphones/tablets when comparing the throughput of the DFU or any other write operation to a BLE characteristic.

The main contributor to the high throughput of the DFU service is the increased ATT MTU size. So even tough it is by default set to 23, the central may negotiate a higher ATT MTU size, which significantly increases the throughput.

We have a separate section in the S132 v6.0.0 Specification which states the throughput for the various combinations of event lengths, ATT MTU size, Connection interval etc. Here is the link to the section on the Nordic Infocenter.