Back to the Martin paper
deltaKE = 0.5 * (mass+I/r^2)* (Vf^2-Vi^2)
I : moment of inertia they they say is approx .14 kg*m^2 . That number could go up or down significantly with the wheel set
so with a standard wheel, 1.315kg gets added to the mass, so about 2% for a pro tour rider and not athlete in larger body :-)

Agreed that in your case J(ke) as per your video should be constant from interval to interval.

However, correct me if I am wrong, other protocols (like Shen) will have "lots" of acceleration so more impacted ?

As well in your video, you are fortunate that your slope is constant and therefore you can rely on distance. I personally can't even imagine a course accessible to me where this would be the case.

This is where I bang on my "we need good altitude" drum, because if we do, it opens the doors to all kind of possibilities to test "everywhere" and especially places that have good and bad asphalt.

BTW, we do a lot of the same work (pun intended) and we solve Cda/Crr via Cramers rule. But we calculate using points of well known change in elevation.

PS : I watched your video. Youtube started the video and then paused, queuing up an ad to show me. You could see the AI engine compute "what would be an appropriate ad for a person watching this video ?". It had a stack overflow, caught the excption, corrected itself and continued to show the video without ads.

Speaking for outdoors, with elevation changes, not velodrome and as a less educated sensor user:

In general this gets back to a gripe of mine about accel/decel. The formulas with sensors (as I'm aware) penalize CdA or CRR for the sins of accel and decel in laps. In reality, if you're in your position for the test and there isn't a massive outside variable like a changing yaw wind you're testing on purpose..............the calc should penalize elevation correction with accel/decel. Not CdA. You're holding as constant a speed/power as you can, your power or speed increases or decreases largely due to elevation changes. Not huge wind changes, if so, try again another day.

I've no idea how you fix the formula or what logic in the programs would be necessary, but it's almost like "if lap is test lap, assume CdA = almost constant". Then use the last 1/4 second's datapoint of accel/decel figure to correct the next point's elevation.

It's why I'm obsessive about finding/using circular laps that even if it has an elevation problem I can do enough laps in short enough physical exertion time that the screwups of accel/decel occur over a same known spot every lap and it's usually only one spot. But with longer out/backs, you're praying that the dozen or so little pieces of change in the road "work out" in the math somehow.

So, the circular laps may look like: where I'm doing a 1/3 mile lap of a roundabout with a small elevation change on it.....
__^__^__^__^__^__^__^__^

But the out/back laps will look like: where it "misses" or treats the bumps/accel/decel differently over laps
______________^____^______
____^_____________________

What you might be seeing is your accelerations/decelerations are actually throwing the barometer off, and making it look like excess or a shorter of altitude change, that works out to a CDA error. If you want to prove/disprove this to yourself, simply look if barometer elevation and VE match since VE does exactly what you say, it assumes "CDA is constant"

I have seen data from at least 3 vendors that exhibit this problem. It's the consequence of relying too much on a barometer. To be clear a good barometers plays a critical role in the solution but it's shortcomings need to be compensated for.

But it's very easy to diagnose thanks to VE.

Yes. The graphic from 13 years ago wasn't intended for showing other people, it was just for me, so there was some stuff underlying it. The VE is in the top panel but that's not the order in which things were calculated: I was using values of CdA and Crr that were calculated from the data, then the VE profile was constructed based on them. I use the VE as an overall diagnostic, then the bottom panel as a specific diagnostic.

Depends on the length of the work interval and the difference between the starting and ending speeds, so I don't really have to worry too much about what's happening to the inertia in-between. (When I was looking at velodrome runs prior to the 2012 Olympics, we tracked rotational inertia cuz we were trying to figure out how well the model worked when wheel speed differed from center of mass speed, but I worry about it less on the road).

The video talked about (relatively) constant slope because I was recording it for a specific audience who had a test venue that was several hundred meters long dead-end up a slight slope outside their door. They were interested in doing either one-way runs or else out-and-backs, and since it was a dead-end street they didn't have to worry about cars. In more usual tests, I do the overlapping windows thing and the slopes aren't at all constant. That's why I have to get the lap-length just right, and that's the basis for my hypothesis that the systematic cyclicity in the CdA estimate was due to my method of interpolation or allocation being insufficient.

I'm relieved it didn't show you ads for cheap eyeglasses, pocket protectors, programmable calculators, and porn.

Hmmm...the only accel/decel events that should be "penalized" are just braking events, where energy is being removed from the system outside of the potential and kinetic energy "bins". Otherwise, the algorithms should be able to estimate the accel/decel from the change in speed data and apportion the PE and KE appropriately. If they don't...that's a bug. My own VE spreadsheet does so using the current and previous speed reports, but combined in a type of weighted average...I'll have to look it up to see exactly how I did that.

Now, if you're saying you're not able to do an out-and-back type course without braking...well, that's the reason I figured out to find a course that represents what I call a "halfpipe" profile (i.e. uphills into the turnarounds) so that the turnaround can be done at a slow speed and without braking. A side benefit is that because one is traveling quite slowly, than any position "breaks" (i.e. to look behind to make sure no traffic is coming) has a significantly smaller effect, if any, on the VE calculation.

---

http://bikeblather.blogspot.com/

Yup...Robert and I discussed that right here on ST in 2008 when I observed that the Polar S710 watch barometer appeared to be behaving like a "pitot tube" of sorts ;-) https://forum.slowtwitch.com/...ost=1708133#p1708133

