Login required to started new threads

Login required to post replies

Prev Next
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [NickD1] [ In reply to ]
Quote | Reply
NickD1 wrote:
I suspect most people haven't gone for that variant of the Compton Challenge because the most obvious way to check a method for determining CdA is to change the CdA and see what can be detected (Iā€˜m assuming the majority of people that are using your method are doing it to get a CdA estimate).
Yeah, I'm sure that's true. It seems backwards to measure precision in CdA by looking at precision in measurement of mass -- but in all these cases we're just measuring differences in drag. In fact, if we had a truly accurate way to measure height you could measure how small of a difference in elevation you could detect, so an alternative I'd been thinking of was building a little ramp of known height, maybe 15 cm high, and rolling over that. If the data and method estimated the ramp as X cm, that would be a way to assess precision. But once again you run into the problem that people think they should be altering CdA, not ramp height. So I haven't done that experiment. But I'm reasonably sure it'd work.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
How does mass affect drag? Through inertia and gravity and friction but not shape of a body. What is gained from altering mass?
Last edited by: BergHugi: Aug 21, 20 14:33
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [BergHugi] [ In reply to ]
Quote | Reply
BergHugi wrote:
How does mass affect drag? Through inertia and gravity and friction but not shape of a body. What is gained from altering mass?

You're altering mass by a known amount without changing the shape of the body so the drag should change by a known amount. So we measure the amount it does change and compare it to the amount it should change.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
And if you alter the mass by the amount 0 you actually know how drag should change and compare it to the amount drag does change.

There are easier ways to measure mass, just compare it with a known mass.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Not replying to anything in this thread in particular but just want to check a few things before I start my own testing for the first time ever. I have a lot of things I want to try.

1. How important is a separate speed sensor vs GPS? Don't currently have one but don't mind buying one if it's going to drastically improve results.
2. I know the rule is absolutely no braking and hold position, but does that also apply to the turnaround if doing a half-pipe? If I'm testing in aero position, do I need to find a course with a spot wide enough to turn around in aero or better yet, a loop? Or is the turn around slow enough that it shouldn't affect the data.
3. Is there a minimum elevation gain/loss required for the course? I can think of a fairly nice stretch of road but the dips are very minimal.

Thanks all.

Benjamin Deal - Professional - Instagram - TriRig - Lodi Cyclery
Deals on Wheels - Results, schedule, videos, sponsors
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [realbdeal] [ In reply to ]
Quote | Reply
realbdeal wrote:
Not replying to anything in this thread in particular but just want to check a few things before I start my own testing for the first time ever. I have a lot of things I want to try.

1. How important is a separate speed sensor vs GPS? Don't currently have one but don't mind buying one if it's going to drastically improve results.
Depends on how good the GPS signal is. I prefer test venues that have some shelter from trees to dissipate the wind, but trees can block the GPS signal. If your test venue is a straight road, the signal is less important than if there's a curve (especially if the tree cover is right at the point where the curve is located). In addition, some older head units are smaller, so the size of the GPS antenna is smaller, so the positioning isn't quite as good. From a practical perspective, I'd do a quick non-critical ride on the course and come back and look at the GPS trace and especially the speed changes from second to second. If the trace is good and the speed changes look smooth rather than jumpy, you might be okay without a dedicated wheel sensor. If not, you're probably going to have to get one if you want acceptable precision.

Quote:
2. I know the rule is absolutely no braking and hold position, but does that also apply to the turnaround if doing a half-pipe? If I'm testing in aero position, do I need to find a course with a spot wide enough to turn around in aero or better yet, a loop? Or is the turn around slow enough that it shouldn't affect the data.
Sometimes you have no other choice than to use brakes (not just for the turnaround, but for cars or dogs or other obstacles). The #1 rule is don't get hit, and don't hit anyone else. That's also rules 2 and 3. That said, I've used test venues where I had to brake at the turnaround but I'm sorta used to snipping out that part of the data and stitching the parts back together. That might be too advanced for most people, at least with current tools. I would say that *if* you are going to use the brakes, don't feather them, hit them hard so that it's clear where you did use them. What you don't want is to wonder where you used the brakes.


