Amazing videos!
Two questions (and many more that might follow):
(1) Do you mind if I use some of this content in my Aerodynamics lectures?
(2) If (1) is yes, who can I credit for the footage?

The evidence of early separation as soon as the head and shoulders are relaxed and raised just a bit is pretty amazing, as well as the attached flow when keeping low. Surface visualization techniques are so rudimentary but incredibly informative. Its possible to actually do some image processing on the tufts themselves and establish their time-average position as well as variations in position (a lot of effort on the processing side, but gives you even deeper insight into the separated and bi-stable flow regions).

---

Chris Morton, PhD
Associate Professor, Mechanical Engineering
co-Founder and inventor of AeroLab Tech
For updates see Instagram

Really cool videos, thanks for sharing!

Qualitative data like this adds so much more value to the force balance numbers, and frankly given an exclusive choice between one and the other I’d rather have the qualitative data.

I think those serious enough to do a matrix of helmet & skinsuit tests would be better served by an exercise like this using their current equipment and requesting transient data from the wind tunnel operators. They could then return after some studying to do follow-up tests based on that analysis.

Aerodynamic optimization is essentially one with infinite degrees of freedom, quite literally, in the mathematical sense. So, designing tests to get the most value requires that one not test, say, helmets H1 H2 H3 and skinsuits S1 S2 S3 in the same positions P1,P2,…,Pn, (these are the infinite degrees of freedom), but use theory as a guide to test the best possible combinations (Hx,Sy,Pz) first, and their nearest theoretical deviations, while perhaps never testing the same position across multiple suits and helmet combinations. Competitions start in the tunnel, and extracting the highest value data better than some who is naively iterating through permutations (often under the guise of rigor) can really make a difference for the realizable performance gains one can net before race day.

This is not to say a parametric sweep is never the right answer for how to test, but that the initial exploration space is enormous and the tidy variational tests should be nearer the end of the road and not at the beginning. A lot of babies get thrown out with the bath water.

Interesting, insightful. Can you elaborate on this?

E

---

Eric Reid AeroFit | Instagram Portfolio
Aerodynamic Retul Bike Fitting

“You are experiencing the criminal coverup of a foreign backed fascist hostile takeover of a mafia shakedown of an authoritarian religious slow motion coup. Persuade people to vote for Democracy.”

The best use of models and tests isn't to fit data but to hone intuition. I tell students that we often look for ways to model and fit data onto some multidimensional surface but the goal isn't always to find the extrema, because that depends on the exact nexus of parameters. Often we're trying to figure out the shape of the surface, how the parameters interact, and what it's sensitive to. And sometimes we're interested in both.

We can't always "see" the air. Tufts, and smoke, and threads (and water tanks) aren't for quantitative measurement of drag, they're so we can see the air and figure out "where" rather than "how much."

I feel like using “rigor” to structure your limited 1hr or 2hr wind tunnel session is necessary, and doesn’t really lend itself to finding the shape of the elephant in the darkened room.

There are only so many choices available once you screen out unsuitable or unreasonable ones. From there, helmet, clothing, and helmet and clothing combo.

What’s best for you in other words.

---

Eric Reid AeroFit | Instagram Portfolio
Aerodynamic Retul Bike Fitting

“You are experiencing the criminal coverup of a foreign backed fascist hostile takeover of a mafia shakedown of an authoritarian religious slow motion coup. Persuade people to vote for Democracy.”

Oh, I understand. Sometimes we're interested in the answer, and sometimes we're interested in figuring out how that answer came to be. (And sometimes, both).

