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.

Either way, I could have sworn this would have changed my factor............it went from 1.34 to 1.33. So, this is with the sensor now easily about 6" to 10" in front of the leading edge past the front wheel/tire.

Now.......I did notice the CdA in the app at least during this cal factor ride was much much steadier than it has been in the past.

Didn't you mention the cal factor may should have changed? I mean 1.34 to 1.33 is like, nothing. I'll try the GC-Notio cal factor estimator at home later.

I have no idea what the device is actually doing and there isn't any guidence about what values seem reasonable.

Submitted ticket to Notio. For quite a while now this thing is way way way under reporting elevation change. By a factor of often 2:1.

In the meantime I'm considering if it's possible me to modify the elevation used in GC Notio somehow? Anyone know? GC doesn't ever seem to do anything with "fix elevation errors". I want to replace the stupid Notio gain/loss with the Garmin one.

This is now becoming a bit shit.

Edit: did discover digging thru a GC google group chat there is an elevation hysteresis value in GC. They chose 3 meters as their value. I attempted to change it and it prompts you to restart GC after. Upon restart, the CdA value for a segment/selection I had already setup in the activity had changed. Soooooo, there is something there in terms of analyzing things in GC at least that's tangible but I haven't messed with it enough yet to see the true effects.

marcag wrote:

You can take the raw data in the BCVX section and compute elevation from barometric pressure. If it's good, you know it's a bug. If that value is bad you know it's hardware

Or you can send me the file and I'll do it for you.

Found the BCVX section on the "edit" tab. Seems to be same data if I download the CSV from the Notio site from my profile. I downloaded that, and my file from Strava. I plotted the calculated elevation using the baro pressure from the Notio CSV file and the Strava file. The profiles of the road match almost perfectly the two plots.

Sooooo, if the data it uses to calculate changes in elevation is good but the CdA rises and falls as an almost inverse of the profile of the road at times............then what????

I computed the "cal factor" this ride and it matches 100% same as the factor from my last ride. Whatever that's worth. So wouldn't think I should mess with that. CRR very very bad? My mass I use I have weighed self plus kit and bike to have that.

Top is the every 1/4 second Notio data I calculated elevation from baro/temp, the bottom is the export from Strava for elevation.



This is the CdA profile: the steadier CdA on the left part that looks lower is the very slightly uphill and into the wind section, then you see a u-turn bump, then the right part that has more rolling CdA value changes is the same part of road very slightly downhill and with the wind. Stayed in aero that entire time for those two, no car upsets, a bit bumpy road but same road and same bumps. This doesn't look acceptable. Accel appeared negligible for those two sections. Wind this day for that road was pure head/tail.

Define a lap for the out and a lap for the back

What is the lap cda for each lap?
What is the wind for each lap ?
What is the delta altitude for each lap?

Cannot find how for a lap to view the elevation/delta altitude for a lap.

You set a lap metric, your choice should be Elevation Gain or Elevation Loss.

Bigger problems.

I think the data is right. So am stopping digging.

Sooooo, I ran the laps thru aeroweenie calc as a stink test. Didn't stink. So started looking the bike over. No brake rub, plenty good. Chain ran fine on the stand. Then I felt the Speedplays. Felt fine play/grease wise. But when rotating them, I saw a massive groove forming in the pedal spindle. Like stick your fingernail in it.

Soooo, the shoe cleat's c-clip is now loose in the pedal when engaged so when I "knee towards the top tube" the metal rim of part of the cleat is literally machining the pedal spindle. Both left and right, left foot worse than the right.

No idea how long I've been doing this, but that's gotta be worth tangible watts to be machining grooves in hardened metal pedal spindles. Zero idea why it didn't make any noise. I'm going to go with the loss of watts at threshold being certainly more than 5 but probably less than 50. Couldn't have happened during regional TT champs as my power was down but speed almost same from prior year. So, likely is why I feel the data has "gotten worse" recently.

Also zero idea what to do to fix it other than I ruined the pedals not keeping enough grease on the cleats and the c-clip wore the groove in the actual pedal assembly too large now.

Soooo yeah. I'll try my other shoes to see if it's just a cleat thing or a pedal thing, but I found the problem. Maybe the c-clip is too loose now or something and the other shoe may reveal that, but otherwise.....new pedals. Sad face.

In meantime, I'll run the Shimano's and those shoes and do a run again to see if this was a "major unaccounted for loss".

Definitely should be fixed, but IIRC, you run a power2max ? So any losses due to the pedal interface should not affect the power measurement.

You may feel like you are putting down 300 and only 265 is being delivered to the crank but it's that 265 is contributing to your speed. In the future check out that delta Alt.

