Hi Marcag- I'm super busy with work so I don't have time to comment in detail but I would say two things really stand out to me after skimming your posts:



(1) This part above really stands out. I totally understand that it would be great to have detailed and accurate enough sensor data to get real time CdA just riding along, but... it just doesn't exist right now. Lots of people are trying and failing. And it's not just bikes. It's Formula 1 too, and there's real money there, not just the play money here. In the absence of accurate sensor data for elevation and wind, protocols are key for testing. To get precise results you need to pay extreme attention to detail, and follow a detailed protocol. It's really not that hard, and it can be done as part of regular training rides, but it really is that important.

(2) The second thing that stands out is that you seem very focused on getting the elevation profile to fit / make sense. This is actually totally unimportant. What you need is a good estimate of CdA, period. You don't need a good estimate of the elevation profile. You also don't need a good estimate of what the wind actually was. Furthermore, trying to estimate these things does not seem to help in estimating CdA. I have tried going down the path you are going down (spent lots of hours on it maybe five years ago) and I found it did not work well. What works is following the right protocol, testing on a day when the wind isn't massive, and then using the math to average out the wind and elevation changes. The elevation charts that result often look bad and the great thing is it doesn't matter. I don't even look at them.

   



We are a lot closer than you think, or at least I believe we are



Getting accurate altitude allows you to

1) Calculate "instantaneous CDA" or at least calculate CDA on a much smaller window
2) Does not require an out and back which isn't always possible or practical.
3) Opens the door to solving cda/crr.

Instantaneous CDA opens the door for a whole different sensors that are used to explain changes in CDA and find ways to improve it. Measuring is cool, fixing it is even better. Not sure I'm ready to discuss this yet but it doesn't take much to imagine possibilities

Now if you do want to follow protocols, sensors can bring you to a next level of accuracy and eliminate "glitches" and explain inconsistencies.

I thought it was useful info, for discussion in an Aero sensors thread

Out of interest marcag, what device are you using here?

It's not a product per se but a bunch of sensors acquired for another project and put together. All the charts are done in a version of open source Golden Cheetah.

Some of the work will hopefully end up in a future open source initiative.

The post was intended for a discussion on sensors in general, what they can and eventually will do. It's also to provide some data on the discussion that wind measurement is not required.

It should also provide some ideas on how to diagnose irregularities people are having with their device. A cda number is great, but the ability to see how it's made up, where it goes possibly wrong and how to check it was an intention.

The sensors types are very similar to commercial products such as the Aeropod or Notio and assume Aerotech (although I have not seen their product) : barometers, accelerometers, wind sensors, yaw sensors....

PS : cool name

Marcag asked for me to post some data so in the interest of being helpful:

Lots of caveats here. I am not convinced I am doing this 100% correctly. I have my phone mounted between my hands and the unit is on the base bar. I am using the phone app to record "tests" and then doing the calculation in Golden Cheetah Notio. I am still struggling with the calibration factor. It seems it varies depending on even a gust of wind or a car, even if you have it in the same location on the bike. It is not the same run to run but it is pretty close.

Here are my "results" from last Wednesday. It was not a perfectly still day and there was some traffic (one or two cars per run). I did five tests, one longer calibration run (10 mins) and four shorter (5-6 min) runs.
Three base runs were: .221, .219 and .220.
I lowered the bar 1 CM and did two short runs, .217 and .221.

I guess that is pretty consistent given all the caveats. It would take a few days like this and to calculate all of the results over the time to make a conclusion, but the "closeness" of the results is encouraging.

How are you determining that the calibration factor varies? ... or do you just mean the computed CdA varies?

Wind and traffic will certainly affect your calibration runs. The assumption (at least for CdACrr) is that distance-averaged headwind is zero. This will never be precisely true even if you do 1000 out-backs. IME a single out-back can be wildly off. That's why it makes sense to me to use your runs to calibrate if you are able to find an out-back venue with no traffic.

For differential A vs B testing this is less of a concern... but you damn well need to ensure that the calibration is not different for A than B... which underscores the importance of sensor location.

It will read one thing on the phone app, then when you sort out the runs in GC Notio and run the estimate calibration feature, it will re-do the calibration in its own magical and mysterious way and it may or may not come up with something different. It appears the software is supposed to take out abnormalities (start, turns, cars) to do its thing. Like I said, I am not 100% sure it is completely accurate, but I posted some runs on the same test as someone requested it and in case it can be of use to someone.

Maybe we should focus on the first hurdle first... which is a user friendly and efficient system where you can determine CdA in the field with a high degree fidelity and minimal time, when it's windy, even with an excellent venue and protocol.

That sounds like what I said earlier regarding CdACrr. If it's using the runs as your final calibration then of course you will get a different number at the end and your results will be adjusted.

What is your venue like? Out-back? Length? Traffic?

First out and back was two miles each way. The last four runs were just over a mile each way. There were from zero to three cars on each run. It is a pretty good road, and kind of U shaped in the hopes of keeping speed up.

 

If you go in GC, export as a JSON, and email me the file I can take a look and tell you what to look for.

The JSON from GC will have all the data needed.

So I guess you are riding on the shoulder?

Calibration needs to assume that distance-averaged wind cancels. Riding on a different part of the road for out vs back (sheltering), traffic (any), and few laps vs many, are things that will negatively affect this.

But inaccuracies in calibration will mainly affect the absolute values. You can still do A vs B comparisons if the aero sensor is good... but you *must* ensure that the calibration of the device is not affected by the change you've made... A can't have a different calibration factor than B.

