Vo2 Max

suzzlo · 1 May 2019, 16:51

@paul870 in Runalyze you can change running type (jogging, tempo, Interval,…) I think it affects to VO2Max calcs

BR

ianshowalter · 1 May 2019, 18:59

@Yannis-Belouris @suzzlo You can also choose in the dialogue box to change the running type whether or not you want that run to count toward the VO2Max calculation in Runalyze. There’s a checkbox option for whether or not you want it to be used for estimation. For example, when I do a trail run on very rocky terrain that I have to take slow, but it still jacks up my HR from dodging all the rocks, I don’t count those in my Runalyze VO2Max estimation because a couple of those a few runs apart will distort the whole thing.

1 May 2019, 21:14

@ianshowalter
In my case it is way off whereas on a Garmin watch it was spot on.
Also,
since you guys are more knowledgeable in things related to runalyse, how do we make runalyse recognize best efforts in races?
I cannot get it to understand any race , except one, despite designating them as such.

Dimitrios Kanellopoulos · 2 May 2019, 14:04

@Yannis-Belouris same here I was wondering the same. Btw did you check their FB groups?

2 May 2019, 14:34

@Dimitrios-Kanellopoulos Just checked their (?) help button. The races have to be excatly the distance (e.g. 21,1K - I did a manual adjustment of the total distance) for this to have any effect.
Also, one has to manually include or exclude certain workouts from vo2max calculations, etc.

Dimitrios Kanellopoulos · 2 May 2019, 14:51

@Yannis-Belouris yeah I do that (vO2max) after every trail run. Even if I do my best performance on trails the vo2max looks very low. Even if the ascent or climb score is high. Strange as I think there is no way to get that for “mountainrunning” (not simple flatish trails)

stromdiddily · 2 May 2019, 15:15

I kind of cheated it a bit by upping the correction factor for elevation gain which has put it closer. The only reason I ever run on the roads is for flat speed work so almost all of my elevation would come via the trail.

paul870 · 3 May 2019, 14:47

thanks for all the replies, I do discount any runs that are intervals as the recoveries really do mess up the Vo2 max…
Real point was why is Suunto’s so poor, and why it’s not there in SA.

I understand it’s not a simple point to get right, but the Suunto number is really poor.

estevez · 29 Apr 2020, 16:25

Still no VO2 max data in SA for Ambit3Peak? In Movescount I have VO2 + EPOC, however I cannot find it in SA.

lexterm77 · 29 Apr 2020, 18:12

@estevez said in Vo2 Max:

Still no VO2 max data in SA for Ambit3Peak? In Movescount I have VO2 + EPOC, however I cannot find it in SA.

MC used VO2 estimate (not max) based on Suunto (Not FB) algorithm. New fw added on S9 watches half a year ago has calculation of vo2 max (estimate Really since its not measuring you delta co2 from lungs).

So, FB used your personal metrics combined with filtered data(poor quality data was discarded) to calculate (read guess) your MAX volume of oxygen. Higher the intensity and the more level the ground is and more steady the pace is, more the data is valid for your VO2 Max.

MC used a different metric, it is your estimated volume oxygen intake, not max unless you exceed your vo2 max for more than a few minutes then you would see your vo2 max at the peak. This is estimation of an estimation. Because you can only assume your personal data is correct.

Ambit has a built in feature for running performance which is similar but not same as your vo2 max on S3/5/9. It is calculated on watch. And later transferred as a graph to MC.

Ambit cannot calculate EPOC on fly, it is something MC did.

S9 can calculate on fly but sadly it only records highest value on SA. There is no graph.

I wish it would show a graph so users can have a better understanding of their aerobic and anaerobic thresholds.

SA would have to implement epoc graph and vo2 estimation (not max) to have feature parity with MC. I would assume SA servers have enough processing power to calculate those values since equations can basically be copied from MC (assuming no licensing involved)

I think I just made my answer even more complicated. 🥴

margusl · 29 Apr 2020, 20:44

There is a real time EPOC for Ambits provided through app, it’s one of those special ones under Suunto Apps category that comes without a source - http://www.movescount.com/apps/app10049649-Real_time_EPOC
This also provides a graph on a watch and additional EPOC graph in Movescount.
They had enough trust in this to add it as a feature in product specs , but I don’t think I’ve ever tested this against MC generated values.

Interesting to see that Ambit3 running performance data stream is actually sent to Suunto App, though there’s no performance graph and only Performance value is displayed.

I haven’t checked if/how custom Ambit app data is handled by Suunto App, but I’m afraid it’s just dropped. And as there’s no running perf graph even though that data stream is sent out to the service, its probably same for custom app data as well. Otherwise this might provide a way to store EPOC-ish data from Ambits.

lexterm77 · 30 Apr 2020, 02:53

There is a document on how epoc is calculated at https://assets.firstbeat.com/firstbeat/uploads/2015/10/white_paper_epoc.pdf

There is an Ambit app that uses stryd power reading to calculate your energy efficiency similar to the running performance on ambit which was far more accurate than relying on gps data.

http://www.movescount.com/apps/app10645993-Average_energy_efficiency

Notice the level of filtering on Ambits Running Performance graph relying on gps vs the energy efficiency app relying on power data.

By the time you notice changes in Running performance graph to figure out whether you have proper hydration or enough carbs; energy efficiency app would react much sooner as it gets its data from accelerometers vs. gps and barometer on watch used by running performance. Your body makes subtle changes to adapt to current situation, it does not think about finishing line, thats what brain is for (or not). The sooner you notice the sooner you can react because physiological response to recover gets Progressively slower the father you fall in anaerobic energy debt.

Constantly changing wind speeds would render ascent descent baro sensor data invalid even on a flat surface no matter ambit or s9.

Epoc modeling has a delay, see white paper, basically loose ohr or belt ruins it.

Real time running economy would react sooner than any other method. Your model is based on power, sensor will not become loose or fall off (less likely than belt or ohr)

Or better yet, Having a small “sandbox“ for custom equations and graphs sent to SA from s9 like we did on Ambit To MC would stop avalanche of nagging user requests to add features. It would also let us innovate without consuming other peoples time on development. Few 32 bit floating data as temporary registers to implement equations is not much of a footprint these days. Add a few kb of data to support at 10s logging interval. It would just be much more fun even if it fed you meaningless numbers.