Login required to started new threads

Login required to post replies

Prev Next
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [MTM] [ In reply to ]
Quote | Reply
Simply adding the headwind column in the editor seems to break aerolab for me

-Take a file that works fine in aerolab
-Insert headwind column, leaving 0s everywhere
-Aerolab becomes unusable
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
Have you tried copying the speed data into the headwind column? I.e. basically telling it there was no wind.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [MTM] [ In reply to ]
Quote | Reply
LOL. I do have contacts in Copenhagen :)
I've got a much better(GLONASS) GPS for next year. I've used an 800, 520 and 520 for various runs. The 520 was the best of those. There is a thread on here somewhere about the project. If you wish to know more it might be worth posting there to stop us drifting off topic.

Developing aero, fit and other fun stuff at Red is Faster
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [MTM] [ In reply to ]
Quote | Reply
thanks, that fixed it.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Advice from the experts please;


I have found a great spot to do laps which is;

a) near to home (very repeatable)
b) a 'good' length (0.8 mile)
c) very quiet outside of normal working hours
d) has variability in gradients

BUT there is a roundabout at the bottom of a slope (I'm blind to traffic approaching the r/a due to the layout) meaning that braking is a necessity (I don't fancy chancing it).

SO... can I use the laps BUT get rid of the braked data? Would it be easier to not have that section of data included in the first instance; my plan is to stop the Garmin at a particular point each lap BEFORE braking and then restart at a point at a similar height (after ascending from the r/a). Would this still give usable results and would it be better to set the Garmin to start and finish at specific points (so I don't have to fiddle with the Garmin/get out of the TT position etc)?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [esox.flucius] [ In reply to ]
Quote | Reply
Find a different spot.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jbank] [ In reply to ]
Quote | Reply
The only bit of suitable road I can find has a dead turn at either end, a come out of aero and brake job.
Can I cut out these sections and get just the out and back?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tomato] [ In reply to ]
Quote | Reply
Coming up and out of aero if you are going very slow is not a deal breaker. Using your brakes at all is. Perhaps RChung has some ideas/method to post-process with cutting those sections out, but seems highly suspect and error prone. This is the whole rationale for a "half-pipe", you use the hill to slow you down enough to turn on both ends so you don't need to brake. A loop hopefully has the same nice property.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tomato] [ In reply to ]
Quote | Reply
Tomato wrote:
The only bit of suitable road I can find has a dead turn at either end, a come out of aero and brake job.
Can I cut out these sections and get just the out and back?

If you do brake, brake hard so that it looks like a hill with a slope you couldn't possibly have ridden. Brakes, rolling resistance, and slope all the look the same to the physics.

F = ( Crr + s + b )* m*g , where
s = slope and
b = braking

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tomato] [ In reply to ]
Quote | Reply
Tomato wrote:
The only bit of suitable road I can find has a dead turn at either end, a come out of aero and brake job.
Can I cut out these sections and get just the out and back?
Yes you can just cut out that section. I just hit lap on my Garmin twice and cut the piece in between. Use a marker on the road to precisely start and stop at the same point, and pedal through in both directions. I.e. pedal through the stop, turn around, and then start pedalling before the start (just helps with some Garmin recording issues). While I usually use a "half pipe", I actually wrote some simple java software that cuts out the turnaround automatically if needed so it's super easy.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [esox.flucius] [ In reply to ]
Quote | Reply
esox.flucius wrote:
Advice from the experts please;


I have found a great spot to do laps which is;

a) near to home (very repeatable)
b) a 'good' length (0.8 mile)
c) very quiet outside of normal working hours
d) has variability in gradients

BUT there is a roundabout at the bottom of a slope (I'm blind to traffic approaching the r/a due to the layout) meaning that braking is a necessity (I don't fancy chancing it).

