Fleetrun
Hecterra
NimBus
Other apps
Wialon for Android/iOS
Logistics
Wialon Local
Wialon Hosting
Distance Tag
WiaTag
Configurator
Contents
By date
Math Consumption
  • technical_consulting
  • fuel

Some trackers don't send information about fuel, or a unit is not equipped with fuel sensors, but users still want to see fuel consumption data in the report.

As an alternative to fuel sensors, you can use Consumption by rates, which is configured on the Advanced tab. Its calculation algorithm is simple: the mileage per interval is multiplied by the specified consumption rate (l/100 km), which may vary depending on the season. But in this article, we will cover another option for calculating fuel consumption without a sensor, which requires more explanation — Fuel consumption by math, aka Math consumption. Moreover, its field of application is not limited to one use case.

Where can you use math consumption?

First of all, math consumption is used in reports to compensate for the absence of fuel sensors or verify their readings. To display the results of a mathematical calculation, add the Consumed by math, Avg consumption by math columns, or other columns that have "by math" in their title to the table.

Math consumption is also used in fuel algorithms. Firstly, to detect fuel thefts if the Time-based calculation of thefts option is enabled. Secondly, to calculate the consumption on intervals with invalid values, if the Replace invalid values with math consumption option is enabled. Both mentioned options are in the additional settings of FLS.

How does math consumption work?

The system determines the expected consumption for an interval using a mathematical model. It is built on the basis of:

  • engine operation sensors (ignition or absolute/relative engine hours) that indicate the fuel consumption rate at idle;
  • engine efficiency sensors (EES), each of which indicates the influence of some factor on fuel consumption (engine rotation speed, temperature, axle load, air conditioning, attached equipment, and so on).

Math consumption per interval is the sum of consumptions between all messages on the interval. The following formula is used to calculate math consumption between the current message and the previous message:

Δt ⋅ ( CI 1 + CI 2 + ... + CI N ) ⋅ (KEES 1 + (KEES 2 - 1) + (KEES 3 - 1) + ... + (KEES M - 1)),

where Δt — the time between messages; CI j — consumption rate at idle from the j-th engine operation sensor, which was enabled in the considered message; N — the number of engine operation sensors created in the unit; KEES i — the value of the i-th engine efficiency sensor in the considered message; M — the number of engine efficiency sensors created in the unit.

We should note that the given formula applies only to bound sensors.

Why bind engine operation sensors, engine efficiency sensors, and FLS?

Some units have several engines. In most cases, this is special-purpose machinery, and a concrete mixer truck is a good example: its main engine makes the vehicle move, and an additional autonomous engine rotates the mixing drum. Accelerating the vehicle or turning on the air conditioner may affect the fuel consumption of the main engine but will not affect the consumption of the additional one. Consequently, some factors affecting consumption (we take them into account using engine efficiency sensors) affect only one of the engines (we take them into account using engine operation sensors). At the same time, the unit may have several fuel tanks (we take them into account using FLS), which also need to be bound with a specific engine.

To bind mentioned sensors, you should enter the properties of the ignition sensor or absolute/relative engine hours sensors and select the appropriate engine efficiency sensors. Similarly, in the FLS properties, you can configure its binding with engine operation sensors.

How to quickly create a mathematical model?

To create a basic mathematical model, use Math Consumption Wizard located on the Sensors tab in the unit properties. In the Math Consumption Wizard window, you need to enter information about fuel consumption in different operating modes, as well as the seasonal multiplier and the season's start and end dates. Let's take a closer look at these fields:

  • Fuel consumption (l/h) refers to consumption at idle, i.e., with the engine running and the vehicle not moving. The Min moving speed is taken from the Trip Detector.
  • Urban cycle and Suburban cycle (l/100 km) are standard vehicle characteristics you can find in documents, on the internet, or calculate in practice. At the same time, different countries use different approaches to defining these cycles. In Wialon, the urban cycle rate corresponds to a speed of 36 km/h, and the suburban one  80 km/h.
  • Seasonal multiplier (%) refers to the percentage increase in fuel consumption during the specified season compared to the rest of the year. You can disable the seasonal factor if there are no significant temperature changes throughout the year in the area where the vehicle is used.

The more data you enter, the more accurately the mathematical model will work, but the minimum information you should provide is urban cycle consumption.

By filling in Math Consumption Wizard, you will create a basic mathematical model that considers only the unit speed and seasonal influence. Such a model is approximate because, in practice, speed doesn't affect consumption  the engine rotation speed does, as well as the season doesn't affect consumption  the temperature does. However, by default, most trackers don't send information about engine rotation speed and temperature. That's why we've chosen a model that is suitable for all trackers.

It's impossible to automatically create a more accurate model, but you can do it manually by adding engine efficiency sensors.

How do engine efficiency sensors work?

The value of an engine efficiency sensor in each message should show how many times an influencing factor increases the consumption at idle compared to the consumption without the influence of this factor. For a better understanding, let's look at an example.

Let’s assume that the consumption at idle is 2 l/h, and when the heating system is turned on, the consumption increases to 2.2 l/h. Therefore, the ratio of these values is: 2.2/2 = 1.1
Let's also assume that the in4 parameter indicates the state of the heating system: if this parameter is equal to 0, the heating is off, and if it’s equal to 1, the heating is on.
In this case, to take into account the heating system influence on the consumption, you need to create a sensor with the Engine efficiency sensor type, specify in4 in the Parameter line, and add the following lines to the Calculation Table:

x = 0; a = 0; b = 1
x = 1; a = 0; b = 1.1

So, when the heating system is off, the engine efficiency sensor increases the consumption by 1 time (i.e., it doesn’t change it), and when the system is on, the consumption is increased by 1.1 times. Note that a zero value of the engine efficiency sensor would also not affect fuel consumption.

Using the method described above, you can take into account the influence of one factor on the expected consumption. If there are several engine efficiency sensors, all their values are taken into account simultaneously, forming the expected consumption rate on the interval between two messages (see the formula above).

How to make math consumption more accurate?

We should note that if you activate the Time-based calculation of thefts option in the fuel level sensor properties, the system will compare math consumption with the FLS consumption. Unfortunately, the readings of the latter are not very accurate. Hence, there is no need to try to make an ideal mathematical model since this may not affect the result of comparison with FLS in the end.

However, you can try to increase the model accuracy in the following ways.

Consider more factors

You can create more engine efficiency sensors based on parameters from the tracker that describe factors affecting consumption.

Note that numerous factors influence consumption, but the degree of their influence may vary. For example, there’s probably no need to install an air humidity sensor, although humidity can also affect consumption. It makes more sense to measure tire pressure, but on the other hand, it’s better to avoid using under-inflated tires. But don't expect the high accuracy of the mathematical model if you ignore the cargo weight, which can be measured using an axle load sensor. In other words, you should choose the factors to consider according to the degree of their influence on the result.

Increase the accuracy of parameter measurement

This recommendation follows from the previous one. To improve the result, you can not only increase the number of sensors but also use higher accuracy sensors.

Increase the frequency of messages

If the factors influencing consumption change frequently, the tracker must also generate messages frequently; otherwise, you won’t be able to take all factors into account. For example, this applies to trips around the city, when a car can stand at several traffic lights within 10 minutes. But if only one message is recorded in the tracker's memory during this time, the mathematical model simply cannot take into account each speed change.

Why does math consumption show incorrect values?

There may be several reasons for such behavior.

  1. The rates used in Math Consumption Wizard may differ from the actual ones (for example, due to the wear and tear of a vehicle). In this case, you can check their compliance with reality in practice.
  2. This may be due to the incorrect setting of math consumption. Check that a non-zero value is specified in the Consumption, l/h line in the engine operation sensor properties. Also, make sure that the engine operation sensor and the engine efficiency sensor are bound.
  3. The frequency of messages generated by the tracker may be too low.
  4. This may be due to a breakdown of the sensor, which readings are used in the mathematical model.
  5. In some cases, the system may think that the ignition was on all the time when the tracker didn’t send messages. In this case, the mathematical model will show that the engine should have been wasting fuel during all this time. To fix the situation, try to set the correct value of the Maximum interval between messages option on the Advanced tab in unit properties. You can achieve the same result using the Timeout option in the ignition sensor properties.


If you have any questions on specific practical cases, you should contact technical support via support@gurtam.com. Make sure to indicate in your email a brief description of the situation with screenshots, the exact unit name, the report template name for verification, the minimum time interval for verification (for example, not a month, but one day), and other essential details.


