BUGS BUGS BUGS. When will be solved?!?

Me and other user are months that we suggest to solve some TERRIBLES bugs on F6. Every time in every post of stable or beta release we wrote the same BUGS:
-HR detection in some activity like hiking is totally inaccurate. Recording with another f6 on the other wrist, but with an activity like walk, the  HR is more reliable. It's from november that we ask to solve this problem.
-Altitude profile in navigation: the altitude profile of the route we planned in navigation mode, most of the times is garbage...in a clear descent on the maps, the profile altitude shows an ascent, or a plain route. This problem is obvious also in the last model of fenix, so are YEARS that we WROTE this bug.

But Garmin prefer to add dogtrak , sleep detection or other functions.

Due to this is a watch that must be used for outdoor activities and not to count how many times your dog make a poo, GARMIN, PLEASE, HEARD YOUR USER AND SOLVE THE BUG THAT WE NOTICE FROM A LOT OF MONTHS!!

  • Was trying POI's. I don't have any saved locations saved....

  • Sorry if i said this, but why you defend Garmin with this strenght? 

    As we said, since f5+ there is this bug, with all maps in every place (i try in a lot of part of italy, in france, usa and greece), with all version of fw, garmin forum is plenty of reportings, same in reddit forum. Developers said "we are working to fix it", but said this 2 years ago.

    I spent about 1600€ to buy 2 fenix, i prefer this watch against polar or suunto 9 baro for the maps integration, but if a simple function that is a base for trail runner and trekker like altitude profile is totally crap, sorry, but, garmin is not a serious company.

    A bug is possible, but please... Solve this as a primary goal of the Developers team... 

  • Who said defend? I'm trying to work out where the bug originates. For a start, it's never affected me. It's also not something I've seen reported anywhere else.

    So rather than attack someone trying to work out where it's coming from, and was actually going to try and see if they could replicate it - perhaps ease it back a little and realise that just because it affects some people, it doesn't affect everyone.

    I live in a very hilly area of the UK, I run in the beacons. Mos of my runs hit at least 1000ft elevation, often a lot more. I use maps and routes a lot, I rely on the elevation charts and pacepro to manage my runs. I've never seen this bug.

    EDIT: I mean ClimbPro not PacePro - but I do use PPro less often than CPro

    So it's not defend, it's trying to work out where it comes from, how to RELIABLY replicate it - because reliable replication is key to finding it.

  • And I know Garmin's arent bug free as I report a lot of issues to the beta team, have provided more data to the team when requested on some issues, did a lot of working out on a livetrack issue and identified the cause.

    Fixing a bug often relies on reliably reproducing it, so you can trace back and find the code. My guess is there's some sort of overflow going on in calculating the profile that screws it up. Finding out exactly WHAT is that miscalculation will mean the difference between fixing it or it staying as something that only affects others,

  • I don't do a lot of course generation on the watch because... well trying to plan a 32K run on a small screen, with maps that dont show all the sheep trails and small paths I use, is a bloody nightmare. But I do use Basecamp (mainly for Ultra's so I can add aid stations etc) but MOSTLY use plotaroute or garmin connect (often the two in tandem) to plot off road routes using the satellite maps.

    But I am off out for a long mountain walk with the dog later, so I will try navigating to a POI and see what happens. But to be honest I find the inbuilt calculation slow and problematic. Give me a widescreen and wider view any day!

  • https://forums.garmin.com › project...
    Risultati web
    Projected Elevation profile STILL wrong SINCE v 7.10 when navigating a route - fēnix 5 series ...

    The first result that show the problem. But only with the search function i find almost 10 post in the first page with the same issue.

    I spent a lot of time with developers, i sended bug reports and other datas, they can reolicate the problem (as they said), and then? 

    Still ignore us (because we don't receive neither an answer) but they still works in new functions.

    In the italian presentation of f6, an ultramarathon around "monte bianco", with also garmin maps, during its presentation , the bug are clearly present.

    So... Shame on Garmin 

  • I think I may have found one reason why I don't see it, if my DEM suspicion has any merit.

    I use Topo Light UK to plan routes (in Basecamp) and on the watch. That map looks like it has it's own DEM data as if I plot a route on Basecamp using TopoActiveEurope SW (which covers me) there's no elevation data as the DEM data is a separate map.

    If I select TopoLight in Basecamp and do the same, elevation data is there.

    So possibility as far the bug with basecamp may (note MAY, i wonder if other people could correlate) is that if a route without elevation is transferred and the watch has to generate it, that's where it goes wrong. When I have used BC, I'm using maps (either TopoLight or Talktoasters OSM) that have their own DEM...

    Happy to be proved wrong or right, just wondering if people seeing this with Basecamp routes can confirm/deny

  • Basecamp and other software on pc, use contourlines and interpolation to calculate the elevation profile due to is more accurate, but more stressfull for cpu (but pc has no problem). Same situation with oruxmaps and other SW on smartphone, is not necessary that the maps have DEM in it, need only contourlines in a separate layer (and this is a standard from about 15 years :D, only the topolight and other very light maps has no separate layers).
    On F6, but also in other low spec device (as an example my gpsmap 64), in a map without DEM, the route calculated on it doesn't provide profile altitude. Garmin "crazy" system calculate the altitude profile only if there is in the same "garmin" folder a map.img that has DEM in it. (ie. in the gpsmap64 in the first mapsthere wasn't DEM, there was a generic european DEM and then a trekmap for each state, but the quality of the DEM was really bad, then they increase the quality of the DEM embedded it in the trekmap).
    In the F6 is the same, if you remove all the maps and put in it a map without DEM, the altitude profile is constantly equal to zero (and if you have "climbpro" setted to active, the watch freeze and reboots when you are in the page of climbpro...another bug that I noticed on november never solved), if you put a map that has DEM in it, also if you mantain it deactivated, the garmin device use it to calculate the profile altitude. Due to the excellent works of OSM, now in Italy, but also in other european countries, the OSM based maps are preferred due to the extreme accuracy and the hi res DEM integrated in them (the same DEM used by Garmin in its maps).

    Due to this fact, is important to notice how the routes is transferred to the f6. If you use a simple gpx made manually from a SW like basecamp, if you don't tick "export elevation data", is a normal plain route that the watch project to its maps. In this case the elevation profile in our case is wrong. if we export a gpx with elevation profile in it, or we import a gpx aquired from another device (or also from the f6), the elevation profile is correct most of the times.

    Similar bug of incorrect altitude profile was in gpsmap 62 (yes, i owned a lot of garmin devices), but was solved very quickly in its time.



  • Thanks Stefal, that definitely explains why I hardly see it as I always export elevation profile!  Right when I get chance I'll try and break it and set what I get !

    That explains a lot :), thanks again