I use two courses almost interchangeably (not on the same test). Both have negligible traffic.
1) I have a 6-mile (3 miles out/back) course setup on the frontage road of a state highway. I have to brake once at the turn around, which I've marked with paint on the road.
2) I have a 5-mile three-corner loop, all right turns with no stops, pavement quality is sorta terrible.

Then i do a Control run - where I run my baseline suit/helmet/wheels at a steady pace (NOT race power, call it 85%). Then I do two test runs with the variable changed, whatever it is. Then look at the data.

The keys to doing any aero testing effectively is to write everything down and control as much as possible. I keep track of as many variables as I can - It makes keeping track of tests significantly more straightforward, and pretty easy to do in a spreadsheet.

As soon as the local velodrome changes their policy to allow geared bikes on it (while renting the track), I'll do all of my testing there, just because it eliminates another few opportunities for the data to get muddied.

 

What numbers do you use as your "final" results ?

The ones from the app, the Garmin, GC ?

GC.

I haven't found the "live" CDA to be overly useful to me.

That's awesome! I might be done racing for the rest of my life, but I'll definitely give that a try.

I don't know if any airspeed sensors work better. One thing that bothered me about the WM is not being able to align it perfectly, and also the alignment varying day to day. I could fix that part with a better (custom) mount. Just looked at my data, and the calibration varies with a std dev of ~0.7%. I don't know if alignment causes much of that or something else...? Wind direction (probably the big one), pressure, temperature, humidity... ?

It does seem to be immune to yaw (for me)... in other words if I calibrate it using my runs, my computed CdA is the same regardless of wind conditions.

I endorse this.


I endorse all of this, too.

Older methods of estimating drag just assumed that you could hold power and speed constant on a flat course with no wind. Laps or loops and second-by-second recording of speed and power were an improvement because you don't have to hold power and speed constant, or use a flat course--but you still need no wind.

An accurate and precise anemometer means you don't have to worry (so much) about wind.

An accurate and precise altimeter means you don't have to worry (so much) about laps or loops.

An accurate and precise accelerometer means you don't have to worry (so much) about using your brakes.

New sensors (if they're accurate enough) ease the restrictions on protocol.

The key is that sensors have to be sensitive enough and accurate enough and reliable enough so you can trust the results over the range of speeds and wind and slopes that you're interested in using for testing. If the sensors aren't sensitive, accurate, and reliable then you could be worse off than before. Yes, you want a good estimate; but if you can't get a good estimate the next best thing is to know that the estimate isn't good -- and by roughly how much. The worst thing is if you have a bad estimate but think it's good. Unfortunately, the diagnostic can't automatically fix errors. Right now, the best it can do is tell you that there are errors so you can try to figure out what to do about them. This is hard, and takes a lot of experience and some thinking.

I have yaw on the sensor I am using. Useful, but not as big a deal breaker as I thought.

Several times it has explained "blips" on my VE.

I have "instantaneous" CDA except for a few specific cases (which are getting fewer and fewer). I do plot CDA vs Yaw and see trends so I believe it eventually will be quite useful

The first aero sensors I used had yaw, but they were significantly more expensive to manufacture. Today, there is almost no price difference so it's just another data source to use to get a better understanding of the data.

It would be great to be able to parse out the different factors that can cause inaccuracies and determine their magnitude/impact on the results. I remember reading about all the physics that went into how the center of gravity of the cyclist was affected by the banking on a track and then watching how the Skippy Kitchen sensor shows how the yaw angle changes as a rider goes around the track.

I have done some indoor track testing with just a power meter and speed sensor and using VE/Aerolab. I can't see the effect of either of these sources of error on my VE profiles, so I am thinking these sources of error/bias are pretty small, or they are are offsetting sources of error, or it provides some insight into how poor I am at testing.

IME if you don't use these parameters you will get more errors when testing at varying speeds and/or high speeds (on track).

If you plan to use your device on the track, I'd check with their support team if they have any constraints and if they support track use.

So I asked the following question about inclination calibration to the Notio support
I am curious about how the Notio does its inclination calibration. I did a successful out-and-back calibration ride, but it seems like on a consistent downhill I get a low CdA and when I reverse the coarse and ride back up a somewhat higher CdA. Is there any way to figure out if the inclination is correct and is there any chance you can provide a short description of how this is performed?

The answer I received was as a bit puzzling and it sounds like they aren't doing an "on-the-bike" calibration. There response was as follows

We do not have inclination calibration but here are a few things to check

weight will have a big impact if not correct
- power meter accuracy (could be corrected with mechanical efficiency in GC) if not the same power out vs back
- speed could affect cda, (CdA changes with speed) if you ride at the same speed for the out vs the back, your cda will be similar. What we have seen is that higher speed equals lower CdA (riding down the hill will probably give you a higher speed if you kept your power thus lower cda).

What I take from this is that spending some time getting the device as level as possible is important if you want reasonable instantaneous, or on screen estimates.

I haven't gotten a chance to do any testing again because of a back injury and then forest fires have made for some horrible outside air quality. However, I did get a chance to go out and do some more testing today and yesterday after my ride. For this session I just did 4 replicates of 1 lap of my 2.5 mile out and back course. Once again I got some pretty consistent results compared to my earlier runs on the same course. Three runs were very similar at 0.306, 0.309, 0.308 and then one stinker of 0.324. I also have 0.310 from another 3 lap out and back. So for this same course, in less than ideal conditions 7 out of 8 runs were between 0.306 and 0.310.

I will try to post some pictures from the Notio version of Golden Cheetah. Once again I don't exactly know what the graphs are depicted and will check in with support for some more insights. All in all though, it looks promising for repeatability. I will do some modest equipment testing before moving onto to testing on different bikes.

May be it was just an artefact due to the position of the sensor wide in front of the bicycle? I made such a fallacy looking at a windex positioned in front of the front wheel going round a track. ST guys (AF in particular) pointed to it some years ago.

Doing some vector math it came out that only the front and the back of the bicycle gets some yaw (in any case <5°). I would even claim that the front wheel gets „more“ yaw from steering than from turning.

 




They may have changed things so I can't comment on how Notio do it, but I do know how other devices do it (or did it). These devices have barometers that are good over "longer distances", in "specific conditions". They have accelerometers that are very good at instantaneous inclination but you have to worry about them not being level and introducing noise from things like vibration. And of course you may have other devices. You can use one device to correct the other. In super simplistic terms, you could use the barometer over a "long time" and use it to find the accelerometers bias. There are techniques to doing this and IMO this is what differentiates the quality of some of these devices. Elevation accuracy is king.

IMO you're chasing the wrong rabbit, but see if you can look at the "accelerometer plot" from a flat surface.




This is all true. You need to set what Aerolab calls the ETA to 0.97ish for a crank PM and 1.0 for a hub based solution
For the varying CDA, while true, in your case I suspect is not the big culprit. I would put this aside until you've done more testing but you can do things to sooth this concern.

a) separate your laps in out and backs. You can combine them later in GC
b) look at the wind for your out and back. If wildly off, your calibration is probably wrong. Strong suspect here
c) look at the total ascent/descent for each portion. Strong suspect here
d) See if you can get a continuous plot of CDA. I'm pretty sure it's there. If not, use your VE chart to pinpoint where CDA changes. Dr Chung has spoken about this.
e) See if maintaining a more constant speed helps, which IMO won't make much of a difference here




