Login required to started new threads

Login required to post replies

Prev Next
Re: Bike CdaCrr Android app [trail] [ In reply to ]
Quote | Reply
What is the reason for using acceleration data? Even the iBike which relies heavily on this has a hard time dealing with vibration. I'd be surprised if the accelerometer data from a phone was good enough to be useful even with the best filtering.
Quote Reply
Re: Bike CdaCrr Android app [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
What is the reason for using acceleration data? Even the iBike which relies heavily on this has a hard time dealing with vibration. I'd be surprised if the accelerometer data from a phone was good enough to be useful even with the best filtering.

Gravity is such a strong acceleration that it's very helpful in providing in helping calculate pitch and roll, especially when in conjunction with gyros. This would be most useful on a something like a velodrome where you might want a good "roll" estimate on the turns.

It can also be useful in providing good instantaneous estimates of legitimate accelerations, e.g. brake application - something that occurs over such a short time frame that little bias shows up. Less than a second.

It can be horrendous when you try to use it to get velocity or position estimates. I agree there.
Quote Reply
Re: Bike CdaCrr Android app [trail] [ In reply to ]
Quote | Reply
CdA results (average of 10):
Upright in bullhorns: 0.3817
TT position, Giro Synthe: 0.2733
TT position, S-Works TT helmet, with visor: 0.2591

I've noticed too that even if there is a fair amount of wind, the fluctuations eventually don't amount to much of a CdA error if you do enough laps. You can do a quick check by say looking at laps 1-8, 2-9, and 3-10 and see how much difference it makes. Kraig is computing work on a lap by lap basis (I think) but I don't know how he identifies the laps precisely. Also, it seems that wind has very little effect on CdA determination even if it is ignored, unless you have a slope-wind bias, and you wouldn't on a track. I've been using the GPS data for heading, and use that to compensate for static wind anyway.
Quote Reply
Re: Bike CdaCrr Android app [bugno] [ In reply to ]
Quote | Reply
So indeed, if speed fluctuates regulary more than 8% (so 3kmh@40kmh) on a period of few seconds (and in IME this only occurs during very few moments of a VE lap), the error (due to a recorded average speed on 1 second interval with ANT+ standard) on CdA will only be 1%. With a 4% speed variation, it falls to an 0.25% error, with 2% variation (constantly accelerating/decelerating 1kmh every 5 seconds for instance), error drops to 0.06% which is very, very small compared to what VE method is targeting for precision.

If you have 1s intervals, is the recorded speed and power the average for the prior second? So that there is an offset of ~.5s between the time and the power and speed?

Also, it has recently been pointed out to me that some PMs and head units will record two bogus power values after cadence stops (repeats of the last power value), and two zero power values after cadence begins. That can really screw up your results if you have coasting. My Powertap and Joule GPS+ don't do this with power, but it appears that the cadence value gets two repeats after it stops.
Quote Reply
Re: Bike CdaCrr Android app [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
Also, it has recently been pointed out to me that some PMs and head units will record two bogus power values after cadence stops (repeats of the last power value), and two zero power values after cadence begins. That can really screw up your results if you have coasting. My Powertap and Joule GPS+ don't do this with power, but it appears that the cadence value gets two repeats after it stops.
Yes, i have seen this for instance with power2max during crr session where pedalling was so slow that the crank didnt do one complete revolution so power was not recorded... I want the app to detect null cadence during a crr lap to reject the lap if so for all crank based powermeters to avoid bad results. Is this behaviour really common to all crank based pm?

Blog | Twitter| Bike CdaCrr app
Quote Reply
Re: Bike CdaCrr Android app [bugno] [ In reply to ]
Quote | Reply
bugno wrote:
rruff wrote:

Also, it has recently been pointed out to me that some PMs and head units will record two bogus power values after cadence stops (repeats of the last power value), and two zero power values after cadence begins. That can really screw up your results if you have coasting. My Powertap and Joule GPS+ don't do this with power, but it appears that the cadence value gets two repeats after it stops.

Yes, i have seen this for instance with power2max during crr session where pedalling was so slow that the crank didnt do one complete revolution so power was not recorded... I want the app to detect null cadence during a crr lap to reject the lap if so for all crank based powermeters to avoid bad results. Is this behaviour really common to all crank based pm?

My solution to this issue is to have just gotten in the habit of "soft-pedaling" (i.e. coasting while slowly rotating the pedals), instead of just quickly stopping pedaling, while field testing with a crank-based power meter. This drives the recorded values to zero, or nearly so, in a decent manner plus it keeps the legs rotating to get a good average drag value for leg position.

http://bikeblather.blogspot.com/
Quote Reply
Re: Bike CdaCrr Android app [bugno] [ In reply to ]
Quote | Reply
Is this behaviour really common to all crank based pm?

That is what I've heard, unless the data is modified.
Quote Reply
Re: Bike CdaCrr Android app [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
CdA results (average of 10):
Upright in bullhorns: 0.3817
TT position, Giro Synthe: 0.2733
TT position, S-Works TT helmet, with visor: 0.2591

I've noticed too that even if there is a fair amount of wind, the fluctuations eventually don't amount to much of a CdA error if you do enough laps. You can do a quick check by say looking at laps 1-8, 2-9, and 3-10 and see how much difference it makes. Kraig is computing work on a lap by lap basis (I think) but I don't know how he identifies the laps precisely. Also, it seems that wind has very little effect on CdA determination even if it is ignored, unless you have a slope-wind bias, and you wouldn't on a track. I've been using the GPS data for heading, and use that to compensate for static wind anyway.


Great feedback, thanks. I'm excited to maybe be able to approach 'Mantis-grade results with almost no expense beyond the equipment I already own.
Quote Reply
Re: Bike CdaCrr Android app [bugno] [ In reply to ]
Quote | Reply
The app can now records also airspeed with the anemometer WeatherMeter (named WM hereafter, ~80$). It is a pretty cool device which records second by second, air speed, pressure, temperature, humidity:



Thanks to that system (CdaCrr app + WM anemometer), the precision of my aero sessions on a 3600 meters flat loop was improved and get now ~1% or lower CV on CdA with wind range between 0-5 km/h (0-10 km/h indicated by local weather station)

After three years of testing it on outdoor velodrome, out and back runs, rides on different roads, alone or in group, my current opinions are (I surely may be wrong on one or several of them, sorry):

Pros:
  • obviously, measuring airspeed definitively improves the virtual elevation method even with low wind conditions (where wind seems less constant)
  • stagnation effects (the WM is mounted on the handlebar) seem not an issue on the precision of the system. A correction of the raw airspeed from the anemometer, typically a 1.05-1.15 factor, according the position of the anemometer on the bike, provides an acceptable accuracy for CdA (by comparing to apparent CdA when wind is very low)
  • the precision of CdA with the anemometer is not affected when cars pass the tested rider. It is so much better to leave home for aero tests without worrying anymore about wind or traffic
Cons:
  • above 10 km/h wind (5 km/h at one meter), yaw effects or bike parts acting like shields degrade quickly the accuracy/precision
  • measuring CdA with a anemometer (same issue with Pitot I guess), when drafting inside a group ride can't be valid with the 0D model of the virtual elevation equation because of the complexity of the flow behind the rider in front of you
  • monitoring CdA with an aero system can't be used with a good precision (if your goal is fine tuning your bike position/equipment) during rides anywhere, because of Crr changing constantly (+/-25%). You should stick on the same road/loop to compare CdA from run to run, day after day
  • measuring CdA on outdoor velodrome seems tricky in my experience with higher CV (1-3%), possible reasons: specific wind/yaw conditions, bumpy velodrome, or difficulty to keep trajectory near the black line
Other:
  • warning, a powermeter constitutes 50% of the aero system: some models/brands are better than others
  • once wind measured, the sun is now the enemy with possible sudden variation of local temperature (Crr influence?)
  • ...
And yes, I should have done the "Tom Compton Challenge" to prove some of my claims.

bugno wrote:
Hi all,

I have been playing with virtual elevation method for several years now (many thanks to Robert for this and all other guys who provided advices here on ST) and as recent threads pointed out, field testing ask us a lot of time. In order to reduce the time to collect data and analyse it, I recently wrote an Android app to monitor CdA and Crr on an ANT+ enabled phone and it needs an ANT+ powermeter (and an additional ANT+ speed sensor for crank PM). The main features are:

-Compute CdA on laps if mean velocity is high enough (given a Crr estimation)
-Compute Crr on laps if mean velocity is low enough (given a Cda estimation)
-Air density is calculated automatically with weather station data and the app try to use device sensor as much as possible (pressure, temperature if any)
-Data is recorded in 2 different CSV files which is possible to get for post analysis and comparison (for example via Aerolab in GoldenCheetah)

I am testing now an other mode (segment mode) where CdA is computed on the fly with a limited precision (2 digits only) during a ride. Every 1.5 km (@35 kmh), a number is printed on the screen of the device. Of course it is a virtual CdA number cause it depends of wind and drafting, but it is very interesting to see the influence of drafting for example in a group ride...

Thanks, if you get a try with the app (it has been tested with PowerTap and Power2max for the moment and several ANT+ Sony or Samsung phones) and I am interested by any new feature request.

Link on Google play: https://play.google.com/...etails?id=com.cdacrr

Blog | Twitter| Bike CdaCrr app
Last edited by: bugno: Sep 7, 21 13:15
Quote Reply
Re: Bike CdaCrr Android app [bugno] [ In reply to ]
Quote | Reply
bugno wrote:
And yes, I should have done the "Tom Compton Challenge" to prove some of my claims.

I think a "delta mass challenge" is easier to do.
Quote Reply
Re: Bike CdaCrr Android app [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
bugno wrote:
And yes, I should have done the "Tom Compton Challenge" to prove some of my claims.


I think a "delta mass challenge" is easier to do.

Well, technically that IS a form of the "Tom Compton Challenge"...just arguably less of a direct confirmation ;-)

http://bikeblather.blogspot.com/
Quote Reply
Re: Bike CdaCrr Android app [Tom A.] [ In reply to ]
Quote | Reply
Well, the CdA/Crr estimation is indirect so there's that.
Quote Reply
Re: Bike CdaCrr Android app [Tom A.] [ In reply to ]
Quote | Reply
Hey Tom... you interested in doing some more testing?... ;)

I bought the WeatherFlow meter and one of these to mount it: https://www.amazon.com/...2715880762&psc=1

It's attached to the left handle of the basebar and ~45 deg up and out. It's about 18cm from the center of the handle to the center of the meter. Trying to get it outside the influence of bike/body but don't know if I've succeeded. Yes, it's pretty clunky. I figure it adds around 70cm^2 of frontal area and there is nothing aero about it! But it's a test device, not something you leave on your bike, and it should be a consistent drag addition, so I don't think that's a big deal.

I've only been out 2 days and both were quite windy. The calibration factor on the 2nd day was ~5% higher (1.094 vs 1.045) which concerns me. I could have been yaw, or maybe body influence, or maybe when I took extra care to align the meter I actually made it worse? I'll have a better idea after I've been out a few more times.

I'm doing out-back laps (3100m) with a turn around on a hill. Using "fixed lap mode" so I push the button at the start and the app will determine the end. I ride near the center of the road to minimize any sheltering effects so the assumption that "wind cancels" will be valid.

The anemometer certainly helps with consistency compared to what I did before, which was to iterate on a wind vector and CdA that would match the real elevation profile. Wind was assumed fixed for the entire lap and this is no where near reality, so the profiles were a bit wonky and computed CdA for each lap varied a lot (depending on wind). With the anemometer I make the global assumption (for the day) that wind cancels rather than each run, plus the wind will vary a lot by position on the course, rather than using a fixed vector as I did in the past.

Last time for instance over 8 runs (laps), the distance-averaged headwind for each lap ranged between +.99 and -1.12 mph. The measured wind was ~5mph on average (just eyeballing it) +- a lot! Yaw was all over the place, and no idea since I wasn't measuring it.

Computed lap CdA was between .202 and .210, .2053 average, and a SD of .0038 over 8 runs, all the same position and equipment. That's pretty good considering the challenging wind environment.

Bottom line is I think the anemometer and Pierre's (bugno's) CdACrr app show a lot of promise. I still believe results nearly as good can be obtained without an anemometer at all using the real elevation profile and some clever coding, but I won't go into that at the moment. IMO good software (especially a phone app) is vital for making field testing viable for a wide audience. The app needs some work still, but it's close. When I first asked him a few months ago he said he wasn't so motivated to work on it anymore, but I think he might be coming around since he posted here!


Thanks Pierre, for all your efforts on this!
Quote Reply
Re: Bike CdaCrr Android app [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
Wind was assumed fixed for the entire lap and this is no where near reality, [..]
Last time for instance over 8 runs (laps), the distance-averaged headwind for each lap ranged between +.99 and -1.12 mph. The measured wind was ~5mph on average (just eyeballing it) +- a lot! Yaw was all over the place, and no idea since I wasn't measuring it.

Yeah, wind speed is distributed approximately as Weibull, so assuming fixed wind that averages out over a lap isn't always great and having an airspeed indicator can be pretty handy. There are (analytical) things you can do to improve your precision without an anemometer but they're kind of a pain in the butt so I hardly ever do them.
Quote Reply
Re: Bike CdaCrr Android app [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
Computed lap CdA was between .202 and .210, .2053 average, and a SD of .0038 over 8 runs, all the same position and equipment. That's pretty good considering the challenging wind environment.
That's still too much I think, but maybe it was just very windy? I get less variation than that just being very careful with the testing protocol and averaging the wind out.

There are some wind issues that can't be solved by measurement. If the yaw angle is changing, the actual CdA is changing, so even if you knew perfectly what the wind and yaw angles were every moment you could easily get different answers on different runs (associated with a different pattern of yaw angles). In addition, in gusting wind the air detaches and then reattaches, and this process is subject to hysteresis. So again, even if you knew perfectly what the wind and yaw angles were, you could get different answers on different runs. To some extent you can average some of this stuff out over longer runs, but then you also need conditions to stay on average the same across runs and that can be asking a lot in windy conditions.

Still, I'm intrigued by this. If I had an android phone I'd order the WeatherFlow meter myself.
Quote Reply
Re: Bike CdaCrr Android app [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
I'm doing out-back laps (3100m) with a turn around on a hill. Using "fixed lap mode" so I push the button at the start and the app will determine the end. I ride near the center of the road to minimize any sheltering effects so the assumption that "wind cancels" will be valid.
Another question: how well did it do at identifiying the end point of the lap? That's pretty critical I think, both to average out the wind and also to make sure there's zero net elevation change.
Quote Reply
Re: Bike CdaCrr Android app [lanierb] [ In reply to ]
Quote | Reply
lanierb wrote:

Another question: how well did it do at identifiying the end point of the lap? That's pretty critical I think, both to average out the wind and also to make sure there's zero net elevation change.


If the course is a loop (or, if you turn around again at the "start") there are lots of intervals with zero net elevation change.
Last edited by: RChung: May 7, 19 13:51
Quote Reply
Re: Bike CdaCrr Android app [lanierb] [ In reply to ]
Quote | Reply
lanierb wrote:
That's still too much I think, but maybe it was just very windy? I get less variation than that just being very careful with the testing protocol and averaging the wind out.

I've gotten SD as low as .002 (6 runs) on better days using my old protocol. Ya, it was windy. Hard to avoid this time of year, although this was one of the calmer days. And the topography makes the wind very chaotic as well. The wind (m/s) and VE (ft) plots for one of the runs are attached below. X axis is meters.

All good points. I would not expect CdA to be the same each lap. The road is lumpy, the wind is buffeting me around, and the actual CdA is going to changing as the wind changes.

It's damn hard to find a good spot to test, and I suspect that is true for most people. Traffic, visibility, safety, road quality and slope, etc are important considerations. This is the best place I've found but it's still a 20 min drive away. If I tested early morning or evening the wind would be lower, but the sun would be blinding on the horizon and that's too dangerous. Even with the sun overhead, dayglo helmet, shoes, and gloves, and a bright flashing light on the front people still pull out in front of me. In a couple months it should be easier to pick low wind days.

I'm using a Samsung S4 and these are practically free now; certainly cheaper than the weathermeter (which is ~$70).

The app appears to be as good at identifying the start/finish as I am at pressing the button at the right time to start, and inputing the correct distance...;) I'm going to suggest to Pierre a better method though. Looking at my data it should be pretty easy to identify the midpoint (turn) using speed and GPS. So you get that spot and the lap is -1550m and +1550m from that point (in my case). Good precision and no need to press buttons.





Quote Reply
Re: Bike CdaCrr Android app [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
Looking at my data it should be pretty easy to identify the midpoint (turn) using speed and GPS. So you get that spot and the lap is -1550m and +1550m from that point (in my case). Good precision and no need to press buttons.

Exactly. Not only is -1550 and +1550 from that point a net zero elevation interval, so are -x and +x from that point. And that's true for any x. You do have to do some interpolation to find the "matching" observations since (typically) your speed outbound and inbound aren't the same.
Quote Reply
Re: Bike CdaCrr Android app [RChung] [ In reply to ]
Quote | Reply
Yep.

Seems silly to me to not use the actual elevation profile in the analysis, since the points along the course can be located with good precision. All sorts of things are varying when you test, but the elevation profile doesn't.
Quote Reply
Re: Bike CdaCrr Android app [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
Hey Tom... you interested in doing some more testing?... ;)

I bought the WeatherFlow meter and one of these to mount it: https://www.amazon.com/...2715880762&psc=1

It's attached to the left handle of the basebar and ~45 deg up and out. It's about 18cm from the center of the handle to the center of the meter. Trying to get it outside the influence of bike/body but don't know if I've succeeded. Yes, it's pretty clunky. I figure it adds around 70cm^2 of frontal area and there is nothing aero about it! But it's a test device, not something you leave on your bike, and it should be a consistent drag addition, so I don't think that's a big deal.

I am using this one for 2 years, not so clunky. https://www.amazon.com/...pa_dk_detail_0?psc=1



Blog | Twitter| Bike CdaCrr app
Quote Reply
Re: Bike CdaCrr Android app [rruff] [ In reply to ]
Quote | Reply
rruff wrote:

I've only been out 2 days and both were quite windy. The calibration factor on the 2nd day was ~5% higher (1.094 vs 1.045) which concerns me. I could have been yaw, or maybe body influence, or maybe when I took extra care to align the meter I actually made it worse? I'll have a better idea after I've been out a few more times.

I have seen also that, it seems a very slight change of the position/incline of the WM impacts the calibration factor, may be a bad new, I don't know. I try to keep also the same side of the WM face to the wind from day to day too.

rruff wrote:

Last time for instance over 8 runs (laps), the distance-averaged headwind for each lap ranged between +.99 and -1.12 mph. The measured wind was ~5mph on average (just eyeballing it) +- a lot! Yaw was all over the place, and no idea since I wasn't measuring it.

Computed lap CdA was between .202 and .210, .2053 average, and a SD of .0038 over 8 runs, all the same position and equipment. That's pretty good considering the challenging wind environment.

So a CV of 2% (with an average wind of ~10 km/h since your graph, so above my recommended range) and in the past you got 1% with low wind. I think that 1% CV is the goal to reach with the app+WM: while your are not at that level, there is an issue from the test spot, or wind conditions, the used protocol (constant speed/position lap after lap, run after run) or the powermeter/speed sensors.

rruff wrote:

Bottom line is I think the anemometer and Pierre's (bugno's) CdACrr app show a lot of promise. I still believe results nearly as good can be obtained without an anemometer at all using the real elevation profile and some clever coding, but I won't go into that at the moment. IMO good software (especially a phone app) is vital for making field testing viable for a wide audience. The app needs some work still, but it's close. When I first asked him a few months ago he said he wasn't so motivated to work on it anymore, but I think he might be coming around since he posted here!

Thanks Pierre, for all your efforts on this!

I really appreciate the feedback, especially from you. We are talking for years of aero systems on ST, but we have not seen yet a lot of data. Let's start to compare with this cheap DIY system.

Blog | Twitter| Bike CdaCrr app
Last edited by: bugno: May 8, 19 12:54
Quote Reply
Re: Bike CdaCrr Android app [bugno] [ In reply to ]
Quote | Reply
I agree, VE field testing has been around for 11-12 years now? Yet not many are using it. All the ones I know have a science background and a high threshold for tedious controlled testing and messing around with spreadsheets ;) There has been activity lately with airspeed sensors, but the ones that have come on the market so far are still missing the most important part, and that is software geared for testing. And I mean *really good* software that uses all the data available to make results as accurate and precise as possible, and be accessible to pretty much anyone. I know it's still going to take a lot of time in the field, but I think the data reduction is what puts most people off.

It seems that if the calibration of the airspeed is not consistent, we need to either find out why and fix it, or use the runs to calibrate. It could just be alignment. The device is not very easy to align precisely though, and if it is sensitive to alignment, then that means it's sensitive to yaw. For instance if it's tilted a few degrees to the right you will get higher wind readings if the wind is from the right vs straight ahead, and abnormally low readings if the wind is from the left. If I ever have low wind conditions it would be good to try tilting it to the right and left a small amount to see how the results change.

I'm not seeing any bias regarding the wind and computed CdA so far, meaning for instance that a net tailwind during a lap does not tend to higher or lower CdAs vs a net headwind. That is promising. I'll know more when I get more data though.

Pinpointing the turn is quite important for several reasons related to accuracy. First the app would be able to set the correct starting and ending points precisely without user input. Second as Dr Chung alluded to, you can compute CdA values using any of the many intermediate points, not just the start-finish. And third, it allows you to build an actual elevation map (to compare to the virtual one) and precisely locate your position on it. This would allow you to compute a variable CdA along the entire course when using wind data, and allow you to compute variable wind when you don't. That's what I meant earlier when I said good results on windy days should be possible without measuring wind at all... rather inferring it from elevation, speed, and power (with the assumption of constant CdA and wind canceling).

The GPS looks like it would work well for locating the turn based on my files. I know the GPS has significant error in locating position, but it is much better at relative position. When you turn it will trace a curve, and what you want to do is determine the *time* (and odometer reading) at the midpoint of that turn or furthest extent of that turn. Then points +- that position on the run (using the wheel sensor) should be coincident.
Quote Reply
Re: Bike CdaCrr Android app [rruff] [ In reply to ]
Quote | Reply
Just got the anemometer and was excited to use the app yesterday,but it kept crashing in WM calibration.
Before it crashed I managed to calibrate it once and it was way off ,+ I noted the wind speed looked correct at low speed (under 10kmh,then seemed to read as 1 or 2 kmh as it got faster .
Am wondering if this might be to do with latest update (21st May)
Any ideas?

Tested the WM with the wind app and appeared to be correct at higher speeds.
Using Samsung S8, and powertap.
Condition wise it was very still. The surface was quite rough,so was wondering about vibration being a factor(Crr with app 0.007)
Quote Reply
Re: Bike CdaCrr Android app [kevinkeegan] [ In reply to ]
Quote | Reply
Sorry for the crashes in the WM calibration procedure. I will have a look. You can start with a manual input of the calibration factor into the settings (say for instance CF = 1.08).
There is now in the app a dynamic calibration : after each run of your aero sessions, a calibration factor is proposed: you can accept the new value of the CF, if you consider wind was symmetric and no cars passed you. So you can fine tune the CF after some laps...

Blog | Twitter| Bike CdaCrr app
Quote Reply

Prev Next