[closed] Altitude spikes with kitkat (or my phone?)

[Cragproductions]

My Sony Xperia Z got smashed up and I got it replaced on the insurance.

The replacement phone had an upgraded version of Android on it, which has some known issues with the Xperia Z (insane battery drain is the main thing)

Anyway, since I've got my new phone I have been getting altitude spikes if a few hundred meters from time to time. This can be + or -.

It can be pretty bad sometimes. What would normally look like a smooth representation of the mountain I've just hiked up can end up looking like a spiky mess. In one case there is a section at the summit where there are about 6 spikes in a row, each about 300 meters below my actual altitude. This results in an additional 4 miles of distance! (if you have the time on the graph, it is just horizontal for about 1/5 of the graph)

X and y are recorded perfectly.

I have arranged for them to take my phone back, but I was wondering whether this is a kitkat issue or a faulty GPS issue?

I've read up on it bit and it seems that GPS altitude is notoriously inaccurate.


I was thinking, that a solution to this would be to have an option in the filter section of the recorded track that was "ignore altitude increases of more than..." and then have an option 20-100m or whatever. The reality is, unless your facing off the mountain, your not likely to be gaining or losing a significant amount of altitude between points.

While smoothing does a good job generally, it can't really handle big spikes. The effect on distance and all related stats (like calories) can be extreme. The map where I had the section of huge spikes need up about 2000 calories out if wack.

Cheers.

[cragproductions]

Here are some images to illustrate the point:

A mountain walk, with time to show how much of an impact the spikes can have on time:



The same walk, but with speed so show the number of spikes actually in the route:



This is the drive home, you can see how much the spikes stand out on the relatively flat road, causing what should be a fairly m:



Cheers

[Guest]

oops,

here is the one showing time:

[Cragproductions]

I've just gone through a load of my old maps and it seems that this issue has been around for my last 3 phones. It is MUCH more pronounced on this phone and happens much more frequently.

I only noticed it because it added so many miles on that hike, and made a visible difference to the graph. Looking back, using speed, I can see one or two spikes on most of my old maps.

I think having the "ignore altitude changes of more than..." option would definately go a long way towards improving the accuracy of tracks.

Happy to email you track files if you need.

Cheers.

[Psyberia-Support]

Thanks for your report,
I'll have a closer look at this and give you a feedback soon.

[cragproductions]

Just looking at how the speed is affected, and maybe an alternative solution would be for any z value that would cause the speed to go over a certain threshold be converted to the last 'normal' z value.

Just noticed that im tracked as going 192mph!

Anything that would put me over 10mph on a mountain is probably a false reading. (though I appreciate that some may be using mountain bikes etc)

Just done Ben Lomond and Ben Nevis, and both tracks are useless, except for the x and y data. every other stat is completely skewed because of the z data.

cheers!

[Psyberia-Support]

It would be great if you could send me an 'affected' track by email, so I can have a precise look at all values.

The speed if affected because it takes into account not only the flat distance, but also the elevation. When you walk one meter, but from +100m to +200m in one sec, the app will take both horizontal (1m) and vertical (100m) distances into account to compute a diagonal, which in your case if huge due to the elevation spike, leading to a very fast speed.

I think that the elevation spike detection would be more precise since it's a raw value, whereas speed is computed from flat distance, elevation difference and time.

[Guest]

Cool, figured the speed was due to the rapid elevation gain/loss. This also completely screws distance and calories (amongst other things)

I get what your saying about the speed being a less effective solution.

There are lots of options for minimum altitude of speed, but no maximum.

What email adress should I send them to?

Cheers.

[Psyberia-Support]

You can use contact [at] psyberia.net

[Psyberia-Support]

Hi again,
I have improved the statistics and graphics by replacing the previous smoothing process by a much powerful noise reduction process capable of removing erroneous data. Here is the result on your tracks. This will be available in the next update, I hope within one week.

profile_20140921_215857.jpg

(63.01 KiB) Downloaded 3742 times

profile_20140921_215920.jpg

(59.29 KiB) Downloaded 3742 times

Best regards

[Cragproductions]

Thank you!

This is amazing.

Not only have you fixed the spikes but all the data now looks much smoother, including the speed - which is now a much more steady flow.

Thanks!

Dave

[Psyberia-Support]

The fact that the speed graphic is smoother is part of another improvement, same thing for the inclines:

profile_20140921_225719.jpg

(61.29 KiB) Downloaded 3347 times

Best regards