BUG: Location data recording cadence is unreliable - DHM-S1-14 #454
Comments
|
It would be good to start with a view from Dev on what the expected spec is here? Should locations be logged every 300 seconds, like clockwork? Or is some variability expected? What level of variability should we consider a bug? I think the behaviour Chris reports is certainly bugged, but we don't know how widespread that is yet. Once Dev has clarified what counts as a bug, we should probably aim for the test team to collect and analyze more data to assess the frequency of these problems. |
We will get a spec with the expected logging written up for you. There will be a fair amount of variation in the logged intervals, based upon many factors, and it is somewhat complex. For the most part, if the phone isn't moving significantly, we would expect the logging to be near the 5 minute interval, but can be longer. After the next patch the logging should never be faster than every 4 minutes. |
|
To state the obvious. The keywords here are "if the phone isn't moving significantly". So you always need to check the inertial sensors for type and duration of movement . I mentioned this here. |
|
Changed title to reflect that this issue is specifically about the cadence of logging, not the location data itself (tracked as another issue). |
diarmidmackenzie
changed the title
|
Just to be clear. When a gps data point is logged, is it using the internal phone clock for time stamp or that of the gps signal? It sound to me that you're using the phone clock, and that processing for this depends on how busy your processor is at the time. Since most people have just about every social network app running at the same time I'm not surprised that there are random lags as to when a data point is actually processed (timestamped). Unfortunately you did not allow me any access to the google doc above so...not much to look at. |
|
I have been testing with several users and can contribute more based on v1 installed via the play store. User 1 - Samsung Galaxy S8 2020-04-25 15:04:21.418000, diff: 331410 The tester recorded their location for a period of ~4 hours. On average the location was recorded every 9 minutes instead of 5. Additionally, travel (by car) took place between 1850 and 1913. User 2 - Pixel 2 2020-04-25 09:49:08, diff: 527477 User 3 - Pixel 3a User has been recording for several days so the full data is not included. Summary |
|
Several recent test reports of real-world GPS testng, all massively impacted by this issue & seeing GPS logging lock-ups of up to 8 hours. https://pathcheck.atlassian.net/wiki/spaces/TEST/pages/24412463/25+April+2020+-+Real+world+GPS+%232 https://pathcheck.atlassian.net/wiki/spaces/TEST/pages/24543370/26+April+-+Real+World+GPS+Test+4 Results from these tests seem to point to there being multiple issues here, each with a different signature. Suggest we begin investigation of the issue in general, and then break out into multiple issues if needed. This is now becoming urgent as it both blocks further testing, and it will impact testing at our initial prospects, and also be visible to anyone who downloads the APp from teh app store & chooses to test it out. |
summetj
added
Enhancement
|
Question: Does this impact iOS as well as Android? I hope some of the work w.r.t. GPS inaccuracy may end up solving the cadence issue as well. (Perhaps we should log more frequently (2.5 minutes?) and only save every 5 minutes or upon motion?) Getting a "ping" from accerometer data that the phone is actually moving could help us save power by NOT sampling location when the phone is not moving.) If anybody who is working on the GPS logging system wants me to assign this issue to them please speak up.... |
|
I don't have iOS - I have only analyzed one data set from iOS from Elvira, and it was perfect. More testing needed, though. Using accelerometer, we should consider that mobvement & acceleration are not the same thing. People on e.g. trains may be moving fast with no trigger on the accelerometer. We may be willing to trade off these cases for the improved battery life - but we should do so consciously. |
There should still be enough jerk in trains/cars to trigger logging unless you are in a VERY smooth train with no corners or acceleration/deceleration ever... |
|
Closing this issue out as we have work in-flight to improve both the reliability and accuracy of our location tracking. |
Minor variatons seen in my first test session, but other users have reported much more significant issues. Broad issue covering the whole topic,
Here's my intiial report.
https://docs.google.com/document/d/1Uh1A-h7Ddm6t-rAlHOM90xnsrkLEG9SGcTolf3uIbgQ/edit
[DHM-S1-14 - New 454] Gaps between records in the location data were highly variable: 300, 308, 318, even 518 seconds.
I also have this from Chris Wren, which suggests some more severe issues. His suggestions that we analyze broadly in test is worth following up on.
I noticed that it hasn't been taking up much battery lately, so I dumped my locations and discovered that it hasn't been collecting locations, and also that the exported file is pretty chewed up. It started recording March 31, 10am when I installed it, then it injected some nonsensical timestamps from March 15, then jumped back to March 31, recorded for a little over a day until April 1, 8pm and then stopped, but continued to record the identical timestamp and geolocation several thousand times until I launched the app on April 10, at which point it recorded one novel point. Many of the correct samples seem to be duplicated as well, but not all. So lots of issues there. How do you validate the export files? Do you routinely collect exports from the team to make sure they look right, or have some other testing harness? If it's helpful I put my timestamps in a sheet, here's a link.
The text was updated successfully, but these errors were encountered: