For hoots, keep an eye on them. Intentionally hit potholes and rough roads and watch them.

Oh yeah, they jiggle with bounces.

Otherwise, I'm in the exported file. The file populated gpsLatitude, gpsLongitude but didn't populate gpsSpeed or gpsAltitude. Next up, it also has the altitude and altitudeCorr all as very small numbers. Not like starting at an altitude of 350 feet then it losing tiny bits and gaining tiny bits over your ride. Not sure why, but this seems weird.

In GC Notio my altitude starts at zero.

I thought elevation is from sea level and altitude is from the ground. So altitude for a device on your bike should always be the distance from the road to the device. So the altitude, by traditional definition, should always be zero.

I'm just making sure this is right and something isn't wrong here.

The gps coords are like this:
timestamp gpsTime gpsLatitude gpsLongitude gpsSpeed gpsAltitude 0 0 0 0 0 0 0.25 0 0 0 0 0 0.5 0 0 0 0 0 0.75 0 0 0 0 0 1 0 0 0 0 0 1.25 0 0 0 0 0 1.5 0 0 0 0 0 1.75 0 0 0 0 0 2 0 0 0 0 0 2.25 0 0 0 0 0 2.5 0 0 0 0 0 2.75 0 0 0 0 0 3 0 35.60846329 -78.41419983 0 0 3.25 0 35.60846329 -78.41419983 0 0 3.5 0 35.60846329 -78.41419983 0 0 3.75 0 35.60846329 -78.41419983 0 0 4 0 35.60844421 -78.41413879 0 0 4.25 0 35.60844421 -78.41413879 0 0 4.5 0 35.60844421 -78.41413879 0 0 4.75 0 35.60844421 -78.41413879 0 0 5 0 35.60842514 -78.4140625 0 0 5.25 0 35.60842514 -78.4140625 0 0 5.5 0 35.60842514 -78.4140625 0 0 5.75 0 35.60842514 -78.4140625 0 0

Like this:
altitude altitudeCorr 0.03 0 0.09 -0.08 0.07 -0.15 0.13 -0.15 0.02 -0.11 -0.16 -0.11 -0.18 -0.13 -0.1 -0.16

from google

altitude is used to describe the vertical distance between an object and a reference point whereas elevation is used to describe the height of a place above the sea level


what your Notio is probably doing is using your "start point" as the "reference point" in the above statement,


Measuring altitude/elevation change with a barometer is pretty easy. You grab the barometric pressure a the start point and then there is a formula to go from change in pressure to change in altitude or elevation change.

The problem with a barometer is keep in one position, blow on it in one direction, blow harder in another direction and you will get different readings.

So while some barometers may be able to measure 10cm accuracy, that does not include the error introduced by varying weather conditions.

As well pressure at start point and pressure at current point will drift during the day so you will get drift in your altitude measurement.

It can all be corrected but it's not trivial to do it as precisely as possible. The devices don't care about elevation (as per the definition above), they actually care about change in potential energy that can be measured by different methods.

PS, you can get GPS altitude during post processing if that is of any interest to you.
Also, not sure how you export the file, but there are sections in the GC file that you may have interesting data in
Look for example at the BCVX section. One of these days over beers we will explain what BCVX means :-)

Forum needs a like/kudos button. That makes more sense now.

Lets say, the worst was a Rotor 2InPower followed by 1st generation P2Max. Best with ANT+ was / is a SRM PM at a high cadence (or 2 magnets). Anyway, with ANT+ the minimum is allway ~0.25sec, it doesn't get better.

I think synchronisation between sensors may be critical in velodrome testing. I use 0.1sec subsambling for velodrome testing and a heuristic optimisation procedure to synchronize sensors.

Please excuse bad English, we are having a PhD party.

Sometimes it helps to do something like piecewise monotonic speed increases and decreases.

Very close. I do overlapping windows when I'm doing laps or loops. I test at non-constant speed so the windows are each one lap-length long in distance, so they differ in number of observations. It's easiest to envision on a velodrome: each lap is 250m long but say the first lap is done slowly so it takes 30 seconds but each subsequent lap is done a tiny bit faster. If an entire test "set" of 8 laps takes 3 minutes (180 seconds) then I end up with ~150 lap-length windows; I don't average all 8 laps into 1 overall run average. The overlapping windows aren't statistically independent but autocorrelated -- but we know how to deal with time-series autocorrelation, and that effectively adds a smoothness constraint. It's sort of like process control, but with a known anchor point each lap. In any event, since I do laps or loops and generally not on a velodrome, I can plot the estimated avg CdA/Crr for the previous lap-length interval against position (either start, middle, or somewhere else) on the lap/loop. That lets me see if there are systematic differences by lap position that are either dependent or independent of speed and power.

All this talk of differing lags between speed and power sensors has me thinking we didn't know how good we had it doing this sort of field testing back in the days of the "wired" PT hub..."One Stop Shopping!", as one might say, since the speed sensor is built into the hub itself and used in the power calculation.

---

http://bikeblather.blogspot.com/

Did anyone notice a degradation on VE/Chung testing with the newfangled wireless devices ? :-)

Interesting. I guess a similar approach, looking at systematic errors in autocorrelation to understand the time lag issue.

My most consistent results (and smoothest VE plots) were always with my old "yellow cap" PT wheel and LYC ("Little Yellow Computer") head unit. I still have that available to me, if needed ;-)

The data with the ANT+ PT "wireless" hubs is nearly as good. Probably for the same reason that the speed and power signals should be well sync'd within the hub anyway.

