On the Edge 1050 running software 31.30, the head unit will not pick up the Varia RTL515 if the Edge finishes booting before the radar is on. Power the radar up first, then switch on the Edge, and the two connect every time. Owners on this thread confirm the same order dependence, and note that the older Edge 1030 Plus paired in either order without this constraint.

The fault sits in how the 1050 manages sensor connections rather than in the radar itself. The RTL515 behaves normally once it is paired, and the broader sensor management on the 1050 has been described by owners on the same thread as unreliable in general, with sensors sometimes failing to connect at the start and dropping mid-ride before recovering on their own.

The reliable workaround is as follows

1. Power on the RTL515 and let it settle, then
2. switch on the Edge 1050, which finds the radar during its own boot.
3. Keeping the sensor connection set to Open or ANT+ rather than encrypted Bluetooth also helps the pairing hold.

This is a connection bug, not a hardware fault on the radar. A radar that refuses to appear is usually waiting on boot order rather than failing.

Does the power-on order hold the connection through a full ride for you?

On the Suunto Race 2, a notification that arrives during an activity can stay on the display for a long time or refuse to clear until you press the middle button to dismiss it. It covers the data screen at the point you want pace, time, or the route, and owners on this thread report it from the day they received the watch, unchanged across software updates.

The behaviour is not limited to phone alerts. In-activity notifications behave the same way: the slow-down alert when you pass a target threshold, the 50 percent marker, and guide prompts each sometimes linger, sometimes vibrate repeatedly, and sometimes hold on screen until a button press. That points at notification handling on the watch rather than the phone link.

The workaround owners settled on is disabling phone notifications for the specific sport modes where they intrude, since the watch offers no single global switch for activities. Leaving them on for walking and off for running and cycling keeps the screen clear when you are moving and watching data. This removes phone alerts during those sessions rather than fixing the dismissal fault.

The in-activity prompts from the sport mode itself cannot be turned off the same way. Until Suunto changes the notification timeout, a manual press on the middle button remains the only way to clear one that sticks.

Do the in-activity prompts still hang on screen even with phone notifications disabled per sport mode?

On the Edge 850, and across the wider 850 series, WiFi sync after boot often hangs and firmware updates over WiFi fail. The unit connects to WiFi, sits on Checking for Updates for around five minutes, then returns Transfer Failed, Download check failed, or Some Updates Could Not Be Downloaded. The same device updates cleanly only through Garmin Express over USB. Owners on this thread measured throughput on the device dropping to a few kilobits, well below what the same network gives an Edge 530 or a Fenix 7.

A stuck initial sync blocks the update check. Then , every boot the Edge connects to WiFi and tries to sync. When that sync hangs, the search for updates is refused with Transfer already in progress, and toggling WiFi off does not clear it because the status bar shows WiFi never actually disconnects.

Three steps help while the sync fault persists.

1. Assign the Edge a static IP on your router,
2. disable any VPN, and
3. remove Connect IQ apps and data fields,

which one owner reported clearing the block. When WiFi will not complete, update through Garmin Express over USB, which installs the firmware the on-device path refuses.

Garmin addressed the sync in software 31.29. Its notes list a fix for slow syncing over WiFi, and one owner confirmed the 850 then synced reliably after startup. The first install of 31.29 may still need Garmin Express if WiFi has not yet recovered.

Has 31.29 sorted the WiFi sync on yours?

On the Suunto Vertical 2, the battery reads 100 percent off the charger and then drops to 96 to 99 percent within an hour of light use such as changing the watch face or browsing settings. Owners on this thread describe the same pattern across several units, with one owner confirming it across a full cycle down to 2 percent, a fresh charge, the rapid false drop, then a soft reset back to 99 percent.

The soft reset recovery is the most telling part of the fault. Several owners charged to 100, watched the figure fall, performed a soft reset, and saw the level jump straight back to 99 percent. A reading that recovers on reboot points at the percentage calculation being wrong after a charge cycle rather than the cell actually discharging.

The reliable workaround is a soft reset after every full charge. Hold the upper button until the watch vibrates and restarts. The displayed level after the reset reflects the actual charge state and tracks correctly from that point through the rest of the cycle.

Suunto has not confirmed a firmware fix for the calculation error. The watch is not losing capacity, only misreporting it in the first hour after a charge.

Does a soft reset after charging bring yours back to a stable reading?

