Samenvatting

In dit artikel beschrijf ik de bevindingen van mijn hoogtemetertests met de Stryd Duo, versie 4.0 model 27. Dit is een eerste verkenning, gebaseerd op 2 activiteiten. Ik vergelijk met nauwkeurige hoogtekaarten.

  1. De in Stryd PowerCenter gerapporteerde hoogtemeters zijn 16% en 21% te laag en niet duidelijk te reproduceren.
  2. De Stryd-pods zelf wijken ongeveer 25% naar beneden af.

In tegenstelling tot horizontale afstand lijken de Stryd-pods dus niet bruikbaar voor hoogtemeters.

Wat heb ik getest?

Om specifiek wat hoogtemeters te kunnen maken, ben ik onder andere een aantal keer bij de trap in het natuurgebied Kwintelooijen geweest. Het mooie hieraan is dat het recht omhoog en weer recht omlaag gaat, zonder daling tussendoor. Dat maakt het makkelijk om te gebruiken als meetpunt voor de betrouwbaarheid van de hoogtemeters: je neemt simpelweg het verschil tussen het hoogste en het laagste punt.

Ik draag een Garmin Fenix 8 (43 mm) amoled-horloge en heb hieraan de Stryd duo footpods gekoppeld. Activiteiten laat ik vervolgens synchroniseren vanuit Garmin naar Strava en Stryd. Als ik de hoogtedata van Garmin, Strava en Stryd in een tabel zet, dan krijg je het volgende. Op 15 februari was mijn doel 1.000 hoogtemeters te maken, op 13 april was het doel er minimaal 2.000 te lopen.

15-02-202513-04-2025
Garmin fenix 8 softwareVersie 12.38Versie 13.35
Aantal keer de trap30 x59 x
Stijging volgens Garmin1.049 meter2.071 meter
Stijging volgens Strava1.049 meter2.071 meter
Stijging volgens Stryd870 meter1.823 meter

Oftewel, volgens Stryd heb ik helemaal niet de verticale afstand gehaald die ik dacht te halen op basis van mijn horloge! Wie heeft er nu gelijk?

Gelukkig hebben we in Nederland een erg nauwkeurig DTM (Digital Terrain Model, dit is de maaiveldhoogte) in de vorm van AHN (Actueel Hoogtebestand Nederland). Op het moment van schrijven wordt AHN versie 5 gemaakt, die is voor Kwintelooijen nog niet beschikbaar dus AHN4 is de meest recente en meest nauwkeurige hoogtedata die beschikbaar is. Volgens de kwaliteitsbeschrijving ligt 99,7% van de punten binnen 20 cm van de werkelijke hoogte. Als ik deze trap hierop plot, dan krijg ik het volgende: zie deze link https://viewer.ahn.nl/AHN4/DTM/….

AHN viewer met AHN4-DTM van de trap in Kwintelooijen
AHN viewer met AHN4-DTM van de trap in Kwintelooijen

Hieruit blijkt een hoogteverschil van 50,88 – 13,90 = 36,98 meter. Als we de door AHN genoemde 99,7%-nauwkeurigheidsgrens van 20 cm op beide meetpunten toepassen, kan het berekende hoogteverschil in het ongunstigste geval 40 cm afwijken. Op basis van AHN4 ligt het hoogteverschil dus waarschijnlijk tussen de 36,58 en 37,38 meter. Met deze data kunnen we de tabel verder aanvullen.

15-02-202513-04-2025
Aantal keer de trap30 x59 x
Stijging volgens Garmin1.049 meter2.071 meter
Stijging volgens Strava1.049 meter2.071 meter
Stijging volgens Stryd870 meter1.823 meter
Stijging volgens AHN4Tussen 1.097,4 en 1.121,4 meterTussen 2.158,22 en 2.205,42 meter
Afwijking Garmin t.o.v. AHN4 middenpunt-60,4 meter / -5,4%-110,82 meter / -5,1%
Afwijking Stryd t.o.v. AHN4 middenpunt-239,4 meter / -21,6%-358,82 meter / – 16,4%