SO... can I use the laps BUT get rid of the braked data? Would it be easier to not have that section of data included in the first instance; my plan is to stop the Garmin at a particular point each lap BEFORE braking and then restart at a point at a similar height (after ascending from the r/a). Would this still give usable results and would it be better to set the Garmin to start and finish at specific points (so I don't have to fiddle with the Garmin/get out of the TT position etc)?

As AndyF and Lanierb have said, it's possible to snip out the part where you brake -- but it's kind of a hassle. If the next best venue is far away, I'd use this one and snip it. If the next best venue is close, I might use that one.

I do what Lanier and Andy do: I identify a landmark (can be a chalk mark you "X" onto the pavement) and hit the brake hard there or hit the interval button (depends on how fast I'm going) then turn around and when I come up to the "X" from the other side I hit the interval button again.

The hassle part is that when I snip out parts of ride files, I can't really use Aerolab since there's an "offset" in the elevation at the point when I hit the brakes. I have a bunch of little code snippets that let me analyze the data so I use those, but not everyone can do that.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
esox.flucius wrote:
Advice from the experts please;


I have found a great spot to do laps which is;

a) near to home (very repeatable)
b) a 'good' length (0.8 mile)
c) very quiet outside of normal working hours
d) has variability in gradients

BUT there is a roundabout at the bottom of a slope (I'm blind to traffic approaching the r/a due to the layout) meaning that braking is a necessity (I don't fancy chancing it).

SO... can I use the laps BUT get rid of the braked data? Would it be easier to not have that section of data included in the first instance; my plan is to stop the Garmin at a particular point each lap BEFORE braking and then restart at a point at a similar height (after ascending from the r/a). Would this still give usable results and would it be better to set the Garmin to start and finish at specific points (so I don't have to fiddle with the Garmin/get out of the TT position etc)?


As AndyF and Lanierb have said, it's possible to snip out the part where you brake -- but it's kind of a hassle. If the next best venue is far away, I'd use this one and snip it. If the next best venue is close, I might use that one.

I do what Lanier and Andy do: I identify a landmark (can be a chalk mark you "X" onto the pavement) and hit the brake hard there or hit the interval button (depends on how fast I'm going) then turn around and when I come up to the "X" from the other side I hit the interval button again.

The hassle part is that when I snip out parts of ride files, I can't really use Aerolab since there's an "offset" in the elevation at the point when I hit the brakes. I have a bunch of little code snippets that let me analyze the data so I use those, but not everyone can do that.

Thanks for replying Robert, appreciate you taking the time. Would it not be easier to just stop the Garmin just prior to the point of braking and then starting it again at the same point on the way back? Or would this not work as effectively? Similarly in my situation; could I stop the Garmin at the same point going into the round about, brake, accelerate out and start the Garmin at the same point each time on the way out (the second point being at the same altitude as the first, in a 'loop').
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [esox.flucius] [ In reply to ]
Quote | Reply
esox.flucius wrote:
Would it not be easier to just stop the Garmin just prior to the point of braking and then starting it again at the same point on the way back? Or would this not work as effectively? Similarly in my situation; could I stop the Garmin at the same point going into the round about, brake, accelerate out and start the Garmin at the same point each time on the way out (the second point being at the same altitude as the first, in a 'loop').

Hmmm. I don't use a Garmin so I don't know how many key presses it takes to "stop" one. I just hit the interval or lap marker, which takes one quick button press, as I pass my landmark.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [esox.flucius] [ In reply to ]
Quote | Reply
esox.flucius wrote:
RChung wrote:
esox.flucius wrote:
Advice from the experts please;


I have found a great spot to do laps which is;

a) near to home (very repeatable)
b) a 'good' length (0.8 mile)
c) very quiet outside of normal working hours
d) has variability in gradients

BUT there is a roundabout at the bottom of a slope (I'm blind to traffic approaching the r/a due to the layout) meaning that braking is a necessity (I don't fancy chancing it).

