Wasn’t there a person in this topic doing downhill zero power rolldowns?

I could have sworn they said they got a buddy to drive them back to the top of the hill or something.

Power is gone at that point. But without a car a nightmare scenario of lap repeats climbing back up.

Sorry, just fun theorizing given the meter problem there.

Dammit you stole my idea.
Though I would still use a strain gauge as torque/power feedback rather than try to determine the electrical power - too many external/uncontrolled factors in that path.

You bring up an interesting conversation.

IF you have uber accurate inclination and IF you have uber accurate airSpeed, you could do high speed aero testing.
Without those, how can you tell if you had a head wind/tail wind ? How could you differentiate your CDA at 30, 50 and 70km/h ?

This is the crux of the sensor discussion, the more accurate the sensors, the less limited you are by protocol, the more varied scenarios you can test in. Not all sensors are equal.

Don't tell anyone but the downhill testing is my true end goal. Rather than a velodrome I am going to buy a mountain, have a perfectly road surface down and a chair lift to bring the rider back up. I just need a few more decimals of precision on air and incline.

If you care about absolute CdA, the inclination being the same % grade the whole way would matter. As the accel/decel from road changes the GPS elevation cannot pickup would cause error in the calculation. But, if just interested in differences of setups........you're covering the exact same piece of road each lap.

In my feeble brain, for "this is better than that" testing, the only variables lap to lap on same setup are:
-body position
-vehicle passing
-irregular wind effects
-irregular cyclist speed control (accel or decel affects the maths)

They didn't re-grade the road between your laps. They didn't repave it a different CRR material.

You KNOW when a car passes, so add a lap to that set and remove the one lap from the dataset. That variable is gone. Irregular cyclist speed control is an issue if you have "small" bumps in the road causing you to slow or speed up and alter your power plan. This is where road grade being consistent helps a lot for a longer out/back kind of laps. That helps reduce that variable.

I try to get rid of that variable by even if a loop has elevation, I mark it as "velodrome" in GC. It's the same strip of road each lap. Sure, you get a little pimple change in CdA each lap from your accel/decel.......but it's the same pimple.

I have tried this on a 1/3 mile neighborhood roundabout that had a pretty solid little tilt to it. Laps were very consistent on CdA once I told it "ignore elevation".

Issue has been for me with cross winds testing with the disc wheel on the back for out/back laps. The sensor doesn't feel all the cross wind it seems and the out lap is higher CdA, then on the "back" lap the sensor downwind isn't seeing it and the CdA goes really low. With that, I need to just build myself a little wind sock to take with me for the day so I can eliminate that variable by picking the road that's perfectly against/with the wind.

I found a lap I want to try but parking is risky. Don't want to get shot. I may need to park 5mi away and ride with a musset bag of my fit parts or tools.

This is about a 15min drive from my work: .36mi per perfect circle lap, would need to choose days wisely as wind down east can be shit
35°34'34.0"N 78°16'02.7"W

35.576112, -78.267413

probably because I don't know what I'm talking about but what would happen if you set up an out and back where one leg was a coasting downhill then return to top and repeat? The up hill would be fairly slow and of course power would be recorded but at the top it is turn around free fall to the bottom, coast to a certain distance, pedal to a turning point and start over??? would this be a workable option for a Chung CdA test?

That could work. Repeat it over and over and you will probably get a very good VE plot. In a perfect world find a very large "U" and roll down, roll back up , turn around and repeat over and over without ever applying power.

Doing this would be taking power out of the equation, although, of all the sensors is probably the one we can count on the most.

If you coast down and climb up (applying power), then you need an accurate power meter to get accurate number.

A couple of things

If you do this downhill only test, you could get pretty good "this is better than that" if you control the things you mention (wind, cars...). One problem with those tests, is if you get speeds that are "high enough" your CDA will vary in a measurable way. Your CDA measured at 30km/h and 70 will be different. So yes, you can calculate a form of "average" CDA, if you have an accurate delta-altitude and accurate start/finish speeds. But wouldn't you like to know what your CDA at various race speed is ?

If you had a device with all perfect sensors, you'd be able to see a plot of this varying CDA with speed.
If you have "ok" sensors at least you can determine where weirdness such as varying wind occur.
If you have "suboptimal" sensors, you need to compensate with more protocol.

I personally am not a big fan of aero testing with a disc wheel. It doesn't take ridiculous conditions to make test A and B quite different because you get a "sail effect" on one run.