I'll have to see if I can dig up that original plot that got lost in the TinyPic death...

The "stagnation" effect seen with barometric sensor is also why I'm skeptical of aero sensor placement that's "close in" to the rider, and doesn't require a recalibration to actual speed when positional changes are made. That would seem problematic.

---

http://bikeblather.blogspot.com/

Wondering what the Crr plot looks like... do you have that?

If I understand burnthesheep correctly he is saying something else. Let's say true Cda is 0.22. However solved constant Cda might actually come back as 0.223. In reality the solved Cda comes back incorrect because it missed some true elevation not because cda was actually different. This is particularly true if you know that you held a more or less constant position. I think he is suggesting in effect that if there is a particular second(s) of data that is an outlier in terms of implied cda for that specific moment, it would make more sense to set that Cda to the mean or median (excluding that data point) and then adjust actual elevation to fix the fit of virtual to actual elevation rather than change cda to try correct the virtual elevation fit.

I did a really simple test.

- Put barometer on a drone, equipped with a ultrasonic distance detector pointing at the ground.
- Hover at exactly 1m. Use the ultrasonic sensor to measure that.
- Rotate slowly from North, East, South, West really slowly, staying at 1m altitude according to ultrasonic sensor
- Log ultrasonic detector, barometer, compass, wind speed, wind yaw

As the wind hits the barometer at different yaws, different strengths, see the barometer appear to go up and down despite the fact it is at 1m.

yes.

And there is a very elegant way to figure this all out with the right numbers of sensors and some good use of probabilities and other mathematical goodies.

The best way I can put this is it's the barometer for elevation, not braking. No matter the gps I've ever used it simply cannot get the elevation right for my work laps where I do some simple Z2 spinning at lunch. Not aero testing, just workout. Vehicle bridges over railroads must have at least 24 feet from the tracks to under the bridge. Add to that the structure of the bridge for the supports and surface, so another 3 or more feet. We're at 27. And this road definitively starts on either side of the railroad at the same level, or lower, since the railroads are typically elevated so they won't flood in low lying areas. I say it's right about 30 feet.

Each lap I go over the bridge twice. 60 feet total. The total elevation these rides is never enough for the # trips over the bridge. As there's minor 3 feet here and there stuff on the other part of the lap.

Given that error..........but assigned to an aero sensor.......it's going to think since it doesn't know it's for elevation you slowed up or sped up or changed power......that it's aero related. You told it a CRR to use.

Marcag is right........elevation accuracy.

In that instance, if speed varied enough you'd see a different solution for the (CdA, Crr) pair. In addition, the reason why I use VE as a diagnostic of overall fit is that it can help show a transient outlier in VE that isn't visible on other laps. [Edited to add] The right test protocol isn't just so you can get a good estimate; the right test protocol also helps you know when a faulty estimate is faulty.

I don't think we are disagreeing. Burnthesheep even made the point that's why he does laps. I think the point was made in reference to "intelligence" of the sensors to pick up faulty estimates rather that the human picking up the faulty estimate.

You are absolutely right on the ability of a more sophisticate model to determine which signals are better than others and pick the best signals.

