Parameter is a required sensor property. Most of the sensors are based on a parameter coming in messages.

Parameters can be of any names. These names are predefined in the device configuration, for example, param199, param240, TEMP, pwr_int, gsm, can6, and the like. Read device specification to find out which parameters are available and what they measure. On the Messages tab, you can also request messages from the unit and view the available parameters in the corresponding column.

The parameters from the last message appear in the dropdown list of available parameters when creating or editing a sensor. However, even if the parameter you need is not on the list, you can enter its name manually.

The same parameter can be used to create any number of sensors. The maximum number of sensors allowed can be viewed on the Account tab of the User settings dialog.

Virtual parameters

Some parameters are defined in the system by default and are suitable for almost any type of equipment.

Inputs and outputs

The system supports up to 32 digital inputs and outputs. They are adjusted in the following format:

For example, adc8 is a parameter that registers the values coming from the eighth analog input.

Usually, the data from digital inputs and outputs are presented in messages in the following format: I/O = 0/0, where I refers to inputs, O — outputs. If I/O = 0/0, it means all bits (inputs and outputs) are inactive. If a value in any of them is not zero, it means that one input/output or several of them are active. To determine which exactly, convert the hexadecimal number to binary and use the latter to define a bit number.

For instance, when the ignition was activated, we received the message with the parameter I/O = 10/0. To get the bit number (input) in which the value of the sensor is shown, it is necessary to enter the received value in the calculator in the mode of hexadecimal values (HEX). That is, enter 10 and switch to the binary mode (BIN). We get a new number - 10000. Now we have to calculate in which position 1 has appeared. The calculation is done from right to left. In the given case 1 is in position 5, i.e. the ignition sensor is connected to the fifth port. Since the changed number is before the fraction (I/O), it is the input. Consequently, the parameter name is in5 (digital input 5).

For a sensor, it is also possible to specify the parameter name as in or out to indicate the sum of all inputs and outputs, respectively.

Constant parameter

Besides, constN parameter can be used to create a sensor that always returns the same value. N is any number, e.g., const10, const-8.5. Such a sensor can be helpful in charts or as a validator.

Such a sensor can be used both independently (for example, in charts to indicate some critical mark) or as a part of validation chain or in expressions.

Expressions

Parameter for a sensor can be set in the form of expression where you can use:

• parameters in the current message (adc1, in1 etc.),
• parameters in the previous message (they begin from the hash sign #, for example, #adc1),
• bitwise parameters (like param199:3),
• sensors (sensor name must be in square brackets, for example, [Fuel level]),
• constant numbers (const10, const-4.54 etc.),
• mathematical operation signs:

For example, ^const2 — square, ^const0.5 — extract the square root.

If one of the parameters that an expression includes is not valid, its total value is also invalid.

Expressions allow creating a great variety of sensors that meet any needs and tasks.

Example 1: detecting speed by GPS coordinates

To detect speed by coordinates, you can create a sensor with the following parameter:

((lat-#lat)||const2+(lon-#lon)||const2)||const0.5/(time-#time)*const200000

Explanation:

The traditional formula to calculate the speed of the movement is "distance divided by time". To calculate the distance, the Pythagorean theorem is used. The squared difference of latitudes in neighboring messages plus the squared difference of longitudes in neighboring messages, and then the square root is extracted from this sum. The resulting value is the distance (in degrees). This value is divided by the time difference in two neighboring messages. As a result, it is the speed in degrees per second. To convert the value to kilometers per hour (or miles per hour), you should apply the conversion coefficient of degrees to kilometers (or miles) at different latitudes. The coefficient may vary depending on the geographical position. The example above shows the coefficient equal to 200 000 which is used for Moscow.

To calculate the coefficient, the following formula is used:

111321*cos(55.75583)/1000*3600=225513.52

where 111 321 is the length of the parallel arc in 1° longitude at the equator, m;

55.75583 is the latitude of Moscow in decimal format.

If you want to calculate the coefficient for another location, insert its latitude in decimal format into the formula without changing other values.

If you have the ignition sensor, you can set the parameter in the following way:

((lat-#lat)||const2+(lon-#lon)||const2)||const0.5/(time-#time)*const200000*[Ignition sensor name]

Example 2: relative engine hours sensor

To obtain data about real engine hours, create two sensors:

• relative engine hours sensor,
• engine hours coefficient sensor in accordance with engine revolutions.

First, create a sensor of Relative engine hours type. The parameter for the sensor is:

(time-#time)*[Name of coefficient sensor]/const3600

That is, the time difference in neighboring messages multiplied by the coefficient of the intensity of work and divided by 3600. The division by 3600 is applied to convert seconds into hours.

Then, create the coefficient sensor that will define the intensity of work depending on engine revolutions. Dependency scheme can be the following:

• 1 minute work with the intensity of 2000 rpm corresponds to 90 seconds of engine work => coefficient 1.5
• 1 minute work with the intensity of 1500 rpm corresponds to 60 seconds of engine work => coefficient 1
• 1 minute work with the intensity of 1000 rpm corresponds to 40 seconds of engine work => coefficient 0.67
• 1 minute work with the intensity of 500 rpm corresponds to 20 seconds of engine work => coefficient 0.33

Suppose, the param1 sends engine revolutions. Then the coefficient parameter is the following:

(param1+#param1)/const2

That is the arithmetic average of engine revolutions between neighboring messages.

To convert revolutions into coefficient, adjust the calculation table for this sensor:

• x=500 y=0.33
• x=1000 y=0.67
• x=1500 y=1
• x=2000 y=1.5

Example 3: value availability check

There is equipment installed on the vehicle, which sends some parameter (for example, param1). Then the equipment gets out of order. A new one is installed. The new equipment sends the same data in another parameter (for example, param2). To exclude data loss during report generation, it is necessary to use value availability check in the Parameter field upon creating a sensor. The old equipment worked all December, the new one — all January, and we need a report for these two months. If the value availability check is used during the parameter indication (param1|param2 entered as sensor parameter), then the system takes a value from the param1 parameter, and if the param1 value is invalid (for example, the equipment is broken), then the system takes a value from the param2 parameter. In other words, when using the value availability check, the system takes into account the first valid value of the parameter received.

param1|param2

Textual parameters 

Most parameters are designed to send numeric data, however, in some cases, they may provide textual data. This can be, for example, a name of a status (business/private), some state (free/waiting/busy, on/off), time passed since a certain event, etc.

Sensors with textual parameters do not require configuration of calculation tables. Textual data is displayed as it is.

The values of text-based sensors can be shown in:

• additional information about the unit,
• messages panel,
• track player,
• track hittest,
• the Formatted value column of the Sensor tracing table.

Conversion of parameters

The conversion of parameters can only be applied to the parameters that are received directly from the hardware. The cases of application are described below.

Bitwise parameter control 

The bitwise parameter control gives an opportunity to control a specific bit and not the whole parameter. For example, in order to control the third bit of the parameter param199 it is necessary to put a colon and the number of the required bit after its name.

param199:3

This feature is applicable when a device sends various data in one parameter: for instance, the first bit shows alarm condition (on/off), the second bit indicates the state of the driver's door (open/closed), the third — headlights, etc. Thus, using bitwise control it is possible to create several sensors on the basis of one parameter.

We advise you not to address directly a bit above the 53rd. If necessary, you can use the following scheme.

1. Create a sensor in which the required parameter comes. For example, Sensor1.
2. Create another sensor. For example, Sensor2.
3. For the parameter of the second sensor, specify the formula [Sensor1]/const4294967296. In that way, a shift of 4 bytes to the right occurs.

Conversion of textual parameters

If there is a textual parameter in the sensor formula, it is converted into 53-bit integer. By default, it is interpreted as decimal, however, positional notation can be specified after colon. For example, there is a parameter called text_param and it has the value 100, then:

text_param = 100
text_param:10 = 100
text_param:16 = 256
text_param:2 = 4

Determination of the day number in a year

To determine the number of the day in the year (relative to January 1), it is necessary to indicate d after the colon. For example, for March 28, 2017 11:00:00 the Unix time corresponds to the value 1490698800. Therefore,

time = 1490698800
time:d = 87