BTW, we can log, with a Varia type sensor, when there is a car. But I hate throwing out a lap because of one stupid car. This is where more "instantaneous CDA" becomes really nice. If you have 5km stretch where you are constant at .25 and there are "blips" where you go to .26 and you can explain those blips, then you know you were a .25. If you have "Varia type" data, that is one way. Another is to simply not pedal for 10 seconds and when you are doing your analysis, if a CDA blip corresponds to a cadence=0, then you know something happened there. BTW, very often you see it in the airspeed data.

Imagine you had done a 20min FTP test, and you held 320w for the whole thing, perfectly even but at minute 12, there was a drop on the Garmin and you lost 30seconds of data. So you lap average is now 312w. Wouldn't you like to see that perfect 320 before the drop, after the drop and say "I did 320" rather than throw the entire test out the window. That is exactly was the rolling CDA could/should give you, but it requires really good sensors to be accurate.

And if you have good rolling average CDA and you have a plot of wind yaw, you can see things there.

Again, there are all kinds of ways to overcome deficiencies in sensors with protocol but if/when we nail the sensors way, way more data becomes available to us, including things for example the ability to separate CDA/CRR

This is why I think the manufacturers need to continue pushing the boundary of sensor accuracy. It's not an all or nothing thing. What's out there is better than nothing, but there is a whole lot of improvement that can still be done. And yes, they are not all at the same place today.

I have not tried this sort of thing but I have a route near home that maybe if I can slot some time this summer I might try it. As a general rule it is nice and quite, most of the downhill and the route for that matter is in the trees so very little wind effect... and it might be possible to just assess the portion that is downhill and in the trees??? sounds sort of interesting to try.

Hi Marcag,

I would love to try this if you're willing to let me have it.

I have the CdaCrr app and the anemometer. I would love to be able to connect the anemometer to my Garmin and analyse in GC. I'm also thinking of getting the BlueFly vario...maybe if your app works that could be connected too.

I'll try and send you a PM.

Cheers,
Stu

Hey !

I'm sorry I didn't reply earlier. One thing led to another, always planned to come back to it and here we are weeks later.

Some explanation : The reason I put together a Garmin Connect IQ app to read the WeatherFlow and BlueFly was to be able to get "weather" data from these devices to compare to other systems. These datafields do nothing but collect wind, barometric, temperature and humidity data from the WF and Bluefly Varia and stuff them in the Garmin fit file that can be configured to grab power and speed. No need for a phone.

I sent it to a ST user for testing. He does the gymnastics to bring it into GoldenCheetah, analysis compute CDAs, etc. He sends me his raw data. I have a bunch of tools, and we compare aero results such as cda/crr separation. He can probably share his experience but he's got the whole Excel thing nailed to do whatever gymnastics need to be done.

If you want to try it, we can setup some testing. There are no plans to productize it, but eventually it will end up in OpenSource, probably with some import tools for Golden Cheetah. I just need to find the time as I have said we are developing other aero tools that go beyond CDA measurement.

In general I'd say the weather flow device adds value when Chung/VE/Aerolab testing. It's not as accurate as at least two of the major systems out there, but it does help a lot.

The Bluefly varia was far less impressive. It suffers from many of the struggles barometers have when aero testing in general and high precision pressure sensor doesn't solve these challenges. Ryan (the other ST member) has just started testing it, so we'll gather some more data.

He posted some of his findings in the Cda/Crr app thread.

Some of my thoughts/insights from the work Marc is referring to above.

1. We are extremely lucky to have people like Marc and many others on the forum. They have incredible knowledge they are prepared to share.

2. We are living through an incredible time where we are able to connect and record data from multiple sensors basically as hobbyists and that would have been completely a pipe dream say just 10 years ago.

3. I don't consider my testing protocol as "tight" as others. However, the WeatherMeter and the Garmin Edge 530 have made the biggest improvements in results and consistency for me. On some tests I have got what I consider excellent given my protocol (or lack ot). In the past it would be perhaps 1 out of 10 testing days I would get good data, now it feels like most days I get something reasonable. The biggest issue has been getting a stable calibration factor on the Weathermeter.
Credit to Pierre on the cdacrr app for pioneering the weathermeter idea (pretty impressive DIY thinking). As per Marc's points above - to date i think the BlueFly vario has not impressed me, while that should not take away from Pierre's innovative thinkin to include the vario into the DIY system in the first place. I just think a Garmin Edge 530 altitude data is better and its less of a pain..

