I made a canoe trip on a lake and used MyTracks to record the track. In the picture below this MyTracks recorded track is displayed with MyTracks (left) and with Locus (right). I understand there will be noise on the elevation because of inaccuracy of the computed GPS altitude, but MyTracks obviously use a stronger smoothing algorithm, making it more correct. MyTracks reports an accumulated "Elevation Gain" = 137 meters, while Locus reports 649 meters "Uphill Elevation"! This correlates to the way the two applications display the results, but the way Locus computes elevation gain it is not of any interest with results so completely off any meaningful level. I think elevation gain (uphill elevation) is a very interesting number, but Locus has to significantly improve the way it is calculated in order to make it useful and meaningful.
[attachment=0:p6rpi9r6]Both2.jpg[/attachment:p6rpi9r6]
may you provide file with data? I should upload it and test it also on another web service, GPSies for example.
gpx file attached
I think the GPS altitude can be very inaccurate. I went for a hike today, and stopped in a restaurant for lunch. When I went in the altitude was about 150ft. When I came out the altitude was about -630ft, and I don't think the ground subsided that much during lunch :D . I could upload the track, but I already overwrote the altitude information (this is a new feature I really like!).
Edit: I just realized the location of the track is way off too. It's several hundred feet on the wrong side of a river, with various loops and excursions into the middle of swamps, etc :D . It looks like the GPS completely lost itself. It was OK when I left the restaurant (the track is accurate), but then a little while later the track goes crazy, and is completely wrong for the next 40 minutes. So forget my comment about the accuracy: the GPS was obviously completely lost. I don't know why, because there is not much to block it and I have recorded a track there before, but it went nuts today.
Vertical GPS accuracy is not as good as horizontal - that is a fact. My point here is that because of just that, some sort of smoothing algorithm is required. And MyTracks obviously does a much better job with that than Locus. I would suggest a smoothing with user selectable smoothing level, e.g. off, weak, fair, strong, very strong. E.g. if you go cayaking from lake to lake, you want a very strong smoothing. If you go hiking, your elevation doesn't chnage abruptly by several meters between sored points and you may want a fair smoothing, but if you go running in a rough terrain, you may want a weak smoothing. And if you go downhill skiing, you may need to turn off smoothing.
Quote from: "svartbjorn"If you go hiking, your elevation doesn't chnage abruptly by several meters between sored points
Unless you walk off a cliff :mrgreen:
Ok, I'll look at it. Question for you is: do you want to apply some smoothing on recording data itself, this means my smooth algorithm will corrupt recorded data in some way and also exported data will have this or you want to apply these data only to show stats so exported data will be raw recorded data? I expect to use this directly on recording data ...
EDIT: hmm I uploaded your track to GPSies.com and it show same altitude profile as in Locus. I'm not saying it's correct, just that it do not apply any filter on imported data. I'll probably apply simple altitude smoothing (similiar to medium filter applied to orientation) and we'll see what this will do.
Second question are shown values of uphill and downhill. These are values set by me, so no standard. Maybe you can help me a little with this.
I'm counting declivity for every new segment by
declivity = elevation / distance
if declivity is bigger then 0.025, I add this to uphill
if declivity is lower then -0.025, I add this to downhill
else I add it to flat
so border is 2.5% of elevation change. Maybe it's too low values and because of this, to much values are stored in uphill and downhill? What you think?
EDIT2: hmm when I set value to 5% it do not help a lot on your recorded track. As I see I already apply smoothing algorithm on altitude. Only problem here is that I do this on GPS data directly and not on already recorded data. It looks that My Tracks record raw GPS data but when it show altitude profile and some stats, it use some filtering. I on other side, filter altitude a little during recording so my recorded data are already a little bit filtered. So I'm sure, that If you record same track with locus, you'll get at least little bit filtered data also. (because I do not ever see so weird altitude profile on my own recorded tracks :) ) ... but you have still problems with working with locus on your phone right? hmm
I see the dilemma and I was probably a bit too quick to criticize Locus.
I can admit Locus is excused when displaying tracks recorded by another app like MyTracks, since MyTracks obviously store points unfiltered and applies smoothing when analyzing the track afterwards. I looked at a track recorded by Locus during a flight, and it was actually very smooth. Two Locus bike tracks do have some altitude noise that will add more uphill/downhill meters than actually is the case. When I looked at Locus tracks of two walking trips, that charts were quite noisy. So it seems that the lower the speed, the more incorrectly the smoothing works.
When to do smoothing - during recording or as post processing? Well, we know that the raw data are not correct anyway, so why store it unfiltered? If the smoothing algorithm is fixed and not user selectable or speed dependent, then storing raw data and doing post processing should work fine too. But then the smoothing should be applied also when exporting tracks, such that the apps using those data, get meaningful data (my original example with MyTracks show how bad this can turn out when doing it the MyTracks way). If however the smoothing level were user selectable, then the smoothing has to be done during recording I think, otherwise you would need to change the smoothing level from track to track depending upon what kind of trip it was (flying, sailing, running, ..).
I see the challenge of how strong the smoothing should be: too weak will pass through too much altitude noise and hence add too much to uphill/downhill, and too strong will filter out some real up and downs in a rough terrain. So may be the smoothing algorithm Locus is using today during recording is the best compromise after all. Since Locus is supporting display of MyTracks recorded tracks, may be the same Locus smoothing algorithm should be applied before displaying those charts and statistics.
Regarding my phone hang problems with Locus, yes they remain. I even tried more things yesterday, but nothing helped. Locus crashed and killed the phone dead twice during the same 1 1/2 hour trip. But I also can be lucky once in a while and record a trip without issues.
I don't think the raw data should be smoothed - that should be done by the application using the data, for example the chart drawing part. You never know what kind of smoothing you want anyway, or if there are applications where you don't want your track to be smoothed...
Quote from: "menion"so border is 2.5% of elevation change. Maybe it's too low values and because of this, to much values are stored in uphill and downhill? What you think?
To get an idea how steep a 2.5% angle really is, one can look at an airplane coming in for landing: standard descending angle is 3 degrees, which is equal to 5% (tan 3 = 0.05). 2.5% equals 1.4 degrees (arctan 0.025 = 1.4 degrees). So 2.5% (1.4 degrees) may be reasonable is the GPS altitude accuracy were better, but with the accuracies we actually get today from GPS, may be a 5% criteria would work better and rule out more of the small variations due to GPS altitude inaccuracy. But I assume you are using this declivity decision after smoothing? Otherwise it won't make sense at all (refer the raw data example from MyTracks).
yes, I use this value after smoothing.
fine. so I'll set there 5%. this should cover all small disturbance. About storing raw data. Filter I apply is really very simple and filter only extreme huge changes so it really do not change values radically. I'll keep actual state and we will see.
whole problem here is thanks to MyTracks data you displayed in Locus. Question is whether this is really some problem that need to be fixed. I in Locus display data that you really get! So data that are stored in database and also data that are stored in My Tracks database. So it should be little weird to apply some filter on data from My Tracks and not on data from Locus (I know, I apply filter on GPS data before saving but no one know what brings next My Tracks version) ...
Quote from: "durian"I don't think the raw data should be smoothed
I agree. You can't "unsmooth" it later if you decide it wasn't right!
so I'm opening this topic again due to issue here viewtopic.php?f=10&t=757 (http://forum.asamm.cz/viewtopic.php?f=10&t=757)
so firstly:
- I'll create something similar to sensor filtering ... low/medium/big ... it's ok right?
- then - apply filtering directly on recording data? YES/NO
if YES, big advantage is simplicity for basic users and also for me. This can be done during few hours. If I'll not apply filtering on raw data but later for displaying and export, there will be problem how to let user know that there is some filter (if he forgot), also there will be need to compute all stats again during every loading from database and probably I'll have to get all already loaded data and apply changed filter on them again, if something change in settings ...
so what you think guys?
This sounds OK to me. If someone doesn't like having filtered data they can turn it off, and it's the same as now. Will the filter be applied only to the altitude data, or also to position?
nono only on altitude. I prepared one special filter (Kalman filter) a long time ago (only older J2ME mobiles) but now it's not necessary, so only altitude
OK. Sounds good to me then :D
heh, I forget on this. You have to kick me sometimes ... :) ... joe remind me this, so altitude filtering added. To be correct, light filter was already there (without it, results will be much worst) but now you can select stronger version. So test it, and if results will be still weird, I'll try to create some more "clever" filtering method
The most clever "filtering method" would be using the pressure sensor. Or offline DEM data. Or online DEM data. Or a clever combination of everything that is available :).
we'll see ... for now, this is a progress
looks cute :)
this new filter is not applied to imported tracks i guess.
when i import a track from gpsies.com (eg http://www.gpsies.com/map.do?fileId=mympxdsbzetublrl (http://www.gpsies.com/map.do?fileId=mympxdsbzetublrl) ), the climbing is still very wrong. gpsies shows it correctly though.
no it isn't. I'm thinking that current filter system is wrong and I'll have to rewrite it. Currently, I'm changing data that i get from GPS, and that's wrong I think. I should store original data to database and only display and use improved data by selected filter. I'll think about it ...
I agree. Storing original data is better.
You could also store barometer reading with every point and do something useful with it later :). I know it's a bit hard/impossible to work on, if your own device doesnt have a pressure sensor. Might still be worth to at least keep it in mind for later. I believe pressure sensors will become quite common in the future. googles new flagship phone has one too.
hmm , I forget to change my labels, galaxy nexus is home because I had too much reports on some issues on ICS ... so I'll add it also, but later. This will really need to improve some more things. Also some heart-rate monitors will be needed so I'll take it at once ...
Dear Menion, happy new year first off all. ;)
What about the possibility of using the pressure sensor? I would really like to see this in Locus...
Thank you
Matthias
Thanks Matty ... I'm right now work on it ... he :D
... just thinking how to implement in best way ... just settings to enable/disable and result will be modified altitude by the pressure? hmm ...
I think you need to calibrate it. That could either be manually by the user entering current altitude or automatically. You could eg take the first 5 gps heights when a new track is started and calibrate the sensor with that and then only use pressure data for heights.
yes, that's what I want to do ... calibrate it by GPS altitude, anyway question is whether there is need for some screen with info or all should be done on background, which is what I'm currently doing
Background is nice most of the time i guess. However, in case of a serious weather change, calibration must be repeated. Manually?
Also, there might be circumstances when the gps altitude value is simply bullshit. Like in a canyon or or when climbing a huge vertical rock face or whatever.
I think, in the end, a manual calibration screen is sometimes required. It should allow entering the altitude but also allow using the current gps value. Users can call this manual calibration when they thonk they need it (weather change or difficult gps signal conditions).
Or locus shows it when it fails at automatic calibration, eg because the gps measurements are too far apart.
All garmin devices deal with it in some way. They also have different modes later, ie some are better for flying and some for hiking. I dont really know what they do exactly, it might be worth some research.
Its quite a complex topic really, just reading a bit.
http://www.gpswiki.de/dwiki/begriffe/barometer (http://www.gpswiki.de/dwiki/begriffe/barometer) has some valuable info on how garmin treats it. U.fortunately in german....
thanks for link, I'll look at it later.
Support for pressure sensor added. Current system:
- when you turn on GPS, first five locations is used for calibration. After that, altitude is computed from pressure values. Every new location is checked and if difference between measure and computed value is too high, new calibration is computed. Probably too simple, but we'll see
Ive read that garmin sort of recalibrates gradually with time to counterbalance weather influence. No immediate changes though, its more like a gradual thing moving the two data streams closer together.
What seems to be important:
A) only very good 3d gps fixes with excellent accuracy are taken into consideration for calibration at all.
B) when the difference of gps & barometric data is too big (garmin uses 300m i guess), measuring is considered an error and not used for re-calibration.
Obviously we need to be able to turn off all pressure sensor handling and use raw gps data like now. Otherwise you cannot track heights while flying in pressurized cabins.
In general, i think automatic re-calibration during track recording should be done very careful, if at all. Its much more likely to receive a bunch of bullshit gps fixes (think canyons, deep wet forest, rock climbing) than it is to receive wrong barometric data.
Just thinking... it might be worth to consider storing raw data in your data base, ie both gps value and pressure sensor value. You could do the calculations later on export/display. And maybe do funny things too, like a weather forecast :).
- yes, re-calibration during record seems like a problem. When recalibration is done, recorded altitude skip to new calibrated values and this cause "altitude jump" ... probably not wanted.
- ability to disable/enable using of pressure sensor is in settings, so no problem to turn if off immediately
- about database storing. Hmm ... I was also thinking about storing raw altitude data and also data from some heart-rate sensors, so probably this will be a good idea
I think older garmins had the altitude jump problem after recalibration. So they changed it to the gradial thing in newer devices/firmware
Is the barometric locus online somewhere for testing already? I could do a sea journey recording in 30 mins and see if it stays at deck altitude properly :)
not yet, I'll create one when I'll be able to compile it :) give me one-two hours
Hi, I would like to post my opinion in this topic
Basically you have two options when using gps with barometric values,
1. automatic calibration (like garmin mentioned above)
2. manual - you have manully enter pressure at sea level or altitude
To get ideas you can check SportyPal software where it is already implemented. But I prefer manual setting where recalibration takes effect only when user wants. In hiking it is not changed too often as area and period where pressure changes are not too big. But in aviation terms, there are changes more common
Basically there are 3 values with 1 user input, 1 measured and 1 computed values
1. local pressure (measured value taken by sensor) (QFE in aviation terminology)
2. pressure at sea level (QNH)
3. altitude
(either 2. or 3. serve as an input the other one is then calculated)
In hiking most common approach is to set 3. as input then you are able to compute QNH (2) and then every change in pressure correspond to offset change in altitude. (e.g. suunto watches are using this method, altitude is taken from known points/landmarks etc)
In aviation most common approach is to set 2. as input then you are able to compute present altitude and then changes in pressure correspond to offset change in altitude ( QNH value is available in weather METAR messages for every airport or by tower when flying to different area - woudl be usefull to change during flight/track easily. Btw. flying above so called "transition altitude" (often 8000ft) requires all planes/glider to set QNH to 1013 - in aviation, pressure altitude ALWAYS takes precendence over GPS altitude, so manual setting would be welcome.
calculations can be taken from this page as resource http://www.hochwarth.com/misc/AviationCalculator.html (http://www.hochwarth.com/misc/AviationCalculator.html) (first part regarding QNH/QFE) or if exact equation is necessary let me know, but it is inside JavaScript on that page
thanks bebe, it was much worst (mainly on time) then I expect, so I spend almost whole day on this ... nevermind
test version here: viewtopic.php?f=25&t=1404#p8322 (http://forum.asamm.cz/viewtopic.php?f=25&t=1404#p8322)
Is there any way to tell if locus is actually using the pressure sensor?
Just thinking... for testing and maybe also for geeky details, locus could add a waypoint whenever it does some calibration thingies to the sensor. Add a special "automated" poi category so users can enable at will. This could also be used as a general "geologging" thing. You could create "automated" waypoints for many different events (like track export, minimize/maximize, anything of interest).
no there isn't. I was thinking about some notification when you enabled GPS and using of pressure sensor is enabled. This is next step ...
just quick tested in my flat and seems fine, change in 1 milibar ~ change of 10 meters (approx), when weather get's better will check with airplane devices.
if anyone want calibrate (pressure based) you can use http://www.aviador.es/Airports/Nearby/ (http://www.aviador.es/Airports/Nearby/) search any airport near you and in METAR (meteo report) find Qxxxx where xxxx is pressure at sea level e.g. Prague LKPR - METAR LKPR 052130Z 26021KT 9999 BKN042 03/M02 Q0988 NOSIG= pressure is 988 hPa
Maybe another idea but not so important: mainly for hiking - to display height even when no gps fix available, can be good for someone in canyon or dense area. But for aviation it's not necessary as we shouldn't have any obstacle nearby ;-)
Big thanks, I'm also GIS developer and haven't seen anybody to react so fast on user requests ;-)
First 5 GPS locations using for calibrating pressure sensor are very inaccurate. In about 1 minute after GPS start hight is more accurate. But if I start GPS inside the building I'll get inaccurate height until go to open air. So it's difficult to calibrate pressure altimeter by first GPS locations. Maybe better calibrate using SRTM and GPS. Now I can calibrate by SRTM but only manually in preferences - it's difficult to make calibration on every program start.
So really now I compare dynamic height by SRTM, GPS height and when the difference is small I turn GPS off/on and pressure sensor calibrated correct automatically.
Of course re-calibrate during writing track is bad idea.
I want to see function to quick calibration of pressure sensor. Maybe manual calibration when I see that GPS height is correct, but not in deep preferences menu. Maybe by SRTM automatically. Mabe by GPS height but compare with SRTM and when the difference is too big don't calibrate.
edit
I test different methods to calibrate pressure sensor. The best and most accurate way to calibrate pressure sensor is set up pressure at sea level by METAR (thanks to bebe814). Maybe can add automatic calibration using nearest METAR data? If not now, please, can you add a button for quick enter sea level pressure (now I must do it deep in preferences).
edit
I still test Locus in different situations. Today I see dramatically fast preassure fall during day from 1023 to 1010 mmHg. So it's very important to re-calibrate altimeter periodically. But how to make it better? I don't know :( . Of course it will be great if Locus in future can calibrate using nearest METAR data and check pressure every hour. But in hight mountines no Internet connection for check METAR. But I can download SRTM data and put it to my phone. So for calibration compare height of SRTM data and GPS height and calibrate when both height are almost the same. And repeat calibration time to time.
Does anybody know how solve problem with altimeter calibration in GPS devices like Garmin, for example?
Hi, despite the topic is quite old I still see huge jumps in recorded track altitudes. Is there a build in solution now?
Hi Klonutzer,
there were quite a lot of discussions about this topic
I anyway suggest to check Altitude manager screen in Locus (more here https://asammsoftware.zendesk.com/hc/en-us/articles/200028131-Altitude-manager ). There are some techniques that may help. Mainly if you set stronger filter in Altitude filter section
Second possibility is to Fill recorded track with computed altitudes. Locus allow to compute completely offline altitude for a whole track, which is very very fast and result should be very good.