문서의 이전 판입니다!
Code (Finding ghosts): GitHub
English/영문판
Traccar 가 신호를 보내지 않는 텀(gap)이 발생하는 원인과 데이터 유실 확인
1번 경우는 매우 많이 발생하나 데이터 유실은 없는 것으로 보인다. 새벽 시간과 실내에서 일하는 시간에 많이 목격되는 현상.
2번 경우는 자주 발생하진 않지만 실험자가 배터리를 충전해주는 것이 아니면 방법이 없다. 모니터링 시스템이 피실험자에게 낮은 배터리 경고를 보내야 할 것 같다.
3번은 가장 심각한 문제로, 안드로이드 폰에서는 절전 앱 리스트에서 제외하는 것이 가능한 것으로 보이지만(삼성, LG 확인), 아이폰은 3일쯤 뒤에 먼저 프로세스를 막고 사용자에게 Traccar를 계속 허용할 것인지 물어보는 팝업을 띄운다. 만약 이 팝업을 제대로 읽지 않고 차단했을 경우 다시 해제하는 방법이 있는지는 아직 알 수 없다.
자세한 건 하단 표의 Delayed 부분을 참조.
장치에서는 정보 송신을 위한 데이터가 생성되었으나(timestamp: devicetime ) Server에는 송신되지 않는다. 그리고 idle 상태가 해제되면 다시 전송을 재개한다. 전송되는 데이터의 순서(position id)와 데이터의 생성 타임(devicetime)이 서로 섞이는 것도 위치는 수신되었지만 전송이 되지 않음을 의미하는 것으로 보인다.
배터리 부족으로 기기의 전원이 종료될 때는 보이지 않는 현상으로 의도적인 프로세스 블록이 발생할 경우 나타나는 현상으로 보인다. 서버의 응답이 없는 경우 안보내지는 것이 아닌 나중에 연결이 회복되면 저장된 데이터를 보냄. 즉, 서버 문제는 아니다.
알려진 네트워크, 충전 중 등의 상황에서 몇 십분에서 몇 시간까지 Traccar가 block 됨. OS가 다시 깨어나면 재전송.
—— 작성 중 ——–
이미 우리는 2015년 CRC 과제와 이번 과제 중 장애인과 비장애인 30명 씩 대상으로 위치 정보를 수집했었다. Traccar가 아닌 자체 외주 개발 앱을 사용한 적도 있었지만 문제가 많았고, Traccar를 사용한 뒤 크게 문제가 없는 것으로 보였다.
GPS는 기본적으로 야외에서만 사용 가능하다.1) 또한 대부분의 GPS Tracker는 야외에서 활동하는 객체들을 위해 디자인 되었다. 비행기, 기차, 화물차, 택시 등 법적으로 영업용 운송수단은 이동 기록을 제출하도록 되어있고, 회사들은 GPS Tracker를 자신들의 차량에 부착한다. 이러한 차량들도 GPS 신호 음영 지역에 들어가는 경우가 있지만 대부분 알려진 터널, 차고지 등일 경우가 많다. Traccar도 마찬가지로 많은 기능들이 차량을 기반으로 만들어져 있다.
반면에 사람은 대부분의 시간을 안에서 지낸다. 또한 건물 안에서 활동을 한다. 따라서 우리는 GPS를 통해서 사용자들의 '활동'을 파악할 수는 없다.
GPS is only available outdoors.2) 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.3)
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 |
---|---|---|---|---|---|---|
356 | 2019-01-21 14:56:11.084 | 2019-01-21 14:56:10 | 37.555125 | 127.050063 | 1.0 | 00:01:01 |
357 (Gap) | 2019-01-21 18:11:50.026 | 2019-01-21 18:11:43 | 37.555152 | 127.050041 | 100.0 | 03:15:33 |
358 | 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 |
---|---|---|---|---|---|---|
118 | 2019-01-21 10:40:36.633 | 2019-01-21 09:27:28 | 37.555067 | 127.050128 | 37.0 | 00:00:00 |
119 (Gap) | 2019-01-21 10:40:36.915 | 2019-01-21 10:40:35 | 37.555115 | 127.050077 | 86.0 | 01:13:07 |
120 | 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 (#1738)
index | servertime | devicetime | latitude | longitude | battery_level | delay |
---|---|---|---|---|---|---|
1736 | 2019-01-23 03:05:32.082 | 2019-01-23 03:05:31 | 37.415354 | 126.879795 | 100.0 | 00:01:00 |
1737 (Delayed) | 2019-01-24 08:28:23.978 | 2019-01-23 03:05:31 | 37.415354 | 126.879795 | 100.0 | 00:00:00 |
1738 (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 |
1739 | 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 |
---|---|---|---|---|---|---|
118 (Delayed) | 2019-01-21 10:40:36.633 | 2019-01-21 09:27:28 | 37.555067 | 127.050128 | 37.0 | 00:00:00 |
119 (Gap) | 2019-01-21 10:40:36.915 | 2019-01-21 10:40:35 | 37.555115 | 127.050077 | 86.0 | 01:13:07 |
120 | 2019-01-21 10:41:40.577 | 2019-01-21 10:41:40 | 37.555111 | 127.050112 | 87.0 | 00:01:05 |
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.