사용자 도구

사이트 도구


traccar-test-01

Traccar Client on Old Smartphones

Code (Finding ghosts): GitHub
한국어 문서/Korean

Intro

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.

What's the problem?

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:

  • Most of data doesn't show precise position. It is an estimated value of its place.
  • The tracker device are so varied. It is so hard to comprehend.

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.

There is a gap!

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:

  • Is there any critical gap? Have we missed a lot of the data?
  • If not, our data are really safe?
  • What causes the gaps? Should we prevent the gaps?

We must look into which was right.

Test

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

NamePhoneOS Ver.Traccar Ver.NetworkMajor problem
DBLAB0102iPhone 612.1.25.5 (latest in iOS)Only Wi-Fi (tethered to other phone's network)Battery Drain
DBLAB0103Samsung Galaxy S56.0.15.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.

Result and Analysis

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.

Case 1: Low battery and shutting down

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.

  • Some data could be missed if the participant would have not recognized the battery level.

Case 2: Low battery and energy saving mode

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.

  • Some data could be missed if the participant would have not recognized the battery level.

Case 3: Process killed/blocked by OS

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.

  • iPhone: Some data could be missed if the participant would have clicked pop-up unconsciously.
  • Android (Samsung): Some data could be missed if the participant would have turned off energy saving options in advance.

Case 4: Sleep mode/idle

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.

  • Safe. But, there could be a lag for recalibrating GPS signal.
  • If the user didn't go outside for a long time, we could be misunderstood this case as Case 3.

Summary

  • Most gaps caused by sleep/idle mode of the operating system. There is no data loss unless the user forgot carrying his phone.
  • The user must experience the device blocks Traccar because of its power consumption. It is usually three days after. We need to make sure the participant's client unblocked.
  • Battery issue is not trivial.

Future works

  • This is data about locations. We need to make some visualization tools with Korean maps. Traccar supports google and openstreetmap but they have some deficiencies because of legislations.
  • We also need monitoring system for notifying users to prevent any data loss.
  • All participant have to take a pre-test period at least three days. We could assure Traccar working on the device fine.
1)
In fact, today's smartphones with Assisted GPS (AGPS) can get their location from nearby network routers that tell the device where they are.
2)
The disabled and the aged are normally not rich, rather than others, at least in Korea. (I think it is global phenomenon) Anyhow, we'd better ready for a participant who has a phone that we're not familiar with.
traccar-test-01.txt · 마지막으로 수정됨: 2021/04/13 06:54 (바깥 편집)