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:
71745508-45ff-411c-b179-5c5f9f6260d5-image.png
vs my F6 (ice skating, lot of stops, “smart” recording; gpx from Suunto App):
4101a754-e70b-4ae7-8efc-5a0155e36d70-image.png
vs Ambit3P (bike commute, note those 40+ km/h artefacts; gpx from Suunto App ) :
abecdbd8-0d6f-43ef-91e5-f1834e509b1c-image.png
vs same A3P activity but taking speed directly from fit-file (and x is point index instead of time):
2ebf689c-aa29-4bc6-93e7-268aeec2efae-image.png
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 …