Oleg Zharkovsky,Wialon Trainer

Differences in Fuel Algorithms
  • technical_consulting
  • fuel

This page only highlights the key differences between fuel algorithms. I don’t intend to list all possible combinations of settings from the fuel level sensor properties, although they all affect data processing to a certain extent. To study each option, I recommend watching a webinar or testing it in practice. Notice that you can change settings without worrying about the initial data because changing the fuel options doesn’t change messages but only affects the displayed result.

Which algorithm to choose

Below is a list of algorithm features that should help you make a choice.

Mileage-based algorithm

  1. Suitable for most moving units.
  2. Relatively easy to set up.
  3. Used by default.

Time-based algorithm

  1. Suitable
    • for stationary units,
    • for units with long idling intervals,
    • for units with vehicle attachments, which increases fuel consumption,
    • if you suspect fuel thefts while driving,
    • if the mileage-based algorithm doesn’t produce expected results.
  2. More difficult to set up.
  3. For activation, it’s recommended to simultaneously enable the following options in the fuel level sensor properties:
    • Time-based calculation of fuel consumption
    • Time-based calculation of fillings
    • Time-based calculation of thefts – to process thefts, you also need a consumption mathematical model, which you can create, for example, using the Math Consumption Wizard.

What is the difference between algorithms?

First, we should note that, to some extent, a more correct name for the mileage-based algorithm would be a speed-based algorithm because it ignores messages in which speed is less than the Min moving speed set in the Trip detector. But since the mileage increases when moving, the current name is also appropriate.

It follows from the above that the key difference between algorithms is that the time-based algorithm analyzes all messages, while the mileage-based algorithm excludes some of the messages from the analysis, using simplification. It is based on the fact that you can assess the fuel level change during stops or parkings (i.e., on the low-speed interval) by two messages before and after a given stop or parking. For example, if a vehicle was in the parking lot from 14:00 to 16:00, and the fuel theft happened between 15:00-15:10, you can learn about the fact of theft simply by comparing fuel levels at 14:00 and 16:00.

Consumption

Both algorithms calculate consumption for an interval similarly: the fuel level value at the end of the interval is subtracted from the fuel level value at the beginning of the interval, and then the volume of fuel filling for this interval is added to them. However, the key difference between algorithms still implies that they take into account different intervals.

In addition, I’d like to note that the theft volume is included in the consumption by default until the Exclude thefts from fuel consumption option is activated in the report template settings.

Fuel fillings

Detecting fillings is also the same for both algorithms: the system searches for messages with a sequential increase in the fuel level sensor readings. However, the mileage-based algorithm calculates fuel fillings during stops by only two points (fuel level at the end of the previous movement interval and at the beginning of the next one), without analyzing all messages for the given interval.

Fuel thefts

Thefts are detected using different methods:

  • The mileage-based algorithm detects the theft during parking by two points (fuel level at the end of the previous movement interval and at the beginning of the next one), without analyzing all messages for the given interval.
  • The time-based algorithm compares the actual consumption according to the fuel level sensor with the expected consumption determined by the mathematical model.

If you have any questions on specific practical cases, you should contact technical support via support@gurtam.com. Make sure to indicate in your email a brief description of the situation with screenshots, the exact unit name, the report template name for verification, the minimum time interval for verification (for example, not a month, but one day), and other essential details.

Oleg Zharkovsky,Wialon Trainer

Fuel Filling is Not Detected
  • technical_consulting
  • fuel

Fuel fillings are displayed in reports when the data received from the tracker meets all the criteria for detecting fillings. However, in some cases, the Fuel Fillings table doesn’t display the results, although you know for sure that the fuel filling was performed, and the chart in the report shows a sharp increase in the Fuel level line. By following simple recommendations from this article, you can fix the situation and understand the logic of some fuel settings.

Possible causes and their elimination

Sometimes, it will be enough to follow only one recommendation from the list below to solve a problem. More often, you will have to follow several tips at once. But in some cases, you won’t be able to avoid detailed analysis of all fuel level sensor settings, as well as of the features of incoming messages and parameters.

At the same time, fixing the situation with the displaying of one filling often results in the emergence of other inconsistencies in fuel reports. That’s why there should be a comprehensive approach to the fuel data analysis, considering not one filling but several at a time.

1. Filling is ignored due to smoothing

Try to reduce the filtration level in the fuel level sensor settings.

 Explanation

The fuel level in the tank fluctuates due to engine operation, acceleration, braking, turning, road bumps, vehicle tilt, and so on.

The higher the filtration level, the stronger is the smoothing used to compensate for FLS readings fluctuations. The stronger the smoothing, the easier it is to analyze the processed data, but the more distorted the input information is. Thus, to obtain the needed accuracy, you should set the filtration level to the minimum required. If the filtration level is too high, the processed data may no longer contain the fuel level difference corresponding to the filling. In most cases, it’s not recommended to use a filtration level higher than 10.

Often, test fuel fillings are not displayed for this very reason: they are performed immediately after or before fuel draining, that’s why a short-term fuel level change is ignored due to smoothing. Actual fillings don’t imply the return of the fuel level to the previous state, so they will not be missed for the indicated reason.

2. Filling is filtered by volume

Try to reduce the value of the Minimum fuel filling volume option in the fuel level sensor settings.

 Explanation

This option acts as a kind of coarse filter separating fillings and normal fuel level fluctuations, which will remain even despite the use of filtration. Consequently, you should choose the Minimum fuel filling volume in proportion to the value of these fluctuations that in some cases can even reach 20 liters or more.

If you set a too high Minimum fuel filling volume, the actual filling may disappear from the report results.

3. Filling takes place in motion

Adjust the Trip Detector settings by increasing the Min moving speed ​​if the speed is not related to the actual trip of the unit but is related to the error in the initial data. However, if the speed in such messages is comparable to the speed of actual trips (for example, more than 10 km/h), you can probably delete such messages, and to avoid similar situations in the future, you can try to filter them out. Please keep in mind that you will not be able to recover messages deleted manually or as a result of message validity filtration, so pay special attention to these steps.

 Explanation

Speed determined by the tracker and displayed in the monitoring system doesn’t always clearly indicate that the unit is moving. This happens due to the inaccuracy of satellite navigation systems (GPS, GLONASS, and so on). To determine the fact of driving, the Min moving speed is used, which defines the minimum threshold of the speed value recognized by the system as a movement.

In rare cases, speed value inaccuracy reaches large values, which can be associated with both the tracker quality and the environment (terrain, being in a building, the presence of large metal structures nearby, and so on). Some trackers can independently mark messages with inaccurate speed as invalid. However, using Messages validity filtration, you can find and filter out such invalid messages already in Wialon. This filtration applies only to messages that arrive on the server after enabling the appropriate settings, that’s why you’ll have to delete previous invalid messages manually.

Another method for solving a problem is to enable the Detect fuel filling only while stopped option and increase Timeout to detect final filling volume in the fuel level sensor settings.

 Explanation

Fuel level sensors may be inert, i.e., send data with time delays. For some FLS, this is a consequence of built-in filtration; in other cases, the delayed data arrival points at the need of FLS maintenance (for example, cleaning the drain hole).

None of the variants work

You are probably faced with a more complicated situation than those discussed above, and you should contact technical support via support@gurtam.com. Make sure to indicate in your email the exact unit name, the report template name for verification, the minimum time interval for verification (for example, not a month, but several days), and other essential details.

Oleg Zharkovsky,Wialon Trainer

Fuel Theft is Not Detected
  • technical_consulting
  • fuel

Fuel thefts are displayed in reports when the data received from the tracker meets all the theft detecting criteria. However, in some cases, the Fuel Thefts table doesn’t show the results, although you know for sure that fuel was stolen and can see a sharp drop in the Fuel level chart in the report. By following simple recommendations from this article, you can fix the situation and understand the logic of some fuel settings.

Possible causes and their elimination

Sometimes it will be enough to follow only one tip from the list below. More often, you will have to follow several recommendations at once. But in some cases, you won’t be able to avoid detailed analysis of all fuel level sensor settings, as well as of the features of incoming messages and parameters.

At the same time, fixing the situation with the displaying of one theft often results in the emergence of other inconsistencies in fuel reports. Thus, there should be a comprehensive approach to the fuel data analysis, considering not one theft but several at a time.

