Heart rate values in Suunto App different than Strava or .fit file

dombo

I also noticed it. I think it is mainly because suunto’s smart HR belt, which is - let say - not the best. I personally switch to H10, because suunto belt was so unreliable. I think, that suunto not just filter data in suunto app, but also when live heart rate is displayed in watch. rapid change in heart rate during sharp intervals were not displayed correctly on watch for me, but was correctly exported to strava. strange way, how to hide unreliability of own products.

onthesummit

I used the Ambit with Movescount and when I upgraded to 9 I switched to Suunto App. Today I made a test. Since the H10 can connect to 2 BLE receivers I recorded the run with both the 9 and the Ambit. Here is a comparison of the heart rate graph from the exported fit files from Suunto App (top) and Movescount (bottom).

Screenshot (23).png

The watch performed much better, but there was still an issue at the end. Even if the Ambit or Movescount does some sort of smoothing of data before export, it is clear that at the end there is some bad data in the 9/App version vs the Ambit/Movescount version. I believe there is a problem of communication between the watch and the chest sensor.

Links to activities:
https://www.suunto.com/move/marcelilie/5f36270723e16f537841ff80
http://www.movescount.com/moves/move349951057

Dimitrios Kanellopoulos

When you record with the watch the watch only records ibi data and shows the deriving HR value.

I am not sure if other apps do that via the 2nd channel.

Later the ibi data are parsed and also sent to other services.

Unfortunately, suunto app processes those different than other services do, and sometimes even when creating the HR values for other services (via the cloud)

So in suunto app you might see a little better charts (or worse) and on other services a little different.

onthesummit

Another run, another failed recording of the hear rate data. I have checked the hrv field in the fit file and those values are wrong, those are not the values that the chest sensor is transmitting (since a different device is receiving different data from the same sensor at the same time and that data seems to match reality). There is an obvious failure in the connection between the chest sensor and the watch during the run that determines the watch to record bogus data.

Dimitrios Kanellopoulos

@onthesummit what do you mean with that?

What data is wrong?

onthesummit

The values found in the hrv field (rr interval lengths) or the values found in the record.heart_rate (beats per minute) field in the fit file do not correspond to what the H10 sensor is recording or broadcasting and also they do not correspond to what the Suunto App is showing in the graphs. .
The visual hr graph in the Suunto App seems to be correct, but if you export a fit file from said app and try to plot the graph yourself you get a whole different graph full of errors. These errors can not be explained by simply saying that the app ignores some values, because if it were so, a whole chunk of that graph should be missing.
Here is the activity: https://www.suunto.com/move/marcelilie/5f38c7f1e8369b19a32663db . And here is the fit file exported from that activity from the Suunto App: Running_2020-08-16T07_05_23.fit There is no app in the world that could interpret the heart rate/hrv data from that file in such a way to obtain a graph like the one from the link.

Dimitrios Kanellopoulos

@onthesummit mine does qs. You need filtering for ibi and specific algo to create and hr. I’ll give you back your activity processed.

Dimitrios Kanellopoulos

@onthesummit amCharts (50).png

Here is the HR compared to IBI. (From the FIT file you provided)

It all looks good.

Maybe you have some misunderstanding about the IBI / RR data ?

I also just directly converted the IBI to HR via my algo that works like :

private static getHRSamplesFromIBIData(activity: ActivityInterface, ibiData: number[]) {
    // activity.ibiData = new IBIData(ibiData);
    // @todo optimize
    // Create a second IBIData so we can have filtering on those with keeping the original
    const samples: any[] = [];
    (new IBIData(ibiData))
      .lowLimitBPMFilter()
      .highLimitBPMFilter()
      .movingMedianFilter()
      .lowPassFilter()
      .getAsBPM().forEach((value, key, map) => {
        samples.push({
          TimeISO8601: (new Date(activity.startDate.getTime() + key)).toISOString(),
          HR: value / 60,
        })
    });
    return samples;
  }

And here is the produce. A little different on the hard parts but I am not using what Suunto uses exactly.

amCharts (51).png

Dimitrios Kanellopoulos

Also just to be clear and help here.

IBI/RR is the ms between Heart Beats. (In short)

The instant HR from an RR is 60000/RR so for example a 1000ms time between heartbeats is 60bpm. 60000/1000 = 60

onthesummit

@Dimitrios-Kanellopoulos Thanks for the thorough reply. I will try to implement the filters you are describing before calculating the beats per minute values. However, the problem that I initially suspected has sorted itself out after I unpaired and re-paired the sensor to the watch. In the last few runs the data from the fit file exported from the Suunto App was much more reliable.

Dimitrios Kanellopoulos

@onthesummit I made a lib if you like:

https://github.com/sports-alliance/sports-lib

If you can use a bit of JS perhaps it can help looking at the IBI class etc.

Here to help