Bluetooth - any known problems with Venu or Vivoactive 4?

Just noting this: forums.garmin.com/.../1070384

That's for a basic phone connection and it doesn't sound like CIQ BLE is involved.

When you're saying it doesn't connect, is it found in the scan?  Does it connect but you just can't get data, or doesn't it connect at all?  Where are you seeing the issue?

Tried one of my apps that connects to a BLE HRM and it's working.

update: Also tried one of my widgets that talks to a pi, and it's working too.

In cases like this, it could also involve the FW on the e-bike.

In cases like this, it may not hurt to have a way for a user to see some diagnostics (maybe by way of an app setting), so you can see how far it gets before failing.

Thanks jim_m_58, that's really useful

Good to know that you see it working with a pi.

One of the users is happy to try running a debug build, so I'll make one and get some more info about what is failing that way. (Using an app setting sounds a good idea!)

If it could involve the firmware on the e-bike that could be tricky. Note that for one user it works with a Vivo 3 music, but not a Vivo 4 or Venu (he has tried all 3 with the same e-bike).

Maybe have them try again after a reboot.  Hold the upper right button until the watch turns itself off and then back on.

Also, with BLE,is the bike connected (or potentially connected) to something else?  It may only handle 1 connection at a time.

I've been debugging this now (with the help of a friendly user!) - and it seems strange what is happening on the Venu. Following exactly the same code which runs and works on other watches (when they connect to the same e-bike):

• Register 3 BLE services (successful)
• Scan and connect/pair to 1 device (successful)
• Get one of the services from the device, in order to request a read - but getService returns null (so then nothing else works ...)

Ideas on how/why this could be are welcome

I've seen this in the past on real devices, and have seen it in the sim (I don't recall the last SDK I saw it on), but I have code to recover from something like this.  This is also something that can happen if you just happen to get out of ble range

When I queue something to do, I also set a timeout, and if that timeout expires, I reset the connection.  So if  service  is null, the timeout expires, and the connection resets.

So say I want to do a read..  I start the countdown to the time out, do the char.requestRead();. and then in the ble delegate in onCharacteristicRead(), I stop counter for the timeout.  in onTimer(), I do the reset if the countdown reaches zero. (onCharacteristicRead() was called) was seen within the timeout)

See CommQueue.mc the view and the ble delegate in my pi samples.

Ok thanks - so I should try something like this?

• Disconnect from the device
• Scan again to find the device
• Connect/pair to the device
• Try getting the service again in order to start a read

I don't think that will work though, as it happens the very first time I try and get a service from the device. I.e. straight after connecting. The user has never managed to progress to even starting a BLE read using his Venu as the service is never there, but it always works on his Vivo3. So restarting the app should have the same effect as disconnecting & repairing shouldn't it?

I'd have to look at my code, but I may not re-scan.  Just unpair and re-pair. (that's faster)

When I added the code, it definitely worked, as the first time the service could be null, but not the second time.  This sounds exactly like what I was seeing without the timeout.

I also use the timeout while pairing, so not just for read/writes/notifies.

Cool, thanks Gives me some things to try now!

With something like makeWebRequest, there's a timeout, but your app isn't involved.  You just get an error in your callback.

With BLE, you have to do the timeout yourself.  Consider the case where everything is running fine, but you walk away from the device you are connected to.  You want to handle that too.