4. I think an aero sensor that works at a reasonable price is well worth it. The combined cost of the DIY aero solution has probably been close to an aero sensor cost in total. I think Marc and team have thought deeply about the product and I hope I get to support him when their sensor comes out. I think in good conditions the DIY system is similar but i'd expect that in harder conditions the aero sensor would be better, and i think its overall a slicker experience that is probably worth paying for.

5. I'm finding weather station air density data for my area is not accurate. The weathermeter data has consistently suggested slightly higher than weather stations imply for air density.. When temperature is changing there is a potentially material impact in using a dynamic density rather than fixed density calculation.

6. Perhaps just the roads in.my area but the more I test the more my sense is that CRRs are higher than what might typically be expected. My sense is my roads CRR is in the 0.0055 to 0.0065 range. The Flo team's data also seemed to get data in this type of ballpark.

7. There are many minor improvements that GC aerolab could make. . For example.
(a) Allow an elevation to be "reset" to match starting elevation per lap i.e. allow multiple laps to be analysed at once, but with the starting virtual elevation reset to match the actual elevation. For example this can be handly when the actual elevation has barometric drift across laps.
(b) Allow laps to be overlaid, similar to how the compare laps works in other parts of GC.
(c) Improved numeric solver for CdACRR (i almost never get decent results from this)
(d) allowing reference lines to be set as in some other GC graphs to "line up" peaks and troughs
(e) Allow an offset between virtual elevation and actual elevation- sometimes you can see virtual elevation looks a good but is slightly ahead or behind actual elevation in time delay..
(f) Allow a wind intensity scaling factor that scales up or down (headwind data)
(g) calculate implied wind (not just headwind), and allow this to be plotted as a scatter plot
(h) Create a virtual wind simulation in aerolab , by allowing a user to stipulate wind direction (e.g. 25 degrees) and wind strength (e.g. 8km/h). This would then estimate headwind based on actual speed data plus inputted values. Not ideal, obviously better to have real wind, but better than nothing where the user does not have accurate wind data and would allow better results when wind was fairly stable..

Ryan

Here is a neat example of how getting the wind data is making the world of difference.

GC Aerolab same parameters. "Before" is ignoring the Headwind data. The the other file is how the curves fit with the wind data included.

Your comments in the last two posts are interesting. It provides some data the “cost” and “value/benfit” of the various solutions out there. I’d be curious to hear your, and other POV on value of these systems,

Virtual elevation in Golden Cheetah brings amazing value for a cost of $0. And it can compete with multi thousand $ coach level tools and mid price solutions in the $300, $600 and $900 range. They offer “different” value but at a higher cost.

Your last test shows that the Virtual Elevation Model works really well. It even works in windy conditions IF you have wind data. Having looked at several of your files, it seems South Africa and Canada have two things in common. We always have wind and we have no flats :-). Getting VE to work here without wind data would almost be impossible, (for me anyways).

But it also shows that a $90 "weather station" can provide “good” data. Personally I am not a big WF fan for two reason. I don’t think it’s very visually appealing, you can’t use it in race conditions and I suspect it introduces more drag than a more aero device. It also it seems to be more prone to error in yaw condition. But on a scale of 1 to 10, I’d give it a 6.5, some of the non yaw solutions a 7.5, some of the yaw solutions a 8.5. But it seems a 6.5 is maybe “good enough”. I think each can determine if this is worth $90 ?

I think there is “value” in a system that makes testing easier in general. There are still a lot of people that are not willing or able to manipulate the data, transform from Garmin to Excel, merge with data source b, import into GC and pray everything lines up. Apps that streamline this have value. Is a $600 solution that provides marginally better wind data, but a better user experience solution worth it ? If I look at what I think burnthesheep does, I’d say this is where your two solutions differ the most.

You mentioned a list of improvements that could be done in GC. I know of contributions to the open source community that are going to make this much easier. Will the commercial systems be worth hundreds of dollars more if Open Source closes the gap ? I do believe OpenSource is a big part of making the aero testing experience even better. On one hand this is great for consumers, on the other how do the vendors navigate this ? There is even potential for openSource devices.

