As always : you’re the man ! Thank you !
Hi David,
I just looked into the “Streams CSV” data of the Interval tab and found these entries for the hrv:
time,watts,cadence,heartrate,distance,velocity_smooth,temp,torque,hrv
0,119,44,83,5.26,5.263,22,26,
1,120,44,83,10.49,5.225,22,26,731
2,121,44,82,15.84,5.356,22,26,735:731
3,121,44,82,21.24,5.393,22,26,717
4,121,44,83,26.64,5.393,22,26,717
What is meant by the : notation?
Sometimes there are also three numbers:
266,240,73,114,2403.86,8.976,19,31,524:526:524
Thanks! Flo
Here are some reading material on the :notation, it’s basically successive R-R intervals.
https://forums.garmin.com/developer/fit-sdk/f/discussion/255690/fit-file-hrv-data-array-interpretation
The RR data is mapped to the same time ticks as power, HR etc so sometimes there are multiple measurements if your HR is more than 60 bpm. I intend to do some DFA1 stuff with this at some point and it is useful to be able to plot it along with power etc…
Why the value of 0.75 SD specifically? Any reference for this? This would mean that only a bit more than ~50% of the data points fall within this interval, which doesn’t seem a lot? Thanks!
@david it would be great to have the option to log-transform (I guess a natural log ln) the rMSSD data in intervals.icu and the associated transformations (7d cv%, sd of moving averages, …) - seems a lot of the dedicated HRV tools out there are doing this one way or another for good reasons indicated above in this thread.
Anyway, having this data in is already again a great improvement in an already great tool. Thanks @david!
This is an excellent explanation of the factors that can influence HRV readings, but it omits a couple of the most crucial variables, how the reading is taken, and the data acquisition equipment.
Taking a valid reading for HRV is very similar to taking a blood pressure measurement. The subject must be completely relaxed, in a calm state, and not involved in any other activity. Not talking, not watching TV, not working.
It’s best to take the reading first thing in the morning. A reading that approximates the subject’s resting heart rate will be a good reading. But the best conditions for taking a reading are not the same for everyone, and people need to experiment whether they get their best reading sitting in a comfortable chair, on a yoga mat, or lying down.
The data acquisition equipment determines the data quality, and for consumer devices the Polar H9 and H10 set the standard. This article is an independent evaluation of the H10.
HRV is formulated on the inter-beat interval between heartbeats measured in milliseconds. Very few consumer devices are able to measure at this level of accuracy, and the data are compromised with reduced levels of accuracy.
The distance between the device and the heart can also compromise data quality, which is why chest strap heart rate monitors are the standard in consumer devices.
It is important to determine the baseline HRV before trying to interpret results. Changes in diet, stress, stimulants (coffee and alcohol), sleep, exercise, and stress will all have varying degrees of influence on the reading. A determined effort to control the variables that are controllable (sleep, diet, exercise, stimulants) will help to build a solid baseline on which readings can be measured.
Obviously, over an extended period of time, the baseline will reveal itself - but most people want to get an understanding of their results before then.
It’s the most recent I found on Marco’s blog. He started using 1 SD and 30-day avg but modified that to 60-day avg and 0.75 SD a bit later. But be aware that HRV4Training puts more emphasis on the 7-day Baseline iso the daily HRV value. Those results are combined with CV, subjective scores and a mathemaical analysis of “recent trend”. Recent trend of RHR, HRV and CV are calculated by applying a linear trendline to the last 14 day values. The slope of that trendline indicates stable, positive or negative trend. There again, anything within 1SD is considered trivial.
iThlete is giving more importance to daily HRV and uses +/- 1SD for HRV and +1.7/-2SD for RHR around the 30-day avg as a “Normal” condition.
I can’t tell you which one is the right one. I’m just a guy who is very intrested in this HRV thing and spending loads of time reading about it and trying to understand.
Marco Altini, Alan Couzens, Andrew Flatt, Daniel Plews are some of the more intresting guys doing research around resting HRV and training advice.
There is a tendency on using 2 or 20 x Ln RMSSD because that gives you a result that looks scaled to 10 or 100 respectively. HRV4Training uses 2, iThlete uses 20.
It doesn’t really matter what you use for most basic HRV interpretation but in some literature there are absolute % values for CV. In that case it is important to know if they are using RMSSD or a natural log of it.
I agree with all you’re saying but I can’t repeat this on every post regarding HRV. The fundamentals of getting a correct reading can be found in this 4-part series on HRV:
https://medium.com/@altini_marco/the-ultimate-guide-to-heart-rate-variability-hrv-part-1-70a0a392fff4
I’m just trying to give a comprehensive overview of all I’ve read.
My comments are from the analysis of the data, interaction with users of the HRV Health system, as research on the comprehensive literature on the subject.
For example, this morning one of the HRV Health’s users had a rMSSD reading of 43. Other data in the reading indicated that she was not completely relaxed, and we advocated taking another reading while she was completely relaxed. That resulted in an rMSSD of 85. These are significant differences.
And now the first Connect IQ datafield for DFA-a1 is born…
Review by Bruce
The datafield itself
Tested it today and from a user point of view it works flawless. BLE or ANT+.
Don’t have a comparison yet with Fatmaxxer results but will do in the next couple of days.
Great Tool, thanks for sharing!
But the pairing / connecting is realy realy complicated… take me some time, and now sometimes it works, sometimes not… why doesn’t it just use the paired heart rate monitor with the garmine device as every other app???
Well, it depends on how much knowledge/experience you have with pairing devices.
You need to think of it as if it where 2 separate devices, each using their way of communicating with the HRM.
I agree that the explanation on the IQ app page isn’t the most user friendly, but Bruce explains it pretty clear.
I think it is brilliant that you can choose yourself what protocol you want to use for both the device and the app. That gives a lot of flexibility.
I’m using BLE to the Edge for regular heartbeat and RR intervals, saved in the FIT file. That gives best results for post-ride analysis.
And the app uses ANT+ as communication channel for Live View and saves it in a dev field in the FIT.
But you could just as well do it the other way round.
I used the following method to pair my H10 HR strap
-
sync H10 & Garmin via BLE
-
remove Garmin 530/830/1030 connection to H10 via ANT+
-
open IQ Alpha - go to settings - enable “connect via ANT+ to Hear Rate monitor”
-
Re-pair the h10 HR in the sensor bit of settings on my Garmin 530.
If I didn’t do the latter stage it would revert to Alpha HRV working but HR in all my other apps not. Now both work though I think the alpha hrs is slightly off for me at the moment. I guess accuracy will improve as more people use it
@MedTechCD + @Dave_Reed thanks for help, thats the way i did it know (Garmin via BLE and alphaHRV via ANT+)… works so far.
so now @david … if the DFA Alpha1 values are now saved in the .fit-file (via Datafield alphaHRV) it should be possible to show it in intervals.icu, am i correct?
as i can also see them now in the Garmin Connect App
+++ to see the EPOC values in intervals.icu would also be great!
(collected by this datafield for example: Connect IQ Store | Free Watch Faces and Apps | Garmin)
Thanks so far!
Can you clarify what the “sync H10 & Garmin via BLE” step was? In the end did you have IQ Alpha connected via Ant+ & the H10 paired to the Garmin via BLE?
Those are both “dev fields” in the FIT file and need some work to get displayed. @david already has the implementation of dfa-a1 post-ride calculation on the todo list (based on the robust Fatmaxxer code). Implementing this one too would mean 2 dfa-a1 graphs. It’s probabaly possible but it’s david’s call.
If a choice has to be made, I would prefer the post ride calculation from the RR intervals recorded on the unit. The app is nice for real-time feedback.
About the app: I tested latest version 0.9.6 against Fatmaxxer and can tell you that artefact correction isn’t working yet. Artefacts detected and filtered by Fatmaxxer are not detected in alphaHRV app. I could see that because I had both running next to each other. Result from the app is that every artefact causes dfa to jump all over the place for a window of 200-220 beats while Fatmaxxer filters out the artefacts completely.
But I’m sure the app will improve over the next weeks.
Pretty sure that’s what he meant. I have it like that.
when I say sync H10 and Garmin via BLE step, I mean in the Settings/Sensor page on the Garmin. I deleted the h10 sensor and then re-found it and then added it. At the end I had the Alpha HRV connected via Ant+ and the H10 paired to the Garmin via BLE