I got a chance to log some info and visualize it on a map to better understand the results, Here are my findings
But it boils down to, It is significantly better than the unusable 9.1.0 update but significantly worse and less reliable than the old app.
Here is how I set up this test first of all, Traccar settings are as follows
Location accuracy : High
Distance : 10
heartbeat : 900
Fastest interval : 10
offline buffering: off
Stop detection: on
will include some screenshots now from a map but for obvious privacy reasons I added a constant numeric value to the latitude and longitude to keep the ratio between the locations the same and alter their position relative to the actual one, this was done to preserve the user's privacy but still visualize it in a way that is easy to follow. The screenshots will have numbers which indicate the update index in the array of the recorded updates, an arrow pointing to the direction reported by the heading value in the posted json by traccar, when I tap on a location an alert shows up with the rest of the info.
with that out of the way let's dive into the findings
will start with update number 2 as 0 and 1 and 2 are overlapping so the most recent one in that location is the one showing up. will consider this to be our staring point
now let's check update 3
It is 280 meters from update 2, this is the first issue as the distance was set to 10 why would 2 updates be 280 meters apart! the is_moving is true so the phone should have used the GPS since accurace was set to high but it didn't !. The speed and heading had values of -1 which makes no sense as the is_moving is true and since there is movement there should be values for heading and speed which I suspect isn't there since traccar never triggered GPS till this point and just relying on the sdk for detecting movement which doesn't seem to be accurate enough (more on that later) however it detected that the activity is walking which is good. At this point let's assume it took a while for the sdk to detect movement, and that is why there is gap in the initial recorded data. let's move to update 4 and see as at this point the sdk detected there is movement and that the user is moving so all info should be recoreded
But unfortunately, the distance from the previous point updated by traccar is 128 meters which is 12.8x the distance expected (v9.2 has elasticity disabled anyways), and activity is now recored as still but if the user was still then how did they get from point 3 to point 4 which is 128 meters apart?! that doesn't make any sense
point 5 (user has never been there)
Moving on we are going to skip to point 18
In the attached screenshot above you can see point 17 relative to 18 however sdk didn't register that the user is moving and activity is still, but how did the user get from point 17 to 18 unless they are moving?! and the distance is 7.4x the one expected from the previous update (aka update 17)
Now we are going to skip to a point that has a heading point 31 for example
right of the bet the speed is expected to be about 4 km/h, which means the reported speed isn't correct (traccar triggered GPS use prior to this update abit which I suspect why it had a heading value but didn't keep the GPS enabled long enough to record the correct speed)
finally point 35 which is 78 meters away from the previous update. At this point a pattern of inconsistency and unreliability of updates is obvious and the same point we made earlier is also clear here, if the user moved 78 m from the previous update then how is it that speed and heading isn't there and the is_moving if false and activity is still, it should have sent 7 updates all of which should have speed and heading in the posted JSON (However GPS wasn't used at all here which I also suspect is the reason for the inaccuracy and unreliability)
My recommendation if it is about the new approach valuing conserving battery vs accuracy is to approach it this way
if the user had accuracy set to high, then if at any moment a movent is detected, then according to the user's preference turn the gps on and keep it locked an turned on for x predefined (preferrably configurable settings, hidden under advanced settings) and if that time is reached check if there is no movement anymore within the past 30 seconds maybe and if there is no movement (decided based on the location from gps ) anymore then turn gps off and wait for another activity to be detected.
But if the user has set accuracy to medium, the keep the current approach as it is, since the user doesn't seem to care too much about making sure the location updates are accurate and reliable as in the case of setting the accuracy to high,
I know refactoring and revamping is harder than building from scratch and you got this Anton, However I wish the new app will be released separately until all these corners are ironed. Maybe to gather as much data release keep the old app as legacy for those who absolutely need a dependable working solution until the new version is good enough and enough logs are collected to help you out,
Sorry it was a long one, but I think you were looking for that kind of feedback not the one just ranting about a product
I got a chance to log some info and visualize it on a map to better understand the results, Here are my findings
But it boils down to, It is significantly better than the unusable 9.1.0 update but significantly worse and less reliable than the old app.
Here is how I set up this test first of all, Traccar settings are as follows
Location accuracy : High
Distance : 10
heartbeat : 900
Fastest interval : 10
offline buffering: off
Stop detection: on
will include some screenshots now from a map but for obvious privacy reasons I added a constant numeric value to the latitude and longitude to keep the ratio between the locations the same and alter their position relative to the actual one, this was done to preserve the user's privacy but still visualize it in a way that is easy to follow. The screenshots will have numbers which indicate the update index in the array of the recorded updates, an arrow pointing to the direction reported by the heading value in the posted json by traccar, when I tap on a location an alert shows up with the rest of the info.
with that out of the way let's dive into the findings
will start with update number 2 as 0 and 1 and 2 are overlapping so the most recent one in that location is the one showing up. will consider this to be our staring point
now let's check update 3
It is 280 meters from update 2, this is the first issue as the distance was set to 10 why would 2 updates be 280 meters apart! the is_moving is true so the phone should have used the GPS since accurace was set to high but it didn't !. The speed and heading had values of -1 which makes no sense as the is_moving is true and since there is movement there should be values for heading and speed which I suspect isn't there since traccar never triggered GPS till this point and just relying on the sdk for detecting movement which doesn't seem to be accurate enough (more on that later) however it detected that the activity is walking which is good. At this point let's assume it took a while for the sdk to detect movement, and that is why there is gap in the initial recorded data. let's move to update 4 and see as at this point the sdk detected there is movement and that the user is moving so all info should be recoreded
But unfortunately, the distance from the previous point updated by traccar is 128 meters which is 12.8x the distance expected (v9.2 has elasticity disabled anyways), and activity is now recored as still but if the user was still then how did they get from point 3 to point 4 which is 128 meters apart?! that doesn't make any sense
point 5 (user has never been there)
Moving on we are going to skip to point 18
In the attached screenshot above you can see point 17 relative to 18 however sdk didn't register that the user is moving and activity is still, but how did the user get from point 17 to 18 unless they are moving?! and the distance is 7.4x the one expected from the previous update (aka update 17)
Now we are going to skip to a point that has a heading point 31 for example
right of the bet the speed is expected to be about 4 km/h, which means the reported speed isn't correct (traccar triggered GPS use prior to this update abit which I suspect why it had a heading value but didn't keep the GPS enabled long enough to record the correct speed)
finally point 35 which is 78 meters away from the previous update. At this point a pattern of inconsistency and unreliability of updates is obvious and the same point we made earlier is also clear here, if the user moved 78 m from the previous update then how is it that speed and heading isn't there and the is_moving if false and activity is still, it should have sent 7 updates all of which should have speed and heading in the posted JSON (However GPS wasn't used at all here which I also suspect is the reason for the inaccuracy and unreliability)
My recommendation if it is about the new approach valuing conserving battery vs accuracy is to approach it this way
if the user had accuracy set to high, then if at any moment a movent is detected, then according to the user's preference turn the gps on and keep it locked an turned on for x predefined (preferrably configurable settings, hidden under advanced settings) and if that time is reached check if there is no movement anymore within the past 30 seconds maybe and if there is no movement (decided based on the location from gps ) anymore then turn gps off and wait for another activity to be detected.
But if the user has set accuracy to medium, the keep the current approach as it is, since the user doesn't seem to care too much about making sure the location updates are accurate and reliable as in the case of setting the accuracy to high,
I know refactoring and revamping is harder than building from scratch and you got this Anton, However I wish the new app will be released separately until all these corners are ironed. Maybe to gather as much data release keep the old app as legacy for those who absolutely need a dependable working solution until the new version is good enough and enough logs are collected to help you out,
Sorry it was a long one, but I think you were looking for that kind of feedback not the one just ranting about a product