• Increase font size
  • Default font size
  • Decrease font size
Home Reviews Power Meters Cycling Power Meter Review - Power Meter Review pg 2

Cycling Power Meter Review - Power Meter Review pg 2

E-mail Print
Article Index
Cycling Power Meter Review
Power Meter Review pg 2
Power Meter Review pt 3
All Pages


Since the original version of this power meter review published in 2003 (where I simultaneously rode with a SRM/PT/Polar) I’ve purchased a used SRM Pro, and a used PT.  More recently, I purchased a used ibike GenII that was subsequently upgraded to a newer version.  Over this time, I’ve gotten to know the ins/outs of the power meters in this review.  Rather than going into a full blown file by file investigation, I’ll simply try to highlight some of my thoughts and provide specific examples where necessary.

I’ll do this under the framework that people generally make their buying decision based on price/performance/durability issues…with a bit of emotion thrown in!

The systems evaluated range in price from $249 ibike non-downloadable sport version up to $4250 for the top of the line wireless science SRM with pc7.  For the purposes of this review, it was assumed that one has no pre-existing hardware on the bike (i.e, the consumer is starting from scratch).  Ratings at the end will be given on a scale of 1 to 4 (1 is poor, 2 is fair, 3 is good, 4 is excellent).  The SRM that was evaluated was the Pro Model.


Summary: SRM’s are expensive!  The used market is also a great place to find a value.

From doing a bit of research on the topic of power meters, the question that seems to be on the top of everyone’s mind is: which system is most accurate?  Unfortunately, since access to an external dynamometer was not available, this question will not be answered here.  It is, however, possible to make some observations about how the data from each of the systems compare to each other.  Furthermore, it should be noted that no system will ever be 100% accurate, as there will always be some uncertainty associated with the measurement.  And finally, I think a prudent way to look at these kinds of things is to put the data in context and consider the question “is the reported power measurement good enough” to train by? 

Additionally, it can even be argued that absolute accuracy is not an issue, but rather, consistency over time or measurement repeatability/precision is most important (this approach seems reasonable if the same unit is used over time, but may be an issue if one decides, or needs to, change units at some point – then accuracy and precision both become important).  Regardless of which side is taken in this debate, there are also other factors to consider when evaluating the performance of power measurement systems.  The variables selected for this review were: ease of installation/adjustment, overall added mass, data quality, and software capabilities.  Ratings on a scale of 1 to 4 will be given in each of these categories and compiled/tabulated at the end of the review.

Ease of Installation/Adjustment
Though it is an extremely small percentage of the overall life of the product, the ease with which the system is installed and adjusted can immediately affect post purchase perception of the product.  A manufacturer survives in the long term by receiving repeat business, and anything that colors a consumer’s perception negatively can have an impact on future purchases.

An impact on accuracy of the system can also be affected by the amount of consumer input during the installation process.  The best installation is one that minimizes the possibility of error by the consumer.  An analogy can be made to the computer world – the best peripherals are the ones that are “Plug and Play”.  The end user simply plugs it in and it works as desired.  There will invariably be some problems with some users if one has to search for drivers, cables, mathematically derive inputs,  or measure additional variables etc.

Power Tap
The PT system is just about as close to “Plug and Play” as one can get.  The straightforward steps of installing a cassette and a tire on the wheel built with the PT hub are nothing too difficult for your average bike racer.  Once these steps are accomplished, one must simply drop the wheel in the dropouts and install the receiver and CPU mount with the supplied zip ties.  The whole process should take 30 minutes at most.

The SRM installation was only slightly more time consuming.  The cranks currently installed need to be removed and the new ones (both left and right) supplied by SRM need to be installed.  Prior to installing the SRM crank, though, a chainstay sensor needs to be installed as well as the front fork speed sensor.  The rubber band style of mounting the sensors makes it easy to adjust or even move the entire system to another bike.  After the two sensors were mounted, the process was completed with the installation of the right crank.  Installation took approximately 45 minutes and did require the ability to remove and install cranks.

