Over the last week or so there’s been substantial talk about power meter data in the Tour de France, specifically around scenarios of data snooping, data accuracy, data estimation, and data tampering. For the most part, the mainstream cycling media has gotten the majority of the core facts correct. However, there’s been a few cases of things not quite being as ‘neat and tidy’ as I’d like them from an over-zealously detailed standpoint.
Much of this discussion of course has originated from discussion around data from pro cyclist and soon two-time Tour de France winner Chris Froome, and his ability to sustain various power numbers, as well as the feasibility of the numbers that are leaked/stolen.
I’m not going to wade too far into the discussion on whether one is physiologically capable of hitting X power number for Y durations. Others can do that. Instead, I’m just going to focus on some of the data aspects, and talk to the validity of some of the statements thrown about (on both sides of the argument). I will however say that I think we’re just at the beginning of what will be immense discussions and changes on the topic.
So, consider this a bit of a primer on power meters in the aspects most talked about in the last week or so. I’ve divided this up into a bunch of short sections.
(Note: This post is highly technical, well into the geek range. It’ll probably bore many of you.)
Data Transmission:
First up, is the question on how data is transmitted from the power meters. There are basically two main ways power meters transmit data in the Tour de France today: Bluetooth Smart and ANT+. Both of these are designed as ultra-low power sensor systems, enabling power meters to get upwards of hundreds of hours of use on a coin cell battery. Or in some cases non-rechargeable batteries. Either way, almost everyone is using one of those two standards. The exception being SRM & Pioneer power meters to SRM & Pioneer head units, which use a variant of private-ANT (but not ANT+). The principle is basically the same though, and for the purposes of what we’ll discuss here – there’s almost no difference.
Within that, the vast majority of riders in the professional peloton are using ANT+, mostly because many of them are using Garmin devices – or SRM & Pioneer power meters with SRM & Pioneer head units. There are only a handful of Tour riders using non-ANT+ head units (just a few riders on Polar power meters). Furthermore, there’s only a handful of riders even using Bluetooth Smart power meters, which would be just Team Sky on the Stages units (which dual transmit ANT+/BLE). But Team Sky is using Garmin head units, so Bluetooth Smart isn’t used there.
Ok, so to recap:
Power Meters: You’ve got ANT+ or Bluetooth Smart, or in certain cases slight private-ANT variants.
Power Meter Data Collection: The same as above, with almost everyone using ANT+ or private-ANT variant.
Now with that noted, how is the data transmitted? Is it open and easily readable? Well, in a nutshell – yes. But, it depends a little bit on how it’s broadcast. Today, both ANT+ and Bluetooth Smart as used in power meters on the market today are not encrypting data. That means that one could snoop and listen to data broadcast from any rider passing by.
To start, we’ve got ANT+. By design the ANT+ power meter broadcast today transmit ANT+ power meter data clearly identified as such, and in a way that multiple devices can receive that data concurrently. The logic behind this is that it allows perhaps not just the rider, but also a coach/team car, or even a broadcast company to display the data during an event. You can easily download apps to view this data and could simply stand by the side of the road and collect the ANT+ data for a passing rider. Of course, you’d only get the data while the rider is in range – so perhaps 10-20 seconds worth. Hardly enough to be valuable.
When it comes to private-ANT variants, all of the above/below is essentially the same as ANT+.
Next, on the Bluetooth Smart side – that data isn’t as easily identifiable to passing devices. For all of the Bluetooth Smart sensors on the market today, you can only have a single concurrent connection at once. That means that if the rider already has a connection between their head unit and their Bluetooth Smart power meter, another device can’t connect as well. However, just because they can’t connect doesn’t mean they can’t snoop the data. The difference though is that snooping that data would take a semi-sophisticated hack to untangle the relatively gibberish looking data stream (as compared to ANT+ which is crisp and easy to pickup). The Bluetooth Smart data isn’t encrypted though, so someone (be it a paid developer or even just a curious hobbyist) could likely come up with an app to untangle all of that data stream and record it cleanly.
In either scenario though – you’re looking at the issue of how to collect data over the course of an entire stage or climb (mostly just the climbs). While standing by the side of the road gets you a quick snippet, it doesn’t get you much truly valuable data. Instead, for that you’d have to have devices travelling with the riders. For better or worse, those devices already exist today.
Regular readers know I use a device called the WASP from North Pole Engineering that collects ANT+ data from numerous sources. I could set that up to simply collect any and all sensor data. That would mean basically anything out there in the peloton I’d collect into a vast database. I’ve done this for fun at the start of the Paris Marathon – just collecting hundreds of ANT+ heart rate strap sensor data. Different sensor, same exact concept. For private-ANT data, it’s a tiny bit messier, but not much so.
But how do you figure out who is who from hundreds of ID’s? Well, for the most part ANT+ ID’s are sorta unique (they can be re-used, but it’s not usually done within the power meter world since there are less units shipped than 1,000,0000 power meters by company). Given that, and given the ANT+ information includes company/type/etc… you can start to form a picture. Then one merely need to sit outside the team vans each morning at the Tour and match real-time data to what’s going on as the mechanics prepare each bike. Again, trivial stuff (in case you forgot by now, yes I work in IT, and yes, coming up with some of these ‘how to break’ scenarios is part of my job). Even more trivial when you look at team budgets in the $35-40M range.
So over the course of a few days at the early portion of the Tour start and finish lines you could likely map out the majority of the rider’s ID’s being used – thus building a database. Even with bike swaps and the like, it’s still relatively trivial with a small team.
Now – how to collect that data mid-ride? Again, the WASP. It’s small, and would easily fit in a jersey pocket (and, it’s UCI legal). Place one on every team rider and you’d create a bit of a data net that would likely cover the entire peloton with ease. It of course wouldn’t capture attacks where you didn’t have a team rider present – but would probably enable you to gather a substantial amount of information.
Finally – encryption. Encryption could theoretically thwart this (all encryption is breakable with enough time/money/computing resources). Both ANT+ and Bluetooth Smart support encryption of the data in transit. But no power meters or head units on the market support this today. That means that even if SRM, PowerTap, Quarq, or someone else were to add encryption of the data – nobody is actually supporting decrypting at the bike computer/head unit side. Given that no team has demanded this, it likely tells you how much true interest there really is in encrypting of data.
Privacy of data on head units/sites:
Next, comes the data that’s collected on the head unit itself – your ride files. Obviously, that’s the most complete attack vector in that it has everything in one handy little place with all data neat and clean. But it’s also likely the hardest to break electronically. That’s because in order to capture the data wirelessly you’d need to pair with the device. That pairing requires you to validate and/or enter in a unique pairing code between the device and your phone, prior to a successful pairing. This is identical to when you pair most other Bluetooth devices that you must validate first.
At this stage, it’s not a question of Bluetooth Smart or ANT+, since all of the data transfer wirelessly is only done on today’s cycling devices via Bluetooth Smart or WiFi (Edge 1000 basically). And trying to snoop the WiFi connection in a team hotel at the end of a stage just wouldn’t be worth it for a single ride file.
The most obvious way to capture the data is just physical access to the head unit itself. In the case of the Garmin Edge units, if you had physical access to the USB port of the device, then you could easily copy that data off in a few seconds and have complete and ready to analyze full files. The obvious challenge there being access to the bikes. But as anyone who has been to the Tour de France will tell you, these bikes are often left unattended near the RV’s. One who was skilled enough (and even faster with a small custom program), could probably download the full data set off of a unit in 20-35 seconds. But again, that requires a ton of luck (nobody seeing you). Plus, many times riders don’t put their head units onto the bars until they walk up. But…if you’re talking a potentially disgruntled team employee, then nobody would ever notice.
Lastly, we’ve got the data sites that the riders use. Many riders use Training Peaks, with still more using Strava. While I’ll skip discussions about the backend security of these sites, for most attacks it’s far easier to just brute-force or otherwise guess the passwords that the riders or coaches use. If a rider uses ‘YellowJersey’ as his password, then obviously that’s their issue.
Non-Round (Osymetric) Rings & Left-Only Power Meters:
Next, there’s been a bit of discussion around the impact of non-round (osymetric) chain rings and left-only power meters. Both of which can impact the ‘accuracy’ of power meter data displayed/recorded.
Starting first with non-round rings, this has been proven to impact accuracy on many power meters. In fact, it impacts accuracy on almost everything except PowerTap Hubs. It can be correct on some ROTOR Power Meters (newer BB axle based), but not all (it’s still a bit unproven if it’s impacted on Power2Max). But it’s definitely impacted (inaccurate) on SRM, Garmin Vector, Quarq, Polar, Stages, and a number of others. This is due to these power meters assuming a constant speed revolution trigger (be it magnet, reed switch, or accelerometer).
How much is that accuracy shift? Well, it depends actually quite a bit on the amount of ring ovality. From a few percent, or more if you look at the testing that Stages has done, putting it closer to a 4-5% increase (inflation). But putting a specific/exact inflation number on it to just make a blanket statement that it would always be X% higher would be challenging – nonetheless, it will impact the accuracy.
Next we’ve got left-only power. This primarily impacts power meters that are measuring only the left-side, most notably Stages, but also many other companies that have started down that path. This includes Garmin Vector S, ROTOR LT, 4iiii Precision, Polar Power Essentials, and more. This exact split of the power output is called ‘power balance’.
All of these left-only power meters simply ‘double’ the left-side power to get total left/right power. This means that if you have a power imbalance (such as 47% left, 53% right), you’ll have a potentially higher or lower value than reality – due to the doubling of the difference. This is well known. But what’s not well understood is that this difference doesn’t remain the same. Meaning, it’s not always 47%/53% for a given rider.
Many cyclists have noted over the past few years that with left-only devices (and something to compare against) they’ll see shifts in the power balance. For example, for some people they’ll have very even balance up to a given wattage (such as their FTP). While others will have the opposite. Yet still, many might fatigue differently. So as a particularly hard ride goes along, you might slowly shift more or less to a given side.
Being a ‘professional rider’ does not exclude you from these. Mostly because there’s no real evidence that says you ‘should’ be 50%/50% balanced. Usually attempting to change/shift this balance results in a loss of overall power. Thus data from left-only power meters is much more difficult to compare to non-left only power meters. While you can certainly look at Team Sky and say “Well, Team Sky has won the TdF on it”, the reality is that’s marketing and sponsorships for you. Don’t overthink it.
All that said, do remember the timeline of when Stages was being used in the Tour de France on Team Sky:
2013: Team Sky on SRM
2014: Team Sky on Stages
2015: Team Sky on Stages
Thus, if looking at specific data from 2013, remember that’s SRM (which captures full left/right, but is impacted by non-round rings). Whereas data from 2014 onwards would be left-only and impacted accordingly.
Incorrect Calibration/Offsets:
One interesting area of discussion is potentially sending a given power meter an incorrect offset or calibration value. This has been loosely discussed a little bit in the past week – and it’s definitely a valid concern.
See, ANT+ and Bluetooth Smart power meters both allow end users to calibrate the power meter and to then have that power meter store an offset value. That offset value is normally used to account for things like temperature shifts or other environmental/aging factors. Typically a rider prior to the start of riding would do a zero calibration to tell the power meter that no force is currently on the pedals.
It should be noted that while most head unit companies use the term ‘calibration’, that’s actually somewhat confusing. Technically speaking what most consumers do at the start of a ride is called an ‘offset’ and not a calibration. Think of it like using the ‘tare’ function on a kitchen scale. A true ‘calibration’ involves a known weight that allows you to check the torque slope. This is done at the factory, but it’s also something that can be done by anyone at home with a capable power meter. Some power meters don’t support this, but many do. It can be valuable in certain situations if you need to validate a power meter is functioning correctly and accurately.
But 99.99% of consumers (or pros) won’t do that that level of calibration, instead, they’ll just press the ‘calibrate’ button within their head unit to perform the offset.
Now, this same tactic could also be used to set an incorrect offset to another rider’s power meter. There is no validation or check of this data, except to ensure that the bike/crank isn’t moving. So using the team RV scenario each morning, it’d be a trivial easy thing using existing tools to connect to another power meter and then give it an incorrect offset. For example, I’ve used various beta and utility tools that do this over the years.
The impact of this would be that a rider – especially in a time trial stage – could be focused on hitting certain power numbers. You’ll remember a photo two years ago of Tony Martin’s exact power numbers for each section of that time trial. If you skewed his offset just 5-10% higher/lower, that could potentially lead to either going out too hard or too easy.
Of course – this starts to get into fairly ‘dirty’ tactics, but as the sport of cycling has proven over and over again, that’s hardly outside the norm.
And finally – there’s simply the self-inflicted wound case here. That’s where a given power meter is incorrectly calibrated by the rider themselves (or not calibrated at all). That’s I think actually the biggest ‘risk’ to accurate data that’s least discussed.
Odds & Ends:
Finally, before we wrap-up, there are a few other factors that can impact power meter data, or power meter analysis that should be mentioned. In no particular order, here we go:
Impact of weather/environmental factors: If there’s a power meter that’s having a bad day when it comes to adapting to weather and producing erroneous numbers (as I’ve shown in the past in certain power meter tests), that can definitely impact numbers substantially. This is especially true in mountain stages with large shifts in weather. This can sometimes occur in cases where a devices temperature compensation can lag behind the actual temperature shifts (sometimes to mitigate brief false positives). Still, this could in rare circumstances result in non-aligned data. Additionally, there are scenarios with certain power meters where automatic auto-zeroing may be skipped on particularly long climbs due to lack of coasting (which some manufactures use to trigger an auto-zero)- impacting the ability to compensate for temperature shifts.
Providing ‘average’ data: There have been recent discussions on some teams providing ‘average’ data for a given rider on a given stage. For example, to say “Rider X averaged 278w with an average cadence of 92rpm and an average HR of 158bpm”. In the simplest possible way I can express this, that data is completely useless. For example, a TdF winner on a mountain stage like Alpe d’Huez could sit in the peloton all day long before making an attack up the mountain. While in the peloton for 3-4 hours with drafting they could be putting out trivial power numbers (i.e. 150-200w or less). Meanwhile, while on the mountain for that 40-50 minute climb they could be putting out huge numbers (i.e. 380-400w). The average of those two would show a much lower number than the real climb numbers. In my opinion providing such average numbers is basically just a smokescreen to trick people into thinking they’ve done something useful. Don’t fall for it.
Weight loss during a stage: As anyone who has stepped on a scale before and after a workout on a hot day knows – there can be a fair bit of water weight loss on a 3-5hr workout (be it racing or training). While this won’t impact exact wattages, it can impact W/KG metrics that utilize weight. Thus if a rider is doing back to back stages on exceedingly hot days, they might not fully recuperate all of their liquids by the next day. Or, even within a given day. While not a huge issue – it could certainly impact W/KG analysis by 1-2%.
Power meter placement: In a perfect world, the closer the power meter is to your foot, the higher the power value will be. So in theory, if you were to use Vector, Stages, SRM, and a PowerTap – the power output for those in a perfectly calibrated world would actually be in that same order from highest to lowest. That’s because of small mechanical loses as you progress further from the source. Sorta like when you fart in a room, those closest to you get a higher dose than those further away. This is usually 1-3% from pedal to hub, but it depends on many factors including the materials in the bike and cleanliness of the drive chain.
Getting two power meters to agree: While some would like every power meter to agree perfectly every day – as one who rides with 3-5 power meters on every ride, I can tell you this is INCREDBLY hard to get every power meter to agree every day (heck, to get any 2-3 power meters to agree every day to the exact same wattage). It’s a key reason why virtually all power meter manufacturers specify an accurate range of usually 1-2% (high or low).
Any of the above can certainly impact total accuracy numbers. While one might try and add up the different percentages, do keep in mind that some might make a power number lower (i.e. left-only), while others might make it higher (i.e. non-round rings).
Wrap-up:
At this point, you’re probably scared to death of using your power meter. But in reality – almost everything I’ve discussed to date is really about data openness (excluding setting nefarious values). Any many riders today openly post their race data – even stage wins and climbs. Both Strava and Training Peaks do daily/weekly roundups of power meter files posted, as do various other teams. Those teams are essentially giving an additional layer of data that can be used to raise or decrease suspicions on a given rider when it comes to cheating (be it via drugs, motors in bikes, etc…).
Some would say that information is very tactical in nature – and that’s probably true to an extent. So it’s understandable that some teams would want to keep that private. But, when teams face criticism, it can be one potential avenue to increase openness.
With that – thanks for reading – and feel free to drop any questions below!
(Thanks to power meter gurus Robert Chung and Tom Anhalt for validating and contributing to this post – I greatly appreciate it!)
FOUND THIS POST USEFUL? SUPPORT THE SITE!
Hopefully, you found this post useful. The website is really a labor of love, so please consider becoming a DC RAINMAKER Supporter. This gets you an ad-free experience, and access to our (mostly) bi-monthly behind-the-scenes video series of “Shed Talkin’”.
Support DCRainMaker - Shop on Amazon
Otherwise, perhaps consider using the below link if shopping on Amazon. As an Amazon Associate, I earn from qualifying purchases. It doesn’t cost you anything extra, but your purchases help support this website a lot. It could simply be buying toilet paper, or this pizza oven we use and love.
Yes! Great article. I’ve day dreamed about various nefarious things you could do around power in the tdf.
One thing that you didn’t mention is that ant is on a specific channel of 2.4ghz. It can easily be overpowered by a stronger signal. Essentially, you could make all the power meters stop working if you blasted out radio signals at 2.4 ghz.
This happens all the time when someone starts the microwave in our office…I think it’s time to get a new microwave! Even a router can do it if they are set to the right channel.
BT makes that a bit harder because of frequency hoping, but you could still do it.
Your calibration (offset) sabotage is right on depending on the power meter. If it were anything but an SRM you could send a calibration command to an ant power meter while the rider was in the blocks about to start a time trial. You would do this while he had wait applied to his pedals so the offset would be wrong.
SRMs don’t store the offset locally (you use it in software to come up with the power number) so it might not work…but the SRM head unit might just accept the new offset and use that.
Of course, a rider could fix this by pedaling backwards a few times with a Quarq. That would trigger a new offset.
Digital cycling warfare! It’s fun to think about :).
Fart in the room analogy! LMFAO, Haha. Great write up. Didn’t think it was too geeky but that might be a little telling of my personality.
Great post but I never thought I should say this to you, but I think you left out a few details. :-)
How is the live signal transmitted from the bike to the TdF organization and TV broadcasters?
Wouldn’t it be easy for the teams to modify the data before uploading them to Strava and other training sites?
Wouldn’t it be possible to get custom software in the head unit or power unit from the manufacturer or even others if you wished to manipulate the public figures?
While I don’t know about Power Data, Cadense or any other data, I did read up on the new GPS thingy the riders have beneath their seats. That is being transmitted to the motorcycles, then to the cars, then to the helicopters, then to both airplanes, then to the ground station where it ‘edited, reviewed’ and sometimes included in the TV broadcast. Curtesy of Dimension Data, from South Africa.
link to cyclingtips.com.au
The claims the teams are keeping their data secret has baffled me for a couple of years, given that the majority is broadcast unencrypted over ANT+. I’d be interested to see how effective a WASP unit on a drone would be for gathering data. It would take a POV setup and some good flying, but nothing unachievable with some effort.
Also: […] (and, it’s UCI illegal)[…] should that be and, it’s UCI legal? It seems like a strange thing to ban since it’s just a receiver?
(Thanks, fixed on UCI legal typo).
As for a drone, that’d be tricky because of the limited battery time of most units (in the 20ish minute range). But more importantly, most major races have helicopters and such, and one wouldn’t want to interfere with that.
As soon as they start locking down Ant+ i suspect it’ll end up costing the consumer like us.
Inevitable though at some point
I don’t think it will hurt consumers. I think it’ll simply drive Garmin and power meter companies to enable encryption as an option.
It’s not inevitable.
There are significant consumer usability issues in making sure that communications can be only be between or observed by the devices the user intended.
Encryption is easy.
Perfectly secure key exchange over insecure and widely observable channels (e.g. radio), which is required for encryption to be meaningful, is not easy.
Add in normal consumers, who want to be able to easily replace or mix devices, where those devices are very limited (in size, in UI capabilities – perhaps just a couple of LEDs and 1 or 2 buttons), and perfect, reliable, secure *and* _convenient_ key exchange becomes *really* hard.
Almost inevitably, something must be compromised on the security side to make the product practical for consumer use.
(One way: Use a more secure channel, e.g. a physical device – a dongle – to transfer the key – but this adds costs and inconveniences too, and can even introduce new attack vectors).
Note, for WorldTour racing with vendor technical support in attendance, then yes it would be quite feasible. Vendors obviously can do things that would be infeasible for mass market consumers.
As noted in my other comment, it doesn’t need to be enabled by default. It can be optional . The spec is done and already available, and I thought I remember that some medical devices were using it within ANT+ already (and I know some BLE devices use encryption too). On the ANT+ side, you can download the spec from their site for implementation details.
As for WorldTour racing support – it’s actually much lower than you’d think. Many companies like to wave that around a bit in terms of saying “The TdF required X and so we implemented it immediately”. But in reality that’s rarely the case when I talk to these companies – the vast majority of changes were items they already had in the pipeline.
Oh, the encryption implementation spec is detailed in this document starting around page 86: link to thisisant.com
Having encryption in the spec, like I said, the trivially easy bit. No doubt it’s there. I’d confirm it for myself (reading network protocol specs is a regular part of my job), except you can’t download their spec for free last time I went to look. (Ah, apparently that has changed?).
The *hard* bit is key exchange. Not the network protocol side (cryptographic protocols exist for that), but the UX aspect of making it work generally with very UI-limited devices for mass market consumers.
I’ve done a small bit of risk assessment work myself in this area, and had discussions with engineers from respectable vendors working on wireless, electronic devices for cycling, and it really is a difficult problem.
If it was a solved problem, ANT+ communications would no doubt be encrypted. It isn’t – it’s a tough problem, because it involves subjective compromises.
Ray linked directly to the spec PDF, they opened it up a lot of this about 6 months ago.
A few limitations here – only a single channel can be encrypted per node (I think this will allow one channel per sensor), and you would provide the secret key and seed number in clear-ANT before encryption starts. So on most power meters you could encrypt all the data as it comes over a single channel (power and speed/cadence depending on the sensor.
From an implementation point of view it should be possible for the sensors to behave such that once they are configured in encrypted mode by a head unit, they don’t respond to other connection requests. Then on the head unit, once the sensor is connected the user chooses to switch it to encrypted mode, which passes the key and perhaps seed. Yes the key sharing is vulnerable, but you can do it once at home (or in a lead-lined room) and from then on only your head unit will see data from the sensor. The user doesn’t need to know or enter the key, and it could be randomised each time encryption is enabled. The sensor could store the key and remain in encrypted mode until the head unit says otherwise or you do a hard reset (eg. battery removal).
Sure there are points of vulnerability here, but for the typical user it can be simple and ‘secure enough’, and for the pro user you can take precautions as needed.
No doubt there’s aspects that will make it more complex – don’t disagree there.
Will definitely be interesting to see what comes of it. I’d suspect that before we see wireless shifting start shipping, some portion of the problems discussed will have to be solved to a degree that makes both teams and general consumers comfortable.
I suspect the main reason that we haven’t seen ANT+ communications encrypted is simply that it hasn’t been a high enough priority for Garmin. The reality is that the tech side of the cycling industry from a data recording standpoint is driven by them. So while it’s certainly possible another head unit could enable it – all of the PM companies tell me that essentially unless Garmin also enables it, they won’t bother (talking generally, as in Feature X). A great similiar example would be the ANT+ FE-C profile. Companies like Wahoo straight-up said that unless Garmin enabled it, they wouldn’t bother. Within 3 minutes of Garmin stating they’d enable it, Wahoo agreed (it was about 4 minutes actually by time we finished pleasantries on the phone).
(FYI: For ANT+, the specs should be downloadable straight-up without logging in, though I think certain specs require the free-tier account to be created. I know beta-specs require the non-free tier. I haven’t recently looked at the BLE site to see if it’s different/similar).
The lead-lined room approach assumes you can initiate key exchange securely. E.g. using a physical button?
Except, others may also be able to do this in the field, if you leave the device unattended, or reset device authentication in some way (after all, there has to be some way to de-authenticate/invalidate/remove keys). So others with physical access in the field can make you have to do key exchange in the field, away from your lead-lined room.
There may be other reasons why you have to do key exchange in a hostile environment. E.g. a device fails and has to be replaced. At the level of professional teams at races, one could imagine devices having to be regularly replaced insecure environments.
If you can restrict key exchange to a secure environment, then the problem is reduced to securing the mechanism that initiates key exchange. Which might be a physical button.
That issues were *exactly* what I had in mind when I referred to “something must be compromised on the security side to make the product practical for consumer use”, and on vendor support at big races (they might have expertise to use a low-level physical interface, e.g.).
Schemes like this are actually in use, outside of ANT+ at least. They’re almost certainly secure for many use-cases, however there is, as per earlier, a compromise in the security for the sake of usability.
Fair enough, sure there would still be holes in a strategy like that. For consumers I can see it being sufficient, and since the pro’s piggyback on this then they would have to take further steps to keep it secure. Needing to be able to easily configure this in a race situation is another challenge – if it takes too long they’ll work around it.
Maybe wired power meters will make a comeback, pretty hard to hack those on the bike :)
But generally speaking of a person has physical access to a device, then from a security laws standpoint that’s considered ‘owned’.
Of course, the pre-race pro team scenario that’s more challenging due to the wide range of people having physical access. But one could implement aspects like only pairing to a single encrypted device such that if someone had paired to an unauthorized device, then the cyclist would immediately know since no power would be displayed.
Hi Ray,
Yes indeed, by adding a requirement to, say, press a physical button before a device will go into key setup mode, you add a physical security component to it. So the user at least has an opportunity to restrict that mode to RF-secure environments.
However, that still leaves the issue that if pairing/setup/key-exchange has to be done in an RF-insecure environment. The only way to do secret-key exchange securely over an insecure channel is using public key cryptography (which can cost a lot of energy). However public key cryptography of itself doesn’t solve the problem of authenticating and authorising the user’s devices to each other. You would need some kind of public-key infrastructure to address the authentication side. You then also need some protocol to allow devices to authorise access to each other.
Designing, standardising and deploying a PKI system is non-trivial. I guess you could re-use the X.509 TLS PKI used for things like HTTPS, however it is a bit of a monster and it’s not exactly friendly to use. Users would have to submit proof of identity to obtain their own signed key in the PKI. Then to pair two devices they’d have to get authorisation. So you might have to send off proof of ownership (correctly signed) to the PKI operator, before you could pair your devices – because until then, your devices won’t trust you or any of your other devices!
It would be horrendous. PKI is wonderful in theory, but can be a giant pain to design, deploy and administer, and be very inconvient. Simple and fuss free PKI definitely is not.
So, as far as I can see ANT+ does not use public key crypto (and I would be highly surprised if it did). I havn’t checked, but I doubt BLE does either. Which means the keys exchange can be passively observed (certainly trivially the case from the ANT+ key setting messages). Which means the users devices will *work* just fine.
The user simply won’t know.
Security, it’s hard, really really hard. :)
Yeah, I’d guess that we cross the line when we start to worry about sniffing that initial key exchange upon press of the button. That requires a pretty sophisticated attack (logistically speaking) for one to ensure they were there at that time – since it would likely occur at a team training camp or in some semi-private area. I would think that’d be a fair tradeoff for ease of simplicity.
And indeed, PKI infrastructures are uber-non-trivial. There’s noting enjoyable about PKI…ever. ;)
Sure, restricting pairing to physically initiated action, so the user can choose to do it in a secure environment. Undoubtedly the right balance between security and convenience nearly all the time.
*However*, if you need to do pairing unexpectedly, away from a secure place, then it doesn’t help at all. E.g. a device fails and has to be replaced, or isn’t working right and has to be reset, while at a race.
Security that’s perfect and still convenient to use: really really hard.
Security that’s adequate most of the time and still convenient to use: Achievable.
:)
Crypto introduces significant performance overhead. Given that component decisions in bike computers are made pretty ruthlessly on cost-of-goods grounds, it’s possible that crypto support on today’s hardware would lead to sluggish performance.
An analogy: Cisco sales types used to say it was a best practice to have a dedicated IPSec VPN box next to the router. In fact, routers in those days just didn’t have the processing grunt to do IPSec. Now they do, but it required hardware upgrades, and in some cases, dedicated chips from Cavium etc. to do the crypto…
Don’t get me wrong: I’d like to see encryption everywhere. It may require some upgrades, though.
Great write up, covers a lot of details you wouldn’t hear of in the media. Hope this doesn’t get picked up mainstream with the usual pick & choose approach to facts. There is a big gap between people who understand how this technology works and the limitations, and those whose job it is to summarise in sensationalist media to back up their angle.
I’ve done quite a bit of work with ANT+ data capture, and encrypted 1:1 connections has to be coming – such that the first head unit to connect has exclusive reception of the sensor data while connected (similar to bluetooth). It would add extra load on the sensor, but with the low data rates this shouldn’t add limitations. Plenty of other sports outside pro cycling would be keen on this, and with the attention this will now get it is certain to come. Depends on uptake from sensor and head unit manufacturers (both would need to support encryption), and might not get retrofitted to existing hardware so would leave sensor – head unit combinations that couldn’t support encryption unless updated or replaced.
How do you do secure key exchange over radio, in a way that ensures the devices the user _wants_ to talk to each other can decrypt each other comms and _no_ other devices can? How do you do this between devices which have very basic user interaction (e.g. 1 LED and 1 push button)? For a mass market….
It’s already been figured out. ANT+ released the spec back in 2013.
It needn’t be enabled by default, just like most security items and how they start. And ultimately, while some might assume that TdF teams can get a ‘special build’ of hardware/firmware – that just doesn’t happen these days. It’s too small of a market, so all of the PM/head unit companies would do it for everyone.
Hi Ray,
See my other reply. Encryption and key exchange are different things. Encryption is not the issue. However, for encryption to be secure, the keys must be secure. Key exchange can be hard under certain constraints – potentially very hard. See reply above.
Oh, and the issue is that you need to authenticate the user’s devices to each other somehow, with the following constraints:
– The devices’ UI capabilities may be restricted to a few bits of output (e.g. a couple of LEDs), and input (e.g. 1 or 2 buttons)
– The end-users are unsophisticated
– The end-users will want to be able to pair devices quickly and without having to have Internet access
It’s hard to think of a solution to this, other than using a physical channel (but then you need to standardise that, which also has some practical issues).
It’s technically very simple to do a secure key exchange with no user input at all – sensor says “I’ve got data, if you want it encrypted, generate an encryption key and send it to me, encrypted using this public key”. Head unit generates random key, encrypts it using the sensor’s public key, and sends it to the sensor, which then decrypts it using the matching private key for the public key it advertised earlier. True, public key encryption takes a bit of computing power, but as it’s an occasional thing, it doesn’t matter if it takes a few seconds for the initial exchange.
What you describe lacks authentication or authorisation.
Yes, you can do key exchange using public key cryptography. However, without establishing the identity of the other side, this needn’t buy much. You may simply have exchanged key with the “bad” guy.
You could set up a trusted key authority and key signing. However, note what I said about “no Internet access”. Even if you drop that requirement, then what? You have people submit proof of ownership requests to some central authority, so that their devices will allow connections between each other?
To provide encrypted communication you don’t need any of that, all of that is about ensuring you’re connected to the device you think you’re connected to – which is very obvious in the case of a power meter. If you reversed the direction (I.e. had the power meter connect to the head unit using the head unit’s public key) then you would indeed have the problem you mention, but doing it the other way around completely obviates that. You’d do it on pairing and that would be it. Perfect secrecy, with little overhead once paired.
There’s absolutely no need for internet access, and no need for PKI infrastructure. All you need to do is pair your device, and if it’s not showing your power then you’ve paired to the wrong device – it is no more complex than standard pairing from a user perspective.
Mark,
One device being paired with another does not prevent others from reading the messages. They’re communicating via radio – a shared, public, observable channel – i.e. an insecure channel.
If you simply send a key for a symmetric encryption algorithm over such a channel, then anyone observing it can decrypt any latter encrypted messages – without the devices knowing.
If you think it can be done securely, state the scheme you’re thinking in more detail.
It’s really simple:
1. Sensor (when unpaired) broadcasts its public key.
2. Head unit, when attempting to pair, receives public key and chooses random encryption key for future communication, encrypts that with the sensor’s public key, and sends it to sensor.
3. Sensor receives encrypted encryption key from head unit and decrypts it using the private key matching the public key it earlier broadcast.
4. At this point, sensor and head unit both have a shared key to use, and that has never been sent in the clear, so cannot have been intercepted by any third party. That key is then used to encrypt all future communication between sensor and head unit.
Done! What this doesn’t provide is assurance that the “sensor is who it says it is”, so would not be acceptable for, say, financial transactions. That’s why those applications need PKI to sign the public keys used. But with a sensor, it is obvious if you are paired to the right device (and this only needs to be checked on pairing, exactly like a non-encrypted pairing), so that’s an unnecessary overhead for this application.
Obviously, for this, or any other encryption scheme, to work, the sensor must deny other pairings while it is paired securely. Else you’d just have encrypted sensor data going to anyone who asked for it :)
Right, exactly as I stated 2 comments ago:
“However, without establishing the identity of the other side, this needn’t buy much. You may simply have exchanged key with the “bad” guy.”
The 2 devices are very likely:
* low-powered
* computationally restricted
The bad guy potentially may have a much higher power radio and a much faster processor. The bad guy may also have a high-gain, directional antenna, if needs be. I.e. the bad guy can respond more quickly and can drown out the other device – they just have to spend a bit more than the target device manufacturer did.
The bad guy likely can MITM the key exchange, and hence MITM the rest of the connection – as long as they remain within range and active whenever the user uses the device. Otherwise the user will notice and re-pair the devices.
However, this implies that “re-pair” will be the user action to communication problems, so if the target has re-paired the devices, if the attacker can disrupt the communications then the user will respond by initiating re-pairing, and so letting the attacker MITM the connection.
It’s an improvement over plaintext key exchange perhaps, but it’s still not secure. Perhaps for some applications where the user moves, this would be a benefit (devices on bicycles & racing) and raise the bar out of reach of, say, spectators. In other scenarios (competitor who is often near you – as discussed earlier), it doesn’t buy anything.
Overall, I’d stick with passively snoopable, plain text key exchange, and pairing my devices in a secure location. It’s simpler, it doesn’t give my attacker any motivation to jam my communications and disrupt me seeing my data. If my data really was *so* terribly valuable that I couldn’t afford to have anyone else see it, then unauthenticated public-key crypto session-key exchange *doesn’t* protect my data anyway – so why add those costs just for a false sense of security?
If the data really is *that* valuable, you do /need/ authentication. If you don’t need that security, you can settle for the simpler security – half-arsed public-key crypto would only add unneeded cost and energy drains.
It doesn’t matter at all if someone MITM’s the key exchange as they don’t have the private key which is embedded in the sensor. To do as you describe the attacker would have to be present at pairing then remain in range throughout the entire time the sensor is in use, which is obviously impractical.
The point is to prevent simple snooping by other teams/competitors/fans, and a simple public key covered key exchange does this. It would be trivial to add a simple PKI where each sensor manufacturer publishes the certificate used to sign the sensor keys, and for those to be present in head unit firmware, but I’d argue that unnecessary for the very limited attack vector of being physically present for 100% of the time the device is in use… If you exchanged keys in the clear, then someone snooping that would have permanent access to your data until you re-paired – I’ve no idea how that’s better than doing a bit of extra maths during the key exchange to make that impossible.
Yes, that’s exactly what I said:
“The bad guy likely can MITM the key exchange, and hence MITM the rest of the connection – as long as they remain within range and active whenever the user uses the device. Otherwise the user will notice and re-pair the devices.”
I don’t know why you think it is impractical to do this in a race setting. There are literally dozens of people who stay near each other from before the race to well into it.
Why go to the expense (energy, code storage) of public-key crypto, if it isn’t buying anything significant over plain-text symmetric key exchange? In both cases, if you pair/key-exchange in an insecure location like a race, then you simply *no longer have any guarantee of security*. The public-key session-key exchange approach makes the logistics /slightly/ harder for the attacker, but still not that difficult.
So really you need to *still do the pairing in a secure location, either way*, if your data *really* needs to be secure. In which case, why bother with unauthenticated public-key session-key exchange?
A false sense of security is often worse than a less secure, but realistic scheme.
As for PKI, it might perhaps be feasible for an ANT+ industry body to do some kind of signing of device keys. However, that isn’t enough. That would cover authentication, but it doesn’t deal with authorisation. You additionally need some way to (securely) allow the device to know what other devices are allowed to connect to it. So then what? End-users needing to send in proof-of-purchase documentation to some ANT+ consortium, to get signed authorisation-certificates to upload to devices? It’s horrendous…
I just don’t believe anyone really thinks things like biometric performance data like power, or heart-rate _actually_ is *that* valuable, that it warrants the horrendous overheads, complexity and barriers to use of a really strong cryptographic security protocol for a general-purpose, cross-device, industry-standard protocol like ANT+. Proof: Everyone, including pro-teams, is happy to broadcast this data in the clear today. At which point, stick to something simple and obvious like “do the plain-text pairing in a secure location and it’s secure”. Hell, even if you don’t do that – who cares – as is the general state of things today – no one really is bothered.
Don’t add complexity and more complicated encryption algorithms for little security benefit though. ;)
Great article Ray – one of the first i’ve seen that considers the validity of the data as a factor, rather than just the validity of the riders legs.
I have a bit of a random power meter question, I’m looking at the power2max Classic, my current ride is a 20 year old 8 speed setup (shimano 105). Would it be possible to just put my 8 speed compatible chainrings on the power2max? I can’t see any specific restrictions to 10-11 speed chainring models, but wanted to be sure before I got too excited.
I don’t think there is any restriction as it is just a standard spider. I use it fine on a 9 speed setup.
Nice article lots of insight and useful data. I think you underestimating difficulty of some of described exploits, calling them easy and trivial. I know, the budget argument. Might not be practical either. Interesting points though.
Good stuff!
PS
Fart analogy although colourful was a bit weak.
For the ones I called trivial – I can already do. ;)
Today at the TdF I was able to capture both men’s and women’s data, and start to match exact riders to ID’s. And that’s all without even going to the start and sitting around to more easily identify riders (I could likely get/ID an entire team there in 2-5 minutes if timed right).
for SRM bike power meters, you would get the data wrong, unless you got the calibration that day. Is it correct?
For ANT+ data, that value is stored in the PM. I’m not sure about SRM on private-ANT (I’ll find out).
SRM is an ANT+ “Crank Torque Frequency Sensor”. The offset is stored on the display during the calibration process. For this reason you would need to capture the calibration messages to get the real bike power. It is not enough to receive the broadcast messages, as it can be done with the other bike power meters
With Dimension Data tracking riders this year, the real speed and location is known. If you were wanting to show nefarious activity, one could upload this to Strava and let them calculate watts for you.
In case you are not aware, Dimension Data supplies the black handle looking stick on the seats of the riders. This is a GPS cellular modem, a M2M device. The data of each rider captured, IN REAL TIME, by a 3rd party for the tour organizer, thus secrecy is gone. If you have used the LeTour website, this is how they show the live tracking of breakaways, who is in the breakaways, and who is straggling. It would not be difficult to add complete sensor data to the M2M modem, then it would be displayed for all – heart rate, cadence, speed, power, how many water bottles…. This year it appears to just capture speed (GPS driven) and location. It would be neat for the race events to publish this type of data for us data junkies to look at.
link to cyclingtips.com.au
link to dimensiondata.com
link to dimensiondata.com
I’ve often wondered why dirty tricks teams, dont sit on the other side of the ant+ data and start broadcasting their competitors power numbers back to their head unit changing the number by a percent at a time
A little bit off topic Ray but as a multiple PM user, do you know any software (free preferably) that’s capable of recording multiple ANT PM data? Suppose you’d like to record your 4-5 PM data directly on the computer (with the ANT dongle). Is it possible? I have a SRM and just got a Rotor Inpower for testing but only have 1 head unit. I’d like to record both on the same software…
Ray mentions the device he uses in the article (wasp)
If you have a ANT+ USB stick you shouldn’t have any problem. I think the current sticks allow eight simultaneous inputs and there’s no reason two can’t be the same type.
Golden Cheetah (free) could read the data fine, but I don’t know if it can display the data simultaneously. I wouldn’t be suprised if the numbers appeared in the Edit tab page, but if one power input wasn’t graphed. I can’t test it as only one PM. You could record one with the computer and the other with the head unit?
Another free alternative is to download the free ant developer software, but then you’d have to join the developer network (free) and turn the numbers into graphs yourself. As I have proven the usb stick can be put on the end of a USB cable and you can go out recording with a laptop in a rucksack (turn of the lid closing sleep function and consider a SSD). Then copy and paste the data in a spreadsheet and graph it
you can visualize and collect data from multiple ANT+ bike power meters with just an Android device, using the SelfLoops Group Fitness Premium app.
The application automatically gathers data from all the surrounding bike power meters. You still need to match the specific ANT+ ID to the rider, and if you do not know it you can use the methods nicely explained in this post.
IpWatt is another Android and free app to collect multiple PM datas link to play.google.com
And being on topic of “broadcasting” PM data, here a 1989 (yes 1989…) live PM data (the pioneer Look Max One) on TV, of course not ANT+ (LOL) but a solid cable to the head unit :)
Funny how 26 years after and with a lot more technology we cannot see anything remotely similar to this: link to youtube.com
IpWatt captures at most 4 sensors at the same time. The SelfLoops Group Fitness Premium more than 30 at the same time
Anything can be hacked. As you pointed out it comes with cost and complexity.
That said, I completely agree that competition data be open and understood not to be absolute. Training data, however, is a complete different story. Be it wide ranging set up and calibration differences, or just sequence and types of training routines, that data has a lot more variations and possibly prepares a rider better.
So while there may be some value in comparing open competition data, it seems less reasonable to ask a rider for all data that includes training data.
Ray, A wealth of intersting information once again. Thanks.
All of this reinforces the priority of consistency over accuracy in power meter data and training. If pro riders and their teams, and some of the best of them such as Froome and Sky, are perfectly fine with the high level of consistency (2% or better) yet built in “inaccuracy” of osymetric rings and left only power meters for their training and competition, certainly the rest of us can do quite well with them as well, thank you. The growing number of left-only power meters that are shrinking the price, growing the market and making power meter training available to so many more cycling enthusiasts suggests that suppliers and consumers are realizing that you don’t need to spend on the high price of SRM level accuracy to get the primary benefit of professional level consistency in your power meter training. Steve
Any review coming on the 4iiii prescion power meter, I finally got mine a couple of days ago but not had a chance to use it yet
Not at this time. They’re sorting out an issue that’s blocking my ability to test it (same for the last few months).
do you know roughly what chips the head units use now? I think the current chips used in the USB sticks have eight inputs.
I guess the minimum is four:
HRM
PM
Speed independent
Cadence independent
I was wondering if there would be any spare channels. I can see how it would be helpful to know your nearby competitors power output so you could see if they were weakening (eg Froome and Quintana on Huez) and you could get the screen to automatically display it intermittently.
If I was being cynical I’d suggest the teams have no interest in encryption because as it stands if it revealed anything odd they could always claim it was hacked
What about the gear control stuff though? Will that be brought into Di2? if so would that be encrypted? it would be more than irritating if someone moved you to the small ring during a sprint. I hope Di2 is well encrypted already.
You can put channels into a scanning mode, which is how the WASP is able to pickup data from hundreds of devices at once.
I’m surprised then that haven’t already taken advantage of this. It wouldn’t be that hard to find someone’s Ant ID and their FTP/lactate threshold HR and make them blow.
Unsportsmanlike, but that hasn’t stopped people before.
I hope Di2 is really well encrypted. There is very little on google about it. Given the battery limitations I wonder how much energy is expended on encryption.
Typo: “principal” should be “principle” in first para of first section after intro.
Thanks, fixed!
awesome topic!
Typo: INCREDBLY (in Getting two power meters to agree)
could be interesting if any of the TV crews decide to use something like WASP to collect and broadcast snippets of power data as the camera motorcycle crews follow riders around.
Great stuff Ray; love the podcast too.
So, you out-geeked me on the Power Meter discussion, although I managed to follow most of it.
I was just happy to get a “peek” at Geraint Thomas’ Garmin, just to see his choice of data fields.
Possibly more important would be to have the power meter provide a encrypted signature for the data so that it would at least be harder to modify the data after received.
Should teams lock down their data at all? It would be good from a spectator point of view to be able to see the full data from all riders after a stage. It would be even better if data such as power, HR, cadence could be overlayed on screen during the race, much like they do in F1.
I’d agree. I think the main concern above is actually the ability to specify offsets, which can heavily skew data without one knowing it. It’s precisely three taps to do on some utility apps.
….so as regards power meters it seems to me that the only thing that needs fixing is the ability to calibrate/offset without physical intervention on the bike.
seems fairly easy to fix in PM firmware (IMO). ie only allow a calibration/offset after backpedalling 3 times or some such method. I don’t see why we need anything more complicated than that.
Not even a cycling fan.. but had to read your write-up… as always.. brilliant!
extremely interesting and well written article and very much worth the time to read. However, it does absolutely nothing to get me my new garmin 520 any faster and I am so disgusted with poweragent on my windows 8.1 machine that I cannot wait to relegate my joule gps to my daughters bike or something. So I would appreciate it if you would spend your time pushing garmin to release just my 520 unit. hahaha
Yeah, first would be getting any Edge 520’s to ship…rumor is that might be this week.
Great write up on the data side! Guess I’m having a bit of trouble connecting the dots between data and intelligence here. What benefit would hacking other riders’ power meter data be? Sure, you could look at it and see why/how another rider outperformed you on a particular stage, but how could this be exploited on future stages?
Real time data would be useful to have more information about if/when your opponent is in the redline and plan your attacks. Not conclusive, as human body is a machine capable of superseeding itself, but could give valuable clues
More importantly would be changing the offsets without another athlete knowing. In a time-trial situation, with a small change (i.e. 10%), you could likely trick an athlete into going too hard/easy.
Come on DC Rainmaker, you can do better than your comment about “Providing ‘average’ data”…
The data provided by sky is about the last ascent and it is (as expected, they are not fools) in line with the “public data” posted in strava for example by Gesink.
So please don’t feed speculation without concrete info.
If there was a 10min difference in performance there could be a case, but we are talking about 1min in a 40min climb… So the peloton is all in the same boat…
Beep up the fabulous work! (i am a fan of your reviews)
A few things to consider:
A) What if instead of providing detailed power in power meter reviews I simply said “Well, they all average out”. Or perhaps “Well, it was close enough?”. That wouldn’t be very transparent, would it? You’d have no way of knowing whether they truly averaged out. After all, I could just pull this numbers out of mid-air to suit whatever purpose I wanted. Without the data behind it, it’s just a finger in the air scenario. It’s easy to be ‘in-line’. My review of the PowerCal proves that – it’s almost always ‘in-line’ when you’re talking long timeframes (more than a few minutes). So, 40 minutes is a complete wash. So if that was ‘good enough’, then why isn’t anyone using it? Because…it’s not good enough for most users, and certainly not for the TdF.
B) Going back to my note on what people would say if I just posted a total average. They’d say that wasn’t very transparent. They might say I was trying to hide something. After all, posting the actual data takes approximately 5 seconds. Is it foolproof? Nope. But, there are some smart people that can pick out fake data from real data. It’s harder than you think to fake power meter data. Just like it’s harder than you think to fake photographs when you get to the peak of ‘smart people’ who analyze that type of thing.
C) Ultimately, cycling has to prove themselves as clean. It’s not just a Froome problem, or an Armstrong problem. It’s a full sport problem. Do I believe the peloton is clean today? Not a chance in hell. Do I think the majority of riders are clean? Perhaps. Do I think there are some clean riders at all? Yes. In this specific instance, ‘clean’ means both avoiding drugs as well as mechanical cheating. Ultimately, I have zero trust of pro cycling. There’s no reason why I should have trust in them. Every year they collectively show they cheat. I want to believe, but there’s ample evidence I shouldn’t. Just look at the current UCI suspenion lists. Seriously – they are massive:
link to uci.ch
link to uci.ch
D) So many other teams are posting race data. I don’t think anyone is asking for training data – there’s valid reasons why you wouldn’t share that. But for not sharing race data, those reasons start to dissipate.
E) We should have learned something from Lance – and everyone else in that crowd (do remember, while Lance got long-term nailed, all the other top-tier riders simply got passes and a short suspension in the off-season in exchange for their assistance in cooperating). That group of people (riders/managers/etc…) still exist in these organizations. Do you trust that 100% of them are riding clean? If so, see the section C lists for why you shouldn’t.
F) Giving power meter data isn’t a panacea. It’s just another data point to add to ones portfolio, just like the Bio Passport program.
Just my two or twenty cents.
Thank you for the cents :) we agree, as i said “the peloton is all in the same boat” and it is not a clean one.
My point is that given the public data that already exists, using the time difference and weight you can estimate the power, i did it and the difference was 2w. It was 1 min dif not 10 or 5…
Cheating will not be caught with race power data. I think these days “professional cheating” goes more during training than when racing. And it will get worse as the fusion of biology and computers goes deeper. Interesting times :)
Great work Ray – thanks.
Would you go a bit deeper into the differences between ANT+ and private-ANT? In particular for SRM?
Whatever the Pros need to do to “protect” their data. Have at it. But, please don’t complicate my ant+/garmin world with unneeded protection and add costs/complexity. I don’t worry if someone wants to hack and see my 150 avg watts…
Your comments on trusting cycling are sad but true, thanks for the detailed article, avg data = no data
Pertaining to sucking up data via the WASP device and calibration. Isn’t the offset stored in the head unit itself? So if you are listening to the raw ANT+ data you need to convert that into power which requires knowing the calibration value? If I understand things correctly the PowerTap for example doesn’t send the number of watts itself, it sends the torque and RPM values and relies on the head unit to convert that to watts.
Yiu can put a “waps in the middle” that reads power (or torque) and reduces 10% and resends the fake value with same ant id. Devastating effect!
Real life example:
The other day i was testing Vector 2 pedals doing a 25min climb at ftp. Bpm roofed and i blew up and thought i was so weak. When i arrived home and compared the rides the powermeter was reading 35w too low!
“While you can certainly look at Team Sky and say “Well, Team Sky has won the TdF on it”, the reality is that’s marketing and sponsorships for you. Don’t overthink it.”
I don’t buy this. Team Sky spends millions in testing, planning, R&D. Then, because of a sponsorship from a small company, they’d risk such a vital source of data that could effectively cause them serious trouble not only during training but also mid-competition?
And if this makes so much sense, why does it not apply to Cannondale-Garmin’s decision not to use the Vectors and going out of their way to buy SRMs?
Follow the money
More: That small company is backed by people with tons-o-cash. They paid dearly to sponsor Sky and it’s a solid marketing strategy.
Hats off to Stages for landing it, job well done.
But…from a pure data standpoint, it’s not debatable. Left only power meters leave out data, the impact of which varies from rider to rider.
As to why Sky doesn’t think truly accurate power data is valuable in racing…not sure. But, I would suspect that Sky’s recent use of new prototype dual left/right Stages units is probably why they were willing to overlook it for the first season (or demanded better data for the 2nd).
Oh, as for Garmin…that’s mostly just a story of stupidity (or lack of balls). When your name is on the side of the team, you use the products and tell your mechanics to get over it (had less to do with riders). From a business standpoint that’s mind boggling to me. My understanding is the allowance apparently came from some grandfathered contract…but still, stupid business practice.
From a product review/accuracy standpoint, promise really doesn’t matter or prove/disprove anything.
Sky will have validated the Stages meter – comparing it against Left/Right power meters to check the riders’ balance. And they must have found that the measured values are consistent and usable for training and racing. I’m sure it would have been helpful to them that the Stages meter is a lot lighter than most as well.
Who are those people btw?
Ray, it still doesn’t make much sense. Team Sky’s budget is around $38M/€31M. Is a powermeter sponsorship worth this in their big scheme of things? Their TT frames alone cost more than most TT complete bikes other teams are riding and they demanded exclusivity of it for half a year or something. Then when it comes to powermeters they’re going for a whole season with something they can tell it’s subpar (and prone to failures while at it) while coming down from SRM no less? And it’s known how heavily they rely on power data for their training (and racing I’d assume). This is 5th Dimension-type stuff.
Fair question asking where the money comes from. Aren’t some component sponsorships hardware + cash? Maybe Stages made a more attractive offer, and this helps cover part of the overall budget. Think I remember a while back that SRM cut back on how many teams they fully sponsor, it’s around 8 now. Think that was the same time that Sky switched to Stages. Other teams that want SRMs pay for hardware & servicing.
Ray asked a lot of these questions a while back:
It’s definitely a valid question – and one that I’m not honestly sure anyone has a 100% clear answer. Sky has noted in the past they they’ve done some comparative testing with their previous SRM units, especially in the first season. They said at the time they believed to map out the left/right offsets of each riders. But I suspect they meant that they just mapped out ride averages for left/right. The problem is that ignores aspects like differences at power levels at differences with fatigue. Even if they did start to map that out, it wouldn’t help the riders much unless they memorized the offsets (seems complex). Given they are using Garmin head units, there isn’t a way to have it automatically recalculate that on the fly for the rider.
If I were to take a stab at things, I’d guess they Stages managed to convince them early on that the numbers were similar – prior to having a ton of data on the nuances of this. Past interviews with Team Sky has somewhat alluded to the speed in which the original deal come to fruition (which was actually led by Team Sky). Then, at some point along the way, they may have pressed Stages for a full left/right solution. We’ve been seeing Team Sky test that since at least this past spring (possibly earlier). This would resolve the left-only challenges.
And of course in a situation such as Team Sky they’ve have very few (1-2 if that) crank/bike types to deal with from a compatibility standpoint, which is Stages hardest challenge. By effectively minimizing that, it makes Stage’s work reasonably simple since they’ve done so much of the hard work already. Now it comes to taking what they have and applying it to the other side, which again, assuming they don’t run into crank/bike compatibility issues makes their life fairly straight forward.
Ultimately, it doesn’t really answer why Team Sky went down the left-only path initially, since even if you account for the costs of buying SRM units – that’s relatively trivial in the grand scheme of things.
Glad I’m not the only one scratching my head about this. Not so glad that this doesn’t really help a consumer make a decision on which powermeter to get based on what pros use.
Nice little ‘sub-discussion’ though :)
Sigh, messed up the link:
link to dcrainmaker.com
Nice insight into that time of trasition, thanks.
I am getting a Pioneer power meter installed with the Pioneer SGX-CA500 computer. My main reason in going with Pioneers’ computer is for the 12 point pedal smoothness/efficiency feature and the Di2 intelligence. Before the power meter, I had been using my Garmin 510 for speed/cadence & basic data with a Garmin HRM. I know that Garmin is ANT+ but Pioneer is not (I think it’s either Bluetooth or private ANT). With that being said, can I still use my Garmin HRM with the new Pioneer power meter, or will I have to buy a Pioneer HRM? I hadn’t though of this before, but if this is the case, I would then have to swap HRM straps on my transitions from the bike to run on my triathlons in order to sync back up with my Garmin 920 watch. I pick the bike up from the shop this weekend. Any advice is appreciated.
You can use Garmin’s HRM.
No problems with the Garmin HR straps, it’ll pair easily to the Pioneer head unit.
Whilst I find this all very interesting, the fact is, some people will not have the best power figures, the best HR data or so on. What is left to see is that some riders can suffer beyond what others can, some can race smarter than others, some can use a course to their advantage and have better bike handling and or skills.
I have been in races where the others guys are certainly fitter, lighter, stronger than me, but you cannot outfox someone who has race craft. Pure and simple. I get it that you are talking about data security, but reality is, even if the winner of the race doesn’t have good data on paper, he is still the winner. And at the end of the day, that is what counts. I hear guys bragging of this and that when it comes to power, HR, yadda yadda yadda, but they have never won a race in their life.
Same said about the guy’s who love to smash the bunch up out training and brag to everyone for weeks about their training rides and sprints for an invisible non existent world championship, but they have never won a real race.
“even if the winner of the race doesn’t have good data on paper, he is still the winner.”
You’ve missed the point.
Said data can in certain cases (such as mountain stages) point to doping or cheating. Especially when power figures show non-human efforts.
Is it only WASP that can collect readings from more than one powermeter or any other apps or software?
Would like to compare my Vector with an Powertap wheel.
I can always do it in excel but it gets a little bit simpler in an app.
I only noticed this while adjusting the training display in Golden Cheetah amongst the option for display is an option for an alternative power. I’m guessing that means it can show two power meters… I only have one so I can’t test it though. If you already have an ANT USB stick then that is potentially a free option.
Mainly it is for indoors though, although I have successfully been for a cycle with a laptop in a rucksack.
I’ve been reading for looong time… but can’t find answer to my question… I have two bikes: road (mainly training) and TRI (mainly racing). They have completely different setup, specs… I want to start training with power meter but the cheapest option (not sure if the best) may be to buy two different power meters. 4iiii for road bike and powe2max for Tri bike.
Is it a good idea due to the possible power reading difference between two devices?
Thanks Ray
I’ve got INpower and checked the calibration several times
I’m generating 10-15% more power than fellow club members but nowhere near the speed during a TT
Weight plays a part and my aerodynamics are not as good for sure but I am questioning the accuracy and comparability of the reading
One theory is that I have had an old injury on my right hand side which perhaps means I am generating more power through the left hand side which is obviously where the reading is taken. The obvious test of this is to sit on a set up which gives left and right hand balance but will this tell me the whole story and what recorded level of Inbalance would account for a 15% power ‘shortfall’?
Cheers
Hmm, that’s a super-tough one. Injury would definitely account for that, no doubt there, especially since it would really only take about a 5-7% difference when doubled to 10-15%.
I’d see if you can borrow someone’s PowerTap wheel for a short ride. Though, you’ll want to ride more than just 2-3 minutes, so long enough that your body isn’t subconsciously hosing anything up.
Ray, this is slightly off-topic and on an old article, but I’ve long been curious about how teams can manage to distinguish between the multitude of ANT+ transmitters they have at any given time? For one, consider a race scenario where a rider has to change bikes, or even swap bikes with a teammate – does he then spend the rest of the race staring at his teammates power numbers, or maybe nothing at all? Even in a stage race, when you could ride half a dozen different bikes (TT, climbing, aero, spares, etc.) over the course of a few weeks, plus changing out cranksets or other parts from day to day, it seems like a massive undertaking to always be 100% sure that every one of the hundreds of ANT+ devices used by a team are always associated with the correct rider.
My first thought would have been to just leave a head unit always associated with each bike, but from what I’ve seen from watching races, for whatever reason, head units seem to always stay with the riders right up until they mount their bikes, as opposed to being something that mechanics deal with – although I could be wrong about this. But at the very least, you do always see spare bikes come off the team cars without head units, and the rider moves his head unit to the new bike before continuing. This would also obviously impact heart rate straps which are not attached to a specific bike.
Generally speaking most riders have a specific bike they ride (name on it and all), and of course, their own head units they guard quite carefully.
The question then becomes how to handle spares. From what I’ve seen, not all spare bikes even have power meters. So it may not be a huge issue per se.
Technically you’d have two options:
A) Simply have the ANT+ ID listed on the handlebars somewhere to manually enter (just 4-5 digits).
B) Have the spare bikes already paired to the various bike computers, so that if a spare was picked up, it’d default to that should the original bike PM now be around.
I’ll have to do some digging on how it’s handle as far as pairing and handled for swaps. Interesting question. I’ve never seen bike computers on the spare bikes.
Interesting, I didn’t know about spare bikes not having power meters. I suppose it’s less of a big deal in a typical stage, but I’m sure even a spare TT bike would have a power meter, as that’s such an important part of pacing oneself. Although to be fair, if you’re having to switch to a spare TT bike, your race plan (and prospects) are probably going to be significantly changed anyway.
Putting the ANT+ ID on a sticker on the handlebar is a really simple and elegant solution – that makes a lot of sense, and I hadn’t thought of that.
Can an ANT+ ID ever be changed relatively easily? What would be more interesting is if team mechanics had a way to change ANT+ IDs such that a particular ID could always be associated with a particular rider, even if mechanics need to swap out power meters between stages. I’m just imaging a scenario where, over the course of a full season or more, the teammate next to you just happens to be using the left crank arm (and thus, the Stages PM, to take Sky as an example) that you used on your training bike during the winter, and so you’re getting his power data instead.
No, the ANT+ ID’s are baked at the factory. No way to change them by a normal consumer. It’s possible that if a team had a partnership, they could probably get a special firmware updater to set that. I vaguely remember having such a tool for one sensor company a few years back that I was testing. Can’t remember who or what device it was.
Instead of having to pair their head unit to the spare bikes power meter, maybe the team has a sticker on the handlebar that can identify the bike and then the rider selects that specific bike profile on his head unit. It was already paired and saves the hassle of pairing in the middle of the bunch where they would find various power meters and be forced to type a sensor ID number while riding. I think it would be easier to have various profiles matching the various spare bikes, and even teammates bikes.
why don’t pros use pedal power meters? Is it a sponsorship thing, or something technical.
Mostly sponsorships..
Garmin did sponsor teams way back in the Vector 1 days, but that was a poorly managed sponsorship from the beginning. Some athletes were allowed to opt-out (due to a variety of reasons, mainly conflicting individual sponsorship and other pedal choices). and then mechanics cited installation challenges as a reason they didn’t want to deal with it (remember, this was when you had to use a torque wrench to get things right). While that may be the case, that again to me points to poor sponsorship management.
Hi Ray,
Any chance you could please comment on the difference in data transmission rates between the two protocols? I understand Bluetooth can be faster, however what does this actually mean in the real world? Does this mean if the source/powermeter was capable of transmitting more data to the head unit/destination? Would this manifest in more accurate numbers given a larger sample? How do head units deal with more data? Or is this rate limited from the sources to avoid this?
Cheers
Dang