Avoid turning display off just prior to next navigation point
During navigation there are two timing settings which combined can result in confusing behavior - the display is turned off for just a few seconds just prior to next navigation point - not ideal - confusing, unnecessary, and just the wrong time to automatically turn off the display. Lets assume the display "idle time" is 15 seconds (lowest) and the display is turned on 15 seconds before the next navigation point (default). Now if during those 15 seconds I am slow in reaching the point, the display will turn off, sometimes for only 1 or 2 seconds, then when the point is reached the displayed is turned back on. The result - on (15s)/ off(1s)/ on(15s/ off.
My suggestion is simple, doesn't affect those settings or introduce others, and avoids needless turning the display on/ off for just a few seconds. So - at the end of the idle time during navigation, that
is when about to turn off the display, calculate how many seconds until
the next navigation point is reached based on current speed. If this
time gap is less than 5 seconds (say), then just keep the display on.
I like this idea 
Hello Andrew,
agree that such tuning on/off within a few seconds is useless and confusing.
So in new version 3.9.1, this method should be applied. I've made following conditions:
- if screen was turned on thanks to notification on navigation order, Locus will remember that. When screen should be turned off due to defined timeout, Locus check if previous turn on was because of navigation. If so, Locus check if next navigation point is closer then 5 seconds and if it is, screen won't be turned off.
Damn, when I wrote this whole description, I realized that this won't change anything.
So forget on my previous sentence and also on change in 3.9.1. I have in mind how to do it better now, so this feature will be correctly implemented in next 3.9.2 version during June.
Hello Andrew,
agree that such tuning on/off within a few seconds is useless and confusing.
So in new version 3.9.1, this method should be applied. I've made following conditions:
- if screen was turned on thanks to notification on navigation order, Locus will remember that. When screen should be turned off due to defined timeout, Locus check if previous turn on was because of navigation. If so, Locus check if next navigation point is closer then 5 seconds and if it is, screen won't be turned off.
Damn, when I wrote this whole description, I realized that this won't change anything.
So forget on my previous sentence and also on change in 3.9.1. I have in mind how to do it better now, so this feature will be correctly implemented in next 3.9.2 version during June.
Sometimes it is so hard to describe in simple terms a problem, especially in a multilingual forum, hard to get correct meaning across to others without face to face communication, too easy for confusion when slow feedback loops. But there is amazing goodwill in this forum and for this Locus app. Clearly you see the issue and a solution - thanks. It would be nice if the improvements can be combined with more flexibility (shorter times) in the display idle time too ;-)
Sometimes it is so hard to describe in simple terms a problem, especially in a multilingual forum, hard to get correct meaning across to others without face to face communication, too easy for confusion when slow feedback loops. But there is amazing goodwill in this forum and for this Locus app. Clearly you see the issue and a solution - thanks. It would be nice if the improvements can be combined with more flexibility (shorter times) in the display idle time too ;-)
Agree, mainly for people like me, who was too lazy on school during lessons of English :).
Anyway I've just improved this topic (and also "display idle time" ;) ).
Anyway because I personally do not test these Locus features in the field too much, it will be more on you (users).
System is now created - after defined "idle time", Locus test if screen may be turned off (change compare to before, where no such test exists and screen was immediately turned off after "idle time").
Screen won't be turned off if you are close then
- 5 seconds before cross (current navigation waypoint)
- 5 seconds before next expected voice announcement, that should again turn screen on
We will see if this will work. Mainly second point is little bit problematic, but I hope, my implementation will be working ...
Agree, mainly for people like me, who was too lazy on school during lessons of English :).
Anyway I've just improved this topic (and also "display idle time" ;) ).
Anyway because I personally do not test these Locus features in the field too much, it will be more on you (users).
System is now created - after defined "idle time", Locus test if screen may be turned off (change compare to before, where no such test exists and screen was immediately turned off after "idle time").
Screen won't be turned off if you are close then
- 5 seconds before cross (current navigation waypoint)
- 5 seconds before next expected voice announcement, that should again turn screen on
We will see if this will work. Mainly second point is little bit problematic, but I hope, my implementation will be working ...
the solution sounds good thanks
>personally do not test these Locus features in the field too much, it will be more on you
my pleasure!
Does this still handle the opposite situation where a user is stopped/ paused at navpoint eg. traffic lights or cafe, and doesn't want the display continually turned back on? This had been a problem but you fixed it in 3.8.x.
the solution sounds good thanks
>personally do not test these Locus features in the field too much, it will be more on you
my pleasure!
Does this still handle the opposite situation where a user is stopped/ paused at navpoint eg. traffic lights or cafe, and doesn't want the display continually turned back on? This had been a problem but you fixed it in 3.8.x.
Hmm it should!
By default, Locus has some defined average speed values used for "compute with times". If you use "navigate to" and choose a bike, then average speed is by default 5 m/s. So speed used for time computes will be always at least this value. This means, if you will be standing up to 25 m before cross, display should not be turned off.
If you use navigation on imported GPX file, then there is not yet possibility to define mode (car, bike, ...) so it is always used a car. Then this value is 15 m/s. Have to add this selection also, because it affect times of arrival and some others.
Hope my explanation is clear a little bit.
Hmm it should!
By default, Locus has some defined average speed values used for "compute with times". If you use "navigate to" and choose a bike, then average speed is by default 5 m/s. So speed used for time computes will be always at least this value. This means, if you will be standing up to 25 m before cross, display should not be turned off.
If you use navigation on imported GPX file, then there is not yet possibility to define mode (car, bike, ...) so it is always used a car. Then this value is 15 m/s. Have to add this selection also, because it affect times of arrival and some others.
Hope my explanation is clear a little bit.
Thanks for the explanation. Now where could that explanation be included in the manual for other users...?
Thanks for the explanation. Now where could that explanation be included in the manual for other users...?
I do not think this is necessary. All should be in ideal absolutely automatic and on background.
I do not think this is necessary. All should be in ideal absolutely automatic and on background.
Maybe as an expert user you think not necessary, but even though I know a lot more now about Locus, I still find when I try to learn more from the manual (instead of asking questions) that many aspects could be explained better - the "why" to use a certain setting or do something a certain way - possibly a series of "how to" topics would be beneficial. Microsoft documentation was always very good in this area.
Maybe as an expert user you think not necessary, but even though I know a lot more now about Locus, I still find when I try to learn more from the manual (instead of asking questions) that many aspects could be explained better - the "why" to use a certain setting or do something a certain way - possibly a series of "how to" topics would be beneficial. Microsoft documentation was always very good in this area.
Replies have been locked on this page!