When I teach how to find the answer, I say that one way is to do a "grid search." That's related to controlled testing or DOE where we look at many tests where we vary only one parameter at a time over a range, then repeat over another variable, lather, rinse, repeat. This works, but it's inefficient (and, in some cases like my field, we don't get to run repeated randomized controlled experiments on people). That's where statistical modeling comes in: we make a guess at a kind of model (for example, the shape of that multidimensional surface), then make a prediction about what we'd see if we did that experiment with a different parameter, then see if that happened. Models like this can be a shortcut to figuring out what matters, and how much -- but we have to keep checking the model and measurements to see if we were wrong. (This is why much of my day job isn't so much about the estimation or the experiment, it's about the diagnostics).

So being able to visualize the air helps us in our mental model--but we still have to test it against actual measurements.

But, yeah, if I were paying $1000/hr and had to know which helmet worked best, I might not care all that much about the shape of the animal in the dark room.

Thx! Of course you can use the video in your classes - the footage is probably 10+ years old and we did not do a whole lot of tuff stuff. Most folks we worked with just wanted the "answer" - but every once in awhile we got to play a bit. They have this tuft grid that we placed downstream which was a cool visualization as well - low tech PIV!

All credit goes to the crew here:

San Diego Air & Space Technology Center/ Low Speed Wind Tunnel
3050 pacific hwy| san diego| CA 92101|USA
Sandiegowindtunnel.com

Still go down there occasionally - but golf instead of bike stuff these days!

Cheers,
-k

That comment has to do with what Robert describes as "grid searches" for multi-dimensional "surfaces."

In this context, it's probably a good initial assumption that there are non-unique "positions" for each helmet and skinsuit pair which produce low drag values relative to the nearest positions, i.e. local minimizations of drag that aren't necessarily "The" (global) minimum drag combination possible.

Strictly parameterized searches for the minimum drag point are destined to find solutions to an over-constrained problem. That is, the answer you get will be "What is the helmet and skinsuit combination that minimizes drag at position P1," even though our understanding from a qualitative analysis suggests there is nothing to warrant a hypothesis that a given helmet h_i, and skinsuit s_j, would operate best at P1_{h_i,s_j}. One may even have strong evidence that such a combination would be best at P*_{h_i,s_j}. So, why test P1 before ever testing P* for all helmet-skinsuit candidates? If done skillfully, the available test and analysis time can be spent exploring other improvements.

We really seek an answer to: "Which helmet, skinsuit, and position combination gives the rider their lowest drag values?", and we provide the quickest answer to that question when we design tests to see if we can capture the minimum values on the "surface," meaning for each helmet-skinsuit candidate, I would test a most-likely "ideal position", and some positions which test the hypothesis, with the nicest result being that we have two "neighboring" positions that test worse for drag. If we find all such points for each helmet-skinsuit-position triplets, then we can compare them to see which is smallest, and ultimately not care that we don't have "direct" comparisons, because that is not fundamental to our goal.

When I say "A lot of babies get thrown out with the bathwater," I mean that I've seen far too many cases where one test goes well and a perceived "good performing" candidate is progressed deeper into design cycles, while another test article "tests poorly" and gets forgotten or discarded, for no other reason than it was not tested under ideal conditions for its best results, which may have been better at achieving or enabling better(global) improvements.

So, given surely limited time and super-expensive wind-tunnel, cfd, analysis effort, engineer wages, we bring the best value-per-test dollar when we hone in and test less options away from where we don't expect the optimal solutions to be. As I mentioned earlier, there will be a point where one is refining around a known-good solution, but such refinement comes after a fairly long road of more dramatic changes that net larger improvements.

Ain't y'all glad this is the "for dummies" thread?

The long explanation might not be friendly, but the “too long; didn’t read” version is a very user-friendly suggestion to record tufts and choose a position that makes them all look nice :)

And this is what I think the crux of the discussion is... when the average Joe is in the tunnel we are starting from the known-good position, after others have done the refinement, and are limited by time and $$. With an aero sensor, we can do more exploration, assuming we have a very adjustable bike, a cockpit with a mono-riser for example, in order to find the best three-parameter solution for any helmet/suit/position triplet.

Still, I think for dummies doing basic A/B or A/B/C testing from known goods is the best use of time.

Eric

---

Eric Reid AeroFit | Instagram Portfolio
Aerodynamic Retul Bike Fitting

“You are experiencing the criminal coverup of a foreign backed fascist hostile takeover of a mafia shakedown of an authoritarian religious slow motion coup. Persuade people to vote for Democracy.”

Let's not forget the guys from SwissSide, aerodynamic F1 engineers, with access to tons of wind tunnel time chose to develop an aero-sensor for the bike.

I am sure it's one tool in the toolbox that also contains Tunnel time, CFD and Velodrome time

Average Joe only gets to have one tool.

Eric shared his files with me. Lots of interesting stuff in there

I am using a generic version of GC that I took the open source code base and compiled it to tinker with. Eric's data is structured in a way that it is readable by the generic version of GC. CDA, wind….all there. You just don’t have their formulas but you have the result of the formulas.

I saw what Eric was seeing : a big difference in the calculated CDA between the 3 jerseys. But even for a specific jersey there was a very significant swing in CDA but one clearly faster than the other 2. Eric did 4x each jersey, 12 tests.

