Zwift fails to reconnect to Bluetooth HRM after any temporary dropout/disconnect event

Long post, so short summary first: I’ve been trying use a Bluetooth-based heartrate monitor (HRM) with Zwift but unable to get it to be reliable. With some experiments, I believe I’ve identified a fundamental issue with Zwift failing to reconnect to Bluetooth HRMs which makes them much less reliable than when connecting with ANT+.

Can someone at Zwift HQ confirm whether this is a known issue/limitation in the current code? It seems to me that reliability of BT-based connections would improve significantly if this was fixed.

Long story and details of experiments below.

I use a Kickr Bike so I have to pair with BT to get all features like steering. I wanted to eliminate ANT+ from my setup to reduce 2.4GHz interference and mis-pairing (Zwift likes to bind to the bike’s ANT+ instead of BT by default).

Pairing with the bike’s power meter, cadence sensor and controllable trainer all works great. Never any dropouts or issues. However, I’ve not been able to get a stable BT connection with my heartrate monitor.

The symptom is that it pairs fine initially and shows my HR correctly. If the signal drops out for any reason (e.g. I walk out of range to fill a water bottle) it never actually reconnects and the pairing UX alternates between showing stale HR data and “No Signal” every few seconds.

I have tried three different BT HRMs: Garmin HRM-Dual, HRM-Pro and Wahoo Tickr X. All with latest firmware. My PC is a desktop gaming PC with a TP-Link Archer TX50E PCI-Express card with an Intel AX200 chip and latest Intel BT drivers. The PC has recently been upgraded to Windows 11 (same problem was present with Windows 10). I have also tested with an ASUS USB-BT500 BT USB adapter.

ANT+ works fine. I can move out of range and when I get back in range it reconnects and continues to show HR just fine. The problem only happens with BT. The problem occurs even when I don’t have any other devices paired to the HRM.

I made a test using two other devices at my disposal, a Garmin Edge 1030 Plus cycling computer and a Garmin Fenix 6 watch. The watch has a wrist HR sensor and a neat function to broadcast HR to both ANT+ and BT receivers. When a BT device is paired, it shows the name of the paired device on the watch screen, effectively allowing me to monitor the health of the connection in real-time.

Here’s what I observe with different device connections:

Zwift on PC paired with watch: the initial pairing is successful and the name of the PC is displayed on the watch. If I move out of range, the name on the watch screen is cleared and Zwift displays “No Signal” on the pairing screen. Moving back into range, the watch screen stays blank (no connection) and Zwift cycles between showing stale HR data and “No Signal”.

Edge 1030 Plus paired with watch: the initial pairing is successful and “(BLE)Edge 1030 Plus” is displayed on the watch. If I move out of range, the name on the watch screen is cleared and Edge stops showing HR. Moving back into range, the Edge displays “Heart Rate Sensor Found”, “(BLE)Edge 1030 Plus” is again displayed on the watch and HR display on Edge resumes (as expected).

My conclusion is that Zwift fails to implement BT HRM reconnection correctly and is therefore very vulnerable to one short dropout causing HRM connection to fail completely.

Zwift rarely acknowledges any “issue” reported here (or elsewhere…)

I expect “WiFi interference” responses will soon pop up, however, my personal view is this is all totally Zwift/BLE related. I’ve never witnessed any BLE issue with my trainer - and plenty of with different HR monitors.

Mine drops out but automatically reconnects. Looks like a series of down spikes ever few minutes. Polar H10 but my H7 did the same.
Here’s my workaround. When I see this, I unclip one side of the sensor from the strap. Wait till the trend stops showing any HR data, reconnect and like magic it’s working and stays working

I think I have seen something similar to this. I have been seeing issues with BLE and a Wahoo Tickr Fit. It mainly happen when I start zwift. Unpairing and repair the HRM sensor seems to solve the issue. The problem is that I usually notice this in the middle of a group ride. If I repair I get dropped…

I am seeing some issues with Zwift and TICKR FIT. The pairing screen will show the HR rate sensor as connected but no signal. I can fix the issue by unpairing and then repairing from the Sensor pairing screen. Turning off and then back on the HR sensor does not fix the issue. This happens sometimes when I start zwift. It however does not happen every time.

Zwift 1.18.1 is running on MacOS 1015.7

Also was happening on Zwift 1.18.0

Dam I just got Garmin Dual HRM should have gone with wahoo one I guess. I’m having the same issues. I like using my phone as it’s quicker setup then my laptop. But looks like laptop and buying an ant+ Dongol is the solution. Thanks :pray:t3:

Interesting you are having issue with Tickr but not Kickr Bike. I am having the exact opposite with brand new Microsoft Surface Pro 8 and Windows 11, Kickr Bike but no issues with Tickr X. No issues with previous Surface Pro 5 and Windows 10 either.

