Garmin to add Aerobic Swim Threshold & Blood Glucose Measurements


Garmin to add Aerobic Swim Threshold & Blood Glucose Measurements to Connect


Eagle-eyed sleuth @JohnW has, once again, spied some interesting new additions to the Garmin Connect app, this time it’s linked to swimming zones and blood glucose both of which could have important ramifications for many of us.

Aerobic Swim Threshold

Garmin already allows you to determine your Critical Swim Speed (CSS) with a test and which it defines as

the theoretical fastest pace that a swimmer can maintain continuously without exhaustion…Your CSS is computed using your time for a 400 m or yard time trial, and your time for a 200 m or yard time trial.

However, the addition of a new measure, Swimming Aerobic Threshold, implies that Garmin might be looking at automatically adding HR zones for swimming based on a heart rate derived from your CSS efforts.

For several years I’ve used the ‘Secondary’ heart rate zone for swimming heart rate in addition to the two zones for running and cycling as, for me, the three are quite different. Maybe Garmin is formalising heart rate zones for triathletes and adding a dedicated zone for swimming? Maybe they plan to then add more analysis and insight to swimming efforts like, for example, combining training load together differently for all 3 sports. Perhaps not as the three are not really additive!

Or it could simply be CSS described differently as a threshold speed.

Either way, it’s a heads-up for something potentially interesting in the next few weeks.

Blood Glucose Measurements

More: Detailed Supersapiens Review

The addition of blood glucose measurements is less of a surprise and their addition could be to support either consumer data or athlete data (or both).

In October last year, Garmin added CIQ (app-level) support for the Dexcom G6 Continuous Glucose Monitor (CGM) System and Supersapiens also has special integration with CIQ components and their blood glucose sensor (Abbot Libre).

It’s more likely that is a deepening of the medical/wellness side of things than of the athletic realm due to the Dexcom announcement.

It could even herald an eventual addition of a blood glucose ANT+ profile which would cover both wellness-medical and sports needs?

Source code from Garmin Connect:

<string name=”lbl_milligrams_per_decilitre”>milligrams per decilitre</string>

<string name=”lbl_millimoles_per_litre”>millimoles per litre</string>

<string name=”lbl_swimming_aerobic_threshold”>Swimming Aerobic Threshold</string>

Reader-Powered Content

This content is not sponsored. It’s mostly me behind the labour of love which is this site and I appreciate everyone who follows, subscribes or Buys Me A Coffee ❤️ Alternatively please buy the reviewed product from my partners. Thank you! FTC: Affiliate Disclosure: Links pay commission. As an Amazon Associate, I earn from qualifying purchases.

6 thoughts on “Garmin to add Aerobic Swim Threshold & Blood Glucose Measurements

  1. It seems improbable that Kansas-based Garmin would “litre” and not the American spelling “liter” — especially in the name attributes in this XML snippet.

      1. That would explain the string value but not the name attribute, which would be constant across all regionalizations.

      2. The string resources were extracted from the default (English) strings.xml file.
        I checked in the FR and IT strings file and these new string resources are not in those translations, so I guess they’re not ready for release yet, likely just for testing.
        Maybe they were added by a dev who just spells it “litre” – I came from the UK although I’ve lived in the USA for 16 years, but I still end up using different spellings for some words day-to-day.
        If you are suggesting I’ve “made this up” – just grap the apk file from apkmirror and take a look for yourself, it’s not hard to do…

      3. I’m actually suggesting it is a disturbing sign of poor attention to detail. You can’t just mix and match UK and US spellings. I’d you are using US spelling standards than the UK ones are wrong and vice versa.

        I can imagine how “lbl_milligrams_per_decilitre” leads directly to a defect where the internationalization is not applied to a label and instead it only displays the default because some other code tries to pull the value for lbl_milligrams_per_deciliter.

Comments are closed.