• Replies 10 replies
  • Subscribers 17 subscribers
  • Views 1291 views
  • Users 0 members are here
Options
Related

Issues with BLE connection

Fsallstrom
over 3 years ago

I am using BLE to fetch data from an Internet web service and have many users complaining about connectivity issues. I am experience the same issues on my Fenix 5, that the watch seems to be connected over BT to the mobile Phone and shows up as connected in the garmin Connect mobile app. I also check System.getDeviceSettings().phoneConnected in my app, and it is returning true

The makewebrequest returns various error messages, e.g.: BLE_ERROR, BLE_HOST_TIMEOUT, BLE_QUEUE_FULL. 

I can resolve the issue by manually disable and re-enable the phone connection from the setting menu on the watch, then usually the BLE connection gets re-established and things start working again. It seems like the BLE system is a bit unstable in general, and perhaps not designed for this use-case. But, more and more apps and data fields today rely on data from the Internet, so I think it would be a good idea to revise the BLE framework and see what improvements can be done. 

Meanwhile, I think a good quick-fix would be to disable and re-enable the phone connection from the app itself, the same way as i do manually from the settings menu, but not sure if that is possible and if so, which method to use. Has anyone tried it?

Also, is there a way to check status of the BLE connection before attempting a makewebreques? (Im already checking with getDeviceSettings().phoneConnected but it will return true even though the BLE connection is not working) 

Thank you in advance

/Fredrik 

  • over 3 years ago

    There are probably connect and are due to your app.  BLE_QUEUE_FULL is seen when you try to submit too many makeWebRequest calls without hearing back any responses.  This can be 3 requests or as few as one, based on Android or iOS.  The best way to deal with this is to single thread the requests/responses.

    1) make request 1

    2) get response 1, make request 2

    3) get response 2, make request 3

    and so on.

  • over 3 years ago in reply to jim_m_58

    Hi Jim, Yes I could definitely implement that logic to prevent the BLE buffer to overflow but the underlying issue is that the BLE connection does not work, it seems to end up in some weird state where it seems to be connected but cannot send any data. When this happens, I usually get a BLE_ERROR or BLE_HOST_TIMEOUT message first, and then after a while I get BLE_QUEUE_FULL. Therefore it will not solve the root problem.   

  • over 3 years ago in reply to Fsallstrom

    Try the single treading as I do that and don't see the issues you see on any device.

    Are you using the latest GCM, and is it all the same brand of phone?

  • over 3 years ago in reply to jim_m_58

    Thanks Jim, I will consider implementing something similar. I can see one issue though, especially since the data field is often used in areas with poor mobile coverage, then I cannot rely on always getting a response back for my web request. If that happens, It would never fire off another request. Have you thought of that scenario? 

  • over 3 years ago in reply to Fsallstrom

    You do get something back.  You get a non-200 status in the call back.  Poor cell coverage is probably what starts your errors occurring. 

  • over 3 years ago in reply to jim_m_58

    Another thing, if you're doing this in a background service, recall that will only run at most 30 seconds, and it may take longer than that to see a timeout error.

  • over 3 years ago in reply to jim_m_58

    Yes, I remember I had a conversation with you before on this topic. What happens if the BG process exits before I receive the response from the web request? does it exit to the "onBackgroundData" method with some sort of error code?

  • over 3 years ago in reply to Fsallstrom

    If 30 seconds has elapsed without doing the Background.exit(), the background service simply exits and onBackgroundData() is never called.

  • over 3 years ago in reply to jim_m_58

    okey, so if that happens I will not receive a response back and will not be able to reset the "request counter"?  

  • over 3 years ago in reply to Fsallstrom

    Without seeing your code, it could be you just don't want to use a request counter, and each time the background runs, only do one request.  So never more than one request every 5 minutes.  That's pretty much how I do all my background services, if they use makeWebRequest or I pair to  a device using BluetoothLowEnergy