0

I'm trying to create data transmission between a custom BLE peripheral and Android communication library implemented with RxAndroidBle (1.4.1). I have it working with the default MTU (23 bytes) so that Android transmits only 20 bytes at the time. The communication works with MTU of 23, but we'd really like faster communication.

Our device supports DLE and requests a larger MTU of 158 bytes at the start of the communication and gets it with practically all mobiles. That done, the device starts sending data up-to 155 bytes at the time. Because of this the device->mobile communication is reasonably fast and it works fine. However on the Android side the RxAndroidBle's getMtu() call always returns 23 (even if library and test application have been built with minsdk = 21, running on Android 7.1.1). I tried to add call to RxBleConnection.requestMtu(512) after establishing the connection, but that results no callbacks and the getMtu() still returns 23.

I tried it with just brutally calling setMaxBatchSize(155) on createNewLongWriteBuilder and seeing what happens. Result was faster communication without any issues! (I confirmed on device logs that we really were getting >20 bytes at the time) However, to avoid unpleasant surprises if a device doesn't support large MTU's I'd really like to have the library use an actual MTU value, not a "big guess".

So, What is the actual way of getting current MTU in RxAndroidBle? Is there a bug that prevents it from working or something?

PetriL
  • 1,211
  • 1
  • 7
  • 11
  • It seems that the `RxBleConnection.getMtu()` return the proper value only if the MTU was requested by the central (Android) or not changed at all. Looks like a bug in the library. – Dariusz Seweryn Oct 13 '17 at 15:18
  • Sure looks that way. I tried to decompile the RxAndroidBle and read the code and could not find anywhere code that would update RxBleConnectionImpl.currentMtu if the requestMtu has not been called. What surprised me was that the requestMtu(512) didn't help either. Maybe there was no change since the connection already had the max that the device can support (158)... – PetriL Oct 13 '17 at 15:45
  • Added for tracking: https://github.com/Polidea/RxAndroidBle/issues/293 – Dariusz Seweryn Oct 13 '17 at 16:11
  • Could you try out [the `1.4.2-SNAPSHOT`](https://github.com/Polidea/RxAndroidBle#snapshot) version of the library and check if it works for you? It should return correct value of the `MTU` – Dariusz Seweryn Oct 24 '17 at 12:37

1 Answers1

0

The behaviour you have described is actually a bug as of RxAndroidBle version 1.4.1. The MTU value retrieved by the RxBleConnection.getMtu() is updated only when the MTU negotiation is started by the central via RxBleConnection.requestMtu(int).

There is a release 1.4.2 which has this issue fixed so the MTU value is updated also when the peripheral starts the negotiation.

Dariusz Seweryn
  • 3,212
  • 2
  • 14
  • 21