@sylvain73 sorry if it has been unclear. iOS we add pretty much all who register. For Android I’ve added maybe 1/3 now and have notices the issue with the emails we have, so I’m trying to fix that by modifying the registration form to state about the email attached to users Google Play account.
If we add emails that are not used in Google Play you may join but are not able to install too easily. Have to see if we can get rid of the Google group stuff when this beta is changed to open beta. The Google Group seems to be really confusing to a lot of users and makes the installation of the app complicated.
So copying those Google Play emails from the replies (>80 and counting) now and adding more people to the Group soon.

Both of which would be great on iOS (top time chart on a distance - not a given route, and similar route comparison) 😉
Do we know if that will be inlcuded in the next beta version (and when a new iOS beta version will be available?)

Thanks!

Hi,
I transferred all moves from movescount to TP, and perfect.

Brethren.

As I promised, I have been trying out the routing elements of the current version of the Suunto app (beta version 1.6.0 (6801) and Spartan Ultra Firmware 2.5.18) and I am posting my latest findings and feelings.

Before I get into it I must highlight something…the “you have arrived at your destination” notification that was going off every couple of minutes and doing my head in…hallelujah! Bye, bye and good riddance. It was so annoying and appears to have been resolved so there is one definite plus. Unfortunately there seems to be the introduction of another couple of small glitches which I think I should post on the bugs topic.

Anyway; routes! I said I was going to test them both in the planning and use, and to assess the accuracy of the altitude/ascent data. I planned 3 different routes and the numbers and conclusions are as follows:

Route 1; Planning on Suunto App = 6.41 miles with 502 feet of ascent.
Riding the route - 6.37 miles and 468 feet of ascent.

So the difference between theory and real life is 0.04 miles and 34 feet of ascent. I would go so far as to say that is pretty much spot on really; well done Suunto.

Route 2; Planning on Suunto App = 10.5 miles with 927 feet of ascent.
Riding the route - 10.5 miles and 954 feet of ascent.

So the difference between theory and real life is 0.00 miles and 27 feet of ascent. I would go so far as to say that is pretty much spot on as well!

Route 3; Planning on Suunto App = 28.5 miles with 2035 feet of ascent.
Riding the route - 28.6 miles and 887 feet of ascent.

So the difference between theory and real life is 0.1 miles but 1148 feet of ascent incorrect. This is clearly not very good but let’s keep this real. the route was along an old disused railway line which meanders its way through rolling hills and valleys and parts of the route would have been artificially raised or lowered to create a fairly level and even route. If you look at all of the contour lines etc. then I reckon that it is probably pretty close and so I think I will have to accept that this is not the best route to use for this test (or am I getting soft lol). So, despite my criticisms of this app, there are definite improvements so far and I am prepared to say that the ascent data for the route planning is, on the whole, pretty spot on.

I will continue to keep an eye on all of these points but for now things are definitely on the way up.

Keep up the improvements please Suunto

Word! 😉

Keep me posted.

@Tim4c yes it isn’t an issue, it would just be easier to save one file with multiple legs then have each leg as a file in its own right.

@remib I know, all GPS I have had for the last 20 years have coped with legs. I noticed the Wahoo of a friends doesn’t. It isn’t a problem but even loading the track to SA needs to be done x amounts of times instead of once.

This is nice to have to progressively overload and not stagnate. Do 1 more rep/1kg more than before, this is super useful for me so I don’t stagnate. I am an endurance athlete, but do strength training 2-3 times a week. If you do same thing over and over agin, you just don’t improve, running/cycling is easy to track progress, you need for other workouts too. I fully support this option 🙂

@Łukasz-Szmigiel then your UX will become even worse

@Mff73 In my case I have Suunto5 and I did a big activity, 5hours and half of 110 Km, recorded on the watch. It keeps syncronizing and it seems that everything is fine but could not “read” the activity. Finished the activity I did a second one, 25 minutes stretching, and the app synchronized this latest, in a normal way. So it seems the big one is like invisible for the APP…any proper solution to suggest on this case?