1. Theft is ignored due to smoothing

Try to reduce the filtration level in the fuel level sensor settings.

 Explanation

The fuel level in the tank fluctuates due to engine operation, acceleration, braking, turning, road bumps, vehicle tilt, and so on.

The higher the filtration level, the stronger is the smoothing used to compensate for FLS readings fluctuations. The stronger the smoothing, the easier it is to analyze the processed data, but the more distorted is the input information. Thus, to obtain the needed accuracy, you should set the filtration level to the minimum required. If the filtration level is too high, the processed data may no longer contain the fuel level difference corresponding to the theft. In most cases, it’s not recommended to use a filtration level higher than 10.

Often, test fuel drains are not displayed for this very reason: they are performed immediately after or before the filling, that’s why a short-term fuel level change is ignored due to smoothing. Actual thefts don’t assume the return of the fuel level to the previous state, so they will not be missed for the indicated reason.

2. Theft is filtered by volume

Try to reduce the value of the Minimum fuel theft volume option in the fuel level sensor settings.

 Explanation

The 1% FLS accuracy declared by some manufacturers often doesn’t allow detecting small thefts in real conditions due to the fuel fluctuations in the tank mentioned above. That’s why it would be quite optimistic to set, for example, a 1-liter Minimum fuel theft volume right away. This option acts as a kind of coarse filter separating theft and normal fuel level fluctuations, which will remain even despite the use of filtration. Consequently, you should choose the Minimum fuel theft volume in proportion to the value of these fluctuations that in some cases can even reach 20 liters or more.

If you set a too high Minimum fuel theft volume, the actual theft may disappear from the report results.

3. Theft takes place during short stops

Try to reduce the Minimum stay timeout option to detect fuel theft in the fuel level sensor settings.

 Explanation

During a short stop, the fuel level can change significantly, therefore the analysis of short stops will result in detecting false thefts. Using the Minimum stay timeout to detect fuel theft option, you can configure the system to monitor thefts only during long stops and idle time.

If you set a too long Minimum stay timeout to detect fuel theft, then a long stop or idle time can be excluded from the analysis, and theft will not be registered.

4. Theft takes place in motion

Activate the Detect fuel theft in motion option in the fuel level sensor settings if the unit was actually moving at the moment of theft. Please note that in this case, in order to display the correct result, it’s recommended to enable the Time-based calculation of thefts.

Another method is to increase the minimum moving speed on the Trip Detector tab if the speed is not related to the actual trip of the unit but is related to the error in the initial data. However, if the speed in such messages is comparable to the speed of actual trips (for example, more than 10 km/h), you can probably delete such messages, and to avoid similar situations in the future, you can try to filter them out. Please keep in mind that you will not be able to recover messages deleted manually or as a result of message validity filtration, so pay special attention to these steps.

 Explanation

Speed determined by the tracker and displayed in the monitoring system doesn’t always clearly indicate that the unit is moving. This happens due to the inaccuracy of satellite navigation systems (GPS, GLONASS, and so on). To determine the fact of driving, the Min moving speed is used, which defines the minimum threshold of the speed value recognized by the system as a movement.

In rare cases, speed value inaccuracy reaches large values, which can be associated with both the tracker quality and the environment (terrain, being in a building, the presence of large metal structures nearby, and so on). Some trackers can independently mark messages with inaccurate speed as invalid. However, using Messages validity filtration, you can find and filter out such invalid messages already in Wialon. This filtration applies only to messages that arrive on the server after enabling the appropriate settings, that’s why you’ll have to delete previous invalid messages manually.

None of the variants work

You are probably faced with a more complicated situation than those discussed above, and you should contact technical support via support@gurtam.com. Make sure to indicate in your email the exact unit name, the report template name for verification, the minimum time interval for verification (for example, not a month, but several days), and other essential details.

Oleg Zharkovsky,Wialon Trainer

How to Get Rid of False Fuel Thefts
  • technical_consulting
  • fuel

If data received from the tracker meets all the theft detecting criteria, the Fuel Thefts table will contain records about it, even if there was no actual theft. Such fuel thefts are called false.

