sample set movescount.com uploads Jan.15 by device family
-
@pgrey What do you mean with monolithic vs layered. I am in the field of SW dev (not for Suunto) so please go on.
-
@Dimitrios-Kanellopoulos Bricked and effectively-bricked/non-functional are different, in this case, but only slightly.
If you can’t use it to track things like DH skiing, because apps are no longer supported, well, then it’s “effectively bricked”, right?The only difference, is that it might be possible to sell it still, depending on how far the “bottom falls out”, once this is more common knowledge.
The bizarre thing to me, is you can go to the Suunto Sales page, right now, choose “Alpine skiing” as one of your desired activity, and it’ll suggest the Ambit3, as one of the watches to purchase. There’s NO mention, anywhere here, about how the activity will be disabled, in about a year (possibly earlier, if you want to port your data over, from the activity).
I’ve owned mine a bit less than 2 years, and am VERY frustrated with this, but I can’t imagine how I’d feel, if I purchased it last week.Like I said, I’ve been a Suunto customer for over 2 decades now, and this has me researching where I want to go next, in terms of finding a brand that has a more long-term support model.
I like the Suunto h/w, and the MovesCount site, and all my previous models, to-date, but the (apparent) “future model” of rapidly “aging out” existing-functioning watches, is something I want no part of. -
@pgrey hi why will exactly alpine skiing be removed ? Am i missing something ?
-
@pgrey I would really suggest to wait till our summer announcements before you make any next move. Till then your watch will be fully functional anyways.
That is if you like your watch and suunto for the last 2 decades.
-
@Dimitrios-Kanellopoulos Sure.
If you build a monolithic model for something like this, ALL your data flow is contained in one module, or a series of modules with zero re-usability.
For example, there’s a “convert data blob for sport mode to DB XML” function, for each device.If you build a layered model, with an object-model(s) in the middle, then all the “heavy lifting” of the data conversion, DB/XML work, etc, is all contained in modules that span any device, because the data model is all common for these operations.
There are modules “per-device”, that sit on the bottom of the stack, and simply retrieve data, and push it into the data-receiver-OM.
This means, that if you make a change, in ANY module above the device-modules, the abstraction completely removes the data from any fixed data-source.Pretty much all modern s/w is written this way, if designed properly, because it scales, very easily. Any OS these days, for example, doesn’t care if the data for an operation came from a HDD, SSD, an iSCSI connection, a thumb-drive, or random network device, as long as the modules below it “abstract the data properly”, as a “pure storage module”.
The same model follows, if I have a 10-button mouse, and my OS only officially supports 3 buttons, I can add a layered-driver (a very simple one to write, BTW) that grabs data from those other 7, and adds it to the data model, say for a few specific apps (that work better with the 10 button setup).You can add to this model easily, for future devices, as long as you keep the current abstractions constant and inherited, the “additional data” is essentially “optional”, but fully supported, and has NO effect on older devices.
This also allows easily adding new functions/data-sources, say from Bluetooth6, 802.59xyz, or whatever, that might be more efficient if added, without changing any of the other data-flow modules, as they’re still getting the exact same data from the OM-abstraction, just from a slightly different source (that they have no knowledge of, or need to have any).If you work in a s/w role (as I have for going on 30 yrs now), I’m sure you’re familiar?
Not having an object-model/layered design (2nd is generally more around OS or device work, but the abstraction is essentially the same) is okay, if you’re writing a “simple utility” or similar, then a monolithic design is quick/cheap.
Not having an OM/layered design, for a multi-device, multi-data source, design is possible, but quickly gets incredibly difficult/buggy/expensive to maintain.
Which do you think is the case here? -
@Dimitrios-Kanellopoulos said in sample set movescount.com uploads Jan.15 by device family:
@pgrey hi why will exactly alpine skiing be removed ? Am i missing something ?
No, but it’s not very useful, if you can’t count runs, and look at per-run data, it’s almost like you just “rode all over the mountain” on your MTB, or similar.
This is WHY there are numerous run-counting apps that have been published, to-date. Most are really simple code, you can take a look if you’re interested.If these are disabled, and Alpine Skiing isn’t “enhanced”, like it is on more recent watches, for the Ambit3, then my 2YO (and very expensive) Ambit3 becomes a “path-tracker”, on the ski slopes.
I think Suunto has completely ignored this, I bet they know exactly how many people use these counters, and are just figuring we’ll all just buy new watches, or whatever.
I’m not about to go buy a new watch, given the way this has been handled, in particular the fact they’re still selling this watch for this function (this seems like an outright scam, to me), but don’t call out the fact that it’ll be disabled, in a year.The CS person I talked to said there was no plan to add anything to Alpine Skiing, do you have some information that they didn’t?
-
@Dimitrios-Kanellopoulos said in sample set movescount.com uploads Jan.15 by device family:
@pgrey I would really suggest to wait till our summer announcements before you make any next move. Till then your watch will be fully functional anyways.
That is if you like your watch and suunto for the last 2 decades.
That’s one perspective. Say if the “summer announcements” show that we’re not going to lose all this functionality, then it’s a good thing.
With all customization going away, too, for the Ambit3 (and my Ambit2 becoming a “doorstop”), I won’t even be able to display data screens for road-cycling on it, beyond what Suunto deems as “necessary” for cycling, right?If I sell now, before this tanks (I’ve already listed my Ambit2, with a full disclosure about the support lifetime issue), it seems like I’ll have a much better chance of getting enough value from them to get into a decent used device(family), that shows continued support for multiple sports types.
There’s a LOT of discussion about selling/bailing across multiple sports/tracker forums, and a lot of rampant speculation, given the limited disclosure about this.
Currently, I’d say 75% of the people in these discussions believe, like myself, that we’re going to have a very hampered device, once we’re forced onto the new platform, along with the (lack of decent functionality) website.If Suunto wants to prevent this, or re-assure customers that their very expensive Ambit3 devices are still going to function, with most/all of their current sports, and still allow them to use screens that “work for them”, then they should make some sort of official announcement, IMO. If they don’t care about these customers’ perspective, and continuation as Suunto customers, then I guess they’re on-track.
-
@Dimitrios-Kanellopoulos You should read this.
I’m not the only one who notices the monolithic design issue, as it’s called out here too (in a slightly more subtle, but definitive way, still), along with the fact that recently-sold/purchased devices are getting obsoleted, at a rapid pace. -
@pgrey i am glad to have you here. Ill take some time to reply back, but personally talking please hold on.
-
Sure. Here’s an example of what it looks like, when I have a run-counter app, to push data to the site (either MovesCount, or Sports-Tracker).
https://www.sports-tracker.com/workout/petegrey/5c6dd27f0f3e495dc8a0bd41If I do this w/o the counter, it’s just a bunch of random data on the mountain, it includes the chairlift rides and everything, as one “big run”.
I guess you could manually use laps, to separate things, but remembering to do this (we are in 2019, right?) is inconsistent, and can be unpleasant, say if it’s 5-degrees-F, on a day (usually involves taking off a glove, shoving my coat and other layers out of the way, to push a lap button).I have a couple of custom-screens in my Alpine Skiing, which is really handy for at-a-glance stats, for things like number of runs, descent-per, etc (which Suunto obviously excludes in the Alpine skiing screens, because it has no “run” concept on the Ambit3 skiing mode).
I use a similar set of screens, and an app, for group sprint sections on when riding (road cycling), so I can see how I’m doing, at-a-glance, on a particular day.
Removing all of this pretty much means my watches are non-functional, for my use, and they either become auction items, or landfill items (which it seems like the Ambit2 Sapphire is, regardless).
Edit: I should mention, too, that it took me over an hour, with SA, to get my Ambit3 to sync a handful of moves (about 10/20), at which point it failed outright, and said it was unable to sync further (despite multiple retries). This is on a VERY fast phone, with an 845 chipset, Bluetooth 5.0, screaming-fast data pipe, etc, that can sync my cheap-o Garmin tracker I wear to track daily stuff (Suunto resting HR is way too inaccurate to even consider for this), in maybe 20-30 seconds (syncing a couple of days of complete HR/activity/sleep data, in that example).
Edit2: I tried SA, again, and it restarted at activity/move 1/26, and was still there after 8 minutes, when I decided to shut it down. Something is gravely wrong with Bluetooth (sync) on the Ambit3, and it’s questionable as to whether or not this would be an app-side fix, IMO/IME. But apparently that’s about to become the “sync standard”, right, whenever the data-port happens, you’ll have to use SA, going forward?
