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

onthesummit

I just upgraded to Suunto 9 Baro from my old Ambit3 and I found there are some inconsistencies between the heart rate data showed in the Suunto App and the one from Strava or the exported .fit file. Activities can be seen here: https://www.suunto.com/move/marcelilie/5f32f0405f7eea5d72ae0c34 vs https://www.strava.com/activities/3898940370

The Strava graph is identical with the fit export. You can clearly see some irregularities in the data from Strava between 0:01:02 and 0:01:25 and a lot shorter ones at the end of the activity. However, in Suunto App, these irregularities are missing and the data shown there seems to be genuine and not simply a constant value or interpolated data.

I am using a Polar H10 chest strap for heart rate. Also, I am using Stryd for pace, cadence, distance and power (in case it is relevant) and the power data from the fit file is very accurate.

margusl

You didn’t use Suunto App with Ambit? Those spikes are just bad HR sensor readings due battery, bad contact, noise from statics from clothing or something else. It’s just something that happens with all belts from time to time. With Suunto App Suunto has decided to filter out those obvious anomalies for you, but I wouldn’t take it as a feature, it’s more like hiding an issue.

When those errors are becoming more frequent, it’s usually a sign for you to clean your belt, change the battery, find a replacement belt or find a way to deal with statics. You’ll get way better overview of this if you use something that can plot individual IBI values (interbeat intervals, periods between every single heart beat), like Runalyze. Or something that provides fine control over HR smoothing, like Training Peaks.
Few examples, recorded with A3P & H10, had problems at the start, but it somehow started working after 16 minutes:

Training Peaks, smoothing switched off, small variability after 16min mark is expected

IBI values for that exact activity from Runalyze. Clear indication that HR for first the first part should just be discarded

Same activity in Suunto App, it’s trying to apply some filtering to noisy data. I’d prefer just a flat line or some indication that there’s something wrong with HR reading.

And it was all just fine the day before. And it got a lot worse the day after. Belt is about 20 months old, battery maybe few months, and I’m using it about 30 … 50 hours per month.

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