Cheap Android Tablets & Multiple BLE connections performance

[graphefruit]

Hello there,

some days ago I've recieved an bug ticket from a user with an Tablet: Lenovo Tab M8 (3rd Gen) 8" He told me that when he connects a bluetooth-scale, the receiving data are working flawless. When he connects a bluetooth-pressure, the receiving data are working flawless.

But when he connects the bluetooth scale, aswell as the bluetooth pressure device, the receiving data has a high latency lag. The data from the pressure sensor aswell as from the scale are reported within 100ms each. When both are connected, the data transmittings take like 1.5s to 2s for each value in worst case.

Another tablet e.g: Samsung Tab A 10.1 (2016) does not have any issues anymore.

Therefore for me its looking like somehow a bluetooth chip usage issues even when BT 5.0 is stated.

Do you know this issue, do you have ideas how to handle it maybe?

Thanks so far for your time! Have a great cup of coffee :) Lars

[peitschie]

Hi @graphefruit

As a step one, I'd suggest try calling https://github.com/don/cordova-plugin-ble-central?tab=readme-ov-file#requestconnectionpriority with "high", and see if this makes a difference. E.g.,

await ble.withPromises.requestConnectionPriority(device_id, "high");

[graphefruit]

Hey @peitschie, thanks for the fast replay (as always <3) I've made the change and sent to the user:

 ble.connect(
    deviceId,
    (data: PeripheralData) => {
      try  {

        setTimeout(() => {
          ble.requestConnectionPriority(deviceId, 'high', ()=> {
              this.uiToast.showInfoToast('We requested high priority sucessfully for scale');
            },
            ()=> {
              this.uiToast.showInfoToast('We could not request high priority for scale');
            });
        },500);

      }catch(ex) {

      }

I couldn't do the requestConnectionPriority before connecting, it just worked when connected. The user (and myself) got toast popup that the priority was successfully done for scale.

The feedback of the user was that it doesn't helped sadly.

[graphefruit]

Adding to this, this are the reported timestamps of the values of the scale.

15:42:25.929
15:42:26.780
15:42:28.239
15:42:28.527
15:42:29.231
15:42:30.171
15:42:30.906
15:42:31.579
15:42:32.580
15:42:33.766
15:42:34.322
15:42:34.883
15:42:36.158
15:42:36.716
15:42:37.140
15:42:38.122
15:42:38.763
15:42:39.221
15:42:39.762
15:42:40.727
15:42:41.006
15:42:41.713
15:42:42.501

There are realy huge jumps.

[peitschie]

Hrm!

Are you able to get any information from the Bluetooth device about it's connection parameters (connection intervals, slave latency, etc)?

The other thing I'd suggest is use nrf Connect to try connecting, and look at the debug logs from there to see if there's any connection interval info we can see.

There's very little that plugin does here that might contribute to latency, which makes me wonder if what you are seeing is a performance problem with the tablet manufacturer's Bluetooth stack, or potentially even a limitation of the BLE radio the tablet uses (perhaps it's not able to handle the concurrent packets efficiently).

[graphefruit]

Thanks @peitschie, great idea! I've forwarded this idea to the user and waiting for response right now :)

But I also think its a total limitation of the BLE radio/stack.

The issue rather on my end is: People are having a tablet, using the Beanconqueror App and getting back to me because they have BLE-issues, and I actually can't give a good feedback like: you need a minimum requirement of X tablet