Garmin 800: First Look

In a standard display of Murphy's Law, shortly after I bought my Edge 705 last year Garmin announced the newer Edge 800 to replace it. The 705 is an incredibly powerful unit, but the concept was ahead of the technology available in 2007 so it was showing its age. This update brought to bear the advancements made since then, replacing the cumbersome joystick interface with a touch screen, adding a more modern and responsive user interface and a host of new features that have trickled into lower-end units over the last few years. It also addressed some of the primary concerns that I had with the 705, including the addition of a third telemetry screen.

After the announcement I was resigned to the fact that it wouldn't be worth the trouble and cost to make the upgrade. Fortunately, however, a friend that I ride with regularly was impressed by the 705 and offered to buy it. That opened the door to making the upgrade relatively easily with the added benefit of being able to help out a friend at the same time. As such, I picked one up as soon as it became available in this market (we Canadians always have to wait a bit longer than our neighbours to the south). The upside to this approach is that I will have both units for a short while, so I'll be able to compare them directly.


Overall Design

As I already had the sensors and maps from my 705, I elected to buy the basic unbundled package. Unlike the 705, the 800 isn't offered in a bundle containing the sensors but not the maps. Had such a mid-range option been offered I'd likely have grabbed it, as the fellow buying my old unit doesn't have the Cadence sensor yet and I wouldn't have minded switching to the new premium heart rate strap. With the maps included in the $650CDN bundle, however, it was cheaper to just buy those bits separately.

Fortunately, while the Canadian prices were substantially higher than the American prices for the Edge 705, the Edge 800 is a lot more competitive. The price is also a lot more uniform from retailer to retailer - while I usually don't mind paying a premium from my LBS, with the 705 there was a nearly $300 difference over the radio shop I ended up buying it from. With the 800 though, prices are all within about $50 of one another ($450-500CDN) so I'm guessing that Garmin is doing a better job of leaning on their distributors to not rip off the little guys.


Inside the box is the unit itself, mounting kit, combined power brick/USB cable and a handful of basic documents. Rather than a CD like the 705, the user manual and software are actually stored on the flash memory of the unit itself. As I never really bothered using the CD with the previous unit (easier to download a newer version from their website) that makes a lot of sense. While it does use up some space, it means that you'll never have to look for the box when you need to look something up (and if you don't want it you can always just delete the files).


The one thing that I was a bit disappointed with was the new power brick and USB cable. The 705 came with two separate cables (left side of following image), both relatively heavy gauge and about 1.5 feet long. With the Edge 800, however, they used a combination set (ie the power brick has a USB connection rather than an integral cable - see right side of image) with a cheap six inch cable. It certainly works reasonably well, and is a bit more compact, but the quality is not up to what its predecessor offered.


On the upside, they were quite generous with the mounting hardware including two full mounts and 14 attachment bands (7 large and 7 small). The 705 came with two mounts as well, but one was for a stem mount and one for a handlebar mount so it didn't offer as much flexibility. While I was a bit concerned about the elastic band design of the mount, having actually seen them in person they're much heavier duty that I imagined and I don't see it being a problem. Time will have to tell how well they compare to zip ties, but so far so good.

Getting back to the unit itself, the use of a touch screen rather than mechanical switches like its predecessor means it is a much sleeker overall design. In contrast with the 705's seven buttons and a joystick, the 800 sports only three physical buttons - a power switch on the side, and a pair at the bottom of the front face (lap/reset and start/stop). The rest of the functionality is handled by menus on the touch screen, but those simple buttons cover most of the actions that will be needed while underway.

The buttons themselves are made out of a hard plastic rather than the soft rubber that their predecessor used. They do appear to be better built and will likely be more robust over the long term, but the increased force required to actuate them and their smaller physical size makes them a bit more difficult to use while moving. That's likely a trade-off for making the unit as small and light as it is, but I likely would have preferred a slightly larger/heavier unit to get the easier to use buttons.


The flaps covering the microSD and USB ports on the back of the unit have also been improved significantly. The USB port cover on the 705 (top left corner in the following photo) was pretty flimsy and it was hard to be sure that you had a good seal. The microSD card slot was placed below a simple plastic cover (bottom centre just below the FCC logo), which while plenty secure had no o-ring to seal it in. On the 800 both ports have been moved to the very bottom of the unit (where they'll see less moisture to start with) and have much more substantial seals around the ports (see below). Further, the rubber gasket covering the ports is now connected by two exposed screws so if it ever breaks (mine never did, but I've seen lots of reports of it happening), it should be easy enough for the user to replace it.


One of the biggest improvements that the Edge 800 offers over the 705 is the new mounting mechanism. The 705's slide and lock mount (bottom of the image below) was pretty flimsy and, considering the value of the unit, always left me a bit concerned. Aside from the cheap feel of the plastic used in the mounting harness, the latching tab was a bit finicky so one had to be very careful that it actually engaged when mounting the unit. Further, getting the 705 off was a bit annoying as I had to reach under the aerobar extensions to flip the release lever. It got the job done, but it didn't exactly instill confidence.


The Edge 800, on the other hand, uses the excellent quarter turn mounting mechanism shared with the Edge 500 and the Forerunner 310xt's quick release kit. As such, in addition to being substantially more secure than the 705's mount (and offering a very positive click when it locks), it also means that you can share a single mount with those other units if so desired. I've been tempted by the 310xt for a while so that I could use the same HR strap for both cycling and running during actual races, so the ability to share a mount is a pretty significant plus. Further, as it is compatible with the 310's quick release wrist band, it is possible (although still kludgy) to use the 800 while running.