At first the data seemed wrong. Power was really low, like 75watts. I was sure this was a bug since I always imagined Eric as a 400watt guy. He confirmed he was riding super easy, in a super relax position. When I re looked at the data I was impressed how consistent things were for the 12 tests.

The first problem was pretty easy to spot. Eric is riding on a flat 400m track, but the altitude calculated was undulating slightly. It’s pretty easy to track back to the source of the error ie the barometer. This is pretty normal. Barometers are much more subject to atmospheric disturbances. We’ll come back to this

You see that for a test there is a net gain OR a net loss in altitude. This gain or loss is inconsistent from test to test. One test would end with a net 1m gain, the other a 1m loss. This should be 0 since he's on a flat velodrome. You will see it in the pictures attached).1m on a test like that is about 3.5-4watt. So -1 to +1 is a 8 watt difference. When the “air component” is in the 50 watts range, 8 watts is a BIG source of error.

Had he been putting out more power the error would have been diluted. Then again had atmospheric conditions been more difficult he would have got more error. The wind was pretty calm compared to other real world situations.

This is an example where a straight barometer will not do as well as some more elegant solutions. It’s also an example where if you want real time/instantaneous CDA on terrain other than a velodrome you need more than a barometer or you better have a way to correct the barometer. This is not a phenomenon specific to any one device. The need for accurate altitude is so under evaluated.

Yes, protocols such as out and backs with 0 net elevation change help if the software accounts for this. But in such a protocol you would still need accurate levation to get accurate CDA at intermediary points. Protocols can compensate for poor data but the better the data, the less need for protocols and the more you can pinpoint changes.

At one point there was a feature in their GC to zero the altitude. If it’s still there, that is one way to eliminate the error if you are on a velodrome. Too bad we don't all have velodromes :-) Even then, when 50-60ish watts are allocated to the aero component, you will get big error bars. The bigger the aero component, the better. But the devices need to provide accuracy at lower speeds as well, especially when climbing, or when you are using varying speeds to try a separate CDA/CRR.

At the end, the trends of each jersey (from fastest to slowest) remains the same but with a lot less noise and a lot more certitude in the results

What is really interesting is when putting the data in Aerolab’s virtual elevation ie the Chung method, you get really good results. You can also see blips in data. They were mostly due to uneven wind which one can see with the data.

Attached are two tests, green is the device elevation, white is virtual elevation/Chung method. You see a +1m error in one case and a -1m error in the other. The green line should follow the white line.

We have to get Eric to repeat at his regular 400w level (with tufts and a drone)

at least this dummy checked out early :D

---

My Blog - http://leegoocrap.blogspot.com

Thanks. Yes, very interesting.

I think of good data and good protocols not as substitutes but rather good protocols are a belt-and-suspenders for mostly good but transiently noisy data. They allow you to see the blips in his barometer.

Make a backup copy of the data first. Then you can go into the "Edit" screen and delete the altitude column.

Cool, ain't it?

This is an example that shows that a small error in the barometric altimeter, especially when you're testing at relatively low speeds, can have a fair-size effect on precision.

That will unfortunately not help the Notio's calculation of CDA. If you want the 0 elevation change reflected in the number they spit out, you have to use the zero function. Based on what's on their support site, it's still there.

There's a toggle button to select "velodrome" in the "Aerolab Chung Analysis" chart, which flattens out the altitude, but you still have to eyeball the VE with the CdA slider to get accurate results. Zeroing out altitude does not affect the CdA in other words...

E

---

Eric Reid AeroFit | Instagram Portfolio
Aerodynamic Retul Bike Fitting

“You are experiencing the criminal coverup of a foreign backed fascist hostile takeover of a mafia shakedown of an authoritarian religious slow motion coup. Persuade people to vote for Democracy.”

Yes. Correct. The toggle in the Chung analysis tab will put the actual elevation line flat so you can visually overlay the VE line

However what I am referring to sets the elevation to 0 in the computed data, so 0 elevation will be used in all the CDA calculations. Getting a CDA by playing with the slider is great but you also want the product to compute CDAs internally and report on them

For example this is my output on the Summary page of GC

I've a related question: I'm testing (or, trying to) on a lapped course which is 7.3km long with a small elevation difference of ~6m between the high and low point of each lap. However, even with the Notio calculated altitude (which I assume is using slope information as well and so should be better than just barometric sensor data, and possibly could be corrected based off map data as well?) I'm seeing a difference of ~1.5m in the elevation of the high point over the course of 6 laps.

