Slope / Gradient ?
Mark Liversedge
I won't pretend to understand any of the recent posts about how
climbing/descending is calculated BUT it did get me thinking on a old
topic... SLOPE
When looking through my data I often wish I could look at power output
related to climbing -- i.e. how does my cadence and power output
adjust according to the slope I'm riding. That specificity thing -- if
I'm gonna ride lots of Cols at a 10% gradient then I need to train in
the way I will ride them (not high cadence TT efforts!) -or- maybe my
gearing needs to change to accomodate...
To be able to do this kind of analysis I really need to know what the
slope is for each data point in my ride.
If we're doing clever things for climbing/ascending can we populate a
SLOPE field in the RideFile dataPoints? It would make for some very
interesting charts, and would be a doddle to add to the 3d charts i.e.
cadence & power by slope.
Is this easy to do?
(And I believe we would need to take care not to overwrite slope when
some devices already provided it)
Cheers,
Mark
Mark Liversedge
just altitude). That way we could do some interesting analysis aka
Robert Chungs power expansion pathways (Greg, is that right?)
I'll go back to my cave now.
perrygeo
On Dec 30, 7:25 am, Mark Liversedge <liverse...@gmail.com> wrote:
> When looking through my data I often wish I could look at power output
> related to climbing -- i.e. how does my cadence and power output
> adjust according to the slope I'm riding. That specificity thing -- if
> I'm gonna ride lots of Cols at a 10% gradient then I need to train in
> the way I will ride them (not high cadence TT efforts!) -or- maybe my
> gearing needs to change to accomodate...
>
> To be able to do this kind of analysis I really need to know what the
> slope is for each data point in my ride.
>
I agree that slope would be valuable... I have 1 powertap and 4 bikes
so many of my rides are done with a Garmin 305, no power meter data :-
( Using the slope, rider weight and speed, there are some formulas for
estimating power output. They are simplistic and ripe with assumptions
but i've found them to be better than nothing (http://
www.trainingbible.com/joesblog/2008/01/climbing-power-formula.html)
Also would be nice to see more elevation-related metrics such as
average slope, elevation loss/total descending, and vertical ascent
per hour or VAM (http://www.53x12.com/do/show?page=article&id=21 -
which, given slope, can also be used to estimate average power
output).
Mark Liversedge
go up and down more than we go round and round ;-)
Justin F. Knotzke
VAM would be really, really nice. But I guess only to those of us who
go up and down more than we go round and round ;-)
jason osborne
From: jason osborne <jason.l...@gmail.com>
Date: Wed, Dec 30, 2009 at 11:34 AM
Subject: Re: [Golden-Cheetah-Users] Slope / Gradient ?
To: Mark Liversedge <liver...@gmail.com>
An inferred/calculated slope (I prefer the "V.E." parlance) can be done from the available PM data quite effectively.
Robert Chung, AndyF, Tom_A, and Alex Simmons have all done a considerable amount of work to refine the current technique.
The issue is with creating accurate profiles; at all times there needs to be very little wind, and both your Crr and CdA needs to remain relatively stable to generate "good" elevation profiles. Then there is the sticky issue of braking - it can create "false" elevation changes that are troublesome.
In short, you can generate VE profiles, but it's only *really* useful under a very specific set of conditions.
Jason.
--
_______________________________________________
Golden-Cheetah-Users mailing list
golden-che...@googlegroups.com
http://groups.google.com/group/golden-cheetah-users?hl=en
jerry....@gmail.com
Sent via BlackBerry by AT&T
Mark Liversedge
think Andy Froncioni and Sean are working on V.E. as we speak.
jason osborne
I misinterpreted what you were talking about.
Jason.
I was suggesting we calculate slope from altitude and distance data. I
think Andy Froncioni and Sean are working on V.E. as we speak.
--
Andy Froncioni
> I was suggesting we calculate slope from altitude and distance data. I
> think Andy Froncioni and Sean are working on V.E. as we speak.
>
look like for the GC Aerolab. :-)
The usage I have in mind, based on some very good feedback from Greg
Steele, is that the user would either enter an elevation profile (comes
for free with iBike) uses the Crr-CdA sliders to balance out the
elevation profile, as in the attached mock-up. Greg, please speak up -
you have great ideas!
There are 2 modes: manual and autosolve. In manula, the user tweaks
the Crr and CdA using the sliders. In autosolve mode, the user fixes
one, both, or neither of the Crr-CdA sliders and presses autosolve.
Autosolve needs a real elevation profile.
Refinements could be to incorporate lap markers when the course is a
loop, and to incorporate wind direction and speed when a full GPS path
file is available.
Not sure if this is the way GC interfaces are usually done, but that's
my first guess. Hope it's not too early for this discussion.
Cheers!
Andy
jason osborne
"and to incorporate wind direction and speed"
Jason.
Andy Froncioni
> What's the path for entering profile data for Autosolve, from
> "regular" GPS, or a manually generated elevation profile from topo SW?
clarify the usage:
Step 1 - Upload ride data. Possibly separately upload elevation or GPS
data.
Step 2 - If elevation is known, Autosolve button is active. Either use
Autosolve to completely solve for Crr and CdA (ve perl script does this
already, so this step has been numerically de-risked), or use manual
sliders to "tune" Crr and CdA by hand.
If one of the parameters is known a priori, then check off the "fixed"
checkbox and you can still use autosolve to compute the unknown parameter.
>
> "and to incorporate wind direction and speed"
> Sounds like you're also thinking about being able to support time
> synced wind speed/direction data from a anemometer too?
The main refinement I'm thinking of for wind is if the wind is steady,
and a full GPS path file is available we can allow the user to impose a
known wind speed and direction. I can use a cos(yaw_angle) term in the
aero drag term to get a good elevation profile. There might also be a
separate option for out-and-backs, but I don't know how to do this yet.
Cheers,
Andy
jason osborne
I wasn't sure, so I didn't want to impose a workflow here. Just to clarify the usage:
Step 1 - Upload ride data. Possibly separately upload elevation or GPS data.
Step 2 - If elevation is known, Autosolve button is active. Either use Autosolve to completely solve for Crr and CdA (ve perl script does this already, so this step has been numerically de-risked), or use manual sliders to "tune" Crr and CdA by hand.
If one of the parameters is known a priori, then check off the "fixed" checkbox and you can still use autosolve to compute the unknown parameter.
The main refinement I'm thinking of for wind is if the wind is steady, and a full GPS path file is available we can allow the user to impose a known wind speed and direction. I can use a cos(yaw_angle) term in the aero drag term to get a good elevation profile. There might also be a separate option for out-and-backs, but I don't know how to do this yet.
Cheers,
Andy
I was thinking more along the lines of a logging weather station as another data input (like this: http://tinyurl.com/y9wm64x). It could provide time stamped wind speed/pressure/and direction, that as long as the clock sync between the power device and the weather station were with a small margin of error could be really cool. Now, granted this would be data from a single fixed location, but in most of the instances of VE testing I've done that would be more than sufficient.
Jason.
Andy Froncioni
>
> Sounds like a reasonable work flow. It seems that for separately
> uploaded elevation profiles an auto correlation would need to be done
> to hook the elevation profile points to the "correct" VE locations
> from the power data file.
v(t) as possible, where u(t) is actual elevation and v(t) is computed
elevation, right?
I was thinking more along the lines of a logging weather station as
another data input (like this: *http://tinyurl.com/y9wm64x*). It
could provide time stamped wind speed/pressure/and direction, that
as long as the clock sync between the power device and the weather
station were with a small margin of error could be really cool.
Now, granted this would be data from a single fixed location, but in
most of the instances of VE testing I've done that would be more
than sufficient.
Yup, ok, I'm seeing it. Wow -- putting all this together would be
really cool! Definitely one station to measure pressure and
temperature is important.
For the future, though, using unstructured interpolation any number of
geo-located weather stations could be used to give a stable space-time
interpolation on the test course. I've done this before. I just
never thought I might use the stuff again. :-)
What sensors are available for GPS position right now?
Cheers,
Andy
Justin F. Knotzke
For the future, though, using unstructured interpolation any number of
geo-located weather stations could be used to give a stable space-time
interpolation on the test course. I've done this before. I just
never thought I might use the stuff again. :-)
What sensors are available for GPS position right now?
Robert Chung
On Dec 30, 3:12 pm, Andy Froncioni <a.fronci...@sympatico.ca> wrote:
> Mark Liversedge wrote:
> > I was suggesting we calculate slope from altitude and distance data. I
> > think Andy Froncioni and Sean are working on V.E. as we speak.
>
> I guess it's an appropriate time to talk about what the interface might
> look like for the GC Aerolab. :-)
Man, are you guys gonna force me to add GC to the long list of
discussion lists I'm already monitoring?
> The usage I have in mind, based on some very good feedback from Greg
> Steele, is that the user would either enter an elevation profile (comes
> for free with iBike) uses the Crr-CdA sliders to balance out the
> elevation profile, as in the attached mock-up. Greg, please speak up -
> you have great ideas!
>
> There are 2 modes: manual and autosolve. In manula, the user tweaks
> the Crr and CdA using the sliders. In autosolve mode, the user fixes
> one, both, or neither of the Crr-CdA sliders and presses autosolve.
> Autosolve needs a real elevation profile.
>
> Refinements could be to incorporate lap markers when the course is a
> loop, and to incorporate wind direction and speed when a full GPS path
> file is available.
>
> Not sure if this is the way GC interfaces are usually done, but that's
> my first guess. Hope it's not too early for this discussion.
Andy:
This is very cool and is sort of not far from the way I often use this
myself, though without sliders of course. However, I'd add another
"control": let me explain.
I don't usually know the true elevation profile and, in fact, on those
occasions when I've been given GPS data I find that they're often not
precise enough to use as if they were true. On the other hand, I do
tend to know whether I've crossed the same spot and geologic processes
work slowly enough that we can generally assume the altitude hasn't
changed between crossings. So: do a very rough VE profile (by
distance) then click the mouse to locate the start and end of an
interval that you know has net zero elevation change. Then solve for a
(Crr, CdA) pair for that interval. If you know something else about
the interval, like the true profile or the true min-max elevation
difference, or you traverse that same interval twice at speeds
different enough to separate out the linear and nonlinear components
then you can pry apart the (Crr, CdA) pairs. Note that if you identify
an interval where the start and end points are *not* at the same
elevation but you know the difference, you can calculate the PE
component.
So, in my own analyses, I often identify a segment and then specify
the net elevation change over that segment. Usually, I specify zero
but sometimes not. So that's the additional control I'd add.
Andy Froncioni
On 2009-12-30, at 11:52 PM, Robert Chung wrote:
>
>
> On Dec 30, 3:12 pm, Andy Froncioni <a.fronci...@sympatico.ca> wrote:
>> Mark Liversedge wrote:
>>> I was suggesting we calculate slope from altitude and distance data. I
>>> think Andy Froncioni and Sean are working on V.E. as we speak.
>>
>> I guess it's an appropriate time to talk about what the interface might
>> look like for the GC Aerolab. :-)
>
> Man, are you guys gonna force me to add GC to the long list of
> discussion lists I'm already monitoring?
Well, this might turn you off all over again, Robert: :-)
http://andyfroncioni.com/2009/12/virtual-elevation-does-rotational-inertia-play-a-role/
Please stick around and share your thoughts -- if all works out, you may end up with a nice aero tool here.
:-)
Cheers!
Andy
Andy Froncioni
---------------------------------------------------------------
My other signature is a pun.
---------------------------------------------------------------
a.fro...@sympatico.ca
(514) 829-0255
Robert Chung
On Dec 31, 8:34 am, Andy Froncioni <a.fronci...@sympatico.ca> wrote:
> Well, this might turn you off all over again, Robert: :-)
> http://andyfroncioni.com/2009/12/virtual-elevation-does-rotational-in...
Nicko brought this up recently on wattagetraining. A long time ago I
looked at both the exact small angle calculation and the rotational
inertia component but decided that the additional precision wasn't
worth it. However, if you don't expect a donkey to fly you're not too
critical when it doesn't get very high off the ground and I was just
happy to get estimates that stayed in the ballpark even with
horrendous experimental control. For example, in early experiments I
didn't weigh myself or record air density or bother to figure out true
elevations or hold my line exactly through turns, so exact small angle
and rotational inertia were getting swamped out. Now folks appear to
be taking this stuff seriously so it probably makes sense to re-
evaluate -- but I suspect there are other systematic errors that
dominate and while I'm not wedded to parsimony I do have a soft spot
in my heart for it.
Robert Chung
On Dec 31, 9:12 am, Robert Chung <rech...@gmail.com> wrote:
> while I'm not wedded to parsimony I do have a soft spot
> in my heart for it.
Not that I'm trying to discourage you. I was just explaining that I
looked at this stuff before and opted (with what I saw at the time)
not to include it. The times they are a-changin'.
Andy Froncioni
> Nicko brought this up recently on wattagetraining. A long time ago I
> looked at both the exact small angle calculation and the rotational
> inertia component but decided that the additional precision wasn't
> worth it. However, if you don't expect a donkey to fly you're not too
> critical when it doesn't get very high off the ground and I was just
> happy to get estimates that stayed in the ballpark even with
> horrendous experimental control. For example, in early experiments I
> didn't weigh myself or record air density or bother to figure out true
> elevations or hold my line exactly through turns, so exact small angle
> and rotational inertia were getting swamped out. Now folks appear to
> be taking this stuff seriously so it probably makes sense to re-
> evaluate -- but I suspect there are other systematic errors that
> dominate and while I'm not wedded to parsimony I do have a soft spot
> in my heart for it.
Good summary!
What would you say are the biggest systematic errors inherent in the calculation? And just to be sure we're on the same page, systematic errors don't include random sensor error or centred numerical roundoff errors, right?
Robert Chung
On Dec 31, 10:42 am, Andy Froncioni <a.fronci...@sympatico.ca> wrote:
> What would you say are the biggest systematic errors inherent in the calculation?
> And just to be sure we're on the same page, systematic errors don't include
> random sensor error or centred numerical roundoff errors, right?
Well, in the way I think about things, anything that contributes to
bias counts. For example, there are well-known idiosyncrasies in the
way that the PT reports data vs. the way that the SRM reports data
(like, systematic holes in the reported speed for SRMs vs. systematic
holes in the reported hub torque for PTs).
So, in general, there are systematic errors that arise from unmodeled
variables (chiefly, wind or braking but also changing rho), systematic
errors from the data (like, holes in speed, incorrect rollout or not
holding your line or position) and systematic errors that arise from
poor parameterization (like ignoring small angles and rotational
inertia but also including errors in estimating quantities like KE or
drivetrain efficiency).
How would you rank these sources of error? As a not-so-aside, I
generally (though not always) envision VE as a way to help estimate
changes in CdA so getting an exact handle on rotational inertia sort
of drops a bit down my list, especially since I use the VE profile as
a diagnostic rather than as the end product.
Andy Froncioni
> How would you rank these sources of error? As a not-so-aside, I
> generally (though not always) envision VE as a way to help estimate
> changes in CdA so getting an exact handle on rotational inertia sort
> of drops a bit down my list, especially since I use the VE profile as
> a diagnostic rather than as the end product.
>
prescriptive? ;-)
Thanks for the feedback. I'll think about all this stuff. By the way,
over on wattagetraining.com Nicko has mentioned that the rotational
inertia terms (I1+I2)/R can be as high as the equivalent of 1.5 kg.
Would you consider this to be significant?
Andy Froncioni
> Thanks for the feedback. I'll think about all this stuff. By the way,
> over on wattagetraining.com Nicko has mentioned that the rotational
Oops, meant slowtwitch.com forums. Sorry.
Robert Chung
On Dec 31, 5:56 pm, Andy Froncioni <a.fronci...@sympatico.ca> wrote:
> So then you would describe VE as being descriptive rather than
> prescriptive? ;-)
Yup.
> Thanks for the feedback. I'll think about all this stuff. By the way,
> over on [slowtwitch] Nicko has mentioned that the rotational
> inertia terms (I1+I2)/R can be as high as the equivalent of 1.5 kg.
> Would you consider this to be significant?
Nope.
Robert Chung
To clarify, depending on how much acceleration is going on, it might
be significant to the exact VE profile but since I don't usually fit
the VE profile to a true elevation profile I generally don't consider
it significant. That is to say, I'm sure it has an effect on the
instantaneous slope (just as the small angle correction does) but I
don't usually care about instantaneous slope in isolation.
J.T. Conklin
> If we're doing clever things for climbing/ascending can we populate a
> SLOPE field in the RideFile dataPoints? It would make for some very
> interesting charts, and would be a doddle to add to the 3d charts i.e.
> cadence & power by slope.
>
> Is this easy to do?
>
> (And I believe we would need to take care not to overwrite slope when
> some devices already provided it)
Would we want to record an instantaneous gradient in a RideFile, or is
this something that we want to compute at presentation time?
Like the recent discussion about the use of filters to "de-noise"
climbing/decending totals, I suspect using raw altitude data will
result in similarly noisy data, and that we'll want to compute
gradient over a small distance around the data point.
I suppose if that distance is a constant, this could be done once and
the results stored in the RideFile.
--jtc
--
J.T. Conklin
Mark Liversedge
> Like the recent discussion about the use of filters to "de-noise"
> climbing/decending totals, I suspect using raw altitude data will
> result in similarly noisy data, and that we'll want to compute
> gradient over a small distance around the data point.
I assumed the same algorithm could be applied?
Jerry Zornes
------Original Message------
From: J.T. Conklin
Sender: golden-che...@googlegroups.com
To: liver...@gmail.com
Cc: golden-cheetah-users
ReplyTo: j...@acorntoolworks.com
Subject: Re: [Golden-Cheetah-Users] Slope / Gradient ?
Mark Liversedge <liver...@gmail.com> writes:
> If we're doing clever things for climbing/ascending can we populate a
> SLOPE field in the RideFile dataPoints? It would make for some very
> interesting charts, and would be a doddle to add to the 3d charts i.e.
> cadence & power by slope.
>
> Is this easy to do?
>
> (And I believe we would need to take care not to overwrite slope when
> some devices already provided it)
Would we want to record an instantaneous gradient in a RideFile, or is
this something that we want to compute at presentation time?
climbing/decending totals, I suspect using raw altitude data will
result in similarly noisy data, and that we'll want to compute
gradient over a small distance around the data point.
the results stored in the RideFile.
--jtc
--
J.T. Conklin
_______________________________________________
Golden-Cheetah-Users mailing list
golden-che...@googlegroups.com
http://groups.google.com/group/golden-cheetah-users?hl=en
Jamie Kimberley
look for changes in elevation that are bigger than a certain value
before we add that data to the computation of altitude gained.
I don't think that this scheme will work well for looking at the
slope, and a more traditional smoothing filter would probably be a
better approach. On way would be to define a distance over which we
want to measure the slope and use that as our guide (as opposed to
using a fixed # of data points or time) to smooth the data or
calculate an average slope over.
Jamie
"It is a mistake to think you can solve any major problems with just
potatoes."--Douglas Adams
__________________
Jamie Kimberley
Postdoctoral Fellow
Department of Mechanical Engineering
The Johns Hopkins University
Office: 410.516.5162
Mobile: 217.621.8272
Fax: 410.516.4316
E-Mail:jamie.k...@jhu.edu
Andy Froncioni
Aerolab. My motivation is to completely make the very best VE matching
tool possible. Please let me know if I've run completely past the
end-zone. :-)
I'm working off some very very good ideas I stole from Greg Steele's
workflow and Robert Chung's comments concerning systematic errors. ;-)
One important aspect of VE workflow is to be able to incorporate known
symmetries in the elevation profile. I've outlined two types of
possible marker points ( loop points and turn-around points ) that users
may wish to create in the attached image file. Each marker point creates
a transformation in an associated elevation-matching window. The
transformed segments make it easier to perform VE matching.
Loop points allow the interface to superimpose segments to eyeball a
match when loops are used. Turn-around points are used in out-and-back
trials. They transform the segments by reflecting one of the halves to
make visual matching better.
Additional construction objects could include:
- elevation anchor points (coordinates of known elevation)
- relative elevation pairs of points (that impose that two points have
the same elevation)
- wind segments ( intervals in which the user can impose a known tail-,
head-, or cross- wind speed to get a better elevation match )
- other imposed segments, based on measured values of temperature or
barometric pressure or relative humidity or road roughness that can help
improve
I'll keep posting updates to this interface until someone tells me to
stop... ;-)
Cheers,
Andy
Erik
some kind of sequencing info in the PF/PV chart.
Is an animation possible? Select a range or interval and watch the
data points paint the picture, faster than real-time ideally.
If not that, then a color code, dark to light, or blue to red, etc,
showing which data point was first and which was last.
As I've been doing a lot of long interval sessions lately, I've often
wondered what the PF/PV chart would look like sequentially in the 30
sec - 1 min range around the peaks and troughs of the 'hills' on my
course when I'm struggling to maintain a given power...
On Dec 30 2009, 10:19 am, Mark Liversedge <liverse...@gmail.com>
wrote:
> And on the same topic. It would be good to have a power slope too (not
> just altitude). That way we could do some interesting analysis aka
> Robert Chungs power expansion pathways (Greg, is that right?)
>
> I'll go back to my cave now.
Robert Chung
<a.fro...@sympatico.ca> wrote:
> One important aspect of VE workflow is to be able to incorporate known
> symmetries in the elevation profile.
Very nice. This is basically what I do, though the "turn-around" can
sometimes be a bit tricky if you're using an actual TT rather than a
special data collection run. The reason is that for many TTs you go
into the turnaround fast, pass the pylon, then brake hard, turn, and
accelerate back. The hard braking appears to VE like you just climbed
a sudden, short, and very steep hill so when I get a data file like
that I usually have to cut-out-and-splice the turnaround.
Robert Chung
On Jan 1, 10:54 am, Erik <erik.ols...@gmail.com> wrote:
> Seems to me that the way to make sense of expansion paths is to see
> some kind of sequencing info in the PF/PV chart.
That's part of it but it's not quite so easy. The issue is that for
any particular gear ratio, cadence and speed are strongly related.
This means that if you look at *really* short time intervals, all
you're going to see is that increasing power looks like it's almost
entirely a function of increasing pedal force. However, over a
slightly longer time period we accelerate and eventually the cadence
increases, too. The expansion path does mark combinations of pedal
speed and force but you have to "average" over long enough periods so
you're getting something akin to an equilibrium or quasi-equilibrium
at a higher speed (and, of course, power).
So the expansion path depends on the gear and, by extension, the slope
of the road. Which is why the expansion path is way to relate QA with
VE.
Robert Chung
On Jan 1, 8:26 am, Jamie Kimberley <jamie.kimber...@jhu.edu> wrote:
> As of now, Sean has implemented a threshold scheme in which we
> look for changes in elevation that are bigger than a certain value
> before we add that data to the computation of altitude gained.
Rather than look for ways to brute force the threshold, would it make
sense to sidestep and finesse it by looking at PE?
Jamie Kimberley
I'm not sure what you mean here, care to expand?
Jamie
Robert Chung
> On Fri, 1 Jan 2010, Robert Chung wrote:
>> Rather than look for ways to brute force the threshold, would it make
>> sense to sidestep and finesse it by looking at PE?
>
> I'm not sure what you mean here, care to expand?
Well, the issue seems to be how to cumulate gains from either GPS or
altimeter readings when those readings are noisy. There are two,
possibly three, basic reasons why we're interested in cumulating total
elevation: first, because we look at total elevation gain as a way to
describe the difficulty of rides; second, to help us recall and
identify rides we did in the past; and possibly third, for bragging
rights.
I think the second and third reasons are better served by notes,
photos, log entries, and story-telling over beer. As for the first, we
have power meters so rather than use an approximate way to evaluate
the difficulty of a ride we have a fairly precise way. In some sense,
elevation gain is sorta like HR: people collect it out of habit but
most of us can't figure out what to do with it when we already have
power info. But in any event, to get back to the original problem,
since cumulating the positive part of noisy data (or, the positive
part above a certain threshold) creates an artificial (really,
artifactual) total maybe the way to go is to sidestep the problem
entirely and just use some measurement of maximal change in PE over
the interval of interest.
Jamie Kimberley
Points well taken, I find it useful to have these numbers to
discuss over beer, it keeps me from drinking too much.
Can you define PE for me? I'm usually pretty good with TLA's (three
letter acronyms), but i find two letters often have too many
reasonable combinations for me to decipher.
Thanks,
Robert Chung
On Jan 2, 7:33 am, Jamie Kimberley <jamie.kimber...@jhu.edu> wrote:
> Points well taken, I find it useful to have these numbers to
> discuss over beer, it keeps me from drinking too much.
>
> Can you define PE for me? I'm usually pretty good with TLA's (three
> letter acronyms), but i find two letters often have too many
> reasonable combinations for me to decipher.
If you're using the numbers to restrict beer intake then you're using
them wrong.
I meant potential energy.
Jerry Zornes
--
Tom_A
On Jan 2, 7:24 am, Robert Chung <rech...@gmail.com> wrote:
> In some sense,
> elevation gain is sorta like HR: people collect it out of habit but
> most of us can't figure out what to do with it when we already have
> power info.
I mostly use it to more easily evaluate the power data. It's not
necessary...but it sure makes things easier for me. Even so, I'm just
talking about the altitude trace in general and not necessarily an
elevation gain summation...
Andy Froncioni
an initial issue with GC not summing some parts of the data, but Sean
fixed that.
My own simple algorithm (in perl, of course) to list all the hills (up
or down) generated results that made sense. At the very least the
results were reasonable for Fernando's FM_12_20_2009_0753_42_Miles.csv
file:
Hill #, Number of Samples, Net Climb
094, 859, 502
118, 149, 80
140, 202, 79
150, 143, 59
104, 98, 56
062, 116, 53
154, 97, 51
122, 77, 50
086, 130, 43
... records omitted ...
149, 52, -50
171, 67, -50
121, 58, -52
135, 75, -52
189, 77, -53
103, 88, -68
233, 139, -82
153, 63, -84
101, 262, -524
============================================================================================
Total: 579 Hills, Samples: 9831, Ascent: 1437ft, Descent: 1423ft, Net: 14.000000ft
You can threshold the middle (near zero) values to get any answer you want basically. But other than matching the iBike display, I don't know why you would do that.
Cheers,
Andy
Robert Chung
On Jan 2, 7:47 am, Tom_A <theanha...@gmail.com> wrote:
> I mostly use it to more easily evaluate the power data. It's not
> necessary...but it sure makes things easier for me. Even so, I'm just
> talking about the altitude trace in general and not necessarily an
> elevation gain summation...
Yeah, the trace can come in handy even when it's noisy. What I can't
figure out how to use is the summary statistic -- except, of course,
as an aid to bibulation.
Andy Froncioni
> I guess the question is, Is it robust enough to be true in all cases or in the one you looked at? I know this sounds like a nit but I'm building some models and they appear to show that profile changes (sample related) are to some extent speed related. WIthout a window and smoothing algorithm to account speed/road variation ie. noise.
>
I had it sorted by ascent. If you sort the output by number of samples
in each climb, you get a better picture of what to filter out, if that's
what you want to do:
Hill #, Number of Samples, Ascent(ft)
094, 859, 502
101, 262, -524
140, 202, 79
118, 149, 80
150, 143, 59
233, 139, -82
086, 130, 43
... stuff left out ...
053, 1, 0
052, 1, 0
039, 1, 1 <-
034, 1, -2 <- single-sample climbs
015, 1, 2 <-
014, 1, 0
010, 1, 0
009, 1, 0
006, 1, 0
Total 579 Samples: 9831 Ascent: 1437 Descent: 1423 Net: 14.000000
I can see a case for omitting single-sample climbs maybe, but I'm not
crazy about filtering on vertical ascent. 2 consecutive samples of
very low ascent should still be counted.
Jim Ley
> crazy about filtering on vertical ascent. 2 consecutive samples of
> very low ascent should still be counted.
Personally I want even more than that filtered out. Basically any
climbing that is simple alternating 1-2% gradients for a few hundred
meters - like you get following a road alongside a river or similar I
don't want to count. What I'm interested in is the amount of
climbing that is part of actual climbing efforts. So gentle rolling
you don't notice just happen to speed up/slow down as you put out
solid identical watts isn't counted. But 10 minutes at 4% is counted.
Of course this really highlights that what people want is different
things, as Robert says. I'm very much in the first of his reason to
have an interest in meters gained. I'm not sure there is a good
single solution that deals with both the noisiness and the different
peoples needs.
Possibly best to just leave it as whatever creates the highest value,
so those who want it for willy waving get to see big numbers.
Jim.
Sean Rhea
> I think the second and third reasons are better served by notes,
> photos, log entries, and story-telling over beer.
To that end, I would like to propose a new metric, "Tall Tale Points".
If your ride is a loop (based on GPS data), but it has a positive
elevation gain, you get 100 points. If it's below freezing and the
humidity is such that it was likely to be snowing, you get another 100
points. As such, a ride that is uphill both ways in the snow will be
worth 200 points.
Sean
--
"I refuse to accept the idea that the ‘isness’ of man’s present nature
makes him morally incapable of reaching up for the eternal ‘oughtness’
that forever confronts him." --MLK
Robert Chung
On Jan 2, 9:34 am, Sean Rhea <sean.c.r...@gmail.com> wrote:
> To that end, I would like to propose a new metric, "Tall Tale Points".
You know how some spreadsheets have a "goal seek" function? Maybe you
guys could develop a joaquin module.
Jerry Zornes
Jerry
Jerry Zornes
Jerry