The only downside to this mount design is that the unit needs a good amount of clearance on both sides. As unlatching it requires the Edge to be rotated a full 90 degrees, any obstructions near the mount can make it impossible to attach/remove the device. On a pure road bike this isn't a big problem, but as I've got clip-on aerobar extensions flanking my stem this design meant that the Edge 800 couldn't be mounted where my 705 used to be. It's not a huge deal as I just grabbed a computer mount for my aerobars and stuck it a bit further ahead, but it was nonetheless a bit of an annoyance as the stem was a better position for me.

On the topic of the mount, I should quickly mention that the speaker opening is now placed in the centre of the mounting latch (presumably to better protect it from the elements). While the overall volume level of the 800 is actually a little higher than that of the 705, the new design appears to be a lot more focused. As such, the warning chirps generated by the device aren't quite as audible as the mount ends up muffling the sound a lot when on the bike. At low speeds that's not much of an issue, but when the wind is blowing by one's ears it is a lot easier to miss the tones than it was with the 705.


Touch Screen

One of the most central components to the design of this model is the replacement of physical control buttons with a touch screen display. As such, the performance of this core component is absolutely critical to the usability of the entire device. Touch screens open a lot of doors to designing unique user interfaces, but when implemented poorly they can make using a system a painful process. When done right, however, they can be an absolute joy to use.

Garmin appears to have used a resistive touch screen display rather than the capacitive displays that have become so popular on modern electronics. This means no multi-touch gestures like pinch-to-zoom or two finger rotation, but in return for those sacrifices it is capable of detecting any object that produces pressure on the screen surface. As such, gloved fingers and sweaty hands won't cause any problems with this device, and given the hostile conditions we often ride in that's a pretty critical feature.

The display does offer pretty robust swipe gestures (rare for resistive displays), facilitating quick navigation of the device's interface without having to pick off tiny buttons. The various workout displays can be navigated through by a quick swipe left or right, allowing a moving rider to quickly pull up additional information without having to look closely at the screen. Further, complex menus can be intuitively scrolled through by swiping up and down, which is a lot faster than pecking at the small up/down buttons offered.

With the joystick interface of the 705, tasks like entering an address into the navigation interface were extremely time consuming as you had to manually move the cursor from letter to letter. In these circumstances, the Edge 800's on screen keyboard is a major step forward as you can quickly type in long strings of letters. Using a qwerty order rather than alphabetic sequencing would have made it even faster, but either way it's light years ahead of its predecessor.

With all of that said, where the touch screen really shines is manipulating the map displays (see above) in the unit. On the 705, panning was handled by a five-way joystick (ie no diagonal motion) and zooming handled by buttons on the top-right edge of the unit. Combined with its slow processor, examining the maps was often a painful process - panning up a bit, waiting for the screen to redraw, panning up more, waiting, panning to the left, etc. With the 800, however, the process is downright pleasant. Panning is done by simply placing your finger on the map and dragging it, and redraws are done in pretty much real time so there is no waiting. Zooming is handled by the plus and minus buttons on the top right and left of the screen which, while not as convenient as the pinching mechanism of multi-touch devices, works quite well.

The only issue that I've had with the touch interface is that it seems to be a bit less responsive when it gets cold out. It hasn't missed a beat for me on warm days or indoors, but the last few days have been below freezing and it has required a couple of attempts before responding to a command on a number of occasions. With that said, I haven't used it for long enough at this point to be sure that it's actually the display and not just my numb fingers causing the problems.


Despite the overall unit being smaller than its predecessor, the display is actually slightly larger than the one on the 705 (2.6" vs. 2.2"). Additionally, looking at the units side-by-side the 800's screen appears to offer improved contrast and brightness (when the backlight is set to full). Whites are also noticeably more pure and colours are significantly more saturated making the map screens much easier to read. It does, however, have a glossier finish that may be an issue when dealing with harsh sunlight (unfortunately around these parts sun is pretty rare this time of year, so I haven't had a chance to test that as of yet).

As seen in the image above, one major change that they have made in this unit is the use of anti-aliasing on the text used throughout the interface. Doing this gives these displays a crisper look and often makes small type more legible compared to the bitmapped text of the 705, however it also makes letters and numbers a bit bolder and can make things appear softer. I personally prefer this design to the old-school look of the 705, however a number of people have expressed concern that it makes the display harder to read. I can't say that I concur with that at this point, but if your vision isn't 100% it might be worth checking it out in person to be safe.

The one thing that I was a bit disappointed with is that Garmin hasn't increased the resolution of the screen. The punchier colours and anti-aliasing mean that the readability of the maps is significantly improved over the 705, and for turn-by-turn navigation it offers more than enough detail (reading street names is likely not wise when rolling). Unfortunately, when stopped and manually browsing the maps (eg figuring out a detour) the 240x160 display doesn't provide a lot of real estate to work with. Getting street names often means zooming right into the local area, which in turn translates into a lot of fiddling to get the information that you're looking for (zoom out, pan, zoom in, repeat...). Naturally, the touch screen makes this a lot more pleasant than it was with the 705's joystick, but not having to do it in the first place would be a big improvement.

