Android write speed is abysmally slow when working with CPro. (Android!!!)

I have been reading that Android has a very poor implementation of Bluetooth Low Energy with a myriad of issues in communicating with BTLE devices and I think I'm experiencing some of those.

I have written an application to use the Metawear CPro. I have compiled versions that work on Win32 and Android. The Windows version starts up and initialises the CPro very rapidly, with little delay between calls to the write_gatt_char routine and starts up the accelerometer (and other modules) just fine. However the Android version is substantially slower.

The time between calls to write_gatt_char during just the initialization of the CPro take between four (4) and five (5) seconds each to complete. With the twenty (20) odd modules that require initialization this can take over a minute and a half to complete. Then when I attempt to turn on the Accelerometer, Android terminates the application as unresponsive. I have tested this on an ASUS Nexus 7 - 2013 (with the Wi-Fi turned off) and a Samsung Galaxy Tab A6 with the same result.

I have tried using

mbl_mw_settings_set_connection_parameters(11.25, 11.25, 0, MAX_TIME_PER_RESPONSE); // I chose 11.25 as I hear this is the minimum speed allowed on Android 6.

to set a low latency time, but I am not sure if this information is stored in the device and sent to Android during connection or at the time of the command is issued, or it survives battery removal, firmware updates or even just reinitialization. Furthermore, as it is part of the settings module (#17 in the sequence) the change can't be made until after initialization which, as described above is slow to begin with. It's a bit of a chicken and the egg problem.

I was reading the adopted bluetooth characteristics and noted that the 0x2A04 is the BTLE service for Peripheral Preferred Connection Parameters which has a signature similar to mbl_mw_settings_set_connection_parameters and thought if this were added in the firmware it would allow me at least to set the preferred speed through this characteristic before attempting initialisation.

Futher, I was reading this page and noted under the section Latency Patch, they resolved the bulk of problems with slow communications on Android by sending a second L2CAP latency request packet (since Android apparently ignores the first) after connecting. As this is part of the BTLE protocol layer I thought perhaps this may help if implemented in the firmware (although I admit my knowledge of this level is extraordinarily limited and I may be talking out my ...)

Can you provide any thoughts or feedback?

Comments

  • I presume your Nexus 7 is running Android M?  We have two Nexus 7s (Android 5.0 and 4.4) and I've noticed that the Bluetooth radio is slow when the app is run in debug mode however they were never slow to the point of having to wait over a minute for initialization.  Apps do flow much smoother in release mode but not to the same extend as newer Android devices such as the Nexus 6 and 9.

    If you're using the latest firmware (v1.2.5), the default max connection interval is reduced to 100ms and the firmware did undergo some changes to support updating connection parameters live.

    Have you tried using the Android API instead of building an NDK project with the C++ library?
  • I have a nexus 7 running on M and have not seen these problems using the Android API.  Thinking that this is related to something with the C++ code.
  • Yes, I am using the C++ API. But my since this is happening at the BTLE interfacing layer which the API leaves to abstracted read_gatt/write_gatt calls I wouldn't expect the code base to have an impact on communications speed.

    No I haven't tried a native Android API since I'm trying for a single code base that compiles on desktop's and tablets and it would be impractical other than to experiment to try and adapt it.

    Does the Android version of Metawear/Metabase/Metahub use the Android natively or are they also cross platform as I notice that they seem to connect quickly. If they are native, what might be being done natively that may not be happening when using NDK?
  • All Android apps are written in Java with the Android API.
This discussion has been closed.