This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF mesh application reconnecting failed before node configuration

We using Android Phone (OPPO A53 Android 5.1) and some custom tablets (Android 9.0), to start add custom board as BLE mesh node. But sometimes the reconnection failed even after 3 retries, with error code like 133  or 8.

We would like to improve its success rate and now seek for clarifying: 1.why original Android mesh demo need try reconnection before configuration, it's a must operation for Android attributes cache pitfalls? 2.If we just wait for several seconds without disclosing BT connect ion,then trigger discover Services, would it be OK?

Something about mine issue in the following.

1.I'm using modified version App, and we don't change the GATT and proxy provisioning procedure

2.I had tested several android devices (Samsung Galaxy C5 or Pixel 3 and so on), mostly the whole provisioning succeed.

3.Our failure Android devices only have BT 4.2/4.1 supported, and our BT board is nearby.

4.We are uing latest demo App(updated at July 2021)

I' m looking forward to your response.

BRs.

Parents
  • Hello Weijun!

    1.why original Android mesh demo need try reconnection before configuration, it's a must operation

    Yes, as a matter of fact you first need to connect in order to run provisioning, and then to configure. This happens as one process in the app, but it is in fact two distinct processes according to the Bluetooth Mesh spec. It isn't related to android, and there is no way getting around that. 

    2.If we just wait for several seconds without disclosing BT connect ion,then trigger discover Services, would it be OK?

    I'll have to get back to you about this.

    When it comes to reconnection issues I think I need more info to be of any help. Could you tell me about this custom board? Have you tried it on other boards?

    Best regards,

    Elfving

  • 1.I tested on custom board-Espressif ESP32-S, which supports Wi-Fi and BT. Currently, it needs several retries for connection on some android device, maybe other 2.4GHZ signal interfere with it.
    2.And I tried my way:  without closing BT connection(no local GATT services list refresh), just waits at least 1s, then trigger discover Services. It would be successfully on android 9.0/11.0, but surely failed on android 4.4/5.1 with 129/133 error code showed during later GATT write request. Have you met something it before?

Reply
  • 1.I tested on custom board-Espressif ESP32-S, which supports Wi-Fi and BT. Currently, it needs several retries for connection on some android device, maybe other 2.4GHZ signal interfere with it.
    2.And I tried my way:  without closing BT connection(no local GATT services list refresh), just waits at least 1s, then trigger discover Services. It would be successfully on android 9.0/11.0, but surely failed on android 4.4/5.1 with 129/133 error code showed during later GATT write request. Have you met something it before?

Children
  • Error code 133 is very famous for being undocumented by Android itself. What we conclude is that this is usually a timeout error. This error happens very rarely from Android 8.0 onwards (it sometimes may be on Samsung devices and we almost never see this on Pixels). You could try to increase the retries or even increase the delay between each retry.

    As I mentioned earlier, you should disconnect and connect again and do a service discovery as stated in the spec.

    Best regards,

    Elfving

Related