Positioning of the crank pickup sensor can be a bit cumbersome on the new breed of bikes.  In fact, the placement of this sensor may even require specialized hardware depending on how beefy your bottom bracket is.


The Polar installation was a relatively painful operation.  Most of the anxiety involved in the installation arose from plain old uncertainty – was I doing it right?  The most tedious part in the installation was in adjusting the height of the chain frequency sensor.  It needed to be raised, lowered, and leveled multiple times while troubleshooting some erroneous power readings.  There is also a chain speed sensor that needs to be installed.  This required removing the bolt from one of the derailleur pulleys and installing the one provided by Polar through the attached chain speed sensor.  The cabling to this sensor must be adjusted to make sure it is not damaged during normal operation of the derailleur.  The image below shows the installation used by the Polar folks in their booth at last year's Interbike show.

The speed sensor must also be placed on the opposite chainstay using zip ties.  This was a straightforward operation – just be sure to route it and tie down the cable so that it doesn’t interfere with the tire.

The cadence sensor provided also did need some special attention when used with the Shimano Ultegra cranks I normally use on my bike.  The sensor needed to be rotated drastically inward and often times rubbed the chain when in the 53x12.  It simply did not want to stay in place, no matter how hard I cranked down on the zip tie.  The main problem with the sensor was that the sharp angles of the crank did not match well with the cadence sensor base.  A simple v shaped base might make this sensor more adaptable to varying crank geometries.  However, when used with the SRM crank, the cadence worked perfectly.  Complete installation took the better part of a Saturday morning (3-4 hours) and subsequent tweaks to troubleshoot some erroneous readings added another hour or so.

The erroneous readings that were noticed while riding were obvious.  On the initial setup, while riding along on a relatively level grade and shifting through the entire gear range in the big ring, power stayed constant.  When I shifted into the 53x21 (I run a 23 in the back, so this was not the most extreme crossover possible) I observed a 40 watt increase in measured power.  No matter how the chain frequency sensor placement was adjusted, (raising, lowering, leveling, rotating, translating) the same phenomenon occurred.

As a last resort, I swapped out the chain for a longer one and the problem vanished.  I can only speculate that the tighter chain originally used was creating an effectively shorter unsupported chain length (due to more friction between chain and gear teeth) and, thus, the higher vibration frequencies (measured power) observed.   The problem might also have been resolved by tweaking the chain speed sensor orientation, but that variable was not manipulated at the time.

The main thing to take away from this is to test out your installation before getting real comfortable with the setup.  Do this by riding along at a relatively constant speed on level ground and shift through the entire spectrum of gears.  Obvious problems should be readily apparent.  Be patient with this system, one can get good results if due diligence is done.


The ibike hardware installation is _seemingly_ fairly simple and straightforward.  I used the provided stem mount that bolts on and had wireless speed/cadence sensors that were zip-tied to the bike.  A separate crank magnet was also installed. 

My perception of the stem mount was that it felt “cheap”.  Plastic injection molded bits and low grade, easily deformable, screws with pressed in threaded inserts left me feeling a bit hollow as a mechanical engineer by trade.  Initially, I couldn’t get the screws tight enough to prevent movement during big hits on the bike, so I eventually added double stick foam padded tape in between the stem and the clamping hardware.  This seemed to solve many of the initial issues I was having.

You’ll note that I used the word “seemingly” above when describing the ease of installation.  I am revisiting that comment simply because during my evaluation of ibike unit #1 (an ibike genII) my ability to install and set up the unit was more than likely doubted by ibike.  It was so much in doubt, it seems, that ibike actually flew one of their guys across the country to make sure things were properly installed and configured.  I was glad to have that kind of support, but really, if a hands-on mechanical engineer (that’d be me!)  can’t properly set up the unit, what chance does a more typical end-user have in getting things right in the eyes of ibike?

As it turns out, I was installing the unit properly…  Whew!!! That was a close one, since it would have been really embarrassing to have to tell you all that I wasn’t capable of installing it correctly.  :-)

