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 drains if the **Calculate drains by time** 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 ⋅ ( C _{I 1} + C_{I 2} + ... + C_{I N} ) ⋅ (K_{EES 1} + (K_{EES 2} - 1) + (K_{EES 3} - 1) + ... + (K_{EES M} - 1))**,

where **Δt** — the time between messages; **C _{I 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;

**K**— the value of the i-th engine efficiency sensor in the considered message;

_{EES i}**M**— the number of engine efficiency sensors created in the unit.

## 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 coefficient 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.(%) 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.**Seasonal coefficient**

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 **Calculate drains by time** 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.

- 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. - 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. - The frequency of messages generated by the tracker may be too low.
- This may be due to a breakdown of the sensor, which readings are used in the mathematical model.
- 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.