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

Disable Lactate Threshold auto detect

The Edge 530 has a Lactate Threshold Heart Rate auto detect feature, however it appears to be completely broken. I chatted with Inder from Garmin Support and they recommended disabling the auto detect feature for now. And they're going to submit a request to the developers to either remove it, or at least document it better.

It order to disable it go to: Menu, My Stats, Training Zones, Heart Rate Zones, Lactate Threshold, Auto Detect LTHR. You can set it manually to the correct value if you like, but generally it's better to use FTP for cycling instead of LTHR. 

Normally my Forerunner 935 auto detects my LTHR at about 177 bpm after maximum effort running activities, which seems correct. However my Edge 530 auto detects my LTHR at about 46 bpm which is obviously wrong. I am using the latest firmware version 5.00 and measuring heart rate with an HRM-Tri strap. The 530 does record correct heart rate data for my cycling activities, it's just the LTHR auto detect which doesn't work.

The same defect likely impacts the other 30 series devices.

  • Lol about the countries, maybe there is some sponsorship money involved! :D

    I thought there was a decline option for a new LTHR, but to be honest I haven't had one of those popup either in a long time, probably since 2020. I actually had to verify today that the auto LTHR detection was even enabled.

    I'm just realizing too that when I typed my reply it was mostly the FTP detection I had in mind. That one "should" be relatively straightforward since it's mainly based on the power data. It's the one that made the most sense too in the situation you described.

    As for the LTHR though, I just honestly don't know. After Garmin bought FirstBeat I hoped that maybe they would be more open about the underlying science they use but maybe that was just wishful thinking. I honestly haven't pursued the topic much more because once I satisfied myself that there was a lotttt of uncertainty in their models, I sort of stopped relying on it. Their descriptions suggest that they really stretch their empirical data. They test individuals and observe trends, looks for things that they believe correlate (such as HRV), and then extrapolate that to apply it to the entire world's population with some fudge factors applied to account for age, gender, activity level, etc. Anytime I ever sent specific questions to FirstBeat or Garmin I only got more vague answers.

    So for me, FTP seems useable. But LTHR and VO2Max..., ehhhh, pretty to look at but I really don't know. Actually I think I read some critiques that the VO2max estimates tend to be way off actual test results. Likewise I don't know if I can trust Training Effect, which is what I spent most of my time analyzing and ultimately gave up, though I did learn some things about how they calculate it. The fact that it's hard-coded with some straight lines that just automatically increase with time, and then suddenly slow down at specific values like 2.0, 2.5, etc., make it seem really sketchy to me.

  • Anytime I ever sent specific questions to FirstBeat or Garmin I only got more vague answers.

    I gave up almost a decade ago to ask Garmin about this sort of questions related to deeper layer of knowledge.

    But 2-3 years ago when I had a Fenix 5+ and was shocked that calorie expenditure in kcal was calculated simply as being equal to work in kJ if you had a powermeter on your bike instead of the Firstbeat calorie expenditure model (including hrv on/off) described in their document I sent requests to FB, and indeed I get no valuable answers.

    I guess they had Garmin not just as a client, so did not want to elaborate whether Garmin misapplied their algorithms or mot, but I guess it was a time when they were a out to be bought by Garmin.

    And since then FB=Garmin as regards corporate policy on comms with user.

    So I also gave up. I understood it is not their model to have sophisticated users with questions.

  • Garmin only uses FirstBeat for heartrate-derived metrics. Power-derived metrics are separate (note anaerobic training effect needs both).

    So things like normalized power, intensity factor, training stress score, calories, these are all from power data, and Garmin doesn't need FirstBeat for those. We can actually calculate these ourselves because the formulae are not secret. (I run a ConnectIQ app that does this in real-time on my Edge 530, so that the data appears in a graph in Garmin Connect. It lets me see how those values change during a ride, not just the final value that GC shows in the summary.)

    Things like load, training effect, VO2max, training status, these are estimated from heartrate data. It's this batch of metrics that use the secret sauce FirstBeat algorithms, and there doesn't seem to be much clarity around how they work, or how reliable or useful they are.

    Anyhow I only mention all this to say that it is no surprise that Garmin does not use FirstBeat to calculate calories, because they don't need to when they have power data available directly. (And if the user does not have power data, they could roughly estimate calories in a similar way to Strava based on the route. I think this is what they do, but I haven't checked it in a long time since I added a power meter.)

    Sadly FirstBeat's publications and so-called white papers seem to be little more than marketing brochures. And I agree this is a very disappointing situation.

  • So things like normalized power, intensity factor, training stress score, calories, these are all from power data, and Garmin doesn't need FirstBeat for those. We can actually calculate these ourselves because the formulae are not secret.”


    I see it differently. And I know that I am in a minority here among users with my opinion.

    You can calculate work in kJ easily, because the formula is rigid and unquestionable since it is based on basic physics. But you cannot do the same with calories in kcal unless you use some metabolic assumption (so part of the formula comes not from physics, but exercise physiology), namely a fix/constant metabolic efficiency being the same for everybody, which is far, far, far from reality.

    I had this argument with FB  and the confirmed that I was right, they also thought that both gross and net ME varied much more among individuals and also due to other factors like cadence or power-level than the error coming from their HR+HRV model.

    Actually while I had this battle regarding my F5+ (maybe also when I had used F3HR earlier) and the algorithm was never fixed, I realized that Edge 530 does not simply say that calories should come from work data directly. My F6X still thinks at, or at least thought a year ago when I tested it. 

    So my bet is that in the background the FB guys convince the cycling/fitness team while they did not contact or failed with the outdoor team.

    Or another possibility: the latest outdoor watches like F7 and Epix 2 use the same calories calculation as Edge 530/830.

    EDIT

    ADDITIONAL NOTE: I remember that 2.5-3 years ago users said that calories came from power if a powermeter was present. At that time I had no 530 yet. But since many months calories are calculated in a different way. Maybe not exactly in the same way as for activities without a powermeter, maybe, but I am more than sure that it does not come from power, because for a long while work does not equal to calories. Just check any of your cycling activities recorded by 530 in 2022. If you had it 3 years ago already then you can check  it also whether fellow users were right then or not. 

    I am going to try to look for the thread I referred to research papers on ME in cycling….

  • So things like normalized power, intensity factor, training stress score, calories, these are all from power data, and Garmin doesn't need FirstBeat for those. We can actually calculate these ourselves because the formulae are not secret.”


    I see it differently. And I know that I am in a minority here among users with my opinion.

    You can calculate work in kJ easily, because the formula is rigid and unquestionable since it is based on basic physics. But you cannot do the same with calories in kcal unless you use some metabolic assumption (so part of the formula comes not from physics, but exercise physiology), namely a fix/constant metabolic efficiency being the same for everybody, which is far, far, far from reality.

    I had this argument with FB  and the confirmed that I was right, they also thought that both gross and net ME varied much more among individuals and also due to other factors like cadence or power-level than the error coming from their HR+HRV model.

    Actually while I had this battle regarding my F5+ (maybe also when I had used F3HR earlier) and the algorithm was never fixed, I realized that Edge 530 does not simply say that calories should come from work data directly. My F6X still thinks at, or at least thought a year ago when I tested it. 

    So my bet is that in the background the FB guys convince the cycling/fitness team while they did not contact or failed with the outdoor team.

    Or another possibility: the latest outdoor watches like F7 and Epix 2 use the same calories calculation as Edge 530/830.

    EDIT

    ADDITIONAL NOTE: I remember that 2.5-3 years ago users said that calories came from power if a powermeter was present. At that time I had no 530 yet. But since many months calories are calculated in a different way. Maybe not exactly in the same way as for activities without a powermeter, maybe, but I am more than sure that it does not come from power, because for a long while work does not equal to calories. Just check any of your cycling activities recorded by 530 in 2022. If you had it 3 years ago already then you can check  it also whether fellow users were right then or not. 

    I am going to try to look for the thread I referred to research papers on ME in cycling….

    EDIT 2:

    here we go: https://forums.garmin.com/outdoor-recreation/outdoor-recreation/f/fenix-5-series/141473/does-garmin-use-firstbeat-calorie-calc-method-when-biking-w-a-powermeter-paired#pifragment-1292=1

    At that time I used a nick of Tisztul_A_Visztula

  • The older thread you linked is very interesting! Certainly it reminds me of some issues I've encountered as well with the Edge series, specifically a lack of consistency and... "cohesiveness"(?) among their various metrics. They seem to be a really mixed bag thrown together, maybe even contradict each other. The marketing push around the newer devices this year is that a lot of that has been improved so that it's easier for the user to understand and use. I'm curious to see how that works out..., and whether the "easier to use" data is actually reasonable and reliable!

    Sorry yes I misunderstood your earlier post about calories, meaning energy expenditure not actual work done. I do recall a while ago encountering similar. I've looked at it again in my data and here is what I see:

    - Until 12 Jun 2021, Garmin Connect shows my "Total Calories Burned" almost equal (numerically) to the Work. For example, my activity that day shows 1749 Cal (kcal) vs 1753 kJ work. Since 1753 kJ = 419 Cal, then it suggests Garmin applied an overall efficiency of about 24% on that ride (=419 / 1749), which as you mentioned is in the average range for efficiency, but which can vary widely(!!).

    - Beginning on 13 June 2021, Garmin Connect shows a much larger difference in numerical value between Total Calories Burned and Work (and the same is seen echoed over on Strava). My activity shows 1377 Cal and 1196 kJ. Following the math, it suddenly suggests my efficiency is down to 20.8%.

    - Sometime between 27 Jun and 14 Jul 2021 (unfortunately I have no activities in between because I was busy selling my apartment), the system changed again. "Total Calories Burned" is now supplemented with values for "Resting Calories" and "Active Calories" (Resting + Active = Total). The Active value is again nearly equal (numerically) to the Work value. My activity of 14 July shows 183 Resting + 1170 Active = 1353 Total Calories Burned and 1170 kJ Work. With this presentation of the data (still in place today), the efficiency between Active and Work is back to 24%.

    So it seems that in June 2021 Garmin rolled out an update to begin accounting for resting Calories (which I understand to be the Calories that your body consumes by simply being alive), though I'm really not sure what value this serves since it's the Active Calories we're interested in. In any case, the Active Calories remains roughly similar (numerically) to the Work in kJ, giving that same efficiency of about 24%.

    So the appearance that the Active Calories is nearly numerically equal to the Work in kJ may be just coincidence. The bigger concern is like you mentioned elsewhere, that it seems to imply they are using a fixed efficiency value (~24%) for all users under all conditions, which is susceptible to a lot of error. Personally I have always assumed that any Calorie estimate was very rough and I didn't put a ton of faith in it anyhow. But you're right, if a better method is claimed to exist from FirstBeat (assuming it is indeed better), then why didn't they implement it. Personally I think it goes back to the mixed bag comment I made at start of my message, this is simply how it got thrown together during production.

    Of course we would hope for a lot better from such a major company on such relatively expensive products, that puts so much marketing emphasis on exactly these features. It really strains credibility with users.

  • The Active value is again nearly equal (numerically) to the Work value. My activity of 14 July shows 183 Resting + 1170 Active = 1353 Total Calories Burned and 1170 kJ Work. With this presentation of the data (still in place today), the efficiency between Active and Work is back to 24%.

    Thanks for adding the concept of Active and Resting Cal) and for correcting me.

    Something I mixed. I will check it, because I do remenber that kcal was different from kJ.

    Maybe I was kooking it on the display of 530 (and not in GCM post-ride) not knowing yet that there was this new concept, or I mixed the story and F6X calculates it as if there was nothing to do with power.

    My problem is that I have no recent fit files of cycling saved by F6X not to confuse training load with double recording, perhaps I found some older…..

  • Maybe not directly related to this, but definitely similar. I found this thread very interesting. 

    I have ALL (Regular, Sport-Cycling, Sport-Running) heart rate zones set to be based on %LTHR. I am mostly a cyclist, so I do that more than I run. My watch (Epix V2) continually reverts to having my Cycling Heart Rate Zones be based on %HRR, with those also being wildly off. I'll be in the middle of a workout, heart rate ~150 and its still showing in the bottom of Zone 1. I can go into the settings during the workout and change the setting for that sport HR zone to be based on %LTHR, but its pretty annoying to be mid workout and not know what my HR zones are at the start. I am always using the HRM-Pro when working out. My regular Zones and Running Zones do not change what they are based on (as best I can tell).

    Has anyone else seen this or know why it might be happening?

    Settings:

    • Auto Detection is ON for Max HR, Threshold, FTP

    • Resting HR ~56 (auto detect while sleeping)

    • Max HR: 188, this has auto-adjusted a few times

    • Manually Set LTHR at 169 (this has never auto-changed) based on age/ body composition

  • Hi @RedWonder you may want to try turning off the auto detection for max HR to see if it stops this issue of resetting your zones.

    There "was" a major issue with auto detection for Max HR, LTHR, and FTP on the Edges (130 and 530 in my case). When a new value was detected, the device would reset the user's zones incorrectly. There were 3 cases I encountered:

    - If new LTHR detected and I use zones based on %LTHR, it would leave all the HR zone bpm values the same and change the zones' % values instead. In other words, it didn't update the zones at all.

    - Similarly if new FTP detected, it would leave all power zone watt values the same and change the zones' % values instead, again not updating the zones at all.

    - Finally (the worst one), if new max HR detected (zones still based on %LTHR), it would change all HR zone % values to 10% increments (the default) and make new HR zone bpm values based on those % values of the new max HR. Total mess.

    So basically, none of the autodetects were handled correctly, and I disabled them.

    Since that time, it seems that the issues have been fixed by firmware updates. I do not recall having any more issues with auto detect for LTHR or FTP messing up my zones (but I still check them rigorously after every autodetection to be sure!). However I do not have max HR detection enabled currently, and I can't recall if I tested it to confirm that it's okay now.

    It's possible that your Epix V2 might have a similar-ish issue, though I'm not sure if it's related to autodetections, or it's simply screwing up your zones for some other reason. Some things you can try include disabling the autodetections (especially for max HR, which generally wouldn't change much) to see if the issue goes away.

    Another idea is to leave autodetections enabled, manually set your HR max, LTHR, or FTP to a lower value (I suggest trying only one at a time), and then do a ride that triggers an autodetect, and note what happens to your zones in the device after that. (This approach was repeatable for me when I was submitting the issue to Garmin support.)

    Also note in my case I only have a single device (Edge 530) and I only use the default zone profile. I have not added any extra "run" or "cycle" profiles as you have. (At one point Garmin/FirstBeat told me I needed to create a cycle profile for things to work correctly, but that made no sense to me since it's a cycling device and the default should be fine, so I ignored it.) Since you are both multi-profile and multi-device, there might be a possibility that the combination is causing the issue. It's definitely a pain to test the combinations, and meanwhile it's polluting your metrics (training effect, training status, etc) which can't be reversed or corrected.