They discussed this on yesterday’s trainer road podcast. Tr guys interviewed dc rainmaker and roughly halfway through they discuss. Seems like there’s potential but no one has really been able to validate it

Currently, the limiter isn't the lack of a sensor so much as it is a wide-spread shortage in the knowledge of what to do with the information we can already get.

Robert, so is this another way of saying that you believe this type of sensor is not really necessary? That methods and technology already exists for the 'layperson' to accurately and repeatably determine CdA ?

- serious question...... !

Dbeitel

Correction... plenty of people have validated that a more sophisticated device is needed (even than the Notio) unless you are cool with big error bars... and if you are, then might as well save your money and use the CdACrr app with an anemometer. By big error bars I mean SD ~.003m^2 IME in windy conditions, so like .200 +-.003.

A couple people in the UK have been working on systems that should be more accurate but I have no idea what the status is on those.

Yes! Ideally user friendly and nearly idiot proof software that uses every scrap of data for analysis and error checking, with a good venue and protocol.
The CdACrr app is the best thing going at the moment, but it isn't there yet.

Hmmm. I think that if you live somewhere where the wind perpetually blows and you live far away from convenient access to a protected venue, then it has the potential to be really handy. However, I think the bigger problem at the moment is that we (and by that I mean me) haven't done a good job explaining how to collect and decipher the data that we can already collect.

I recently explained to one of my students that I sorta kinda invented a bathroom scale, but I haven't done a good job explaining how to use the bathroom scale to give you the information you need to lose weight. Actually, that's kind of generous. I invented a bathroom scale that you have to use carefully in order to get a precise and accurate measurement of your mass. You can get a rough idea of your weight pretty easily but you have to be careful to get a precise and accurate measurement. Even if they make it easier to get good measurements, neither I nor Notio (nor Aeropod) still tell you exactly what you need to do to lose weight.

That's sorta my fault.

Not at all. Hundreds of people have a deep understanding of how to use the technology - it's not all on you. But there seems to be a widespread cultural inclination to tightly hold that information so that it seems to remain the tightly held knowledge of "aero gurus." Partly due to protecting business interests. But not solely because of that. Part of it is just that documentation is tedious. And aero testing can be tedious and unsexy.

It seems similar back in the early days of power meters, when power data was often closely guarded as a kind of trade secret. Now power data and the techniques for using it is are far more transparent. Hopefully aero testing techniques will follow suit.

I don't think it's your fault. The few times I've tried to explain it to people, even good smart people, somehow they either discount it, or don't pay attention or whatever, so then I figure they don't care about the details and give up. Then later on they ask: how is it you get such accurate testing? and I'm like "remember when I said..." But honestly most times they still don't get it.

