Bluetooth over companion dropouts. (WHOOP 4.0 the culprit?)

Today I rode a workout with and experienced several dropouts. The weird thing is that once I entered the pairing screen everything said “disconnected” but given a second it reconnected instantly without me having to re-pair.

However exiting the pairing screen and starting to cycle again, the connectivity only seems to last a few seconds before dropping out again. Then re-entering the pairing screen, unpairing every device and then re-pair will allow me to cycle for another random amount of time before a new dropout occurs where i then have to repeat the abovementioned steps to make it all work again.

This happened somewhere between 5-10 times on a 1 hour 30m ride. All devices get’s dropped out, not just a single one.

I suspect that it has something to do with my new WHOOP 4.0 band, this is the first time I’ve used it as a HR monitor. So it might be the culprit for the dropouts.

In any case I’ve stored the log file and the fit file for debugging this issue. If anyone on support would reach out to me, i can send them.

I took a quick look at the log files myself, and there seems to be a recurring pattern of when it drops out. But i guess a technical person would be better to read and understand them better.

PS. Running latest companion and zwift as of 26-03-2022

I’ve been having the same kind of issues since Zwift was updated to 1.23.0 & the Companion app to 3.33.1 (several posts of mine on different threads). I use a Wahoo Tickr Fit, Apple TV and an Android BT bridge.

I no longer use the Companion app and pair directly.

1 Like

Pairing directly is not an option for me. So I’m reliant on companion app (or more so the bridge) to work flawlessly. I can however report that, atleast previously, when using Wahoo Tickr X, Wahoo Kickr Core and Wahoo cadence sensor generally works 100% of the time with the bridge.

So that’s the reason why i’m guessing it has something to do with my WHOOP band.

I’ve been thinking about reverse engineering the bridge API against Zwift, would be nice to have a type of “set top box” that would connect to ant+ devices and bluetooth devices and communicate that datastream to zwift. But I guess zwift doesn’t want this as this could increase the chance of cheating…

Zwift themselves on the forum describe the Companion App bridging function as a “tool of last resort” - one WiFi or BLE hiccup and it’s often game over.

I experienced this in past and gave up. If I can’t connect directly, I use the North Pole Engineering “CABLE” pod. (convert ANT+ to BLE) It’s rock solid and can aggregate multiple data sources into one BLE stream.

https://npe-inc.com/cableinfo/

I get that it’s another hardware purchase but, IMO, even though I don’t use it all the time, it’s a handy device to have around.

Cool product! Wouldn’t be against buying yet another product if it meant giving me proper connectivity. Sadly I don’t think this is it. The reason I can’t connect directly is because WINE doesn’t support ANT or Bluetooth (running in Linux). And in any case I don’t think it really should matter much if you connect directly to the application or if a middle-ware is used (the only real difference is the signal latency). Bluetooth hiccups and such should be just as much prevalent for a direct connection as with a bridge.

And really, we shouldn’t have hiccups at all. It should just work no? I can understand poor signal, but not like this were a connection is simply dropped and the fix is to re-pair everything, I mean if I can fix it manually in 2 seconds, then it should be something the computer device could do as well.

You buried the lede by not mentioning that in your first post. Linux adds yet another layer of complexity.

This is where I tap out and let someone else offer advice - I gave up on running Zwift (and a lot of other stuff) under Linux due to compatibility issues.

Full disclosure, I’m the creator of:

A project that aims to make it dead simple to run Zwift on Linux. And opens up for the possibility to run multiple instances of Zwift on a single machine.

Hi @Kim_Eik

You might already be aware, but just for visibility you’ll find all of the common troubleshooting that Zwift has for ZC BLE bridge connection dropouts can be found in this article.

If you’re thorough and go through all the steps listed in the article, there’s a chance it might resolve your issue.

In my experience, the ZC BLE bridge works well for most and perhaps not so well for others. I’ve seen issues where complex WiFi networks (e.g. mesh networks) and networks with elevated firewall security settings create problems with maintaining a stable ZC BLE bridge.

I’ve also seen it before where sometimes just restarting your router more often clears out any bugs or loops in the operation of your network equipment that are otherwise contributing to issues with the ZC BLE bridge.

And that’s just the potential issues on the WiFi side, there’s still the matter of wireless signal interference (more on that in this article), which can happen even if your devices pair to Zwift using a native (built-in) BLE connection.

That being said, it doesn’t sound like the ZC BLE bridge connection dropouts have historically been a persistent issue for you, Kim, so perhaps there’s a simple solution if you go through the aforementioned suggestions.

Furthermore, it’s hard to say if the WHOOP 4.0 HRM is a contributing factor here, but I suppose you can test this theory by entirely removing that device from your environment. If so, do the ZC BLE Bridge connection dropouts persist? If not, does reintroducing the WHOOP 4.0 HRM to your setup allow you to consistently reproduce the issue?

I will try to test it out in the coming weeks :stuck_out_tongue_winking_eye:.

Cheers!

1 Like

My wife rode last night with my usual setup (Tickr, Kickr core and no Whoop 4.0 band). For about an hour, No dropouts at all. Which is what im also usually accustomed to.

Will try to run a few more tests with and without the whoop band and see if i can gather some statistics on dropouts with and without the band.