Code (Finding ghosts): GitHub
한국어 문서/Korean
We have been studying differences of daily activity between disable people and non-disable. So, we had to gather people's move day by day. We needed a GPS tracker that is stable enough to get 30-100 people's location at once, and easy to install for participants. We've been through a few things, that is another story.
Anyway, we adopted Traccar as our GPS tracking platform base, and we'd already tried several experiments. It worked well, but we got a bad news recently.
GPS is only available outdoors.1) Today, GPS tracking system are usually built in vehicles such as airplane, ships, trucks, and taxis. They move most of the time except for a few minutes on a shaded path such as a tunnel. So, it's easy to get the location data from these objects. There are not too many tracking devices that also fit perfectly by types of vehicle. Well then. How about the location of people? Can we still get data from individual person through GPS Tracker like Traccar?
Today's people mostly spend their time inside: home, office, subway, shopping mall and so on. GPS cannot get indoor position so that we can just see where people move from a place to another place. What's more, if people send their location data through small devices like smartphone, we will face numerous smartphones. Unlike the devices for vehicles, there are a lot of things varied such as its OS, the version of OS, manufacturer, hardware conditions, etc.
So, we got some potential issues:
Besides, it is sufficient so that we can get the places our participant visits, although we don't catch actual location where they are in each place.
While we believe we know the testers' stay points, Dr. Jun, our fellow researcher, reported some clients didn't send data for several hours. It could be problems. We need to find answer for some questions:
We must look into which was right.
Unfortunately, we don't have the specific information of previous participant's devices. So, we should imagine the device which might cause some problems and should be sifted out before experiment begin. First, we picked old phones with some troubles. We want to know whether these legacy devices can run Traccar client properly. Because no small number of our study targets is the disabled and the aged. Some of them use a quite old phone that might have hardware or software issues.2)
Test starts: 20190121
Name | Phone | OS Ver. | Traccar Ver. | Network | Major problem |
---|---|---|---|---|---|
DBLAB0102 | iPhone 6 | 12.1.2 | 5.5 (latest in iOS) | Only Wi-Fi (tethered to other phone's network) | Battery Drain |
DBLAB0103 | Samsung Galaxy S5 | 6.0.1 | 5.17 (latest in Android) | Only Wi-Fi (tethered to other phone's network) | A little Lag to catch GPS signal |
Both devices have sent location data for a week. To get more information, go to the GitHub link above.
We configured the client to send its location every 60 seconds. Theoretically, it should've transmit data within 1-2 minutes even if there is some include calculation delays. Here is count of the gaps in minute.
< 2 min | 5 | 30 | 60 | 120 | 180 | 360 | > 360 | total | % of < 2 min | |
---|---|---|---|---|---|---|---|---|---|---|
DBLAB0102 | 5095 | 49 | 3 | 0 | 2 | 0 | 4 | 4 | 5157 | 98.0370 |
DBLAB0103 | 8852 | 144 | 7 | 14 | 5 | 1 | 3 | 0 | 9026 | 98.0722 |
Although the iPhone(0102)'s overall delays are shorter than the other, the count is remarkably low. The reason why it didn't send anything is that iOS blocked Traccar several times. Thus, iOS has got many long gaps.
Low battery example: DBLAB0102's shutdown (#357)
index | servertime | devicetime | latitude | longitude | battery_level | delay |
---|---|---|---|---|---|---|
284 | 2019-01-21 14:56:11.084 | 2019-01-21 14:56:10 | 37.555125 | 127.050063 | 1.0 | 00:01:01 |
285 (Gap) | 2019-01-21 18:11:50.026 | 2019-01-21 18:11:43 | 37.555152 | 127.050041 | 100.0 | 03:15:33 |
286 | 2019-01-21 18:12:45.090 | 2019-01-21 18:12:44 | 37.555191 | 127.050067 | 100.0 | 00:01:01 |
Traccar client spend the network data and battery, more or less. Old phones usually have smaller battery size than brand-new ones. We have already planned for the battery issue by providing additional battery to participants. Still, we need a tracking system that can save more energy and alert the battery getting low.
Energy saving example: DBLAB0102 (#119)
index | servertime | devicetime | latitude | longitude | battery_level | delay |
---|---|---|---|---|---|---|
46 | 2019-01-21 10:40:36.633 | 2019-01-21 09:27:28 | 37.555067 | 127.050128 | 37.0 | 00:00:00 |
47 (Gap) | 2019-01-21 10:40:36.915 | 2019-01-21 10:40:35 | 37.555115 | 127.050077 | 86.0 | 01:13:07 |
48 | 2019-01-21 10:41:40.577 | 2019-01-21 10:41:40 | 37.555111 | 127.050112 | 87.0 | 00:01:05 |
This case occurred twice on DBLAB0102 (iPhone). iOS seems to have got a kind of procedure that halts power-consuming process for a while. It may have a relation to the case 3. We have not founded the case 2 on Android phones yet.
Traccar blocked: DBLAB0102 (#1666)
index | servertime | devicetime | latitude | longitude | battery_level | delay |
---|---|---|---|---|---|---|
1664 | 2019-01-23 03:05:32.082 | 2019-01-23 03:05:31 | 37.415354 | 126.879795 | 100.0 | 00:01:00 |
1665 (Delayed) | 2019-01-24 08:28:23.978 | 2019-01-23 03:05:31 | 37.415354 | 126.879795 | 100.0 | 00:00:00 |
1666 (Gap) | 2019-01-24 08:28:24.149 | 2019-01-24 08:18:10 | 37.415651 | 126.881761 | 98.0 | 1 days 05:12:39 |
1667 | 2019-01-24 08:28:24.322 | 2019-01-24 08:27:53 | 37.454902 | 126.895622 | 98.0 | 00:09:43 |
It is critical issue. You can see #1737 data sent after unblocking Traccar. (#1738) The circumstances like this can also be shown Case 4, but the system unblock automatically in that case. We must prevent this case.
iPhone blocks a process that uses power and data continuously. As I know, the only way to unblock Traccar is to wait until iphone shows a pop-up asking whether keep blocking the process. The default option (right side) is block. If the participant are unaware, he will tap “block” and the experiment with iPhones will be doomed. Samsung phones have a similar energy-saving procedure, but we can exclude Traccar beforehand.
index | servertime | devicetime | latitude | longitude | battery_level | delay |
---|---|---|---|---|---|---|
718 (Delayed) | 2019-01-22 08:57:05.475 | 2019-01-22 03:08:24 | 37.415295 | 126.879858 | 100.0 | 00:00:00 |
719 (Gap) | 2019-01-22 08:57:07.915 | 2019-01-22 08:24:02 | 37.416994 | 126.884924 | 100.0 | 05:15:38 |
720 | 2019-01-22 08:57:11.347 | 2019-01-22 08:25:06 | 37.417065 | 126.884946 | 100.0 | 00:01:04 |
We can see server got two locations #118 and #119 at once because OS blocks sending position #118 so that Traccar client update the local location like #118 but it'd not sent. Unlike Case 3, however, the device resend the data spontaneously in this case. We've spotted a lot of idle mode delays. All of this case, the devices have no movement when they connected known Wi-Fi at home or in the office. Usually, the owner was sleeping or working inside.