Heart Rate Variability Logger is a mobile app that lets you record, plot and export time, frequency domain and non-linear HRV Features. It is typically used in research studies and for self-experimentation
Heart Rate Variability Logger requires a Bluetooth Low Energy (also called Bluetooth Smart or BLE or 4.0) heart rate sensor (we recommend Polar H7 or H10)
Main features:
Extracts, plots, stores and exports heart rate, RR-intervals, time and frequency domain heart rate variability features (AVNN, SDNN, rMSSD, pNN50, LF, HF, LF/HF, alpha 1 from DFA)
Configurable experience sampling for events annotation
Comparison between up to 3 recordings lets you get a better understanding of differences in HRV under different contexts in a glance. The comparison modality includes also Outlier removal
Activity tracking: step counter or accelerometer derived motion intensity for user context (step counter only for iPhones 5S)
Location tracking, either using GSM/WiFi networks (low battery consumption) or GPS (high accuracy)
Configurable time window for features computation (choose between 30 seconds, 1, 2 or 5 minutes)
RR-intervals correction can be enabled to prevent ectopic beats or artifacts from affecting HRV features
Export for Kubios
Filters data based on the selected threshold
Data export using email, iTunes or Dropbox
No backend or remote database, all data is stored only locally in the app
HOW SHOULD I CONFIGURE THE TIME WINDOW AND ARTIFACT CORRECTION THRESHOLD?
Optimal parameters configuration is essential for HRV analysis. However, each application requires different considerations and therefore a different configuration, and there are no universal optimal parameters
In particular, for resting measurements we recommend:
window size between 1 and 5 minutes if interested in time domain features, or between 2 and 5 minutes for any other feature
artifact correction set to 25%, which will be able to get rid of most issues with ectopic beats
For biofeedback or deep breathing:
window size between 2 and 5 minutes as breathing rate enters the low frequency band, which requires at least 2 minutes of data for a meaningful assessment
correction disabled, as deep breathing elicitates large beat to beat variations that would otherwise be overcorrected. Make sure to inspect the data afterwards for artifacts
For exercise data and aerobic threshold estimation:
window size of 2 minutes for DFA (see additional FAQ below)
correction set to "workout" mode, which is equivalent to 5%, as there is very little variability when heart rate is high, so being more strict allows for more accurate assessments
WHAT SENSOR SHOULD I USE?
Very few sensors on the market satisfy the two requirements for usage with the HRV Logger (and in general for HRV analysis):
Comply to the standard Bluetooth heart rate profile. This means that the sensor can talk to a third party app, and not only to the app of the sensor manufacturer (this is the case for a Polar strap, but not for an Apple Watch for example)
Provide accurate RR intervals
Similarly to what we have reported in the previous question, the right sensor will also depend on the application of interest
In particular, for resting measurements or biofeedback we recommend:
Polar chest straps (H7, H9 or H10)
Scosche Rhythm24 (armband), in HRV mode. Note that HRV mode will work only if you are completely still, so this cannot be used reliably during exercise. You can find a comparison here
Corsense finger sensor, which also works reliably when not moving. You can find a comparison here
For exercise data and aerobic threshold estimation:
Polar chest straps
What about other chest straps? Currently, Garmin dual straps seem to work as good as the Polar ones. Tickr HR straps have provided mixed results, some users reported high quality data, while others had many artifacts or inaccurate data. Thus, we would recommend if possible to use Polar straps
Why can't I use the APple Watch with THE HRV Logger?
Unfortunately the Apple Watch does not comply to the standard Bluetooth heart rate profile, meaning that no third party app can collect data in real time. Additionally, the Apple Watch (just like all other optical or PPG based sensors) cannot provide accurate RR intervals during exercise (but only heart rate)
While the Apple Watch can work quite well for heart rate during exercise, this is not the same as providing accurate beat to beat (RR) intervals for HRV analysis, which is currently not possible with any sensor that is not a chest strap or ECG
If you are instead interested in using the Apple Watch for resting measurement, the only workaround given that the watch does not communicate according to standard protocols, is to use the Breathe app to record data to the Health app, and then use another app to read that data from Health, at the end of the short measurement. This is outside of the scope of the HRV Logger, which is meant to be used for real time measurements. However, you can use HRV4Training for measurements of resting physiology using the Apple Watch, as explained in detail here
How does the timestamping work?
The Bluetooth protocol has limitations, meaning that it does not timestamp data, but simply sends packets, approximately every second. Within each packet, we can potentially have multiple RR intervals (depending on the heart rate, as a heart rate above 60 will result from more than 1 beat or RR interval per second)
Hence, we need to come up with a way to timestamp data so that you can compute HRV features for a given time window, and we do so by summing up RR intervals over time
In the exported RR intervals file, you will find a since_start column, which starts with the first RR interval, and then we sum up each consecutive RR interval. Note that if there are gaps or artifacts, those will be removed already, so the since_start column (which is in milliseconds) might diverge from the date or timestamp column after a while
Thus, the way we recommend to analyze RR intervals for further analysis if you are not using the features already computed in the app, is the following:
annotate when you have a relevant task, for example you might have started a test at 17:04 and collected data for 5 minutes
grab all the data that is included in that range, according to the date or timestamp column, which represents real time but has nothing to do with RR intervals
then take all the RR intervals within that time window, and use the RR values or the since_start column for HRV computations
What is included in the data export?
The data export includes 4 files:
Heart rate: typically averaged over the past 15-30 seconds depending on the sensor used
RR intervals: all RR intervals sent by the sensor, unless artifact removal is enabled. In this case, only clean RR intervals are exported
Features: time, frequency and non-linear features computed over the selected time computation window
Events: any annotated events
How Should I configure the HRV Logger for aerobic threshold analysis?
In order to use the HRV Logger for aerobic threshold estimation, please do the following:
Set artifact correction to “Workout” and feature computation window to “2 minutes” in the app Settings
Link your chest strap, we highly recommend a Polar strap for this test
Run or cycle. Either a rather constant easy effort or an easy progression are ideal for this kind of analysis. Short intervals or frequent changes in intensity should not be used for this test as at least 2 minutes of stable data are required
Your aerobic threshold should be at alpha 1 = 0.75, as reported in the app’s HRV features and also in real-time. Efforts harder than your aerobic threshold will result in lower alpha 1 values, while easier efforts will results in alpha 1 values higher than 0.75. Please note that while this is what the researchers suggest, large individual variability is present, and therefore this method can lead to large errors for the individual.
What's a good protocol to analyze alpha 1 FOR AEROBIC THRESHOLD ANALYSIS?
We recommend either a rather constant easy effort or an easy progression are ideal for this kind of analysis. Short intervals or frequent changes in intensity should not be used for this test as at least 2 minutes of stable data are required
Normally, we would recommend to increase intensity in small steps, and hold a certain intensity for 6-8 minutes, before progressing. This is normally feasible as the intensities covered are always relatively easy, since we are talking about the aerobic (not anaerobic) threshold
An alternative is to try a few workouts at a constant effort, and then analyze the data and look at the alpha 1 values. You can find an example from ultrarunner Daniel Rowland, here
What's noisy data?
Artifacts create large issues in HRV analysis. Sometimes artifacts can come from actual ectopic beats, while other times it could simply be that the strap is dry or there is a motion artifact. Regardless of the cause, artifacts will have a dramatic effect on HRV analysis, causing the resulting features to be extremely inaccurate (you can learn more about artifacts and artifact removal, here)
In order to allow for a more meaningful analysis of your data, the HRV Logger not only can remove artifacts based on what you configure under settings, but can also keep track of how many artifacts were removed
Why is this important? Keeping track of how many artifacts were removed is indicative of the quality of the data. If we removed a lot of artifacts, most likely the data was poor quality, and therefore should be discarded. By selecting "hide noisy data" in the app, you will be looking only at windows that included less than 10 artifacts
Please note that if you keep artifact correction disabled, artifacts can still be present, but will not be reported as no artifact is removed with this modality. Normally you can visually identify artifacts in the RR intervals view, as they will look like clear outliers in the time series (much higher or lower values with respect to the ones nearby)
How are features computed?
Time domain features are computed according to their standard definitions, which is very straightforward and does not depend on any other parameter
For frequency domain features and DFA alpha 1, the implementation can be done in different ways, all mathematically correct, but which might lead to slightly different results. For example, frequency domain features can be analyzed with different windowing, the RR intervals can be interpolated using different methods, and the power spectrum can be estimated with different methods as well. All of these options are correct, but lead to differences when comparing different implementations. This is why it is sometimes difficult to compare studies reporting frequency domain features, while it is easier to compare time domain features.
The same is true for DFA alpha 1. When implementing this method we have many degrees of freedom, from a set of pre-defined parameters (window size and range), to other mathematically valid ways to implement the different steps, for example in terms of artifact removal, re-interpolation, how to split the data when computing the residuals, etc.
The best we can do in this case is to be clear about the steps we take, so that they can be reproduced and investigated systematically
Therefore here below we report how we compute frequency domain features:
Collect all RR intervals in a time window (unit is in milliseconds)
Interpolate RR intervals at 4Hz (so 1 point every 250 ms, this is necessary since RR intervals are not evenly spaced in time, and we need evenly spaced data in order to perform frequency domain analysis)
Remove the DC component, then we convert into seconds
Compute hamming windowing on the time series resulting from previous steps
Perform FFT
Compute frequency power for the 2 bands of interest (LF and HF).
While for DFA alpha 1, we provide the source code from which the app implementation is derived, here
In the context of aerobic threshold estimation, Bruce Rogers has highlighted how at high intensities the HRV Logger might report slightly less suppressed values, in some individuals. We hope to be able to analyze these differences more systematically in the future, so that results shown in literature can be more easily matched to what you can record with available tools, such as the HRV Logger
You can find Bruce's review of the HRV Logger here. Check this post for some examples of potential differences between the HRV Logger and Kubios, which use different implementations to determine alpha 1
Features requests
For features requests, please use this google form. Thank you