Communications transmit queue full

There is a limit to the number of transmissions the communications backend can handle at one time. I believe the maximum active transfers on all the current wearable devices is 3, but this value is configurable per device. If you are seeing this warning printed in the error log, you should also have received a onError() callback in your ConnectionListener.

There is a limit to the number of transmissions the communications backend can handle at one time. I believe the maximum active transfers on all the current wearable devices is 3, but this value is configurable per device. If you are seeing this warning printed in the error log, you should also have received a onError() callback in your ConnectionListener.

Brian, thank you very much for your reply. This is a very important issue for me. Please tell me more specifically: how is this limitation applied? Is it applied only on transmissions from the watch to the phone, vice-versa, or combined? Is it applied per application, or per device? Because, I have no idea what else is going on with the other, Garmin apps. And it seems that quite a lot is happening, as even the most simple transmission (of few bytes) takes several seconds.

I want to achieve smooth transmissions in both directions, and thus I need to know the proper way to do it, and all limitations that exist.

Thanks again!

I am pretty sure this limitation only applies to transmissions from the device to the phone. As long as you don't transmit() more than 3 messages before you get onComplete() responses, I don't think you should see this warning in the log. You should also be getting onError() responses if you do, so if you catch those, you should be able to intelligently retry your transmissions.

I saw your posts about the large transmission times on messages, and I don't have any good ideas on that right now. I know there is some latency that we cannot control in the BLE protocol, but I don't think messages should be as slow as you are describing. I recall some internal development was seeing transmission times in the 1-2 second range, and our analysis indicated that at least 75% of the delay was not something we had control over. The data speeds are very slow, so if you are sending anything of significant size, you will see delays due to that (less than 1KB/second I believe). Another issue I have seen is that on iOS, apps that are in the background are given extremely low BLE priority. If your app is in the foreground on iOS you should see much less transmission delay than when it is running in the background. I think this should be less of an issue on Android, but I am not sure of any details.

I am pretty sure this limitation only applies to transmissions from the device to the phone. As long as you don't transmit() more than 3 messages before you get onComplete() responses, I don't think you should see this warning in the log. You should also be getting onError() responses if you do, so if you catch those, you should be able to intelligently retry your transmissions.

I saw your posts about the large transmission times on messages, and I don't have any good ideas on that right now. I know there is some latency that we cannot control in the BLE protocol, but I don't think messages should be as slow as you are describing. I recall some internal development was seeing transmission times in the 1-2 second range, and our analysis indicated that at least 75% of the delay was not something we had control over. The data speeds are very slow, so if you are sending anything of significant size, you will see delays due to that (less than 1KB/second I believe). Another issue I have seen is that on iOS, apps that are in the background are given extremely low BLE priority. If your app is in the foreground on iOS you should see much less transmission delay than when it is running in the background. I think this should be less of an issue on Android, but I am not sure of any details.

Hello Brian, once again, thank you so much for looking into these issues.

This is my setup: I use an Android device - Nexus 5 with Android 6.0.1 and a Vivoactive with the following information in the Settings/System/About section:
Unit ID: 3902690949
v.3.40
Display Version: 2.10
GPS Version: 3.00
TSC Version: 2.00
Connect IQ: 1.2.1

I got this device a week ago through some guy on Ebay who said it was a new device, but arrived with a note that it is refurbished (by Garmin). I don't know if this can raise suspicion over the faultiness of the device itself.

The Garmin Connect version is 3.2.1.1.

The messages I transmit are really small, for example, the first one I transmit from the watch to the phone is one char only, and the response is less than 500 bytes. It takes several seconds (~7) for this process to complete. The Android companion app is indeed running as a service in the background, but this is not the cause of the delay, because I get the same results when I test with an app that runs as an Activity in the foreground.

This is really discouraging, as I tested my apps with the simulator during development and the results were drastically different, even with simulated BLE. So, while I expected the user experience on the Garmin device it self to be somewhat smooth, the reality is that I doubt the users will have any patience to wait for the app to make any progress...

