A. Bodner shared this idea 3 years ago

Calculating the slope/gradient via altitude (only GPS) / distance results in nonsense-values.

Apps like Clinometer use the acceleration sensors of the smartphone with precision up to 0.1 degree(!).

Using this technique with appropriate damping factor (biking!) and values only for the driving direction would be great (maybe second value for the inclination in sharp curves)

1

Disappointing there are no further comments or discussion for this topic.

While cycle touring over 7 weeks I experimented with displaying the slope on a dashboard. I found it necessary to have quite heavy filtering of the elevation (settings > GPS > Altitude Manager > Filter > ultra heavy filter) otherwise (as A.Bodner has observed) the displayed slope was "nonsense values" - values varying between +/-10% even with a constant gradient. I observed while nonsense slope values, the elevation values seemed quite reasonable? Why?

However by applying the heavy filtering to workaround this problem, it resulted in another problem - the elevation graph was also heavily filtered (of course!), and no longer accurate. See below - green track has no filtering, red track (of identical ride) uses ultra heavy filter:

Unfortunately it was weeks of recorded tracks before I realized my stupidity and lost detail/ accuracy of the recorded elevation. So I reverted to no filtering, but also giving up display of the slope.

Maybe the elevation and slope variables can be filtered (if required) independently? Or better still as A. Bodner has suggested, use the level sensor for slope calculation. I have found the level sensor very accurate and responsive, no delay for filtering/ damping. Tapping a "Calibrate" button could save the "0 degree angle" of the phone when mounted on handle bars.

2

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

1

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,

1

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

yes, fair point

1

Interesting Idea.

Aside of compass and barometer usage, it is rare to see in navigation software to combine GPS positioning and direction with orientation and acceleration sensors, creating a kind of combined Inertial Navigation Unit.

1

SURPRISE!! There are (now?) two values in the miscellaneous section for the slopes (inclinations) forward and sidewards and yes you can calibrate these values to zero via the compass screen for the mounted smartphone on the steering bar, BUT the units are degrees (not %) AND the values are not practical (upwards: 359° .. 357° ... etc., downwards 1° .. 5° ... etc.). Please adjust these and make me happy, when cycling in the mountains

1

Is the compass inclination used anywhere in Locus other than for display on the Compass screen? I don't think so. There would currently be a conflict between the "use compass below speed" setting, and using compass inclination above that speed. I don't use the compass at all (disabled) for map rotation because it is not accurate when mounted on my bike handlebars.

1

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.

1

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

1

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

1

Rather

use compass orientation below the speed. either with inclination either without it

use GPS bearing orientation above the speed.

1

Surely it does matter - while riding (i.e. speed>=value) I can assume the GPS can be used for accurate orientation. Conversely when I stop (i.e. speed<value) it is impossible for GPS to know which direction I am facing, hence swap to compass (if reliable). Do I miss your point? However, either way, this discussion is unrelated to the original topic suggestion of use of sensor for slope calculation instead of derivation via filtered GPS elevations.

1

Andrew, I have difficulties to really understand your point. :-/ Once you write about altitude (vertical differences / slope), then about compass (horizontal differences) - is it about one of them or both? And where shall the gradient been shown - just in the dashboard (overlay information in map screen) or also in graphs?

2

I suppose the Andrew's idea is to use the phone orientation sensors ( data of phone tilting are visible on compass screen, as orientation and magnetic sensors are related ) to correct and smooth altitude and mainly slope data. As the slope info is extremely sensitive to altitude data noise.

1

Ah, OK, understood :)

1

Georg D - as Libor so eloquently says.

1

