Cycling Computers: What I'd Like to See...

As I've mentioned here in the past, I've been considering various options on cyclocomputers for a while now and been a bit frustrated in finding what I was looking for. While most would likely focus on other areas of the bike first, I tend to put a lot of importance on devices like this as they can help improve the performance of the engine (ie me) which likely will provide better gains than anything else. As such, my focus was on high-end units with the intention of trying to find a match that could give me every bit of data possible.

Unfortunately, while there are plenty of great units out there all of them are missing one or two critical things so it's a matter of balancing those compromises. Polar has the best implementation of the core features IMHO, but they lack aftermarket power meter support and have limited storage capacity. Garmin is the posterboy for interoperability, offers tonnes of capacity and has some great navigation features, but its core features are a little rough (inability to manually seed barometric altimeter, periodic lockups/file corruption, etc.). iBike's devices can capture much more data than their competitors (air speed, instantaneous incline, aerodynamic drag, etc.) and offer power out of the box, but their interface and power supply are crude.

Despite this, at this juncture I ended up going with the Garmin Edge 705. It has its rough edges, but most of them can be worked around one way or the other. The Polar was my favorite from the start, however power measurement is an extremely critical feature so the wider selection of more robust meters on the Garmin side tipped me away from that option.


Regardless, in case the vendors are listening I figured that I'd make up a list of things that I would have liked to see in a device like this. I've pretty much dug through every tidbit of information that I could find on all of the different options, and spent a lot of time considering my choices, so I figure it's a good way to make additional use of all of that work ;) I'm going to focus on generalities where possible here, as specific requests are of limited utility as they are often governed by design constraints their engineering teams are faced with. Naturally, any comments are more than welcome as anything that I say here is going to be tainted by my personal interests ;)


Reliability of Core Functions

Above and beyond anything else, it's important that a high-end cyclocomputer is capable of performing the core functions (reporting and recording basic telemetry) at least as well as the basic $50 offerings. This sounds like a silly point to have to make, however with the addition of advanced features the complexity of these devices has increased considerably so it becomes more and more difficult to maintain that stability. As such, it becomes critical for the engineers designing these computers to redouble their testing methods to combat this. The fancy features are nice, but not at the expense of getting the basic stuff right - if I'm paying 10x more for a product, I expect it to do the basics without exception.


One of the things I have seen with the advent of field upgradable firmware common in many of these devices is that vendors often ship code before it is ready. When you have hard coded firmware (like Polar), releasing code with bugs in it is a huge problem as it can cost the company large amounts of money in service and support. As such, the testing procedures for these products are often incredibly rigorous and the final products are generally rock solid from the start. This often means products get to market a bit late, but frankly I'd rather wait a little while and get something that works right ;)

When this pressure goes away, however, getting the product to market quickly often takes precedence and products are shipped with numerous bugs. This wouldn't be so bad if the latter upgrades resolved the problems, but often without the proper culture in place updates often introduce new problems as they fix the old ones. Further, as time passes less and less resources are available to the team producing these updates and quality can often dive off even more over time. Ultimately, you end up with a product that consistently has issues and users are often left intentionally using old releases as they have fewer problems for their particular requirements.

The ability to upgrade firmware is in-and-of-itself a great feature for any product, but the company producing the product should never lean on this. These devices are embedded systems, not computers, and firmware must be designed with the same rigor that their hardware engineers apply to their work. If that means adding fewer features or pushing back the release date, then so be it - these devices should never ship from the factory with known bugs. Locking up or corrupting data is not acceptable in any scenario, nor is providing unreliable readings.


Charge for Firmware Updates

I know that this is a bit of an odd request for a consumer to make, but stick with me here ;) The ability to upgrade firmware has the capacity to extend the utility of a device considerably. Regardless of how much of a gadget freak I am, these devices are not the sort of thing I will be replacing just to get a few more features. Unless the unit breaks down or some incredible new breakthrough comes around, I'm likely to be using it for a long time. As such, getting significant new features added via firmware updates is a huge potential asset.

The problem with this, however, is that there is little incentive for vendors to devote many resources to this effort beyond the first few months. Providing significant feature additions via firmware updates is a resource intensive process, and it's generally pretty difficult for companies to get a return on that investment. Existing customers are happy about it, but they aren't providing any additional revenue. Those additions may get a few new customers who otherwise would have gone in another direction to buy, but that's generally not a very big population so it's difficult to justify. As such, it often makes more financial sense to save those ideas for the next version.

If, on the other hand, a yearly subscription fee provided them with a revenue stream from many of those existing users the picture changes a bit. It means that these vendors can better justify expending the necessary engineering resources on these products - allowing more significant upgrades, better QC on the updates and an improved realization of the potential of these devices. Users would be free to pay this or not, which would give the vendor an incentive to provide meaningful new features to give people good reason to continue with it.


Provide Raw Data wherever Possible

Several of the sensors commonly used by cyclocomputers monitor discrete events (heart beats, crank/wheel revolutions, etc.), and shoehorning that data into a one sample per second framework is effectively destroying potentially useful information. For instance, every chest-strap based heart rate monitor can fundamentally capture R-R data, however the vast majority of them process this to a regular sampling rate before relaying their readings to the head unit, throwing away that potential. One can always discard information after the fact, but once it has been discarded there is little one can do to get it back.

When flash memory was expensive, this made sense as it would have been difficult to provide sufficient capacity to hold all of that additional data. At this point, however, large capacity flash parts are extremely inexpensive so that's not really a huge constraint any more. Naturally, for an entry-level offering where the price is the primary competitive factor every penny counts, but at this level I have to figure that functionality is a much more significant variable than anything else.

The main issue at this point, of course, is that the current infrastructure is built upon the fixed sampling rate model. File formats, desktop software and web services would all require modification to support this sort of thing. This is a non-trivial matter of course, however going forward this would enable a lot more flexibility in adding powerful new functionality. Naturally, if the major players in this market (eg Garmin, Polar, Suunto, iBike, Zone Five, TrainingPeaks, etc.) could agree on a standard file format for these exercises that would be even better, but I'm not holding my breath on that front ;)


Another instance of this issue is automated filtering algorithms implemented in the device itself. When they work correctly, they are a good thing as they produce more useful data - both for live display and later analysis. The problem, however, is that they don't always work well and can sometimes obscure useful data (smoothing out short bursts of speed). If the unprocessed data is stored in the exercise files and the filtering is applied by the software after-the-fact, the user can easily correct for this by manually disabling the filtering when they see it is causing a problem. Further, the powerful microprocessor(s) in a desktop computer can use much more sophisticated algorithms than the small embedded processor in the device itself - potentially meaning more reliable and accurate results.

