Detailed Topic Index

Saturday, May 22, 2021

Best practices for Runalyze and DFA a1 thresholds

Added 8/2023 - Ramp slope and HRV a1 thresholds - does it matter?

Added 10/23 - 

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:



  • 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.


  • 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.


  • 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


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

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

    1. Do you mean the hrvt2 and SmO2 breakpoints? I did a post on that awhile back.
      It's a difficult goal. You need near artifact free H10 data and good quality nirs readings.

    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)

    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.

    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.

  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.

    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?

  4. Hi - thanks for sharing all the info on aerobic threshold calculation. Have tried following your suggested runalyze protocol and just trying to get comfortable with accuracy of results - would be very grateful if you found a moment to comment as I'm very much at beginning stage of learning about this. Did ramp test: +5w every 1min for 30min (100-250w, the latter being ~my FTP) and using bluetooth HRM - artifacts showing in runalyze at 0.9%. What is making me unsure about validity of results is that DFA-a1 data point are grouped for periods above and below 0.75 - broadly, below for 170-190w then above for 190-210w then below for 210-230w then above for 230-240w then below after that. I guess I expected DFA-a1 to broadly stay below 0.75 after a certain power level (accepting a few outlier data points). So, worried about how that data looks and also previously using Marco Altini's app and just looking at how DFA-a1 lines up with power/HR data, Runanalyzer estimates for AeT seem quite a bit higher than that. Interested to know if you think the profile of my dataset seems valid? Thanks

  5. Hi, why don't you send me a link to the raw file (RRs if possible). Sometimes the artifact correction is better with Kubios premium and we will get a better looking result.

    1. Thanks for getting back to me and offering to take a look at the file. Do you just mean the .fit file, or something else (I ask because I notice that runalyze offers csv and json exports of the data). And how best to get it to you? Thanks again

    2. The .fit file would be the best (raw RR data including artifact)

  6. Hello, I have also did a progressive ramp test. starting at 100w 6w increase a minute. So after 20min I was at 220W. I normally would do 25min but not enough time so I stopped at 20min. But now I get the message "The estimation results are not feasible.". My LT1 was 145BPM and power was 220W. So? Maybe I should do the test again with an extra 5min?

    1. It's difficult for me to say why - maybe you did not drop a1 low enough for a good regression

    2. I think this is the case because I stopped at 220W and the analyze gave 220W as LT1 power. I think I will do the test again with extra 5 or 10min...

    3. Is there a difference in doing an incremental ramp-up (in zwift) by 5w/min or use a 6min interval ramp up by 30W?

    4. Yes, there may be. The 6 min stage test was suggested to compensate for the limitations of hrv logger (only displays every 2 min). It will not give you a linear vo2 rise. If you can, use a zwift ramp. However, you can try 10w per minute.

  7. I’ve had similar issues to Chowders in that I can’t seem to get my DFA to drop significantly below 0.7, despite getting my HR up to 180. I analyzed the data with Runalyze, and the relationship between my DFA a1 and HR doesn’t appear to be linear. Rather, every time I drop near the 0,75 range, I cycle back up to the 1,0 range prior to coming back down again, and continue to follow this pattern for the remainder of the ramp test. I used HRV logger with 6 min intervals on a treadmill and increased my pace by 0,5 Km/hr with every step, removing any warmup or cool down periods prior to merging the .csv file. The strap was a Polar H10 and I checked that the strap gave me nice tall R waves by using the ECG Recorder and ECG Logger apps prior to starting.

    That being said, the ramp was done prior to my knowing how to use Runalyze, so it may not have been optimal with respect to avoiding scatter. Still, I would have thought that I’d have been able to at least get some values close to 0.6 at a heart rate of 180 bpm. Nevertheless, I’ll give it another shot tomorrow, this time using a dynamic cycling ramp on Zwift (100 watts in 20 min). I’ll only record the ramp, and will re-analyze the Runalyze csv file using the excel method you recently wrote about in order to remove any cluster of elevated DFA values that may be present at the start of the ramp. Given this plan, would you recommend I disable the “R-R intervals correction” in HRV Logger and solely rely on Runalyze for any artifact correction?

    Any other tips? I’d really like this method to work as it’s so much easier than testing lactate which can also be quite finicky. I’m also interested in seeing if DFA a1 can be applied clinically in a critical care setting, but first things first :)

  8. Sorry to hear that you are having difficulty. Artifact correction is a potential reason to see what you are describing. Why don't you turn off the correction, record the raw data and send me a link. I'll take a look in kubios.

  9. First of all, I wanna say that a1=0.75 is pretty close to my aerobic threshold. What I observe though, my HR range between a1=1 and 0.75 is very small, I would say within 5-10 beats. Is this how it is supposed to be?

  10. Sure can - it is the same with me

  11. Hi, just quick question. i just did a test. I was using Garmin Edge 530 and Polar H9 monitor. To extract my LT i use Butr it shows me that my data have only 24% of data valid. And avg artifacts is 4.9%. any sugestions why? I will try to replace battery in my H9, but something else what i can do?

  12. A few different thoughts - 1) The percent valid on runalyze refers to the SDNN and artifact thresholds seen under Results/Settings. I would have SDNN set for a higher value than their default but artifact should stay about 3%. As far as why the artifacts are high - without an ECG we can't really know. There are ways to get an ECG from the H10 but not the H9. Take a look at this for more details and the links at the top of the post -

    1. Thank you, changing to the H10 resolve problem. Now i have 0.3% so it is no bad i think.