차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

--- traccar-test-01 [2019/01/30 07:37]
chajh
+++ traccar-test-01 [2020/04/14 08:25]
@@ 줄 1: / 줄 1: @@
-<title> Traccar Client on Old Smartphones </title>
-{{:traccar-working.png?nolink&400|}}
-Code (Finding ghosts): [[https://github.com/jaehyukcha/jaunt/blob/master/Finding%20Ghosts.ipynb|GitHub]]\\
-[[traccar-test-01-kr|한국어 문서/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.((In fact, today's smartphones with Assisted GPS (AGPS) can get their location from nearby network routers that tell the device where they are. )) 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! =====
-{{::traccar-error1-rev1.png?nolink&600|}}
-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.((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. )) \\
-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.
-===== 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^
-^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.
-  * 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^
-^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.
-  * 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 (#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.
-  * 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^
-^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.
-  * 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.

Database Lab

사용자 도구

사이트 도구

차이

문서 도구