Ok, I will do that when I finish with work. Thank you all for help.

@mff73 said in Calculation Trainings Peak Parameters:

Posting here by default.
I walked 3 days ago very slowly with my father, without HR measurement and with my SSU.
2 hours for 4km 😂😭.
But this activity (saved with hiking profile) gives TSS Met = 101 🤪. Looks like a bit too much.

i found something quite “strange” or “interesting” about TSS.

I recorded an activity, slow Hiking, but 3h duration, and SA calculated TSS : 150 MET (no HR recordings).
I exported this activity fit file, and imported it to my wife’s SA account (with QS), because she forget her watch.
Same pace, no HR, same activity.

But in her SA, this imported activity was calculated with TSS : 53 MET
this value looks more related to 3h slow hiking, than my 150 🙂 (which influence a lot my fatigue/fitness).

is it something that can have good explanation ?

Another update on this, I just wrote a simple script in Python to manually compute ascent and descent of all tracks and routes contained in a GPX file, and the result for this file is 3598 meters of ascent and descent.

This is the same number that we can see in SA. So simply SA does not apply any filter to the data, and counts every meter of ascent of the GPX file.

Conclusion: I will not open a bug with Suunto. Maybe not very sophisticated, but the SA implementation is coherent with the data.

@Brad_Olwin Ok

@brad_olwin Thanks a lot!!!

@dima-h2o ok, thanks for that. I’ll try both apps with just paired to MC. it may be an ios thing

@Agustin-Gonzalez-Perez-Corral there will be route planning improvements.

@silentvoyager all data are recorded in speed units. I am not talking about first averaging the speed and then converting.

The rounding is about the display value. Makes sense? On the chart 30 difference on the avg that is what I was talking about.

@mcindr moreover it was possible with old models (I miss my ambit 3 so much!!) but it was possible with the spartan, and it was a key feature of this model! Suunto is lowering its products… We are all sportsmen and sportwomen here, I think we need sport watch and not apple watch or samsung gear. Please Suunto give us back our original features!!

There is a document on how epoc is calculated at https://assets.firstbeat.com/firstbeat/uploads/2015/10/white_paper_epoc.pdf

There is an Ambit app that uses stryd power reading to calculate your energy efficiency similar to the running performance on ambit which was far more accurate than relying on gps data.

http://www.movescount.com/apps/app10645993-Average_energy_efficiency

Notice the level of filtering on Ambits Running Performance graph relying on gps vs the energy efficiency app relying on power data.

By the time you notice changes in Running performance graph to figure out whether you have proper hydration or enough carbs; energy efficiency app would react much sooner as it gets its data from accelerometers vs. gps and barometer on watch used by running performance. Your body makes subtle changes to adapt to current situation, it does not think about finishing line, thats what brain is for (or not). The sooner you notice the sooner you can react because physiological response to recover gets Progressively slower the father you fall in anaerobic energy debt.

Constantly changing wind speeds would render ascent descent baro sensor data invalid even on a flat surface no matter ambit or s9.

Epoc modeling has a delay, see white paper, basically loose ohr or belt ruins it.

Real time running economy would react sooner than any other method. Your model is based on power, sensor will not become loose or fall off (less likely than belt or ohr)

Or better yet, Having a small “sandbox“ for custom equations and graphs sent to SA from s9 like we did on Ambit To MC would stop avalanche of nagging user requests to add features. It would also let us innovate without consuming other peoples time on development. Few 32 bit floating data as temporary registers to implement equations is not much of a footprint these days. Add a few kb of data to support at 10s logging interval. It would just be much more fun even if it fed you meaningless numbers.

<nudge> <nudge>

@Dimitrios-Kanellopoulos

Hello ,
I also have the concern to transfer big move.
I installed version 3.6.x, at first it worked, but no longer I have a move of 12h and she does not want to transfer to the app suunto.
I am French, sorry for my English.
THANK YOU