The second step after the hardware was installed was making sure that the appropriate mathematical constants were being used by the head unit.   First, you’ll need to make sure you have an accurate “all up” mass value (this is the total mass of you, your bike, clothing, spares, water bottles etc..).  Next you’ll have to make sure you have accurate CxA (axial force coefficient area) and Crr (coefficient of rolling resistance) values. 

There are two ways to set up the head unit with the proper variable constants of CxA and Crr: 1) Fast setup method (which uses height/weight and a formula to assume a Cxa and also assumes/allows user input for Crr) and 2) user conducted coast-downs to empirically derive Crr and CxA.

After having done 40+ coast downs in varying conditions with the ibike, my advice is to punt on this method and rely on the fast setup numbers – the coast down data I generated was basically worthless.  I was in a better position than most when judging the quality of the coast down data simply because I’ve done field testing to ballpark determine the Crr for the roads and tires I use in training/racing and have tested my position in a wind tunnel many times.  And, as a result, when the ibike put up silly coefficient numbers, I could easily recognize that something was amiss.  It’d be nice if the ibike software had some sort of quality assessment feature that would let users know the “goodness” of their field coast down data.

The last portion of the process is to do an out and back ride so that the wind speed sensor can be calibrated/scaled.  Since the wind speed sensor measures stagnation pressure, it must be calibrated to the specific setup on your bike and to how you predominantly sit on your bike.  For more reading on stagnation pressure you might consider checking out this article:

The calibration of the wind speed sensor requires you to ride an out and back route.  Then some math is done (by the CPU) such that settings are tweaked in order to make the distance averaged wind speed net out to zero.  That sounds complicated, but it really just means that the average relative wind speed on the “out” leg is made to match the average wind speed on the “back” leg.  This approach yields accurate results when wind speed is constant – so make sure the wind doesn’t shift, or you don’t ride in an area where traffic patterns are asymmetric.  I’m not sure how one assesses this kind of thing (asymmetry of traffic or shifting wind conditions), but just beware!

An interesting sidebar (or maybe not), but the ibike rep set up a couple of my bikes.  One bike was set up with a stem mount and the other with a bar mount.  The wind speed correction factor was nearly an order of magnitude different for the two different configurations.  The crazy thing, though, for me, was that the longitudinal difference (front/back – fore/aft distance) between where the two stagnation ports were located relative to my center of mass was maybe 5-10 cm.  That’s seemingly “crazy” to me, simply because the range of where I sit on the saddle during a race/ride is on that same order of magnitude of 5-10 ish cm.  Is the reported ibike wind speed that sensitive to the relationship of the stagnation port and my center of mass?  The answer to that one will require more work on someone’s end (sorry, but I’m not that guy! ;-)  )

So, now we’ve got multiple layers of user-defined/reported values at play here with the ibike.  Remember what I was saying earlier about setup and being robust to user input?  With so much end-user reliance and interaction on setup, the easy route to take (for ibike) when it comes to explaining away bad data will generally be focused on the user.

Installation of the hardware and getting the math coefficient values inputted properly, however, is not the most painful part of the process.  The hard part is in convincing yourself that you’ve done everything right and that the numbers flashing on the display are good enough/in the ballpark of reality.   Without a calibrated, trustworthy PM to compare against in a variety of use-conditions, I’m not quite sure how this can be done reliably.  I think the best way to independently check a portion (i.e, mass and rolling resistance and accelerometer performance) of the ibike input variables is to validate things using a stopwatch, an accurate scale, and a steep hill with known, accurate elevation gain combined with an online calculator such as the one found at:


Aside from that, you’re on your own!  ;-)

Summary: ibike and polar are tricky to set up; SRM and PT are much easier.


The scale doesn’t lie.  It should be remembered that power measuring systems are not essential and any additional weight added to the bike negatively affects overall performance – though, at these levels the added weight has a small affect on performance.  This weight penalty, of course, neglects any gains to be had by training with a power meter.


Here is the good part!  Let’s take a closer look at an estimate of which system has the potential to be the most accurate.


A common practice in any experimental design is to do an uncertainty analysis on the instrumentation used.  The results of this analysis will show how good the results are, or what claims can be made based on those results.  If the uncertainty is only plus or minus 20% and one needs +/- 1% to answer a question, the source of the error must be identified and corrected. 

