To send commands via the TCP and UDP channels, the unit should be connected to the server. You can see the connection state of the unit on the Monitoring tab.
Depending on the device type, the number of virtual commands in a queue for execution can be limited. If the queue is overfull, the commands sent first are deleted.
This problem occurs mainly while sending SMS commands, when the encryption protocol of the communication service provider differs from the Wialon protocol. In this case, contact the communication service provider because the message has been decrypted incorrectly.
The reasons can be mainly as follows:
Yes, use the Register working interval feature on the Drivers tab.
No, the bindings cannot be registered automatically using imported messages or messages of the past period.
Yes. Read more about simultaneous bindings of the drivers.
For real-time assignments, activate the Exclusive option in the properties of the drivers. Read more about simultaneous bindings of the drivers.
The storage period of messages about the bindings of drivers corresponds to the history period of the account to which the resource belongs.
Yes, but only if the driver has not had other bindings since he was last assigned to the unit.
Check if a sensor of the Driver binding type with a parameter (usually it is avl_driver) is configured in the unit properties. In messages, this parameter should contain the information about the driver’s code.
Make sure that the driver’s code from the message with the parameter corresponds to the code in the properties of the driver.
Check if the unit belongs to the list of the units to which the drivers from this resource can be assigned using the automatic binding method.
When you use different devices, they might interpret the driver’s code differently. To bring this code to one form, use one of the methods described below.
Method 1. Specify the mask (IButton card number parsing mask) in the configurator of the device type (the icon in the general properties of the unit).
Method 2. Indicate the formula avl_driver:16 (where avl_driver is the parameter of the driver) as the parameter of the sensor. It allows converting text from hexadecimal (HEX) to decimal (DEC) number format. In the calculation table wizard, you can use the obtained decimal value as X and specify an arbitrary value (or, for example, the driver’s code) in the Y column.
To add a new map, send your request to firstname.lastname@example.org. Attach a vector map in one of the supported formats (MP, MapInfo, ESRI Shape, OSM, or KML) to your email and give us a link to download the map. If the size of the map does not allow sending it by email, you will be given FTP access. The data must be in the WGS 84 coordinate system.
A CSV or XLSX table can be used to upload addresses to Gurtam Maps. Such table should contain the following columns: house number, street, city, region (optional), X and Y coordinates in WGS-84. You can download a table template here.
Gurtam Maps do not support the DWG format, but AutoCAD allows you to export data to other formats supported for import (MP, MapInfo, ESRI Shape, OSM, KML). Make sure that WGS-84 is set for the data.
You can limit the access to custom maps with a billing plan. If you want a map to be available only to one client, create a separate billing plan, assign it to the client’s account, and specify the name of this billing plan in your request to email@example.com. The map will be available only to the users that use accounts with the created billing plan. It will not be available to other Wialon users.
Please, send your request to firstname.lastname@example.org indicating the coordinates of the place and the correct address.
In this case, it is necessary to upload a more detailed map to Gurtam Maps. If you have a map of your region in one of the supported formats (MapInfo, ESRI Shape, OSM, KML), you can send it to us for adding to Gurtam Maps. We can also use the data of open sources, for example, OpenStreetMap. You can add the missing information to OpenStreetMap and then send us an email to email@example.com. We will try to upload the data to Gurtam Maps.
Consult the service directly. We can only connect third-party cartographic services and are not responsible for their contents.
Possible explanations and actions:
Possible reasons and their elimination:
1. Outliers of data.
To detect such outliers, build a track of unit movement for the appropriate period. Outliers of data will be seen on the track as dashed lines.
Ways to overcome outliers:
2. Incorrect settings or operation of the mileage counter.
Possible reasons and how to eliminate them:
Possible explanations and actions:
1. Incorrect settings for trip detector.
The option to analyze fuel filling only at stops is set in the properties of the fuel level sensor, however, the trip detection is not adjusted correctly. Either disable filling detection at stops or change trip detector settings (in particular, increase minimum moving speed or maximum distance between messages).
2. High filtration level of FLS.
Decrease the filtration level of FLS in its properties (recommended are values up to 15) or set the Calculate filling volume by raw data option.
3. High value of minimum filling.
Decrease the value of the minimum filling volume in the properties of the fuel level sensor.
Possible explanations and actions:
1. Test theft right before fuel filling.
If you made a defueling for test purposes and then refueled the vehicle right away, the system may regard this as an outlier of data. In real situation, when a theft is not followed by immediate refueling, such theft will be detected.
2. Theft during a prolonged shutdown of the device.
A theft can be detected only if the Time-based fuel level sensors consumption option is off (see the properties of the fuel level sensor) and if there is a trip after switching on the device again.
3. High filtration level of FLS.
Decrease the filtration level of FLS in its properties (recommended are values up to 15) or set the Calculate theft volume by raw data option.
4. High value of minimum theft.
Decrease the value of the minimum theft volume in the properties of the fuel level sensor.
1. Mileage-based calculation
In a standard situation, all calculations of fuel level are mileage-based. That means data from the FLS is taken only during intervals of movement (trips). Those trips are defined according to parameters set in the trip detector.
Thefts and fillings are detected if there is a difference between the fuel level on the following movement interval (X) and the fuel level on the previous movement interval (Y). If (X — Y) > 0, it is a filling; if (X — Y) < 0, it is a theft; if X = Y, it is neither. Of course, there can be some inaccuracy in data coming from the FLS. That is why, to avoid false thefts and fillings, set the following parameters in the FLS properties:
2. Time-based calculation
This type of calculation is more complicated and is based on the following algorithm: the speed of the decrease of fuel level according to the FLS is compared with the consumption calculated mathematically. The time-based calculation is necessary for stationary units. It is also widely used for moving units for controlling thefts during the movement, for example.
A vehicle stayed at a parking lot during 10 hours. Defueling was made in small portions over the whole parking period. As a result, 60 liters of fuel were stolen. It is possible to determine if it was a theft o fuel consumption according to the state of the unit's ignition sensor.
Since the consumption math mechanism is based on the values of the ignition sensor, check its properties and operation. You may not have this sensor created or there may be 0 l/h indicated for the fuel consumption in its properties.
You may use one of the approaches described below.
Create a virtual ignition sensor. We recommend that you use average speed (speed+#speed)/const2 as its parameter.
Even if you haven't installed an ignition sensor in the unit or are not sure of the name of the parameter that responds for the ignition, in the parameters of the device there may be some characteristic that corresponds to the operation of the engine. To use it, compare two messages from the unit: one — when the ignition the most probably off; the other — when it's on.
During a long time interval the unit sends approximately the following set of parameters:
While moving at some speed — approximately the following:
Straight before the start of the movement, as a rule, the ignition turns on:
Discard the parameters that are obviously imprecise: hdop (precision), adcN (it's difficult to determine the regularity), odo (relative odometer in meters), mcc mnc cell_id and lac (LBS data section), gsm_lvl (the level of the GSM signal), etc. The parameter J1708_eng_hrs for this unit seems the most probable, as it doesn't change during the night parking. As a rule, it is also possible to use pwr_ext. Is the ignition is digital, you can follow the values' changes in the block 'I/O =' (see more details in the Inputs and outputs section).
If you have already connected the ignition, find out its parameter by means of the method described above or from the manual of the manufacturer.
Let us suppose that the fuel consumption in the urban cycle is 10 l/100 km and 7 l/100 km — in the suburban cycle.
Note that the last pair of points is how the system calculated before (the fuel consumption was considered constant for a speed above 80 km/h). You cannot use this method and change the set of points. Also '3' in this example is the minimum speed from the unit's trip detector, consequently, this parameter can be different for your unit.
Result: in our example, the average consumption has been calculated for the unit. It has been calculated relative to the speed and time between messages and taking into account the values of the vehicle operation.
During the mathematical calculation, fuel consumption is computed separately for each pair of messages.
The following algorithm is used:
This option is on the Advanced tab.
As a rule, the seasonal coefficient supposes increased fuel consumption. For instance, the consumption in winter is 30% higher than in summer. Let us suppose, that the winter in your climate is from December, 1 to March, 1.
time is the parameter that is present in any message from any device, and the system will calculate the number of the day automatically on its basis. In that way, as the season starts, 30% will automatically be added to the fuel consumption.
A more accurate result can be obtained if there is, for example, an ambient temperature sensor by means of calculating an increase in the norms in certain conditions.
They are necessary for the adaptive calculation of fuel data taking into account different conditions: various types of implements, temperature regimes, operating conditions, vehicle mileage and its technical state, several fuel consumers on the same unit, acceleration/braking, engine revolutions.
LBS (location-based service) is a service that determines the location of a unit according to the coordinates of GSM base stations.
GPS may be unavailable for various reasons: GPS antenna failure, dense urban development, tunnels, parking garages, and so on. In such cases, it is advisable to use LBS. Due to shorter waves, the probability of LBS catching the signal in places with obstacles (reinforced, metal, shielded surfaces) is much higher.
The accuracy of LBS is generally lower: it depends on local radio conditions, the density of the base station network, cell configuration. However, it is easier to catch the signal using LBS. This increases the chance of receiving positional data in a message when GPS is not available.
If technical conditions are met, the service can be configured for any monitoring unit. For the most part, LBS is used in the fields where the exact coordinates are not so important as the fact of arrival, departure, moving, or stopping.
For example, in container shipping, a device installed inside the container does not catch the satellite signal. However, the LBS messages show the fact of delivering the goods to the warehouse, unplanned stops, significant deviations from the route.
LBS is also used for monitoring stationary units, especially if the device does not have a source of direct current. This saves the battery life of the device, while a disabled GPS module would significantly increase it.
You can find a list of supported devices in the Hardware section of our site.
When the monitoring unit does not send positional data via satellites, Wialon reads the identification number of the base station and searches for the coordinates in the database.
Wialon uses its own database. It is updated as new messages with LBS and GPS coordinates are received from the units. Before adding new points to the database, they are additionally checked. At the moment, the database includes more than 62 million points.
The messages should contain 4 parameters: cell_id (identification number of the base station of the mobile operator), mcc, mnc, and lac (service parameters). To verify the fact of their correct transmission and reception, request data messages on the Messages tab.
To see the last unit location determined by LBS, use the LBS detector.
In order for the LBS data of the unit to be saved in Wialon, open the Advanced tab of the unit properties, enable message validity filtration and activate the Allow positioning by cellular base stations option. After that, the LBS coordinates will be used in reports and when displaying the unit on the map. For notifications, activate the Process LBS messages option in their settings.
The LBS coordinates of the unit are saved only if they are determined later than the GPS coordinates in the message.
If the location of the unit is determined by LBS, you can tell this by how it is displayed on the map and by the icon which is shown opposite the unit name in the work area of the Monitoring tab.
Send a request to firstname.lastname@example.org indicating the type of device for considering the issue.
Send a request to email@example.com indicating the values of the parameters mcc, mnc, lac, cell_ID.
The AVL hardware installed in a vehicle figures out the location of that vehicle with help of satellites, gathers data from various accessories and sensors and transmits the data through a cellular or satellite network to Wialon data center. This data can be interpreted to monitor in the Wialon web interface the whereabouts and other parameters of a vehicle in real time.
We’re ready to support a new device by customer’s request. All you need to do is to email us at firstname.lastname@example.org. Please specify the following information in your email if possible:
In case you don’t have the information mentioned above, don’t worry – we will contact the manufacturer ourselves and try to get whatever is required for integration.
The integration of LoraWan, Sigfox and other similar devices is the same as for any GSM hardware. If the device is not integrated yet, kindly contact us at email@example.com.
At Gurtam we do not sell any hardware devices. We’re the software developer only. Nevertheless, we’re trying to inform our customers about various hardware compatible with Wialon platform.
Therefore to get the device you’re interested in, please contact the manufacturer or your local supplier.
We recommend you to use Wialon IPS protocol. Wialon IPS communication protocol was developed by Gurtam for personal and vehicle GPS/GLONASS trackers, which send data to the satellite monitoring system server over TCP.
Wialon IPS protocol is freely distributed under GNU FDL and can be used by manufacturers of GPS and GLONASS equipment as the main protocol for data transmission between GPS/GLONASS trackers and communication server of the satellite monitoring system.
Our goal is to support full trackers functionality in Wialon. We remain hardware agnostic company and do not distinguish any manufacturer leaving the choice to our customers. When choosing hardware you may refer to Gurtam rating of manufacturers or decide on any other device even if it is not integrated with Wialon yet.
In most cases, there is no need to integrate additional hardware with the platform since they work in conjunction with a GPS tracker. Therefore if the tracker is integrated with Wialon, you can connect various sensors to it.
In case when a sensor has its own GPS module or works through transparent channel, integration might be needed and we will list it as a separate device type in Wialon.
To check device unit ID, please use id.wialon.net service.
First, please learn the device user manual provided by the manufacturer or supplier. If you still have difficulties with device configuration, email us at firstname.lastname@example.org and we’ll do our best to assist you.
Though it is common to set up local time zone on GPS devices, it is not recommended, as Wialon works with data in UTC+0h time zone only. This is a mandatory requirement for correct data display in the system. So please reset time zone to UTC+0h in your device. Whereas, local time zone should be set in your Wialon account.
Yet there is an exception from the rule – GPS watch. In this case, you should set a local time zone in the device. When integrating such device type we allow for specifying local time zone in unit properties, after that Wialon will automatically adjust it to UTC+0h.
If after that the tracker still doesn’t show online in Wialon, please contact us at email@example.com and we will try to assist you.
Raw data storage requires huge drive space and is not of practical value for users.
There could be a few reasons for it: your tracker doesn’t see satellites, GPS module or GPS antenna is not working.
There could be the following reasons for it.
Yes, you can! Wialon supports video hardware which allows for real-time video tracking as well as getting video files from the device's memory by command or event.
The full list of supported video hardware is available here.
Video monitoring in terms of GPS tracking is quite a young industry therefore not all video devices are suitable for working with GPS tracking platforms. To integrate a video device with Wialon, it should meet some requirements from our side. If you want to have your device supported in the system, kindly email us at firstname.lastname@example.org and we will analyze the possibility of integration.
If you want to receive technical consulting on HU-GO products call +37052078283 and we will analyze your problem.
A possible explanation is that the unit is included in a group to which the user has some access.
The reason is a slight inaccuracy in coordinates sent by the tracker. It is absolutely normal for any type of equipment. This inaccuracy is appreciable, particularly at parkings. A unit stays still, however, the coordinates sent by the tracker slightly differ from each other. That is why 'stars' appear at the places of parkings.
You may want to get rid of those 'stars' to make the track look more intelligible. To weed off the stars at parkings, apply the trip detector to that track:
Make sure that the trip detector is adjusted correctly. Additionally, you can activate the message validity filter on the Advanced tab of unit properties.
1. You need a tachograph and a tracker which supports unloading DDD files.
2. Create a driver in the monitoring interface. The value of the Code field must correspond to his personal card's number.
3. Create a sensor of the Driver binding type and add the unit to the driver's automatic binding list.
4. Add a command for unloading a DDD file on the Commands tab of the unit properties. The command syntax may vary depending on the device type.
5. For executing a command of querying a DDD file, the unit must have an open TCP connection (the timeout depends on the type and the configuration of the tracker).
6. After unloading a DDD file the following line appears in the messages:
The syntax of the response depends on the type of device used. Some devices send an additional response by means of the Chat with drivers window.
The time needed for unloading a file depends on the tracker (it may take from 5 to 30 minutes approximately).
7. You can view the downloaded file and check the driver's work for a previous interval in the application TachoView.
8. The DDD files from a driver's card are stored in a resource. The storage period of such files is not limited; they are deleted together with the resource they belong to.
Different algorithms are used when processing messages for the mobile application and the Wialon reports. In some cases, the results of processing may differ. See more about the reasons for such discrepancies.