To correctly configure fuel theft detection, you need to know not only the technical features of Wialon algorithms but also the operating principles of hardware (trackers, sensors, and the unit's fuel system). This article provides simple instructions, following which you can eliminate false fuel thefts by focusing on the fuel level chart only.

Required steps before applying instructions

  • A unit is created in Wialon, data messages from the tracker are displayed in the system.
  • The fuel level sensor is connected to the tracker, the fuel tank is calibrated.
  • A sensor with the Fuel level sensor (FLS) type is created in the unit.
  • The Calculate fuel consumption by sensor option is activated in the FLS settings.
  • The calibration table (XY pairs) is added to the fuel level sensor Calculation table, whereafter the Generate button is clicked.
  • A report template with a Regular type chart is created, which displays the Processed fuel level.
  • The chart also displays fuel theft markers and the background of trips (it's pink by default), stops (blue), and engine hours (yellow).

Chart behavior in the location of false fuel theft

Choose one of the options below according to what you see on the chart where the fuel theft marker is located.

1. Jumps during motion or engine operation

During engine operation, driving on uneven surfaces or basically any movement, fuel fluctuations occur, and the FLS reads them. Depending on the tank volume and shape, as well as the FLS location, these fluctuations can reach dozens of liters, which can result in detected fuel thefts. In general, you can compensate them with the help of a smoothing algorithm adjustable via the filtration level.

To do this, activate the Filter fuel level sensors values option in the fuel level sensor settings. Then, set the filtration level (e.g., 3). Keep in mind that high filtration levels should be used only with a high frequency of message sending (1-5 seconds between messages). After applying the filtration, fuel algorithms will work not with the raw data but with smoothed data.

To check if smoothing is effective, add the Fuel level line (before smoothing) to the chart and compare it with the Processed fuel level line (after smoothing). If the Processed fuel level line fluctuations still seem significant to you, try to increase the filtration level (an increment of 1 is recommended). But don't forget that smoothing may distort the input data, that's why you have to find the middle ground: Processed fuel level line fluctuations no longer seem significant (or they are eliminated), but at the same time, the lines before and after smoothing are still not much different in distinctive points (for example, during actual fillings/fuel thefts).

 How filtration works (smoothing of sensor values)

Wialon uses median filtering. For each message, several messages before and after it are taken; altogether, they form a filter window, and then, taking these messages into account, a smoothed value in the center of the window is calculated.

Filtration levelWindow widthNumber of messages before/after the window center
031


N

N — odd5×N(5×N-1)/2
N — even5×N+15×N/2

Example

The filtration level is set to 3. The window width will be 5×3 = 15. Consequently, 7 messages are taken before the message concerned and 7 messages after to smooth the fuel level values.

For example, messages 54 through 68 will be used to calculate the value in message 61.

2. A sharp jump immediately after the start or stop of motion

FLS readings can change abruptly at the moment of motion start/stop, which can result in fuel theft detection. If the chosen filtration level doesn't smooth out these jumps, and you don't want to increase it (for example, in your case, this causes significant distortion of input data at other intervals), then you can use one of the two time filters in the fuel level sensor settings:

  • Ignore messages after the start of motion — this option allows you to exclude a specified number of seconds after starting the movement from the fuel theft analysis.
  • Minimum stay timeout to detect fuel theft — if the duration of the interval without movement doesn't exceed the specified one, then this interval won't be analyzed for fuel thefts (thus, you can cut off fuel level fluctuations, for example, during short stops at traffic lights).

3. Smooth falling with the running engine and no movement

There are two algorithms for fuel analysis in Wialon: the mileage-based algorithm (used by default) and the time-based algorithm. For stationary units and units with long idle intervals, it's recommended to use the time-based algorithm. To do this, activate three options in the fuel level sensor settings: Time-based calculation of fillings, Time-based calculation of thefts, and Time-based calculation of fuel consumption. We should clarify that in this very case, it would be possible to do only with the Time-based calculation of thefts option, but the simultaneous activation of all options will allow you to achieve better convergence of all fuel indicators in the reports.

When using the time-based algorithm, the FLS fuel consumption value is compared with the calculated fuel consumption value, i.e., with the value calculated by the mathematical model. At idle intervals, the calculated fuel consumption value is generally determined by the engine ignition sensor or engine hours counters. Therefore, open the ignition or engine hours sensor properties and check if the correct consumption rate per hour is set in the Consumption field.

4. Fuel theft during driving, although the chart looks normal

Most likely, you are using the time-based fuel analysis algorithm, and you've also activated the Detect fuel theft in motion option in the fuel level sensor settings. In this case, the FLS fuel consumption value is compared with the mathematically calculated consumption. If the consumption by calculation is set incorrectly, a false fuel theft can be detected when the unit is just making a trip; therefore, it's recommended to check the mathematical model of the calculated consumption. It's set via:

  • engine ignition sensors or engine hours counters — in the properties in the Consumption field specify the consumption rate per hour at idle;
  • engine efficiency sensors — this sensor can use any parameter that affects fuel consumption and based on its value, it determines the fuel consumption change coefficient, which is then multiplied with the consumption value from the previous point.

A basic mathematical consumption model can be created using the Math consumption wizard on the Sensors tab in the unit properties. Further, you can complement it, taking into account other factors affecting the consumption (cargo weight, temperature, operation of vehicle attachments, and so on).

5. Significant jumps to the minimum/maximum

If the chart shows jumps of the Processed fuel level line to 0 or to the maximum value (often 2¹⁶-1 = 65535) and back to the actual value, then even after applying the smoothing, these jumps can cause the detection of false thefts. Such jumps in readings can be connected with the wrong configuration or the connection of the fuel level sensor itself.

It's recommended to fix this problem on the hardware side; however, on the Wialon side, you can try to cut off these readings using the Calculation table. To do this, go to the FLS settings, go to the Calculation table tab, and set the values of the Lower bound and/or the Upper bound corresponding to an empty and full tank. In the lower bound, however, it's better to set not 0 but a value close to zero (for example, 0.1) to cut off false jumps in readings to 0.

6. Significant jumps not to the minimum/maximum

If the FLS readings change by significant values (but not to 0 or the maximum value) and then return to the actual value, even after applying the smoothing, these jumps can cause the detection of false thefts. Such behavior can be connected with voltage surges, which can be seen on the chart using the Voltage line if you have a Voltage sensor.

It's recommended to fix such situations on the hardware side; however, on the Wialon side, you can try to neutralize the impact via Validation. To do this, follow the instructions:

  1. Open the Messages tab and request raw data messages for the interval that includes the considered fuel level jump.
  2. Manually or using a filter, find another parameter that changes simultaneously with the FLS readings.
    Suppose this is the pwr_ext parameter, which for most trackers corresponds to the external voltage.
  3. Determine, upon passing which value of the found parameter, the FLS readings change.
    Suppose that if pwr_ext is less than 12, then the FLS starts sending incorrect readings.
  4. Enter the unit properties and create a sensor with the Custom digital sensor type using the parameter from point 3, and then define a Calculation table for it with the following lines:
    X = 0; a = 0; b = 0
    X = 12; a = 0; b = 1
  5. Save the created sensor and the changes of unit properties by clicking OK twice.
  6. Enter the unit properties again, and then the FLS properties. Specify the sensor from point 4 as a validator with the Not-null check type.

In the example above, a real case is considered since low voltage actually often leads to the distortion of readings of different sensors. This means there is a direct connection between the transmitted parameters of voltage and fuel level. However, you can also use a correlation if you notice a simultaneous change in the FLS readings and any other parameter. Perhaps the tracker doesn't send a voltage value, but it does send a temperature value, and the temperature sensor also fails and sends, for example, 451 °F at the moment of a power surge. In this case, using validation, try to connect the FLS and the temperature value, which should also correct the situation.

7. Smooth falling after filling when there are several interconnected tanks with an FLS in each

Such a change in the FLS readings may be because the unit has several interconnected tanks and fuel flows between them. After filling one of the tanks, the equalization of levels between several tanks may take some time. If you created fuel level sensors in Wialon separately, the system can detect false theft in one of the tanks immediately after filling.

When working with several interconnected tanks, we recommend you to create a Custom sensor for each FLS (for example, named “FLS 1” and “FLS 2”) and add your calibration table into them. After that, create a separate sensor with the Fuel level sensor type, don't add the calibration table into it, but instead just use the following formula: [FLS 1]+[FLS 2]

8. Sharp falling when reaching a certain level

This situation can be observed for tanks of a specific shape at the moment of transition from a wide part to a narrow one (for example, L-shaped tanks). This is particularly likely if the calibration was performed using too few points, and often it's done using only two points (for an empty and full tank). Therefore, it makes sense to re-calibrate the tank using small portions.

9. Smooth change at the same time

Sometimes the fuel level drops/rises at specific points in time, and in some cases, later even returns to the actual value. This can happen at night, or during a trip (especially when loaded), or after approximately equal time after the end of the trip — it's difficult to identify a common rule.

Possible reasons:

  • temperature change, affecting the fuel volume and the tank deformation (this is especially true for flexible plastic tanks);
  • a "vacuum" created due to the pressure difference (active intake of fuel into the engine);
  • sedimentation of impurities in the fuel or dirt in the tank, happening after the end of the trip (shaking).

The solution in most cases is related to the hardware: using a fuel tank cap with a valve to equalize pressure, dirt/sediment removal in the tank or on the FLS. However, if the situation is related only to temperature changes, then using a sensor with the Temperature coefficient type can help you (you can find an example of its setting in the documentation).

None of the variants work

This article discusses only false fuel thefts, so if you couldn't get rid of thefts using the suggested instructions, this may mean one of three variants:

  1. The FLS accuracy is insufficient for a given tank shape, type of vehicle, mode of motion, terrain, etc. The only thing that can help is increasing the Minimum fuel theft volume value in the fuel level sensor settings. In fact, this is not a problem solution, but simply the recognition of the FLS low accuracy and the unit adjustment according to this accuracy.
  2. You are faced with a more complicated situation than those discussed above, and you should contact technical support via support@gurtam.com. Make sure to indicate in your email a brief description of the situation with screenshots, the exact unit name, the report template name for verification, the minimum time interval for verification (for example, not a month, but one day) and other essential details.
  3. Probably, the fuel theft actually took place.

Oleg Zharkovsky,Wialon Trainer

Command Does Not Work
  • technical_consulting
  • commands
  • sms

Wialon not only receives data from trackers, but can also send commands to them. In this article, you will find conditions for executing commands, the description of peculiar properties of different channels for sending commands, as well as possible issues and their solutions.

Conditions for executing commands

To execute commands, you should consider several conditions at once related to the service, account, user, and unit. Let's look at these conditions one by one.

  1. The Commands service is enabled in the account.



  2. The user has the Send commands special right regarding the unit.



  3. The command is created in the same-name Commands tab in the unit properties.


    To create commands, the user must have the Create, edit, and delete commands special right regarding the unit.

  4. There are several additional conditions for executing commands over the SMS channel:
    • The SMS messages service is enabled in the account.

    • SMS must be available in the service, i.e., the counter on the top panel must be greater than zero.

      This counter is not displayed if the service uses a personal modem for sending SMS.

    • In the General tab in the unit properties, you must specify the Phone number in international format, to which the tracker will receive SMS.

Peculiarities of channels for sending commands

The channel (connection type) for sending the command is selected in its properties. Depending on the selected channel, you should consider the unit with the server connection state when executing the command.

The unit keeps an Internet connection with the server if messages with data or keep alive/heart beat packets come from it. To check the current connection status, you can use the Connection state column on the Monitoring panel.

Channel

Peculiarities

GPRS (TCP/UDP)

The unit must keep an Internet connection with the server.

Virtual

This channel is similar to TCP/UDP judging by the principle of sending, but the virtual command can be executed even when the unit is not connected to the server. At the moment of execution, the command is queued, and its actual sending will be done at the moment the unit goes online.

For each type of device, Wialon imposes a limit on the number of virtual commands in the queue, and when the queue is full, a new virtual command will push the oldest command out of the queue (it will not be sent).
SMSThe unit may not keep an Internet connection with the server.
AutoWhen sending, the program will choose the channel that is currently available. If more than one type is available, the channel that is higher in this table will be used.
If the communication channel selected for commands is currently available, the button for command execution opposite the unit on the Monitoring panel will become active.

Checking the command sending on the Wialon side

The fact of command execution is recorded in the unit Log. This information is also available for viewing:

  • in the Messages tab when requesting Sent commands;
  • in the Messages tab when requesting SMS messages;
  • in the report with the Sent commands table.

An entry about command execution in the log means that the command was executed on the Wialon side. Then it is sent over a TCP/UDP channel or transferred to the modem/SMPP gateway for sending.

If the command was not executed when pressing the corresponding button, you should check the compliance with the above-mentioned requirements. If all the requirements were met and the unit did not lose connection at the moment of command execution, you can send a detailed description of the problem (username, unit, command name and execution time) to support@gurtam.com for analysis by Wialon technical support specialists.

Possible issues and their solutions

If according to the Wialon log the command is executed, but there is no response from the tracker, the issue is most likely related to the operation of third-party systems. It’s possible that the tracker did not receive the command, the tracker did not perform the programmed actions on the command, or it did not send a response/file to the command to Wialon. The most common issues of this kind and possible actions to solve them are listed below.

IssuePossible causesOptions for action
SMS command is not delivered to the unit

Problems with the delivery of SMS messages and TCP/UDP commands are usually associated with problems at the level of telecom operator/Internet provider networks. Together with your provider, you should check the message delivery route, troubleshoot the network, or search for other delivery routes.

If you use the 500 SMS package, write to Wialon technical support at support@gurtam.com.
If you use your own SMPP gateway or modem, please contact your SMPP provider or GSM operator to analyze the situation.

The command is delivered but with incorrect text

Typically, this problem is related to the telecom operator encoding and is relevant mainly for SMS messages. Wialon uses the standard A5 (CCITT T.50)/ASCII (ANSI X3.4) encoding. The recipient's operator may use a different protocol and, as a result, decode the message incorrectly.

The user should contact the recipient's operator to correct the situation.

An alternative is to use your own SMPP gateway with the required encoding.
The command is delivered with the correct text, but the tracker did not execute/rejected the command

An incorrect command format is specified in SMS. You should double-check the syntax according to the device manual or contact the hardware manufacturer.

If standard Wialon commands are used (except Custom message), make sure that the correct parameters are specified in the command (for example, the number of the tracker input for activation). You can also contact Wialon technical support at support@gurtam.com, providing the detailed problem description.

An SMS command is received from a sender's number that is not added to the allowed list.

Add the allowed number in the tracker settings.

The command is received from an IP not allowed to the tracker.

Add the allowed IP in the tracker settings. IP in Wialon Hosting depends on the service data center, and you can see it in the General tab in the properties of any unit.

The Password for executing commands is not entered in the unit settings (or it does not match the password in the tracker).

Double-check the password for executing commands. It is recommended to use the Latin alphabet for the password, because the tracker may decode other languages incorrectly.

The tracker is defective.

A hardware or software failure at the tracker level should be analyzed with the engineer maintaining this tracker.

The command is delivered, executed by the tracker, but the Wialon system receives no response

For some types of devices, there is an additional hardware protocol setting, where you should activate the corresponding flag or configure settings for receiving and displaying messages from the tracker.

When configuring the device, find and activate the corresponding option in the General tab. The configuration button is located to the right of the device type entry field and is active if the device itself provides the configuration option.

The command came from a virtual number that cannot act as an SMS recipient.

Wialon Hosting uses a virtual number 79037676122. You can contact Wialon technical support at support@gurtam.com and clarify whether it’s possible to switch your service to another available sender phone number in order to receive SMS responses from trackers to this number.
If, due to the peculiarities of SMS delivery routes to a certain country, you cannot set a different sender’s number for sending SMS, the most convenient solution would be to connect your own SMPP gateway for your Hosting service with the ability to receive SMS from trackers. To connect your SMPP gateway to the Hosting service, contact your manager (or Wialon technical support for technical advice).


Sergey Novikov,Technical Consulting Engineer

How to Choose a Parameter for a Sensor
  • technical_consulting
  • sensor_parameters
  • sensor_types

If you know the device type, its configuration, and how it was installed, you may know which parameter to choose for the sensor in Wialon. But if you have just started working with Wialon and have doubts, this article can help you select a parameter based on how other users usually do it.

General recommendations

  1. You can find the list of parameters and their description on the page of a specific device on gurtam.com in the Hardware section. To do this, enter the desired device model in the Search hardware line. You can also select one of the categories of hardware types and find the desired model on the list. Then, on the hardware page, go to the Parameters tab (an example of such a page for WiaTag).

    If there is no parameter description on the hardware page, please contact hardware specialists via hw@gurtam.com.
  2. In most cases, you can understand the value of a parameter by its English name. For example, the fuel_lvl parameter will most likely display the fuel level value, the total_mileage parameter — mileage sensor values, and so on. Parameter names received from CAN bus usually begin with the prefix can.

  3. Parameters sent by the device can be described in the hardware documentation. As a rule, documentation is available on the manufacturer's website.

  4. There is a list of virtual parameters defined in the system by default and suitable for almost any type of hardware:
    • speed — speed of movement;
    • altitude — height above sea level;
    • sats — number of satellites;
    • course — direction of movement;
    • lat — latitude;
    • lon — longitude;
    • time — UNIX time of the message;
    • regtime — time of the message registration on the server.

The method for searching and checking the selected parameter depends on the type of sensor in which it is used. Below, we’ll cover a few examples for the most commonly used types of sensors.

Engine ignition sensor

Engine ignition sensor is a digital sensor that indicates whether the engine is running or not. When the value of a digital sensor is zero, it is considered off, and when the value is non-zero, the sensor is considered on.

Engine ignition sensor does not indicate the ACC position of the ignition key, in which the engine is not running, but additional hardware is already available for use.

One of the digital inputs can be used as a parameter for the Engine ignition sensor (the I/O format parameter at the end of messages). It describes the state of all digital inputs and outputs simultaneously, and you can use it to determine the state of a particular digital input inN (the logic for selecting the input number N is described in another article).

You can also try to create an engine ignition sensor based on the external voltage parameter (usually named pwr_ext). In this case, you need to create the Calculation table in the sensor properties. The user guide provides an example of such a table. When using this example, you only need to change the voltage threshold at which the ignition will be considered on.

Practical method for selecting and checking a parameter

  1. Turn off the engine and wait for a few messages from the tracker.
  2. Start the engine and wait for a few more messages.
  3. Compare the messages received in points 1 and 2. If there was an abrupt change of only one parameter, it is most likely that it will indicate the ignition status. If several parameters changed, you can select the desired one using the additional check described in the following point.
  4. Examine the messages with non-zero speed. It is assumed that the ignition is on when there is speed, as well as in several messages before and after the speed exists. At the same time, it is recommended to consider intervals with a duration of at least five minutes, since some trackers can change the mode of sending messages after the start and the end of the movement.
 Example

Messages with the following parameters are received from the unit:


Speedparam1param2param3
15526.00301000
25626.00401020
35726.00511015
4026.00611004
5026.0071476
6026.0080489
71026.00901001
81126.01011004

Let's assume that the unit ignition was off in the 5th and 6th messages (highlighted in red). In other messages, the ignition is on (highlighted in green).

param1 — the value was constantly increasing at all intervals, there are no abrupt changes, there is no connection with the speed or its absence. Hence, this parameter can’t be used for the ignition sensor.

param2 — changed at all three intervals, took on a zero value when there was speed in the messages, although the ignition should have been turned on at that moment. Hence, this parameter can’t be used for the ignition sensor.

param3 — at intervals when the ignition is supposed to be on, the parameter takes on a value of more than 1000, and at intervals when the ignition is off, the value abruptly drops to a level of less than 500. Hence, you can try to use this parameter in the ignition sensor by applying the calculation table.

Mileage sensors

Currently, Wialon has two sensors for tracking mileage:

  • Mileage sensor shows the entire mileage of the unit since the sensor was installed.
  • Relative odometer shows the mileage between the current and previous messages.

If the device sends parameters for both mentioned types of sensors at once, the odometer readings do not have to completely coincide with the difference that you get by subtracting the mileage sensor readings in two adjacent messages. This is due to the fact that the calculation algorithm for sensors may differ on the device side. In that case, it is advised to choose the sensor that shows more reliable results.

Both mileage sensors use kilometers (or miles) as measuring units. If the incoming parameter has other measuring units, you should apply a coefficient for converting to kilometers (or miles). For example, if the can_odo parameter displays the value in meters, then in the Parameter line in the sensor parameters, you will need to write the following formula to convert to kilometers: can_odo/const1000

Practical method for selecting and checking a parameter

You can use the Distance tool to check whether the parameter for Mileage sensor or Relative odometer is selected correctly. The parameter values and the distance measured between two messages most often do not completely coincide, but are comparable. This is due to the fact that the Distance tool mathematically calculates the distance between two points with the selected coordinates, and sensors usually calculate kilometers traveled based on the number of wheel rotations and its diameter.

You can use the parameter in the Mileage sensor if

  • its value does not change when the unit stands;
  • its value increases when the unit is moving;
  • the difference of its values in two adjacent messages is comparable with the value obtained by using the Distance tool.

You can use the parameter in the Relative odometer if

  • it is zero when the unit stands;
  • it has a positive value when the unit is moving;
  • it has approximately equal values when the unit is moving at the same speed;
  • its value is comparable with the value obtained by using the Distance tool.
 Example

Messages with the following parameters are received from the unit:

Create a Mileage sensor based on the mileage parameter, as it constantly increases while moving and does not drop to zero during a stop.

Create a Relative odometer based on the odo parameter, as it has different values while moving and drops to zero during a stop. However, its value seems too high, so try using the odo/const1000 formula.

Measure the unit mileage between several pairs of messages using the Distance tool by placing the measured segments on top of the track.

Compare the obtained results:

Mileage sensorDifference with the previous by the mileage sensorRelative odometerThe Distance tool
16801.54 km1.00 km
26802.52 km6802.52 - 6801.54 = 0.98 km1.00 km1.000 km
36803.51 km6803.51 - 6802.52 = 0.99 km1.00 km1.020 km
46804.00 km6804.00 - 6803.51 = 0.49 km0.50 km0.500 km
56804.20 km6804.20 - 6804.00 = 0.20 km0.50 km0.160 km
66804.20 km6804.20 - 6804.20 = 0.00 km0.00 km-

The values are approximately equal, therefore, we can assume that the parameters for both sensors are selected correctly.
Please note that different sensors may have different accuracy. In this case, in the Mileage counter and Trip Detector, it’s recommended to use the sensor that sends readings closest to the expected ones.

Fuel sensors

Currently, Wialon has several types of fuel sensors:

  • Absolute fuel consumption sensor (AbsFCS) shows the fuel consumption for the entire period of unit operation. Therefore, to obtain data on the fuel consumption for a specific period, you should use the following algorithm: calculate the difference in sensor readings at the end and the beginning of the considered interval.
  • Instant fuel consumption sensor (InsFCS) shows the amount of consumed fuel since the previous measurement (message). Therefore, to obtain data on the fuel consumption for a specific period, you should use the following algorithm: calculate the sum of the sensor readings in all messages in the considered interval.
  • Impulse fuel consumption sensor (ImpFCS) — the operating principle of this sensor is similar to Instant fuel consumption sensor.
  • Fuel level sensor (FLS) is designed to calculate the amount of fuel in the tank. You can use it to calculate fuel consumption, as well as control fuel thefts and fillings.
  • Fuel level impulse sensor (ImpFLS), like the previous sensor, is designed to calculate the amount of fuel in the tank. You can use it to calculate fuel consumption, as well as control fuel thefts and fillings. The difference from FLS is that the data from the previous message is used in the calculation, and the difference in the impulse values of two adjacent messages is divided by the time difference between them. This type of sensor is almost never used in practice – instead, most users prefer a traditional FLS.

If the device sends parameters for several of the mentioned types of sensors at once, their readings, as well as the calculation results for them, may differ. This is due to the difference in measuring methods, and the peculiarities of working with fuel. In that case, it is advised to choose the sensor that shows more reliable results.

Fuel information can be contained in parameters with the following names: fuel_lvl, fuel_used, cons_total, can_fuel, rs485_lls, adc1, adc2, etc.

You should select the sensor type based on how the parameter value changes. Let’s consider the different behavior of parameters below.

AbsFCS

You can use the parameter in the Absolute fuel consumption sensor if

  • its value does not change when the engine is off;
  • its value increases when the engine is running;
  • its value increases faster when driving or operating under a load than when stopped or with no load.

InsFCS and ImpFCS

You can use the parameter in the Instant fuel consumption sensor or Impulse fuel consumption sensor if

  • it is zero when the engine is off;
  • it has a positive value when the engine is running;
  • it has approximately equal values when the unit is moving at the same speed or operating under the same load.

FLS

You can use the parameter in the Fuel level sensor if

  • its value does not change when the engine is off;
  • its value gradually decreases when the engine is running;
  • its value decreases faster when driving or operating under a load than when stopped or with no load;
  • its value fluctuates around the actual value during engine operation and movement;
  • its value increases sharply during fuel filling.

In contrast to fuel consumption sensors, the parameter from FLS may behave not the way described above, because fuel theft may happen during a stop or movement, the unit may move at an angle, the temperature may change significantly during the day, fuel may contain impurities, etc. Find more information about fuel control issues and their solutions in the MiscellaneousFuel section.

Below is an example of the FLS parameter changing chart, which covers the trip and filling intervals.

In some cases, the FLS parameter behaves in the opposite way: when the engine is running, its value increases, and when filling, it decreases. This difference will be neutralized after the tank is calibrated and its results are entered into the Calculation table.

Ekaterina Grib,Technical Consulting Engineer

How to Choose the Number of Digital Input/Output (I/O)
  • technical_consulting
  • sensor_parameters

Digital input and digital output are electrical contacts (connector pins) that are energized by the voltage of only two levels: one of them corresponds to the on-state (1, or On), and the other one — to the off-state (0, or Off). Hence, digital inputs and outputs are used to connect tracker and devices or circuits that transmit only two possible states. For example, you can connect a door status sensor to the tracker's digital input so that the tracker can determine whether the door is open or not. And you can connect an anti-theft device to the tracker's digital output that will be controlled by the tracker and block the ignition.

I should note that if the client requires an exact numerical value, an analog connector is needed. Because if you, for example, use a digital input for FLS, you can only find out whether there is fuel in the tank or not.

The number of digital inputs and outputs on the tracker may be quite large (for example, Galileosky 7x may have from 6 to 10 digital inputs, depending on modification and configuration). Therefore, users often wonder to which digital input or output the installer connected the device a client is interested in. Follow the instructions below to get the answer.

Displaying digital inputs/outputs

At first, it should be noted that the state of digital inputs and outputs in Wialon is represented as two hexadecimal numbers (HEX) obtained from binary numbers (BIN), in which each bit corresponds to an input/output with the same number. The parameter with these values is named I/O (short for Inputs/Outputs) and contains two numbers separated by a slash: to the left, there is the value corresponding to the state of all inputs, and to the right — the state of the outputs.

Why was this implementation chosen? Let's look at an example.

Suppose that some vehicle attachments are connected to digital inputs 1, 3, 4 and 7 and outputs 1, 3, 6 and 8. Also, suppose that all the mentioned inputs and outputs are activated in the considered message. If separate parameters were used for each of them in the message, you would see the following:

in1=1, in2=0, in3=1, in4=1, in5=0, in6=0, in7=1, in8=0, out1=1, out2=0, out3=1, out4=0, out5=0, out6=1, out7=0, out8=1

In the current implementation in Wialon, you will see the following entry:

I/O=4D/A5

The obvious conciseness of the entry is a key advantage.

Defining the number of an activated digital input/output

If the number N of an input or output is known, the corresponding parameter will be inN, and the output parameter will be outN. For example, the fourth input is in4 and the output — out4.

However, if you don't know the number of an input or output to which the hardware is connected, you can use one of two methods: selection or a mathematical approach.

Selection

When connecting hardware, installers most often use the first inputs/outputs. So, if we talk about a device or circuit that transmits information to the tracker, you should check in1-in4, and if it's about a device or circuit that the tracker controls — out1-out4.

To find the needed input, you can create 4 sensors with the Custom digital sensor type based on these parameters (for example, the first sensor will have in1 in the Parameter field, the second — in2, and so on). Then go to the Messages panel, select the Data Messages type, and specify Sensor values ​​in the menu below. After that, query messages for the interval when the hardware was first turned off and then turned on to find the moment of transition from Off to On in one of the columns, each of which corresponds to the created sensor.

This is the fastest practical way to find the needed input (similarly, you can work with outputs, but in this case, you should use the parameters out1, out2, and so on). If it doesn't work, you can use a mathematical approach.

Mathematical approach

If you don't know the number of an input/output to which the hardware is connected, you can use the following instructions:

  1. Go to the Messages panel, select the Data Messages type, and specify Initial data in the menu below.
  2. Query messages for the interval when the hardware was first turned off and then turned on.
  3. After displaying the table with messages from the tracker, pay attention to the Parameters column and find the I/O parameter there (it's located at the very end of the line).

    Suppose that the message where the hardware was turned off has the I/O=102/0 parameter, meaning that digital outputs are deactivated (or not even connected), and some digital inputs are activated.

  4. Open the Calculator application (it is preinstalled on every computer, or you can find its analogs on the internet) and switch it to the Programming mode (or a similar one that allows you to convert values from one numeral system to another).
  5. Switch the calculator to a hexadecimal numeral system (HEX).
  6. Enter the value 102 found earlier.
  7. The application will automatically (or by pressing the enter key) show you the given number in different numeral systems. We need the binary format entry (BIN), which consists only of zeros and ones.



  8. Examine the resulting binary number. Note that the bit number is counted from right to left (as in the decimal system, where ones are to the right, tens are to the left of them, then hundreds, thousands, and so on): 0001 0000 0010
  9. Determine the bit numbers for a given number (bit numbering in Wialon starts from 1):

    Number121110987654321
    Value000100000010
  10. From this entry, we can conclude that in this message, inputs 2 and 9 are activated (i.e., in2=1, in9=1), and all other inputs are deactivated (i.e., their value is zero).
  11. Now find the message where the hardware was turned on. Suppose it contains the I/O=10A/0 parameter.
  12. Repeat steps 4-8 for the 10A value.



  13. Determine the bit numbers for a given number:

    Number121110987654321
    Value000100001010
  14. In this message, inputs 2, 4 and 9 are activated (i.e., in2=1, in4=1 and in9=1).
  15. Compare the results of steps 10 and 14. As you can see, they differ only in the state of the in4 parameter, which means the hardware in the given example was connected to input 4.

Using digital inputs/outputs

You can use the digital input or output parameter the same way as any other parameter.

When creating sensors for digital inputs/outputs, types from the Digital group are most suitable since they imply only two states (On and Off).

A unique use case, which is only available for digital inputs, is a notification with the Digital input type, for which you don't even need to create a sensor.

Oleg Zharkovsky,Wialon Trainer

Incorrect Mileage
  • technical_consulting
  • trips

Incorrect mileage can affect the calculation of average speed, average fuel consumption per kilometer, service intervals and, of course, the indicator of the distance traveled. Therefore, it is crucial to track and fix problems that arise both on the hardware and software side.

If you’re faced with the problem of incorrect mileage detection in a report, on a track, or in messages, the first thing you should do is to check what type of mileage counter is selected on the General tab in the unit properties:

  • GPS
  • GPS + ignition sensor
  • Mileage sensor
  • Relative odometer

After finding out which counter is used in your unit, choose the appropriate section of the article.

1. GPS

When using this type of counter, the mileage correctness can be affected by the unstable communication with satellites, data transmission failures, as well as the use of additional sensors. Let's consider these options in more detail.

a. Outliers of coordinates and incorrect message chronology

Outliers of coordinates may appear due to poor communication with satellites of the Global Navigation Satellite System (GNSS). To determine that outliers occurred, go to the Messages tab and upload data for the required unit for the problematic time interval. On the map, you will see a track that can be used to determine the fact of outliers: coordinates of messages are significantly spaced from the actual unit location.


In this example, a clear indication of problems with determining the unit location is the HDOP parameter – it has values >1.

Wialon has a limitation: no more than 1 message should come from a unit per 1 second. If the terminal transmits more than 1 message per 1 second, the chronology of messages may be disrupted and the track will look the same. The reason is incorrect arrangement of messages with positional data (coordinates) in the Wialon database. In such cases, you should reduce the frequency of sending messages with data in the terminal settings.

Possible solutions:

  • Use Message validity filtration;
  • Change the Trip Detector settings.

In the example above, we managed to get rid of outliers by using the ignition sensor in the trip detector, since they are detected in the interval when the ignition is switched off:



b. Using the mileage sensor

In some cases, the counter (the General tab in the unit properties) works based on GPS coordinates, but a separate mileage sensor is also created (the Sensors tab in the unit properties). In reports, for example, with the Trips table, the Mileage column will display the value based on GPS (total distance between coordinates), but the value of the Initial/Final mileage columns will be calculated using the following methods:

  • If the first/last message of the interval has the mileage sensor value, the system uses these values.
 Explanation

Let's agree that the unit actually traveled 2 km, and messages came in the following order:

  1. 10 km
  2. -- km
  3. -- km
  4. 15 km

In the Mileage column, we get 2 km (the total distance between coordinates without considering the mileage sensor); in the Initial mileage column, we get 10 km (as in the message); in the Final mileage column, we get 15 km (as in the message).

В колонке Пробег получим 2 км (суммарное растояние между координатами без учета датчика пробега), в колонке Начальный пробег получим 10 км (как в сообщении), в колонке Конечный пробег получим 15 км (как в сообщении).

A similar example, but the value of the mileage sensor is available only in the last message:

  1. -- km
  2. -- km
  3. -- km
  4. 15 km

In the Mileage column, we get 2 km (the total distance between coordinates without considering the mileage sensor); in the Final mileage column, we get 15 km (as in the message).

And one more example, where the mileage sensor value is only available in the first message:

  1. 10 km
  2. -- km
  3. -- km
  4. -- km

In the Mileage column, we get 2 km (the total distance between coordinates without considering the mileage sensor); in the Initial mileage column, we get 10 km (as in the message).

  • If there is no mileage sensor value in the first message of the interval, the system looks for the first available message with the mileage sensor value for this interval, and then the mileage before the start of the trip, calculated from GPS coordinates, is subtracted from it.
 Explanation

Let's agree that the unit actually traveled 2 km, and messages came in the following order:

  1. -- km
  2. -- km
  3. -- km
  4. 15 km

In the Mileage column, we get 2 km (the total distance between coordinates without considering the mileage sensor); in the Initial mileage column, we get 15 km – the value calculated from GPS coordinates or 15 km - 2 km = 13 km; in the Final mileage column, we get 15 km (as in the message).

  • If there is no mileage sensor value in the last message of the interval, the system looks for the last available message with the mileage value for this interval, and then the mileage at the end of the trip, calculated from GPS coordinates, is added to it.
 Explanation

Let's agree that the unit actually traveled 2 km, and messages came in the following order:

  1. 10 km
  2. -- km
  3. -- km
  4. -- km

In the Mileage column, we get 2 km (the total distance between coordinates without considering the mileage sensor); in the Initial mileage column, we get 10 km (as in the message); in the Final mileage column, we get 10 km + the value calculated from GPS coordinates or 10 km + 2 km = 12 km.

  • If there is no mileage sensor value in the first and last messages, the system looks for the first available sensor value, and then subtracts the mileage calculated from GPS coordinates from it to get the initial value, and to get the final value, on the contrary, adds the mileage calculated from GPS coordinates to the mileage sensor value.
 Explanation

Let's agree that the unit actually traveled 2 km, and messages came in the following order:

  1. -- km
  2. 10 km
  3. 15 km
  4. -- km

In the Mileage column, we get 2 km (the total distance between coordinates without considering the mileage sensor); in the Initial mileage column, we get 10 km – the value calculated from GPS coordinates before the first message of the interval; in the Final mileage column, we get 10 km + the value calculated from GPS coordinates before the last message of the interval.

In such a situation, if due to some failures the mileage sensor didn’t work and sent 0 km, negative mileage values may appear:


In this example, a mileage sensor was created for the unit based on the can_mileage parameter, which is absent in messages until 12/18/2019 4:38:54 PM:


After 4:38 PM onwards, the parameter always has the value 0, and the sensor, respectively, has the value 0 km.

Possible solutions:

  • Remove the mileage sensor and completely switch to the mileage using GPS coordinates;
  • Fix the problem on the hardware side or switch to a parameter with correct values.

In the example above, the solution was to remove the sensor and switch to GPS mileage only, since the parameter values were not read from the CAN bus.

2. GPS + ignition sensor

When using this type of counter, the mileage correctness can be affected by the unstable communication with satellites, data transmission failures, as well as the use of additional sensors. However, a significant difference from the GPS type and a fairly common cause of issues in this type of counter will be the use of an ignition sensor that doesn’t work correctly. Let's consider this option in more detail.

Incorrect value of the ignition sensor

The GPS + ignition sensor option is selected as the mileage counter. When building a track (via the Messages, Tracks or Reports tab), the mileage is 0 km, while the track itself is displayed on the map:



The track on the map is built according to coordinates from messages, while the mileage calculation algorithm takes into account not only coordinates and distance between messages, but also checks if the ignition is on.

In this example, a sensor with the Ignition type is not created for the unit, so the system ignores all messages and displays 0 km of mileage:


Possible solutions:

  • Switch the mileage counter to GPS;
  • Add a correctly working ignition sensor.


In the example above, the unit doesn’t send a parameter based on which the ignition state can be determined, therefore the problem is solved by switching to the GPS counter type.

3. Mileage sensor

The readings of any sensors, including mileage, can be exposed to external factors such as power shutdown, pickups, sensor malfunctions, errors of calibration and sensor/terminal configurations. Let's consider some examples of errors in more detail.

a. Resetting values of the mileage parameter

Some terminals stop transmitting mileage sensor readings for a short period of time (for example, due to power shutdown, pickups in the power supply circuit, other hardware issues). In such cases, the accumulated total mileage of the unit may differ from the last available sensor value:





In the example, the total mileage on the mileage counter is 26943 km, and on the mileage sensor – only 7069 km.

The reason is the reset of the mileage sensor parameter.


In such a situation, there occurs a reset to 0 km and then again an increase to 6452 km (in the example, such resets were repeated several times).

Possible solutions:

  • Use the Lower bound in the sensor settings;
  • Use Validation if the reset occurs under certain circumstances, and you can identify the dependence with other parameters (sensors).

In the example above, it is enough to apply the lower bound (0.01), since the reset occurs randomly and there is no dependence on other sensors.




Thus, by applying the lower bound, we managed to eliminate zero values (reset to 0 km) and avoid the incorrect mileage calculation.

b. Messages with the same timestamp (the With overflow option enabled)

Terminals may send messages too frequently. Wialon has a limitation: no more than 1 message should come from a unit per 1 second. When receiving data with a higher frequency, its chronology may be disrupted and a lower mileage value may end up in the database after a message with a larger value, an example is in the picture below:


In such situations, the counter overflows to the maximum possible value – 2147483648.

Possible solutions:

  • Disable the With overflow option in the sensor settings (if it was enabled).

In the example above, the With overflow option was enabled. Turning it off, we got a more correct mileage value:


с. Messages with the same timestamp (the With overflow option disabled)

Messages may come with the same timestamp, disrupting the chronology, for example:

In general, in the picture above, the mileage looks correct – 25.01 km, in contrast to the previous example, where the error was obvious. However, if we take from the messages the initial value of the mileage sensor in the interval – 9917.81 km and the final value – 9942.44 km, subtract the difference, then we get the mileage – 24.63 km.

The difference is 0.38 km on a relatively small section of the track. The inaccuracy will grow with the increasing amount of data (number of trips). The reason for this error is, of course, the disruption of message chronology. The system expects the sensor value to increase. In the example, we see a drop from 9931.03 km to 9930.85 km and a subsequent increase to 9931.29 km. The mileage between messages with the sensor value 9930.85 km and 9931.29 km is recalculated, i.e., an extra 0.44 km is added.

Possible solutions:

  • Switch the mileage counter to GPS;
  • Fix the problem on the hardware side;
  • Switch the mileage sensor to the Relative odometer type and apply validation.

In the example above, we managed to get more correct mileage values by switching the mileage sensor to the Relative odometer type with the added validation. The relative odometer sensor is based on a parameter represented as: mileage-#mileage. The validator is based on a parameter represented as: time-#time. The lower bound for the validator is 0, and the validation type is Not-null check. The mileage counter in the General tab is switched to Relative odometer.

After applying the validation, the mileage was 24.65 km. Messages with the same timestamp are excluded from the calculation.

If you have any questions on specific practical cases, you can contact technical support via email support@gurtam.com. Make sure to indicate in your email a brief description of the situation with screenshots, the exact unit name, the report template name for verification, the minimum time interval for verification (for example, not a month, but one day), and other essential details.

Pavel Chebotarev,Wialon Trainer

Issues When Changing Access Rights to Units
  • technical_consulting
  • access_rights

Users can have access rights to various items: units, groups of units, resources and accounts, routes, and other users. Depending on the available rights, the user can view and take some actions on a particular item.

Most often, full access to the unit (all rights) have only those users who configure it, while other users have limited rights sufficient to work with the unit. To avoid the incorrect changes of settings, it is important to assign to users only those rights that they really need.

Observed issue and the method of solving it

In everyday work, the rights to the unit are defined appropriately and do not change. However, there may be difficulties when changing rights, or sometimes rights can change without your participation, and the resulting settings may differ from what you expect. In this article, we'll consider standard issues of this kind. Choose one of the options below according to the situation you are experiencing.

1. After reducing the rights, the user still has more rights

A unit can belong to the group, towards which the user also has rights. In this case, the user will possess a wider list of rights of the two possible.

To correct the situation, try excluding the unit from the group or removing user rights to the group that the unit belongs to. After making these changes, set the desired rights towards the unit again.

A unit can belong to several groups at once, and in this case, it is recommended to check the user's rights towards all these groups. The list of groups that a unit belongs to is displayed on the Groups tab in the unit properties.

2. When removing all rights to a unit, an error is displayed and the changes are not applied

Most likely, this user is the creator of the unit. At the moment, it is impossible to remove from the creator all the rights to the item created by him or her. If you try to do this, an error will be displayed with the text "You cannot withdraw access rights from the creator of an object".

To correct the situation, you need to change the creator of this unit. To do this, you can transfer the unit to another account. The unit must be in the account of a user who directly uses this unit.

We’ve created a video on how to use the Switch account tool from the management interface (CMS):

3. When extending the rights, changes are not saved

Wialon uses the following hierarchy principle: it is impossible to give a user more rights to a certain item than the creator of this user has to the same item. If you extend the list of rights, but the changes are not saved, it may mean that the user's creator doesn't have enough rights to the unit.

To correct the situation, assign a wider list of rights towards the unit to users who are higher in the hierarchy. After that — to the user, who needed to extend the rights (that is, go through the entire branch of the account hierarchy from top to bottom).

You can check the service structure using the Service Hierarchy tool in the management interface (CMS).

4. Rights change even though you don't make changes

To change access rights to a unit, the user must have the Manage access to this object right towards that unit. Multiple users can have access to a unit simultaneously. Accordingly, several users can make changes. You can track changes using the Log, which you can view on the Messages tab or in a report using the same-name table.

To correct the situation, analyze the Log and disable the ability to change access rights for those users who should not do this.

5. Rights change even though no user is making changes

Most often, such changes may occur in a certain equal period or under certain conditions. In this case, the reason is the work of Jobs with the Change access to units type or Notifications with the action method Change access to units or Add or remove units from groups.

To correct the situation, check that jobs and notifications are configured correctly (if necessary, you can delete or stop them).

6. Rights change even though users, jobs and notifications don't do this

Wialon has the ability to change item settings (including changing rights) via API requests. Such requests are still executed on behalf of a specific user, at the same time, logging in and out of the system using an API request to some third-party application is logged. This information can be tracked in the user properties on the Log tab or in the management interface (CMS) on the Users tab in the Last visit column.

To correct the situation, analyze the operating logic of the third-party application. If the application uses a user token created specifically for working with a third-party application, then this user can change the list of rights and disable the Manage access to this object right, or change the flags of his or her token. If the application uses the token of the same user that is used to enter the monitoring interface, it is necessary to revise the application logic, getting rid of changing user rights towards units.

Changes to unit rights are logged in the Log (on the Messages tab or in a report using the same-name table). The Host column will contain the username if the changes were made manually or via an API request, or "job" or "notification" if the changes were made using this functionality.

Log entries can be deleted. In this case, information about changing rights will not be displayed. If you suspect that you’ve faced such a situation, please contact Wialon technical support via email support@gurtam.com.

Ekaterina Grib,Technical Consulting Engineer

10
  • 10
  • 25
  • 30
Thank you for your feedback!
Report a mistake
Text with the mistake Comment
Maximum 500 characters