Quote:
3. Is there a minimum elevation gain/loss required for the course? I can think of a fairly nice stretch of road but the dips are very minimal.
Not really. People do this on velodromes, where the change in elevation is maybe a few inches. The real reason why a half pipe course is handy isn't because the elevation change is necessary, it's because it's handy to get a wide range of speeds and the climb at the ends slows you down enough so that you don't have to use the brakes (much) at each end.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Appreciate it Robert. Thank you.

Last question because I couldn't find a solid answer anywhere, should the start of each run be rolling or from a standstill?

I realized the best thing for me to do will just be go out there and give it attemps and start learning, but I just want to make sure I'm not making any obvious mistakes.

Benjamin Deal - Professional - Instagram - TriRig - Lodi Cyclery
Deals on Wheels - Results, schedule, videos, sponsors
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [realbdeal] [ In reply to ]
Quote | Reply
realbdeal wrote:
should the start of each run be rolling or from a standstill?


It doesn't matter all that much, but I usually do rolling so I can already be locked into position when I hit the lap button rather than fiddle around getting into position. For a half-pipe course, Tom A. has talked about hitting the lap button a few seconds before the lap "start" as he approaches the first turnaround, and he hits the lap button again a few seconds after the crest of the last turnaround. He doesn't hit the lap button during the test so he can stay in position all the test without moving his hands. I do the same, even when the course isn't a half-pipe: I hit the lap button once before the point where I'm going to start, and then after the very end. Usually it's pretty easy to spot the laps so you don't have to mark them explicitly with the button. Hitting the button before the "official" start of the lap and then after the end gives you two extra well-defined peaks to line up.

An oddity that I've had is that the data from my very first lap is often noisier than subsequent laps. I used to worry about this a lot and tried to track down why that was but, in the end, I decided it was more practical just to plan on doing an extra lap at the start (for example, if I planned on 3 laps for each test, I'd do 4 laps instead for the very first one). Then, if the data are noisy, I just toss that first lap. This is one of the reasons why I try not to make my laps 2 or 3 miles long; shorter laps let you do more of them, and if you have to toss one lap, not only for noisiness but also for a passing car or a chasing dog, it's not so painful.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [realbdeal] [ In reply to ]
Quote | Reply
Question for the group:

For half pipe testing can I get out of aero for the turnarounds? So few course options around me but if I'm allowed to do that for a tighter turn around I think I have a spot.

Benjamin Deal - Professional - Instagram - TriRig - Lodi Cyclery
Deals on Wheels - Results, schedule, videos, sponsors
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [realbdeal] [ In reply to ]
Quote | Reply
realbdeal wrote:
Question for the group:

For half pipe testing can I get out of aero for the turnarounds? So few course options around me but if I'm allowed to do that for a tighter turn around I think I have a spot.

That's what I do. Since you're travelling slowly (or should be) at the turnarounds on a "half-pipe" course, the effects on the total run of getting out of aero are extremely small, so being able to quickly sit up, look around, and make sure your turn is safe to do is what is paramount.

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [realbdeal] [ In reply to ]
Quote | Reply
I concur with Tom A.... slow down, sit up, look behind, then turn.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
I have a course that is a straight road with a cul-de-sac/lollipop at one end. It doesn't have enough elevation change to really slow down using only gravity so I coast for a bit and then I sometimes turn aggressively if I haven't slowed as much as anticipated at the lollipop. It seems that the aggressive turn is scrubbing off quite a bit of speed almost as if I were lightly applying the brakes through the corner. When I thought about the original set of equations in the presentation, there isn't anything to account for cornering forces or lateral acceleration. Are there any general rules about how much "cornering" is too much or is it really important to limit any hard cornering?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [grumpier.mike] [ In reply to ]
Quote | Reply
You can generally see the hard corners. I have a venue that is sort of like what you're describing, with a wider turnaround at one end and a narrow turnaround at the other. I coast at a softpedal as I approach, then often have to feather my brakes. I try to do that in the same spot each time and then either snip or "re-tare" the VE profile at that point. It's kind of a pain so I don't do that in Aerolab and instead use my own analytical routines.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [ In reply to ]
Quote | Reply
I wanted to contribute some data, particularly in relation to what i think was successful application of the Shen approach to pry apart CDA and CRR given there have been a few comments about not being able to get it to work