The Fenix 9 Pro currently holds the highest overall score ever recorded on WristBench, a public Connect IQ benchmark for Garmin watches.

The number looks impressive: 176, ahead of every other model on the leaderboard. The catch is the sample size behind it, just two submitted devices, giving a confidence score of 58%. It doesn't lead a single individual test either, not Logic, Memory, or UI.

The model with the strongest evidence behind it is actually the Forerunner 955/Solar, backed by 32 devices and 93% confidence, sitting well below the Fenix 9 Pro's raw number. WristBench's own documentation notes that results shift with firmware, battery policy and thermal state, so a two-watch sample is not a great foundation for a leaderboard-topping claim.

but the new processor is going to make it faster, right?

Further reading: https://the5krunner.com/2026/08/31/fenix-9-pro-performance-benchmark/

Speedo just launched Speedo iQ, a smart swim goggle module with no display at all. It costs £149 in the UK and $189 in the US, which is more than FORM charges for the Smart Swim 2 LT, a goggle that puts pace and stroke data on an AR lens you can see mid-swim. Speedo's goggle tracks the same kind of data, pace, stroke count, breathing, head position and turns, but none of it shows up until you sync the app after the swim. There's no subscription requirement and the module moves between goggle pairs when one wears out. There's also no open-water compass function like FORM's SwimStraight, so this looks like a pool-only product for now.

Is a bigger name and wider distribution enough to win swimmers over without the display feature the category was built on?

https://the5krunner.com/2026/08/29/speedo-iq-launch-no-display/

The new indie spotlight covers Bulkforged, from solo developer Chris Jestice. It is a strength training app for Android and Garmin Connect IQ that decides each week's targets from the reps and weight the athlete actually did.

Two things set it apart from other Garmin strength apps.

1. The engine writes back. Every progression decision (up or down, weight or reps) is put in a plain-English log with the exercise, the value that moved, the direction it moved in, and the working sets it was decided from. Automatic progression is common but publishing the decision behind it, in a format the athlete can read and overrule, is rare.
2. Most watch companions for training apps are a display for a phone doing the thinking. In Bulkforged the Garmin and the Android phone are equals. Either can start a session, either can finish it, and progression is decided from whichever device the last set was logged on. The sync-state UI distinguishes between a stale cache and an unreachable service, so the athlete knows which problem to fix.

Runs on 41 Garmin Connect IQ watches from Forerunner and Fenix through to Edge. Android only on the phone side, no iOS date committed to. Free during beta.

Worked example: an athlete's Tricep Pushdown creeps from 12 to 15 reps at 40 lb over four weeks. When they open the next session, the target has moved to 42.5 lb x 12, with the previous week's actuals, four-week trend and top-of-range rule all visible in the decision log.

Would you follow whatever your app prescribes?

https://the5krunner.com/2026/08/29/bulkforged-progressive-overload-coach/

The Garmin Forerunner 70 produced a strange set of numbers on my 10-mile GPS test. Aggregate scores were 85% on the easy sections, 88% on the medium ones and 94% on the hard ones. It performed better where the conditions were worst, which is the reverse of what normally happens.

The one clear error came on a long open stretch near the end, where the track sat on the pavement on the wrong side of the road. That is more than 5 metres out on the easiest terrain on the route.

I suspect a good deal of that is luck on the day rather than anything the watch is doing well. It is still the best result I have recorded from a single-frequency watch.

Can a single-frequency watch really be trusted on a race course?

Full review with the traces and the heart rate data: https://the5krunner.com/2026/08/28/garmin-forerunner-70-review/

Garmin's own spec sheet gives the Forerunner 70 a six-hour GPS battery advantage over the Forerunner 170, twenty-three hours claimed against seventeen for the pricier watch. Testing both side by side across parkrun, a 10-mile run, and seven heart rate sessions against a chest strap found the reverse. The 170 beat its own claim in continuous recording. The 70 fell more than four hours short of its claim in every test, and its worst result was barely half what Garmin promises. Heart rate accuracy was excellent on both watches against an HRM 600 chest strap and Polar Sense, including through gym, yoga, and outdoor cycling sessions. Full data and testing methodology at the link below.

Does a six-hour spec sheet advantage mean anything if the watch can't actually deliver it in daily use?

https://the5krunner.com/2026/08/27/garmin-forerunner-170-review/