For instance, one of the biggest concerns that I had with the Edge 705 was its automatic altitude correction mechanism. Barometric altimeters are extremely precise instruments for measuring elevation, however they are unable to differentiate between changes in air pressure caused by altitude changes and those caused by passing weather systems. To combat this, Garmin added a mechanism that uses the GPS altitude reading to help correct for this problem. This simplifies the operation of the device as the user doesn't have to worry about these issues, however individual GPS altitude readings aren't particularly accurate. Over time, multiple readings can be combined to generate a pretty reliable number, however at the beginning of a ride it takes time to collect enough data to do this.

Unfortunately, as these corrections are done in real-time, until the GPS altitude settles down the elevation telemetry at the beginning of a ride is unreliable. While barometric readings do have their issues, the error that comes from them is generally pretty easy to detect and correct for as it operates in a deterministic manner. The error inherent in GPS altitude data, on the other hand, is difficult to model so the 'corrected' elevation plot is much more difficult to clean up. Unfortunately, until recently Garmin provided no mechanism to disable this functionality and manually calibrate the barometric readings (and their current solution is somewhat convoluted, requiring you to add a waypoint rather than simply entering the value).

With that said, this idea has merit and if it was implemented in post processing rather than in the device itself it could have a lot of potential. That is, if the device simply stored the raw data from both sensors (ie GPS altitude and barometric pressure) and then sorted it out on the computer after-the-fact rather than attempting to do it in real time we'd see much better results. In this configuration the computer can take multiple passes at the data, allowing it to consider readings over the entire ride (vs what had been collected up to that point) when correcting each data point. When processing a sample before the GPS altitude had settled down, for instance, the system could look ahead and use longer-term averaged data to provide a more accurate correction.

The other advantage that this mechanism would provide is that it would be easily reversible. If the specific conditions surrounding a ride meant that the correction did more harm than good (eg tree canopies blocking GPS reception) the user could easily disable it after-the-fact and work with the barometric data only. Conversely, if operating in weather conditions where the barometric pressure was all over the place the user could also elect to instead rely on the GPS elevation. As the athlete generally has a pretty good idea of what the elevation should look like, he/she is better equipped to determine which mechanism is more accurate for a given situation than any automatic system is.


Either way, getting back to the general point - the above examples simply illustrate that while processing data in the instrument itself may be simpler, it isn't always the ideal solution. From a technical and economic standpoint there aren't a lot of costs involved with adding this sort of functionality, but the benefits that it can provide are significant to more advanced users. Further, this is the type of feature that can help to differentiate the high-end products from the more mainstream ones. Making use of that raw data is more complicated, but given sufficient documentation of the necessary file formats aftermarket software vendors would likely be more than eager to take care of that task.


Provide a Fixed Position Barometric Data Logger

This is breaking my rule of remaining non-specific, but as all of the high-end cyclocomputers use barometric altimeters I figured that it was warranted in this instance. As mentioned above, the problem with barometric altimeters is that they can be fooled by pressure changes caused by weather systems. As such, while these devices can generate extremely accurate altitude readings they do require correction to account for these issues (either manually in post processing, or automatically).

Even when cycling, however, users will generally not venture far enough away from their starting point that these weather systems will vary significantly. As such, having a second barometric sensor that is left at the starting point (home, car, etc.) and logs the pressure changes at a fixed point would give the system a recording of pressure changes triggered by those systems (as its altitude is fixed). That baseline could easily be subtracted from the barometric data recorded by the head unit, and would provide an extremely accurate and reliable elevation plot without any elaborate tricks.

The easiest place to put this would be in the device used to interface the head unit with the desktop computer (eg IrDA transceiver, ANT+ stick, etc.). It wouldn't be difficult to integrate a barometric sensor, a small quantity of flash memory (even 4MB could easily store several week's worth of uninterrupted barometric readings) and a battery into these sticks and would allow both datasets to be downloaded simultaneously. Alternately, it would be easy enough to make a standalone device that users could buy separately if desired (the only downside is that this would require a way to get that data to the computer or head unit).

Given the online services that each of these vendors are beginning to add, it could even be taken a step further by uploading this data to a central server along with an (anonymized) location. If enough users were clustered in a geographic area, this would allow the system to interpolate pressure changes and build even more accurate corrections for all of their users in the vicinity.


Capture Additional Telemetry (Air Speed, Inclinometer, etc.)

If there is one thing that will make me seriously consider spending more money on a device like this, it's the ability to capture and record additional types of data. Ultimately, the primary purpose of an instrument like this is to give me metrics with which to examine the quality of the exercise that I am performing. The more information that the device can measure, the more complete a picture it can paint and the better that final analysis will be. Naturally, that doesn't mean mindlessly throwing in the kitchen sink, but finding important information that competitive devices aren't measuring.

The iBike devices are actually a good example of this, and had it not been for critical shortcomings in other areas of its design, I would have happily paid the ~$200 price premium for their iAero product. As the iBike needs a complete picture of opposing forces to generate power numbers, it added an air speed sensor, multi-axis accelerometer and inclinometer into the mix. While the power calculations are nice, the availability of this additional data is a much more significant tool as it gives the rider the tools necessary to figure out exactly where all of that power is going (and by extension, what one can do to use it more efficiently).

The inclusion of both ground and air speed plots is an especially crucial detail, as at typical road bike speeds aerodynamics plays a huge part. At 32km/h (~20mph), for instance, more than 77% of the power output by the cyclist is being expended to fight aerodynamic drag. Mix in a 20km/h headwind, and that percentage goes up to 90%. As such, when fighting a strong headwind that ground speed measurement doesn't really tell you a whole lot so finding the right effort can be difficult.

More importantly, if combining power data with both air and ground speed, it's possible to calculate a good real-time approximation of aerodynamic drag. Having this reading on a bike computer allows the cyclist to refine their body position without needing expensive visits to a wind tunnel. Further, as these measurements are made in the real world, they can consider aspects that are difficult to model in a synthetic environment (eg effects of drafting in a dynamic peloton).