I get quite accurate testing even in somewhat windy conditions without this sensor, but yeah I think it could make things even better. Still waiting for proof it works, though. Theses sensors have been in development for so many years now, by so many different groups, that I figure it must be harder to make work than everyone thinks. Still I can't help but wonder if we're seeing exactly the same problem play out to some extent. I bet you or I could take the output from this sensor and add it to the data we already have to get really accurate testing. I had the chance to test with one from a different developer (who I won't name) and they had done loads of hardware development but seemed to have absolutely no clue on testing protocols, and as a result even with the additional data their testing was pretty much totally useless.

I suppose that's more accurate than I put it.

I sort of meant it in the sense that I have a day job and I figured that others would explain things so I wouldn't have to. I wasn't trying to hide anything and I don't have any business interests to protect. I don't build anything, I don't sell anything, I don't make any money off this, I just do this cuz I wanted to know for myself, and I wanted to get faster. I'm an academic, and even my simple explanation turned out to be 116 pages. Even when my kids were in elementary school they wouldn't ask me for help with their math homework. My kids are pretty wise.

Yup. This is what I fear, too.

I think this is a very accurate statement. These sensors probably are to aero testing what power meters were to training Back in the day, you could use a heart rate monitor to do training in specific zones. But,.... you had to know how to use that information. Then power meters were invented. These made training in a specific zone much easier. Great! Except you need to know how to apply the information to get meaningful benefits.

I remember my first ride with a power meter. I could hit 300 watts without even trying, unless I had to do it for more than 3 or 4 minutes. That is when you realize the human body can only put out 3-400 watts for a few minutes.

So the "Training with a Power Meter" book helps, but that is still pretty much a DIY solution. Now there is SufferFest, Zwift and all the other programs that you download a training plan and tell you how hard to pedal for how long. Follow the plan, improve power.

Assuming these sensors work, you have a new level of complication. You can change CdA, but did you lose or gain FTP and is that a net benefit for a 20 minute versus 60 minute effort? So now you have fit/comfort vs a power vs FTP relationship vs CdA (don't even talk about yaw).

So as someone who as tried, and only been marginally successful at the "Chung method", I am super excited to try these new sensors. I see them as great additions to what your original work with aero testing provided. Nevertheless, I don't think one of these sensors will work for most people. A person might be able say that helmet A is better than helmet B, but you still need to be a great experamentalist to optimize all the variables that go fast on a bike.

Now the trick is to develop software to do a fractional factorial experiment to manage all the up-down, narrow/wide, FTP reduction vs CdA reduction..... parameters to minimize the power-to-speed relationship. If you can get there everyone will be doing 30 mph on 250 watts for an hour.

You mean like the bio racer speed sensor concept at this year’s Eurobike?

Speaking of bathroom scales, I really do need to try the chung method. But it is windy around here, and I am not close to a protected venue (very far actually). No wind tunnels for days and days either.

I would likely do the chung method with the sensor pod, and compare.

Until that day, I am just doing "Armchair aero" and going with proven approaches, and eyeballing it. All while making sure I am not reducing power. So far.. I have yet to go slower with my efforts.

I agree. Just as a PM cannot tell a rider how to win races. Or a bathroom scale with losing weight.

These things are tools. Anyone can pick one up and use it. But as with all tools It takes much practice before they can be used with great skill.

---

Mark E

Excellent post.

I share your comparison of today's devices to power meters. They open the door to advancements in aero testing, including white papers, books, seminars, more sophisticated software, ..... Maybe someone will write a Training with Aero Sensor book :-)

I also think it will help the community to measure and share info. "Helmet X got me Y grams" rather than the anecdotal info we get now.

Like the power meter, these things will improve and become more accurate in more conditions. At first power meters had challenges with calibration, suffered from drift due to temperature, water problems.....yep, my faithful Quarq went through all of these. But even with it's flaws, the Quarq always provided me with actionable data. I believe the aero sensors today (or at least some of them) are there. I hope the manufacturers do the job Quarq did in supporting their customers, working through the issues
and being open

The feedback I have heard from people that I respect greatly, is the device has reduced SD from run to run and it's reduced the time for analysis. This has been my experience as well.I do a weekly TT and I get a very consistent CDA in 2 or 3 minutes, with varying wind, braking and other "blips". There is 0 "cost" racing with it and it gives me real numbers in real race conditions. That said I know all the ins and outs of the device.

I have said this multiple times, the VE method in GC is amazing, if you have the right venue, conditions and ability to analyze. These devices reduce the restrictions on venues, reduce the restrictions due to conditions and make analysis a bit easier. But there is still room for improvement.

Just like the power meter was an enabler to aero testing, aero testing will be an enabler to other things. There is technology under development (by other parties than the current aero sensor players) that will help us get to the next level. But we need good measurement tools to get there.

Hey Lanier, curious what your detailed protocol is? If it's not too much trouble.

Hey Ron, Sorry busy weekend. There are lots of details that matter - a few pages worth so too many to put here. I think I once e-mailed you a first draft of a write-up. Here's a not very well thought out summary...

It's based around a pretty standard VE (I use the total work method for most of what I do) and out and back testing with the turn-arounds snipped out, so I think similar to what you do. I've simulated the bias on a computer using lots of different assumptions on the wind and the bias is theoretically small the way I do it, even for reasonable wind with gusts etc. Cars are a bigger problem but I find that a few here or there doesn't affect things much. Obviously ideal is to have no wind and no cars. Cross-day comparisons are tough with wind because each day you test the yaw angles are different, and measured CdAs will reflect the yaw angles experienced. Intra-day comparisons are fine with wind. Cross day comparisons are better with no wind.

Some key parts of the protocol
- out and back course around 7 mins (~3 miles), some hills are okay but avoid anything steep because bike control is harder at high and low speeds, flat is good too.
- preset marked start and end points that must be on level ground (because with 1sec recording the start and end points are not recorded super precisely)
- bike must have accurate power meter and speed sensor, both calibrated and sensors have to acclimate to temp before calibration
- measure air density and temp for each run (where I live it can change quickly)
- rider has to keep pedaling consistently (no coasting) and follow the same line each time on the road
- rider pushes lap button at start and end of each section out and back

Some more comments: (1) I snip out the turnarounds but you have to be careful here because exiting and entering speeds may be different so you can't treat the data as one lap. I run the calcs for each lap separately then put them together after. E.g. you can compute total work for each lap separately. (2) course can't have significant corners. Usually tests are pretty fast - 25-30mph and you just can't hold position in any significant corners at that speed. (3) I get better results from snipping out the turnarounds than I do when I have the rider turn around on a hill. (4) I find wind causes lots of error in practice on loop courses (doesn't average out properly) so I always use out and backs. If all you have is a loop, treat it like an out and back and run it once each direction. (5) I'm not big on half-pipes though obviously others (Tom A) have had good luck with them, though I think he's testing with no wind and no cars. (6) Rider experience matters (and rider should be warmed up) - first testing sessions often don't go that well and first run can be unreliable if rider isn't warmed up. (7) I measure (ambient) temp for each run so I can temperature correct CRR. I've found this to be an important source of error. (I think maybe I should test pavement temp but where I live I don't think there's much difference.) (8) If testing on a new road I also do a couple very slow speed runs so I can jointly estimate CdA/CRR. (9) Lots of power meters and speed sensors give crappy data of various kinds, so when using a new combination you have to be on the lookout for weird stuff. E.g. the speed data from Pioneer power meters has a weird oscillation in it (just one example but there are many) (10) when testing on a velodrome things change a bit: centrifugal force increases rolling resistance and measured speed at the tire is higher than the speed of the body through the air

That's most of it. Other stuff that's important is to be super consistent in how you test: always test a given rider with exactly the same equipment and setup. Think of it like a physics lab - details matter. I.e. same skinsuit, same helmet, same shoes/shoe covers, shave your legs the day before, same wheels, same tire pressure, etc. If you control all these details you will get rid of a lot of testing noise. Then change *one* and only one thing per test. Pro's are the worst because their bikes are never set up exactly the same from one day to the next and they can't really control it themselves - such a PITA.

Let me know if anything isn't clear.

Thanks for the detailed protocol write-up!

Question: 7 mins/3 miles total for the out-and-back or each direction?

Also: in your experience is it best if that is a straight road or can the heading change some (assuming no sharp turns)?

-- 7 mins /3 miles total (1.5mi each direction). Longer is better of course, but this is a happy medium between low error and getting stuff done. With no wind you can use less.

-- Good question. All the roads I've used are pretty straight. If there's no wind it makes no difference. With wind, heading changes lead to yaw changes. That would mean you are averaging across different yaws during the test, which I can't see being any worse than not (at least on average).

It's surprisingly hard to get someone else to test with the same equipment in the same condition. Sometimes it's hard even for me. People forget what they wore, or what their tire pressure was, etc. I once tried to put together some "test forms" so I could write down stuff like that, and add a selfie or two to remind myself what I wore.

Thanks for that, Lanier! I'm getting ready to do more testing and fiddling now that the races are over. Always would like to do it better...

How exactly do you snip off the turn? I've been doing an out-back (~1 mile each direction) with a steep hill at one end for turning. I hit a button for the start and let the app determine the end (fixed lap length) so I don't do any snipping. I like the idea though. And I definitely agree that out-back is best. I always have wind and I have to make some assumption on wind canceling for the whole data set. If I do out-backs and ride near the middle of the road then that's a reasonable assumption. It definitely isn't reasonable for a loop, though you might get lucky.

Are you using your own software for these calculations? Or a spreadsheet?

I did some measurements awhile back with pavement and air temp vs tire temp; the tire will be closer to the air temp than the road, but not by a lot... ~30-40% of the difference between the two. On a sunny day this ends up being a significant factor on Crr and resulting CdA determination. Earlier I tested on 3 different days and got an average of .205 on all of them with the same setup and windy conditions, so I was pretty excited at first. But then the numbers started moving up to ~.212. The only thing I could put my finger on was that I started testing in the morning instead of mid-late afternoon. Best guess is that Crr was not properly accounted for because I was just using the air temperature.

I also discovered something odd when I had a strong tailwind on the uphill leg of my course. The aero drag became a small factor on this leg, making the results sensitive to tire drag. Crr seemed to change quite a lot (increase) with speed. At least it was the only thing I found that would make the curves look right. ~.0030 at 20km/hr and .0045 at 40km/hr. That was consistent on 3 different days. Not sure yet if it's real or a symptom of some other issue.

I didn't realize how much temperature and pressure varied until I started measuring it on the bike. The CdACrr app makes it easy if you use the Weatherflow meter for airspeed, as it can get temperature from that, and pressure is recorded by both the meter and phone with good accuracy. Sun can inflate the temperature reading if you are parked but it comes down to near ambient pretty quickly once moving. I still think it would be best to take the low temperature from the run and apply that to all of it, but I don't think Pierre has implemented that yet.

Regarding wind, if your course has some slope between end points then ignoring wind will definitely affect your results. For instance going uphill into a headwind and downhill with a tailwind will give different numbers than the opposite (or no wind) situation. If your end points are at about the same elevation then this won't occur. Unfortunately I haven't able to find a usable out-back course that has less than 1% grade. Another consideration with wind is its consistency. On some out-back runs I can easily have >1 km/hr net headwind or tailwind and this has a big effect on the CdA calculation. Cars have the same effect. Measuring airspeed helps a lot. With variable wind or variable traffic, if you have a big enough sample then you can average it out, but it can play havoc with any individual run if you aren't measuring airspeed. At least that's been my experience. I always have a good amount of chaotic wind.

Wow lot's of great stuff there Ron. I definitely think I can improve my methods some more too and measuring wind would be great. I kind of hope one of these devices works out. I'm careful to measure temperature and pressure in the shade and you also have to be careful about radiating heat etc from pavement or other sources (car/ground/etc). I don't measure it on the bike.

I wrote my own (rudimentary) software that loads in a fit file and processes the data. The way I snip out the turn is I process each lap separately then combine them. I would have to add a pdf with the math but hopefully that makes sense. This is basically equivalent to snipping out the turn data and then processing the whole data set but dropping the first second of the second lap (which would be wrong because the exit velocity of lap 1 is not the same as the enter velocity of lap 2 so you just drop that one data point). Does that make sense?

I also agree with the stuff you wrote about the wind issues. If your course has significant elevation change end to end and there's a headwind/tailwind, that adds more bias. (I simulated that case as well but don't remember the exact numbers.) Measuring the wind would definitely help with that. I had another idea on that too, which is to make the VE total elevation change match an estimate of the actual total elevation change. I might experiment with that. That would make the calcs more complex, but still easy to program.

