Dashboard slope /gradient enhancement

I would use at least light altitude filter, as GPS altitude is more jumpy than GPS position.

As slope is derivative of elevation per distance,

and as derivative of noisy function is much more noisy functions,

then it is quite obvious, that even if elevations ( especially filtered ) quite fine,

slope can look funny and useless,

>I would use at least light altitude filter, as GPS altitude is more jumpy than GPS position.

yes, fair point

Compass direction is not much usefullfor bike, rather useful for slow walking and mainly geocaching.

But even for bike, compass may be useful for initial orientation in unfamiliar place, as a biker may be confused which direction he should start.

It *would* be useful for me, when I stop cycling, for orientating the map, however it is unreliable. Nothing I can do about that.

You may need to use stronger compass orientation filter, but obviously not at steel handlebars.

Ah, OK, understood :)

The experience with my phone (Xperia Z1, no barometer or pressure sensor) is that any slope measurement derived only from GPS elevations is mostly a waste of time. Even a visual inspection of recorded track elevation shows the folly of using this data. On a standardized 3.6km training walk with 70m elevation, I have overlaid 6 identical tracks from Locus Pro into Basecamp. Position accuracy is generally +/-10m. Starting/ ending elevation should be 220m. GPS locked on 5 minutes before start of track recording. All other test conditions made as standard as possible.

Unfortunately I do not have a track recorded with pressure sensor elevation data, but it would show far less variation in the elevation in any 200m interval/ would be far smoother.

On the other hand when I walk or otherwise simulate a bike ride using the "GPS Status" app I can see good filtering of the accelerometer and/or gyroscope sensor data.

@LIbor:

I cannot understand that and the solution could be to provide two methods to configure GPS and gyroskop.

When I use to dashboard for cycling the gradient field (via GPS) is almost useless because it is way to inprecise and faulty.

@Andrew: Your problems with the altitude is only because of the lack of a barometer. A barometer makes elevation much more replicable because it is much more precise when calibrated (GPS and barometer with filtering). When you need more precise elevation information I really recommend to buy another smartphone.

But Locus has this feature (usage of barometer) implemented instead of my problem with the faulty gradient. The barometer is implemented in the compass but this information is not used in any other part of the application.

Hi guys,

did you tried in "Altitude manager", select option to replace (optimal for a flat terrain) or optimize (for "hills") elevation data by SRTM values? In case, you have downloaded elevation data, this option may highly improve results of elevation chart and also gradient values/chart. Give it a try.

Hey Menion,

thanks but the problem of the thread opener and mine is not elevation data. I use elevation optimization via SRTM and barometer with a strong filter and this is ok.

The problem is the actual measurement and display of the gradient, like this (I hold my smartphone horizontally on the picture with gradient approx. 0%):

Please see my post 1 year ago how to solve this issue.

It would be better to use the gyroscope data instead like on the video where I tilt the phone:

https://www.file-upload.net/download-13249029/IMG_4426.MOV.html

Best regards

@hannes - yes sure built in barometer is best solution. Simply reporting my experience. I think majority of phones do not have a built in barometer; so gyroscope data seems like a nice solution.

@menion - graphs are using ultra filtering and SRTM optimization. I gave up using these settings & reverted to no filtering/ no SRTM optimization. Basically I don't think too much about elevation accuracy anymore. Maybe future phone will have a barometer.

Don't expect much from the barometer, it is an huge improvement but you still have the same problems with tasks like summerized uphill elevation of an track:

http://help.locusmap.eu/topic/threshold-for-altitude-changes#comment-60178

The only reliable way is to use SRTM data. Only if you have a rough landscape with canyons and cliffs you will get trouble with SRTM.

Relative accuracy of pressure values is arround +/-0.2m and even with this over 10 times better accuracy you won't reach the reliability of SRTM.

Gyroscope does work only for steady phone mountings. And I am not sure how stable gyroscope data is when you have acceleration. If it is stable enogth it is maybe worth to implement a second application which display it as a small overlay like I did for the elevation problem.