Conclusie: Stryd wijkt 3 à 4 keer meer af van de AHN4-referentie dan Garmin in deze 2 gevallen!

Het is mij eerlijk gezegd niet duidelijk of Stryd zich alleen op gps-data baseert, waar ze een onjuist correctiealgoritme overheen leggen, of dat ze daadwerkelijk de pods gebruiken om hoogtedata te berekenen. Wel goed om te vermelden is dat de weergegeven horizontale afstand van Garmin, Strava en Stryd wel bijna identiek is.

15-02-202513-04-2025
Aantal keer de trap30 x59 x
Afstand volgens Garmin12,51 km25,07 km
Afstand volgens Strava12,50 km25,07 km
Afstand volgens Stryd12,50 km25,07 km

Ik heb de vraag bij Stryd neergelegd waarom dit grote verschil in hoogtemeters kan ontstaan. Er bestaat een Stryd-artikel over dit onderwerp dat eigenlijk niet zoveel zegt. Ze verwijzen daar naar een interessant artikel van gpsvisualizer.com, om vervolgens te zeggen dat ze deze methoden niet gebruiken.

Met 2 activiteiten van 1 gebruiker op 1 locatie begrijp ik dat dit niet alle cases van een algoritme kan dekken. Daar is meer data en breder onderzoek voor nodig. Aan de andere kant heb je juist precies een verzameling van dit soort concrete gevallen nodig om verbeteringen te kunnen doen.

Update 1

18 april 2025

Er kwam vrij vlot antwoord van Stryd waarin ze stellen:

  1. Hoogtedata van de pods wordt niet gebruikt wanneer je een activiteit via een Garmin-horloge opneemt.
  2. Stryd importeert de activiteit en neemt de hoogtemetingen hieruit over, dus ze pakken wat mijn horloge heeft opgenomen.
  3. Stryd past geen correctiealgoritme toe (in dit geval) op die geïmporteerde data.
  4. PowerCenter geeft slechts de hoogtemetingen per seconde weer uit het activiteitenbestand en aggregeert om het totaal weer te geven.
  5. Verder verwezen ze naar dit artikel van Garmin – How do I Change the Elevation Source in Garmin Connect?

Ik weet dat mijn horloge een barometrische hoogtemeter heeft en inderdaad, als ik de activiteit in Garmin Connect open, dan kan ik bij hoogtebron kiezen uit ‘Je toestel’ of ‘Professionele enquêtegegevens’. Deze beide waarden kan ik nu ook opnemen in de tabel door de Garmin regel te splitsen. Voor de duidelijkheid is ‘Je toestel’ de barometer van het horloge en ‘Professionele enquêtegegevens’ is gps in combinatie met hoogtekaarten.

15-02-202513-04-2025
Aantal keer de trap30 x59 x
Stijging volgens Garmin (toestel)1.049 meter2.071 meter
Stijging volgens Garmin (enquête)919 meter1.851 meter
Stijging volgens Stryd870 meter1.823 meter

Nu is de vraag: wat zit er nu daadwerkelijk in een activiteitbestand (.fit bestand)? Laten we erin duiken. Ik gebruik fitfileviewer.com om de details te bekijken van mijn activiteit in april. Onder ‘Activities Metrics’ is in de kolom ’total ascent’ een stijging van 2.071 meter te zien. Dit is het getal dat Garmin en Strava gebruiken voor deze activiteit, en dit is ook het dichtste bij de referentiewaarde van 2.181,82 meter. Dus waarom gebruikt Stryd dit getal ook niet? Ik heb werkelijk geen idee.

Screenshot van fitfileviewer.com
Screenshot van fitfileviewer.com

Ok, wat voor data hebben we nog meer? De daadwerkelijk per-seconde data zit in zowel ‘Record’ als ‘GPS Metadata’. Beide reeksen bevatten het veld ‘enhanced altitude’. Het eerste wat opvalt is dat ze op een verschillende waarde starten (maar wel op dezelfde timestamp).

