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

In general I haven't seen many exact specs published for the different sensors - like accuracy of air speed, yaw angle, elevation, etc., and within which boundaries it works and doesn't.

that is an intriguing question. One way to find out the answer to your question is to do the roll out at the prescribed/ planned pressures. You can then at the least know the difference and calculate the differences between one and the other as a %, assuming the highest or lowest pressure is you base then see what it looks like from there. I would see if the extremes are really that large a difference to make you worry about the speed impacts. I have never tried this and would be interested in what you find.

I will guess it is worse for lower pressure larger tires on the cross bike and likely irrelevant for on road TT bike.

A 35, 38, larger gravel tire surely squishes a good bit more at 30 psi than 50. But those would be valid gravel CRR testing points if the trail has a mix if hardpan smooth and rougher surfaces. As higher for hardpan and softer on the other surfaces.

Cross sometimes locally it is hard/fast versus slow muddy. So knowing that could mean big gains in speed.

Also remember that an incorrect wheel diameter will have a much greater impact if you are not using a wind sensor.
For example if you are using "traditional" GC-Aerolab, the power to overcome air resistance (Pair) is related to wheel speed to the cube and is linear for rolling resistance (Prr) ( v^3 vs v^1 ). So if there is an error in V it impacts the Pair component much more and makes the separation of CDA and CRR more 'difficult'.

If you are using something that measures airSpeed the error impacts Pair and Pcrr by the same percentage.

Depending on your protocol/analysis you can compensate for this at analysis time, especially knowing if you are using airSpeed or not. You know that if your tire is say 2.05m instead but your data is computed based on 2.10m, you can adjust the CRR or CDA in GC accordingly to correct.

You need to decide if the process of stopping, measuring, reconfiguring, restarting a session is worth it at test time or if you compensate during analysis

In the Gizmo, I use wheel speed for my speed/distance calculation in the Gizmo. However I don't use wheel speed on my head unit, I used GP. I can then compare the two and see if my wheel size is out of whack. There are several checks/adjustements I do like this. The more sources of data, the merrier :-)

I mean, I could measure the rollout anytime then just update the circumference in GC at analysis time.

How do you do that ?

In one of the dropdown menus at the top there's a recalculate GC-Notio data button, it brings up a popup. In the popup you can enter your CRR, circumference, cal factor.

I've generally done this when there's an obvious "whoops" like I forgot that this wheelset is on 25mm tire on the wheel with the speed sensor versus some of my wheels have the 23's.

And it works, the lap avg speeds before/after updating it there were affected and it seemed to push the cal factor into the "Notio CdA" graphic page slider/input box.

I believe (best to confirm with Notio), that there is a "window" in which the compute their rolling CDA and this is configurable (by default 60seconds). "Lap CDA" is computed from when you press the lap key. So you can be sure there is no turn around data in it. This may have changed, check with them.

The challenge with either of those methods is if you have bad data (altitude or other) during the interval measured. If you use an out and back with net elevation=0 you can cancel out elevation error. But you'll get a number for the entire lap, not rolling value(s).

If you want an accurate rolling CDA you need accurate altitude. If you are not seeing accurate altitude, that is probably your problem.

Eliminating errors by restricting protocol is ok. Better is to identify error, best to correct it with another sensor.
It's not just to get a better measure for the lap, but for a whole bunch of other reasons. If you have good altitude, you can compute reasonable estimates of intermediary data and you can do things like :

- Calculate standard deviation to get confidence in your individual test.
- Separate CDA/CRR at various speeds that change significantly with altitude climbs and descents.
- You can override/correct one sensor with another (baro vs acceleromter vs gyro vs....)
- You can measure the impact of position changes and yes, people move during the test
- The better the data, the shorter the rolling window, the closer you can get to "instantaneous". Different opinions on how short a window is good enough.
- You can start differentiating impact of yaw and not have to try and eliminate it like you do
- ...there is a long list of things you can do better. And no, not all devices do all this....

When you do all these things, you don't force a protocol, you can race with it, you don't need to ride at 27mph to reduce yaw....all kinds of good things.

IMO This is where the technology needs to get.

The more you treat it as an aggregated out and back with constant speed, assuming wind is constant........the lesser value. At one extreme you have lots of constraints and get "fuzzy numbers", and at the other extreme : precision, accuracy in all kinds of conditions. I believe this is what should differentiate the $80 solution and the $3000 solution.

I think you have discovered that altitude is as harder to measure than wind . You have discovered VE is the best way to diagnose and work around some of the challenges of altitude. Having seen altitude challenges in several products, it's clear it's a tough nut to crack. I hope all products export to GC/Aerolab to do diagnosis.

An aerometer is like a scale. You get on it and it says 75kg. Is that really, 74 or 76 ? You don't know. But if you get on and it's 74, then 30seconds later 77, then 30 seconds later 75...your confidence is hurt.

Outdoor/road testing is noisy but again, what will differentiate the various devices is the ability to detect and correct that noise and use it it a variety of condition.
I found this article interesting https://www.rouleur.cc/...U3XH5fJH01O9_B7iWgxc

if a manufacturer needs a closed road to do tests, if you need a flat surface, if an out and back is mandatory, then the manufacturer needs to continue refining their solution to get from good to great.

Anyone know if a pressure based gps like an Edge 530 would get damped out a bit for small stuff if it is nested behind my hands hidden in the TT position? As in, that not being desireable.

What is the next "direction" you will go to find a few watts ?

Personally, I would try to add a tiny bit of stack to angle the torso up slightly, at the same time bringing the head slightly down (with a net looking at the same point away in the distance), with a bit of shrug which should be a bit easier. But that is a WAG that I saw work well on a person recently.

How do you determine a value you are happy with ?

I assume your Notio gives you a "lap CDA". Do you use that ?
Or do you put it in GC and determine a value through adjustment of the CDA slider ?
Or do you bring into Excel and determine a value through some type of computation there ?


When you say "compare to baseline". Do you re-baseline every session ?

I always always make a run of laps of the current setup.

Lap wise if using autolap on the Garmin for out back do a 45 second lead in each direction before setting the lap button. Then about 1/2 mile of lap data. This means fewer laps for same test distance so usually a total of 4 laps, 8 laps if you count out and back separate.

Traffic circle loops of 1/3 mile I will do like 10 of.

Either way I dont do ABBA or whatever as fit changes can be painful outdoors in bike shoes alone. So analyze laps in GC. In GC I do the Notio “factor” thing to ensure it is still about same. Then look at laps in there. Never use the Notio app really. Then expect each lap within .001 or .002 of each other to trust.

I have considered trying longer single lap stuff by doing box and whisker plot on all the sample points. The outliers being easily ignored.

I simply cannot muster more than 7 hrs a week training so meed more CdA gains. Oh, and a new bike pump for mastering CRR testing.

marcag wrote:

How do you account for errors in altitude measurement ?

For your "box and whisker plot" I am assuming you would be doing some type of standard deviation of the lap cda to every point in the lap ?

I want to try the box and whisker. I've not done it yet. I'd have to look into the best practices for doing that, but you're a step ahead mentioning the standard deviation aspect. It just seemed like a good way to visualize the data.

Altitude errors for the really long one lap each? Or the short multiple laps? For my small loop laps I figure there's so many laps of the same error, each setup gets to see the same "bump in the road".

Otherwise, with my new "plate" I made I can simply carry a single 5mm and 4mm allen key with me and a mini 4" long stainless machinist scale to do changes with low risk of not getting it back together. I found a pan flat perfect circle loop, but zero parking nearby. So adjustments would have to be made beside road.

It is here: about 10min from my work in Clayton
35.576124, -78.267447