This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

30s VAM

The 30s VAM is a great data field to keep on track while climbing. But, in most recent times, the values are (much) too high. It shows high three digit values even at moderate climbs, and even 1.8-1.9k. That's at least a factor of 2 too much. Any ideas what could be wrong?

0 usrusr 9 months ago

I run a homebrew cIQ 30s VAM in parallel, and I can confirm this observation. I certainly would not dare to blindly assume that my own cIQ code is 100% correct (easy to be off by one setting up a ring buffer), but my legs can definitely tell a 1300 VAM from a 2300 VAM. And a 300 VAM from a 1300 VAM. Because on the last ride, it was clearly not off by a factor (as I *think* it used to be, earlier), but by a fixed offset. Always very close to 1000 off.

In earlier observations (long before 6.75), the native 30sVAM was noticeably higher than my cIQ on some days, noticeably lower on others and occasionally it seemed to match well enough. But it was always off by a consistent factor within the same ride. Or maybe it has already been an offset back then? I think it was a factor but it can be hard to tell when it's not that big. Last ride it was definitely an offset, to the point of bottoming out to flat zero instead of negative after the crest (I don't look at any VAM mid-descend, no idea how it was at continuous negative).

The point is that the error changed between rides but remained very consistent within an activity, so the bug must be something happening at the start. Perhaps related to GNSS acquisition or some correction factors/offsets between the raw barometry data (that cIQ can't see) and the elevation reading derived from it.

Maybe the ring buffer for "elevation 30s in the past" is in raw barometry, with a conversion to elevation set in stone at activity start, but the "now" value the old elevation is compared to is barometry with the latest conversion parameters? Those comparison parameters are continuously recalibrated onthe fly, but you wouldn't want to keep copies of those parameters in a ring buffer, they don't change *that* fast. But if you ran your lookbehind ringbuffer on raw barometry (e.g. because the grade display uses the same ringbuffer and you don't want to get phantom spikes in the grade when barometry parameters are updated) using some outdated copy of the barometry parameters for the -30s data would be an easy mistake to make.