The inclinometer is also a nice touch, as it provides a much better way to capture the grade of any hills that you ride. Most devices (including Polar and Garmin) rely on a simple rise over run calculation using the altimeter and wheel sensor data. This works reasonably well at capturing the overall grade of a hill, but it doesn't do a very good job of reporting the instantaneous grade nor capturing its nuances. Further, a dedicated inclinometer also provides a backup method of generating an elevation profile in case something interferes with the proper operation of the altimeter (eg rain blocking up the barometer port).

While the accelerometers are important for iBike's power implementation, they don't really add a whole lot so they're not something I'd likely put a lot of priority on. With that said, they could be used indirectly to provide estimates of road quality (and hence rolling resistance) by quantifying the amplitude of high-frequency vibrations transmitted through the frames. They could even be used to implement a dead reckoning subsystem to handle mapping duties for short periods when the GPS signal was lost (tree canopies, tunnels, etc.). Either way, probably not worth the cost/energy footprint unless the engineers can find something more useful to do with them ;)

As for other data that would be useful, this is largely where the engineers could be creative but would depend a lot on the specific design of the device. While not really critical, as any device with a barometric altimeter needs a thermal sensor anyway adding temperature traces to the data is also potentially useful. Gear position readings would be handy (most of Shimano's shifters already have the sensors), as would brake position sensors (would need to be done independently, but relatively simple).

A forward facing proximity sensor could also be very useful, as it could provide information on when (and how close) you were drafting other riders when analyzing data after-the-fact. Thanks to their inclusion as back up sensors in cars, ultrasonic rangefinders have become commodity items and can be added relatively inexpensively. Such readings would also be useful in races where drafting is forbidden, as it could allow you to precisely space yourself according to the rules.

Alternately, given the trivial price and footprint of basic camera parts nowadays (thanks largely to their ubiquity in cameraphones), it would also be interesting to integrate a camera and capture a low-resolution (~320x240) picture every second or so to go along with the data. Like GPS track recording, this wouldn't provide any directly useful telemetry but it would potentially provide important context. For instance, it could be immensely useful for reviewing race tactics as you would not only be able to tell when you were drafting, but where in the pack you were and even whose wheel you were on. When looking back, it could also give information on weather and traffic conditions to explain changes in speed/effort that may not be obvious from conventional telemetry. Further, when dealing with abusive motorists, such a feature could even record licence plate numbers and evidence that could be forwarded to law enforcement officials.


With all of that said, as users it's easy to list a bunch of sensors that we'd like to see but quite a lot more difficult to actually design something that provides them all. Generally speaking, the air speed sensor is really the only major thing listed above that I'd really like to see in a product. It's also probably the most expensive and complicated to add, but it adds a critically important window into performance that is missed by the vast majority of devices. As noted above, I'd gladly pay a significantly higher price to get this feature, and that's a critical distinction for a manufacturer. The rest of the sensors listed above would all be useful, but to determine whether they'd justify the costs inherent in their addition (engineering, manufacturing, size/power footprint, etc.) one would really need to know the details of the implementation.


Cooperate with Aftermarket Vendors

This is one area where Garmin has done quite a good job, and is the primary reason why I ended up settling on their product. Thanks to an freely licenced protocol for their sensor network (ANT+) and a well documented file format (.tcx), they've built a significant ecosystem of aftermarket software and hardware around their products. This means that when a user has a need that isn't met by their own products, they have somewhere to turn to find the tool that is necessary. An ecosystem of many different vendors working together can build a more complete solution than any one company can ever hope to provide.

Many other vendors in this space, however, are far less open. Wireless protocols are proprietary, documentation of file formats are either missing or significantly out of date and there are few places to turn for those answers. As such, companies who want to support these products are forced to revert to reverse engineering in order to find the details they need. In addition to taking a lot more time and energy, this also means that support for new products often lags significantly as developers can't start this process until they can get their hands on one through retail channels.

Naturally, this approach gives the vendors more control over their products - they can make changes unilaterally, and don't have to worry about compatibility with anything but their own offerings. It also simplifies the task of supporting their products, as since everything is in-house they aren't likely to get calls/emails requesting help with poorly implemented software/hardware that they didn't produce. This is an understandable position for a vendor to take, however when considering my options as a customer it is potentially a significant strike against those product lines.


Build Quality

Bike computers often sit front and centre on your handlebars, and as such can easily be exposed to a much harsher environment than most electronics. Aside from dealing with normal outdoor hazards (temperature extremes, heavy rain, periodic hail, etc.), they also have to deal with dripping sweat, spilled electrolyte drinks/gels and road grease being sprayed up by the front wheel. Further, as they're rigidly bolted onto a vehicle with high pressure tires and no suspension they have to deal with vibration forces well in excess of what normal devices need to face.

Regardless, while the core instruments are often reasonably well designed, critical components like their mounts and covers for their electrical connections are often hastily made. These are both bits that will see a lot of fatigue (basically being actuated after every ride), and if either fails they can easily lead to expensive damage of the rest of the instrument. Cutting corners like this takes a lot away from the feeling of quality of these products, and makes users feel less confident about taking them out in the elements. We're not so much talking about fundamental flaws here, simply a matter of putting a little more thought into their design.

It's important to remember that this is a market that has a deep appreciation for material choices and build quality. These instruments will often be mounted on bikes made out of expensive materials and painstakingly engineered to maximize performance. Fixing little things like this may cut into margins a bit more, however getting a reputation for cheaply made products (whether real or perceived) is a dangerous prospect with this demographic.


User Serviceable Components

Despite the best efforts of designers, some components are inherently wear items and will eventually begin to degrade over time. The chemical batteries that power these units are a good example of this - there are things you can do to improve their life, but after repeated charge-discharge cycles and hostile conditions they will eventually begin to loose capacity. As such, it is important that it's possible for users to replace these components themselves when that does happen.

Bicycles are inherently high maintenance items, and they require their owners to do a good deal of work to keep them running smoothly. The drivetrain needs to be cleaned and lubricated regularly, tires and tubes need to be replaced and mechanical components need periodic adjustments. As such, if the design requires hiding these wear components behind a few screws that really isn't a big deal. We just need the ability to buy the parts that are necessary, as well as get instructions on how to get them in there. For the less mechanically inclined, being able to get the bike shop to do it would be vastly preferable to sending it to the other side of the country and back.

Making disposable units is fine for entry level products, but when spending this kind of money the lasting power of a product becomes a significant component of the value proposition. In practical terms, I'll likely be replacing the unit with something more modern before this becomes an issue, but when spending this kind of money I'd like to use it for other tasks when that happens so longevity is still important. The bottom line is that the more comfortable I feel about how long a product will last me, the more I am going to be willing to invest in it.


Customization

There are lots of different types of cyclists out there that will use these devices in very different ways. Further, even within one discipline there are different conditions (eg recreation, training and racing) that they will be used. As such, trying to design a user interface that will appeal to all of these subgroups is impossible, and will simply lead to setups that are compromises for each of them. Customization, then, is key to the design of any of these instruments.

Aside from allowing users to customize which data fields are displayed on their screen (offered by Polar and Garmin), it would be nice to have more options on how exactly that data is shown. For instance, the colour bitmap display that the Edge 705 isn't really used by the telemetry pages. All of the data fields are simple monochromatic text entries, and at most all that you get are separate entries for instantaneous, average and maximum values. Simple things like being able to provide colour coding for heart rate and power zones, for instance, would make it easier to see where you are at a glance.

Visual mechanisms for displaying information like this can be beneficial in this type of use, as the faster the user can retreive the data they need the faster they can get their eyes back on the road. Ironically, the units with fixed element LCDs are often better at presenting this type of feedback. My $40 cateye unit, for instance, has little arrows adjacent to the speed field that tell me whether I'm above or below my average - it's a simple thing, but it allows me to quickly look down and get immediate feedback.

Taking it a step further, being able to extract trend information during a ride can also be useful and visual plots can be helpful for that. Having basic statistical readings like 10 minute rolling averages, median values, etc. could allow more meaningful analysis of performance. When taking a break for lunch during a long ride, for instance, it would be incredibly helpful to be able to pull up a graphical plot of speed, HR, power, elevation and cadence to review what has been done and what needs to be improved.

While the iBike is probably the least customizable unit, one feature that I did like was its ability to automatically display appropriate data when the context changes (eg when the grade goes beyond a threshold, hill climbing data is displayed without user intervention until things flatten out). Naturally, that's easier to do with a hard coded setup, but allowing some simple if/then commands to automatically change pages wouldn't be difficult to do and could significantly reduce the amount of fiddling I'd have to do while on a ride (eg grade info on hills, giving me ride summary data whenever I come to a stop, showing different data in work/recovery stages of an interval, etc.).

Further, one feature that I have found lacking in many devices is the ability to work with mixed units. Rather than forcing the user to make a wholesale selection between metric or imperial units, simply providing that choice with each data field would make things a lot more flexible. While I'm much more comfortable working in metric, many training programs and races use imperial units so being able to display the two side-by-side can often be handy.


Data Sharing Between Devices

As someone working on building myself up the Triathlon ladder, I'd love to have one device that would be suitable for all of the sports. The problem, however, is that what I'm looking for in a cycling computer is very different than what I'm looking for in a running computer. There are many devices out there focused at this market, however all of them have significant compromises in one or more of these specializations that make it preferable to have two discrete computers.

As such, for those of us who want to buy two separate devices it would be nice for them to have the capacity to communicate with one another and share information. For instance, simple features like being able to synchronize time elapsed as you approach the bike after the swim and allowing lap presses on either device to add the marker on both would be incredibly useful. The wireless radios are already there (the 705 can transmit courses between head units), so it's just a matter of the firmware to make it work. Naturally, providing customers with reasons to go down this route also makes sense from a business point of view - as it acts as a strong motivator to stay within the product line when it comes time to upgrade ;)

Additionally, the ability to pull up live telemetry from friends in a group ride would also be useful in many situations. A coach training a number of other riders, for instance, could have a real-time readout of the heart rate and power information from his students to better guide the workout. Similarly, in a race situation allowing riders to silently retrieve telemetry from their teammates would be a significant benefit in figuring out which tactics make the most sense at a given point.


Ideally, my preference would be to have a robust multi-sport implementation like Suunto's T6c with a simple dumb head unit attached to the stem that allows access to the telemetry that the wrist unit is recording. Such a device wouldn't need any dedicated flash memory or computer interface, and would only need a basic microprocessor (as the wrist unit is doing all of the heavy lifting). Aside from being more cost effective than two full featured computers, such a device could be much smaller and lighter.

Such an infrastructure would also be useful in laying the groundwork for other types of aftermarket devices, such as sunglasses with basic readouts so the user doesn't even have to look down. Something as simple as having tri-colour LEDs in the frame indicating whether you are in, over or under your desired speed/heart rate/power zone would be incredibly useful. A full blown HUD would certainly be cool, but I don't believe that the technology is there for that just yet ;)


