Activity detection while moving is noticeably better and now reacts almost in real time (which is really good). When a driver or cyclist stops, the recognized activity switches to still right away, which starts the 60-second stop detection timer.
However, 60 seconds is shorter than a typical traffic light stop, and this creates a problem. Exiting stationary mode and resuming movement tracking takes much longer than entering it.
Scenario example:
- The user is driving and stops at a traffic light for 2 minutes.
- After 60 seconds, the app switches to stationary mode.
- One minute later, the user starts driving again.
It takes about 5 minutes for the app to return to moving mode, so no location updates are sent during that time.
Before this update, this was rarely noticeable because the old activity detection was slower and the app usually stayed in moving mode through short stops. Now that detection is much more accurate, the short timeout triggers much more often.
Suggestion:
Simple soution: Increase the default stop detection timeout from 60 to 300 seconds ( I think this is a resonable period)
More advanced (maybe in the advanced settings) : make it auto scale propotionally to the time the user has been moving in with a configurable minimum duration of x seconds and maximum stopdetection timeout of y seconds, to avoid stale locations during short stops.
This is an issue starting with version 10.1.3
Can you explain your first suggestion. How does it fix the problem?
It increases the timeout from the currently set stopdetection period of just 60 seconds to a more reasonable one that is 300 seconds ( slightly more than the average duration for most traffic lights in the world) so this way, before the device goes into stationary mode in a traffic light, the recognized activity won't be still anymore and traccar will continue being in moving mode
Or maybe you have a better way to resolve this issue. What do you think the ideal way to resolve this issue be?
Ideally, Also maybe have different stopdetection timeouts for different activities. For example for walking 60 seconds is ideal , however for driving or cycling 300 seconds is more reasonable
Activity detection while moving is noticeably better and now reacts almost in real time (which is really good). When a driver or cyclist stops, the recognized activity switches to still right away, which starts the 60-second stop detection timer.
However, 60 seconds is shorter than a typical traffic light stop, and this creates a problem. Exiting stationary mode and resuming movement tracking takes much longer than entering it.
Scenario example:
It takes about 5 minutes for the app to return to moving mode, so no location updates are sent during that time.
Before this update, this was rarely noticeable because the old activity detection was slower and the app usually stayed in moving mode through short stops. Now that detection is much more accurate, the short timeout triggers much more often.
Suggestion:
Simple soution: Increase the default stop detection timeout from 60 to 300 seconds ( I think this is a resonable period)
More advanced (maybe in the advanced settings) : make it auto scale propotionally to the time the user has been moving in with a configurable minimum duration of x seconds and maximum stopdetection timeout of y seconds, to avoid stale locations during short stops.
This is an issue starting with version 10.1.3