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 ;)
Sunday, January 31, 2010
Weeks 3 & 4: Review
Didn't get around to posting an update last week, and when I eventually got around to it I figured it was better to just hold off and two both weeks in one article. Either way, week 3 went quite well and I was rebuilding back toward my normal mileage - culminating with an 8 miler on Sunday. Unfortunately, when I was getting ready to go to the pool on Monday morning I yawned and something popped back out of place in my back again. It wasn't nearly as bad as the issue the week before, but it did mean that I had to take more time off and am now just starting to get back into it.
Additionally, the plan was to bring the bike in to get the aerobars and computer installed this Tuesday. As the aerobars need a fitting, however, I figured that it was best to put that off as doing that with an injured back would likely be difficult. Since I need to get my rear tube replaced, however, that also meant that I can't really use the bike until I make that trip. I'm hoping to get it down there early this week, so hopefully I'll be able to restart my cycling and speed up my recovery (while the bike stretches out the back, there is much less impact than running).
Week 3 Totals:
Running: 46.8km (29.1mi)
Walking: 5.1km (3.2mi)
Cycling: 0.0km (0.0mi)
Swimming: 7.1km (4.4mi)
Total: 59.0km (36.7mi)
Week 4 Totals:
Running: 12.8km (8.0mi)
Walking: 7.4km (4.6mi)
Cycling: 0.0km (0.0mi)
Swimming: 0.0km (0.0mi)
Total: 20.2km (12.6mi)
Year to Date:
Running: 130.8km (81.3mi)
Walking: 17.4km (10.8mi)
Cycling: 0.0km (0.0mi)
Swimming: 15.7km (9.8mi)
Total: 163.9km (101.8mi)
Going forward, I'm going to have to be easy on things this week to ensure the back doesn't get re-injured again and throw me off. I need to start doing some core exercises to prevent this in the future, but I also don't want to push those muscles too hard until they are recovered so it's a bit of a balancing act at this point. I've got to get back to battle condition in two weeks if I want to use the 12 week program for Mississauga, but if that's not possible than I'll simply have to skip the Marathon this year and focus on Triathlon.
As for a plan, I'm likely going to have to wing it this week as it's going to depend a lot on how things feel. I'll probably do at least one more 4 miler before stepping back up to 6, and will likely hold off on going much longer than that until the following week to be safe. Naturally, only time will tell ;)
Additionally, the plan was to bring the bike in to get the aerobars and computer installed this Tuesday. As the aerobars need a fitting, however, I figured that it was best to put that off as doing that with an injured back would likely be difficult. Since I need to get my rear tube replaced, however, that also meant that I can't really use the bike until I make that trip. I'm hoping to get it down there early this week, so hopefully I'll be able to restart my cycling and speed up my recovery (while the bike stretches out the back, there is much less impact than running).
Week 3 Totals:
Running: 46.8km (29.1mi)
Walking: 5.1km (3.2mi)
Cycling: 0.0km (0.0mi)
Swimming: 7.1km (4.4mi)
Total: 59.0km (36.7mi)
Week 4 Totals:
Running: 12.8km (8.0mi)
Walking: 7.4km (4.6mi)
Cycling: 0.0km (0.0mi)
Swimming: 0.0km (0.0mi)
Total: 20.2km (12.6mi)
Year to Date:
Running: 130.8km (81.3mi)
Walking: 17.4km (10.8mi)
Cycling: 0.0km (0.0mi)
Swimming: 15.7km (9.8mi)
Total: 163.9km (101.8mi)
Going forward, I'm going to have to be easy on things this week to ensure the back doesn't get re-injured again and throw me off. I need to start doing some core exercises to prevent this in the future, but I also don't want to push those muscles too hard until they are recovered so it's a bit of a balancing act at this point. I've got to get back to battle condition in two weeks if I want to use the 12 week program for Mississauga, but if that's not possible than I'll simply have to skip the Marathon this year and focus on Triathlon.
As for a plan, I'm likely going to have to wing it this week as it's going to depend a lot on how things feel. I'll probably do at least one more 4 miler before stepping back up to 6, and will likely hold off on going much longer than that until the following week to be safe. Naturally, only time will tell ;)
Tuesday, January 19, 2010
Week 2: Review
As mentioned in my previous post, the back injury took out most of my sessions last week. I did a couple of easy 4 milers with an extended warm-up, as well as one easy 6 miler on Sunday to test out everything. Thankfully, all of those runs went well and the back is feeling quite good at this point so I'm planning on working on rebuilding from this point on.
The one odd thing that I did run into was that my heart rates were substantially higher than expected (~+15bpm) for minimal effort runs like this. While some loss of fitness happens in these scenarios, the heart rate didn't line up with the perceived effort. My first run back, for instance, was done at minimal effort levels and my breathing wasn't even slightly laboured. My heart rate, however, averaged 167bpm - which would normally take a full blown tempo effort to achieve.
I'm guessing that this is likely some kind of side effect of the muscle relaxants that were lingering in my bloodstream, but I'm still not sure. I did find some mentions of them lowering heart rate while you are on the medication, but nothing about it elevating them after going off. Fortunately, I did a 6 miler today (Tuesday) and my heart rate appears to have gone back to normal (10bpm slower than Sunday, despite a pace that was 15 seconds per kilometer faster) so whatever it was appears to have worked it's way out of my system. It's still higher than normal, but well within what can be explained by lost fitness.
Other than that there isn't a whole lot to report. I skipped my swimming sessions to avoid hurting things again, and missed my cycling sessions due to a blown tube. I'm back into the former at this point, but still have to get the bike back to the shop to get back into the latter.
Week 2 Totals:
Running: 22.5km (14.0mi)
Walking: 3.8km (2.4mi)
Cycling: 0.0km (0.0mi)
Swimming: 0.0km (0.0mi)
Total: 26.3km (16.3mi)
Year to Date (as of Jan 17th):
Running: 71.2km (44.2mi)
Walking: 4.9km (3.0mi)
Cycling: 0.0km (0.0mi)
Swimming: 8.6km (5.3mi)
Total: 84.7km (52.6mi)
I don't want to plan things too rigidly for this coming week as I will have to be careful not to overdo it. As mentioned above, I did do a slightly faster 6 miler this afternoon and that went well - so I'll be working up from there. With respect to the plan, I'm likely best switching over to Pfitzinger's 12-week program so that I can carefully build myself back up rather than trying to force myself back into an aggressive routine right away. I'm going to have to look over the race calendar, however, to make sure that it's suitable for what I'd like to do this season.
This Week (Tentative):
Mon 3.25K Swim
Tue 6mi Recovery
Wed 6mi Recovery
Thurs 6mi Recovery
Fri 3.25K Swim
Sat 4mi Recovery
Sun 8mi Recovery
In addition, I'm going to start working on re-introducting some core strength workouts into my routine again to avoid this problem in the future. I'm not a big fan of them, but it's obvious that the swim-bike-run exercises alone aren't doing a good enough job of building those muscles, so I will have to take special care.
I will also have to find the time to bring the bike in to get the tube changed as well as get those aerobars and computer mounted and fitted for me. As boring as indoor training is, hopefully having some new toys to play around with in the process will help to make it more interesting ;)
The one odd thing that I did run into was that my heart rates were substantially higher than expected (~+15bpm) for minimal effort runs like this. While some loss of fitness happens in these scenarios, the heart rate didn't line up with the perceived effort. My first run back, for instance, was done at minimal effort levels and my breathing wasn't even slightly laboured. My heart rate, however, averaged 167bpm - which would normally take a full blown tempo effort to achieve.
I'm guessing that this is likely some kind of side effect of the muscle relaxants that were lingering in my bloodstream, but I'm still not sure. I did find some mentions of them lowering heart rate while you are on the medication, but nothing about it elevating them after going off. Fortunately, I did a 6 miler today (Tuesday) and my heart rate appears to have gone back to normal (10bpm slower than Sunday, despite a pace that was 15 seconds per kilometer faster) so whatever it was appears to have worked it's way out of my system. It's still higher than normal, but well within what can be explained by lost fitness.
Other than that there isn't a whole lot to report. I skipped my swimming sessions to avoid hurting things again, and missed my cycling sessions due to a blown tube. I'm back into the former at this point, but still have to get the bike back to the shop to get back into the latter.
Week 2 Totals:
Running: 22.5km (14.0mi)
Walking: 3.8km (2.4mi)
Cycling: 0.0km (0.0mi)
Swimming: 0.0km (0.0mi)
Total: 26.3km (16.3mi)
Year to Date (as of Jan 17th):
Running: 71.2km (44.2mi)
Walking: 4.9km (3.0mi)
Cycling: 0.0km (0.0mi)
Swimming: 8.6km (5.3mi)
Total: 84.7km (52.6mi)
I don't want to plan things too rigidly for this coming week as I will have to be careful not to overdo it. As mentioned above, I did do a slightly faster 6 miler this afternoon and that went well - so I'll be working up from there. With respect to the plan, I'm likely best switching over to Pfitzinger's 12-week program so that I can carefully build myself back up rather than trying to force myself back into an aggressive routine right away. I'm going to have to look over the race calendar, however, to make sure that it's suitable for what I'd like to do this season.
This Week (Tentative):
Mon 3.25K Swim
Tue 6mi Recovery
Wed 6mi Recovery
Thurs 6mi Recovery
Fri 3.25K Swim
Sat 4mi Recovery
Sun 8mi Recovery
In addition, I'm going to start working on re-introducting some core strength workouts into my routine again to avoid this problem in the future. I'm not a big fan of them, but it's obvious that the swim-bike-run exercises alone aren't doing a good enough job of building those muscles, so I will have to take special care.
I will also have to find the time to bring the bike in to get the tube changed as well as get those aerobars and computer mounted and fitted for me. As boring as indoor training is, hopefully having some new toys to play around with in the process will help to make it more interesting ;)
Saturday, January 16, 2010
Core Strength
Just a quick update here, as I've been off of my normal routine due to a minor back injury and am just getting back into it at this point. A week ago Friday I got up with a bit of a sore back, and while it didn't feel like much at the time it ended up getting a lot worse part way through my speedwork session later in the day. To be safe, I've been resting it for most of the week and only did a short and very easy run on Thursday. It appears to be better now, however I'm going to ease back into things to make sure of that.
When I started swimming on a regular basis, I started cutting down on the core strength exercises that I was doing prior to that. That was primarily due to time constraints, however I figured that the upper body aspect of swimming would make up for that. Unfortunately, while it is great for the upper back it doesn't do a whole lot for the core muscles and it's obvious that it wasn't enough ;) While I've never been a fan of strength training (or any indoor exercise for that matter), I'm going to have to get back into the practice of mixing it in so as to avoid issues like this in the future.
Week 1 Totals:
Running: 24.6km (15.3mi)
Walking: 1.3km (0.8mi)
Cycling: 0.0km (0.0mi)
Swimming: 8.6km (5.3mi)
Total: 34.5km (21.4mi)
Year to Date (as of Jan 10th):
Running: 48.7km (30.3mi)
Walking: 1.1km (0.7mi)
Cycling: 0.0km (0.0mi)
Swimming: 8.6km (5.3mi)
Total: 58.4km (36.3mi)
Unfortunately, this was supposed to be the first week of my Marathon training program and that's largely gone up in smoke. Either way, the first week is relatively light so I should be able to make it up - but worst case scenario I can always switch over to the 12 week program.
Adding to the complexity, while I had planned to give the bike a try yesterday the rear tube appears to have blown in the intervening week so I'll have to bring that in to get replaced before I can restart on that front. Not a huge deal, as I have to bring it in anyway to get the aerobars fitted and cyclocomputer installed - will just have to get it done sooner than later ;)
This Week:
Mon Rest
Tue Rest
Wed Rest
Thurs 4mi Recovery
Fri Rest
Sat 4mi Recovery
Sun 6mi Recovery
When I started swimming on a regular basis, I started cutting down on the core strength exercises that I was doing prior to that. That was primarily due to time constraints, however I figured that the upper body aspect of swimming would make up for that. Unfortunately, while it is great for the upper back it doesn't do a whole lot for the core muscles and it's obvious that it wasn't enough ;) While I've never been a fan of strength training (or any indoor exercise for that matter), I'm going to have to get back into the practice of mixing it in so as to avoid issues like this in the future.
Week 1 Totals:
Running: 24.6km (15.3mi)
Walking: 1.3km (0.8mi)
Cycling: 0.0km (0.0mi)
Swimming: 8.6km (5.3mi)
Total: 34.5km (21.4mi)
Year to Date (as of Jan 10th):
Running: 48.7km (30.3mi)
Walking: 1.1km (0.7mi)
Cycling: 0.0km (0.0mi)
Swimming: 8.6km (5.3mi)
Total: 58.4km (36.3mi)
Unfortunately, this was supposed to be the first week of my Marathon training program and that's largely gone up in smoke. Either way, the first week is relatively light so I should be able to make it up - but worst case scenario I can always switch over to the 12 week program.
Adding to the complexity, while I had planned to give the bike a try yesterday the rear tube appears to have blown in the intervening week so I'll have to bring that in to get replaced before I can restart on that front. Not a huge deal, as I have to bring it in anyway to get the aerobars fitted and cyclocomputer installed - will just have to get it done sooner than later ;)
This Week:
Mon Rest
Tue Rest
Wed Rest
Thurs 4mi Recovery
Fri Rest
Sat 4mi Recovery
Sun 6mi Recovery
Thursday, January 7, 2010
Week 54: Review
It's been another crazy week, so I'm just getting around to writing up last week's review at this juncture ;) Between catching up with work stuff after Christmas and New Years mixed into the equation, things were pretty busy for the final training week of the year (plus a few days in 2010). I ended up getting most of my running mileage in, although swimming suffered a bit due to pool schedules and cycling due to the time constraints. As such, it wasn't a banner week - but I'm not yet in formal training so that's not really a huge thing ;)
Week 54 Totals:
Running: 55.2km (34.3mi)
Walking: 1.7km (1.1mi)
Cycling: 30.1km (18.7mi)
Swimming: 5.0km (3.1mi)
Total: 92.0km (57.2mi)
As noted, this week (ie Week 1) has turned out to be pretty busy as well so cycling is still a bit behind at this point. I also had to move today's planned speedwork session back to tomorrow morning, but other than that all of the running/swimming mileage I was planning on doing is up to date.
I'm looking at moving some equipment around this weekend so that I can stream video from my computer when on the bike, which should help to make it more interesting. Right now I've just got an old TV set with some bunny ears and as there isn't anything watchable on TV during the day, it's not difficult to convince myself to skip a session. Being able to watch stuff that I've recorded from prime time should make it easier to get motivated.
With that said, as this is my last week before starting Pfitzinger's 18 week program for the Mississauga Marathon I might end up making the long run a bit shorter to rest the legs a bit. The first week of the program goes down to 12 miles, so the 16 milers that I've been doing aren't really necessary at this point. I still need to figure out a plan for base building in the other two sports, however that's going to require a bit more research.
Tentative Schedule:
Mon 11mi LSD*
Tue 4.3K Swim, 6mi Recovery
Wed 7K Recovery
Thurs 4.3K Swim
Fri 7mi GA w/10x100m, 40K Ride
Sat 4mi Recovery, 30k Ride
Sun 16mi (25.7K) LSD
* Counted toward week 54's total as it was simply postponed from Sunday.
Week 54 Totals:
Running: 55.2km (34.3mi)
Walking: 1.7km (1.1mi)
Cycling: 30.1km (18.7mi)
Swimming: 5.0km (3.1mi)
Total: 92.0km (57.2mi)
As noted, this week (ie Week 1) has turned out to be pretty busy as well so cycling is still a bit behind at this point. I also had to move today's planned speedwork session back to tomorrow morning, but other than that all of the running/swimming mileage I was planning on doing is up to date.
I'm looking at moving some equipment around this weekend so that I can stream video from my computer when on the bike, which should help to make it more interesting. Right now I've just got an old TV set with some bunny ears and as there isn't anything watchable on TV during the day, it's not difficult to convince myself to skip a session. Being able to watch stuff that I've recorded from prime time should make it easier to get motivated.
With that said, as this is my last week before starting Pfitzinger's 18 week program for the Mississauga Marathon I might end up making the long run a bit shorter to rest the legs a bit. The first week of the program goes down to 12 miles, so the 16 milers that I've been doing aren't really necessary at this point. I still need to figure out a plan for base building in the other two sports, however that's going to require a bit more research.
Tentative Schedule:
Mon 11mi LSD*
Tue 4.3K Swim, 6mi Recovery
Wed 7K Recovery
Thurs 4.3K Swim
Fri 7mi GA w/10x100m, 40K Ride
Sat 4mi Recovery, 30k Ride
Sun 16mi (25.7K) LSD
* Counted toward week 54's total as it was simply postponed from Sunday.
Friday, January 1, 2010
2009: Year in Review
2009 has been quite an eventful year for me, with a number of major milestones. I ran my first marathon in May, and while I didn't get the second one in as planned I did manage to parlay that training into a Triathlon. In addition to those major steps, I also managed to get my 5K time below 21 minutes for the first time. I've run a lot more miles than I did in the previous year, and have built up a good amount of experience which should be invaluable for future seasons. Further, I moved my cycling training to a more structured format and introduced swimming into the equation as well.
There were setbacks, of course, with my first real experience in dealing with injuries this year. Fortunately, they were relatively minor and healed pretty quickly with appropriate rest. They did interfere with my training plans a bit, however that is part of endurance training and getting the experience of how to deal with them will be an asset in the future. The upside, however, is that derailing my fall marathon plans helped me to focus more on the Triathlon side which has a lot of promise for the upcoming year.
With that said, at this time last year the plan was simply to do a 30K race in the spring and worry about the full marathon in the fall. Fortunately, after training went well in the early part of the year I elected to use the 30K as a stepping stone and work my way up to the Mississauga Marathon in May. As such, I'm happy to say that I was able to exceed my expectations and I'm a lot further along than I expected to be ;)
The Numbers:
Running: 2,694.5km (1,674.3mi) - 230h02m (5:07/km avg.)
Walking: 237.0km (147.3mi)
Cycling: 4,058.6km (2,521.9mi) - 134h13m (30.2km/h avg.)
Swimming: 180.7km (112.3mi)
Total: 7,170.8km (4,455.7mi)
Overall, that's a little less than 1,300km (~810mi) short of last year's total. The main difference, of course, is that I significantly cut back on the walking sessions that made up the bulk of my mileage last year. Between major increases in running mileage and finding time for the other two sports, fitting in time consuming walking sessions was difficult this time around.
Further, the two (minor) injuries that I had this year took a chunk out of my mileage as well. Aside from the direct loss of time/distance, I also had to gradually rebuild the fitness lost during that downtime which further contributes to mileage loss.
Either way, to illustrate this I put together the following plot of my running mileage over the course of the year (click on it for more detail). It has the weeks of my two 18 week training cycles overlaid on the graph, the 5 weeks of recovery between them. The plot also has markers for each of my races as well as the two injury periods:
To compare progress over the last few years, I've also thrown together a table with a few rough numbers. My weight (yellow line above) has drifted up a bit this year, however I'm still well within the normal range so I'm not worrying about that too much. Most of that built up part way through my first training cycle, as getting used to the fueling requirements of running beyond the half took a bit of learning. I've held it roughly steady since that point, as I think that I've gotten the hang of the right balance. With that said, some of that is likely additional muscle mass as swimming and cycling work groups that previously didn't see much load.
My running index is a little lower (blue line), but that's likely skewed by the walking at the beginning of the year. Polar's running index is a synthetic metric that is intended to monitor fitness levels by looking at exercise telemetry (primarily comparing %VO2Max against pace). Unfortunately, as walking is a more efficient gait than running is it tends to inject higher scores into the plots. Resting heart rate is likely a better measure anyway, and on that front I'm roughly in the same boat as I was last year (slightly lower, but likely within the margin of error).
2009 Racing History:
Looking Ahead
Either way, 2009 is now officially in the books and I'm looking forward to what I can achieve in 2010. I'm still working out the details for the overall plan, however the primary objectives are as follows (in order of importance):
Happy 2010!
There were setbacks, of course, with my first real experience in dealing with injuries this year. Fortunately, they were relatively minor and healed pretty quickly with appropriate rest. They did interfere with my training plans a bit, however that is part of endurance training and getting the experience of how to deal with them will be an asset in the future. The upside, however, is that derailing my fall marathon plans helped me to focus more on the Triathlon side which has a lot of promise for the upcoming year.
With that said, at this time last year the plan was simply to do a 30K race in the spring and worry about the full marathon in the fall. Fortunately, after training went well in the early part of the year I elected to use the 30K as a stepping stone and work my way up to the Mississauga Marathon in May. As such, I'm happy to say that I was able to exceed my expectations and I'm a lot further along than I expected to be ;)
The Numbers:
Running: 2,694.5km (1,674.3mi) - 230h02m (5:07/km avg.)
Walking: 237.0km (147.3mi)
Cycling: 4,058.6km (2,521.9mi) - 134h13m (30.2km/h avg.)
Swimming: 180.7km (112.3mi)
Total: 7,170.8km (4,455.7mi)
Overall, that's a little less than 1,300km (~810mi) short of last year's total. The main difference, of course, is that I significantly cut back on the walking sessions that made up the bulk of my mileage last year. Between major increases in running mileage and finding time for the other two sports, fitting in time consuming walking sessions was difficult this time around.
Further, the two (minor) injuries that I had this year took a chunk out of my mileage as well. Aside from the direct loss of time/distance, I also had to gradually rebuild the fitness lost during that downtime which further contributes to mileage loss.
Either way, to illustrate this I put together the following plot of my running mileage over the course of the year (click on it for more detail). It has the weeks of my two 18 week training cycles overlaid on the graph, the 5 weeks of recovery between them. The plot also has markers for each of my races as well as the two injury periods:
To compare progress over the last few years, I've also thrown together a table with a few rough numbers. My weight (yellow line above) has drifted up a bit this year, however I'm still well within the normal range so I'm not worrying about that too much. Most of that built up part way through my first training cycle, as getting used to the fueling requirements of running beyond the half took a bit of learning. I've held it roughly steady since that point, as I think that I've gotten the hang of the right balance. With that said, some of that is likely additional muscle mass as swimming and cycling work groups that previously didn't see much load.
My running index is a little lower (blue line), but that's likely skewed by the walking at the beginning of the year. Polar's running index is a synthetic metric that is intended to monitor fitness levels by looking at exercise telemetry (primarily comparing %VO2Max against pace). Unfortunately, as walking is a more efficient gait than running is it tends to inject higher scores into the plots. Resting heart rate is likely a better measure anyway, and on that front I'm roughly in the same boat as I was last year (slightly lower, but likely within the margin of error).
| 01/01/2007 | 01/01/2008 | 31/12/2008 | 31/12/2009 | |
| Weight | 240lbs | 180lbs | 151lbs | 166lbs |
| HR-Rest | 74bpm | 62bpm | 43bpm | 41bpm |
| Running Index | ? | 41 | 66 | 61 |
2009 Racing History:
- March 15th Achilles 5K 20m55.6s (PB)
- March 29th Around the Bay 30K 2h27m48.6s (PB)
- April 4th Harry's Spring Run-Off 5K 22m56.4s
- May 10th Mississauga Marathon 3h29m03s (PB)
- September 19th Lakeside II Sprint Tri 1h17m37s (PB)
Looking Ahead
Either way, 2009 is now officially in the books and I'm looking forward to what I can achieve in 2010. I'm still working out the details for the overall plan, however the primary objectives are as follows (in order of importance):
- Build up my mileage in the Triathlon, with the hopes of doing a Half Ironman in the fall. Whether that is realistic or not remains to be seen, however even if I don't get up to the half I want to at least do an Olympic distance race sometime this year.
- Build towards a 3:20 Marathon in the spring as a stepping stone towards the 3:10 I need for Boston. To run a 3:10 I'm going to need more experience under my belt, so aiming for the mid-point between where I am now (3:29) and where I need to be (3:10) should be a good learning experience.
- Try to get my 5K time below 20 minutes sometime this year. It's a bit of an out-of-band goal, however I got within a minute of that early last year and that was coming off of an injury. I've gained a lot of experience this year, and my fitness level has improved since then so it should be realistic.
Happy 2010!
Subscribe to:
Posts (Atom)