I have garmin vector 3 pedals and also a kinetic smart power unit. I use my vectors as the power source.
My battery status on the vectors shows either 50% on ant or 86% on Bluetooth which I think is down to the single vs double sided?
Am I best to connect my smart trainer via ant or Bluetooth? I had typically ran via ant, but today noticed that the Bluetooth connection had additional options for powermatch.
I’m finding my power readings are generally low vs RPE so currently investigating equipment issues.
Bluetooth hardware and software is almost guaranteed to be vastly more robust. There are at least 1000x as many Bluetooth devices than ant+. This means more bugs have been found and closed and unresolved ones will be found and closed faster. Bluetooth.
FWIW, I have used TR for a long time with BT and ran Zwift concurrently using ANT+. For the last week or so, I reversed it as I had bought a Sterzo steering block and Zwift only supports that in BT.
I found that TR kept my Elite Direto X trainer much tighter to the prescribed wattage in ANT+ than BT. With BT, it was a constant minor over / under the wattage…while still there with ANT, it was noticeably tighter.
Not that it matters much, but just thought I throw out that observation.
When it comes to sports devices specifically, the ANT+ protocols are generally more robust and better suited to the transmission of sports data (eg. the problems with transmission of dual sided power over BLE), and also support recording on multiple head units/devices
However, there is a fair bit of anecdotal evidence that ANT+ may be more susceptible to EMF interference in a typical domestic pain cave (eg. wifi routers, microwaves, etc) than Bluetooth.
Also, many phones/laptops that people use to run TrainerRoad/Zwift are Bluetooth only, so either you have to get an ANT+ dongle, or use Bluetooth. On the other hand, multiple streams of data (eg. speed, cadence, HR, etc) may exceed the number of available Bluetooth channels on the device, and if you want to capture all those streams of data, you may have to use ANT+.
My suggestion would be to try ANT+ first, but if you are having dropouts/interference, then try BLE.
Ant has the advantage for sensors in that lots of receivers can receive the same data. So if you look at reviewers like @dcrainmaker they do most tests with ant as it’s easy to feed the data into multiple head units. But since the signal isn’t acknowledged a lost packet is gone forever so you can have drop outs. (A trainer in erg mode when sent a wattage to target does send an acknowledgement message back but still can be missed and the delay can be large)
Bluetooth is a one to one broadcast so you can only pair to the number of channels the device supports (usually one, but some like the newer kicked support more then one. This can be a problem when you want to pair a sensor to multiple devices or if a receiver is paired to a sensor without you knowing it happened and then causing frustration trying to troubleshoot this. The one to one connection does have a significant advantage in that dropped packets are rebroadcast so while still possible to have dropped packets, it’s much harder.
If you understand IP networking ant is like udp, as it’s broadcast and the receiver hopefully gets it. Bluetooth is like tcp, a bit more overhead but more guarantee that the data will get to the destination.
So if you have one sensor you want to share with lots of devices ant is better. If you don’t really care about some lost data, ant is better. A receiver for ant just needs to know what to look for, it doesn’t need to establish a connection.
If you do care about dropped data, Bluetooth is better. So for example of you want to do HRV analysis of data from a heart rate strap, use bluetooth as the dropped packets in ant while not noticably impacting basic heart rate data will make HRV calculations significantly less accurate. Trainers are the same way, you don’t want to lose data in a transmission when controlling a trainer cause the trainer may not change the resistance when you want it to.
Not all devices implement the protocols perfectly so it’s possible Bluetooth may not be the best to use for a certain trainer
This reasoning is almost completely wrong. Ant is a much simpler protocol. This means less possible bugs (how many bugs does notepad have vs Microsoft word?) And easier to troubleshoot in that you can easily intercept all the transmissions to analyze and fake a device by transmitting what you want. The ant receiver hasn’t really changed in the last 10 years
Bluetooth on the other hand is more complicated with more edge cases as it sports a much wider variety of data connections. The implementation is not the same in all devices and they keep changing
Both work in the same rf spectrum, Bluetooth will rebroadcast packets that weren’t received making it less impacted.
However, keep in mind, the app/device won’t always actually reconcile those packets and record them out of sequence.
For example, I was testing a watch yesterday using a Bluetooth connection to a power meter, and it dropped out the connection occasionally, and clearly wasn’t reconciling the connection. Zero issues on the ANT+ side.
In general, for trainers I wouldn’t fret on which connection to use. However, for power meters, without question, I’d use ANT+ unless there is a very specific issue you’re trying to troubleshoot.
So i’ve been experiencing beaucoup drop outs with my power meter (vector 2) and it’s quite frustrating. I remember troubleshooting with TR support a few months ago and the guy was explaining to me that 2.4ghz frequency is used for ANT+ (!?) so the more activity i’ve got going on there, the more interference i’ll get in getting my signal through.
Now my old chromecast uses 2.4g
So i’m wondering if the streaming + other devices (smart trainer + hr) might be causing issues for my device to handle (whether it be my phone or laptop and ant+ stick) Luckily i’m just doing trad base for now but when intervals start, i gotta have this figured out
Maybe i have to find an alternative for entertainment on my tv to limit interference.
I wonder if that is a bug or just missing relatively easy functionality or if this would be something hard to implement. My assumptions:
-the retransmits are handled by the Bluetooth stack and so separate from the application itself. (Bluetooth receivers and transmitters have their own dedicated compute hardware to do this)
-Bluetooth packets have a timestamp or a sequence number of some kind to be able to reconstruct the order the data should be
-receivers that drop data just take the latest packets and write that to it’s stream
To me it seems like they should be able to detect it received an older packet and be able to backfill the stream. Since the flash memory store it writes the data to has to be done in blocks there should be a block that hasn’t be written out yet that could still be modified before it gets flushed out.
I run TR/Zwift together. I run TR through Bluetooth and Zwift through ANT+. Occasionally I get a little power drop, brief for only a split second, but only happens on Zwift and not TR. This leads me to believe that BT>ANT for reliability and ANT has notoriously poor signal range too
Yeah, ultimately all watches/bike computers that I know of are writing the .FIT file in real-time (or their internal equivalents), and none will backport data into that file. The singular exception is Garmin with their HR straps for data backfill, but that’s only after the activity is completed during the final sync process.
I’m not talking about backfilling from a significant amount of time in the past, I mean a second or two. Since watches/bike computers use flash memory as their back end data storage and all flash memory has to be written in complete blocks I’m pretty sure they aren’t really writing each and every new data point as it gets it.
Writing a partial block means read a block into memory, write the new data in with the old data and write the whole block out again. This means you’ll be writing the same peice of data lots of times, the first time when that is the new data and as part of the existing block when it is old data. Plus all those additional writes use power as writes are relatively high power draws so delaying the writes by having a buffer in ram saves power
That will make it easy to troubleshoot connection problems in zwift. I don’t know if any way to troubleshoot trainer road without depending on support. Would be nice if the desktop app had a log file of packet drops
Yeah, I’m not saying there isn’t better ways - I’m just saying how it actually works today. Nobody is backfilling data that I’m aware of, thus, any Bluetooth re-transmission benefits for that aren’t currently leveraged.