When using a Quarq Cinqo as the PM source, I use a separate speed sensor, but I also understand the "quirks" of how the ANT+ broadcast signal is updated in the Quarq (i.e. data sent out at 4hz, but only updated upon the completion of a pedal cycle, so use a magnet trigger and "soft pedal" even when coasting to force it to zero, for example). Not as consistent as with the PT hubs though, especially since drivetrain loss variation comes into play.

Just my experiences...

---

http://bikeblather.blogspot.com/

Yes, though I suspect it will differ for specific models of power meters and speed sensors, and for different test conditions. So I think it's useful to investigate but in the grand scheme of things I think it's possible there are ways to finesse that issue.

I am having trouble wrapping my head around the protocol and what the results show. Have a picture ? :-)

Doh! I realized while re-reading this that the plots I referred to above are in another thread. You can find the post here: https://forum.slowtwitch.com/...ost=7803932#p7803932

Sorry if that caused any confusion

---

http://bikeblather.blogspot.com/

Do you mean about the time lag issue, or about the "overlapping laps" thing?

Anyway here's a plot (from 2009!) that kind of illustrates both. The test was three out-and-back laps on a half-pipe type venue. This test used an old PT Pro, so each dot was an observation at 1.26 sec. (half-pipe and 1.26-sec and 2009 means that Tom collected these data). The x-axis is km of distance. The top panel shows the VE profile in meters, the middle panel is speed in m/s, so the speed and elevation were definitely not constant.



[If you're having difficulty seeing the plot, here's the link.]

The bottom panel shows a calculated CdA for lap-length intervals. Since there 3 laps, that very left-most dot is the CdA calculated over the entire first lap, so another way of thinking about that lower panel is that it should have been moved about 2.3 km to the right, and the top panel should've been normalized to start at 0 -- but this plot was for me and I wasn't confused by it. After an initial period of about half a lap, the calculated CdA becomes much smoother and more regular -- but it has obvious periodicity. Remember each dot actually represents an estimate over the preceding lap-length interval, so this is intriguing evidence that either the PM or the speed sensor or something else systematic (like, my estimate of the acceleration based on the the speed sensor) was introducing systematic error in the estimate. Also intriguingly, after removing the obvious systematic cyclicity, the SD of the CdA estimates was pretty damn small. (BTW, I wasn't assuming a given value for Crr -- I was calculating the Crr and CdA simultaneously from the data). [Edited to add:] I had/have a hypothesis for what was going on, but then my real job interfered and I never came back to this particular topic to nail it down. In any event, I wasn't getting just 1 estimate of CdA from a 3 lap test, I was getting a lot of estimates of CdA over lots of lap-length intervals. That let me do some statistical inference on the estimates.

Plot isn't showing up...at least not for me.

---

http://bikeblather.blogspot.com/

Doesn't appear for me, but I can "open image in new tab"

I've added a link to the image if you still can't see it.

Thanks for the explanation

How do you compute/include rotational inertia ? GC/Aerolab doesn't.

I used to try to include it, especially when I was working with 250m indoor velodrome data because I was interested in whether I could determine characteristics of the track's geometry from the observed data; but when I'm working with outdoor laps and loops like this where I'm basically integrating the power equation up to a work equation (and, thus, the inertia calcs simplify) I found out that the extra effort didn't seem to be worth it. At the time there were other analytical areas with potentially greater return. So I stopped.

[Edited to add] Or were you asking what my hypothesis was for the systematic error that I never got a chance to track down? This "overlapping lap-length interval" approach is sensitive to getting the lap lengths right. Since the data were coming at 1.26-second intervals, the "end" of a lap-length interval didn't usually coincide with an exact observation, so I would have to interpolate between two points to find speed and energy over the lap-length interval. When the speed at the end points was slower, the end points were closer together; when the speed was high, the end points were farther apart, so the interpolation would be less exact. At the time I was doing this, I was using a simple interpolation: if I were to do this now, I think there are better ways. In addition, if there was differential lag in the reporting that would be a potentially addressable issue too.

While simplified, wouldn't they work out to about 4% of work that goes towards acceleration ? That charts shows constant acceleration/deceleration.

I'm pretty sure the acceleration/deceleration can't be constant -- the velocity isn't. By "simplifying" I meant that since I was calculating over lap-length intervals, I didn't have to be that concerned about instantaneous errors in speed, power, or acceleration (I still had to be a little concerned, just not *that* concerned). If the speeds at the start and end of lap-length intervals is close, the contribution of both overall translational inertia and rotational inertia ought to be small. I'm not sure how you got 4% of total joules.

But maybe I'm off. Anyway, here's a YT video that shows how I was thinking about it. In that video, I choose i and k to be the start and end of lap-length intervals, and each second (or, more pertinent to the example above, each 1.26 seconds) I update i and k and slide the window one observation farther along. https://www.youtube.com/watch?v=4OpJapMljOE

Thanks. I will watch. That 4% was by memory and quick calculation seems high. I need to go back and recalculate but yes, if the start and end speed of the intervals are close, which they are, even a 4% of a small number would be small.

Sure...but the accelerations are really slow (relatively speaking), so I don't think that rotational inertia effects are a significant factor.

---

http://bikeblather.blogspot.com/

Condolences in advance. Sorry, you'll never get that part of your life back.

It is getting somehow complex for me. A single VE profile? isn‘t the VE profile dependent on CdA and Crr and … ?

I have tested a number of speed sensors. The simple ANT+ sensors with a REED switch behaved similar, i.e. a time lack of about 0.2 - 0.3 sec. Hub sensors using acceleration sensors are worse.