Power meter: Powertap
Tires - GP5000, one latex one butyl. - pumped to 90PSI
Test conditions
Temp -17.9c
Rho calculated as 1.206
Unfortunately not windstill but seems to have still produced reasonable data.
Used Speed sensor from Powertap
Weighed myself with all gear at 83.7kg

The main part of the run was 6 laps, the track is about 460m, rode the black line as best as my skill allowed. Slowest lap was about 25km/h, and fastest was about 42km/h

Used Golden Cheetah Aerolab to do the analysis. I started by putting in unrealistically low CRRs and unrealistically high CRR - this exaggerates the "bow" shape of the virtual elevation plot when CRR/CDA combination is not the "true" elevation. I found this to be key to observing the convergence of the solution and being able to identify more subtle under or over estimates. For example, see below and a few GC chart images

CRR CDA Comment
0.002 0.28 Highly Concave virtual elevation
0.009 0.178 Highly Convex virtual elevation
0.004 0.25 Concave still clearly visible
0.007 0.2065 Convex still clearly visible
0.005 0.2356 Close, but still slightly concave
0.006 0.2213 Close but very slightly convex
0.055 0.228 Very very close to a straight line.....

I found the Shen method and approach very valuable. While the surface is far from "glass" smooth, I would have assumed lower CRRs and overall this has me thinking that i have probably setting CRR assumptions too low.

What would have been helpful is for the GC y-axis scale to be more adjustable - as i think would have assisted in amplifying the concave or convex bow shape even better to allow more fine-tuning.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [ryinc] [ In reply to ]
Quote | Reply
ryinc wrote:
I wanted to contribute some data, particularly in relation to what i think was successful application of the Shen approach to pry apart CDA and CRR given there have been a few comments about not being able to get it to work
[..]
Rho calculated as 1.206

Your first post after 5 years? Very nice.

Yes, this is a good example of how to use Andy Shen's protocol. There are other ways to pry apart Crr and CdA but they require some math and this is a nice explanation.

Was rho really that high? Were you using GC's rho calculator? Remember that it assumes that you're using "station" baro pressure, not "offical" baro pressure that is standardized to sea level.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
 
Was rho really that high? Were you using GC's rho calculator? Remember that it assumes that you're using "station" baro pressure, not "offical" baro pressure that is standardized to sea level.

Mmmm, i used the value directly from "MyWindsock.com" which integrates weather data but now you have me second guessing. whether that site has somehow calculated it incorrectly? A bit of a problem if that is the case!
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [ryinc] [ In reply to ]
Quote | Reply
ryinc wrote:
The main part of the run was 6 laps, the track is about 460m, rode the black line as best as my skill allowed. Slowest lap was about 25km/h, and fastest was about 42km/h

Thanks, I hadnā€™t come across that method from Andy Shen before, although in the past I have in also noticed the same convex and concave shapes of the VE profiles in the testing and analysis that Iā€™ve done, when trying to find the correct combination of CdA and CRR.

Perhaps one thing to clarify is how you are varying the speed? I noticed in Andy Shenā€™s article that he mentions a ā€œsteadily accelerating rideā€. I guess youā€™re doing the same, slow laps initially and finishing fast?

When Iā€™ve done testing in the past, Iā€™ve done the opposite - for no particular reason - started fast for the first lap and gradually slowed down. If you do it in this decelerating way instead, the VE profiles would have the opposite relationship with CRR compared with the plot in Andy Shenā€™s article. This could be useful to note, in case other people use a decelerating protocol.

