This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Heart rate zones in Garmin Connect Web

Hi all, I am trying to understand how the below values are being calculated. 

Just to make an example, have for today's run the following "time at zones" values:

Z5 0% 

Z4 26%

Z3 30%

Z2 32%

Z1 9%

And in this case, in the HR zones I can see 3,3 z ave HR, 4,9 z max HR. How these values are calculated?  

Thanks!

  • Just one point, how to define intervals. For example, for Z4 interval, why we consider (Z5 min - Z4 min) and not (Z4 max - Z4 min) it's more logical to me, without creating overlapping.

    Yes I agree that Z4 max - Z4 min is more logical. To explain why I used Z5 min - Z4 min instead, I will echo what trux said and add:

    Historically, Garmin has actually presented your zone BPM ranges in 2 ways: with and without overlapping.

    1) In the (old) HR zone settings [**] where you could see both % and BPM at the same time, with overlapping (without gaps). e.g. My real zones would've looked like this:

    Z1: 123-137
    Z2: 137-151

    2) In the time in zones chart, without overlapping (with gaps). e.g. For my real zones:

    Z1: 123-136
    Z2: 137-151

    It is worth noting that the new settings based on BPM show non-overlapping ranges as in 2).

    I think 1) (overlapping zones) makes more sense mathematically [*], but end users may find it confusing, which is why Garmin went with 2) (non-overlapping zones) for the time in zones chart.

    [*] For example, if my average HR is 136.5, then by 2), it is in neither zone 1 nor 2, but by 1) it is clearly in zone 1.

    If you use the overlapping zone ranges from 1), then Z4 max is the same as Z5 min, and Z4 max - Z4 min is the same as Z5 min - Z4 min, so it doesn't matter which one you use.

    If you use the non-overlapping zone ranges from 2), then you must use Z5 min - Z4 min for the Z4 calculation.

    I think Garmin actually uses overlapping zones internally (this can be seen in a few technical ways, by looking at the Connect IQ SDK or analyzing activity FIT files). Internally, zones actually look like this:

    Z1 min, Z1 max,  Z2 max, Z3 max, Z4 max, Z5 max (max HR)

    (Ofc these could also be interpreted as half open ranges - ultimately I don't think it matters.)

    --

    [**]

    The old HR zone settings (available on the Connect website for older devices) actually would've looked something like this, which pretty much shows overlapping zones:

           %HRR / BPM
        ...

       |--- 70% / 151
    Z2 |               
       |--- 60% / 137
    Z1 |             
       |--- 50% / 123

  • One problem with 1) (overlapping zones) is that if a value is on the border of 2 zones (like 137), which zone range is it in?

    If you use fractional zones, then the fractional zone for 137 is always 2.0 whether you assume 137 is in Z1 or Z2:

    Assume 137 is in Z1 and use the overlapping zones:

    Z1min + 1.0 + fractional_zone * (Z1max - Z1min) = 137
    fractional_zone = 1.0 + (137 - z1min) / (Z1max - z1min)
    fractional_zone = 1.0 + (137 - 123) / (137 -123)
    fractional_zone = 1.0 + 1
    fractional_zone = 2.0

    Assume 137 is in Z2 and use the overlapping zones:

    Z2min + 2.0 + fractional_zone * (Z2max - Z2min) = 137
    fractional_zone = 2.0 + (137 - z2min) / (Z2max - z2min)
    fractional_zone = 2.0 + (137 - 137) / (151 - 137)
    fractional_zone = 2.0 + 0

    fractional_zone = 2.0

    (Either calculation would also work if you used the non-overlapping zones, but ofc you'd have to adjust the formulas)

    In other words, in terms of fractional zones, 137 would be "100% into Z1",  "0% into Z2", or 2.0.

    If you use integer zones, you could just Garmin's non-overlapping presentation and say that 137 is in zone 2 (which also makes a lot of sense given that the fractional zone is 2.0)

  • I will also say that for fractional zones, there a couple of uncertainties:

    - For 0.x (HR lower than zone 1), it's not clear what "zone 0 min" is (I *think* it might be a fixed value like 30, the minimum hr that Garmin watches will measure)

    - For 6.x (HR higher than max HR), it's not clear what "zone 6 max" is. (Note that zone 5 max is your max HR in user profile). I *think* it might be 220 or some other arbitrary absolutely max HR.

    If you ever have examples of these (0.x should actually be easy because your recovery HR "fractional zone" will almost certainly be less than 1.0 *), you can calculate these unknown constants yourself.

    [*] Ofc it makes little sense to present recovery HR as a "fractional zone", since it's not an absolute HR measurement but a relative calculation (the difference between HR measurements when you stop exercising and 2 minutes later), and HR zones only make sense for absolute HR measurements, but Garmin does it anyway....

    EDIT I did the math and it looks like:

    - "zone 0 min" is actually 0 (or maybe 1)

    - there is no zone 6 max, because if you exceed your max HR, Garmin just displays 6.0 anyway, even though it will show "% of Max" as being higher than 100%.

  • Thank you for the good discussions! My time zone is actually non-overlapped but as far as I understand it's preferable to set with overlapping. BTW, overlapping should not be an issue if we assume that 137.0 is Z1 and 137.1 is Z2.

    Z1=123-137 intended defined as max 137.0

    Z2=137-151 intended defined as min 137.1

    Thanks, ciao

  • My time zone is actually non-overlapped but as far as I understand it's preferable to set with overlapping.

    I was saying that Garmin presents HR zone BPM ranges to the user as non-overlapped (or 1 bpm apart), but internally / mathematically Garmin's zones are overlapping (or touching). And in the past, Garmin actually showed HR zones as overlapping in the Connect website HR zones settings (which don't exist for newer devices).

    You cannot actually *set* your zones with overlapping BPM, although if you set your zones by % (% HRR or % max HR), you will see that the percentages are overlapping, which proves my point.

    For example, I set my zones by %HRR, and these are the default ranges in settings (User Profile > Zones):

    Z5: 90% - 100%
    Z4: 80% - 90%
    Z3: 70% - 80%
    Z2: 60% - 70%
    Z1: 50% - 60%

    Z1=123-137 intended defined as max 137.0

    Z2=137-151 intended defined as min 137.1

    Not exactly. Think of it this way - Garmin shows the following ranges in the HR time in zones chart:

    Z1 = 123-136
    Z2 = 137-151

    But actually it means:

    123 ≤ Z1 < 137
    137 ≤ Z2 < 151

    Z1 max and Z2 min are both 137, but if your HR is exactly 137, then you're in Z2 (both by the above definition and the fractional zone calculations).

    In other words, if your HR is on the border of 2 zones, then the higher zone applies. So actually, Garmin's non-overlapping zone presentation is correct as long as your HR is an integer (and since we don't really ever see or care about fractional heart rates, that's just fine).

    It's similar to tax brackets. Tax brackets are often defined with overlapping ranges. You might see progressive tax brackets defined like this (fake example):

    $0 - $10,000: 0%
    $10,000 - $50,000: 10%
    $50,000 - $75,000: 20%
    ...

    But what if my income is exactly on the border of 2 brackets, like $50,000? Am I in the 10% bracket or the the 20% bracket? It doesn't matter, because of the formula that's used to calculate your taxes. In the case of tax brackets, only the income that *exceeds* the minimum value for a bracket is taxed at that bracket's level. So If you make exactly $50,000, then $50,000 - $50,000 = $0 of your income is taxed at 20%. In this case, if your income is on the border of 2 brackets, the lower bracket applies.

    Again it's better for the ranges to overlap like this because it takes care of all possible cases of fractional amounts.

    The average person who is not too interested in numbers / math will ofc not really understand why the ranges overlap, which is why Garmin presents HR zone BPM ranges as non-overlapping (but they can't do that with the % ranges, because a difference of 1% won't be exactly 1 BPM, and that would mess up the BPM ranges).

  • Sorry, I admit I made a mistake because effectively my time zone (%) is actually set as overlapped (I wrote non-overlapped). 

    I readr carefully and I think your explanation

    Z1 = 123-136 --> 123 ≤ Z1 < 137
    Z2 = 137-151 --> 137 ≤ Z2 < 151

    is quite well explaining. 

    Just one question: you say that Garmin presents HR zone BPM ranges to the user as non-overlapped (or 1 bpm apart), but internally / mathematically Garmin's zones are overlapping (or touching). 

    But If I see the math your wrote:

    Z1 = 123-136 --> 123 ≤ Z1 < 137
    Z2 = 137-151 --> 137 ≤ Z2 < 151

    The two zones are at the end non overlapped as well, are they not Garmin's internal zones assumptions?

    Again, thank you! 



  • The two zones are at the end non overlapped as well, are they not Garmin's internal zones assumptions?

    No, the zones are continuous. If they use classic rounding then they are

    122.5000000... (rounded to 123) » 136.49999999... (rounded to 136) and
    136.5000000... (rounded to 137) » 151.49999999... (rounded to 151)

    Theys could also use FLOOR or CEIL conversion to integer, but the principle is the same - there are no gaps between the zones

  • No, the zones are continuous. If they use classic rounding then they are

    122.5000000... (rounded to 123) » 136.49999999... (rounded to 136) and
    136.5000000... (rounded to 137) » 151.49999999... (rounded to 151)

    I really don't want to belabour the point, but in the FIT file (and I assume internally), adjacent HR zones actually share a single value at the border, just like this little diagram I posted above, which shows how my zones would've looked in Garmin Connect's old HR zones settings, which displayed BPM and % at the same time:

           %HRR / BPM
        ...

       |--- 70% / 151
    Z2 |               
       |--- 60% / 137
    Z1 |             
       |--- 50% / 123

    So actually, there are not separate values in the FIT file (and I assume internally) for Z1max and Z2min, for example.

    As I said above, if a 3rd-party Connect IQ app queries the user's current HR zones, they get back the following values:

    Z1 min, Z1 max, Z2 max, Z3 max, Z4 max, Z5 max (max HR)

    I also don't see any reason for the boundaries to actually be fractional as in your example. The boundaries could very well be rounded to the nearest integer (in BPM), without changing any of the assumptions or the math).

    I actually think it makes more sense for the zones to be exactly as I said:

    123 ≤ Z1 < 137
    137 ≤ Z2 < 151

    In other words, if an avg HR of 136.75 was calculated, that should be in Z1 (and it would be, based on the fractional HR zone formula that I guessed), not in Z2 as per your zones whose boundaries lie on *.5. Then again, if 136.75 is rounded to 137 before being converted to a "fractional zone", then it would be in Z2. I'm guessing that probably how it works in practice, but I don't think it matters so much. With that in mind, I see your point about how the zones could be considered to be anchored at values of *.5, but that seems like more of an implementation detail.

    [1/2]

  • To drive home the point, here are the zones that were recorded to the FIT file for a recent run. Again, only Z1 min, Z1 max, Z2 max, Z3 max, Z4 max, and Z5 max are represented in the file. Note that these are indeed integers.

    Ofc nothing stops Garmin from taking these numbers and internally using them anyway they want.

    They could in fact take these numbers to represent zones such as:

    122.5000000... » 136.49999999... 
    136.5000000... » 151.49999999

    But I really don't think they do (unless you consider that it could be that way as an implementation detail, as mentioned above). (But that implementation detail would only be necessary if in fact there were 2 separate values internally at borders - one for Z1 max and one for Z2 min, for example, and I don't think there needs to be.)

    I think the simplest answer of looking at it that my zones are actually:

           %HRR / BPM

       |-- 100% / 195
    Z5 |               
       |--- 90% / 181
    Z4 |               
       |--- 80% / 166

    Z3 |               
       |--- 70% / 152
    Z2 |               
       |--- 60% / 137
    Z1 |             
       |--- 50% / 123

    If I could see them in the old Connect website HR zones settings page (not available for new devices), I think that's exactly what it would look like. 

    Note that these zones are a little different than what I said before, since the watch detected a slightly lower max HR (195) for me than was previously set.

    To write these zones differently (making the equalities at the borders explicit)

    123  Z1 < 137  Z2 < 152 ≤ Z3 < 166 ≤ Z4 ≤ 181 ≤ Z5 < 195

    Again I am assuming that if a HR value is on a border (like 137), then it belongs to the higher HR zone (in this case, Z2). This at least matches the fractional HR formula that I guessed, and it also matches Garmin's presentation of the zones in BPM where adjacent zones are separated by 1 BPM (e.g. my time in zones chart shows zones like 123-136, 137 - 151, etc.).

    In the end it doesn't matter. I think we all agree that the zones are actually continuous, which is especially obvious if you use % zones, as in % max HR or % HRR. In this case, Garmin shows continuous/touching/pseudo-overlapping ranges in the settings such as 50%-60%, 60%-70%, etc, for the reason that I said above. (It wouldn't work with ranges like 50% - 59%, 60% - 69%, for example, because then you'd have something other than 1 BPM of separation between adjacent zones)

    But it doesn't matter so much when you look at BPM values, because Connect never shows fractional BPM values. Internally, any BPM that is recorded to the FIT file is an integer if I'm not mistaken, and any average that is taken is rounded for dispaly.

    And I mentioned the formula for calculating fractional zone, which was the point of this thread in the first place. At least that formula works for me. Here's the formula in general:

    For a given heart rate H (in bpm), the corresponding "fractional zone" X.Y (where X and Y are integers) is given by:

    fractional_hr_zone = X + (H - zone_X_min) / (zone_(X+1)_min -  zone_X_min), where X is such that zone_X_min ≤ H ≤ zone_(X+1)_min)

    Here I have chosen to write the formula so it would work with either the (supposed) internal continuous ranges, or the user-visible ranges which are separated by 1 bpm.

    I could be wrong ofc, since all of this is an educated guess. But it's the simplest explanation (to me, anyway).

    And maybe the details don't really matter, so long as we understand that a fractional zone of 4.5 (for example) means that you are halfway (50%) between zone 4 min and zone 5 min.

    Similarly, 3.3 means you are 30% between zone 3 min and zone 4 min.

    [2/2]

  • As I said above, if a 3rd-party Connect IQ app queries the user's current HR zones, they get back the following values:

    Z1 min, Z1 max, Z2 max, Z3 max, Z4 max, Z5 max (max HR)

    https://developer.garmin.com/connect-iq/api-docs/Toybox/UserProfile.html#getHeartRateZones-instance_function 

    getHeartRateZones(sport as UserProfile.SportHrZone) as Lang.Array<Lang.Number>

    Retrieve an Array of the current heart rate zone threshold values in beats per minute (bpm)

    The returned Array contains zone values as follows:

    min zone 1 - The minimum heart rate threshold for zone 1

    max zone 1 - The maximum heart rate threshold for zone 1

    max zone 2 - The maximum heart rate threshold for zone 2

    max zone 3 - The maximum heart rate threshold for zone 3

    max zone 4 - The maximum heart rate threshold for zone 4

    max zone 5 - The maximum heart rate threshold for zone 5

    There's no need for the API to return min zone 2 [for example], because it's understood to be the same as max zone 1. [Ofc the docs don't really explain whether a value on a border of 2 zones actually belongs to the lower or the higher zone, which is a shame]