Closing Thoughts

Either way, I've rambled on enough on this topic for the time being so I'll end it here. As an engineer myself, my normal desire is to try and find ways to fix up shortcomings in the products that I use. Unfortunately, as systems like this are closed and there is no practical way for me to modify them to suit my needs this is about the only way that I can do that!

If you've got anything to add on this topic, don't hesitate to comment and add your suggestions. I'm not holding my breath that this will actually make it through to anything, but after piling through information for the last few months I wanted to get my thoughts written down somewhere on the topic ;)

Aside from this article, I'm also going to look at making a few others with specific examinations of the various products that I considered. Once I get the 705 on the road, I'll make up a full review - but that's likely going to be a while as the snow isn't going anywhere for the next couple of months ;)

Contemplating Upgrades...

We've had a great streak of weather this winter, however it's coming near the end at this point so the bike will likely have to be switched over to the trainer soon. I'll be bringing it into the shop to have it tuned up and the rear tire and skewer switched over, and that has got me thinking about potential upgrades that I want to look into over the winter. I'm still riding on a mostly stock configuration of my bike, but as I'm looking at getting into some proper races next season it's likely worth considering a few additions to suit where I want to go with the bike.

Aerobars

The one major change that I'm looking into at this point is adding some aerobars onto the bike to better optimize it for what I'm going to be doing. As it stands, I'm currently riding on a conventional road configuration - using drop bars and a 73 degree seat tube angle. This is ideal for group rides and races where you have the benefit of a draft as it provides more responsive controls. In these scenarios, aerodynamics isn't a huge consideration as you are protected from the wind for large portions of the race/ride. In most Triathlons, however, drafting is not permitted so that balance changes a bit.

Without the protective sheath of the peloton, the aerodynamic drag of the rider and bike is the primary force that a rider's energy is fighting. At my normal flat ground cruising speed (~32km/h), for instance, approximately 78.5% of the power that I am producing is expended to cut through the air. Thanks to this, the market is flush with all kinds of expensive accessories to help improve the aerodynamics of the bike itself - deep dish wheels, wing shaped handlebars, water bottles, etc.