Also, when you said that a too low CRR gives a ā€œhighly concave VE profileā€, your plot seems to show a convex profile instead, i.e. a VE profile that rises, peaks, then falls. I would call that convex personally, so could it be a mistake in your post perhaps, or could there be some ambiguity in those concave and convex terms?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [NickD1] [ In reply to ]
Quote | Reply
NickD1 wrote:
ryinc wrote:

The main part of the run was 6 laps, the track is about 460m, rode the black line as best as my skill allowed. Slowest lap was about 25km/h, and fastest was about 42km/h


Thanks, I hadnā€™t come across that method from Andy Shen before, although in the past I have in also noticed the same convex and concave shapes of the VE profiles in the testing and analysis that Iā€™ve done, when trying to find the correct combination of CdA and CRR.

Perhaps one thing to clarify is how you are varying the speed? I noticed in Andy Shenā€™s article that he mentions a ā€œsteadily accelerating rideā€. I guess youā€™re doing the same, slow laps initially and finishing fast?

When Iā€™ve done testing in the past, Iā€™ve done the opposite - for no particular reason - started fast for the first lap and gradually slowed down. If you do it in this decelerating way instead, the VE profiles would have the opposite relationship with CRR compared with the plot in Andy Shenā€™s article. This could be useful to note, in case other people use a decelerating protocol.

Also, when you said that a too low CRR gives a ā€œhighly concave VE profileā€, your plot seems to show a convex profile instead, i.e. a VE profile that rises, peaks, then falls. I would call that convex personally, so could it be a mistake in your post perhaps, or could there be some ambiguity in those concave and convex terms?


Yes, i increased speed each lap.

Yes, if you switched the order of the protocol (i.e. fast speeds first), then if your CRR is too low (and CDA too high) to solve for zero net elevation - then at fast speeds the VE model assumes you must be going downhill to make the equation work (i.e. compensation for a CDA that is too high), and at slow speeds (when CRR is a bigger percentage contributor than at fast speeds), the curve would start to slope up again as the model predicts an incline to compensate for the CRR that is too low).

It wasn't a typo, i did interpret that as concave shape, but apologies for any potentially confusing/ambiguous language which is not necessary. In short, yes - rising, peaking and the falling when CRR is too low, and an increasing speed Shen protocol is followed and what i am referring to.




Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [ryinc] [ In reply to ]
Quote | Reply
Thanks
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [NickD1] [ In reply to ]
Quote | Reply
NickD1 wrote:
Thanks, I hadnā€™t come across that method from Andy Shen before, although in the past I have in also noticed the same convex and concave shapes of the VE profiles in the testing and analysis that Iā€™ve done, when trying to find the correct combination of CdA and CRR.