Dan is de tweede vraag hoe hoogteverschillen hieruit afgeleid kunnen worden. Is een positief verschil van een regel ten opzichte van de vorige een stijging en een negatief verschil een daling?

Het derde wat ik zie is dat de hoogte die geregistreerd wordt binnen ‘GPS Metadata’ niet met dezelfde waarden verandert als die binnen ‘Record’.

Screenshot of fitfileviewer.com with Record and GPS Metadata
Screenshot of fitfileviewer.com with Record and GPS Metadata

Een plot met beide datareeksen.

Fitfileviewer.com met data reeksen
Fitfileviewer.com met data reeksen

Zeker als je inzoomt dan wordt het nog duidelijker dat de beide reeksen echt verschillen. Dus welke van de twee reeksen moeten we gebruiken?

Filefileviewer.com vergelijk
Filefileviewer.com vergelijk

Ik heb wat C# code geschreven om beide reeksen te analyseren. Download hiervoor de ‘Record’ (18.387 regels) en ‘GPS Metadata’ (18.424 regels) secties in ISO formaat. Vervolgens neemt de code de som van de hoogteverschillen. Installeer de NuGet package CsvHelper als dependency om dit te runnen.

C#43 regels
using System.Globalization;
using CsvHelper.Configuration;

const string gpsMetadataFilePath = "/Users/dirk-janmeijer/Downloads/18816702726_ACTIVITY-gps_metadata.csv";
const string recordFilePath = "/Users/dirk-janmeijer/Downloads/18816702726_ACTIVITY-record.csv";
using var gpsMetaDataReader = new StreamReader(gpsMetadataFilePath);
using var recordDataReader = new StreamReader(recordFilePath);
var config = new CsvConfiguration(CultureInfo.InvariantCulture);
var usCultureInfo = new CultureInfo("en-US");
using var gpsMetadataCsv = new CsvHelper.CsvReader(gpsMetaDataReader, config);
using var recordCsv = new CsvHelper.CsvReader(recordDataReader, config);
var gpsMetadataItems = gpsMetadataCsv.GetRecords<dynamic>().ToArray();
var recordItems = recordCsv.GetRecords<dynamic>().ToArray();
var (gpsMetadataElevationGain, gpsMetadataElevationLoss) = GetElevation(gpsMetadataItems);
var (recordElevationGain, recordElevationLoss) = GetElevation(recordItems);