These can be useful tools, however the biggest contribution to drag by far is the rider sitting on top of all of that fancy equipment. As such, anything that can be done to get one's body into a more aerodynamic possition will often have much more effect than anything else you can do to the bike. Thanks to this, for events such as Triathlon, the addition of aerobars has the potential to provide a lot more bang for the buck than any other upgrade. The loss of responsiveness is also less of an issue, as the anti-drafting rules force riders to spread out allowing riders more time to react.

The tricky thing is that there are a wide variety of different designs out there, so selecting the appropriate equipment can be tricky for someone like myself that has no experience using them. Adding to the complexity is that I don't have the luxury of a second road bike, so the aerobars have to be configured in such a way that the bike can still be used in the road configuration when necessary (group rides, hilly courses, etc.). I can naturally defer to my bike shop to help me with the details of how to configure these components, however figuring out which parts to buy is something that I'd rather do on my own (as they're likely to push what they carry over other products which may better meet my needs).

On the other end of the equation, one thing that I do have going for me is that my particular bike model was explicitly designed to function well in both road and TT configurations. The seatpost head can be flipped into a different possition that allows it to provide either a 73 or 76 degree seat angle (partially thanks to a bottom bracket located slightly behind the centreline of the seat post), so by purchasing another head and saddle I can switch back and forth between both geometries. That allows me to use full length clip-on aerobars and get my body into a position that is difficult to achieve with most conventional road bike designs.

Either way, I still have a lot more research that I have to do in order to figure out what I'll have to move around to achieve what I'd like to do here. Simple factors like whether the aerobars are mounted above or below the handlebars make a significant difference in how everything is configured, and with competing parameters (eg getting enough drop for the aerobars while not pushing the normal handlebars too low) it's a complex equation. I will naturally have a fitter work out the details once I buy all of the bits, but I'm still a good deal away from that point.


The other, more indirect, benefit to adding aerobars to the bike is that it makes hydration a little easier in a race scenario. Reaching down or back to frame or saddle mounted bottles requires the rider to move out of their normal riding position, slowing down the bike. On a training ride that's not a huge deal, but during a race one has to think twice about when they want to do this and it can ultimately lead to taking in less fluid than one should. With aerobars, however, there are hydration systems (eg Aerodrink) that can mount directly on the cockpit so that the rider can drink without having to move out of position.

Cyclocomputer

I've posted a few times on this topic in the past and have been going back and forth with my choices for a while now, but it's getting to the point where I need to make a decission one way or the other. The tricky thing has been that each of the options has bits that I want, and all of them are missing somewhat critical pieces that another unit has. I had hoped for some new offerings from the vendors over the last year or so that would resolve that, but unfortunately there hasn't been a whole lot on that front.

Polar's CS600X has long been my favorite design amongst the group, however it has one critical flaw that is difficult to overlook. While Garmin's ANT+ protocol has seen wide adoption from third party power meter vendors, Polar's WIND protocol isn't supported outside of their own set of products. The more that I read about power training, the more and more important it seems to be so this is a major consideration on which computer I intend to go with. As ANT+ devices like Garmin and iBike offer a wide range of different choices on this front (Vector, Quarq, Powertap, SRM, etc.) that is a pretty significant edge.

Polar does have their own power meter, and while a novel solution its indirect measurement technique means that accuracy is sensitive to how it is installed. Without any local vendors that have experience installing the product, I'm concerned about how well they'll be able to set it up (and hence the validity of the information that it provides). I've also seen some degree of concern about its reliability, as the wires connecting the main sensor unit to the battery pod appear to come loose periodically.

As such, it's largely down to the Garmin Edge 705 and the newer Edge 500 models at this point in the game. The former has a colour screen and full navigation capabilities which are tempting, but the latter offers all of the core functionality for about half of the price (saving more money for an eventual power meter purchase). The 500 also has the advantage of a more modern design, such as accurate calorie computations (the 705 uses an older algorithm that is horrendously inaccurate) and a better heart rate strap (soft textile vs. hard plastic). It also has longer battery life and comes in a much smaller package. Further, judging by Garmin's behavour in the past it's also more likely to see substansive firmware upgrades in the future.

The iBike Aero is still on my radar, but it is significantly more expensive than the other options and has a bit of a kludgy design (limited UI, short life batteries, offboard wireless radio, etc.). I still love the idea of having air speed data, but I'm not sure that that's enough to offset the disadvantages of the design. iBike is rumored to have a new model coming down the pike in the spring that may resolve these issues, but without specific evidence that it addresses my concerns I've already waited far too long to make this decision.

I'll likely head over to some local shops to check out the two models once the Edge 500 starts coming into stock and make a decision at that point, however after thinking about this for nearly a year I really have to make a move ;) Naturally, if I'm going to get some aerobars mounted it's a good opportunity for them to install the new cyclocomputer and its sensors.


Naturally, I will want to add a power meter to the equation at some point in the future but that doesn't appear to be realistic at this juncture. The Metrigear Vector has the potential to open the door to that, however even at it's expected price it'll still likely take a while to save up the money to add that into the mix. That's not necessarily a bad thing though, as it'll give the new product some time for a shake down in the market before I buy into it.


Either way, I'll be looking into more detail on these topics over the coming weeks and figure out which way I want to go but I wanted to get my thoughts in here in case anyone has any suggestions on either front. I tend to be a bit of a perfectionist with these things, and that means I waste a lot of time digging for every shred of information I can find on all of my options. That helps to avoid making mistakes, but it also means that it can take me forever to come to a decision ;)

Power Meters - Metrigear Vector

As an engineer, the idea of a power meter on my bike is an extremely attractive one. The basic concept of a unambiguous, objective method to monitor performance that can cut through all of the outside influences (fatigue, wind, drafting, hills, road surfaces, etc.) is a powerful training tool. Unfortunately, the cost of these sensors is often difficult to justify unless you are a high level athlete (which I'm most certainly not). Most of the solutions out there cost upwards of $2000, and at this juncture there are other things that would likely be more beneficial for me at this point (eg a dedicated TT bike).

The Saris PowerTap is probably the closest direct measurement power meter on the market right now, and while it can be had for less than $1000 it needs to be installed into a wheel (or purchased with one). Unless you are planning on upgrading wheelsets, that means that the effective price of adding one of those units is a good deal higher. Further, eventually I'd like to have a separate wheelset for racing vs. training, and with the PowerTap solution that means buying more than one power meter.


Polar's CS600X power meter falls into a lower price bracket and, as it is external to the powertrain, doesn't need any modifications to the bike. Additionally, Polar does offer a lot of interesting information that other vendors don't - such as left-right balance and indications of the roundness of the stroke. How accurate these values are I'm not sure, but for someone still relatively new to the sport they could be quite useful for improving technique. Finally, Polar's heart rate straps are much better than the Garmin ones used on all of the ANT+Sport units that work with the aftermarket power meters, so that's a big plus on their side (Suunto has competitive HRMs, but they appear to use a different variant of the ANT protocol that is incompatible with other products).

Unfortunately, the more that I read about it the more concerned I am about its accuracy. It measures power indirectly, by picking up chain speed and vibration and working back to the power number. This is an ingenious idea in-and-of-itself, unfortunately it is susceptible to noise introduced from road vibrations and varying distances between the sensor and chain as you change gears. Due to this, it is very sensitive to how it is installed on the bike and as I have yet to find a local store with any experience with the unit I'm a bit uncomfortable with the concept. If I could find a store that has installed a few dozen of these I might think about it, but unfortunately that doesn't appear to be an option around here.


The most promising solution I've seen until recently was the iBike line, which doesn't so much measure power output but measures the opposing forces and figures out how much power would be required to explain the current velocity/acceleration. Aside from providing power readings, this solution has the benefits of also recording exactly where that power is going - having airspeed measurements and a proper inclinometer (ie not just dividing elevation change by distance covered) could be invaluable for analyzing a ride after-the-fact. Further, when paired with another ANT+ power meter it can provide real time readings on your aerodynamic drag coefficient (great for fine-tuning body positions on the bike).

The problem with this unit is that its design has a lot of rough edges (kludgy non-customizable UI, wireless radios not build into the head unit and insufficient battery life) largely due to them using the same hardware platform for their $199 and $799 products. Further, its heavy reliance on the airspeed sensor means that it can't provide accurate power readings when riding in heavy rain (as the port gets plugged with water). Still, it's an excellent concept and its shortcomings should be easy for Velocomp to address in any future iterations (ie add at least two bitmapped lines to the display for proper alphanumeric menus, add the capacity to customize the data fields shown on screen, put the wireless bits in the head unit rather than the mount and move to a bigger battery (eg a CR123 or even rechargeable cellphone batteries)).


Looking over the coverage of Interbike last week, however, a company called MetriGear caught my attention with a new power meter called Vector. Rather than measuring at the crank (SRM and Quarq) or hub (PowerTap), they put a small sensor in each of the pedal spindles. As such, they are trivial to install and don't require you to replace any major components of the bike. Further, as each foot has its own sensor this technology has the potential to be able to provide more detailed information about how the rider is delivering that power. This means they could provide the left-right balance and stroke quality readings like Polar are providing, but with a lot more detail as these values could be directly measured rather than extrapolated (although this will be dependent on a head unit that can capture and record this extra data).

Adding to this, like the PowerTap it should be very easy to move one set of sensors over to another bike as necessary. As such, if I do eventually get a dedicated TT bike to go along with the road bike, this would make it feasible to have a single power meter that could be used by both. The crank-based designs are a pretty complex ordeal to swap over (especially for someone like myself with limited experience changing out parts), and while the iBike is pretty simple the fact that they put the wireless bits in the mount means that it's an expensive proposition.

The big news, however, is that they are talking about comming in at a price below $1000 including the pedals. That's still not innexpensive by any means, however it does fall into the range where I might consider picking up a power meter. The price doesn't include a head unit (they don't appear to have any plans to make one), but as they are ANT+ compatible they will work with a number of offerings already on the market. The question remains whether the aftermarket head units (Garmin's 310xt, 500 and 705 and the iBike Pro and Aero products) will be able to understand the unique data these sensors can capture as the current firmware seems to simply understand basic power data.


At this point I'm not really in a position to buy one of these (not that it matters as they won't be available until Q1 2010), however I am in the process of buying a new cyclocomputer (as I've written a few times here) and this development is enough for me to strongly re-focus on products that will be compatible with this unit. The Polar CS600X (likely without power) was strongly leading the pack before this announcement, but now I'm seriously reconsidering the Edge 705 or potentially waiting for the Edge 500 as they will both be compatible with the Vector. I've always preferred much of the hardware design of the 705 over the Polar, but I'm still a bit concerned about its perpetually crappy firmware (stability issues, horribly inaccurate caloric readings, unreliable elevation recording, etc.). The Edge 500 may address those issues as it's a much simpler design, but it gives up a lot of what made the 705 attractive (street level mapping, ability to upgrade memory, etc.).

The iBike iAero is also an option, although that is a more costly option and, as above, I have some reservations about their design. I was hoping that they'd announce a fourth generation design of their product this year, but it doesn't look like that is going to happen. They have made great strides on their firmware over the last little while, and appear to be by far the best at addressing user concerns with periodic updates. Unfortunately, firmware upgrades can't address the fundamental shortcomings of the underlying hardware platform so it remains an unlikely choice despite its compelling feature set.


Either way, it seems that every time I'm about ready to settle down for one choice or the other a wrench like this gets thrown into my plans ;) Garmin is good at making excellent hardware, but they aren't very good at the firmware side. iBike, on the other hand, is great at squeezing every last bit of capability out of their devices with firmware updates, but their hardware is limited due to their insistence on a single platform for such a wide range of price points. Polar was the happy middle ground (not the most feature packed, but exquisitely engineered hardware and software), but their lack of support for the ANT+ protocol is a big limitation with the advent of power meters such as the Vector.

With the Toronto bike show comming up in a couple of weeks, I'll probably go and see if there are any decent deals on these things. Barring that, I'll just have to mill over the choices a bit more ;)

Cycling Computers: Revisited

About three months ago I was looking at various options for replacing my bike's basic cyclocomputer with something more capable. Unfortunately, things got busy after that point and I never got a chance to do much more research. After getting back on the road for a while, however, the limitations that weren't so big of an issue on the trainer re-asserted themselves and brought this consideration back to the forefront. As such, over the last few weeks I've been doing a little more digging and re-examining my options.

Shortly after the last post, I was strongly gravitating towards the Polar CS600X but it wasn't available at the time. Thanks to some pro-active assistance from Chris at Polar USA, I was able to get confirmation that the CS600X with power is available in this country so it's just a matter of finding a retailer at this point. In the meantime, however, I've heard a lot of good things about the Garmin Edge 705 from local bike shops and riders that I've met out on the road so I'm reconsidering that option as well.


The other unit that I've heard good things about and didn't consider last time around is the Velocomp iBike series (specifically their Pro and Aero units). In addition to the basic cyclocomputer features, these units provide power readings using a relatively novel solution that measures opposing forces rather than measuring the drivetrain itself. Using an air speed sensor and a multi-axis accelerometer array within the head unit, it measures the various forces resisting movement (primarily aerodynamic drag and rolling resistance) and backsolves the amount of power necessary to maintain the speed the bike is traveling at.

Naturally, the power readings do make some assumptions that more direct measurements don't have to deal with. Primarily, when one changes positions during a ride their drag coefficient will change but the system has no way to know that this is happening. As such, when going down on the drops power will be overestimated and when sitting up to drink, power will be underestimated.

With that said, most people that I've talked to that have actually used the system appear to be impressed with it's accuracy. Part of that is likely down to the fact that one typically spends most of their time in one position so the impact of this is likely less significant than it would seem at first glance. Either way, Polar's measurement mechanism has significant sources of potential error as well and as the other power options aren't really realistic at this point this may be somewhat moot ;)