Hello,

SRTM is too indifferent (horizontal resolution of 90x90m), no usable in hilly terrain. And it will fail on bridges and tunnels.

But SRTM will be correct in 99,9% of the rest of the track.

There is no solution for everything, you have to select the best solution which is still affortable. If you get only 0.1% improvement it is not worth it to spend time on this.

Even 90m resolution is not an issue, just look at your average track and calculate how many meters of the track have more then one mountain peak in 90m. Hills are not like a citiy skyline where you need a hight value every 10m. It's enoght to have one every 90m. Even if you have 100% climb rate 1000m on point 0 and 1090m on point 90, in most cases the calculated assumtion of point beween an 45m should be "1045m" is correct.

SRTM fails only on 0.1% of the track based on briges and tunnels. And on tracks in canyons or on the edges of cliffs.

By the way 30m resultion is not only available for alps you could get it for most europe regions, it's just difficould to find a server which does host them because it's uncommon to need them outside of the alps. And if you realy don't find them you could create them with special software based on free available data.

>Don't expect much from the barometer

I have compared my phone (no barometer) with a cheap Garmin GPS unit (barometer) over the test route in my above graph, and the results from the Garmin are far more reasonable. Maybe not absolute accuracy, but in terms of total ascent, and reduction in noise/ jitter of elevation.

>The only reliable way is to use SRTM data. Only if you have a rough landscape with

>canyons and cliffs you will get trouble with SRTM.

again, I have dozens of track recordings over the same test route, not show on my graphs above, which show using Locus Pro with SRTM data was not much better

We'll have to agree to disagree. And we seem off topic - the original suggestion is proposing acceleration sensors.

@Falco: If you live or cycle in hilly areas especially with slopes beside the street, etc. SRTM is not really useful. Lidar data is much better but not available everywhere, e.g. not freely in Germany where I live. So in my case is SRTM in 99% useless and I only receive reasonable height data with the usage of the internal barometer. It is nonsense that a barometer only brings an improvement in average of 0.1 %. I tested a lot of different settings in LocusMap (SRTM, GPS, barometer, profile intensity) in comparison with the data of Garmin, Wahoo users, etc.

But this all is NOT the problem in this thread and my problem. This discussion is only for the usage of a gyroskop to display the actual gradient.

I agree that it will not make sense to make overall height measurement with the gyroskop as this is to vague.

I just want to see a feature that I can display the gradient (additional) with a reasonable use of the gyroskop in the dashboard like every usual bike computer is capable of as they are not based on GPS but only sensors like a gyroskop.

@Hannes

I know you care about slope value, but "slope" is computed from a change of elevation and traveled distance. So it is obvious that is needed to move ( Locus record & little filter, these slope values if you move more then 05 m/s ).

I believe, key here is as accurate/stable vertical accuracy as possible. Horizontal precision should be during movement good enough in most cases.

Btw. slope value is already filtering from last 15 seconds (new values has a higher weight in computing).

---

When slope is so important for you, isn't then better to display directly pitch or roll values (angle of the device around X, Z axis, already visible in compass screen), with an option to display it in different units (percent) and option to calibrate on certain 0° directly over dashboard?

That is exaclty what this idea does describe. Make it able to use the angle of the device in dashboard.

Ah, but these values are already available in the dashboard. Search for "Pitch" and "Roll" values. Values are also displayed calibrated based on calibration in compass screen (just tap on small circles at the bottom with these values in compass screen). So only problem are units, which are currently based on defined "angle" units from preferences.

Well, didn't expect this. I thought if 16 people did request this that I don't have to look if this is already implemented :D

@Menion

I will check this later at home when I have the smartphone with me.

And yes it would be very useful to have the display in % instead of °.

Furthermore it would be helpful to calibrate a predefined value for each dashboard that corrects the real value.

e.g. my road bike has a mount with horizontally +3% my mountain bike with +6%.

So when I climb with my road bike a 7% mountain it should display 7% and not 10%.