Console.WriteLine($"GPS Metadata: {gpsMetadataElevationGain.ToString("#,##0.00", usCultureInfo)} elevation gain, {gpsMetadataElevationLoss.ToString("#,##0.00", usCultureInfo)} elevation loss");
Console.WriteLine($"Record: {recordElevationGain.ToString("#,##0.00", usCultureInfo)} elevation gain, {recordElevationLoss.ToString("#,##0.00", usCultureInfo)} elevation loss");
return;

(decimal elevationGain, decimal elevationLoss) GetElevation(dynamic[] items)
{
    var elevationGain = new List<decimal>();
    var elevationLoss = new List<decimal>();
    foreach (var tuple in items.Zip(items.Skip(1)))
    {
        var firstEnhancedAltitude = GetEnhancedAltitude(tuple.First);
        var secondEnhancedAltitude = GetEnhancedAltitude(tuple.Second);
        var difference = Math.Abs(firstEnhancedAltitude - secondEnhancedAltitude);
        if (firstEnhancedAltitude > secondEnhancedAltitude)
        {
            elevationLoss.Add(difference);
        }
        else
        {
            elevationGain.Add(difference);
        }
    }

    return (elevationGain.Sum(), elevationLoss.Sum());
    
    decimal GetEnhancedAltitude(dynamic row) => decimal.Parse(row.enhanced_altitude);
}
Code2 regels
GPS Metadata: 3,662.20 elevation gain, 3,657.20 elevation loss
Record: 2,155.60 elevation gain, 2,151.20 elevation loss

Zoals te zien zit er een heel groot verschil in beide reeksen. De punten binnen ‘GPS metadata’ vertonen veel springerige afwijkingen en dus telt dit onterecht veel stijging en daling mee. Maar geen van beide is de 1.823 meter die Stryd rapporteert, of de 1.851 die Garmin (enquête) zegt.

Op dit punt wordt het wel erg vaag wat Stryd bedoelt als ze zeggen dat ze “de gegevens rechtstreeks vanuit het activiteitenbestand tonen van de per-seconde informatie”. Zijn er andere datapunten in het activiteitbestand die ik over het hoofd zie? Is mijn analyse of de code verkeerd? Ik weet het niet.

Ofwel Stryd doet simpelweg een hoogtekaart lookup, of ze leiden de stijging en daling op een andere manier af dan de methode die ik hierboven in de code heb gebruikt. Mogelijk een vorm van filtering, smoothing en hysteresis?

Update 2

19 april 2025

Ok, nu wordt het echt interessant, want ik realiseerde me zojuist dat de Stryd-pods zelf ook activiteiten opnemen, zelfs als je via Garmin opneemt. Deze activiteiten kun je van de pods afhalen en synchroniseren binnen je Stryd-account. Omdat mijn activiteiten al via Garmin in mijn Stryd-account gesynchroniseerd waren, ontstonden er dus dubbele activiteiten.

Maar het mooie is dat ik dus ook de originele Stryd-data heb en echt antwoord kan geven op de vraag hoe betrouwbaar de hoogtedata van Stryd is! De Stryd footpods hebben namelijk maar 1.641 hoogtemeters geregistreerd tijdens mijn activiteit in april! In werkelijkheid zou dit dus volgens de AHN-data in de buurt van 2.181 meter moeten zijn. De Stryd-pods meten de hoogte zelf met hun ingebouwde barometer.

Stryd Powercenter met pod activiteit van 13 april 2025
Stryd Powercenter met pod activiteit van 13 april 2025

Helaas heb ik de activiteit van februari niet meer van de Stryd-pods zelf. Ik denk dat ik deze een keer eerder gesynchroniseerd heb en meteen ontdubbeld (dus verwijderd). De tabel kan ik nog een keer aanvullen, dit keer door de regel van Stryd te splitsen in die met de geïmporteerde activiteit en die van de Stryd-pods zelf.

15-02-202513-04-2025
Aantal keer de trap30 x59 x
Stijging volgens Garmin (toestel)1.049 meter2.071 meter
Stijging volgens Garmin (enquête)919 meter1.851 meter
Stijging volgens Stryd, geïmporteerde activiteit van Garmin870 meter1.823 meter
Stijging volgens Stryd-pods1.641 meter
Stijging volgens AHN41.109,4 meter2.181,82 meter

Conclusie: Tijdens mijn activiteit in april met 2.181 hoogtemeters, logden de Stryd-pods slechts 1.641 hoogtemeters. Dit zit er dus 24,8% naast!

Voor de duidelijkheid: ik vind hardlopen op vermogen interessant, je kunt makkelijker een consistente inspanning aanhouden. Langzamer lopen bij wind tegen, warmte, hoge luchtvochtigheid en heuvelop. Wat sneller lopen met wind mee, koeler, minder vochtig en bergaf. Een vermogensmeter die dit meeneemt in 1 metric, namelijk vermogen, maakt dit heel goed inzichtelijk.

Verder denk ik dat Stryd en de Stryd footpods een goed product zijn. Los van terugkerende verbindingsproblemen zien de pods er goed uit, zijn de racevoorspellingen verrassend nauwkeurig en krijg je inderdaad vermogen dat gevoelsmatig redelijk goed klopt met geleverde inspanning.

Om vermogen echt goed te laten werken moeten de onderliggende waarden eerst nauwkeurig zijn. Temperatuur, luchtvochtigheid, luchtdruk, afstand, etc. Dat één van die waarden zomaar 20% afwijking kan vertonen is niet ok. Je moet erop kunnen vertrouwen dat het gemelde vermogen juist is.

Daarnaast zou vermogen een vaste schaal moeten hebben zodat je het kan vergelijken, met jezelf, maar ook met anderen. Anders zegt het alleen: hoger getal is meer moeite, lager getal is minder moeite. En dat voelen de meeste mensen zelf goed aan.

Update 3

20 april 2025

Het genoemde Stryd-artikel is offline gehaald. Ik hoop dat dit betekent dat er binnenkort een nieuwere versie van online wordt gezet die preciezer en duidelijker omschrijft hoe Stryd nu precies met hoogte omgaat.

Update 4

4 oktober 2026

Mijn bedoeling was om op 18 september tijdens de 54 km Julian Alps Trail in Slovenië veel hoogtemeterdata te gaan verzamelen met de Stryd-pods. Met meer dan 2.700 hoogtemeters op deze trail een mooie test. Maar na afloop van het event kwam ik erachter dat de Stryd-pods om een of andere reden niet hebben opgenomen, helaas.

Vervolgens na lange tijd weer eens naar de Stryd-website gekeken en er is een nieuw artikel verschenen: Strava and Stryd. Daarin lees ik:

Stryd uses 3-dimensional motion capture and changes in barometric pressure to determine pace, distance, and changes in elevation.

En verder beschrijft Stryd dat het op heuvels de schuine zijde van de driehoek meet. Dat klinkt allemaal goed, maar geeft helaas nog weinig details.

Update 5

5 oktober 2026

Interessant! Er is blijkbaar een Stryd-patentaanvraag. Daarin staat concreet:

  • actuele helling kan worden geschat door tijdgebonden barometerdrukmetingen te combineren met pace
  • daar kan een lineaire hellingsfunctie op worden gefit
  • daardoor hebben langzame drukveranderingen door het weer minder invloed
  • het barometersignaal kan met een low-pass filter van ongeveer 0,2 Hz worden gefilterd om wind/aerodynamische drukschommelingen te onderdrukken
  • de cutoff kan dynamisch worden aangepast
  • hoogteverandering komt vervolgens rechtstreeks terug in een vermogenscomponent

De vermogenscomponent ziet er als volgt uit:

Pvertical=k1mgΔhΔtP_{\mathrm{vertical}}=\frac{k_1\,m\,g\,\Delta h}{\Delta t}
Pvertical=verticaal vermogen (W)k1=schaalfactorm=massa (kg)g=zwaartekrachtsversnelling (m/s2)Δh=hoogteverschil (m)Δt=tijdsinterval (s)\small \begin{array}{rcl} P_{\mathrm{vertical}} & = & \text{verticaal vermogen }(\mathrm{W})\\ k_1 & = & \text{schaalfactor}\\ m & = & \text{massa }(\mathrm{kg})\\ g & = & \text{zwaartekrachtsversnelling }(\mathrm{m/s^2})\\ \Delta h & = & \text{hoogteverschil }(\mathrm{m})\\ \Delta t & = & \text{tijdsinterval }(\mathrm{s}) \end{array}

Het patent zegt expliciet dat de verschillende k-factoren empirisch kunnen worden bepaald op basis van metingen van één of meerdere gebruikers. Ze kunnen bijvoorbeeld worden gebaseerd op gemiddelden van een groep lopers, maar ook worden gepersonaliseerd voor één specifieke loper. Dat roept echter twee fundamentele vragen op:

  1. Wat is je referentiekader? Is er een nauwkeurige ground truth voor 1 persoon of zelfs groepen te bepalen?
  2. En is deze k-factor voldoende of is de afwijking dynamischer? Stel dat de afwijking afhankelijk is van snelheid, hellingshoek, cadans etc. Dan is een vaste k-factor slechts een grove correctie en onvoldoende om juist te modelleren.