The one thing that has me intrigued by these devices, however, is their ability to record both the air and ground speeds of the bike. This provides a detailed log of the intensity of head and tailwinds, as well as a way to quantify the effects of drafting positions during group rides. This information can be extrapolated to an extent from heart rate and power data, but as other things can influence those values the air speed readings can be quite instructive (especially for a relatively new rider such as myself).

Further, their iAero head unit can actually provide estimates of your aerodynamic drag coefficient each time you coast (with the addition of an aftermarket ANT+ power meter, it can even provide a continuous readout). If accurate, this would allow me to experiment with different positions on the bike in order to determine exactly how efficient each of them are. At common cycling speeds, aerodynamic drag becomes the dominant force the rider is fighting against so the ability to fine tune one's position is potentially a huge feature.

The problem with the iBike products, however, is that their user interface is pretty crude compared to Polar and Garmin's products. Velocomp elected to use a simple three-line fixed element LCD, which is fine for the numeric information readouts but has severe limitations for the on-device menus. This is likely due to the fact that they appear to use the same hardware for their various models and differentiate based on firmware. As such, their design had to be profitable for their $199 Sport model and compromises had to be made to reach that price point. As a user, however, justifying paying $799 for this type of user experience is a bit frustrating. The biggest annoyance with their implementation, however, is that the user cannot select which pieces of telemetry are shown on each of their pages - one is stuck with the groupings that Velocomp offers.


