GPS monitoring - message attribute analysis

    This post raises the Hamlet question “To be or not to be” to an attribute in the message history. The approach adopted in ViaLatM GPS monitoring system is described , and arguments in favor of these solutions are presented.

    The set of attributes sent by trackers is quite wide. It ranges from 2-3 basic for personal trackers and beacons, to dozens (including information from connected sensors and CAN buses) coming from telematics devices installed on vehicles.

    Here we will discuss some of the basic attributes that are sent by most types of devices: speed, direction of movement, validity of determining coordinates, DOP factors and the number of satellites.

    Less than a year ago, we posted on our site two small articlesdedicated to the speed and attributes of geolocation, which briefly touched on the issues raised in this post.

    By reducing the number of attributes stored in the message history, we optimize the amount of disk space and increase the speed of generating reports (traffic, parking, visiting geofences, ...) and displaying traces for certain time intervals.

    In this case, for the last message received from the device, all message attributes are stored and available for display and processing .

    Speed

    Trackers transmit the instantaneous speed of an object. This speed is calculated based on the determination of coordinates by satellites and accordingly has an error. In ViaLatM, we do not save instant speed in the message history. It is displayed for the last event, and the reports use the average speed instead, which can be calculated based on the distance and time interval between two neighboring points. Below on the graph, the red line corresponds to the instantaneous speed, the blue line to the average speed.The graphs are quite similar. For the user, the average speed gives much more useful information. If the interval of transmission of messages by the tracker during movement is large enough (for example, 10 minutes), then the instantaneous speed may not display the real picture. Suppose the instantaneous speed at the entrance and exit of the “traffic jam” is 60 km / h, and the distance between two points is 1 km. Then the average speed for the moment of exit from the traffic jam will be 6 km / h and this is more consistent with the real situation.

    Statistical studies have shown that the smaller the time interval between messages on moving objects, the less the deviation between the average and instantaneous speed. In most trackers, messages are transmitted more often during movement than in parking conditions.

    At the same time, control and generation of notifications about speeding mode violations is carried out on the basis of instantaneous speed. In these cases, the instantaneous speed is stored in the violation notification settings.

    Direction of travel

    When working with the message archive, we did not find the use of this attribute. Yes, and when observing the object in real time, perhaps the only possible benefit from it is when the message came at the fork of two roads, and the user can understand which road the object will move next.

    Location validation feature

    Most types of devices return a sign of correct location. The attribute is processed but not stored. The presence of coordinates in a saved message is a fact of their validity. If a message arrives with a sign of incorrect determination of coordinates, and the coordinates themselves are present, then they are deleted before saving the message in the archive.

    Number of satellites

    The number of satellites by which the location is determined also carries little information. Sometimes with the visibility of 3 satellites, the location can be determined more accurately than with 10 satellites, if the latter are located on the line. ViaLatM does not save coordinates if the number of satellites is less than 3.

    DOP attributes

    DOP attributes (HDOP, VDOP, PDOP, and TDOP) are factors for the weakening of accuracy that are transmitted in messages by some types of devices. For ordinary users, it is more obvious to calculate and display, based on their values, the accuracy of determining the coordinates. The green circle in the figure shows the accuracy of determining the coordinates for the last event. The violet polyline is the device’s track (the device’s track for the last 10 minutes, but not more than 20 points). In the current version, we maintain the accuracy of determining the coordinates for all events. But maybe this does not need to be done for the moving ones.

    GSM signal strength

    Another attribute with which it is not clear what to do to the average user. According to its value, we can conclude how well cellular communication works in one place or another. For monitoring, this concerns the issue of data transmission via GPRS. But what conclusions can be drawn based on the value of the attribute is not clear to us.

    "What we do not store, computing by crying"

    It is impossible to restore parameters that are not saved (direction of movement, the validity of determining coordinates, the number of satellites and the level of the GSM signal), but so far we have not come across a case where for a properly working tracker it would be necessary to obtain the historical value of at least one of these parameters.

    Regarding the instantaneous speed, as noted above, it is close to the calculated average speed, which, in our opinion, is more informative. There was a problem. If the maximum permissible speed was not set for the device (accordingly, alarm notifications about violation of the speed mode were not generated), then the formation of a report on speeding takes longer than if the instantaneous speed were maintained. Statistics of users ’access to reports showed that this report is requested an order of magnitude less than reports on traffic, parking, visits to geofences and alarming events. The choice was made in favor of accelerating the formation of more frequently requested reports.

    ViaLatM system can put the device into test modein which all message attributes are stored. This mode is used at the stage of connecting new types of devices or checking devices whose correct operation is in doubt. Messages of this kind are not stored in the standard archive of events, but in a separate archive (while exporting events from this archive to the standard one is allowed).

    Conclusion


    In the ViaLatM system, we adhere to the principles of:
    • Save only what is used and cannot be calculated
    • Display only what carries user-friendly information

    Each of the principles must be approached carefully.

    If some attribute (of potentially calculated ones) is often used in reports and its calculation requires significant resources, then you should think about its permanent storage.

    The question of what information is useful to the user is unlikely to have an unambiguous unequivocal answer. When the GSM signal strength attribute was constantly stored and displayed in reports in our system, we interviewed 10 users. All together answered that the attribute is needed (let it be, it does not interfere). When we removed this attribute from persistent storage and display in reports, only one of the surveyed users noticed its disappearance. But the question of how he uses it, he did not give an intelligible answer, and it was not difficult for us to convince him that he did not need him. This is a matter of psychology. People will not refuse additional functions because they will not want to spend time thinking about how much they really need them (“Maybe it’s useful” and there’s nothing to rack your brains on). But one of the most important tasks of developers is to remove all unnecessary.

    We will be grateful to the Habrachians for expressing ideas and criticizing our approaches.

    Also popular now: