Posts

Showing posts with the label Garmin Edge 500

Garmin Edge 25: simpler, lighter, smaller equals better

SCRainmaker has a "hands-on" (as opposed to an "in-depth" review; still way more in-depth than any other reviews on the web) of the new Garmin Edge 20 and 25. These are, finally , Garmin addressing the simpler/lighter-is-better market for GPS. On bikes, a huge amount of attention and money is directed towards minimizing weight. The best way to minimize weight of a GPS unit is to ride without a GPS unit. But the prominence of social networking website Strava has increased the value of GPS data. So for many, GPS has become a virtual requirement. What's the point of riding if you can't get kudos? Yet despite big push for lighter bikes, and with real estate on the handlebars and stem so limited, Garmin has seemingly ignored the value of lighter-and-simpler-and-smaller by producing a series of increasingly complex, heavy, and bulky GPS units. The Edge 500 came out more than a half-decade ago, and yet it has remained the lightest and most compact unit pro...

Vector pedal stroke analysis metrics available

Fulfilling a long-term promise, the Garmin Vector now does pedalstroke analysis! See DC Rainmaker's excellent blog post on the latest firmware update. The new metrics include: pedal force offset: this measures how far outboard or inboard the average force is applied. pedal power stroke: this measures over which angles peak propulsive force is applied seated versus standing time: if you're standing, the pedals support full body weight (non-propulsive), so the Vector can determine how much time you're standing versus sitting (and record whether you're standing or sitting). Various applications for these metrics would be bike fit, technique analysis, and interpretation of performance. For the pedal force offset, that obviously suggests a bike fit application. "Power stroke" suggests both fit and technique. Standing versus seating suggests performance analysis: am I faster seated or standing on short steep climbs? What about long sustained climbs? More d...

Vector vs Powertap ride #3: crank length problem solved?

Image
The plot thickens... Another day, another ride. This time I made sure to do a static zero test before the ride. I further checked that I had the latest firmware in my Edge units (Mac WebUpdater says I did). I was full of hope that the crank length fix had corrected things. So I set off on a ride to fetch new contact lenses, but where I took "scenic detours" up five significantly steep, significantly painful climbs in San Francisco. For the record: 17th from Market to Twin Peaks (and on to Twin Peaks summit), Sanchez from 17th to 18th, Church from 18th to 21st, 21st from Church to Sanchez (these two are contiguous, but I took a break in between, not initially planning to ride 21st, which is daunting), and finally, just because I felt like I could, the ever-painful 22nd from Vermont to Carolina. No luck. My suspicion now is that the head unit is overriding the crank length setting. Issue is I don't know how to change the crank length in the head units. In the 510 ...

Vector vs Powertap: data comparison (no washers)

Image
On my relatively new randonneuring bike, which got its first serious long-distance test in the Memorial Day Ride (MDR) this past week, I've been using Garmin Vector Pedals I was lucky enough to get. The Garmin Vector, of course, offers the advantage of "true" left-right power, since it is effectively two independent power meters, one for the left, one for the right. But even though I've had the pedals on there for awhile, I've been ignoring the power data. I didn't trust it. It's not that I didn't think the Vector is a good product, but rather I didn't trust the installation decision I made to not install any washers. Of course, I could have just added the washers, but that would lose interesting data. I wanted to do a direct comparison with Powertap to quantify what the reduction in power, if any, was. Being generally lazy about this sort of thing, I procrastinated... until today. In this post I compared power data versus climbing rate on ...

Garmin Edge 500 and Mt Diablo: then and now

Image
The Mount Diablo "Time Trial" was today. I felt I rode well, but recorded only my second best time on the relevant Strava segment. North Gate to Summit , which is erroneously named since it actually begins after a bump which follows the North Gate. But since the race today staged on the hot side of the gate, segments which begin at the gate itself included staging time. My previous best was a training ride in September 2011 . I wanted to know why I was slower. Was it due to the tactical portion of the race, with reduced VAMs isolated to a particular portion of the course, or was it due to being generally overall slower? Of course I'm 2.5 years older now, and I've not been training on the bike more than a few weeks, and I'm recovering from a cold which isn't quite gone yet, and the weather was substantially cooler than it was that September day, and I'm presently 1 kg over my "race weight". Lots of possible issues. But I wanted to look a...