Use of VE eliminates the need for accurate elevation when using a tight protocol However, accurate elevation opens the door to many things, adds more value and greatly increases accuracy. Until we have accurate elevation we won’t be able to get “instantaneous” or “real time” cda. Once we have more real time cad we can better pick apart what is impacting CDA, such as yaw, position changes, etc. We can do much better CDA/CRR separation. The ability to do aero testing on random point to point (as opposed 0 net elevation loops) is only possible with accurate elevation. If someone does an evaluation of the various aero sensors, I think elevation accuracy is THE biggest differentiator amongst solutions, not wind. Your $90 wind solution shows this. But this is just a personal opinion.

The bluefly Varia does not solve the elevation problem. While it’s a high precision barometer, factors other than barometric pressure introduce error. A high precision Barometer is an important part of the solution but not the whole solution.

So for me, you score a product on 4 fronts. 1)Quality of the air sensor, 2)quality of elevation data, 3) useabilility and 4)a small bucket of “other”. Someone doing an evaluation of the technology today could give a score for each of these criteria and I can tell you there is no clear cost/value winner.

Then there is a whole new set of tools that will be available once the underlying CDA measurement is nailed. That's when things get exciting :-)

I realize folks are in different budget buckets and no assumptions can be made, but tons of people blow LOTS of money on bike frames or wheels that would make a lot less up front difference than a sensor that saves them lots of time optimizing their aero.

They could forego the 3w saved on the extra $1000 on a nicer frameset or the 2w saved on the $500 to $1000 more expensive wheels and get the sensor.

But yeah, the GC aero tool for "free" is amazing for the folks truly in the tough financial spot but wanting to improve.

A few comments:
- Where i live in South Africa is not flat but is not actually considered that windy (many other more windy cities) - just proves the point though that finding truly windless days to test is very difficult and solving to handle wind is a pretty core ingredient.

- I agree with all of your comments on the "wind meter" solution - it's not discrete, it adds material drag, you can't use in a race and it does seem prone to "off" days (whether due to yaw or something else). I'd add some further issues to consider
- Depending on where you have it located on your bike it may not be easy to leave it on the bike semi-permanently which i think raises the risk of calibration issues ride to ride
- There are "hidden" costs beyond the device - e.g. the mounts for the weathermeter (plus your phone if you are using that to record data).
- Data recording options are currently tricky - you can use CdACrr app (i did not find it ideal for my needs) or you need access to a garmin app (no open source solution at this point) and minimum device requirements to support such an app (e.g. in my case i ended up upgrading edge 520 to edge 530).

While i don't regret spending the $90 on the weather meter, ultimately i think it will be throwaway spend because i think I will graduate into a proper aero sensor device - at the moment all seem to have some downsides and/or are too expensive to justify in my personal situation. I imagine this will change in the near future though as options come online.

Also agree on the user experience - many people are not going to be prepared to do the data massaging i am currently doing. I think some of this could be automated to a degree to speed it up, but still many others probably just want a "1 click" solution. The flip side is having another "platform" also has downsides. For example if i were to buy a Stryd running power meter - i want that data in the platforms I am currently using. I don't want to have to go into the Stryd platform to see the data. At the moment, i am managing data across Strava, TrainerRoad, Golden Cheetah - sometimes analysis data in Mywindsock.com and Motionysis.com too, so i am lukewarm about "another" platform. As a minimum I do think having the raw data, available to analyse in GC etc is a "must" even if their is a slick analysis tool outside of GC etc to give users options on how they want to do the analysis. Long term, i think you can look to power meters where it's really split into software/apps/platforms vs devices - e.g. i could see a future world for example where you can see aero stats in Strava, or that BestBikeSplit supports aero sensor data from a range of device manufacturers (rather than just relying on weather data from stations). I.e. the current model where vendors i think are trying (out of necessity) to cover both the device and software side is probably just a medium term issue (some exceptions may apply for companies that play in hardware and software side - e.g. garmin).

I think the key issue for device manufacturers to consider and manage is the optimisation of volume/margin in pricing. How do sales volumes change when the device costs $200, $400, $800 - i suspect volumes more than double when prices half across this spectrum, and i would imagine a big chunk of costs is in recovering R&D so i suspect that the "sweet spot" is on the lower end of that spectrum. There is no way i am spending $90 on an inferior DIY solution if a proper purpose built solution costs $200-$300 so the "opensource" issue kind of becomes irrelevant at that price point. A big part of power meter adoption has come from falling prices not just the "people getting familiar with power meters" line of reasoning that is often thrown up. It would be interesting to know whether power meter industry were making more absolute money 10 years ago when adoption was low but prices were high vs now when prices are lower but significantly more volumes.