Not to mention that I had my app completely block the watch, most likely due to the number of transmission attempts. I restored it to the default settings and now everything works again.

I created similar (or exactly the same) apps for other smart watches (more precisely: Pebble, Samsung Gear and various Sony Smart devices) that also use BLE to connect to the phone, and the transmission speeds (for much larger data chunks) there are extremely higher than on the Vivoactive, when testing with the same phone.


I hope to hear some word of advise, how to improve the performance of the data transmission. Many thanks!

We have someone looking into the message latency you've been seeing. We'll post back here once we know more. Thanks!

We have someone looking into the message latency you've been seeing. We'll post back here once we know more. Thanks!

Thank you Brandon!

Let me illustrate the latency issue. This is a video of my app. The watch app makes a connection with the phone, sends a message "L" (i.e. one char), and the phone app response consists of 9 + 9 strings (9 names and 9 phone numbers), which amounts to less than 500 bytes in my case. This is how fast that goes: https://www.youtube.com/watch?v=H4a6ZHMiNAc

Not very impressed, huh? Neither am I. I have more less the same app working on the Pebble Classic, and various Sony devices, and this simple communication is instantaneous. Here's a video demonstrating that, I'm using a Sony SmartWatch 1, several years ago, and the messages exchanged between the watch and the phone are more than 500 bytes: https://www.youtube.com/watch?v=ijh5EOTTR-w

It would be very significant for my apps, if this performance is improved on the Garmin!

We're certainly focused on doing everything possible to improve performance, but there are limitations to the BLE protocol.