I disaggree. it would not be reasonable to spend many hours into a feature like store calibration per dashboard if it takes just 3 seconds to calibrate it by "click on GPS, click compass, click pitch value"

Instead of spending many hours into save calibration feature it would be more usefull to take care of the high votet ideas where 100s of people did vote for.

There are still so many more thing open where people spend multible hours per week with workarrounds, where some development hours would save alot more then 3 seconds per bike change.

@Menion

I only wonder how manufactures of bike computers manage this btw. which data they use.

Do pitch and roll values have to be calibrated like compass (north-south)?

Because with a regular bike computer the slope value works fine without calibration.

@Falco: Sorry but your solution would mean that everytime I ride a bike I have to find a flat area and calibrate it. Without a predifined value all the effort can be saved in total becuase it is not practical.

@Menion: It would be good when the converion from ° to % would arise from a X.X° value and not only from a X° value to be more precise. A display of X % is sufficient though.

Does anybody have one? Would be nice if somebody could play arround with it. I would guess that every bike computer with slope featre does have pressure sensor.

Does anybody know bike computers with slope display and no pressure sensor? I would guess that there isn't one because of the calibration topic which isn't that simple for the average bike user. Most of the user does even complain about pressure calibration.

Based on the magnet wheel speed sensor it is more easy to disable false slope value detection for non moving situations like your 11% dashboard slope example. I guess a bike computer can't messure slope changes if it doesn't move forward. But this is just a guess. Maybe there are solutions with pitch sensor which do auto calibrate based on situations where a pressure sensor based slope detection is very precise.

For example calibrate pitch sensor based on pressure change if there is no acceleration and we have movingspeed > 10km/h

That would be the german answer for this problem, komplex solution for a little problem ;)

Man, that would be fun to implement with tasker, we would just need to be able to set pitch sensor offset over locus api and a dark rainy day in the winter time :D

If other manufacturer calculate this via pressure sensor it would be the best to use this sensor because all implementation is useless when you have to calibrate it (every start or during the ride) because you dont have a hand free to swing the phone around.

My only complaint was that the current value in dashboard based on GPS is not precise at all that means useless for a current display of a slope. And it is also not precise when the wheel spins. My picture was just an example at home.

@Menion: Maybe this description of Garmin how to calucalte gradient is helpful:

https://galebernhardt.com/blogs/news/how-does-garmin-calculate-percent-grade

So this just means that the value for gradient already implemented should be calculated in addition with barometric altimeter sensor and speed sensor WHEN the phone has the corresponding hardware.

Well, if you want to have barometric values, then you don't need this idea.

Just enable it in altitude manager and every altitude get replace by pressure messurement.

I would still like to see pitch sensor usage in dashboard with % values for 2 reasons:

1. for people without pressure sensor
2. for static messurements without movement speed.

And keep in mind not every phone with pressure sensor is able to messure air pressure, For example pressure sensor on sony phones is sealed into the phone and used to tell if the device is still sealed. You need to remove water seals on Sony phones to get air pressure values.

@Falco: This is not true btw. is not my problem. I have barometic pressure enabled under elevate measurement but this does NOT effect the calculation of the gradient value in the dashboard. It ONLY affects actual height measurement.

I cannot speak for sony but my samsung is IP68 too and the pressure sensor works as expected. And it is not a problem becuase there can be a different calculation depending on the sensors available.

Maybe it is more easy to add the decive angle from the compass view to the available dashboard elements instead of a configuration of replacing the existing slope calculation?

That means overall we need the following:

- configuration UI for enabling it, old method is default

- UI for calibration would be nice but a less complex solution would be to tell the user to calibrate it on gps/compass screen

- a help text or section in the documentation which warns for acceleration based error values

- a documentation section which describe that elevation change related slope messurement is based on GPS, presure or SRTM

- don't record it just display it like on the compass screen

- add device angle to dashboard and display it as unit %

+1

I've never needed the use the compass screen before- but just checked - the angle is fine, it could do with some heavier filtering and allow units as %; then just add field to dashboard toolkit - perfect

