Software update 2.13.18 for S series (S3,S5,S9)
-
@Brad_Olwin issue isn’t so much w the home location but I do rely on the watch face altitude when out backpacking. Useful in making sure I’m on the right/same level as camp…
-
@stromdiddily The work around for this is just use the auto-calibrate feature when you are at a camp. This always restores my altitude values.
-
Do you need to take watch off wrist for auto calibration?
-
@lexterm77 No, but I think it may be faster if it is off.
-
@lexterm77 I also tried GPS only today, but I have got a worse track than yesterday with Beidou. Will try few more times.
One interesting thing I noticed though, is that it seems (in a totally non scientific way) that I get better Fusedalti without Beidou. I will also check if this is the case in the next few days.
-
With Beidou my tracks are 5 meter apart, with GPS only they are half a meter apart.
One is GPS only around parking lot, it is spot on, couldn’t draw better myself.
Other one is trail run with beidou, single track trail is visible on sat image but tracks are like 15 meters apart.
-
My observations with current firmware (S5) as compared to older versions:
- GPS only is universally good except in deep forests or urban canyons. It’s as good as previously with Beidou.
- Beidou makes my tracks more “wobbly” and in my experience is the least useful system with current firmware.
- Glonass is ok but I don’t find it more useful in general everyday trainings (it’s superb in mountains though).
- Galileo - if there are enough sats available - is a monster. It struggles near dense and high buildings but in every other area it’s perfect for most of the times. I can’t think of a better track precision in a running watch.
Also, “offset locks” happen way less often than before. It used to be a norm when changing direction (ie. 90 deg) for the track to be locked on a constant offset by 10 - 20 meters. Now it happens rarely.
It may be placebo (as everything written above ;-)) but I feel that my tempo doesn’t drop as dramatically when entering wooded area. It used to drop from 6/min to 7/min only because I’ve entered the park from river embankment.
I also get an instant fix almost always.
It really is amazing.
-
Feature idea: use gnss data and route information to automatically select system with most satellites visible at that time, account for duration for completion of activity and terrain type (flat route no trees means you can catch sats at lower sky points while wooded area with lots vertical points on route means only high sky satellites are ones in direct line of sight or city routes) let algorithm decide best choice for you. Of course this would need to be done in app but with predetermined window of activity start time in lets say next 24hours would be passed onto a watch as calculated “best choice” for which gps system would watch choose for each route. I can see that some satellites are barely populated at some time of the day (8) while sometimes there are 12 of them. Each hour has its advantages. These satellites (most) are moving across the sky, they are not geostationary or geosynchronous orbits. If all this is complicated an artificial horizon can be optimized for universal satellite count at lets say 20 degrees above horizon and which system has most satellites is the one being chosen
-
@lexterm77
interesting idea.
I expect that this is likely never to come, because of a crazy bad effort/benefit ratio.
I mean, how bad is it really when the track we record is 5-10m off at some points? It looks ugly on the map, yes. But most of my tracks are well within what I consider precise.
I can imagine that it would take a lot of coding and even more testing before this type of algorithm works flawlessly.I’m happy with my tracks and if I manage to keep my baro sensor dry and clean I’m happy with the altitude, too
-
@freeheeler not to mention that Spartans won’t get any new firmware
-
@freeheeler basically this.
The only thing that I believe might be beneficial for all of us is an “auto” mode when you go outside the watch checks which sats are available and chooses the best GNSS at the moment. But this also is prone to errors as what the watch would choose at the beginning of the workout might be bad for the rest of it. Ideally the chip would use all GNSS available and mix them in the same way mobile phones do - just use the best sats that are available at the particular moment - but that might not be possible considering that we’re talking about low power chip. I’m not even sure if it’s possible to get a location from 2 GPS sats, 1 Beidou and 1 Galileo or do you always need to have a “base” fix from 1 GNSS and then augment it with other GNSS.
And in the end - why? If there’s no fix at all - it sucks, but if there’s ~15m error for couple hundred meters - why bother?
-
@Łukasz-Szmigiel
my wild guess: it needs at least GPS and all the others are the whipped cream on top -
Of course if choosing any option other than gps only renders track scattered, auto option would do no better than a random choice
-
@Łukasz-Szmigiel said in Software update 2.13.18 for S series (S3,S5,S9):
@freeheeler basically this.
The only thing that I believe might be beneficial for all of us is an “auto” mode when you go outside the watch checks which sats are available and chooses the best GNSS at the moment.
I think this is exactly how the GPS chip in the S7 does it.
Works pretty well. -
Can someone explain why ascents are somehow substracted with descents? My workout shows 28m ascent and 35m descent, where I can clearly see from the graph that it was way more (friend of mine with other brand watch had over three times more elevation gain on this route). 28m is just one longer uphill ride in the middle of it.
-
@lobo_tommy non baro version?
-
@dmytro correct
-
@lobo_tommy it’s all fine then. Alti graph is a representation of non filtered data ( threshold for non baro watches is 14m, or was it 7?) and ascend/decend values are being derived from filtering the data. So if you have two small decends roughly threshold sized - only only one might have remained after filtering. All other spikes could have been noise or not big enough altitude changes to make it towards the totals.
It’s not an issue per se, but a limitation of a device - feel free to search for ‘Altitude issues’ in the forum, it has been discussed plenty. -
@dmytro thank you very much, that is an explanation I was looking for.
-
@dmytro correct. 7 meters.
-
I isazi unpinned this topic on 18 Oct 2022, 09:48