I really can`t believe it! The proposal of using the magnetic sensor for steepness is available since months, but in a way, that makes no sense! When I cycle on a road in the mountains, I see for example 350 degree (or -7 degree, if it goes downwards).

Therefore a last attempt:

All over the world the steepness is measured in percent, that is the elevation vertical divided by the distance horizontal times 100. Mathematically this is the tangent function of the angle times 100 for per centum. Please be aware, the tangent function needs an angle in radiants, that is degree * PI / 180 and the range is usually from -PI to *PI. Please check, that uphill are positive values, horizontally is 0% and downhill ...

Once again: This value of the steepness especially for MTB-riders on the display of locusmap is similar important like the motor-rpm in racing cars. Of course it is only usable for bicycles, where the smartphone is fixed to the steering bar or stem. And you have to calibrate it. You can check the calibration by turning around the bicycle by 180 degrees (via the vertical axis) in a slanted position.

Yes, you can see the correct steepness also without motion! That is far beyond the posibilities of the Garmin gagdets!

I hoped that my hint using the second value for the lateral inclination in curves would produce a lot of discussion and protests. That was a nonsense, because the resulting vector of gravity plus centrifugal acceleration does not change the direction related to the smartphone sensor. Only when accelerating the resulting vector leads to wrong values for the steepness. Therefore no problem when driving downhill and using the brakes as long as the speed is constant (only the suspension fork will influence the correct value).

I and I think all people riding bicycles and using a smartphone fixed to the bike wish to have this value when starting in the new bike season!

1

The slope/gradient value is really annoying. Especially when using a smartphone it would be much better to use the values of the gyroscope / compass with the possibility to equal it to zero in advance (due to the gradient of the bike mount).

The slope/gradient via GPS is really useless and inaccurate because it differs between +/- 10% without changing elevation.

Furthermore there should be a limit in time (like 3 seconds) for measurement, so that the value is more precise and not changing like crazy.

1

Many people share same experience in many help topics and forum discussions.

+1

1

Is there really still no interest of the developers to provide a solution for usage of the gyroskop instead of GPS data only?

1

( Not speaking for the developer)

IMHO, filtering of accelerometer and gyroscope data during the real erratic bike motion is a bigger deal than the proper Kalman filtering of the 3D GPS position and 3D velocity, with low process error variance and high measurement error variance.

1

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.

1

@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.

1

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.

1

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:

Best regards

1

@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.

1

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:

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.

1

Hello,

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

1

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.

1

>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.

1

@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.

1

@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?

1

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

1

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.

1

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

1

@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%.

1

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.

1

@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.

1

@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.

1

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

1

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.

1

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

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.

1

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.

1

@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.

1

Maybe we could help to push this if we try to find a description of the minimum required change to find out if we did miss something or if this is ready for implementation.

if we look at the activities which could benefit from a acceleration based feature, we can't enable it by default:

- not usable for runners

- not usable for hiking

- only usable for static mountings

-- cycling

-- maybe car, but there is to much acceleration there to get precise data

Configuration needed?

- yes, I don't know any generic solution where we could skip a configuration

What should be configurable?

- selection of 2 methods: elevation change (old method) and acceleration sensor (new method)

- old method should be default because only the old method could handle all activity types

I guess the old method does cover barometric messurement as well, which means we just need to select between elevation change and acceleration sensor.

- do we need configuration for freuqenzy and filtering? Would be nice but I wouldn't complain about hardcoded values if this limitation would make it less complex

Calibration needed?

- yes, gyroscope needs a 0 angle calibration. But we could reuse the compas screen onclick calibration

Should this feature get recorded?

I would say no, because of acceleration based errors. It does not need much of breaking force to accedently twist the screen upsidedown if you forget to disable screenrotation :D

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

Who does not agree with this summary?

1

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

+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

1

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

1

@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?

1

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

1

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.

1

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).`

1

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 .

1

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.

1

I guess this idea could be marked as solved if we could get the Dashboard Pitch element as percent value. Because it does already have what we need, it does use the phone sensor, it is filtered and it is able to calibrate it.

The only point is that angle value is not usefull because it is from 0° to 360° instead of -180° to 180° and % whould be the best solution.

1

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

1

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```

1

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

1

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