Fleetrun
Hecterra
NimBus
Other apps
Wialon for Android/iOS
Logistics
Wialon Local
Wialon Hosting
Distance Tag
WiaTag
Configurator
Contents
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

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