A question about RHR setting being overwritten by data from Garmin:
I’m only using my Garmin watch when exercising so my daily RHR estimate is always way too high (it is calculated using the lowest 30 minute average in a 24 hour period). I do run Health Snapshot in the mornings to track RHR and HRV instead.
I’m syncing wellness data including Resting HR from Garmin into Intervals.icu, it works fine and I can plot Resting HR (Snapshot) in the Intervals.icu. However for Resting HR in the Settings my RHR gets regularly updated to daily RHR from Garmin (so it’s always too high).
Is this RHR setting important? The note says “Intervals.icu uses your resting HR when calculating training load using HRSS” - so it looks like it is?
Is there any way to discard daily RHR updates from Garmin in Intervals.icu and sync RHR from snapshots at the same time?
If it’s not possible, should I change load training load method from HRSS to something else (I’m mostly doing hill running)?
Hi David, thanks for the reply and sorry for my delay in responding, I’ve been offline for the holidays.
I understand that my case may be not very common, so I don’t know what’s the best way to make it work. Personally I’d prefer to have an option to disable RHR updates from Garmin overwriting RHR in Settings - I’d set it manually and leave it as is, it does not change too much to affect training load calculations.
Another option would be to be have separate Garmin sync options for snapshot and daily data (I’d keep syncing snapshot values but disable syncing daily data).
Morning RHR measured manually (a good proxy for how well rested the athlete is in the morning) – either synched (as a Garmin Health Snapshot, HRV4training CSV, etc), input manually into a field of choice, or tracked entirely outside of Intervals.
Same might apply to HRV data points – one might be an overnight average provided by the wearable, another a morning seated (standing for elites) measurement, some (Gordo Byrn being one example) like to take a 2nd manual measurement in the afternoon… there is also something to be said for the 24h Average Stress computed from Garmin as a proxy for all-day HRV. All of them could be equally useful to a power user.
I’ll hazard introducing some (a lot of?) scope creep by embiggening the problem – what if both of those issues (and many others) are a result of a rigid approach to data field mapping and de-duping during sync?
@david - What if the user was given the ability to pick not only which metrics get pulled from which data source, but also which fields in Intervals they get put into (including custom ones!) and what the conversion logic is?
I know this would have far-reaching repercussions, including the potential to utterly break things for folks who aren’t careful, so it’s probably best hidden in the bowels of Settings behind a couple disclaimers, but worth a consideration?
This is spot on @DesertUnicorn. I’ve had a similar thought on my list to post. I am one of those athletes who likes to look at RHR from different perspectives as you describe. Besides doing a seated RHR and HRV in the morning [HRV4 Training], I also do an orthostatic i.e. lying HR at end of 2 min, stand up and measure peak HR, standing HR at end of 2 min, I enter these values manually into custom Wellness fields in Intervals. Also enter into Excel where I do some calculations for example rate of HR decrease from max standing to end of 2 min standing. I don’t believe it’s not currently possible to do calculated values on Wellness data, hence I use Excel.
I have thought about this a bit and came to a similar conclusion to you. Best would be storing everything in separate fields and then settings to decide which of the several RHR fields (or whatever) get mapped to the “default” RHR that goes on activities and so on.
This would need to be part of a biggish wellness refactor. I would probably also just do the basics (resting HR, resting HR sleeping, resting HR snapshot) and then choose which gets used for resting HR. This stuff quickly gets out of hand (HRV …).
A few have asked similar questions recently (links below).