I discussed in my presentation, around slides 40-44 (or alternatively, slides 96-100). The key is varying speed -- I had been looking at varying speed within and across laps since I knew that variations in speed affect aero and rolling drag differently, but I had gotten so used to how they vary that I'd trained my brain to look for distinctive patterns even if the speed didn't change monotonically. I just sorted the laps in speed order. (You can see an example just before I talk about Andy's protocol where I was doing hill climbs at different speeds and power, then sorted the runs by speed and looked to see if the VE profiles also sorted by speed). Andy had the idea to try monotonically changing speed so that you all wouldn't have to do all that. It's really quite clever.

(And, as I've said, there are analytical ways to do this, but this visual fitting is much easier for people to understand than a bunch of equations).
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Sorry, I hadnā€™t noticed those plots on slide 44 when I read your slides a few years ago (despite having read them a couple of times!). The information canā€™t have sunk in properly. What I should have done is gone back and re-read them, after using your method in anger. There are lots of little tips and tricks explained throughout, that I only notice and understand properly now that Iā€™m more familiar with the method.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [NickD1] [ In reply to ]
Quote | Reply
NickD1 wrote:
Sorry, I hadnā€™t noticed those plots on slide 44 when I read your slides a few years ago (despite having read them a couple of times!). The information canā€™t have sunk in properly. What I should have done is gone back and re-read them, after using your method in anger. There are lots of little tips and tricks explained throughout, that I only notice and understand properly now that Iā€™m more familiar with the method.

I'm the one who's sorry. I should've done a series of explanatory posts or videos or seminars or rewritten that thing to make it clearer years ago to help people understand the subtler bits. Prying apart CdA and Crr is one of them. (Many people still seem to think you have to assume a value of Crr.)
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Forgive me for asking without reviewing any papers, but why would programmers need guidance to implement a least-squared error fit using your energy model?

Provided road and wind conditions are constant, time series data with arbitrary velocities and altitudes should fit the model and can be found with old, standard methods.

Iā€™ve suggested this in a recent post, but Iā€™d like to see a running convergence of Cda and Crr on a cycling computer using this method. Start a new test, bike, compute the best fit and variance, use the variance to flag the values green or something visual to denote convergence below a certain value. Perhaps with an additional check that there is not a step change in conditions (asphalt change or gusts, or rider position, or braking). This way, one can perform a-b-a type tests on reasonable roads and wind conditions. See the student-T distribution and estimating the ā€œtrue meanā€, relevant section in Low-Speed Wind Tunnel Testing (Barlow et al.). This would be something like a Kalman Filter with fading memory or explicit resetting of memory under chosen tolerances.
Last edited by: codygo: Jan 12, 21 13:21
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [codygo] [ In reply to ]
Quote | Reply
codygo wrote:
Forgive me for asking without reviewing any papers, but why would programmers need guidance to implement a least-squared error fit using your energy model?

Provided road and wind conditions are constant, time series data with arbitrary velocities and altitudes should fit the model and can be found with old, standard methods.

Iā€™ve suggested this in a recent post, but Iā€™d like to see a running convergence of Cda and Crr on a cycling computer using this method. Start a new test, bike, compute the best fit and variance, use the variance to flag the values green or something visual to denote convergence below a certain value. Perhaps with an additional check that there is not a step change in conditions (asphalt change or gusts, or rider position, or braking). This way, one can perform a-b-a type tests on reasonable roads and wind conditions. See the student-T distribution and estimating the ā€œtrue meanā€, relevant section in Low-Speed Wind Tunnel Testing (Barlow et al.). This would be something like a Kalman Filter with fading memory or explicit resetting of memory under chosen tolerances.

So, you seem pretty familiar with statistical modeling, and that's good. The underlying main issue is that in field testing where you don't get to control every variable, errors are typically not well behaved with zero mean, fixed variance and, critically, they're not iid. So the Gauss-Markov theorem doesn't apply and the least squares estimator is neither unbiased nor efficient. In real tests on real roads, a gust of wind in one direction isn't usually balanced by an equal and opposite gust, and a passing car or a dip in the road or a jiggle in your position don't balance out. VE takes into account that the errors aren't iid (just as in time series analysis the errors aren't iid -- however in TS, we can often do an empirical correlogram to get an idea of some ARIMA-type model so even though the errors aren't iid, they're well-behaved). So anyway, VE was kind of a robust diagnostic for deviations from modeled fit where the objective function isn't the standard Martin power-for-speed model but an elaboration of a work-for-duration model (which you can get to from the Martin model). That said, the Track Aero System that Alphamantis developed does use Kalman filters to get its near real-time estimates of CdA. I don't know enough about how the Notio/Aerolab Tech/Velocomp/etc. models work but I *suspect* they try to do something similar. The bottom line is that convergence to a solution isn't the issue, the issue is whether it converges to the *right* solution.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Hi, thanks for responding. What you said makes sense, but Iā€™m suggesting that a real time metric for gusts or other disturbances can be developed and used to invalidate or reinitialize a run that contains such deviations. Essentially, if the convergence isnā€™t Cauchy after some minimal period of time, we can assume something ā€œnot niceā€ happened during the run that would invalidate the data even if it were calculated in a ā€œrobustā€ manner. That is, we could get a value but that value is tainted by an unquantified gust/position change, etc. mid run.

Perhaps this requires directly using what you refer to as ā€œMartinā€™s power-for-speed modelā€, but Iā€™d assume that a good test at least implies absence of these disturbances, so why not build in checks that practically guarantee their absence?
Quote Reply

Prev Next