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