The above screen shots provide a good example of this issue. There is plenty of physical space to fit names on those roads, but the low resolution of the display means that it doesn't have enough pixels to render them legibly so it leaves them out. Moving to the 200-300ppi displays commonly used on smart phones (vs the 800's 109ppi) would easily remedy this, allowing more detail to be provided on the maps and making the utility of this feature immensely more significant. Given that the mapping functionality is the main justification for this model costing 50% more than the Edge 500, adding a high density screen to make that feature more useful would make the leap a lot easier to justify. Note that the above maps are shown with detail set to the maximum level and font sizes set to their minimum.


Exercise Displays

As with the rest of the products in Garmin's Edge line, the main interface element that will be used are the telemetry displays that provide the readouts during a ride. As sophisticated as the 800 is, these very basic displays form the core of any cyclocomputer and are what the user is likely to be looking at most of the time. Like its predecessor, all of the pages presented by the device are fully customizable - allowing the selection of not only which fields to display, but also how many of them (up to 10 with the Edge 800, up from 8 in the 705). Further, if desired these fields can also be added to the map display so that a basic dashboard view is still available when navigation is necessary.

As noted earlier, one of the complaints that I had with the Edge 705 was that it only offered two customizable pages of telemetry data. Having come from a Polar device offering six pages, I was used to setting each of them up for filling a specific role - providing just the bits of information that I needed for the task at hand (eg cruising, climbing, speedwork, cadence drills, etc.). The 705 allowed for up to eight fields per page, so it could provide a lot of information on those two pages, but the clutter of all that data at once made it much harder to parse at a glance. As such, I was basically forced to set up one page for the basic information that I'd need when riding (speed, cadence, heart rate, distance and time) and another for examining totals and averages when I came to a stop (using all eight fields).