If anyone gets their hands on a notio, I'd love to hear more about it.

Out-and-backs are degenerate loops, so they count as laps.

Depending on how tight the turnaround is at the end of the out-and-back I snip off the ends, too. Just like Lanier, I have to treat the new endpoint slightly differently.

I do coast, but I soft pedal so my legs are still moving. I coast so that I can check zero power deceleration and widen the range of speeds to help pry apart CdA and Crr.

For out-and-backs, I mirror reflect the data around the turnaround (or snip).

Well, I'm getting SDs of ~.003 even with airpseed. I think you indicated earlier that you typically achieved less variation than that, so I'm hoping to learn something from you... ;)

I know someone who has a Notio, but I doubt it will interest you. They may improve it in the future, but I think it's primarily a JRA device like the Aeropod. James Webb (skippykitten) and Steve Irwin in the UK have been working on more precise systems designed to be used with a test protocol. I haven't spoken to either since the beginning of the year so I'm not sure where they are. Some considerations for measuring airspeed are that the measuring height needs to be near the drag-center of the system (probably near pad or saddle height?) and far enough removed from interference from the system so that you can modify your configuration without needing recalibration. So mounted way in front or to the side, and definitely not something you leave on the bike.

I understand dropping the 1st data point where you splice runs together, in order to deal with the discontinuity. I was curious about how you snipped the same distance from each leg so you'd have coincident points... seems like a combination of odometer and GPS would do it, just curious what you did exactly. It's a feature I'd like to persuade Pierre to include in his app ;) Not just for snipping turns but also locating other points on the course.

