New review on HRV as a marker for exercise intensity

Sorry, I fixed the PM.

If you don't mind, the gas exchange is instructive for folks out there and I will comment here.  Using the excess CO2 method, here is the graph (look in the link for more info on how to do this)

It actually looks like a textbook calculation of the VT1, better than many I've done.  The heart rate is about 150 and the VO2 2.52 L/min.  The power calculation is a bit problematic since it's such a fast rising ramp.  Although it works out to 250 watts, it can be way lower due to something called the mean response time.  I'm surprised they did such a rapid ramp on you.  Typically it would be 10 watts per minute, not 25w/min.  The VO2 max should be valid.

Now on to the HRV.  Here things are not good.  Although your ramp is well done, the artifacts are quite high.  I did not do any detailed analysis (garbage in - garbage out).  Here is the Kubios "time varying" plot.  The artifacts listed are not accurate in auto correction mode. Here they are in threshold:

DFA a1 in black, avg HR in blue.

Note the initial green arrow down then up for the DFA a1, that should not happen although occasionally it does (see below).  After that it does drop again, but the artifacts are too high to get an accurate picture.  However, clearly at the end of the test you were low in the .5 range (red circle).

Here is an example of something I'm working on now, a patient with heart failure, as the heart rate rises, the DFA a1 declines and we figure  a corresponding HR value by using an equation.  There is a slight plateau in there but overall the linearity is good.

Bottom line - just repeat your ramp and we will take a look.  Gas exchange looks solid but is a short test and the VT1 cycling power is "artificially" high.

This was very insightful, thank you! I will re-do the test and use conductive gel next time to minimize the artifacts. HR strap is H10. Power at VT1 seems quite high as my FTP is around 280W at 165 bpm. On the other hand, I was aiming for several seasons to improve my aerobic base and get VT1 in VT2-10% area. So from this standpoint, it could be indeed near 250W. If I compare it with my interval sessions, cycling in sweetspot around 250-260W does result in HR around 150 bpm.

The H10 is a solid unit but it suffers from artifact in some people.  Your power at VT1 is not the power corresponding to that time of the test.  As I mentioned, the MRT shifts the curve depending on ramp rate of increase.  At the rate you did it could be 20 watts or so.  Juan Murias and his group have published extensively on this if you are interested (see the link above).  Even if your VT1 is 230 watts, that's still excellent.  FTP is a good index as well but is also protocol dependent.

Besides doing a ramp to determine your HRV threshold, just looking at your training session can be helpful.  Take a look at Figure 3 in our Frontiers article.  This method is great for enforcing polarized training.  Unfortunately, you would need to upgrade to Kubios premium to do that.

Our validation study for DFA a1 usage as a surrogate for VT1 has just been published in Frontiers in Physiology.  I have some more details in my blog and some "how to" info.  In addition, Marco Altini has incorporated this into his HRV monitoring software.

I've done my first practical DFA a1 test today via HRV Logger after following your research and articles. Do you think it would be worthwhile to implement live DFA a1 data as a Garmin data field, or would that be too problematic because of potential artifacts with end-user HR straps?

With my Polar H9 and the default HRV Logger settings, I am not seeing significant artifacts in Kubios Free from my data.

A few comments.  HRV logger RR data is already "cleaned" of artifact, so you will not see any artifact in Kubios.  To get an idea of the true artifact percentage, look at the .fit file from the Garmin device.  Since you have the H9, you can use ANT+ to the Garmin and bluetooth to the logger. 

Can a mobile Garmin device implement a DFA a1 data field?  You would either need to load the python libraries used by HRV Logger or code from scratch.  I'm not sure the CPU or RAM is there to do it.  I know the Suunto people are looking at it - www.muscleoxygentraining.com/.../dfa-a1-calculation-kubios-vs-python.html for their products. 

Yes, it would be great if Garmin picked this up, even if it they needed two way communication to your smartphone to do the math.

Finally, how did the test go?

Yes, noticed the default cleaning of HRV logger by now. The originally recorded artifact percentage is of course significant:


Altough, the artifact cleaning algorithms not neccessarily need be too complex. In the simplest form (https://github.com/alan-couzens/python_for_coaches/blob/0c71cc5c6e1641ddfa950038d0e9ec30e25f3415/get_hrv_data_from_fit_file.py#L35):

More sophisticated versions also entail "only" a few dozens of lines of code, e.g. along https://github.com/GoldenCheetah/GoldenCheetah/blob/master/src/FileIO/FilterHRV.cpp 

https://github.com/MarcusVollmer/HRV/blob/58badf917cecd1490c1955fc61a0bc1a55736aa3/HRV.m#L1211 could provide for a middle ground in terms of complexity of filtering artifacts.

I'll look into the quoted Python based example implementations regardin DFA a1 to get an idea about complexity and feasibilty for mobile Garmin devices. Being quite fresh to Garmin MonkeyC programming having implemented my first data-field recording %HRR/%6minMMP ratio about a month ago, I already can tell that those libraries would need to be ported from different programming languages.

Regarding the actual test ride and recording: I expected to get the DFA alpha1 closer to 0.75 much earlier than I did as I was riding around VT1 (from my last lap test). Not before the lead-in to a final sprint I did get it below 0.75.

I'm affraid the CPU performance would be the biggest problem. (If we somehow reduce artifacts to low levels) CPU would have to calculate FFT in real time. F6, FR945 all struggles with less resource demanding tasks like rolling average values, etc. If one puts more of these into custom CIQ field.