Help analyzing ride data and protocol

[evokesiron]

I'm pretty sure my testing protocol was pretty bad, but want to figure out the sources of error and fix those for next time . So hoping folks can help with my questions/observations below.

• Calibration I did upright, except for the last part which I think is supposed to be closer to real/TT position? How important is it that the position is close to testing position -- is it only for the time advantage feature?
• I did this on a paved trail. I was mostly alone on the trail so thought it may be viable, but it does have a high-speed roadway that is somewhat close, although there is a buffer area of 25-50 feet. So I wasn't sure if this would work for testing, but wanted to give it a shot, but maybe that has caused issues.
• There are two .ibr files. I guess the smaller one is from the calibration phase? But is it only the last part of the calibration (e.g., I don't see a slow down in speed for the turnaround)
• In the real-ride .ibr (iBike_12_24_2018_1414_17_Miles_HiDef.ibr), you will see some of what I experienced while riding (also in pic below).
• At ~1 mile got into tt position, CdA for next mile shows ~.22, which I thought was reasonable. Then you can see I stopped when my phone fell out of my pocket at about 2.2 miles (yes, told you my testing was poor). Then from about 2.5 - 8 mi I continue (with a turnaround at about 5.4), and it looks like I get an average CdA of 0.25. Not sure why such a difference after stopping (Can I overlap a map within Isaac?)
• The strangest thing for me was when I stopped from about 8.2-9.2 mi and tweaked my position/setup. I intentionally didn't hit the lap button knowing there were issues with that causing estimates to start from scratch. But when setting off in my new position at ~9.2, the displayed CdA was super unbelievably low, like < 0.15, but then would just continue to rise and rise slowly getting up to 0.26-0.28. Maybe it just takes this long to readjust after the stop? But I was also expecting a lower CdA than the first position.

Anyway, (John) or whoever, please let me know if you have any insight. I realize my test was probably crap and this location won't work, but wanted to see if there were any takeaways I could correct for next time. I also don't know where you'all find good testing locations. Smooth/even backcountry roads that aren't used seem hard to come by around here. I'm in the Seattle area if anyone happens to have any location tips . My next location (after getting confirmation that my location is not good), would maybe be an outdoor velodrome, but I'm hesitant to ride opposite direction for calibration purposes.

[Velocomp]

What kind of DFPM are you using?

[Velocomp]

The two big bumps in CdA, at the beginning of the ride, and at mile 9, are caused by your AeroPod changing position (we have hidden graphs that show this).

Make sure your AP is rock-solid mounted and CANNOT ROTATE in the mount.

Otherwise, your CdA data looks good.

There are 2000W power spikes from your DFPM whenever you stop pedaling. What kind of DFPM are you using?

[evokesiron]

Thanks John for taking a look. My DFPM is a Pioneer dual leg Dura-Ace crankset. I'm surprised by the spikes, I haven't seen that in any of my rides indoors or outdoors (thought I also saw it for this ride when viewing in Isaac). Maybe it is happening and other software is just throwing them out.

I had the AP attached with the handlebar mount and tightened with a screwdriver so it seemed very tight/solid. However, when my phone fell out at the beginning of the ride when I hit a bump I wonder if that perturbed it. At mile 9 I changed the height of the handlebars, and didn't think I touched the AP, but apparently something happened wonky there (and as you say data on the AP says it moved). That's good to know though, as a source of error that occurred.

So you're saying it was the fact that the AP moved that caused the weirdness in changes in the CdA (and super low values)? Did it eventually stabilize to the correct values, or would you suspect that the values were still off and I would need to recalibrate after something like that happened? That's fine if that's the case, that would explain things.

[Velocomp]

You are the second customer where we have seen mysterious watts spikes with Pioneer power. We may have to do a firmware "fix" to change this.

Yes, ANY movement of AP will affect its readings. Eventually AP will readjust itself, so that a new cal ride is not necessary.

[evokesiron]

Ok, I think I have almost enough info to go try things again, but a few last questions if you don't mind:

• Any need to be in a certain position during the calibration stage? (e.g., can I be upright vs in aerobars)
• Any indication that the location I tried was not ideal, from the .ibr file, or can that not be ascertained? (e.g., large variance in wind) Does my distance/time look ok?
• If I'm changing the position of the AP (as a side effect of changing handlebar height), is it better to lap-reset to start from scratch, or it doesn't really matter and it will eventually stabilize regardless? I know there is also some new firmware coming out that might affect this.
• I added a garmin speed sensor separately from my gps based one (as I knew the gps-based one was not accurate enough). Is there a way to tell that it is indeed using that and not my gps speed?

Thanks!

[Velocomp]

1) During calibration we measure your "default" CdA. Ride in the position you use most often during training or racing (your choice)
2) Your wind data looks great. I would not move AP
3) If you're changing handlebar height, I would do a completely new cal ride. This is because the opposing wind force can be a function of AP position on the bike
4) AP won't work unless it is receiving speed from your sensor. So, your speed sensor is working! Also, you can use Isaac "Edit/Edit Profiles/Extract from Ride File/Wireless IDs" to find out the ID of your speed sensor.

[evokesiron]

Thanks for your quick replies on the forum, John, helps a lot!