GPS options for Devil Mountain Double

I'm getting ready for the Devil Mountain Double, and it's a good time to review GPS options for the ride. Back before Strava, GPS was a bit of fluff for rides like this, but the social networking + power analysis + segment timing of Strava provides so much value I wouldn't consider skipping GPS today. The following are the strengths and weaknesses of the various GPS options available to me: Garmin Edge 500: Mine had the tabs snap off on me, so using it would require putting it in my jersey pocket. But I can borrow Cara's for the day. Battery life is likely adequate: it should last the double century if I start with a full charge. I will make sure auto-pause is on to limit battery consumption during rest stops (which will be minimal, but every bit counts). Smart sampling is unavailable due to the power meter (and I wouldn't use it anyway). It's light: only 58 grams without the mount, 66 grams with the mount. It's compact: mounted on my stem it won...

Garmin Edge 500: broken tabs

Image
As I rapidly descended Panoramic Highway toward Highway 1 from Mount Tamalpais with my Roaring Mouse teammates, I passed by some sticks on the side of the road. Suddenly something hit my foot. That didn't feel like a stick... I felt my pockets and nothing seemed loose, so perhaps it had been a stick after all. Seconds later one of the riders behind me shouted "computer!" And then I knew. My Garmin had fallen. A quick look at my stem confirmed it: the bracket was empty, a white sliver of a plastic tab the only remaining sign of my Edge 500. Fortunately after a bit of searching we were able to find and retrieve the computer. Honestly I was as worried about losing the ride's data as I was about the computer itself. A quick inspection showed the problem: the plastic tabs on the back had sheared off. Indeed one of the tabs had already come off during a previous ride. But the one remaining tab seemed enough to hold it in place. I'd taken to using a piece o...

Garmin Forerunner 610 vs Edge 500: city run smack-down

Image
Previously I compared the Strava Android app on my HTC Incredible phone to the Garmin Forerunner 610 on a run I did along the Steven's Creek Trail. I thought the phone might have been slightly better, but it was close. This time I set off for a city ride without my phone, but I had the Garmin Edge 500 mounted with a strap to my right wrist, and I had the Garmin Forerunner 610 mounted to my left wrist with its integrated strap. I had both set to 1-second sampling. This wasn't a pure run, as I was also Christmas shopping (books for my nieces). So I stopped in several book stores along the way, as well as a two cellular phone shops (thinking of switching from Verizon to T-Mobile), one bike shop (the black-on-black Specialized SL4 with 2012 Red is very slick), and a chocolate shop (disappointed Girardelli's "sea salt" "Intense Dark" doesn't seem so dark at all from the fat:carbohydrate ratio). Anyway, all of these stops meant loss of signal. Here...

Garmin Edge 500 sample time and Strava lap time determination

Image
Last post I noted there had been a difference between the reported lap time up Old La Honda and the extracted time for the segment. The lap time had been reported by Strava as 18:12, while the segment time was quoted as 18:22, a ten second difference. But looking at the difference between the point at which the end of the segment was tagged and the end point of the lap I had a difficult time imagining that was worth ten seconds. After all, while I slowed there, not just coasting but actively braking to check for cross-traffic, I never came to a complete stop (law enforcement: my account here seems to have been hacked). So it occurred to me I was assigning the full error on the segment time, but assuming the lap time was correct. Back when I was making suffer score test files, I used a 3 second sampling time, the same as is used by my Android phone. Since each sample represents 3 seconds of ride data and since there are 3600 seconds in an hour, I generated 1200 samples. I figu...

Wednesday Noon ride and Strava timing accuracy

Image
After working at my job for close to year, I decided it was finally time to indulge in the Wednesday Noon Ride this week. The weather was perfect: warm but not hot, a so-very-welcome liberation from the tights and long sleeves which have been part of virtually every ride I've done this year thanks to San Francisco's persistent "marine layer". And Matt has done a great job of championing the often-neglected Wednesday ride which has climbed Old La Honda since the Egyptians were first domesticating cats. I'd done two of the Friday rides so far and the experiment was generally a success: out the door by a drop-dead time of 11:30, back before the 1:30 pm time when the cafeteria shut down its main lunch service. Obviously it's not something to do every day but since my typical lunch break is a line-dependent 7-12 minutes it takes to go to the cafeteria, buy something, then get back to my terminal, it'd still be doable to go even once per week and still ave...

Vector launched!

Image
Garmin announced today the launch of the Vector pedal. Pretty exciting stuff. I've written a lot here about the then-Metrigear Vector. This certainly looks a lot like the Metrigear version did. Of course the devil's in the details, and I know a lot of development has occurred since Garmin bought Metrigear. It will be very interesting to see how this plays out. I know that when I'm riding sometimes I feel asymmetric, that my left leg maybe isn't working as hard as my right. But that's based on perceived exertion... now you'll be able to see real numbers. And for tandems. I don't think there's another option (other than the Look/Polar) for independently measuring stoker and captain power. How many times have I seen a guy pulling his 8-year-old kid on a Trail-A-Bike and the kid (or kids in the case of the linked version) are slacking off? Slap some Vectors on that puppy and keep an eye on those little parasites. For portability it's...

Strava Android App: head-to-head testing against Garmin Edge 500

Image
This morning a head-to-head competition.... I had 8 minutes to catch Caltrain 206. Plenty of time, but no time to waste. I got my bike in the garage, turned on the Garmin, left the garage, shut the automatic door, then pulled my Android phone from my pocket, brought up the Strava app, and hit new ride. Ten precious seconds later GPS signal was acquired and I quickly hit go. I clipped in and was off to the station. Twice per block I checked the status of the Garmin. As I've noted, this is a GPS-challenged environment, and the Garmin doesn't like it. For the first three blocks the progress bar moved steadily to the right. Then it retreated a bit. Then it regained some of its previous progress... where it stalled. I was doing well. Traffic was extremely light at 6:05 am, so my quest for scientific fairness wasn't placing too great a burden on my survival chances. The train station is just south of 4th Street. When I reached 7th Street I missed the light. I ...

first impressions of Strava Android App

Image
Recently I've been testing the new Android Strava app . My preferred method of recording ride or run GPS data has been the Garmin Edge 500. On the bike, I use the usual mount which I attach to my stem. For running I got a Forerunner wrist strap which works great: the Edge 500 and the Forerunner share the same strap. But when the Strava app for Android app was released I was pretty excited. I'd read and heard hints and rumors of real-time features, perhaps for example instant notification of KOM rankings results while on the bike. But, alas, nothing so spectacular. The app reports speed, distance, and time of exercise, then allows the user to upload the ride to Strava. Once uploaded, a limited resolution map of the activity can be viewed along with rankings on matched segments (once the servers have had adequate time to process the data, less than a minute). So it seemed as if I'd have little use for it. But I decided to give it a try anyway. And I was pleasan...

Strava, Garmin Edge, and the top of Old La Honda

Image
The second worst offender in the little investigation I did last post was the "INTEGRATE Performance Fitness OLH Climb". Integrate is a fitness studio in Mountain View so I suspect they did a time trial there to test client fitness. But while the West Alpine climb which resulted in the 48 second error is a bit tricker to debug, this one is fairly clear. Old La Honda starts with a bridge crossing and finishes 5.2 km later at a stop sign immediately before a ridge road which contains high speed car and motorcycle traffic. While a full stop honestly isn't critical here, at least some attention past the sign is necessary. And it's common for riders to stop past the sign on the dirt shoulder. With manual timing, you start your climb at the bridge (I use the trailing edge) and finish when your front tire crosses the perpendicular line passing through the stop sign. It's all very precise. But nothing about commercial GPS is "very precise". As I...

testing Strava segment timing reliability

Image
DC Rainmaker recently did an interesting study of the accuracy of GPS units. He mounted eight different GPS computers on the handle of surveyer's measurement wheel then walked, ran, or rode various courses, comparing the measured results ( Part 1 , Part 2 ). The GPS units tended to disagree on how far he'd gone, although usually the results were consistent with the claimed positional accuracy of the units. I suggested he use the data to test Strava reproducibility in segment timing. No luck there, but I did find that a friend of mine has been in the habit of riding with a Garmin Edge 500 mounted alongside a Garmin Edge 800 on his rides. We have a mutual friend who works for Garmin, so he's doing this to compare the two. I asked him for data from three of his rides. I then created two new accounts on Strava and uploaded the data from his Edge 500 into one, and from the Edge 800 into the other. The new accounts are necessary because Strava rejects what appear to b...

CycleOps GPS Joule and the future of head units

Image
Garmin released its Edge 500 head unit at around the same time as CycleOps released its Joule. Each of these was an ANT+ Sport compliant head unit which could read power data from compliant power meters like the Quarq and PowerTap. However, otherwise they almost couldn't be more different. The Joule's focus was on functionality. Power users like to analyze their data, CycleOps reasoned, so we're going to give the user as many options as we can fit to crunch power numbers and even do history analysis. This sounded good, but the head unit is the wrong tool for this job. Riders would upload their data at the end of the ride anyway, for example with Golden Cheetah or WKO, then may be from there to a web site like Training Peaks. So the result was a heavy, bulky, and expensive head unit which sold like coldcakes. And despite all the cost and complexity the unit lacked GPS. Why burden a head unit designed for a power meter with GPS? The Wattage List old-guarde esche...

filtering motorized ride segments with power estimation: finally done (for now)

Image
I implemented the biexponential filter, along with power filtering, in my motorized segments detection code. This program, along with my other Garmin Perl codes, can be found here . I made a few changes from previous descriptions. One is I changed the anaerobic time constant to 120. This is more the upper end, rather than the median, of typical numbers. This may provide a bit more margin against falsely identifying a segment as motorized. The other change I made was to separate the altitude-smoothing time constant from the anaerobic time constant. Oversmoothing of altitude can result in the overprediction of power when a rider descends small dips. I set the default to 30 seconds. I also added some speed smoothing but only 5 seconds. Without any speed smoothing and there's too much effect from when the Garmin occasionally spits out a single point with ridiculously high speed. But too much longer than 5 seconds and I lost more of the train segments in Italy where the tra...

exponential filter impulse response for altitude data smoothing

Image
Linear filters are characterized by their impulse responses. To test my exponential filter algorithm, I created an input data set with zero-value points randomly spaced in time. At zero I put a finite approximation to a unit impulse: ‒0.01, 0 0, 100 0.01 0 I then ran this through my exponential filter in various ways. One way is to run the points in time-forward order. This is the "causal" approach: I'm analyzing data as it comes, and I want a smoothed result as I am receiving data. Also causal is to run the smoothed curve again through the exponential filter. You'd expect this second smoothed result to be even smoother than the first time through, and of course it is. Then there's a single and double application of the exponential filter in reverse time order. You'd expect the result to be flipped from the forward-time order (there's nothing special about forward time versus reverse time which should make the shape different; if it were th...

exponential filtering algorithm

Here I'll briefly describe the algorithm for filtering data with an exponential convolution. First, I'll define the following: n: an index for the point in the series. The first point is n = 1, the next n = 2, the next n = 3, etc. y n : the series of unfiltered points data values, for example altitudes. t n : the series of unfiltered points time values. Δt: the time separation of the data for uniformly spaced time points. Δt n : when time is not necessarily uniformly spaced, Δt n ‒Δt n‒1 . τ: the smoothing time constant. u n : normalized time values, t n / τ. Δu: Δt / τ (for uniformly spaced time points). Δu n : Δt n / τ. z n : the series of smoothed time points. So using these definitions, I want to convert from the unsmoothed series y n to the smoothed series z n . First, if an initial point is encountered, we start things rolling with the following: z 0 = y 0 Then assuming uniformly spaced data, a naive approach is the following: z n = z n‒1 exp...