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 ;)

Week 50: Winter Cometh...

It looks like the string of awesome weather we've been having over the last couple of months has come to an end :( I missed my Friday and Saturday rides this week as it was simply too cold out there. I can take it down to about 3C, but it was flirting with -1C on both of those days, and combined with the 30km/h wind generated on the bike that's a bit beyond my threshold. As such, I finally broke down on Friday and brought the bike into the shop to have it switched over to trainer duty for the winter. Was trying to hold off as long as I could, but with 15cm of snow forecast for Wednesday I figured this was pretty much as long as I could hold out.

Part of the issue is that I don't really have much in the way of proper winter clothing for the bike, as it only buys a week or two of extra time per year so it isn't really worth the outlay. The arms and legs are generally okay down to about zero even with my shorts/short sleeve jerseys, but the face and fingers are both pretty exposed any my running stuff doesn't really work on the bike. My gloves are too loose to fit underneath my fingerless cycling gloves, and despite my best efforts I've yet to find a pair of full fingered gloves with the padding necessary for long rides. As for the face, the neck warmer just gets in the way with my head tilted forward so there isn't much I can do on that front either.

Either way, I still havn't gotten around to cleaning off the bike and mounting it on the trainer but I will be doing that for a short ride on Wednesday. I'm not looking forward to spending hours on that machine in the coming months, but it's about the only way to avoid loosing cycling fitness over the winter. The one upside, however, is that it will allow me to get back to the consistency that I was training with in the summer - can't use the weather in the basement as an excuse ;)

Running-wise things went quite well this week as the colder temperatures can actually be helpful on that front. On Tuesday, I headed out with the intention of doing a 7 mile recovery run but I was feeling good and the conditions were near perfect so I stepped it up to a 4:45/km pace and did a 6 mile general aerobic run instead. On Wednesday, the half marathon group was doing a 4K tempo again so I went out with the 10K group to do some hills. The pace was pretty slow (only averaged 5:37/km), but otherwise it was nice to do some hill repeats again. On Friday, I followed that with my scheduled 6 mile run with ten 100m intervals.

Due to scheduling issues, I again moved my long run up to this morning and put in a good 16 miles. It started off with a bit of overcast, but within about 30 minutes it started snowing pretty heavily. Fortunately, it wasn't sticking to the ground and I didn't run into any ice, but in retrospect I should have brought along my sunglasses to keep the flakes out of my eyes ;)

As for swimming, we had our final clinic night last Monday and headed out for drinks afterwards. While we spend many weeks together during the clinic sessions, we didn't really get much in the way of time to just chat so it was good to get to know people better. Still havn't figured out what I'm doing on this front going forward, so for the time being I'll continue my own sessions and just try to work in some more drills to replace the clinic night.

Week 50 Totals:
Running: 61.1km (38.0mi)
Walking: 3.3km (2.1mi)
Cycling: 35.7km (22.2mi)
Swimming: 9.4km (5.8mi)
Total: 109.5km (68.0mi)

Year to Date:
Running: 2,491.0km (1,547.8mi)
Walking: 225.5km (140.1mi)
Cycling: 3,918.5km (2,434.8mi)
Swimming: 149.4km (92.8mi)
Total: 6,784.4km (4,215.6mi)

This week is likely to see the first significant snowfall of the season, with about 15cm of wet snow expected to fall. That's likely to make runs in the later half of the week a bit interesting, but fortunately as the bike is now inside it shouldn't effect my cycling mileage. The cold is likely to persist as well, but that's easy enough to deal with by selecting appropriate clothing for the conditions. I'm more concerned about runoff from the melting snow freezing and making the pathways icy, but that's just a part of the equation of running around these parts.

Tentative Schedule:
Mon 16mi LSD*
Tue 2.5mi Swim, 7mi Recovery
Wed 30K Ride, 6mi Recovery
Thurs 2.5mi Swim, 7mi GA w/10x100m
Fri 50K Ride
Sat 4mi Recovery, 80k Ride
Sun 16mi (25.7K) LSD
* Counted towards this week's mileage, as it was simply postponed from yesterday.

While I was down at the bike shop getting it switched over, I took the opportunity to check out the aerobars that they offer and ask a few questions. As they're likely the ones that will be doing the fitting to get everything set up correctly, it's my preference to buy the equipment from them so it's easy to return if there is a fitting issue with my eventual choice. They had a number of the units that I was looking at (Profile Design T2+, T2+Cobra, T-Mag and Sonic CSX), and gave me a rough idea of the cost of the other parts I'd need (Tri-specific saddle at ~$150, reversable seatpost head $30) and the modification to my fitting is included in my three year service plan. With that said, I'm still a bit partial to the design of the HED Clip Lite that has been recomended on a few fora so I'll have to head back there at some point to see if they carry it.

Thanks to the design of the bike I should be able to configure it in such a way that the fit should be comparable to what one could get with a dedicated Tri bike. Naturally, I won't be able to get the extreme drop that more aggressive Tri bikes like the Cervelo P3 offer, however I'm not entirely sure whether my back is flexible enough for that possition anyway ;) Ultimately I will eventually need to buy a proper TT bike for these races, but I figure that this will be a decent stepping stone to that point and should show dramatic improvements over my current road configuration.

The only concern that I do have with these plans is that between the bars and aerodrink assembly, I'm looking at between 1-1.5 pounds of extra weight on the bike. I'm normally of the it's cheaper to knock weight off myself than off my bike gear school of thought, but that's about a 6-9% increase in overall weight so it's not as insignificant as most upgrades. With that said, the decrease in drag when in the aero possition will likely more than offset that, but when I'm in group rides and have to use the road bars it may be a bit of a liability. Either way, I'm doing what I can to keep that penalty down as much as possible and there isn't a whole lot more I can do about it.


On the cycling computer side of things, I've gotten some additional information about the Edge 500 that has tipped me back to focusing on the older (but higher-end) Edge 705 model. I popped into a retailer that sells the unit on the way back from the bike shop and played around with the similar 605 model (they didn't have a display unit of the 705) and it's a pretty impressive little device one way or the other. Further, a recent firmware update (3.1) has partially dealt with the elevation issue that I was primarily concerned with (buggy GPS-based correction of the barometric altimeter data). It's a bit of a roundabout solution unfortunately (it still doesn't allow you to manually seed it directly, but it will pick up the elevation of the first waypoint in a planned trip), but it allows me to work around the problem well enough that it's not a huge sticking point.

I'm still flirting with the idea of the iBike Aero, however from a rational perspective I think the Garmin model is a better fit. I still love the idea of having both air and ground speed data for a ride, as that would provide an incredible ammount of information. Unfortunately, some of the critical design elements of the device still concern me significantly, such that the Garmin still looks to be a better overall computer.

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 ;)

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!