Either way, I'll continue to do a bit more digging but wanted to get my thought process down here. Like anything, there are significant pros and cons for all three choices here and it's just a matter of figuring out which compromises are the least significant for my needs. Naturally, if anyone has any experience with these products I'd welcome any input on the topic!

Cycling Computers...

When I bought my bike last August, I went with a relatively basic cyclocomputer (Cateye Strada Cadence) to keep costs down. It does a good job at providing me with information during the ride, however it has no mechanism to store that data so analysis of my cycling sessions is a little difficult. Right now, I use my Polar RS800sd to monitor my heart rate, and simply hit the lap button every 2.5km to provide me with a basic record (giving me average speed over those intervals). This works on the trainer, but it's a kludgey way of handling things and will become much less practical when I get back on the road (and can't monitor the display as closely).

Being the data junky that I am, and given that cycling has worked well for me over the last little while, I'm now looking to replace that unit with something more sophisticated. While there are a few things that I could upgrade on the bike, at this juncture I'm still the weak point in the equation so being able to better monitor my training will likely have more effect than any other equipment changes. I'd like to get that done now, so I'll be fully familiar with it and ready for the new season once the weather picks up a bit.

The Contenders

With that said, the market for these devices is a whole lot more complicated than their running equivalents so figuring out which way to go isn't easy. When I selected my RS800sd over Garmin's Forerunner 305, the choice was relatively easy as the former generally has a functional superset of the later, so it was just a matter of figuring out whether the Polar was worth twice as much. With cycling computers, however, there are multiple choices and each of them have some significant advantages over one another so any selection is going to be a compromise.

As I haven't made a selection as of yet, the purpose of this post will be to (a) collect my thoughts on the matter and (b) hopefully to provide information for anyone else looking at making a similar choice. Once I do get something, I'll be sure to post a review of it as I did with the RS800 but for the time being I'm simply discussing my thought process prior to figuring that out ;)

Polar RS800CX

The easiest choice would be to send my RS800sd in to Polar to have it upgraded to an RS800CX which, amongst other things, adds support for their cycling sensors. This would give me a singular device that would work for both running and cycling, and would offer some significant advantages in multi-sport events where I may need to record information from both. As I understand it, one does have to fiddle with the controls to switch sports, but that's not likely a huge issue (as switching between two discrete devices will have the same issue).

The downside to this choice, however, is that the RS800CX is a wrist mounted device so it's not nearly as convenient as the stem-mounted solutions that the other options offer. Aside from being harder to operate, this also means that reading the display would be a much more distracting affair. Polar does offer a mechanism to mount the watch on the handlebars, but this is a bit kludgey and given the issues that I've had with my wristband I'm not sure how much I'd trust it. The other catch is that the RS800CX doesn't have any capacity to work with a power meter, so adding that down the road would mean a second piece of electronics cluttering the headset.

The other catch to this option is I'm not sure whether Polar Canada offers this service, nor do I know exactly how much it costs. The decision as to whether the upgrade is available in a market appears to be left to the national distributor, so not everyone can get this done. I'll have to give them a call to figure out, however as this option isn't really at the top of my list right now I haven't gotten around to it as of yet.

Polar CS600/CS600X

The natural choice for my current situation would be Polar's CS600, which is the cycling analog to my RS800sd running computer. It uses a similar interface, the same software package and shares some of the sensors with what I've already got. In addition, Polar offers this unit with a simple power meter that, when combined with the computer, is within my price range. As the CS600 uses a user-replaceable button-cell battery like the RS800, it also means that I won't have to mess around with charging batteries (or about aging cells bricking the device down the road) and can easily carry a spare with me at all times.

Additionally, if I were to upgrade my watch to the RS800CX down the road, the two devices could record data simultaneously. For multi-sport events like the Triathlon, this could potentially be a significant boon as it would (a) provide redundancy, and (b) allow an uninterrupted log of both the cycling and running legs of the race. With that said, having both the CS600 and RS800 upgrade would likely be more expense than it is worth.