Uncertainty of the instrument is a function of all the parameters used to calculate the parameter of interest.  Essentially, the fewer things that need to be measured and the lower the uncertainty of the individual instruments used to compute the quantity of interest, the more accurate the measurement will be.  I will spare you the gory details.

It should be clear that the PT and SRM have fewer fundamental sources of error than the Polar system, and all of those have fewer sources of error than the ibike.  It can also be speculated that the largest source of error on the PT and SRM will be in the calibration of the strain gauged structure, whereas the largest source of error in the ibike could be the reliance on the user to provide accurate inputs for the equation of motion (of which there are many!), or maybe the accelerometer.

PT units can have their accuracy checked by the user doing a static torque test.  The SRM goes one step further, and allows the end-user to easily change the factory calibration values in the event that the original system calibration has drifted with time.  It is recommended that users do a static check on their PT and SRM systems during the initial installation and at least every 3 months to make sure that the system is stable.  Checking the systems statically requires a time commitment, but it is helpful when analyzing long-term power output trends – e.g.,  did you really increase your 20MP by 10% since last year, or did your power meter drift?  Static calibration will lend some insight into the answer to this question.  Unfortunately, the ibike doesn’t really provide a way to consistently check that things are well-behaved as a function of time.  In fact, when you change your tires (even if they are the same brand) you’ll more than likely have to adjust the Crr values that the ibike uses to report power.

Average Power

While reviewing data from all my experiences and normalizing (side note…It’s crazy to think that I used the term normanaliz* power in a bike related context on the interwebs first… LOL!) how the average power is calculated, (dealing with how zeros are handled) it’s generally true that most power meters will converge to a relatively small power value range as the time-span of interest increases. 

Over shorter time periods, the units will differ slightly (or significantly as the case may be), but over longer periods of effort/duration (on the order of 1+ hours), they will all converge (+/- a reasonable amount) to what the equation of motion (with the correct inputs for continuous speed measurement and elevation change – i.e, the kind of information that you could download from a polar HRM in the mid 1990’s – I regularly used a polar xtrainer-xl in those days that provided this info) for a cyclist reports.

Takeaway:  if your minimum duration of interest is longer than an hour or so, and with good data for speed, elevation, and reasonable CxA and Crr/mass estimates you can pretty reliably assess the KJ burned/average power over that duration with or without a power meter.  The power meter makes it easier, though!

Somewhat as an aside, it has been my experience that on a watts/kg basis using a steep hill, stopwatch, and an accurate bathroom scale, power meters (even the SRM/PT) are really no better at assessing the power output to climb the hill (and that the ibike is actually worse than a stopwatch) And, dang, it’s tough to beat a stopwatch and a scale when it comes to assessing power on a “value” basis, eh?

The key takeaway for me is that as your duration of interest decreases, the better off you will be with an SRM or a PT; and if the duration is short enough and on a steep enough hill, heck, a stopwatch and a scale are just as good as an expensive PM!  It’s those free-ranging ‘tweener rides where a power meter can add additional information that may/may not be useful when looking at the efficacy of your training program.  Generally, though, a safe recommendation would be to steer away from the ibike if you want to have actionable information for time periods less than an hour or so, and rest assured that the PT/SRM are pretty solid over a wide variety of conditions and environments.

Peak power

Peak power measurement accuracy is primarily driven by how long of a sample period the data is averaged over.  Therefore, the PT and SRM are relatively similar, since the reporting intervals are 1.26 seconds and 1 second respectively.  On the other hand, the Polar unit only reports data every 5 seconds and naturally has a much lower peak power reading for similar efforts.

The above plot shows two five second sprints done.  The Polar under-reports the first effort by 50% and completely misses the second effort.

Here’s an example of how the ibike does with a slightly lower power level sprint (I must have not been givin’ it my all this day!)

The longer the duration of the effort, in this case 10 seconds, the more closely the srm, pt, and polar systems will match each other.  The same trend is generally true for the ibike vs srm comparisons done in my experience.