SO... can I use the laps BUT get rid of the braked data? Would it be easier to not have that section of data included in the first instance; my plan is to stop the Garmin at a particular point each lap BEFORE braking and then restart at a point at a similar height (after ascending from the r/a). Would this still give usable results and would it be better to set the Garmin to start and finish at specific points (so I don't have to fiddle with the Garmin/get out of the TT position etc)?


As AndyF and Lanierb have said, it's possible to snip out the part where you brake -- but it's kind of a hassle. If the next best venue is far away, I'd use this one and snip it. If the next best venue is close, I might use that one.

I do what Lanier and Andy do: I identify a landmark (can be a chalk mark you "X" onto the pavement) and hit the brake hard there or hit the interval button (depends on how fast I'm going) then turn around and when I come up to the "X" from the other side I hit the interval button again.

The hassle part is that when I snip out parts of ride files, I can't really use Aerolab since there's an "offset" in the elevation at the point when I hit the brakes. I have a bunch of little code snippets that let me analyze the data so I use those, but not everyone can do that.


Thanks for replying Robert, appreciate you taking the time. Would it not be easier to just stop the Garmin just prior to the point of braking and then starting it again at the same point on the way back? Or would this not work as effectively? Similarly in my situation; could I stop the Garmin at the same point going into the round about, brake, accelerate out and start the Garmin at the same point each time on the way out (the second point being at the same altitude as the first, in a 'loop').

I think some things are just easier to deal with in a spreadsheet since it requires some level of manual manipulation of data. It's not hard, just a little fiddly. Overlay the VE plot for each of the outward runs on top of each other (and same for return runs) and force the start of each run to begin with same elevation. Enter in assumptions so that at least one of the VE lines resembles the actual elevation change for the section.

Then you see which plots climb an apparently steeper hill than others (or show a less steep decline). The question then becomes why they exhibit such behaviour? In an ideal world it'd be all because of the change you made to your set up, but of course it may also be for uncontrollable things, e.g. differences in air movement (wind, traffic etc).

http://www.cyclecoach.com
http://www.aerocoach.com.au
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AlexS] [ In reply to ]
Quote | Reply
AlexS wrote:
I think some things are just easier to deal with in a spreadsheet since it requires some level of manual manipulation of data. It's not hard, just a little fiddly.
Yeah, sometimes describing what to do takes more time than just doing it. Popping the data into a spreadsheet and snipping out (or, just ignoring) the turnarounds is pretty simple as long as you hit the interval marker.

Quote:
Overlay the VE plot for each of the outward runs on top of each other (and same for return runs) and force the start of each run to begin with same elevation.
When I'm doing an out-and-back I sometimes "mirror" the runs. If all the outbound runs have a little less total VE gain than all the inbound runs, you know there must've been a tailwind on the way out and a headwind on the way back.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Thanks Rob,
For an out and back how far would you aim for. I have one that is 1 mile stretch so 2 miles in total.

I have a place I can turn at each end, I have to coast right down and come out of aero but can avoid braking.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AlexS] [ In reply to ]
Quote | Reply
AlexS wrote:
In an ideal world it'd be all because of the change you made to your set up, but of course it may also be for uncontrollable things, e.g. differences in air movement (wind, traffic etc).

Well, at least with the field testing I've done, things like traffic and wind show up as inconsistencies in the VE plot from lap to lap and can thus be identified. I use a very quiet road and only do testing on low-wind days and I find the VE plot very consistent lap to lap, when an occasional car does pass I can see it as an identifiable inconsistency in that one lap and ignore that lap. I've done VE laps on windier days just as practice and the inconsistencies lap to lap and thus lack of data integrity are very clear from the VE plot.

I suppose it's possible for wind to be very consistent and introduce a systemic error that doesn't show inconsistencies lap to lap but at least where I live when there's wind there's also inconsistency. Plus wind is not something our senses can't detect, not that hard to look at the wind speed on weather underground, look at the movement in the leaves, etc. etc.

