Exporting data from Suunto 9 Peak

Lauri Rantala

Thanks! If there are any real hackers out here, please help me out. Here is my gpx workout plotted with gnuplot. The speed is all over the place. On the Suunto app it’s totally smooth. What’s going on here? Notice I went shopping there between 2700 and 3700 seconds.

I wrote a perl script that outputs all the gpx data into whitespace separated data file, that can be used with gnuplot or any other software. It also shows the min and max and average heart rates, elevations, speed and total time and whatnot. Will upload that to some place safe in the near future. Not sure if this is the right place for “hackers”. But I’ve had a lot of fun with this so far.

For comparison, the heart rate, elevation and positions are totally smooth, readings taken every second. Not so with the speed:

DMytro

@lauri-rantala maybe SA is applying some smoothing algorithms.

Egika

@lauri-rantala I am not sure if the Suunto forum is the right place to trouble shoot your own programming or file parsing.
But anyway regarding your speed graph: what is the vertical axis meant to be in units (m/s, km/h, min/km etc)?
If you look at the gpx file using a text editor - what kind of speed information do you see there? It sould be easy to get to the source of the issue.

Lauri Rantala

@egika The Suunto gpx file only has position in latitude and longitude, time in seconds - the distance between two points has to be calculated and my script does that - no problems there, but when I calculate the speed from the distance and the seconds between the two points, the data is all over the place.

OK I’ll ask in some hackers forum, this may not be the right place. But if anyone is interested in hacking the gpx files, please comment here or in my blog, link above. Thank you all!

Dimitrios Kanellopoulos

@lauri-rantala we are not applying smoothing. Gpx is not the best format. Please use fit. The reason is that gpx is xml basically and each node needs to have lat long to hold the subvalues of speed etc.

Fit is not restricted to this. You can have speed without lat long etc.

Dimitrios Kanellopoulos

@lauri-rantala also I have written the sports lib. It’s in TS though but can help with all that stuff even generate the ngap

Also Thomas from elevate for Strava has a good PR open to that lib

Not sure if it helps with python, but a node J’s backend could help or a wrapper script.

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

Lauri Rantala

@dimitrios-kanellopoulos

OK thanks, I’ll look into fit, but the gpx file is pretty OK. I take the average speed of 5-20 points and end up with a pretty OK plot:

alt text

The advantage with gpx is that on my Linux system I can view them with other software too. But I’ll look into fit, why not.

And my perl script gpx2plot is now available at github, if anyone is interested.

Lauri Rantala

@dimitrios-kanellopoulos Oh and the fit format is proprietary, so not that interested. There is no fit library for perl, but there is one for gpx, so I’m pretty happy with gpx for now.

Lauri Rantala

@dimitrios-kanellopoulos I did download the fit file, tried to convert it to gpx with gpsbabel, but that program says Unsopported protocol version 2.0 - that’s the thing with proprietary formats.

margusl

GPX files from Suunto App are quite heavily processed, some datapoints are dropped while others are added through interpolation, so when calculating speed from resulting GPX-points, that level of noise is kind of expected.

Though what I find interesting and bit unexpected is that level of granularity - how points are gathered around 3-2 values and forming vertical parallel lines on a chart. The way you calculate speed makes this more prominent - time difference between most points is 1 s, so if speed is calculated only by considering time & distance between current and previous point, it’s basically a dataset of distance differences between points. When calculating speed at point n through points n-1 and n+1, output would be smoother and granularity does not pop out that much, though it’s still there.

Had to see if this is something specific for GPX-generator used by SuuntoApp / SportsTracker, but GPX from 9P was only one with such a strong granularity. Nothing to worry about ofc, just interestingaf and I’m sure it’s more visible in GPX than FIT exports.

Your gpx with few different takes on calculating speed, speed_between_prev is basically same approach that you took, seg_get_speed uses n-1 & n+1 for speed at n and and speed_rollin_15_mean is centered rolling average over 15 points:

vs my F6 (ice skating, lot of stops, “smart” recording; gpx from Suunto App):

vs Ambit3P (bike commute, note those 40+ km/h artefacts; gpx from Suunto App ) :

vs same A3P activity but taking speed directly from fit-file (and x is point index instead of time):

Notebook, works in Colab -
https://gist.github.com/marguslt/166fb2856bf1a16b279f4c89c14b0fbf

If I’d be interested in “raw” data, I’d certainly look for ways getting closer to dataset generated by the watch itself. So either a fit-export or perhaps a json data that’s used as an input for SuuntoApp service and stored at <internal storage>/Android/data/com.stt.suunto/files/smlzip/ on your phone.

Any relatively recent installation of gpsbabel should handle fit 2.0 just fine, at least 1.7.0 works or me with SA fit-files and it was released more than a year ago. Though for up to date reference tools one should head to https://developer.garmin.com/fit/download/ , SDK includes FitCSVTool.jar for converting fit to csv.

And there are at least 2 perl modules for fit with at least some userbase. But why aren’t those in cpan, I have no idea nor interest to find out. Though popularity curve for the language during past 10-15 20 years might have some role in this …