Saturday, May 22, 2021

Best practices for Runalyze and DFA a1 thresholds

As previously discussed, the web service Runalyze provides a helpful tracking feature of DFA a1 over time.  Moreover, it allows one to recalculate the index repeatedly over a user defined time span such as 5 seconds as we do in our studies.  Only Kubios premium can come close to that!  Another potentially useful feature is that the web app will automatically calculate your HRVT based on DFA a1 vs power or heart rate.  I would like to suggest some "best practices" to make this as accurate as possible for the aim of threshold determination.

Prerequisites - accurate HRM such as a Polar H10 in bluetooth mode to a recording unit (Garmin watch, HRV logger with artifact correction off, Ipbike with HRV enabled, etc).  

The ramp:

We want a progressive ramp with a reasonable dynamic range of DFA a1.  In other words we want to start with high values (>1) and end up at or below .5.  The VO2 rise should also be somewhat linear - we don't want too much time spent at a given power with a steady VO2.  Why?  As noted in some older posts, there is variation in the a1 resembling a "normal distribution" around the AeT/VT1:

The above was my data from a previous long cycling session (>1 hr) just below the AeT.  There would be a notable a1 bounce from .5 to 1.25 if I did a prolonged interval at this intensity.  Therefore, we want to have a progressive and significant rise in power/intensity to avoid this scatter.

Another example comes from our Frontiers study using Sander Berk's 6 minute data intervals.  Notice the point spread at each intensity point (circles).  

Luckily, he increased the power by 30 watts after each 6 minute interval so the overlap is not severe.  But if one were to minimally raise power by just a few watts (and only have a few sample points every 2 minutes in Logger), you can see how difficult it would be to plot a line through the points.

If you are going to use the 6 minute intervals (as suggested for a real time approach), use at least a 20 watt separation.  Below is a plot of 6 minute intervals that I did recently.  My HRVT is usually about 205 watts.  There is a red line at the a1 = .75 mark.  The plot agrees with my historic DFA a1 with values above .75 at a power below the HRVT, and a1 below .75 at the 230w power level.  There will be fluctuation especially if an artifact is present.



Suggested Runalyze ramp:

Between 5 and 10w per minute rise over 10 to 20 minutes.  This can be done manually as "step" intervals (130, 160, 190, 210w ..etc) with a change every 3 minutes or just use Zwift to create a incremental ramp (example - 130 to 230w over 20 minutes = 5w/min).

Optimizing Runalyze output:

A key component of getting accurate HRVT results from the web app is to record the ramp and only the ramp as a discrete session.  In other words, don't record the warm up or post ramp exercise.  The warm up will be skewed to the higher a1 range and the post session could have HIT/post HIT contamination.  After a HIT interval, the a1 will stay low for a variable time at easy power levels - we don't want that to interfere in our HRVT plot.

Once we get our ramp done, it's time to go to the "settings" for Runalyze to process the data - don't use the default.  We want to get a granular output with plenty of a1 points - to produce the every 5 second recalculation we need to set the window overlap field (in yellow) to 115.


 

Artifact correction is also very important.  Even one APC can mess up the a1 and ruin our threshold plot.  The yellow line above should be set for .01, not .10.

Here is an example of an otherwise perfect ramp marred by 1 APC that escaped correction:

 

With a more aggressive correction (.01), the plot is now fine for HRVT:

Let's now see how Runalyze stacks up to Kubios using the same data.  

Entire ramp:

  • There is a bit of deviation early on, but the lower, nadir values are very similar (they were not in previous versions).
  • Overall, a good enough agreement, especially in the 1.0 to .5 range.

What about the thresholds?

HRVT heart rate:
 



  • The HRVT heart rates are within 1 bpm of each other - excellent!
 

However, the official Runalyze plot yields a bit different result:


Why?


 

  • Probably because they incorporate values from the start of the ramp.  Perhaps they can address that in the future.  We do not want those "flat", unchanging data points (red circle) at the ramp beginning.
  • However, all in all - still very close to our hand calculations.

HRVT power

