Software release 2.30.26

Frederick Rochette

@Dimitrios-Kanellopoulos
Thank you for this message
Thank goodness it’s not the weather data
Please keep us informed as to when these bugs will be corrected.

Stefan Kersting

@far-blue thumb up for this

Majkel Paszeko

@far-blue What new platform you’re talking about?
New UI introduced already in 9PP almost year ago? Map module added in April with vertical release? Or these couple widgets added/reorganized with recent race release?

far-blue

@Majkel-Paszeko The 9 Peak Pro is, as far as I can tell, the first of the new generation platform watches on which the Vertical and the Race have been based. This is why the 9 Peak, Baro and 5 Peak won’t be getting the new features but the 9PP will.

sartoric

@Majkel-Paszeko said in Software release 2.30.26:

@far-blue What new platform you’re talking about?

hardware platform I suppose

BastMaSVSRS9PP

@wmichi I’m wondering if Suunto did this on purpose showing TSS etc from the day before on the watch. It’s not intuitive but wondering if there is some logic behind it I don’t understand. No excuse here just wondering…

BastMaSVSRS9PP

@far-blue Amen well said

Majkel Paszeko

@BastMaSVSRS9PP some explenation i heard from our local fb group moderators: that metrics in SA can be collected from multiple watches, co CTL, TSB is being calculated individualy in the watch and only sync from SA when soft reset happened. But it doesn’t convince me.
Metrics in SA should be always the primary “source of truth” whatever number of watches they’re collected from. Every watch (even if i use many and swap them) should pull these common metrics from SA on every sync.
While not doing sync for longer, watch should follow with its own calculations and keep updating metrics individually/internally so it shows very current informations always.
When it’s doing sync again, it shoul first send all missing trainings to SA, let SA re-calculate metrics, then pull them and let them override internal values.
Does it make sense?

Walter Samuel

I share the same opinion as far-blue. I would also like to add that Suunto’s development team will not be as numerous as, for example, Garmin has.

And still SV and SR are breakthrough watches! I like Suunto, I switched to Garmin once and then regretted it. Despite some problems, Suunto has heart. Just like the Suunto community.

The watch hasn’t frozen during activity yet after the update, that’s essential for me.

I would allow myself just two things:

I was expecting an improvement in SpO2. It still measures 99%. A useless feature, I wouldn’t even brag about it in marketing. Of course, I am aware that the watch is not a medical device, but even so at a price of over 500 euros.
Suunto metrics while sleeping. Fever today, passed the night, I feel terrible. And the quality of sleep? 72% with a heart rate over 70 and a sleep duration of 6 hours (alleged). I would have maxed out at 40% before the update. Some people are more comfortable with the new metrics. It’s probably subjective.

Thanks Suunto for the work though!

inkognito

@Walter-Samuel I believe that all metrics with new algorithms need to establish new baselines etc. Therefore, I would really give them a week or somethig before rating sleep quality and resources accuracy.

wmichi

@far-blue I don’t have 25 year of experience in software development, but my 18 years are also more than enough to know, that you are absolutely right. Endusers simply don’t see how complicated all of this can be. They only see the result and they can only judge the result. And if the result is buggy, it’s buggy.
Ordinary users just want a product to work as advertised, they don’t care about code refactorings, migrations, unit tests, reimplementations of existing code or whatever. Why should they? If you ship buggy software, people will complain about those problems until they are fixed. We just have to deal with this.

GiPFELKiND

@Dimitrios-Kanellopoulos said in Software release 2.30.26:

Tss etc values are off by one day. Known issue.

Does this clear the discussion?

Yes but when this Problem will be changed?! Why this was not seen by the beta testers before bring a new watch out

jjpaz

@wmichi said in Software release 2.30.26:

Ordinary users just want a product to work as advertised, they don’t care about code refactorings, migrations, unit tests, reimplementations of existing code or whatever. Why should they? If you ship buggy software, people will complain about those problems until they are fixed. We just have to deal with this.

That’s the point. Users want a product to work as advertised (and expected) because the’ve paid for that product. This isn’t an Open Source software like Intervals.org or something like that so users/customers are going to demand the correct behavior.

far-blue

@wmichi If I wanted to summarise my post, it wouldn’t be “Bugs happen, deal with it”, it would be “The developers will have been pressured (completely understandably) to release by the marketing department but the slow updates, lack of communication and lack of features over the last 2 years should be a thing of the past and bugs should get squashed within weeks so be hopeful, don’t despair :)”

Of course, this is entirely my guess and I have no internal knowledge so I might be completely wrong.

wmichi

@jjpaz I am one of those people. And I submit bug reports, because I really like Suunto watches and the app. If I wouldn’t care I would use another brand. While Polar seems to be at the end (not an expert, it seems to me this way), Suunto will make a big comeback, I am sure. All of those recent developments are awesome. Just a little bit buggy

@far-blue That’s also what I was thinking, good summary. Of course it’s always the management/marketing/the money/market pressure. That’s no sarcasm, in my experience this is simply how the business works. No dev has an interest to ship buggy software. That’s something we should not forget: everyone is doing his/her best: devs, testers, support,…

far-blue

@jjpaz There has been a cross-industry shift over the last few years due to the implementation of automatic over-the-air updates in products. The benefit is new features on existing hardware and, often, new features arriving more frequently. The flip-side is that there’s also often more bugs. It all boils down to market competitiveness - it’s more commercially successful to release features with minor bugs if the cost of fixing those bugs is low. If you hold off on a feature release when your competitors have strong offerings then you miss out on sales. Before OTA updates, the cost of fixing bugs was much higher - initially because you needed to replace the hardware and then, more recently, the support helpdesk resource costs of explaining to users how to do a firmware update via their computer. This meant slower release cycles and more testing. You can see the exact same pattern across TVs, home security products, even xmas tree lights! I’m not saying it’s a good thing, just that it’s a thing And Garmin have had their fair share of dodgy updates over the last few years - hence why they have a beta community testing program.

BastMaSVSRS9PP

@Majkel-Paszeko yeah that makes sense. Thanks for explaining !

jjpaz

@far-blue Yes, I know the “new” industry process. In my company we are “fighting” every day with our own developments (and bugs) and the third-party partners software and bugs.
Also our customers demand us to correct the issues as soon as possible.
Some issues are solved as soon as possible, some bugs are acknowledged and delayed due to “script requirements” (or more commonly, priorities).
It’s not easy to find the balance…

What we do is allow downgrading to a stable software version (or previous one) in case of a serious failure. I think Garmin also allows that.

DrSilverthorn

@Maryn I would disagree. The problem with more features is more bugs. And Garmin is the feature king. I’ve got an Enduro - it was a great watch until Garmin pushed an update that broke the course guidance display. Five months later, and it’s still broken.

I think it’s important to pay attention that core features work. Of course everyone will disagree on what those are.

Dimitrios Kanellopoulos

Let me add that not all development is the same. You cannot compare web development to embedded development nor android etc.

So while everyone speaks with experience it doesn’t mean we have to argue all the time.

A button takes 2 seconds to style on html, 2 minutes on Android and perhaps 1 day on embedded.