Maximal BLE Throughput Between nRF52840 DK and nRF Connect

Hi everyone,

I've been trying to figure out what is the maximal BLE throughput between nRF52840 DK and nRF Connect (on iOS).

Using "ATT_MTU Throughput Example" between two separate nRF52840 DK boards I could get more than 1MB/s, but when switching to the app (as central) I could only get about 35KB/s with this example: 7534.nrf5_sdk_17.0.2 - ble_app_uart_throughput.zip

 

Is it possible the get around 1MB/s between the app and the board? If yes, I would appreciate some guidance.

Thank you,

Dekel

  • Hello,

    Which phone are you using as the central in your test?
    You will need to make sure that the phone both supports and allows the connection parameters that your peripheral device has set as its preference, in order to achieve the same throughput.
    When using an nRF DK with the throughput example as the central device it is programmed to accept any connection parameters update requests from the peripheral, while a phone typically might not.
    This might either be an issue with the hardware of the phone you are using (old chipset that does not support certain connection parameters), or the OS itself which may restrict the nRF Connect applications access to the BLE adapter in the phone. This could typically be the case if the OS prioritizes lower power consumption rather than high throughput connection.
    Just in case, I would also like to mention that it is the central device that determines which connection parameters that actually will be used - the peripheral may only express its preferred parameters and send connection update requests to the central, which the central may decline.

    Could you test this with another phone to see if you achieve the exact same throughput then? 
    Could you also read out the connection parameters used for the connection with the phone? I would suspect that these turn out to be different from what you have set as the preferred connection parameters in the peripheral device. I suspect that this might be a limitation imposed by the OS or phone Hardware.

    Best regards,
    Karl

  • Hi Karl,

    thank you for your answer.

    I've also tried the above example with an Android device, which resulted in ~140KB/s (better than iOS, but still insufficient for my project).

    I'm not sure where I can see the connection parameters in the phone.

    Thanks,

    Dekel

  • Hello Dekel,

    Dekel said:
    thank you for your answer.

    No problem at all, I am happy to help!

    Dekel said:
    I've also tried the above example with an Android device, which resulted in ~140KB/s (better than iOS, but still insufficient for my project).

    This strengthens my earlier suspicion. Which iOS device and version are you working with, and what is its valid connection parameter ranges?

    Dekel said:
    I'm not sure where I can see the connection parameters in the phone.

    You could click the three-dot-dropdown menu in the application while in a connection, and select 'show log'. It will detail the connection parameters used at the start of the connection, as well as any connection parameter update requests.

    Best regards,
    Karl

  • I''m using iPhone 7 with iOS 14.8, but got similar results with a newer iPhone (not sure which generation).

    The only parameter I could get from the app is the MTU, which is different than the value set by the perpheral, as you said.

    Is there a way to bypass this issue?

    Thanks,

    Dekel

  • Hello,

    Dekel said:

    I''m using iPhone 7 with iOS 14.8, but got similar results with a newer iPhone (not sure which generation).

    The only parameter I could get from the app is the MTU, which is different than the value set by the perpheral, as you said.

    Which connection parameters are you trying to use, and which parameters are reported in the nRF Connect log?
    I was able to find this Apple document which details the guidelines for Accessory design, which outlines which parameter ranges are valid.

    Which parameters are you attempting to use?

    Best regards,
    Karl

Related