(I've shifted this discussion out of your app thread as requested.)

Well, there certainly are BT 3 devices, but for example Sony's SmartWatch 3 and Pebble watches are BT 4, and they still don't have that kind of lag, so it seems the reason lies elsewhere. I understand that Garmin focuses on other aspects of these devices, but I'd say having a faster BT communication with the watch is not too much to ask from a device of this price range.

It is true that Pebble has BT 4.0 capabilities, and it is required to communicate with ANCS on iOS devices, but they do not use the BLE protocol for any other communications because the power savings is not significant to their device. I found this in their FAQ on reddit.

Q: WHY DOESN'T PEBBLE USE BLUETOOTH 4.0 LE ON ANDROID?

A: Currently, Pebble only uses a Bluetooth "classic" connection on Android, and does not utilize Pebble's Bluetooth 4.0 LE (aka Bluetooth Smart) capability. In short, this is because there is no need to; and there are not enough benefits that outweigh the drawbacks.

LE stands for Low Energy, and this name is a frequent cause of enduser confusion. Many people incorrectly assume it will improve the battery life of their phones or watches, but that is not truly the case, nor it's purpose. The Low Energy name, refers specifically to devices like miniature fitness trackers, glucose monitors, sleep tracking bands, etc; with very tiny batteries (often under 80 mAh), and thus the devices themselves are low energy. Such devices previously would have had hard wired data connections only, Bluetooth 4.0 LE is designed to allow wireless capabilities for them. In order to achieve such low energy usage, 4.0 LE is designed to operate at much lower throughput (only 0.27 Mbit/s, versus up to 2.1 Mbit/s for "classic" Bluetooth). In short, it's intentionally much slower.

On iOS 7+ Pebble utilizes Bluetooth 4.0 LE, but only because it has to in order to use ANCS (Apple's centralized notification system in iOS 7+) over Bluetooth. This is a requirement Apple created. Bluetooth 4.0 LE's slow speeds make it unsuitable for the larger file transfers Pebble needs, for doing firmware updates and pushing apps and faces to the watch. So iOS 7+ has two simultaneous Bluetooth connections to Pebble. One Bluetooth 4.0 LE connection used solely for receiving notifications via ANCS. The other is a Bluetooth "classic" connection, used for phone call notifications, communication with third party apps/faces, firmware updates, and pushing apps and faces to the watch.

It's safe to assume that if Android gets 4.0 LE support for Pebble, there would also be two simultaneous Bluetooth connections to Pebble, which is not ideal. Doubling the number of connections has potential to half the reliability, and double the chances for problems, conflicts, etc. This has been shown to be a frequent cause of issues for iOS 7+ users. So while notifications via ANCS greatly improved the Pebble experience on iOS 7+, it came at the price of making it more technically complicated and prone to failure and issues.

Bluetooth 4.0 LE also offers little benefit to battery usage of the phone or watch. Pebble is already extremely battery efficient without LE, and Pebble's battery (130 mAh), is more than double the size of the sort of devices LE was designed for. As an example, even if LE saved 15% battery usage on Pebble - if you already get 5 days (120 hours) out of a watch charge - than that's only another 18 hours of usage. As far as energy usage on your phone, Bluetooth "classic" is only about a 10% battery usage. If LE managed to reduce that by even half to 5% - the difference to a phone which lasts 10 hours (600 minutes) on a charge, is only 30 extra minutes. Neither scenario are likely to change charging habits of either device or be a noticeable benefit.


Q: IOS 7+: MY PEBBLE IS LISTED TWICE IN BLUETOOTH SETTINGS, IS IT OK TO REMOVE THE ONE THAT ISN'T LE (LOW ENERGY)?

A: No. The Pebble uses both connections. Pebble uses the regular bluetooth connection for installing apps and firmware updates, transmitting phone call info and music controls. The Bluetooth LE (Low Energy) connection is used specifically for Notifications.

Our wearable devices unfortunately would not be able to use the Bluetooth 2.1 protocol without a significant impact on battery life as they have a much lower baseline power draw.

I was unable to find any information on the Sony device, but I suspect they use a similar approach to Pebble since they only run for 2 days on a 420mAh battery, which would mean BT 2.1 would effect them even less than the Pebble.

We're certainly focused on doing everything possible to improve performance, but there are limitations to the BLE protocol.

(I've shifted this discussion out of your app thread as requested.)


It is true that Pebble has BT 4.0 capabilities, and it is required to communicate with ANCS on iOS devices, but they do not use the BLE protocol for any other communications because the power savings is not significant to their device. I found this in their FAQ on reddit.



Our wearable devices unfortunately would not be able to use the Bluetooth 2.1 protocol without a significant impact on battery life as they have a much lower baseline power draw.

I was unable to find any information on the Sony device, but I suspect they use a similar approach to Pebble since they only run for 2 days on a 420mAh battery, which would mean BT 2.1 would effect them even less than the Pebble.

Hi Brian,

thanks for transferring the thread! I think this is a better place to discuss such issues, and that's why it's first here that I posted my video demo.

Here's the SmartWatch 3 specs: http://www.sonymobile.com/global-en/products/smartwear/smartwatch-3-swr50/specifications/#tabs it says BT 4.0. To be honest, I still haven't made any apps for that particular watch, so I don't know exactly how fast the BT transfer is, but the apps that already exist seem to make the connection with the phone instantaneously.

I guess the thing to try to look for is what protocol they actually use for transferring, but I was unable to find anything. 4.0 hardware is the standard and is required for ANCS, but the older BT 2.1 protocol can still be used on newer hardware. The Pebble has Bluetooth 4.0 hardware, but they use the 2.1 protocol for everything except ANCS because it is faster and they do not feel the increased power draw is significant to their platform. Given the power profile of the Sony device, I would guess they are doing the same since they would not gain any noticeable advantages from using the BLE profile to transfer data.

I guess the thing to try to look for is what protocol they actually use for transferring, but I was unable to find anything. 4.0 hardware is the standard and is required for ANCS, but the older BT 2.1 protocol can still be used on newer hardware. The Pebble has Bluetooth 4.0 hardware, but they use the 2.1 protocol for everything except ANCS because it is faster and they do not feel the increased power draw is significant to their platform. Given the power profile of the Sony device, I would guess they are doing the same since they would not gain any noticeable advantages from using the BLE profile to transfer data.

Well, ok, if you say that this is how Garmin devices should perform, then I have nothing to add.