Please define "heavier filtering"

It could be take a lot of effort to find good filtering parameter in real word tests.

Some one would like to use average across last 5 seconds and others like to have the average of the last 120s

@falco - if I tilt my phone back & forth quickly the displayed angle is updated very responsively - many times per second. I have never checked the angle on a bike because I usually have a map displayed but I would imagine this could be averaged across last 1..5..10 seconds which would ideally relate to real-life change in road gradient. In other words I do not need to know road gradient is changing many times per second, but 5 seconds would be useful? On the other hand an average over 2 minutes is of no use to a cyclist because road gradient could change a lot in that time. I hope that make sense?

if we want to exclude a filter configuration to make it less complex we would need to agree to exaclty one set of filter parameters.

What about reusing the filter of the current slope calculation?

That would be average over values of the last 15s by default

As I tried to explain I'm not too fussed about the filtering. It just needs to be slower than many-times-per-second. 15s is quite OK for cycling. 120s is too slow. How do you know the filter of the current slope calculation is for the last 15s? There is a choice of light, medium, heavy, ultra.

Are you sure that this choice is used for slope calculation?

Menion did told us that the slope calculation is bases on last 15s

Btw. slope value is already filtering from last 15 seconds (new values has a higher weight in computing).

Please be aware that pitch/roll, as well as orientation, is already filtered.

All these values are received cca 15x per second. Here is used the simple filter that computes an average value from last X values, where X is by default set to 10, but may be changed by "hardware_compass_filter" parameter in config.cfg .

That mean we would need to manually change it from 10 to 75 to get 5s average.

I am not sure how many of the 16 people would like to do this. But we have to touch locus anyway to change the angle from 0° - 359° to percent because it's a little bit difficould for humans to translate 340° to slope percent.

perfect summary of desired requirement (from my point of view at least), well done Falco

keep in mind that we still have to change "hardware_compass_filter" parameter in config.cfg from 10 to 75 to get 5s average but it's limited to 50. I did already check what happens if you exeed the limit, if you put in 500 and count down how long it does take to update orientation from 40° to 0° it takes just 3s instead of 33s which means the 50 is really the max value :(

50 (3.3 seconds) average is fine for me but I am not sure if everybody is happy about it because we do sacrifice the compass as well. I am ok with sacrificing compass responsness because I don't use this anyway because the calibration for bike usage is way to hard.

By the way, it wasn't as easy to get this config.cfg to work because on my system I did get an empty config.cfg. I did try to delete it with "root explorer" which didn't work. I did need to use a terminal, manually login as root and then I was able to delete the empty file. After locus start it did create a new prefilled config.cfg where I found the setting

# filter value for an compass system. (default:10, max: 50)
hardware_compass_filter=10

thanks for the tips

I have no problems editing config.cfg using Jota+ app without root access

max:50 is a little low (3.3s) but I can live with that if making minimum of code changes

This -180 to 180 instead of 0 to 360° is actually a bug because my sony does display -180 to 180 and my samsung do 0 to -360

http://help.locusmap.eu/topic/pitch-value-range-is-broken-on-some-devices

Hello, I see that this topic has been talked about for a long time, I just wanted to know if there is finally the possibility of showing slope using the accelerometer in percentage (%) instead of in degrees (º)

Hello Jose, this option was not (yet) implemented in Locus Map app.

Thank you for the quick response, and since you say "still" I understand that at some point in the future you will do it, without the intention of bothering, do you have an approximation of the date on which it could be?

I'm worried Jose, that such minor, but quite complicated tasks have a very small chance to be implemented in the current situation. We are now only two developers who work on the Android app version and there is 100+ other tasks, that have a lot higher priority. Sorry, a thanks for understanding.

Hi all,

is there an option to have slope % in dashboard on watch app?

Simon, it might be possible using tasker and locus tasker plugin to get information, and then send it to the watch, bit not part of the locus widget.....

thanx

too much for me this i guess.

will wait for future updates 😎