Split apart the laps, this will give you insight into the conditions in which you can get "accurate" results. Also the use the VE chart or continuous CDA chart since it should show you where the "stinkiness" (your term) occurred.

I recently did some of the stuff described in the evaluation of some technology not on the market. Eventually it would be interesting for a guy say like Ray to do a shoot out of all the various technologies using some techniques and tools meant to asses the strength/weakness of these devices.

there is a very interesting interview on the Flo Faster Podcast with Chris from the sensor design team at Aerolab. He had some interesting things to say and if I paraphrase him correctly he does not see this technology being plug and play consumer friendly for a while yet. So maybe the for dummies part is to be a means of education for users on how to do the best job for getting reliable data from a unit.

I come from a chemistry lab background and we talk about measurement uncertainty. This is basically the sum of all of the errors in the system between the inputs and the final answer. I see a similar problem for an aero sensor, each detector in the system has some sort of error regardless of how big or small, these error are cumulative. Chris mentioned in the pod cast how hard it is to get sensors that they deem accurate. Another item that is not part of their sensor but is integral to it working is a power meter and we know the issues there. Well if that is a problem then the machine they provide info into can not be any better than their accuracy. (and don't get me started on precision). So the idea of accuracy is a ghost, there is no way I see to determine the "true value" for CD or CDA, I suspect more it depends on the environment etc, etc. So accuracy is not likely a term that will be useful until someone comes up with the way to determine the true value and I suspect that is always going to be a relative thing, ie CDA at (put specific conditions here).

So the Chung method may in fact be one of the best/ elegant (dare we say gold standard, thank you Dr. Chung!) methods out there because inherent in its method is the minimization of measurement errors. What is cool is how it can be diagnostic for errors or real changes. Also error trapping is visual. Unfortunately it is not real time. Though technically real time, dealing with systematic with sensors may not be that easy. So per the pod cast they see users of the Aerolab sensor being people who are trained in how to use the system, not casual folks who just want a device that produces a number on the road.

It might be handy to have some way to assess and prioritize information from sources ranked from most to less reliable. This is a hard problem because there would be so many paths through the data. In a Kalman filter or Bayesian sense, the error distributions for different devices aren't all identical or independent. GPS could be more reliable at lower latitudes than at Montreal or Copenhagen; speed from a reed switch sensor might be more reliable than one from a wheel hub accelerometer sensor; altitude and inclination might be more reliable from some sensors than others; etc. I haven't been able to do a rigorous test on aero sensors but I suspect there will be differences.

Yes, and the "most to less reliable" is based as much on the instantaneous condition than the sensor itself. There are conditions barometers do well, there are conditions they suck. Same for gyros, accelerometers....Identify those conditions and deal with them.

There is also a good amount of "redundancy" of information to be used. For example, I have three sources of info on wind direction. Multiple sources of elevation change...

Then there's things that is specific to cycling that just make things simpler compared to a drone. Then there's stuff (like bad roads) that make it tougher.

And of course some basic physics laws that help.

though you have redundancy, how does that inform your measurement? can you determine bias, or how do you know which one is telling the best version of the truth? For elevation there may be some gold standard measurements but that is hard to do every time you want to calibrate your device? I doubt that you will put the device in a bell jar with a saturated salt solution to calibrate the relative humidity before each test session? and on and on... so you have to believe the measurement devices in the aero sensor stay in calibration over time (day to day). How true can that be? and at what cost? I think it is a very complicated system to try and control all of the potential sources of measurement error. Math may help but that is way over my head.....

Sorting through and evaluating the redundancies is a feature, not a bug.


The one constant is the road (I suppose unless there are earthquakes or landslides), so I translated all the measurements into a virtual road. That's how you can assess which source of measurement is telling the "best" version of the truth. The other piece of that is you don't have to match up every single damn inch of the road. I cumulate to look at the overall estimate. That's how you can tell bias.

I am more thinking in terms of a sensor device not when one is using the virtual elevation method. How in a real time multi sensor device can you tell truth? again asking because I do not know the answer... I appreciate your explanation(s), even though the math you have done goes way over my head the elegance of the virtual method and the fact it can be visualized graphically is so cool!

In order to calibrate a bathroom scale or a car odometer it's hard to do in real use in real time--but you can do it not in real time and then hope it still holds true in real time. For example, you can take known weights and place them on the bathroom scale, or travel known distances down a road, to check whether they're reading accurately and precisely. Then you step on the scale or travel down the road (and I suppose if you're still worried, you check the bathroom scale or odometer again). We do the same thing with bike sensors. We add a known amount of drag (which can be via a change in elevation, or a change in drag area, or a change in speed) and see whether they accurately recapture the change. Some barometers or variometers can measure a change in altitude of a few inches. So we can often independently check their accuracy and precision by comparing to something real.

The math isn't that hard or I'd never have been able to do it. I explained it to my kid when she was in 8th or 9th grade (though, admittedly, I didn't explain how to solve for the CdA and Crr part when she was that age, and now that she's a senior in college she's made clear that she's not interested in hearing the rest of it).

I see, thanks for the explanation. I guess I never thought of calibration of a scale as not real time but when you look at it that way yes I see your point. Does this mean that you feel that a sensor device can predict CDA in "real time" on bike just riding along? What got me going down this rabbit hole was listening to Chris Morton and him saying that he felt it was not for the general user but a trained user under proper protocols. He also mentioned the problem of getting good sensors, not every sensor they receive passes the test to be used in the device. All of this then started the wonderment. I'll stop now :-).

I think maybe eventually we'll get sensors that are accurate enough, precise enough, and sturdy enough that "real-time" CdA would be reliable on just any road while just riding along, but we're not there yet. Until we get accurate enough, precise enough, sturdy enough sensors, we'll have to be careful to use these devices on *relatively controlled* surfaces with *relatively controlled* protocols, and check them frequently. Each new sensor lets us add "redundancy" in a particular way so we can see whether our answer is consistent or inconsistent with the previous data, and under what conditions. It's not really all or nothing -- each new sensor widens the range of situations where we could do testing, or narrows the error bars in situations where we did the same testing.

Yes, absolutely. We are not there yet but we will get there. I am betting money on it.



Who is Chris Mortin ?

I'll make this comment. There is a need to make it accurate and there is a need to make it easy to use. Easy to use won't come until we solve the accurate.

On the "the math is not that hard", yes, the CDA/Crr formulas are not very sophisticated and solving this with a little linear algebra or having to integrate here and there is within my competence.

For the heavier lifting, I had the foresight 25 years ago (to the day yesterday) of producing what would become a Magma Cum Laude EE with a passion for math, now a Masters student in AI, thinks programming Kalman filters into FPGAs is fun and who works for Guinness beer. I give him 2 and tell him to dumb it down and explain it to me. Works every time.

Dr. Chris Morton University of Calgary prof and one of the people behind a device called Aerolab (aerolab.tech) which is referenced in my earlier post regarding the Flo wheels Faster podcast wherein he was interviewed.

Ah yes, cool !! I heard him on a recent podcast.

Looking forward to see their product in action.

I can't stop thinking what is the actual use of putting a numerical value on CDA. If you are JRA surely you just want to know if the value is going up or down. Am I right in thinking that Aero drag changes with speed as air detaches at differing speeds and stalls, interacts with different rotating components (cranks, and wheels) let alone the human body, So you numerical CDA might only be true at a certain cadence and wheel speed. Please excuse my rambling!

That's like saying rather than giving a numerical value like watts, all a power meter needs to do is report higher or lower.

Cd does vary with speed but the important question isn't "does it vary," the important question is "by how much?" Over the ranges of speeds we generally ride at, CdA may not be exactly independent of speed but it's *mostly* insensitive to speed so we can treat it *almost as if* it were constant. So that's still pretty useful.