This is where Runalyze really shines - it gives us a power estimation. Since they have a comprehensive tracking database of all the metrics involved, power is displayed as well.



  • There is only a 7 watt differential which is trivial in my opinion.

Their plot does show a close value as well:


  • Although a bit skewed by that initial flat section, still overall an excellent estimate.
  • Since one is able to download the data as a .csv, recalculation to your hearts content is possible.
 

A friends data:

To make the comparisons more appropriate, I've included some fresh data done by a friend.  This was taken from a cycling ramp, 7.5w/min using a Polar H10 with bluetooth pairing.  Only 2 artifacts were present in the entire series.  We will compare the Kubios vs Runalyze data and HRVTs.

Entire ramp session:


  • Excellent agreement between methods, especially at the .75 level and below.
  • Nice, linear HR rise in the area of interest.

HRVT HR


  • Each HRVT (using similar data points for plotting) yields values with 2 bpm of each other.
  • I analyzed another ramp for this athlete recently, and the HRVT HR using Kubios was an identical 144 bpm.

HRVT power:


  • HRVT power is with 5 watts of each other - again a very close fit.


Conclusions:

  • The Runalyze developer team has really nailed the DFA a1 accuracy to a very close approximation of Kubios premium, and in a web based package.  This means it's possible to do a ramp, have automatic .fit file transfer from Garmin, then simply look at the HRVT on your smartphone browser (that's what I do).
  • For best and most accurate results, try to keep artifacts down and only use dedicated ramps for HRVT assessment.  In fact, make sure your ramp does not have a lengthy, flat DFA a1 phase like I had above.  Until that is addressed, a progressive a1 drop would yield the most precise HRVT done by Runalyze.  Of course, if you are doing the HRVT line plotting by hand, you can just skip that part of the data.
  • Try to avoid very long, "stagnant" interval steps.  We want a steady rise in VO2 (or HR) in order to not get that point scatter noted above.
  • My compliments to the Runalyze team for a fantastic job.  Given the computational power issues and programming constraints, the current implementation is an excellent compromise in accuracy and usability.
  • No other current solution is able to automatically calculate your HRVT heart rate and cycling power (including Kubios) from a ramp file.  
  • I strongly urge users to support the site by becoming members so as to encourage further development and improvements.  Considering the up front and yearly maintenance fees of Kubios premium, this is a steal.


Heart rate variability during dynamic exercise



8 comments:

  1. Yup, i instantly paid.
    Good stuff. Excited to see where this leads to.

    ReplyDelete
  2. Btw am I the only one who is curious how this correlates with moxy data?

    ReplyDelete
    Replies
    1. Do you mean the hrvt2 and SmO2 breakpoints? I did a post on that awhile back.
      http://www.muscleoxygentraining.com/2021/04/dfa-a1-and-hrvt2-vt2lt2.html?m=1
      It's a difficult goal. You need near artifact free H10 data and good quality nirs readings.

      Delete
    2. We don't have an IQ field for DFA1, i was simply wondering what the correlation would be between power/hr/dfa/smo2. (i'm nothing but an amateur, just pure interest)

      Delete
    3. As power rises. there will be a SmO2 breakpoint at the second threshold but not at the first. The DFA a1 will be about .75 at the first and .5 at the second threshold (with excellent quality recordings). Yes, no a1 data field but I don't think a watch can do the heavy computation to easily do that.

      Delete
    4. To be honest, there's no need to have relative dfa when you can use runalyze and Golden Cheetah to get a ballpark number to go by. I'm planning on doing some ramps this weekend, so maybe I can share my data from my metabolic cart and Moxy's.

      Delete
  3. Hi, just want to pass along that Golden Cheetah has a chart to estimate power and pace from dfa, similar to runalyze. It's based on Marco Altini's original Python script and works nicely.

    ReplyDelete
    Replies
    1. Nice to hear, thanks. I will say that the new Runalyze computation method is perhaps closer to kubios than the original python version. The issue was with something called "detrending" (unrelated to DFA). Have you done any comparisons?

      Delete