Data Peculiarities
The most concerning thing that was noticed while using the PT, SRM, and Polar systems was while riding a trainer.  The SRM and PT units tracked each other quite well independent of whether the power or cadence was held constant during a gear sweep.  The Polar unit exhibited erroneous readings when in the smaller cogs in the rear (for both large and small chainring).  These elevated power readings for the trainer workouts also show up in the “on road” power, but the on-road discrepancy is of slightly less magnitude than the trainer discrepancy.




If one does a lot of riding on the trainer with the Polar unit, a brief sweep of all available gears should be done at a constant power to determine if any of these peculiarities are present.  Stick to the gears that give the most consistent power readings during your workouts.

Unfortunately, I didn’t have the desire to ride the trainer this year in order to see how things sorted out for the ibike.  As a result, I can’t really comment (with data) on how the ibike performs on the trainer.  I would say, though, that the SRM/PT will be pretty accurate and repeatable, whereas the ibike will have some challenges, but might get the right answer with their additional trainer firmware update ($40 upcharge).

When comparing the ibike to the SRM, additional peculiarities not mentioned above were noticed.  I don’t generally ride in the rain, but when I’ve been caught in a storm my SRM has continued to work.  Out of blind luck and during the period I was evaluating the ibike, I got caught in a thundershower.  It seems that the road spray or maybe an errant rain drop fouled one of the pressure ports on the unit and for the remainder of the ride I was unstoppable - putting out nearly 2000 watts!  It’s possible that the ibike won’t work as desired in wet conditions.

Furthermore, as mentioned previously, the ibike uses an accelerometer to help measure power.  Unfortunately, it seems that during out of the saddle efforts, the bar/stem mounted system gets pointed upwards more often than it gets pointed downwards; this asymmetry in orientation will lead to inflated power values.  Here’s a screenshot that demonstrates this phenomenon (green trace is SRM, black trace is ibike in the top panel):

You can convince yourself that the ibike unit gets pointed upwards for a portion of the time for out of the saddle type efforts on steep climbs by going to your bike, leaning it to the right and then turning the bars to the left.  See how the ibike sensor is pointed upwards?  The same is true when you lean the bike to the left and turn the bars to the right.  This is the orientation of the bike around the time one “flicks” the bike at the bottom of the pedal stroke when climbing at your limits out of the saddle on a steep climb.

Another peculiarity with the ibike that generally makes it unusable for me, as on on-bike tool, is that it seems to be influenced by environmental conditions.  I regularly ride on hilly, twisty, and variable road surface conditions.  This ride was typical of my experience when riding with the ibike and SRM installed:

the green trace is the SRM, the black is the ibike.  These wild fluctuations on the ibike would happen regularly and the magnitude of the deviations were so large that I could just tell by feel (no need to even look at the SRM or do complicated post-ride statistical analysis) that things were not working as intended.  As an aside, the ibike crew, in total, sent me something like 4 units and had me test on a couple different bikes.  The plot above is representative of all those units/bike configurations (and they set the units up on the bikes for me and even went on a couple rides with me to ensure that there were no shenanigans).

I think even for that ride depicted above, though, that the total KJ’s and average power were within acceptable, ballpark ranges, so that was good.  The ibike did seem to “work” for chunks of time, which demonstrates the potential of the approach, but the systematically erratic readings quickly eroded my confidence.

I’m pretty convinced the root cause of failure with the ibike is a hardware issue, and no amount of signal filtering/firmware updates will fix the problems I was personally experiencing.  I’m also pretty sure I know exactly how to manipulate/mess with things in order to cause these giant fluctuations:

…see those ibike (white line) square waves which begin at km 3.4 and persist until 4.6 km?  I was purposely controlling that while seated, grabbing the tops of the bars with both hands, riding a straight line, not swerving, and maintaining a relatively constant power as shown by the SRM trace.

It is possible that I am a unique case, and I’m sure there are plenty of people that have gotten reasonable results from the ibike over their durations of interest; but, that was not my experience.  I am hopeful that the ibike crew will resolve things…though, my days of doing free ibike product testing are over.