When this occurs, I get Zwift pairing screen cycling between Kickr bike data and no signal. This all sounds rather similar but with Kickr Bike rather than Tickr having issues.

Everything works fine for a short distance, then mid ride connectivity just drops out.

Thankfully for time being using Zwift companion app as a bluetooth bridge seems to work ok.



Another one seeing significant changes to the way BLE heart rate connects. Very much points to Zwift changes rather home interference.

Following on from my previous post, these lines from the log file I think relate to the bluetooth connectivity issue, but not the ride above.

The reported caught exception is likely to be as a result of the Zwift app encountering an issue and not handling it. Only Zwift will know what it was trying to do at the time. What is clear to me, as a former software engineer, is that Zwift are in control of this situation, how it is handled in their app and what the next steps are in order to investigate this issue further. It is not a case of the user investigating bluetooth interference et al. type scenarios. This is one for Zwift to take ownership of and work out what the root cause of the issue is, irrespective of whether that root cause is of Zwifts making. Once that is known, then the root cause can either be fixed, or potentially be handled more gracefully.

[11:07:21] FPS 20.45, 65281, 27038, 207644
[11:07:21] [FTMS] SIM (1.1)
[11:07:22] [FTMS] SIM (1.1)
[11:07:22] [FTMS] SIM (1.1)
[11:07:23] [FTMS] SIM (1.1)
[11:07:23] [FTMS] SIM (1.1)
[11:07:25] [FTMS] SIM (1.1)
[11:07:25] [FTMS] SIM (1.1)
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Sending DEVICE - BLE DISCONNECT ERROR [ UUID: 238364874949049 ]
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Starting Native BLE search
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] BLE : Exeption caught in Windows BLE CharacteristicValueWrite()
[11:07:26] [FTMS] SIM (1.1)
[11:07:26] [FTMS] SIM (1.2)
[11:07:27] [FTMS] SIM (1.2)
[11:07:28] [FTMS] SIM (1.2)
[11:07:28] [FTMS] SIM (1.2)
[11:07:29] BLE : Sending DEVICE - DATA LOSS [ Name: Power|Cadence|Controllable UUID: 238364874949049 ]
[11:07:29] BLE : Sending DEVICE - DATA LOSS [ Name: Power|Cadence|Controllable UUID: 238364874949049 ]
[11:07:29] BLE : Sending DEVICE - DATA LOSS [ Name: Power|Cadence|Controllable UUID: 238364874949049 ]
[11:07:29] [FTMS] SIM (1.2)
[11:07:29] BLE : Sending DEVICE - DATA LOSS [ Name: Power|Cadence|Controllable UUID: 238364874949049 ]
[11:07:29] BLE : Sending DEVICE - DATA LOSS [ Name: Power|Cadence|Controllable UUID: 238364874949049 ]
[11:07:29] BLE : Sending DEVICE - DATA LOSS [ Name: Power|Cadence|Controllable UUID: 238364874949049 ]
[11:07:29] BLE : Sending DEVICE - DATA LOSS [ Name: Power|Cadence|Controllable UUID: 238364874949049 ]
[11:07:29] BLE : Sending DEVICE - DATA LOSS [ Name: Power|Cadence|Controllable UUID: 238364874949049 ]
[11:07:29] BLE : Sending DEVICE - DATA LOSS [ Name: Power|Cadence|Controllable UUID: 238364874949049 ]
[11:07:29] BLE : Sending DEVICE - DATA LOSS [ Name: Power|Cadence|Controllable UUID: 238364874949049 ]
[11:07:29] FPS 19.93, 66774, 27172, 212522
[11:07:30] [FTMS] SIM (1.3)
[11:07:31] HUD_Notify: STEERING DEVICE DISCONNECTED
[11:07:34] Saving phone triggered screenshot to server
[11:07:34] Saving phone triggered screenshot to server
[11:07:34] Enqueuing screenshots for upload
[11:07:34] NETCLIENT:[INFO] Uploading image to mobile device C:\Users\me\OneDrive\Pictures\Zwift/2021-11-15_11073419.jpg
[11:07:37] FPS 19.62, 67624, 27257, 215248
[11:07:38] Saving phone triggered screenshot to server
[11:07:38] Saving phone triggered screenshot to server
[11:07:39] Enqueuing screenshots for upload
[11:07:39] NETCLIENT:[INFO] Uploading image to mobile device C:\Users\me\OneDrive\Pictures\Zwift/2021-11-15_11073821.jpg
[11:07:41] “TICKR X BCD9 96” battery level: 37%
[11:07:43] [FTMS] SIM (1.4)
[11:07:43] “KICKR BIKE B3FE 235” firmware version: 1.23.0
[11:07:44] “KICKR BIKE B3FE 235” hardware revision number: 4
[11:07:44] [FTMS] SIM (1.4)
[11:07:44] [FTMS] SIM (1.4)
[11:07:45] [FTMS] SIM (1.4)
[11:07:45] FPS 19.42, 67661, 27261, 215413
[11:07:45] [FTMS] SIM (1.5)
[11:07:46] [FTMS] SIM (1.5)
[11:07:47] [FTMS] SIM (1.5)
[11:07:48] BLE : Sending DEVICE - BLE RECONNECT [ UUID: 238364874949049 ]
[11:07:48] [FTMS] SIM (1.5)
[11:07:49] [FTMS] SIM (1.5)
[11:07:49] [FTMS] SIM (1.5)
[11:07:49] Saving phone triggered screenshot to server