In my opinion out-back is the best way to do this testing (loops both ways would be the same), and cutting off the end points of the runs is probably best as well. Ideally you'd have a flattish test section with hills for turning at each end, to reduce the amounting of acceleration required. I don't know about you, but a bunch of ~FTP efforts with sprinting to get up to speed twice a lap is not a workout I want to be doing that often.

Before I measured airspeed I'd still include a wind vector in the calculations. I'd assume this was a fixed value for each out-back lap, and adjust it so that the max and min elevation points matched known values. I still had quite a bit of scatter in the CdA calc from run to run, because the assumption that wind was a constant even for one lap wasn't very close to reality. But it averages out over many laps. A much better way to deal with this would be to map the elevation of the course and split it into sections. Compute a wind vector for each section, but don't require wind to cancel each lap, rather use the constraint that wind needs to cancel for the entire test session. There would be a good deal of iterating involved but it should converge easily enough. It's the best way I've thought of to deal with wind without actually measuring it. The elevation map would not be perfect at first, but could be refined using the data (an elevation error would result in consistent anomalies). I haven't done any programming in 30 years (when I last worked as an engineer) and not much then, and my spreadsheet skills aren't so great either, so I haven't actually done the analysis described above... :(

IMO good software is the most important thing, besides a precise protocol of course. As Dr Chung keeps saying there is so much analysis you can do with the data already being gathered... but that takes a pretty sophisticated piece of software designed for public consumption, and I'm not surprised that no one has taken that on. I'd gladly pay $500 for software that would do everything I want, but I don't know how many would. The CdACrr app is the best thing currently and he basically gives it away.

On the hardware side I think an optimal system would measure air temperature, barometric pressure, humidity (these are easy), plus air speed with yaw and tire temperature. All this would be logged with power, distance, speed, and GPS and analyzed on a smartphone. Airspeed measurement that is sufficiently precise (a high bar actually) and doesn't need calibration every day would be super nice.