With the addition of a third screen on the Edge 800, however, I was able to set up a second page for use in other contexts. Further, as the larger screen now allows two additional data fields I was able to pack more information on the summary page that I set up (when stopped, the clutter isn't much of a problem). Either way, I'd still like to see more pages made available as it's purely an artificial limit and adding them really has no downside (the 800 allows you to hide any unused pages). With that said, the addition of the third page and the two additional slots certainly are a major improvement.

Like its predecessor, all of those data fields can be customized by the user from a plethora of options. Setting up the 705 was a bit of a pain, as all of the fields were in one big list and paging through them one-by-one to find what you wanted was a slow process. Thankfully, with with Edge 800 Garmin has grouped the settings so that you can drill down to what you want without having to go through the entire list. The following is a list of all of the fields available on the 2.0 firmware release (what the unit came with):

• Cadence - Instantaneous readout of crankset revolutions per minute.
  
• Cadence Average - Average cadence over the entire ride.
  
• Cadence Lap - Average cadence during the current lap.
  
• Calories - Estimated amount of energy (in kilocalories) consumed during this ride.
  
• Calories (Fat) - Estimated amount of energy drawn from fat stores during this ride.
  
• Course Point Distance - When riding a pre-programmed course, the distance from the current location to the next course point (generally the next turn instruction).
  
• Distance to Destination - Distance from the current location to the end of the current course.
  
• Distance to Next - When using the navigation subsystem, the distance to the next instruction.
  
• ETA at Destination - Estimated time that you will arrive at your programmed destination.
  
• ETA at Next Waypoint - Estimated time that you will arrive at the next waypoint in a pre-programmed route.
  
• Heading - Written compass bearing of your current motion (eg N, NE, etc.).
  
• Time to Destination - Approximate amount of time before reaching your programmed destination.
• Time to Next - Approximate amount of time before reaching the next instruction on a navigated path.
  
• Distance - The total distance covered during this ride.
  
• Distance (Lap) - The total distance covered on the current lap.
  
• Distance (Last Lap) - The total distance covered on the previous lap.
  
• Odometer - The total distance covered by the selected bike profile.
  
• Elevation - The current elevation above (or below) sea level.
  
• Grade - The percentage grade of the road that the bike is currently traveling on (only reported when moving).
  
• Total Ascent - The cumulative number of feet/meters climbed during this ride.
  
• Total Descent - The cumulative number of feet/meters descended during this ride.
  
• Vertical Speed - Instantaneous readout of climbing rate (feet or meters per hour).
  
• Vertical Speed (30sec) - Thirty second rolling average of climbing rate.
  
• Battery Level - Graphic indication of battery level (unfortunately no percentage readout).
  
• GPS Accuracy - Current margin of error in position information calculated by the GPS chipset.
  
• GPS Signal Strength - Strength of the GPS signals that the unit is currently receiving.
  
• Sunrise - Estimated time when the sun will rise given the current location of the device.
  
• Sunset - Estimated time when the sun will set given the current location of the device.
  
• Temperature - Current temperature reading of the sensor integrated into the altimeter.
  
• Time of Day - The current time of day in the specified format.
  
• Heart Rate (bpm, %HRR or %Max) - Instantaneous heart rate reported in either beats per minute, percentage of heart rate reserve or percentage of maximum heart rate.
  
• Heart Rate Average - Average heart rate over the entire ride.
  
• Heart Rate Lap (bpm, %HRR or %Max) - The average heart rate over the duration of the current lap.
  
• Heart Rate to Go - When using a heart rate target, this field will display how far the wearer is above or below the specified range.
  
• Heart Rate Zone - Reports the current heart rate zone being reported by the HRM (eg 3.2).
  
• Power (watts, %FTP) - Instantaneous power readings reported in either watts or percentage of functional threshold power.
  
• Power 30sec Avg - 30 second rolling average of power readings.
  
• Power 3sec Avg - 3 second rolling average of power readings.
  
• Power Average - Average power output over the entire ride.
  
• Energy (kJ) - The total amount of energy output by the rider over the entire ride.
  
• Power Lap - Average power output over the current lap.
  
• Power Maximum - Maximum power output reported over the entire ride.
  
• Power (Watts/kg) - Instantaneous watts per kilogram being output by the rider.
  
• Power Zone - Current instantaneous power zone being reported.
  
• Speed - Instantaneous speed being reported by either the GSC10 or GPS.
  
• Speed Average - Average speed over the entire ride.
  
• Speed Lap - Average speed over the current lap.
  
• Speed Last Lap - Average speed over the previous lap.
  
• Speed Maximum - Maximum reported speed over the entire ride.
  
• Speed Zone - The current speed zone being reported.
  
• Number of Laps - The total number of laps currently recorded during this ride.
  
• Time - The quantity of time that the timer has been actively running.
  
• Time of Average Lap - The average time taken per lap.
  
• Elapsed Time - The total amount of time since the Start button was first pressed (ie includes any breaks).
  
• Time of Current Lap - The amount of time consumed during the current lap.
  
• Time of Last Lap - The amount of time consumed during the previous lap.
  
• Calories to Go - When a caloric target is set, the number of Calories remaining until it is met.
  
• Distance to Go - When a distance target is set, the remaining mileage left to be covered.
  
• Reps to Go - Number of repetitions remaining in a pre-programmed workout.
  
• Time to Go - When a time target is set, the quantity of time remaining.

With that said, the one thing that I'd like to see added to this list are a few visual tiles rather than simply offering numeric readouts. Being able to work some real-time plots of key parameters (eg heart rate or power) alongside the numeric readouts would be quite handy to give an idea of trends. When climbing, for instance, I generally don't have much time to be looking down at the display - but when I hit the top it would be nice to have a quick at-a-glance look at how hard I worked.

My hopes were up when I saw a 'HR Graph' field in a table from another review, but as that was with a pre-production device I'm guessing that it was pulled before release (the groupings appear to have been changed since then as well). Doing so would certainly use more processing horsepower than the simple numeric tiles, but it would need nothing remotely close to what the moving map requires. Given the gorgeous colour display offered in this model, this is the type of unique feature that could really help to set it apart from competitive products.

It would also be extremely handy if the numeric displays could generate colour coded backgrounds when targets are set for the specified parameter. That is, if a heart rate target is set - change the background to red when one is above the target and blue when below it. It's a little thing, but such a visual cue would allow the rider to passively glance down after hearing an alarm and determine exactly what they need to do.


Garmin also worked a number of small touches into the new unit that offer welcome additions to its functionality. For instance, granular control of the units used by the device allows it to be better configured to meet the needs of the user. With the 705, it was an all-or-nothing choice between metric and imperial measures - if you wanted distances and speeds in kilometers, you had no choice but to have everything else in metric as well. While Canada theoretically only uses the metric system, there are certain measures (eg altitude, body weight, height, etc.) that for one reason or the other are almost exclusively stated in imperial units. While not a huge thing, it's a very nice touch that allows individuals to select the measures that they are most comfortable with.

Another nice touch is the addition of an auto scroll feature that has been offered in lesser models in the past, but is new to this particular market segment. When enabled, the display on the head unit will automatically flip between the various pages so that the user can see all of the data available without having to fiddle with buttons. For my requirements I don't really see myself using this a whole lot, but I can certainly see situations where it may be helpful so the option is a welcome one.


Originally added in the Edge 500, another significant addition is the optional Start Notice feature. When enabled, the device will generate a warning whenever it detects motion but the timer is stopped. I've certainly restarted my ride after a break without remembering to hit my 705's start button on a number of occasions, resulting in a big gap in my exercise data for that session. In those circumstances this feature would have caught that immediately, and I would likely have all that data that I failed to record.


Data Recording

As important as the real-time displays are, the ability of these devices to record all of that telemetry for later analysis is even more critical. The Edge 800 can capture a huge amount of data during a ride, and the ability to pull it up on a computer after the fact in order to analyze performance is one of its biggest assets. For the most part, the new unit works in a manner very similar to its predecessor, but there are a few important changes.

The most obvious of these modifications is a switch from using the XML-based .TCX format to the binary .FIT format. The downside is that support for the older format is more widespread in third-party software, but thankfully that is becoming less and less of an issue as its use in the Edge 500 and Forerunner 310xt means that it is being added to most packages going forward. The upside is that this new format is substantially more efficient and produces much smaller file sizes (~20X) - making managing logbooks and uploading files to online services easier.

Along with this switch, Garmin reduced the amount of on-board flash memory from 512MB to 105MB. Fortunately, the reduced size of the activity files more than offsets that difference as the effective recording time is still about 1,500 hours. If, for some reason, that isn't enough the Edge 800 also adds the capacity to store activity files directly on the memory card (the 705 could only use it for maps). With a 16GB card, for instance, you'd still have about 30 years of uninterrupted recording time available. With that said, the one downside to this reduction is that it basically means you have no choice but to buy a microSD card if you want maps (which haven't gotten any smaller).

Another big improvement in the Edge 800 is its use of a new heart rate based caloric computation algorithm that was first made available in the 405CX. The Edge 705's caloric estimates were pretty much useless as they were always laughably higher than they should be. Garmin's older algorithms were hamstrung by patents governing Calorie calculation based on heart rate data, so they relied soully on speed and distance data for their computations. Fortunately Garmin recently elected to drop this method and license a more robust algorithm from Firstbeat for their units going forward. That decision appears to have been a good one, as the Edge 800 now generates numbers in the same basic ballpark as my Polar unit provides (whose values I relied on when I was working on my weight, so I know they're pretty much bang on for my physiology).

The recording of altitude information also seems to be significantly improved on the Edge 800. The barometric altimeters used in the Edge series are much more accurate instruments than the GPS-based mechanism used in their Forerunner line, but the values are sensitive to drift caused by changes in barometric pressure triggered by passing storm systems. As such, Garmin has long used GPS altitude data to detect and work out those errors. With the 705, that system would often cause more trouble than it would fix, but fortunately from my experience with the 800 so far it is producing much better results. Adding to this, Garmin has also incorporated the long requested option to manually seed the starting elevation if so desired.


Unfortunately, along with these steps forward Garmin made one major step back by removing the option to disable their 'smart recording' feature. When enabled, this system records samples as it deems necessary rather than at a fixed one second interval. This helps to make file sizes smaller, but given the minuscule size of the new .FIT files there is little need for that (especially given the ability to store them on multi-gigabyte microSD cards). The downside is a more course recording of telemetry that flattens out a lot of fine details captured by devices using a more conventional recording technique (which has been clearly evident on the sessions I've done with both the 705 and 800 on my person).

With the 705, smart recording was the default but there was a menu item that allowed the user to force the device to record at fixed intervals. Unfortunately, Garmin removed this in the Edge 500 and that mistake has been carried forward with the Edge 800. Smart recording is thankfully disabled when a power meter is fitted, but for any user (such as myself) who doesn't currently have one we're stuck with it on.


Connectivity

Like its predecessor, the Edge 800 acts as a USB mass storage class device and thus doesn't require any drivers. That is, when connected to a computer it simply appears as a new drive (or two if a microSD card is installed) and is immediately ready to use. As such, if desired both devices can be used without installing a single piece of Garmin software on your computer. All of the telemetry can be accessed by grabbing the .fit files from the Garmin/Activities/ folder, and other files (courses, workouts, etc.) can be loaded by simply copying them to their respective locations. Naturally, Garmin's software does make the process simpler (it handles all the file management for you), but if you don't have access to your own computer and need to upload some exercise files it's nice to be able to quickly plug it into any available computer and get the job done.

The Edge 800 does offer a few differences compared to its predecessor, however. Unlike the 705, the 800 can't natively use the older .TCX and .GPX files - instead relying on .FIT for all of the functions they used to provide. Thankfully, however, Garmin added a handy 'NewFiles' folder that users can just drop the files into and it will sort it all out once the Edge is disconnected from the computer. If any files in these older formats are placed there, the 800 will automatically convert them to .FIT files and move them to the appropriate location. As such, the unit does a great job of taking care of the dirty work and saves a lot of storage space in the process. While this isn't a huge thing, attention to details like this can make a big difference in the day to day usability of a device like this.


Additionally, if the user does elect to make use of Garmin's ecosystem, the device includes scripts that will offer to automatically direct them to the Garmin Connect website whenever the Edge 800 is plugged in. That site will then walk them through the process of creating an account and getting the latest versions of the software installed on their computer. As such, the process of getting the computer set up the first time is actually quite elegant and should be relatively intuitive for even the least computer literate users out there.

Unfortunately, just like the 705 the performance of the file transfer mechanism in the Edge 800 is not particularly stunning. Transferring .fit and .tcx files are fine thanks to their small size, but trying to load a multi-gigabyte map file onto the SD card is brutally slow. Thankfully, it's easy enough to simply remove the card from the Edge and load these big files via a conventional card reader before re-installing it. I haven't had a chance to play around with things to see if it is the USB or SD controller in the unit, but it is something that I really would have liked to see them address - especially with the Birdseye Satellite Image feature that this model offers (maps are pretty much load and forget, but the subscription nature of this service likely means frequent changes). As such, I would strongly recommend making sure that whatever microSD card one elects to buy comes with a sled to use it in an SD card reader.


Navigation

The main feature differentiating the Edge 800 from pretty much every other device on the market is its navigation and mapping capabilities. Automotive navigation products have become ubiquitous, so pretty much everyone knows the benefits of this technology. Applying it to a bicycle, however, poses a variety of unique challenges that Garmin had to face when designing the Edge 705 and now the 800. Getting this right is key to the value proposition of this device, as it is substantially more expensive than the otherwise similar Edge 500.

With that said, I'm going to leave this section brief as getting the unit this late in the season means that I haven't had a lot of chances to fully test out this feature set as of yet. As I'll likely be forced onto the trainer for the winter pretty soon, I'll likely have to make up another post in the spring when I get a chance to fully try out the new functionality. In the meantime, I'll provide some brief thoughts based on my experience with the 705 and what I've seen in my limited time with the Edge 800.


The simplest form of 'navigation' offered is the courses functionality that has been present on Garmin products for a while now. Courses are basically breadcrumb trails following a pre-determined route generated by a mapping website or from a previous activity. As such, all of the routing decisions are made ahead of time by whatever software generated the file and the Edge simply follows those directions. While many lower-end Garmins offer this functionality as well, the 705 and 800's ability to overlay the route over top of a street map is invaluable for situations where you have to go off route because of an obstruction.

Despite this simplicity, the advantage to courses is that you can decide exactly what path to follow. While automated routing engines are great for cars wanting to get from point A to point B as quickly as possible, a lot of additional considerations come into effect when cycling. For instance, the proportion of hilly versus flat terrain depends a lot on what you want to achieve with a specific training session, and the Edge has no way of knowing that. On a bike you are often starting and ending at the same place, so the specifics of the journey is a lot more important than the fastest/shortest route.

One other big advantage of the courses functionality with both the Edge 705 and Edge 800 is that they can provide a forward looking elevation plot as long as you remain on the route. Knowing exactly how long that hill is going to last, and precisely what the terrain looks like beyond the top is an invaluable piece of information to have at your disposal. It allows the rider to make better strategic decisions about how to budget their energy and how hard to attack a specific hill. Without this information, it's all too easy to go all out up a hill and then have nothing left when you realize there is another one right after it!

The 705's implementation of course-based navigation worked quite well the vast majority of the time, although sometimes on out and back legs of the route it could get confused and stop providing directions. The problem appeared to be connected to small drifts in GPS positions making the unit think that the rider was off route. When that happens, the Edge 705 simply waits for you to get back to any point along the route at which point it continues navigation from that point forward. Unfortunately, when both an outgoing and return trip run along the same stretch of road, sometimes it would lock onto the latter instead of the former. In that scenario, the next queued up instruction is in the wrong direction so you won't get any direction until you return to that point. Fortunately, the map display still shows the route line so you can easily navigate on your own when this happens, however it ceases to provide you with explicit guidance.

My experience with the Edge 800 has been flawless with courses so far, however given the rarity of the situation on the 705 I can't say that I've used it enough to know if that is just dumb luck or not. With that said, from the experimentation that I've done so far the handling of off course scenarios appears to be dramatically improved so I'd wager that this type of problem will likely be a lot more rare. On my last ride, for instance, I intentionally took a few short detours to see what it would do and it didn't miss a beat on any of them. I will have to play around a bit more to see how it handles more elaborate variations but so far it is looking like a big improvement.

The other advancement with the Edge 800 is the addition of a Turn Guidance mechanism to the courses sub-system. With the 705, the only instructions that you'd get on a course were the pre-programmed 'course points' prepared by the mapping software or website. These messages were simple text messages that could only be a few characters long, so 'Turn Left' was about as detailed as they got. The Edge 800 supports these as well, but it also generates detailed turn guidance messages on it's own (can be disabled, but is on by default). This means that you get complete instructions including street names, graphic icons overlaid on the map to indicate turns and a countdown display (see above) as you approach the intersection. This is a huge step forward, and makes using courses as easy as the inbuilt navigation routines.


In addition to the courses functionality, the Garmin Edge 705 and 800 both offer the ability to handle navigation tasks on their own as well. Like automotive GPS units, the rider can enter a destination and the Edge will use its maps to plot a route from the current position. Unlike courses, all of the decisions are made on the device itself and incorporate a long list of exclusions that you can specify.

Like the turn guidance in the courses mode, you get detailed lists of instructions, visual indicators overlaid on the maps and countdowns ahead of each turn. If you've ever used one of Garmin's automotive GPS units, the Edge 800 pretty much works in exactly the same way (which is a huge step forward from the Mapquest-style look of the 705). Although the small screen limits its utility, the new model even offers a 3D map perspective if desired (called 'automotive mode' it's disabled by default). About the only thing it doesn't do is give you spoken directions, but that's not really a big deal as wind noise would likely make that useless anyway.

The caveat, however, is that the routing algorithms used in the Edge 800 are basically borrowed from their automotive products and don't always consider bicycle-specific characteristics. They are smart enough to avoid unpaved roads and try to stay away from major streets, so the Edge isn't likely to put you in a dangerous situation, however it doesn't always select the optimal path. For instance, the unit might end up sending you down a hellishly hilly road because the flat one next to it was 100m longer (the city navigator maps don't have elevation data so it would have no way of knowing). It also seems to still use posted speed limits to determine which road will be faster, so it's likely best to configure it to find the shortest distance rather than the fastest (given that most of us can't pedal at 80km/h for very long).

Fortunately, you always have a map that you can look at and the unit will dynamically re-route when you make a wrong turn, so it's easy enough to navigate around problems on your own. While the 705 took ages to do those recalculations, the 800 does them within seconds so it's a lot easier to work with. Thankfully, the birdseye satellite images that can be loaded onto the Edge 800 promise to potentially make this task a lot easier (photos tell you a lot more about the road ahead than any map), but I haven't had a chance to play around with that much as of yet.

With all of that said, while I wouldn't use this functionality to plan out an entire ride, it is an extremely valuable asset when you are in unfamiliar territory and need to make a change. The exhaustive list of points of interest is especially valuable, as if you find yourself in need of more water than you originally brought along, being able to pull up a list of all of the nearby convenience stores and immediately plot a route to one of them can come in very handy. It's also quite helpful in scenarios where the weather is unexpectedly changing on you and you need to find the quickest way home.


Mapping

While the ability to help to direct the user along a specified route is indeed a handy feature to have, to me the biggest benefit to these devices is the fact that I can pull up a map whenever I want. If the weather out is great and you want to add a bit more distance to your ride, it's a cinch to pull up the map display and figure out how to do that. Given training rides can easily cover more than a hundred miles, we often get pretty far away from our base and it's impossible to know each and every road. Further, having this capacity encourages more variety in route selections, as you never have to worry about getting lost.

As mentioned above, one of the major new features offered by the Edge 800 is support for Garmin's Birdseye satellite imagery. Maps do a good job of telling you where the roads go, but satellite photos provide a lot more detail about what those roads look like. Riding under a tree canopy is a lot different than riding past open fields on a windy day, for instance, but maps won't provide you with that kind of information. As such, this feature alone has a lot of potential to make this mapping capacity even more useful.

While many riders have smartphones that can do this sort of thing, when riding out in the country cellular service can sometimes be a bit spotty. While it's rare to completely lose service, trying to download satellite image tiles over a 2G connection can be a painful process. With the Edge 800, however, all of the maps and satellite images are stored locally and will pop up at a moment's notice. Further, as the device is bolted to your handlebars you don't have to try and memorize all the turns that you need to make to get where you want to go.

With that said, the utility of the Birdseye feature is somewhat crippled by the artificial limits on the number of tiles that can be loaded at any given time. I haven't really had a chance to play around with it enough to determine the severity of this issue, but I'm hoping that Garmin lifts those limitations before spring rolls around to unlock the full potential of this feature. With this in place, however, smartphones have a potentially significant advantage here as they don't require strategic selection of which areas to cover. If a more expensive tier of their subscription service is required to facilitate this (at $30USD/year, I can certainly see bandwidth costs being an issue), than so be it - I'd rather pay more than try to work around a crippled feature.

The other handy feature offered by the Edge 800 is Garmin's custom maps capability. This overlays an image file that you generate over the map, so you can easily set the device up to show things like trail maps or race course diagrams (ie where aide stations are, hill classifications, etc.). I haven't had a chance to play around with this much as of yet, however when spring rolls around this is definitely something that I intend to do a lot of experimenting with.


Documentation

Maybe I'm old fashioned, but when I buy a new piece of equipment the first thing I do after plugging it in to charge is dig out the manual and read it cover to cover. When a product comes with a well written manual, by the end of that process I should be able to pull out the device and know exactly how to make full use of every facet of its design. I should know exactly what it is capable of, and exactly how to access all of those facilities. Unfortunately, that is a very rare thing in this day and age as proper technical writing is becoming a bit of a lost art. Most products nowadays come with a pamphlet that does little more than get you up and running, leaving the user to fiddle around with the device to figure stuff out on their own.

Just like the Edge 705, the 800's user manual is no exception to this rule. The provided documentation barely skims the surface of the deep feature set of this powerful device, leaving the user to fumble around and figure out how things work. It does a decent job of getting you up and running, but even the most advanced users will have to do a lot of playing around to figure out exactly how everything works.

For instance, after my first session with the 800 I wanted to adjust the vertical scale of the elevation chart to get a closer look at my workout before resetting the timer. With the 705, this was done by pressing the joystick up or down but obviously that wasn't a choice on this touchscreen device. I tried swiping up and down to no avail, then looked through the menus to find a way to adjust this. As I had no luck with that, I pulled up the manual but it had absolutely no mentions of this display let alone how to adjust it. After a bit more fiddling I figured out that it was done by taping the scale indicator in the top-left corner of the screen, but a simple single-line mention of this would have saved me a lot of time. Had I not used the 705 before I likely would have tried that sooner, but then again I likely wouldn't have realized that the scale could even be manually adjusted.

After a while this will become less and less of an issue as other people will ultimately run into the same problems and you can search for solutions on their official fora. With a new product, however, such resources haven't matured yet so you are often left to figure it out on your own. Regardless, many buyers of this product don't even know about the existence of that resource and will likely not explore half of the features that this equipment offers simply because they don't know that they are there.


Summary

The Garmin Edge 705 was an extremely powerful device and the Edge 800 continues that tradition as the flagship of Garmin's line of fitness products. While the 705 was largely a revolutionary product adding features to the bike computer that no other product even came close to, the 800 is more of an evolutionary step forward along that path. In effect, the Edge 800 is to the 705 as Google Maps is to Mapquest - it performs the same fundamental tasks, but it just does them in an elegant way that makes them much more useful. The technology available in 2007 severely limited what they could do at the time, but thankfully advancements in recent years have allowed them to put together a polished piece of equipment that lives up to the promise that it's predecessor tempted us with.

The difficult question is whether or not it is worth the cost and effort to make the jump from the 705 to the 800. Fundamentally, the decision really relies more on how much the oddities of the 705 get in your way. As noted above, the 705 can pretty much do most of what the 800 can - it might take a bit more patience and effort, but if you are willing to deal with that then sticking with what you've got is likely the best idea. If, however, certain aspects of the 705's design are getting in your way, the 800 does a great job of ironing out all of those quirks and just allowing you to get things done.

For someone coming to this market segment from simpler units, the main question you need to ask yourself is how useful you see the mapping and navigation features being to your particular set of circumstances. If you ride the same routes in familiar territory all the time, then those features will likely spend most of their time idle. If, on the other hand, you spend a lot of time exploring new ground, those maps can be a major asset. Aside from that, the Edge 500 does most of what the 800 can do, is smaller/lighter and costs about $150 less. Making the determination of whether those features make up for that additional cost is a question that no review can really answer for you.

Pros:
+ Additional customizable exercise page and the addition of two more fields per page.
+ Elegant and responsive touch-based interface with a larger full-colour screen.
+ Significantly improved bike mount compatible with other Garmin products.
+ MicroSD card slot can now be used to store exercise files.
+ Improved weather sealing over the USB and MicroSD ports.
+ Ability to load satellite image tiles onto the device itself in addition to street level maps.
+ Ability to produce custom map overlays to provide additional information on the map displays.
+ Improved algorithm for correcting altitude information.
+ Support for discrete wheel speed and cadence sensors (the 705 only supported combined sensors like the GSC-10).
+ Much better looking unit in a more compact package.
+ Temperature recording.

Cons:
- No method to disable smart recording feature without a power meter.
- Artificial limitation on the number of Birdseye tiles that can be loaded on the device.
- Incredibly slow file transfers to memory card makes loading maps unnecessarily painful.
- Reduced on-board flash memory means MicroSD card is necessary if you want any maps.
- No improvement in the resolution of the display.
- Smaller face buttons that require more force to actuate.
- Warning sounds are harder to hear than the Edge 705.
- Combined power adapter a step down from the cables supplied with the 705.


Firmware Wishlist

As noted above, many of my concerns with this device aren't related to the hardware itself and can potentially be addressed by future firmware updates. Garmin fortunately updates the firmware on their devices on a regular basis, so I figure that it's worth putting down a list of things I'd like to see modified on the off chance that something can be done about it. Some of these issues only require trivial changes, and some would require significant changes, so it's unlikely we'll see them all dealt with but it's still worth putting them on the record.

1. (Trivial) Restore the option to disable the smart recording feature and force a fixed 1Hz recording resolution. Given that the device already does this when a power meter is connected, it is just a matter of flipping a switch somewhere and would be a trivial thing to add. While smaller files are nice, given the massive recording capacity of these devices there really is no downside I can see to offering users the option of more detailed recordings.
   
2. (Moderate) Provide the capacity to add more user-configured training pages into the rotation. While three 10-field pages can display pretty much everything that I could need, I'd prefer to have a larger number of specialized pages to curb the information overload. As the device allows pages to be disabled for people who don't need them the option to add more wouldn't really make the device any harder to use. Further, since only one is displayed at any given time it shouldn't use any more resources.
3. (Moderate to Difficult) Remove the limitation on the number of Birdseye tiles that can be loaded into the device and bound it soully by how much room is available on the memory card. The usefulness of this feature is primarily for figuring out alternative routes when something unexpected comes up along a ride, so by definition we can't really predict which areas we are going to need. Given the massive amount of land area that can be covered on a 100+ mile ride, that's a lot of ground that needs to be covered. Further, expecting us to manually select the area for each and every ride is going to get tired quickly, so to be usable this system ultimately needs to be able to load up images for everywhere that we'd likely end up going (ie at least a 50 mile radius around the user's house). This may require some significant optimization work on the engine and/or file format used to store the tiles (so that it can rapidly find the specific tiles that it needs), but it's not an insurmountable task as only a small window has to be loaded at any given time (240x160 viewport, plus some caching of surrounding areas).
4. (Difficult) Add the capacity for visual tiles such as real-time heart rate plots to be added to the exercise displays. Additionally, add the capacity to colour code numeric fields when targets have been set (eg red when above target, blue when under, etc.).
5. (Difficult) Add a display similar to the elevation plot that shows overlaid historical telemetry plots for all major parameters (heart rate, power, speed, cadence and elevation). Given the colour display on this device, the ability to look back on the details of a ride (rather than just looking at splits) would make on-device analysis much more powerful. This can naturally be done on a computer after-the-fact, but it would be nice to be able to pull this up at a mid-ride lunch break to see how things are going so far.
6. (Trivial to Difficult) Adding advanced metrics like TSS, IF and Normalized Power would make analysis of rides on the device itself a bit more complete. Adding these features would draw a lot of potential customers away from competitive products like the Joule. Naturally the rub here is whether or not these metrics require licencing fees, as if they do adding them via a free firmware update would be unlikely.

Either way, if I could get the first three issues addressed I'd pretty much have everything that I'd want in a device. The last three would be great to have, but they're just icing on the cake. With that said, I'm not really holding my breath and I'd consider myself lucky if they just managed to hit one of them!


Further Reading

- DC Rainmaker's detailed first look review of the Edge 800.
- User manual for the Garmin Edge 800.
- Official product page for the Garmin Edge 800.
- Official Forum for the Garmin Edge 800.

Update (29-11-2010) - After experimenting a little more with the courses functionality of the device on the road, I made a few changes to the navigation section of the review. With what I've seen here, there are some substantial improvements to this area of the system and I hope to play around a bit more with them in the future.

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