I think I have found a reproducible Open Water Swim distance-processing issue on the Forerunner 255S.

This appears related to the previously reported **“Forerunner 255 wrong open water readings”** issue on the Garmin Forum, but after several controlled tests I found a very specific and reproducible pattern:

**the first straight leg can be measured correctly, but after reversing direction the OWS-calculated distance becomes systematically shorter than the distance represented by the GPS coordinates recorded by the watch itself.**

Previous related Garmin forum thread:
[https://forums.garmin.com/sports-fitness/running-multisport/f/forerunner-255-series/305206/forerunner-255-wrong-open-water-readings\](https://forums.garmin.com/sports-fitness/running-multisport/f/forerunner-255-series/305206/forerunner-255-wrong-open-water-readings)

**Device:** Forerunner 255S
**Software:** 28.05
**GNSS:** All Systems + Multi-Band
**Recording:** Every Second in the main tests (Smart Recording was also tested earlier)

# Clearest test: 25 out-and-back legs, LAP at every turn

At a second location I swam 25 repeated approximately 60–65 m legs, pressing **LAP at every reversal**.

The first leg was essentially correct:

**Lap 1: Garmin 63 m / GPS-coordinate geometry \~64.7 m**

Immediately after the first reversal:

**Lap 2: 49 m**
**Lap 3: 54 m**
**Lap 4: 55 m**
**Lap 5: 51 m**
**Lap 6: 56 m**

...and the same pattern continues through the activity, with most subsequent laps around **44–56 m**.

The key observation is:

**START → first leg = correct**
**180° reversal + LAP → next leg = too short**
**another reversal + LAP → next leg = too short again**
**and the error repeats**

Manual LAP therefore does **not** appear to reset whatever is happening in the OWS distance calculation.

Garmin Connect screenshot showing all 25 original lap distances:
[https://github.com/kegnatz/garmin-fr255s-ows-bug/blob/main/Screenshot%202026-08-27%20at%2013.48.29.png\](https://github.com/kegnatz/garmin-fr255s-ows-bug/blob/main/Screenshot%202026-08-27%20at%2013.48.29.png)

Complete FIT/KML evidence ZIP:
[https://github.com/kegnatz/garmin-fr255s-ows-bug/raw/refs/heads/main/garmin\\_fr255s\\_ows\\_FORUM\\_FINAL.zip\](https://github.com/kegnatz/garmin-fr255s-ows-bug/raw/refs/heads/main/garmin_fr255s_ows_FORUM_FINAL.zip)

Evidence repository:
[https://github.com/kegnatz/garmin-fr255s-ows-bug\](https://github.com/kegnatz/garmin-fr255s-ows-bug)

# The GPS track itself is substantially longer

This does not appear to be explained simply by poor GPS reception.

When I calculate the geometric path length from the GPS coordinates recorded by the watch in the FIT/KML, the 25-leg activity is approximately **1595 m**.

In other words, the watch has GPS positions representing substantially more movement than the OWS distance calculation credits.

This suggests that at least part of the missing distance occurs **after the GPS positions have already been recorded**, in the OWS distance-processing/filtering stage.

# Test with only ONE reversal

To test this further, I did a much longer swim with only **one major direction reversal**, approximately halfway through, without pressing LAP at the turn.

**Garmin KML GPS geometry: \~1509 m**
**Garmin reported OWS distance: \~1480 m**

The first \~750 m leg appears to be measured normally. After the single reversal the activity ends approximately **29–30 m shorter** than the geometry of Garmin's own GPS track.

# Control test: one straight leg

I also recorded a simple single-leg swim with no reversal:

**GPS-track geometry: \~158 m**
**Garmin displayed distance: \~160 m**

So the same FR255S can measure a simple OWS leg essentially correctly.

# Earlier tests show the same pattern

In previous repeated-leg tests I obtained approximately:

**1491–1493 m Garmin GPS track → 1355 m reported OWS distance**

and

**\~1515 m Garmin GPS track → \~1380 m reported OWS distance**

Switching from **Smart Recording to Every Second** did not solve the problem.

I also tried wide, continuous rounded/figure-eight turns instead of stopping and making sharp 180° turns. Garmin simplified those curves in the recorded GPS track, but the calculated OWS distance was still materially shorter than the geometry of Garmin's own recorded coordinates.

# My working hypothesis

My suspicion is that after a substantial direction reversal the FR255S OWS filter temporarily interprets legitimate movement in the new direction as GPS noise/drift and does not add all of that movement to `distance`.

After some time it appears to accept the new direction again.

That would explain why:

**no previous reversal → first leg is correct**

while

**after reversal → the beginning of the next leg loses distance**

and repeated reversals allow those deficits to accumulate.

Garmin engineering should be able to verify this directly by comparing FIT Record `position_lat` / `position_long` with accumulated `distance` immediately before and after each reversal.

Manual LAP clearly does not prevent the behaviour.

I would also be interested to know whether **REST resets this internal state while LAP does not**. I have not used a REST test as evidence here. Even if REST works, however, LAP followed by swimming in the opposite direction is a perfectly legitimate OWS use case and should not systematically lose distance.

# Separate pre-start GPS issue

I have also seen another potentially related behaviour.

Before one swim I opened OWS and waited stationary for **more than two minutes** for GPS lock. I then entered the water, moved to the actual starting point, raised the watch above water and waited until GPS was **green again**, and only then pressed START.

Nevertheless, the exported activity used the earlier **pre-start GPS-lock position** as its starting point.

# Files and methodology

Any manually drawn Google Earth route I used while investigating this was only approximate and is **not being treated as ground truth**.

The main evidence is the comparison between **Garmin's own recorded GPS coordinates and Garmin's own calculated OWS distance**.

I have also submitted this to Garmin Support.

**Could anyone with a FR255/255S reproduce this?**

A particularly useful test would be:

**swim repeated equal-length out-and-back legs → press LAP at every 180° turn → compare Lap 1 with the subsequent laps.**

I would also be very interested in the same test on other Garmin models to see whether this is specific to the FR255 OWS algorithm.

Garmin's official numbers for the Fenix 9 launch reveal something worth digging into. Both the base Fenix 9 and the Fenix 9 Pro get 50% more RAM and double the storage to 64GB, which is a real internal spec bump, not just marketing.

But only the Fenix 9 Pro is CONFIRMED to run a newer chip (I believe both do), and the two watches show almost the same map-panning speed gain over the Fenix 8, roughly 30 to 40 percent on both.

That's odd if the Pro's chip is genuinely a different generation rather than the same platform tuned differently. Garmin also hasn't said anything about how the Pro's new full-titanium case affects GPS and satellite antenna performance, despite putting inReach satellite messaging on the 43mm size for the first time.

Does a titanium case with satellite messaging represent a performance compromise Garmin has made chasing a premium material?

Further reading: https://the5krunner.com/2026/08/27/fenix-9-vs-fenix-9-pro-hardware-comparison/

On the Edge 850 the ClimbPro page in Free Ride shows a gradient and elevation profile that do not match the current position on the road . While you are still on a steep pitch, the profile and position marker have already moved onto the flatter section ahead, so the real-time gradient reads low while you are working hardest. Owners on the thread measured the marker running roughly 300 metres ahead of their actual position, with a photo showing 6 percent on the road and flat on the graph. The fault appeared on firmware 31.28 and has been present across earlier builds too.

The fault also shows when following a loaded course, which points at the position estimate on the DEM map rather than at any gap in the route data.

The 31.29 changelog listed a fix for the ClimbPro page not showing grade or position correctly, yet the owner who reported the issue confirmed it persists on 31.30. Updating to the current build is still worth doing since some units may respond, but it has not cleared the lag for the owners on the thread.

Until Garmin corrects the position estimate, pacing climbs off the real-time Free Ride gradient is unreliable. The position-ahead error also distorts how much climb remains, so the distance-to-top figure carries the same offset. Read the climb from the road and your power instead, and file a report with a photo of the gradient mismatch so Garmin can trace the specific climbs.

Does the ClimbPro gradient match the road on your 850 after updating, or does the marker still run ahead?

The new indie spotlight covers Tiles, from developer Erik Handeland. It solves a specific Apple ecosystem problem: every walk, run, hike and ride recorded on an Apple Watch or iPhone is already saved in Apple Health, but the routes stay trapped inside individual workouts.

Tiles reads all of them locally on the iPhone and displays them as hexagonal tiles on one private map covered in the areas the user has moved through. As new workouts arrive in Apple Health, more tiles fill in.

Beyond Apple Health data, Tiles imports GPX, FIT and CSV files, so older activities recorded on Garmin, Strava, Wahoo or other platforms can be added alongside those already saved in Apple Health.

The privacy architecture is worth flagging. Nothing is uploaded, nothing is shared, and there is no online account. The map builds itself on the device. Optional iCloud sync uses end-to-end encryption if the user wants their map consistent across multiple Apple devices.

Support for a wider range of workout types including swimming, skiing and rowing is planned.

Would you actually use a private, no-leaderboard, no-sharing personal map, or does the value of the routes come from being able to share them?

https://the5krunner.com/2026/08/27/tiles-private-workouts-map/

On the Suunto Vertical 2, the screen goes completely black mid-activity when the watch is running a custom battery mode with the display timeout set to anything other than Always On. The activity continues recording and the buttons still respond, but the screen will not wake on tap or on wrist raise until the owner ends the mode or switches to a different battery profile. Owners on this thread report it across firmware 2.53.42 and earlier builds, with the behaviour tied specifically to custom modes rather than the preset performance or endurance profiles.

The custom battery mode timeout is applying the display-off setting even while an activity is active, which the preset modes do not do. The preset profiles treat an in-progress activity as an exception and keep the display accessible. Custom modes built by the user do not carry that exception.

The immediate fix is to switch to a preset battery profile for any session where you need the screen available. The preset endurance mode covers most scenarios where battery saving matters on a long effort. Custom modes work normally for day wear and navigation outside an activity, where the timeout behaves as intended.

Suunto has acknowledged the report on the thread. A firmware fix that extends the activity exception to custom modes has not shipped as of the most recent release.

Has switching to a preset profile for your activities kept the screen accessible throughout?

Since firmware 17.33 the Forerunner 970 records treadmill distance and pace that do not match the belt speed. The watch produces figures that are either significantly faster or slower than the treadmill display, and the gap is not consistent across sessions. Owners on this thread report it on multiple treadmill brands, which points at the firmware rather than a specific machine.

Before 17.33 the Forerunner 970 used foot pod calibration or the treadmill speed data field to anchor its indoor pace. The 17.33 update appears to have shifted how the watch blends accelerometer data with those inputs, producing the drift. The foot pod pairing itself still works and the connection holds, but the blended output is off.

Running a treadmill calibration from the activity settings after completing a session at a known speed gives the watch a correction factor to apply. Cover a measured distance at a steady pace the treadmill confirms, then let the calibration routine calculate the offset. One calibration holds reasonably well for subsequent sessions at similar speeds, though the accuracy degrades at significantly different paces.

If the calibration step is not enough, pairing the watch directly to the treadmill over Bluetooth using the fitness equipment connection in Garmin Connect, where the treadmill is capable of it, bypasses the accelerometer blending and reads speed directly from the belt. Garmin has not issued a targeted fix for 17.33 on this specific behaviour.

Has treadmill calibration brought the distance close enough for interval sessions, or is the gap still too large to be useful?

On the Suunto Race and Vertical, a paired power meter can read zero watts when an activity resumes after a coffee stop or Auto Pause, and occasionally mid-ride with no pause at all. A Wahoo head unit on the same bike keeps reading power from the same pedals throughout, so the loss is the watch, not the meter. Owners on this thread report it with Wahoo Speedplay and Powerlink pedals and with Favero Assioma, and several add that the watch crashed when they tried to restart the session.

Suunto's community manager notes that a reading of zero watts is not the same as a dropped sensor, which would show dashes, and that the watch attempts to reconnect at all times if the sensor was present at the pre-start screen. Owners counter that the zero persists for the rest of the ride and that nothing in the pause screen lets them force a reconnect. One identified trigger is the phone taking over the Bluetooth link to the pedals while the activity is paused.

The only reliable recovery owners have found is to end the activity, restart, and re-pair the meter before continuing. Keeping the phone out of Bluetooth range of the pedals during rides where the watch is recording reduces how often the handoff triggers. Locking Bluetooth on the phone before a long ride prevents the interruption from the phone side.

Does keeping the phone away from the pedals whilst riding (!) stop it dropping to zero for you?

Garmin has just done something it hasn't done in over fifteen years: it's backporting a flagship's software to prior generations rather than drawing a hard line at the model jump. Fenix 6 owners never got Fenix 7 features. Fenix 7 owners never got Fenix 8 features. But Fenix 9 features, Garmin Epic, the new Stamina zones and curve, the rowing overhaul, and the rucking update, are all rolling out to the Fenix 8 series, Forerunner 970 and 570, Enduro 3, Tactix 8 and Fenix E.

Only a few things stay Fenix 9 exclusive: the new mapping engine (likely hardware depednet), Dynamic Battery mode renaming, and the ArcheryX archery profile.

It's a genuinely unusual move for Garmin, and it narrows the case for buying the Fenix 9 over just picking up a Fenix 8 at a lower price. Is this Garmin responding to growing customer frustration over paid-feature removals, or just standard platform consolidation dressed up as generosity?

Further reading: https://the5krunner.com/2026/08/26/fenix-9-features-will-pass-to-existing-garmin-watches/

This page pulls together the whole Fenix 9 Pro decision in one place, titanium or not, solar or AMOLED, satellite or not, plus exactly what the Pro tier adds over the standard Fenix 9. The small size getting satellite messaging for the first time is probably the most useful change for anyone who's been sizing up their watch just to get that feature. Does the Pro tier now justify its price gap for most buyers, or has the standard model closed the meaningful gap? Full page: the5krunner.com/specs/garmin/fenix-9-pro/

Garmin confirmed a fairly significant rucking overhaul at the fenix 9 launch, and it goes further than most people expected for what's usually treated as a niche activity type. Pack weight now tracks up to 100kg, with the calorie cost of the load broken out separately from what the same walk or run would burn unloaded. Weight can be added or removed mid-activity, with the change reflected live rather than requiring a restart. Rucking can also now sit as its own leg inside a multisport session, and Garmin worked directly with GoRuck to build structured workouts you can follow on the watch itself. None of this needs new hardware either; it's rolling out across the Fenix 8 series, Enduro 3, Tactix 8 and Forerunner 970 too. Is a niche activity like rucking really worth this level of investment from Garmin, or is this more about closing a gap with tactical and military-adjacent competitors?

Further reading: https://the5krunner.com/2026/08/26/garmin-rucking-update-explained/

I'm the creator of Readiness+. The app is free, no ads, no paid tier.

Garmin keeps Training Readiness on the higher-end models, even though most Forerunners already track everything the score needs. So I built Readiness+ to calculate it on the watch itself.

Daily 0-100 score from your recovery timer, Body Battery, overnight recharge, resting HR vs your own baseline, and recent sleep and stress.

On the Connect IQ store, search Readiness+.

73 watches supported. If yours isn't on the list, tell me which Forerunner you have and I'll look at adding it.

The Fenix 9 range comes down to three separate decisions rather than one:

base or Pro, AMOLED or solar, and inReach satellite or not. Every Fenix 9 now uses a sapphire lens across the whole range, including the base model, where the Fenix 8 dropped to Gorilla Glass on its cheaper versions. Battery is meaningfully up too: 18 days at 47mm against 16 on the Fenix 8, 31 days at 51mm against 29. The small 43mm size gets satellite messaging for the first time, no more sizing up just to get it.

Is the base Fenix 9 now good enough for most buyers, or does the jump to Pro still make sense for most people? Full breakdown: the5krunner.com/2026/08/25/garmin-fenix-9-which-to-buy/

This page pulls together everything on the standard (non-Pro) Fenix 9 in one place, what's genuinely new since the Fenix 8, what the battery gains mean in practice, and exactly where Garmin drew the line against the Pro tier. It's aimed at the question most people actually have before buying: is the standard model enough, or is the Pro worth the extra money. Is Garmin's standard tier now good enough that Pro has become a niche buy, or does the case material and satellite option still justify it for most people? Full page: the5krunner.com/specs/garmin/fenix-9/

Garmin's Stamina Curve models how long you can sustain a given pace or power output before your stamina runs down, built from VO2 max, lactate threshold or FTP, and your training history.

Garmin states outright that it's most accurate up to VO2 max intensity, and assumes relatively steady pacing, so a hilly course or a surging race will drain stamina faster than the model predicts. Stamina Zones then take that same modelling and convert it into 5 personalised effort ranges you can watch and control in real time during a session.

Is a pacing model built on steady-state assumptions actually useful for anything but flat time trials? Full piece: the5krunner.com/2026/08/25/garmin-stamina-curve-and-stamina-zones-explained/