• State Not Answered
  • Replies 10 replies
  • Subscribers 68 subscribers
  • Views 4504 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 231194
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Using Android BLE library, getting into a connecting -> disconnecting (timeout) situation. nRF app seems to help.

13tett

Hi,

We're using the Android BLE library from Nordic. It really helped us handle a lot of the things we didn't want to think about handling on the bluetooth stack. (Thank you)

We've been experiencing some weird issues where the sensors will get into a connecting -> disconnecting issues, effectively timing out on connect.

The flow is : 

  • we scan for devices using the compact scanner (nordic)
  • we try to connect to one or more devices
  • the connection attempt would time out

The interesting thing we've found is that if we use nRF connect application (Android) on the same device (phone), and try to connect to the device it works. And surprisingly, right after connecting and disconnecting using nRF connect app, the devices will connect to the Android app (also using BLE library from Nordic) successfully as well. Are we missing to do anything properly. What are the steps on nRF connect app on connect and disconnect? We are thinking it might be that we got the driver or the sensor into a weird state and nRF connect app connection fixes it somehow?

Running out of ideas because we're tried many different things such as putting delays in possible places. Thanks!

Parents Reply Children
  • 0 in reply to tesc

    Thank you. I will test `shouldClearCacheWhenDisconnected()` and report back my findings.

    We are not using bonding or pairing. (We cannot recover from error state: see logs below)

    The one way we've found works by launching nRF connect app; from my observation we don't even need to hit "connect" on the nRF app. If our app is trying to connect to the device stuck in the follow log and we launch the nRF connect app to scan for devices - it will successfully connect to it. Could it be something with the way we're scanning? (We switched to compact scanner library from Nordic recently from our own scanner)

    Thanks for the help, looking forward to hearing your thoughts on what might be happening.

    For the logs : here's what I have

    2019-06-20 10:07:01.729 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : Connecting...
2019-06-20 10:07:01.731 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, LE 1M)
2019-06-20 10:07:11.766 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : Cancelling connection...
2019-06-20 10:07:11.769 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : gatt.disconnect()
2019-06-20 10:07:11.773 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : Disconnected
2019-06-20 10:07:11.782 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : gatt.close()
2019-06-20 10:07:11.784 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : wait(200)
2019-06-20 10:07:11.987 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : Connecting...
2019-06-20 10:07:11.995 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, LE 1M)
2019-06-20 10:07:21.782 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : Cancelling connection...
2019-06-20 10:07:21.789 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : gatt.disconnect()
2019-06-20 10:07:21.796 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : Disconnected
2019-06-20 10:07:21.810 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : gatt.close()
2019-06-20 10:07:21.813 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : wait(200)
2019-06-20 10:07:22.016 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : Connecting...
2019-06-20 10:07:22.023 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, LE 1M)
2019-06-20 10:07:31.806 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : Cancelling connection...
2019-06-20 10:07:31.813 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : gatt.disconnect()
2019-06-20 10:07:31.821 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : Disconnected
2019-06-20 10:07:31.836 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : gatt.close()
2019-06-20 10:07:31.840 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : wait(200)
2019-06-20 10:07:32.041 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : Connecting...
2019-06-20 10:07:32.045 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, LE 1M)
2019-06-20 10:07:41.834 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : Cancelling connection...
2019-06-20 10:07:41.837 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : gatt.disconnect()
2019-06-20 10:07:41.844 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : Disconnected
2019-06-20 10:07:41.859 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : gatt.close()
2019-06-20 10:07:41.861 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : wait(200)
2019-06-20 10:07:42.062 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : Connecting...
2019-06-20 10:07:42.066 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, LE 1M)
2019-06-20 10:07:51.856 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : Cancelling connection...
2019-06-20 10:07:51.862 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : gatt.disconnect()
2019-06-20 10:07:51.872 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : Disconnected
2019-06-20 10:07:51.883 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : gatt.close()
2019-06-20 10:07:51.886 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : wait(200)
2019-06-20 10:07:52.087 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : Connecting...
2019-06-20 10:07:52.092 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, LE 1M)
2019-06-20 10:08:01.882 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : Cancelling connection...
2019-06-20 10:08:01.888 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : gatt.disconnect()
2019-06-20 10:08:01.894 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : Disconnected
2019-06-20 10:08:01.906 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : gatt.close()
2019-06-20 10:08:01.910 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : wait(200)
2019-06-20 10:08:02.112 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : Connecting...
2019-06-20 10:08:02.118 31999-31999/ai.cloud I/Stream: StreamBleManager : Message : gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, LE 1M)

  • 0 in reply to tesc

    This issue still happens even when I override `shouldClearCacheWhenDisconnected()` to return true. 

    As I've mentioned before, it seems like I we just launch nRF connect (Android) app in the same android device - this timeout issue will go away. The important distinction is that we are not doing anything on the nRF app, we just launch it (no connect/disconnects).

    Any thoughts as to why? If nRF connect code was open source, I would look at what it does and test those out but seems like it's not. Slight smile

    Thanks!

  • 0 in reply to 13tett

    Hi,

    As you are getting "Cancelling connection..." in the log, that means it may be a library issue. It is printed in "internalDisconnect()" method which may be called in 3 cases:

    1. If your device does not support required services,

    2. If there was an error during connection,

    3. If a connection timeout occurred.

    I think, it 1. and 2. you would get something more in the log, which would indicate that you are setting a very short timeout for connection request, possibly in seconds instead of milliseconds.

    Could you put a breakpoint in "internalDisconnect()" method, where it does print this message, and check the stack trace to verify from where you end up there?

    Also, check if you are not setting too small timeout in "enqueue" method.

  • 0 in reply to Aleksander Nowakowski

    Thanks. The timeout is 10 seconds. It is indeed coming from the timeout, as I've mentioned in my previous messages. What is very puzzling to me is that by launching the nRF connect app all of these issues will start to flow perfectly. 

    Scenario : I have a few peripherals (all running the same firmware) advertising. Nordic's compact scanner found it on my app. Then we try to connect to the peripherals. They all get stuck in a timeout loop (times out -> next time I find out it's not connected - I try again in the app). I was using the nRF connect app to see if the peripherals were having advertising or other issues. I would launch the nRF connect app and they will all start connecting successfully. If someone could tell me what other things I maybe missing that nRF connect is doing i'd be very grateful. (Note that I didn't try to manually connect using nRF app).

    Thanks!

  • 0 in reply to 13tett

    nRF Connect doesn't do any magic. I guess it just scanned for the devices, and for some reason it helps. To be sure you may check other scanner app, for example nRF Toolbox -> UART profile (which scans without a filter), scan for few seconds and check your app. I have no idea why that would be helpful.

    Coming back to the timeouts, I didn't try the library with multiple devices connecting at the same time. I don't think they could impact one another on library level, as managers are separate, but perhaps Android has an issue, where allows only single connection at a time? But if the timeout in a library gets called, that indicates an issue in BLE Library. Could you debug why the timeout is being fired before 10 seconds?

Related