However, if the model doesn't have all the data, nothing like a VE plot in front of the greatest fusion engine in the world (the human brain). With a few plots of various signals you can quickly see what is wrong.

But with a more sophisticated model you can give simple to interpret results. I'll send you details.

With the Notio (or some of the other vendors that I have tried), set the Aerolab CDA t(hat controls VE) to the value computed for the "lap" and compare the two curves. They will VE and Altitude chart will diverge at points, probably converge at others and you will understand where the data flaws are. A few simple tools like syncing the curves at specific points make things easier.

Yeah. I oscillate between thinking we need better sensors (like elevation and body position) and thinking we need smarter ways to use and analyze the data we can already collect. I was doing this stuff in 2009, pre-air speed sensors and pre-high precision elevation sensors, so I'm still a little surprised at how many people think you have to start with an assumption about fixed Crr, and do lots of laps.

RYINC has it right on the point I'm making.

If talking the sensor, and the CdA it gives you afterwards in GC Notio.......when doing out/back laps it's a dice roll if the elevation registers correctly. And the hit is always to CdA. So you see the CdA suddenly go from .210 to .250 to .200 then settle back to .210. That's fake news. That was a piece of elevation the sensor(s) didn't read that screwed the reading.

So, I do what Rchung says and I design my laps so I can control those "problems". And see them in the data. So, 1/3 mile long traffic circle with a "known" high point that will register every single lap the same way beats an "almost flat" 1.5mi long out/back any day IMO. That short traffic circle gets me a mountain of laps per test.

I've found one that's a little less of an obvious peak that I'm trying soon. I've also one I found that's pan flat and really long but cannot park nearby so would need to keep adjustments to a 5mm/4mm allen wrench kind of thing or carry my tools in a musset bag to get to it.

I'm with you

And this is why if I buy a device for many hundreds of dollars, I expect it to work in a broad range of conditions because I can't always find a site to do accommodate the quirks of the device.

Yes. I think that several of the current devices can work well under ideal conditions; I'm not so sure about less-than-ideal conditions. But until that day, it's good to know 1) what the quirks of a device are; and 2) what kinds of protocols and analyses you can use to finesse the quirks.

Gonna try this out: a bit more "out of the way"

Do you feel that the air/wind speed measurement of your setup to be the limiter in overall performance/accuracy ?

It might resolve an error I introduced by putting the sensor on the right basebar handle. I noticed a yaw error where if the wind was crosswind the sensor would pick it up more outbound than inbound. My guess, because it was on far side of the bike.

Now with it way out front and also not on the skis, shouldn’t need new factor if messing with cockpit. And solving that issue I saw.

The device on the right basebar is known to be problematic. That would apply to any device. I would tell people not to do it, but would get "I saw Dan B doing it". Dan B should have put a "don't try this at home kids, these are professionals at work"

The "way out and in front", will help your "calibration factor". I find the different solutions out there interesting. They kind of remind me of "auto calibration" of the PM, which everyone does today, vs calibration at the beginning of the ride and live with drift. Nobody liked the autocalibration back in the days because a) it wasn't always accurate b) you never really knew if your numbers were good or just calibrated differently. But they polished those algorithms. You can do it manually in your GC and assess how successful it would be for your device. The performance of such an algorithm is a huge differentiator of these products.

Again, the trick with the boom would apply to any device. So when completed, it will be interesting for you to tell us if you think your airSpeed sensor is a limiter in the performance of your system performance. I think we can all agree that that sensor is pretty basic and there are more sophisticated solutions out there.

We really need Ray, Tom and Robert to get together (again) and test all these devices. The whole calibration thing is one of the top 5 items to try. Also in top 5, I suspect Tom has his Compton ball are ready to roll.

I recently tested a device. On day 1 I brought it to a course knowing it would probably pass with flying colors. It did. Second day I brought it to a course that "if it did well there, it would do well anywhere" and it was...well...kind of ok......maybe.

I am convinced Ray, Tom and Robert could grade all these devices on a scale of 1 to 10, and we would see clear differences in different conditions. I also suspect they would all have conditions in which they thrive and others in which they struggle. Assign a performance/$ score as well.

I suppose we wouldn't be able to call you up for the 3-D printer specs for any missing brackets this time.

Unless
a) I send a device to be part of the tests
b) I intentionally not include brackets to get to speak to you guys