Update 3/23/22 - As discussed in this post,
alternate preprocessing methods other than the type used in Kubios
(detrending method - smoothness priors) may lead to DFA a1 results that
are different than seen with Kubios software. HRV logger does use an alternate method. Therefore,
results may not agree well with published studies. If possible, a secondary check using Runalyze, AIenduance or Fatmaxxer is recommended.
Over the past several months both a perspective review and validation study have been published detailing the usage of the HRV index DFA a1 as a potential means of defining the aerobic threshold for zone 1 training purposes. Ideally, a real time look at this index would be quite helpful. Since it is dimensionless and already "calibrated" to exercise effort, it should be able to inform the athlete about their current intensity load. The iPhone/iPad app, HRV logger was recently upgraded to take advantage of this scenario. The following post is an introductory look at how HRV Logger stacks up to Kubios in terms of DFA a1 during an exercise ramp. In a previous post we looked at a comparison of the python based algorithm used in HRV Logger to that of Kubios and they were very close. However, the question is how well the app will do when presented with the usual artifacts seen with moderate exercise as well as usability issues.
Test setup and settings: After a 20 minute warmup, a cycling ramp was done (Zwift controlled) from 130 to 230 watts (5w/min). The app settings were a 20% artifact threshold and 2 minute measurement windows. A Polar H10 chest belt was used with concurrent recording to a Garmin watch.
Before going over the results, a look at artifact correction effects should be done. HRV Logger does correct for artifact. This entails finding aberrant beats based on timing errors, then inserting a beat based on an educated guess (most commonly simple linear interpolation). That usually works well especially for as missed beat, but not so well for APCs (since they may not flag as an error given the close timing to "normal"). Below is my ramp, first with "threshold correction" then with the newer "auto" correction (premium version only).
Notice the yellowed area (caused by 1 APC on each section), there is a dramatic drop that is not present in the "auto" corrected mode:
If your tracing does not contain beats such as this, there won't be an issue with "threshold" type corrections. However, if it does - be aware of this issue.
Lets' now look at my ramp comparing Kubios (extracted from Polar H10 to Garmin .fit then processed with Kubios auto correction method) vs HRV Logger (Polar H10 to ipad mini running HRV Logger):
The green line is heart rate, showing the rise during the ramp. Blue is Kubios output (2 min windows but recalculation every 5 sec) and red is HRV Logger (2 min windows without overlapping recalculation). For the most part, the agreement seems quite good. The output of HRV Logger has timing markers but not matching HR per measurement window so I matched up as well as I could, but it could be off several seconds.
Getting back to the comparison, look at the circle I placed around the comment - (possible artifact). That corresponds to the drop in DFA a1 seen with the Kubios threshold correction (which is why I went to trouble of explaining this).
Why is that drop important to note? If one were using this as a monitor of intensity during an exercise session, certain degrees and types of artifact can alter the DFA a1 value substantially. Therefore if values suddenly don't make sense, consider the above possibility.
How well does HRV logger correct for missed beat artifact? Actually very well! Below is a Kubios tracing of the "cleaned" RR values from HRV Logger (using HRV Logger correction) alongside the raw Garmin data (using Kubios auto correction). This was done over 2 hours including a ramp and some HIT intervals. Unfortunately, I used the wrong window setting (30s instead of 2 min) so the DFA a1 values are not valid and not shown.
What this tells us is that the HRV Logger is able to handle moderate artifacts as well as the Kubios threshold method. At very high artifact levels (seen at high HR), or during an APC activity the Kubios "auto" method may be better (but only available in the costly premium version).
The heart rate variability threshold (aerobic threshold surrogate) calculation between the Kubios data and HRV Logger were very close:Here we are graphing DFA a1 over time. Since we know the cycling power over time, the point at which DFA a1 crosses .75 can be back calculated and converted into watts. Although it would have been nice to have more points to play with, the Logger is within just several watts to that of Kubios.
- HRV Logger for iOS devices is a powerful and generally accurate means of measuring DFA a1 in real time or in a retrospective manner.
- Artifact correction is similar to the "threshold" method of Kubios. However, both methods are prone to error with even 1 or 2 atrial premature beats. When doing a session, be mindful of a sudden drop of DFA a1 then a rise at the same exercise intensity.
- Price point? A steal! Kubios premium is about 400$ initially then 80$ a year. Sure, you could use the free version but still not get real time DFA a1 on a mobile device.
- Separation of measurement window choice (should be 2 min) with "grid interval" (rolling recalculation time). I know the app can handle a recalculation every 30 seconds since I used that already (but that time is too short for measurement accuracy). Finer granularity in ramp or constant power sessions is helpful for aerobic threshold determination and was our method of choice in the validation study. In fact, I think we were the first to use this technique.
- Real time and historic graphing of HR and DFA a1. Since many users will be runners, knowing heart rate "breakpoints" would be helpful. Having the DFA a1 and HR side by side on the same graph and .CSV would facilitate that. This is not as needed using a bike on a trainer doing constant power intervals.
- Indication of degree of artifact per measurement window. High artifact associated data should be suspect even with correction.
- Perhaps some UI changes to account for usage either riding on a bike or running. Note should be made that the DFA a1 concept was added on to an app that is mainly used at rest. Hopefully the developer will consider a spinoff app aimed as a real time DFA a1 display with appropriate additional metrics for both threshold concepts and training intensity monitoring.