The downside to the CS600, however, is that their use of proprietary communications protocols means that it will only work with their own power meter. While I applaud them for the out-of-the-box thinking on it's design (it is basically a guitar pickup that monitors vibration in the chain), the indirect method of measuring power (vs the strain gauges used in other offerings) is prone to outside influences (eg road vibration) and it isn't as accurate. With that said, it is by far the least expensive way to get power measurement, and as I can't really justify a PowerTap or SRM as of yet, it is better than no data at all. Further, as Polar designed the power meter to explicitly work with this head unit, it is a much more elegant solution than what most of the other firms offer.

Adding to this complexity is that the CS600X has just been released, but doesn't appear to have made it to the retail channel as of yet. This model adds the capacity to work with the optional G3 GPS pod, and can store a tracklog of the route taken alongside with the speed and cadence data captured by the dedicated sensors. In addition, it more than doubles the quantity of memory available in the device - even with the extra GPS data, it can still store telemetry for a longer period of time than it's predecessor. Naturally, as it's a new product prices will likely be very close to the MSRP which is significantly higher than the street price that the CS600 has been selling at.

The other caveat is that, at least with the CS600 model, Polar Canada wasn't carrying the model bundled with the power meter. Back in December, I actually went out with the intention of buying one - but as I couldn't find that SKU anywhere in this country, I had to reconsider my options. Hopefully they've changed their minds with the CS600X, but if they haven't then that changes the equation slightly (as it basically eliminates one of the major advantages of this model, as buying the power sensor separately is too expensive for me to justify). Importing it from the US is one option, however it appears that any warantee issues would have to go back to Polar USA so that's a bit of a risky proposition.

Garmin Edge 705

An extremely impressive bit of kit, the Garmin Edge 705 offers a number of features that no competing solution provides. Most notably, with the purchase of optional maps, it can double as a navigation device which would be a pretty significant aide when doing long rides out in the middle of nowhere. While the route guidance feature is a bit sketchy, the ability to pull up a map on demand and figure out exactly where you are could be extremely useful. Further, the large colour display provided for this function also allows you to display up to eight pieces of information at any given time (vs 3 on the Polar) so less button pushing would be required when out on the road.

The use of a micro-SD flash memory slot also means that this product has significantly larger capacity to store training data before it must be uploaded. The onboard rechargeable battery limits any individual ride to about 13 hours (Garmin quotes 15h, but most reviews seem to indicate 13h is more typical), but that is still significantly longer than the 3h20m recording time of the CS600X with all options turned on (5h40m without GPS). The downside to this, however, is that the battery is not field replaceable, so as the cells age this life will begin to fade. It also means the annoyance of having to deal with battery charging (vs just grabbing a new battery every six months with the CS600X).

In addition to this, Garmin's use of the open ANT+Sport protocol for communication with various sensors means that it can double as a head unit for most aftermarket power meters (including PowerTap, SRM and Cinqo products). These sensors use strain gauges to measure power output directly (PowerTap at the rear hub, and SRM and Cinqo at the cranks), so they are more accurate than the indirect sensors that Polar uses. The downside, however, is that the cheapest of these options costs more than $1000 on it's own, so on top of the price of the Garmin (~$600) that's well outside of my range. While power measurement isn't really critical, it is something that would be very helpful at this stage of my training.

The catch, however, is that using this device would mean having to use different software to analyze the resulting telemetry. Aside from the annoyance of dealing with two pieces of software to do the same thing, it also means that my training data for the two sports would be separated and attempting to analyze things in a holistic manner would be difficult. There are some aftermarket packages that can work with files from both devices, however from what I've seen they don't seem to offer all of the functionality that Polar's excellent ProTrainer software can provide. With that said, I've done some digging on the file formats used by both products and I might consider writing something up to convert the Garmin files into something that Polar's software can read.

The other thing that concerns me with the EDGE is that there appears to be some stability issues with the firmware used in the device. This product is a much more complicated device than those offered by Polar, meaning that there are a lot more things that can go wrong with the software running on top of it. Garmin, unlike Polar, offers periodic firmware updates to address issues as they come up, but they don't appear to have ironed everything out as of yet. While I can certainly deal with some quirkiness, any possibility of losing training data is a catastrophic defect in a device like this. Unfortunately, internet-based fora tend to over-represent the population that is having trouble with a product so it's difficult to tell if these are isolated issues or problems with the underlying design.

Lastly, the HRM strap that Garmin provides is not capable of recording R-R heart rate data like Polar and Suunto's offerings. This isn't a huge thing, but there are a number of aftermarket analysis products (such as FirstBeat) that can use this data to aide in training. Naturally, the per-second data that Garmin does provide is significantly more important, however the loss of this additional information is a bit of a liability. The other catch is that Garmin's HRM straps use hard plastic/metal sensor pads rather than the textile pads used by Polar, so it's likely to be less comfortable than what I've got.

With that said, this last defect could be addressed in future firmware upgrades by simply adding support for Suunto's HRM straps. As they use the same ANT+Sport protocol as Garmin, the hardware that is necessary for this is already there - it's just a matter of adding the necessary firmware to communicate with these devices and store the additional data to file. I definitely wouldn't mind paying for another strap to get this functionality back, but unfortunately that isn't an option at this juncture.

Suunto T6c

Not really a front runner, but something that I am peripherally considering. Like the RS800CX, this is a watch-based unit and carries the same caveats. The advantage that is has over the other options, however, is that it's better suited to multi-sport events. Primarily, Suunto offers an optional 'memory belt' HRM strap that stores heart rate data onboard in addition to transmitting it to the wrist unit. As such, it is the only product on this list that can provide heart rate data from swimming. Further, the T6c also has the advantage of seamlessly switching between different sensors during a session, so no user intervention is required to go from swim to bike to run.

Choices...

Ideally, a device with the Garmin's hardware, firmware and software built by Polar and Suunto's sensor suite would be ideal - but unfortunately such a device doesn't exist ;) As such, I plan to continue digging for more information on these different products and try to figure out what the best course of action is for me at this juncture. At this point, I'm leaning towards the CS600X, but I could easily be swayed in other directions should I find compelling information on the matter.

I might end up picking up a Suunto memory belt either way if I do get into swimming, as it can be used independently of their watches and doesn't cost that much. I'll have to write something up to get that data into Polar ProTrainer, but as the data is structured in a similar way that shouldn't be a big issue.