It strikes me that given I have a course I'll ride repeatedly and that it's the elevation profile within the lap rather than the absolute altitude that matters that I should be able to calculate a consensus elevation profile by averaging the accumulated data. I'm not sure where the errors in the measurement of elevation arise - are there any reasons why this isn't a sensible approach? Or does anyone have any better suggestions?

What you are mostly likely seeing are errors caused by the barometer.

There are a few reasons for this. If you want to convince yourself of how much a role the barometer is playing, plot the elevation used by your device and the elevation you can derive purely from the barometer, chances are they are close. Or look if the altitude plot from your device resembles that from your Garmin. Probably very close.

The fact you are doing loops, the fact you have an accelerometer there are things that can be done for better elevation correction. I use 4 alternate data sources to correct the barometer. I hope to share some plots soon.

In my opinion is one of the key reasons one device will give better results than the other.

How do your VE loops look ? If you are having elevation problems, this is probably your best bet.

How aero sensors run with differents yaw angles?

It will be possible to test it in wind tunnel?

I haven't been following the details of this current crop of on-bike aero probes but I think the Aerolab probe may be the only one that currently measures yaw.

Robert is right, the current Velocomp and Notio products do not do yaw.
The Aerolab product says it does
I don't know about the Gibli or Velosense. I suspect they will.

Technology today makes the measurement of yaw almost trivial.
Robert has a pre-2016 device that did yaw. But it cost a friggin fortune to manufacture. Now with high precision 3D printing I print probes that do yaw for peanuts. (I am not using a commercial product).

Then comes the usefulness of the data. To get a map of percentage of time at various yaw angles is pretty easy. Today I did 4x5km out, 5km back. Pretty windy, (10km/h). Yaw angles were mostly between -10 and -5, 5 and 10. But this was an out and back in a somewhat straight route. When I ride West to South back North to East I get a lot more interesting data.

Sometimes I get a really weird data and yes, yaw allows me to make more sense of it.

But to get CDA at given yaw angles you need "real time/instantaneous" CDA. We can debate how many people are doing that today :-)

The yaw data can be used to correct other data.


For your question on testing in wind tunnel I have done the following
1) measure the drag the device itself introduces. Spoiler : not much
2) measure a few references configurations, like helmets, jerseys, positions so you can then compare them to velodrome and road tests
3) confirm calibration results/scenarios, ie measure the impact of device position on measurement values
4) confirm airspeed measurements/yaw angles are accurate.
5) measure things like the impact of a "Compton test" stick for use later outdoors.

You cannot measure the accuracy of the device in the tunnel but you can use tunnel data to assist in confirming the device results outdoor

I think that in the short run we're playing a game of whack-a-mole with these sensors. As new sensors (yaw, gradient, density, etc.) get added, the accuracy and precision bottleneck gets moved to a different point. Each new sensor absolutely adds new information and (as long as the new data collected are reliable) that improves things but, in the short run, the main benefit is to help us tell when a test run wasn't as reliable as we'd hoped. That's a post hoc thing, not a real-time thing, and that's why I keep saying that real-time is a much (much much) harder problem to crack than post hoc.

This also goes back to something I've been trying to explain (obviously, ineffectively) since 2007 or 2008: errors in estimation are of two types: random, and systematic. A lot of the earlier estimation methods treated errors as if they were random. If so, you can just do more trials and average them to improve the estimates. But I think the larger source of error tends to be systematic, and you can't make systematic errors disappear with larger numbers of trials. You need to identify the source of the systematic error and then look for ways to use that information to improve the estimates. That's why I keep saying VE isn't the estimation method, it's the diagnostic for systematic errors in the estimate.

I used the world real-time and it's not the right word to describe what I meant. I'll explain and maybe you can suggest a better term. Precise words are more important than precise CDA :-)

I did not mean a "live" number, for example when riding around and seeing an accurate number on your Garmin. Agreed on how hard that is.

I did mean the ability (post-ride) to get a CDA (and/or other useful data) associated to a short very period of time. That doesn't have to be 1sec.

For example, if the best a device can do is give you a CDA for a lap, what value would yaw have ? I have seen devices present such a number and I found it useless.

If a device can give you CDA for a x second window, and a yaw during that time, then that yaw has more value. The smaller the window, the better.