I didn’t fully explore all the details of the individual software packages, but I did use them enough to notice some differences.  All of the systems do the basics, and each of them has some additional features that I would probably check out once or twice but never use again.  For example, in the Polar package, the left right pedal balance is interesting, but not something I’m going to regularly check out. 

The ibike has many post ride analysis features that sound good in theory, but fall short in their usability (TimeAdvantage/dynamic CxA).  That said, the ibike software package is by far the most feature rich of all the bundled systems.  In fact, the feature I used the most was the synching/overlaying of multiple power files – that’s a pretty cool feature!

The SRM has some more serious data reduction methods and has a good power distribution histogram feature.  Some screen shots are shown below:

PT screen

Polar Screen Shots

SRM Screen Shots


The downloading process is relatively painless for all three systems.  All systems now use a USB cable that attach your device to your computer for downloading.

Download speeds did seem slow for the ibike compared to the SRM (I think I clocked roughly 2x slower for the same ride) – this isn’t a biggie, but I figured I’d mention it simply because I noticed the slowness.  File sizes are also quite large for both the PT and the ibike (comma separated text files), whereas the binary versions of the SRM file are much smaller.  Again, this isn’t a biggie since 1TB hard drives are getting to be very cheap these days, but if you do a lot of emailing on a slow internet connection, file size can be one of those aggravating details.

When it comes to software, it should also be noted that many folks are now opting to buy third party software at the same time they make their first power meter purchase.  Before purchasing something like RaceDay, or one of the trainingpeaks products, I’d recommend you use your power meter for awhile and check out the open-source application at or the software that comes with your device.  A lot of the third party packages suffer from feature creep – lots of bells and whistles, but nothing revolutionary in their approach.  It’s really tough to beat the simplicity and configurability of the SRM periodic bar chart when keeping tabs on global durations of interest and KJ’s burned:

Summary:  the SRM and PT will provide reliable data most often.  The polare and ibike have some peculiarities to be aware of.


The most robust mechanical systems strictly adhere to the KISS principle of design.  KISS is an acronym for Keep It Simple, Stupid.  A principle component of this concept is in the minimization of parts in the assembly - the fewer the parts, the fewer things that can possibly break.  For the most part, now that the systems are wireless, the number of parts have been reduced from where they were in the early 2000’s.

Number of parts
Ibike has the fewest parts, since it’s specialized sensors and display are housed in the same unit.  Otherwise, it’s the PM platform, transmitter, and CPU for all systems.

Water Resistance
Prior to being purchased by Graber/Saris, the PT units had an extremely poor reputation when it came to being watertight.  Allegedly, the hubs leaked like a sieve.  The folks at Graber/Saris seem to have resolved most of these issues now, though.  But, making rotating parts waterproof is a difficult challenge.  Using O-rings and labyrinth seals is a step in the right direction, but when these rubber surfaces are in motion, they will eventually wear out.  Keep up with the seal maintenance on your PT! 

The ibike unit does have open ports to the environment that did get fouled in the rain, but once things dried out it seemed to be back to normal.

CPU Mount Design
The Polar and SRM units appear very robust in their mechanical design.  The SRM mount is a thick walled dovetail interference style joint, and the Polar is also a very thick walled and beefy looking mount.  The SRM mount has no other purpose than to simply hold the CPU – the plug from the hard-wiring goes directly into the CPU.  If the mount gets broken, there would surely only be a small replacement cost.  Since the Polar uses a plug to interface with the on-bike sensors, the faulty parts can also be replaced in a modular fashion.

There are at least two potential durability liabilities with the PT design, including a thin walled CPU mount – I could see some of the tabs failing with this particular design – and an integrated mount/wiring design.  If the mount fails, potentially, the whole receiver unit will need to be replaced – this could be more costly.

The ibike mount also appears to be quite sturdy, though I did find it difficult to rotate it into position for the first few installations…but then it got easier as the surfaces deformed and broke in.

Summary :  Don’t worry too much about durability, but I’d give a slight edge to the SRM and the ibike over the PT/Polar simply because they have a few less moving parts so to speak.

Last Updated on Thursday, 26 April 2012 17:43