One of the first and crucial stages of working with Wialon is setting up sensors in the unit. This article will provide a detailed explanation of sensor validation, as it has some non-obvious use cases and allows users to perform unique actions with sensors.

## General principle of sensors operation

Wialon supports many types of trackers; you can find their current number on the wialon.com website in the **Hardware** section. Each of the trackers "speaks" in its own way. Therefore, the parameters which come from different types of trackers and which are displayed on the **Messages** tab may contain the same information (for example, about temperature or mileage) but have different names. It is necessary to create sensors for each unit in Wialon to prevent users from noticing the differences when using units with various trackers. Also, sensors have a specific type, which allows the system to understand which algorithm to choose to process input values.

However, a simple selection of a sensor type and specifying a parameter in it is often not enough because the parameter value comes in an unobvious to the user way. There are three methods to convert the input parameter to the desired type:

- Expression in the
**Parameter**field; - Calculation table;
- Validation.

They can be used individually or combined. If you use several methods simultaneously, they will be applied in the exact order they are listed above.

## When to use validation

Validation is used in cases where it is necessary to link the value of one sensor to another. In terms of practical applications, the following cases can be distinguished for using validation:

- one sensor affects another at the physical level (for example, a fuel level sensor shows the wrong value when there is a jump in the voltage sensor readings);
- it is necessary to link several sensors into a logical scheme (for example, it is necessary to create a sensor for opening the front doors of a car, which will be activated when either the left door opening sensor or the right door opening sensor is on);
- it is necessary to display a report for a time interval, where an old sensor with one parameter was used at the beginning and a new sensor with another parameter was used at the end (for example, a less accurate fuel level sensor with one calibration table was previously used on a truck and then it was replaced with a more accurate fuel level sensor with another calibration table);
- several sensors are measuring the same parameter and it is necessary to display the value of one or the other sensor (for example, a more accurate fuel level sensor was installed on a vehicle in addition to a less accurate factory-installed fuel level sensor, and usually the readings of the more accurate one are used, but if they have an error, it is better to read the values of the factory-installed sensor, even though they are less accurate);
- the parameter contains information about different systems of a unit, and only a certain part needs to be extracted from it (for example, the first 5 bits of the parameter indicate voltage, while the subsequent bits have a different purpose, and only those bits related to voltage are to be extracted from the parameter);
- some arithmetic calculations need to be performed that involve values from several sensors (for example, it is necessary to see the real-time fuel consumption in km/l, which is calculated by dividing the reading from the relative odometer by the reading from the instant fuel consumption sensor).

## Types of validation

There are 12 types of validation in Wialon. You won't see such a division in the monitoring system interface, but for simplicity, all types can be roughly divided into 3 groups.

Group | Validation types | Comment | Alternatives |
---|---|---|---|

Arithmetic | - Sum up
- Subtract validator from sensor
- Subtract sensor from validator
- Multiply
- Divide sensor by validator
- Divide validator by sensor
| You can easily work without these types. | Alternatives exist and are simple. |

Algorithmic | - Not-null check
- Replace sensor with validator in case of error
| Both types are used frequently. | There is a simple alternative for the second type. |

Logical | - Logical AND
- Logical OR
- Math AND
- Math OR
| The least clear types, usually only the first two are used. | Alternatives exist, but they are not simple. |

## Arithmetic validation

This group includes basic arithmetic operations: addition, subtraction, multiplication, and division.

You can easily work without these types of validation, as similar results can be achieved using an expression in the **Parameter** field. To refer to the value of another sensor in the expression, you need to specify the name of this sensor in the square brackets (for example, **[Fuel Level]**).

The following example illustrates a small difference between these approaches.

## Algorithmic validation

This group includes only 2 types of validation, and we will consider each of them.

### Not-null check

This type of validation is one of the most commonly used. It allows ignoring incorrect readings of the validated sensor, while their availability is determined by the zero value of the validating sensor (the validator).

The most common situation of application is as follows: a sensor connected to the tracker may show incorrect data when the voltage is insufficient.

### Replacing the sensor with a validator in case of an error

This type of validation is also quite popular. Its logic is simple: if the validated sensor has an erroneous value, it is replaced with the value of the validator.

This type is suitable for situations where it is necessary to display the value of two sensors as if they were one sensor. There are usually two reasons for this: either an old sensor has been replaced with a new one, and reports should contain information for both the old and new sensor intervals, or there are two sensors on the unit at the same time, but one of them occasionally displays an error, and at this moment it is necessary to display the value of the other sensor. Let's consider both cases with examples.

## Logical validation

This group includes 4 types of validation:

**Logical AND**and**Logical OR**, which work with logical values (in Wialon they are called digital, that is, On/Off or 1/0);**Math AND**and**Math OR**, which work separately with each bit of numbers.

Let's consider these types with examples.

### Logical AND/OR

For simplicity, the **Logical AND** operation gives a value of 1 as a result only when both input values are equal to 1, and the **Logical OR** gives a value of 1 if at least one of the input values is equal to 1.

If we assume that two sensors are linked by validation, and one of them is based on parameter **a**, and the other is based on parameter **b**, then all possible results can be described using one table:

Truth table | |||
---|---|---|---|

a | b | a AND b | a OR b |

0 | 0 | 0 | 0 |

0 | 1 | 0 | 1 |

1 | 0 | 0 | 1 |

1 | 1 | 1 | 1 |

### Math AND

This validation is useful for extracting a specific part of the bits from a parameter. It involves bitwise execution of the **Logical AND** operation, as demonstrated below.

First, convert the considered number must be from decimal (DEC) to binary (BIN) numeral system using the **Calculator** application in programmer mode or similar online tools.

For example, the result of the math AND between the numbers 122 and 15 will look like this:

DEC | BIN | ||||||||
---|---|---|---|---|---|---|---|---|---|

number 1 | 122 | 0 | 1 | 1 | 1 | 1 | 0 | 1 | 0 |

number 2 | 15 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 |

result of math AND | 10 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 |

If the bit in the second number is equal to 0 (highlighted in red), then the final value of this bit will also be 0. If the bit in the second number is equal to 1 (highlighted in green), then the final value of this bit will be equal to the value of the bit in the first number. We can say that using the binary representation of the number 15, the number 122 was filtered in such a way as to leave only the 4 least significant bits in it.

### Math OR

This validation implies bitwise execution of the **Logical OR** operation, as demonstrated below.

First, convert the considered number must be from decimal (DEC) to binary (BIN) numeral system using the **Calculator** application in programmer mode or similar online tools.

For example, the result of the math OR between the numbers 122 and 210 will look like this:

DEC | BIN | ||||||||
---|---|---|---|---|---|---|---|---|---|

number 1 | 122 | 0 | 1 | 1 | 1 | 1 | 0 | 1 | 0 |

number 2 | 210 | 1 | 1 | 0 | 1 | 0 | 0 | 1 | 0 |

result of math OR | 250 | 1 | 1 | 1 | 1 | 1 | 0 | 1 | 0 |

If at least one of the bits in the first two numbers is equal to 1, then the final value of this bit will be equal to 1 (highlighted in green). If both bits in the first two numbers are equal to 0, then the final value of this bit will be equal to 0 (highlighted in red).