Many others don't seem to care too much about getting CdA/CRR separated (focusing more on relative A vs B testing), but i agree with you that it's key and would add some examples why
- e.g. if your CdA is 0.23 vs 0.21 there is a big difference on whether you likely think there is still room for material room to improve and what i should focus on. E.g. at 0.21 i would be careful to give up power chasing aero, whereas at 0.23 i would think that there may still be aero gains "on the table".
- It's critical for comparisons across testing venues, different test dates etc - at the moment when i test in a different location and i get "strange" data i have no idea whether it was a testing issue (protocol) or CRR is higher than what i was expecting etc.
- accurate time predictions etc.
Your comments make sense that you can't get there without very accurate elevation data.

Another potential player in the market.

https://endurance-innovation-podcast.simplecast.com/...odes/gibli-aerometer

I'd argue this is still true at 0.230 in terms of "losing power". There's folks simply not used to riding in aero that much that lose a lot of power getting down there no matter what. So, even at 0.230 some folks may stand to lose a pile of power production going down in stack or in on the pad width to get to 0.225 or something.

Then there's folks in the 0.210 range that are very well adapted to the position and they likely already know that "break point" on hip angle with stack or pad width that annoys the power production. And can work on other stuff.

0.210 is good, but the big British TT scene would argue it's not "that stellar" either.

For someone on lower watts at a good CdA, if you can keep the watts and gain more CdA........might be your only choice if you can't train for more power.

Having analyzed many files from the "British TT scene", I'd say their representations are about as reliable as W/kg from Zwift.

Yes we agree - my comments were meant in a probabilistic not absolute sense. I.e. It's probable that someone someone with a Cda of 0.23 has a bigger chance of finding 0.01 in aero gain than somebody with a Cda of 0.20 finding another 0.01. That's not to say it's true for every individual as you rightly point out.

So, dumb question. My Garmin is set to mph. My Notio live field shows wind speed in mph. GC after shows the wind speed in kph in the charts but then in mph in the summary for a lap or selection.

The avg wind speed it shows in GC for a lap out then a lap back, seems woefully too slow.

Yesterday it was some cross wind but surely had to be way more than just 0.9mph help and hurt respectively. It did appear to show wind speed changes of magnitude during the ride, but no freaking way the avg each direction was that low. And clearly the lap avg out vs back for CdA demonstrated a problem somewhere either in not reading true wind speed OR an elevation under estimation.

Not testing, just recording training intervals on a bumpy road. But still want to know how I can post data dump read fix something like an out and back delta in CdA that should have been picked up in wind or elevation.

Given the look, it appears to be a wind underestimate IMO.

If it's pure crosswind Notio should theoretically measure zero wind (air speed = ground speed) as it's not measuring crosswind/yaw.

If yaw is high enough (probably north of 15 degrees or something like that) the pitot might not measure the wind speed correctly depending on stall/stagnation characteristics of the tip design. I'm not sure Notio has published anything about when exactly measurements start to be off (by let's say 1+%) in their tip design.

I am not 100% sure I understand.

Maybe things have changed but "back then", the calculation of the CDA is not done with "wind". It's done with one of the raw inputs called airP and it isn't in danger of being screwed up by mph kph configuration SNAFU. Other things can screw it up however.

An error in wind calculation ould screw up the "headwind" column used in the Chung analysis if you are using that.

The calibration process does calculate wind from Airp and if something goes wrong there, you will get bad wind values and possibly bad calibration numbers.

So if you are using a valid calibration number (say from a previous ride), your CDA should be consistent in the head wind and tail wind.

a) Are your CDA out and back close ?
b) If you use calibration, is the number wonky ?
c) Is out wind ~ (-1 * back wind) or are you seeing massive tailwind, small headwind with a known calibration value?

I'm stupid.

I just went to look at the bike, and in the car the mount for the Notio was suddenly cocked way up from a large bump along the way. So likely outbound with the tail wind it must have been in the right orientation. Then inbound with head wind, right near the u-turn there's a few wicked bumps. I bet it turned the tip upwards then and failed to read well on the way back. I'll check the wind in the app to see if the headwind back registered lower.

Dohhhhhh. Usually is a logical explanation somewhere!

If the device is jostled to face the tip up to the sky, yeah, I bet it won't work so well!

That will show a huge tailwind all the time.

Do you know if any of the manufacturers publish this or make claims on how they handle this ?