Looks like Zwift update 1.19 (Nov 18 2021) might have fixed this problem.

I pulled out my ANT+ stick and redid my tests using Fenix 6, Tickr X and HRM-Pro Bluetooth HR monitors.

When I walk out of range, Zwift now displays a notification that the HRM connection has been lost.

image

When I walk back into range, Zwift reconnects to the Bluetooth HRM and resumes showing HR data without any need to bring up the pairing screen.

I’m not popping the champagne bottle yet, but this looks very promising. :sunglasses:

2 Likes

Something similar happens to me. At some random(*) times during the workout my hrm and trainer disconnected reporting 0bpm and 0W. If i go to the pairing window in the settings, after a few seconds it looks like it has reconnected by itself, but when i go back to the training it will lose connection again.
My workaround was to go to the pairing window, click on all the “Disconnect” buttons and then reconnect everything manually. more or less this procedure takes 30-60 seconds. If this happens during a workout, I’m annoyed. If this happens during an event I’m dropped.

(*) In the past i experienced this issue in some particular places of the maps

It is still occurring with the Kickr bike in latest version but it did recover on its own. I have been communicating with Zwift support and after letting them know the latest version seemed better (it seemed to recover quicker) but it was still an issue I got a

“I hope the latest update will make things a bit better, however, so that you know, I’ve also checked with our team and this is now a known issue and they’re already working on a fix.”.

In the mean time I was asked to continue to use the companion app as a bluetooth bridge as a work around.

2 Likes

I have a brand new ticker and this has become an ongoing problem. Starts off fine and then drops for no reason, this has got me DQ from a few races now. Sad.

I see " connection failure" top left and I hadn’t seen that until a month or two ago.

I am not excusing zwift from being the root of random connection issues but, I also purchased a new tickr2 with firmware dated october 2021 and my hr would freqently be under reported say 81 instead of 150. also random dropouts (using BT 5.0, gave up on ANT+, and still waiting for direct connect to be implemented by zwift). The HRM issue persisted using other riding platforms so I opened a ticket with wahoo.
So I would encourage you to open up a ticket with wahoo, in my experience their support is timely and communicative.

1 Like

Troels - excellent observations that somehow are completely in-line with my findings across multiple HR BLE devices and multiple smart trainers. In my case, Apple TV instead of PC.

Long story short, with both Tacx Neo 2T and Wahoo KICKR Bike I have never, not once, had any connectivity issues in nearly 700 hours of riding. HRM are another thing: incessant drops, frozen “fake” reported HR data to Zwift, etc across Wahoo TICKR, Garmin, and Polar devices - none of which have any issues connecting/staying connected to other applications.

There is something in the BT code that Zwift should evaluate. It’s just not robust and doesn’t seem to expect drop-outs from devices which it needs to allow for. From my observations, a lot of these issues relate to a) if the user walks away from the device, b) if the user starts the BT device before starting Zwift, c) if the user has to adjust the fitment of the device interrupting the data. These kinds of use cases must be accounted for in the Zwift code and I am not sure that they are.

1 Like

Is there a way we can get this onto Zwift’s radar? Happy to help with any work.

I’m having the same problems. Had them several times during the last months but restarting the TickR Fit usually helped. In the last two weeks, however, nothing helped to fix the problem. I either have wrong static bpm values or no signal. To power the TickR off and on during a ride does not help. It really becomes more and more frustrating.
Is there any fix known by now?

Thank you for the write-up, exactly the problem I’ve been having for a long time. I would much rather have this fixed before any more worlds are created or gimmicks like tricycles and dinosaur games that I’ve seen in the past.

Tacx Neo 2T plus Apple TV user.

I’ve used both the Garmin HRM Dual and the Wahoo Tickr Fit and never had a BT connectivity problem with either (provided I pair directly to ATV). All my BT problems are related to the Companion app bridge, which I no longer use.