It's best if you can find a venue with shorter laps and zero traffic if possible, and ride near the center.

A note on traffic: I've read that these sensors do a poor job of accurately accounting for draft effects. In other words when a car passes the effect this really has on your drag will be different than what it measures. It could be enough to screw up your results.

If one is not dependant on a delta Elevation = 0, we could use out cda = back cda as a way to determine if the calibration is good, or find a better calibration.

If we could get CDA over a shorter period of time, we could determine sections where a car impacts values of CDA

But these two things would require accurate elevation which apparently isn't required :-)

Unfortunately the real-time elevation measurement has enough uncertainty to nullify any information that you'd try to use it for... for testing purposes.

I've been saying for a long time that mirroring an out-back venue that has been mapped for elevation is ideal. This can be done very well with existing tech that everyone has... it just needs to be coded.Then you don't need to measure it and it's very consistent... and you can easily compute CdA as a variable, rather than an average per run.

Some say real time elevation measurement is "totally unimportant", at least we agree this is not the case (I think)

Where don't agree on is what error can be achieved with today's technology.

A mapped course and good protocol will always give better results. I do agree that good realtime elevation measurement would be very nice for realtime CdA measurement; instant feedback for postural changes. So I guess it boils down to how realistic/attainable/important you believe that is.

I agree.

My statement that I don't like protocols is a little exaggerated and half joking.

I want to be as efficient as I can with my time, so if protocols are a little less restrictive, I'm in. Anything that can reduce the restrictions of protocols has value. Anything that can find the errors I made or shit that happened, I appreciate.
I also don't have a perfect test venue.


It also opens the door to other measurements such as the ability to pick apart cda/crr. It also allows to show errors which is of huge value....there is a long list of things.

But elevation measurement is not the be-all and end-all.


Agree.

How important will be reflected in how much you will pay for it. It better provide incremental value over a solution a 1/10th of it's price, or free for that matter. Testing 'a la Chung' is free after all.

But don't make that opinion based on what a single sensors spec says "i have a barometer that does +/x cm". Base it on what a group of sensors, complementing, correcting and calibrating each other than do, in specific conditions.

And it's not just for elevation. Elevation and wind are the biggest benefactors of this, but there is precise to be gained elsewhere.

I know you know this

Yes, that's a reason I liked the mapped course as well. Anomoly checking can work very well when going both directions on a known elevation course. You can even compute lap CdA without an airspeed measurement if you wish.

Restricting the venue is not ideal of course... but the determination of CdA in the field in variable conditions is a difficult task, if you want a high degree of accuracy and precision. A vs B is often a small difference... but marginal gains add up to something significant. If restricting the venue doubles or triples the resolution it can easily mean the difference between a viable test and none.

So I've joined the notio club also, hoping it will be more than an expensive mistake...


@marcag do you ahve the details of what build this is? I've like to do a similar exercise with a VE plot using the Notio data. Or otherwise, does anyone know how I can edit Aerolab to achieve something similar?

TIA

The build I use is based on GC3.5 but I took the GC source and modified it, so doable if you the programmer type but not as simple as configuring things. Hopefully a lot of the stuff done will end up in Aerolab 2.0

That being said you should be able to get all the same info although it may not be on a single chart.

I have not used a Notio in over a year so my knowledge may be outdated, but should send you in the right direction.

Notio used to provide a bunch of charts. Those charts can be "reconfigured". You go into the Chart Settings. There is 3 tabs there called Basic, Curves and UserData. UserData will allow you to add and remove Notio data that you want to plot.

It's not simple, but doable. These charts are made with standard GC functionality.

What I would do is become very familiar with the Charts they provide and understand how they generate them. When you really understand them you can start customizing them or creating your own

Notio used to populate the AirSpeed column. I am pretty sure they still do. If so, you can use the standard VE plot from GC.

If you have questions, post here, send me a PM, whatever.

Thank you, really appreciate the offer of help. It would be great to build up a group of users here to share some tips and tricks for data analysis. At a first go I'm very impressed with the user friendliness of the notio, but any data analysis beyond than looking at the calcualted CdA values will need some leg work.

I will as you suggest get familiar with the GC graphing language and replicate some of these myself! Notio do populate the 'Headwind' column, which I wasn't aware was used by defulay in aerolab 1.0.

Sorry about that, yes it' headwind and not airspeed column.

Maybe post some test results and charts here and we can discuss them

What kind of courses do you have, out and back ? hills ?

I will certainly update once I have some data from a proper test. I've ridden with the device on my road bike a couple of times now, and it seems (unsuprisingly given Notio's own advice) that I can't use the same calibration factor (for windspeed) for both riding in the hoods and riding in the drops. I think I might have a play with mounting it at the end of an extension arm at some point to see if that lessens the impact.

Courses are tricky as I've only recently moved to a new area. There are a couple of out and backs I plan on trying, but I'm hoping longer term to be able to use it on a lapped course (e.g. I've identified a ~7km gently rolling one) where I can do some intervals at the same time.

What I suggest is when analyzing results, break the laps into sub laps with out separate from back. This will allow you to see if the calibration makes sense (wind out = -wind back, mostly) and if the CDAs are consistent.

Look at shorter segments within the laps to see if the CDA is consistent. If everything lines up, you will have more confidence in your data and will be less tied to a specific course/protocol.

If it doesn't line up, you will need to debug the why.

DC rainmaker's comments on aero sensors

https://www.youtube.com/...4_UfQsL2c&t=1785