Definitely should be fixed, but IIRC, you run a power2max ? So any losses due to the pedal interface should not affect the power measurement.

You may feel like you are putting down 300 and only 265 is being delivered to the crank but it's that 265 is contributing to your speed. In the future check out that delta Alt.

I verified the alt/elev. is pretty much spot on perfect. I kept digging and think I've found something.

It appears to me the "airspeed" field in the file export is in km/s. Then you would need to multiply by your "factor" to get the true airspeed, and of course unit convert to whatever meaningful units you prefer like km/hr or mi/hr.

So I did this. The dates I applied the factor used on that date, and unit converted to mph. The avg airspeed for that ride was really really close to the overall activity's avg speed (what you would see in Strava for example). Before adding this "boom" for the sensor to be out front.

Fast forward to one of these recent activities in question.........the average parts ways using the factor given from either the Notio app field test OR the factor calculated in GC Notio "get factor" button.

For the ride this week, to get the airspeed to match the activity speed average I had to change the factor from 1.32 to 1.53. The factor before using the boom in the past yielded matching air/activity average speeds.

So. Moving the sensor out on the boom and doing the new cal factor, multiple times, has gotten a cal factor that simply doesn't work. My math on the cal factor it should be is pretty bad. It's also the opposite of what I would think. I thought the sensor should see closer to actual airspeed on the boom. Not slower.

So, now at least I know the why on that one.

Now, going back to data before the "boom" the factor still seemed to most often give an avg airspeed slightly slower than the average activity speed. Not sure that would 100% account for the "CdA rises and falls as ground speed changes during laps" thing though. As it was still doing that quite readily even before the boom.

I'll see what that bogus looking factor does to the GC data.

Things may have changed but "way back when" the factor (which I believe had a default of 1.39) was not applied directly to airSpeed but rather it was used to scale airPressure measured at the Pitot. Probably worth confirming with their support.

Best way I can put it on the out/back laps is comparing it to reading the temperature of your food to make sure your chicken is cooked. You don't want to eat raw chicken, and the following is the temperature readings you get over the last 2 minutes of cooking your chicken taken every 5 seconds:

140
160
165
145
155
175
152
......................and so on....

Now........the average of those each time you cook your chicken over those last 2 minutes works out to 165. But seeing the intermediate values and relying only on temp and not visual...........would you eat that chicken? Hell no.

The allure was someone could use this who can't ride a velodrome indoors nor a velodrome outdoors. Which at this point.......despite being a lot slower, what is a traffic circle without cars? A velodrome.

Some of these devices rely on a pretty simplistic wind out = -1 * wind back and they compute a factor to achieve that.

That works "ok" if you have a good stable wind out and back.
If your wind is negligeable or non constant it makes for a random number generator.

I would not be looking at the factor. I would look if on a day you are getting wind out = 3mph and wind back = -3mph, your factor is good enough. If it's 0.5, -0.5 be less trusting.

If it's 3.5, -2.5 decrease it slightly. Find one that makes sense and stick to it.

I am surprised support is not answering. Maybe ping them on FB and ask them point blank if support is still active.

Another thing I note in the raw dataset is the revcount from the speed sensor on the wheel. Since they sample at 1/4 second, the rev counter sometimes has the same value from the previous 1/4 second. Then, it will jump a count for "catching up" on another 1/4 second reading. This causes the speed over about a 1-second time interval to vary, when in reality....it doesn't.

I have no idea what averaging or filtering tricks occur behind the scenes. But IMO this could be a big issue with how these sensors work.

Maybe that doesn't matter as smarter folks than me know how to deal with data sampled at different rates but used together. I say sampled at different rates as if in 1/4 second the speed sensor doesn't tick over a revolution but obviously you can still sample the temp/pressure/power. But in 1/4 second the speed sensor didn't register more "distance".

If I were to do it, the sample rate would be variable based on each revolution sensed of the wheelspeed sensor and each point's time period is the duration of time it took the wheel to make one revolution.

Right now, you could have constant speed or very very slowly varying speed but you see 0.3kph or 0.5kph jumps in speed between individual readings. 0.5kph in 1/4 second is acceleration of 2kph/s. So imagine that's the amount of accel you would likely have going from a dead stop to 32kph in just 16 seconds. A pretty solid accel.

The raw data of the sensor is a rev count and time at which that measure occurred.

The file I have open, the time is exactly 0.25 second every data point.

As what you say there would align with what my wish was above. But the file clearly has a value in the timestamp column that is 0.25 second increment for every data point.

All my files I've ever downloaded to open and look.

Of note, I need to buy a magnet sensor. Just saw in some literature buried that they recommend a magnet one, not a hub sensor.