[done] Breaks too sensetive?

[Craggy]

I used this app for the first time properly yesterday, on an 8 mile hike.
I am very impressed, battery drain is minimal and the app seems very accurate. Looking forward to using it to track all of my future hikes in stead of Trimble Outdoors (Which is very good to be fair - AlpineQuest seems to have a definite edge in terms of power and flexibility)

One thing that I noticed is that the stats show that I took a very large number of breaks (about 20!) when in reality I took 1, and stopped for no more than 1 minute on a few occasions to let people catch up.

It does look like the sensetivity of the break detection is a little off. I had a look at changing the statistics settings, which affected the results of what I had already hiked - but this was still pretty off.

After changing the threshold of elevation and moving down the breaks did reduce, but after testing afterwards by continuing my hike and stopping at intervals for aprox 2 minutes, these breaks did not register.

Can you please shed a little light on the threshold settings on the stats page, and how they affect breaks. and also let me know if there is anything else that I can do to make break detection more accurate?


I understand that hiking can be a bit of a pain to detect breaks, as on steep inclines particulary, movement may slow to the point where its hard to differentation between that and a stop (combined with the limited accuracy of GPS)

What may be useful is to have a "break time" threshold. so I can set the app to only record stops of a set period (for example, 1 minute, 1.5 mins, 2 mins, 2.5 mins and 3 mins). This could then disregard all breaks under that time and if a detected stop goes over the set time, then the break in its entirety is logged as a break. This should make the break detection a little more accurate.

Thanks

and well done on the app, it is excellent!

[Psyberia-Support]

Hi and thanks for your feedback.
The only stats setting that will change the breaks detection is the 'Moving threshold' one. It defines under what speed the user is considered as stopped.
Depending of the tracking options, locations are usually not recorded while the user is stopped. In this configuration, you have one location few meters before the break place, and another one few meters after the break. So you don't have a clear stop, but rather a segment with a very low speed. The 'moving threshold' allows you to change the speed under which one the user is considered as stopped.
If you consider that the small breaks should not be taken into account, then rise the moving threshold. Try 0.62mi/h (1km/h) to see if it's enough and let me know.

Concerning the other settings:
- the smoothing define the number of locations to mean to have an elevation profile looking more smooth (useful to reduce GPS elevation inaccuracies);
- the elevation threshold allows you to take into account an elevation change only after a certain amount of altitude difference (reduce the extra gain/loss due to inaccuracies).

Best regards

[Guest]

Hi, thanks for the reply.

Wouldn't increasing the threshold make breaks more likely to trigger?
I assume that the lower the speed the more likely a break should be to trigger (0 mph being the ultimate stop).

Changing this in the track seems to reflect this also, as the breaks seem to be dynamically generated. Increasing the threshold increases the number of breaks to about 30.

Not sure how this works if the breaks work how you said, where the data stops recording during a break.

I guess I'm best off testing with a new track, rather than one that already has these breaks stored in the trip.

[Guest]

Sorry, I assumed that the lower the speed the LESS likely a break would be to trigger.

[craggy]

Hi,

I have just done a quick test on my street.

It looked to me like the points continued to record regardless of whether I walked or was stationary. On the next page, where the data is filtered the number of points was significantly less, so you could see the effects of the breaks (and other filters)

Having a higher threshold for speed made the breaks longer, and reducing the threshold made them shorter. This looks like the breaks are calculated as part of the filtering process and not the recording process?

The setting I had the threshold on seemed to make no difference to the recording, only the filtered results.


For this flat walk the break detection worked fine, but on the hike I did yesterday, the breaks were way off. Totalling an hour in a four hour hike... that being said, I was with some new hikers so the pace was slow and there were a number of 20-40 second stop to allow people to catch up.

I will watch this closely during my next hike on my own, where I can be 100 percent sure of how much I actually stopped.



I can't help but feel that a proximity and time based break detection system would be more accurate than a speed based system.

I.e. if there has been no movement outside of an x radius within y minutes then count the recorded points within x radius as a break. (this assumes that while you rest your likely to move around a little within a small area)

[Guest]

Did a hike yesterday and the breaks recorded much better.
I set the threshold to the lowest setting while recording.

That being said, the hike was largely flat except the first few minutes, which was very steep. It does look as though the steep section has recorded in part as a break. I will do another test on a mountain somewhere that is particularly steep, without stopping at all.

I will know then whether breaks are being triggered due to steep inclines.

[Psyberia-Support]

Hi again,
I didn't spoke about that in my first explanation, but the track recording process is independent from the stats computations and break detection.
The location tracker records the locations and store them (nothing about breaks or stats is computed). Then, when displaying the stats the track is smoothed, filtered, and then stats are computed and breaks detected.

That's why you have two sets of settings:
- The Location Tracker settings, allowing you to change the frequency of recorded locations, and also the minimum distance required between 2 locations (precisely the settings that will make locations not recorded during a break);
- The stats settings, allowing you to change how the stats will be recorded from a track (recorded by the Location Tracker, but also on any GPX/KML/... tracks). The break detections threshold is also part of these settings.

Also, you're right that the smallest speed threshold will lead to less breaks.

When I have some time I will try alternative break detections like the one you gave.
But, there will always be a part of personal feeling about breaks. Should a pause of 30 secs be considered as a break during few hours hike? And during a 10min footing?

Best regards

[craggy]

Thanks.

That essentially follows my experience. So in a nutshell the track is recorded independently, then filters are applied, which produce the info for the stats page.

i assume that Hiking is tricky to gauge breaks in particular, since movement as thr crow flies can almost appear to stop as the hiker tackles steep inclines.

Thanks for looking into this.

[Craggy]

With the tweaks suggested in the post and the possible/probable addition of a time threshold option for breaks - I would consider this to be a fixed issue.

[Psyberia-Support]

I have added this option in version 1.4.8, with a default minimum value of 2 mins (instead of 1 before), so the number of small breaks is reduced.
Best regards