Seems to me the real challenge is being able to time your VE sessions to occur on low-wind days. I only might see 2-3 such days in a month but I have a flexible work schedule and can do my testing at a time when the road's quiet and temperature is stable, but a lot of folks don't have that flexibility.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tomato] [ In reply to ]
Quote | Reply
Tomato wrote:
Thanks Rob,
For an out and back how far would you aim for. I have one that is 1 mile stretch so 2 miles in total.

I have a place I can turn at each end, I have to coast right down and come out of aero but can avoid braking.

I've used out-and-backs that are about that length. I like them to be relatively short so I can do more "laps" while long enough so that I can get a wide range of speed. That is, I like to have a couple of chances to ramp slowly up to TT speed, then coast down, then ramp up again, then coast down for the turnaround. So something along the lines of a kilometer or a mile or so is about the right length. I ramp up and coast down (I soft pedal during the coast downs) on loops, too.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [tttiltheend] [ In reply to ]
Quote | Reply
tttiltheend wrote:
Well, at least with the field testing I've done, things like traffic and wind show up as inconsistencies in the VE plot from lap to lap and can thus be identified. I use a very quiet road and only do testing on low-wind days and I find the VE plot very consistent lap to lap, when an occasional car does pass I can see it as an identifiable inconsistency in that one lap and ignore that lap. I've done VE laps on windier days just as practice and the inconsistencies lap to lap and thus lack of data integrity are very clear from the VE plot.

I suppose it's possible for wind to be very consistent and introduce a systemic error that doesn't show inconsistencies lap to lap but at least where I live when there's wind there's also inconsistency. Plus wind is not something our senses can't detect, not that hard to look at the wind speed on weather underground, look at the movement in the leaves, etc. etc.

Seems to me the real challenge is being able to time your VE sessions to occur on low-wind days. I only might see 2-3 such days in a month but I have a flexible work schedule and can do my testing at a time when the road's quiet and temperature is stable, but a lot of folks don't have that flexibility.

Yeah, VE is actually a diagnostic for the estimator, not the estimator itself. What's cool about VE is that you can, as you've observed, easily see when the run was screwed up by a passing car or a gust of wind, so you can evaluate the quality of the data.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
AndyF wrote:
If you start getting serious about this, then invest in one of these: http://www.onetreeknoll.com/...ductCode=PI-W-4250BT

Hey Andy do you have an updated link or recommendation for this? Thanks
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [kileyay] [ In reply to ]
Quote | Reply
kileyay wrote:
AndyF wrote:
If you start getting serious about this, then invest in one of these: http://www.onetreeknoll.com/...ductCode=PI-W-4250BT


Hey Andy do you have an updated link or recommendation for this? Thanks

Sorry - yes, here is what you need: https://kestrelmeters.com/...el-5100-racing-meter

Just let me know how I can help, ok?

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
Thanks!
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply


Greetings Everyone,
I have been TTing for three years with good success, and now am looking for ways to try to bridge up to the elites in Northern California. I have been playing with the Aero Lab in the Golden Cheetah software and have done a few trial tests. The one I am uploading is just on a road bike, I did a hands on the hoods, and hands in the drops runs. Kept my body still, turned off all smart recordings, no coasting, no brakes. What I am curious about is the little spikes or vampire fangs in the one test. What causes that? Is it mean a bad test? Can I still use that run or should I scrap it? How can I prevent it? This was a mile loop.
Thank you very much for your help and responses.
Regards,
Robb
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Robb] [ In reply to ]
Quote | Reply
Hi Robb,

Glad to see you using Aerolab!

The problem seems to be crummy GPS data. You need to delete the Altitude column. Go to the "Edit" tab and right-click "Remove column" for Altitude. Now if you ran loops or out-and-backs, try using those symmetries to make your data make sense. Altitude gains of the same terrain should be identical if you get the Crr and CdA right.

And keep posting your results.

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
Hi Andy,
Thank you for your response. I am using the v3.3 cheetah software and there is no option for me to remove the altitude on the edit tab. I can however check the constant altitude (velodrome) on the Aerolab Page, under the Air Density graph. Would that work?
Quote Reply

Prev Next