Advanced properties

To work with the Advanced tab, you should have the following access rights to the unit:

1. Mileage-based calculation

In a standard situation, all calculations of fuel level are mileage-based. That means data from the FLS is taken only during intervals of movement (trips). Those trips are defined according to parameters set in the trip detector.

Drains and fillings are detected if there is a difference between the fuel level on the following movement interval (X) and the fuel level on the previous movement interval (Y). If (X — Y) > 0, it is a filling; if (X — Y) < 0, it is a drain; if X = Y, it is neither. Of course, there can be some inaccuracy in data coming from the FLS. That is why, to avoid false drains and fillings, set the following parameters in the FLS properties:

• minimum fuel filling volume,
• minimum fuel drain volume,
• minimum stop duration to detect a fuel drain,
• and some others.

2. Time-based calculation

This type of calculation is more complicated and is based on the following algorithm: the speed of the decrease of fuel level according to the FLS is compared with the consumption calculated mathematically. The time-based calculation is necessary for stationary units. It is also widely used for moving units for controlling drains during the movement, for example.

Example

A vehicle stayed at a parking lot during 10 hours. Defueling was made in small portions over the whole parking period. As a result, 60 liters of fuel were drained. It is possible to determine if it was a drain o fuel consumption according to the state of the unit’s ignition sensor. ​

Since the consumption math mechanism is based on the values of the ignition sensor, check its properties and operation. You may not have this sensor created or there may be 0 l/h indicated for the fuel consumption in its properties.

You may use one of the approaches described below.

Variant 1

Create a virtual ignition sensor. We recommend that you use average speed (speed+#speed)/const2 as its parameter.

Variant 2

Even if you haven’t installed an ignition sensor in the unit or are not sure of the name of the parameter that responds for the ignition, in the parameters of the device there may be some characteristic that corresponds to the operation of the engine. To use it, compare two messages from the unit: one — when the ignition the most probably off; the other — when it’s on.

Example

During a long time interval the unit sends approximately the following set of parameters:

hdop=1, odo=0, adc2=2.0475, adc12=1037, c1=0, c2=0, c3=0, c4=0, mcc=260, mnc=2, lac=56720, cell_id=43811, ta=1,
gsm_lvl=55, total_fuel=407154, can_fls=101, can_taho=4797, can_engine_hrs=230420, can_mileage=137603392, engine_temp=123,
srv_dist=0, j1939_air_temp=9072, J1708_eng_hrs=230420, J1708_fl_used=430282, J1708_fl_lvl=101, I/O=80/0

While moving at some speed — approximately the following:

hdop=1, odo=847.358764648, adc2=2.3595, adc12=1117, c1=0, c2=0, c3=0, c4=0, mcc=260, mnc=2, lac=56720, cell_id=60167,
ta=1, gsm_lvl=71, total_fuel=407178, can_fls=101, can_taho=9940, can_engine_hrs=230447, can_mileage=137609550,
engine_temp=124, srv_dist=0, j1939_air_temp=9353, J1708_eng_hrs=230447, J1708_fl_used=430307, J1708_fl_lvl=101, I/O=d1/0

Straight before the start of the movement, as a rule, the ignition turns on:

hdop=1, odo=0, adc2=1.4937, adc12=895, c1=0, c2=0, c3=0, c4=0, mcc=260, mnc=2, lac=56720, cell_id=60268, ta=2,
gsm_lvl=64, total_fuel=407166, can_fls=100, can_taho=996, can_engine_hrs=230439, can_mileage=137605711, engine_temp=120,
srv_dist=0, j1939_air_temp=9369, J1708_eng_hrs=230439, J1708_fl_used=430295, J1708_fl_lvl=100, I/O=80/0

Discard the parameters that are obviously imprecise: hdop (precision), adcN (it’s difficult to determine the regularity), odo (relative odometer in meters), mcc mnc cell_id and lac (LBS data section), gsm_lvl (the level of the GSM signal), etc. The parameter J1708_eng_hrs for this unit seems the most probable, as it doesn’t change during the night parking. As a rule, it is also possible to use pwr_ext. Is the ignition is digital, you can follow the values’ changes in the block ‘I/O =’ (see more details in the Inputs and outputs section).

Variant 3

If you have already connected the ignition, find out its parameter by means of the method described above or from the manual of the manufacturer.

Possible reasons:

• In some cases, the system may consider that during the interval with no messages from the unit its ignition was on. Adjust the default value ‘0 seconds’ on the Maximum interval between messages option on the Advanced tab of unit properties. The influence of the option on the fuel calculation is described in the documentation.
• Several engine efficiency sensors can be created. Check up their values. The easiest way to evaluate it is to create in a report a simple chart with one of the curves Fuel consumption by math.

Let us suppose that the fuel consumption in the urban cycle is 10 l/100 km and 7 l/100 km — in the suburban cycle.

• Create an ignition sensor (as in the example above) and set 1 l/h for the consumption during idling.
• The average consumption in the urban cycle is 36 km/h, in the suburban — 80 km/h.
• The unit will cover a distance of 100 km driving at a speed of 36 km/h in 2.8 hours. 10 l / 2.8 = 3.57. Let us calculate the value of the increasing coefficient when moving in the city: 3.57 / 1 (idling) = 3.57.
• As a result of a similar calculation for the suburban cycle, we obtain the coefficient equal to 5.6.
• Create an engine efficiency sensor, taking into account the fact that the unit cannot consume less fuel than during the idling, and that it is stationary before the beginning of the movement. As a parameter we use the average speed (speed + # speed) / const2 and fill in the calculation table (manually or using the calculation table wizard):

Note that the last pair of points is how the system calculated before (the fuel consumption was considered constant for a speed above 80 km/h). You cannot use this method and change the set of points. Also ‘3’ in this example is the minimum speed from the unit’s trip detector, consequently, this parameter can be different for your unit.

Result: in our example, the average consumption has been calculated for the unit. It has been calculated relative to the speed and time between messages and taking into account the values of the vehicle operation.

During the mathematical calculation, fuel consumption is computed separately for each pair of messages.

The following algorithm is used:

1. The status of each engine sensor (engine ignition, absolute and relative engine hours sensors) in the current message is determined.
2. For the operating sensors the values indicated in the field Consumed, l/h of their properties are summed.
3. The values of the engine efficiency sensors bounded to the engine sensors are calculated.
4. The received values are summed according to the formula k1 + (k2 - 1) + (k3 - 1) + … + (kn – 1). In that way, the coefficient is formed. If the sum of the coefficients is less than 0 or invalid, the total coefficient will be 1.
5. To determine the current fuel consumption of the unit, the value from point 2 is multiplied by the value of point 4.
6. The value from the previous message till the current one is multiplied by the value from point 5.
7. The consumption for each message pair for the indicated interval is summed and in that way, the fuel consumption is determined by consumption math.

As a rule, the seasonal coefficient supposes increased fuel consumption. For instance, the consumption in winter is 30% higher than in summer. Let us suppose, that the winter in your climate is from December, 1 to March, 1.

8. Create an engine efficiency sensor with the parameter time:d.
9. Find out which numbers of the day in the year do your dates correspond to. High precision is not obligatory: a year may be a leap one and the season itself may be longer or shorter. For the period indicated above, for example, the numbers are ‘334’ and ‘59’ approximately.
10. Create a calculation table as seen in the screenshot below.
    

time is the parameter that is present in any message from any device, and the system will calculate the number of the day automatically on its basis. In that way, as the season starts, 30% will automatically be added to the fuel consumption.

1. You need a tachograph and a tracker which supports unloading DDD files.

2. Create a driver in the monitoring interface. The value of the Code field must correspond to their personal card’s number.

3. Create a sensor of the Driver assignment type and add the unit to the driver’s automatic assignment list.

4. Create a command for unloading a DDD file on the Commands tab of the unit properties. The command syntax may vary depending on the device type.

5. For sending a command of querying a DDD file, the unit must have an open TCP connection (the timeout depends on the type and the configuration of the tracker).

6. After unloading a DDD file the following line appears in the messages:

• driver_card1_file=C_хх_1256.ddd, register_ddd=0 — the unloading has been successful, but the file hasn’t been attached to the driver (not enough access rights to the resource or there is no driver with such a code);
• driver_card1_file=C_хх_1256.ddd, register_ddd=1 — the unloading has been successful, the file has been attached to a definite driver.

The syntax of the response depends on the type of device used. Some devices send an additional response by means of the Chat with drivers window.

The time needed for unloading a file depends on the tracker (it may take from 5 to 30 minutes approximately).

7. You can view the downloaded file and check the driver’s work for a previous interval in the application Tacho View.

8. The DDD files from a driver’s card are stored in a resource. The storage period of such files is not limited; they are deleted together with the resource they belong to.

LBS ( location-based service ) is a service that determines the location of a unit according to the coordinates of GSM base stations.

GPS may be unavailable for various reasons: GPS antenna failure, dense urban development, tunnels, parking garages, and so on. In such cases, it is advisable to use LBS. Due to shorter waves, the probability of LBS catching the signal in places with obstacles (reinforced, metal, shielded surfaces) is much higher.

The accuracy of LBS is generally lower: it depends on local radio conditions, the density of the base station network, cell configuration. However, it is easier to catch the signal using LBS. This increases the chance of receiving positional data in a message when GPS is not available.

If technical conditions are met, the service can be configured for any monitoring unit. For the most part, LBS is used in the fields where the exact coordinates are not so important as the fact of arrival, departure, moving, or stopping.

For example, in container shipping, a device installed inside the container does not catch the satellite signal. However, the LBS messages show the fact of delivering the goods to the warehouse, unplanned stops, significant deviations from the route.

LBS is also used for monitoring stationary units, especially if the device does not have a source of direct current. This saves the battery life of the device, while a disabled GPS module would significantly increase it.

You can find a list of supported devices in the Hardware section of our site.

When the monitoring unit does not send positional data via satellites, Wialon reads the identification number of the base station and searches for the coordinates in the database.

Wialon uses its own database. It is updated as new messages with LBS and GPS coordinates are received from the units. Before adding new points to the database, they are additionally checked. At the moment, the database includes more than 62 million points.

The messages should contain 4 parameters: cell_id (identification number of the base station of the mobile operator), mcc, mnc, and lac (service parameters). To verify the fact of their correct transmission and reception,  request  data messages on the Messages tab.

There could be the following reasons for it.

• Your device is not able to send LBS data.
• Your device has incorrect settings. To get LBS data, a device needs to transmit at least 4 parameters: mcc, mnc, lac, cell ID. Please check your device settings and make sure your device can transmit those parameters.
• You haven’t activated message validity filtering. On the Advanced tab of the unit properties, tick the checkbox Message validity filtering, then activate the Allow positioning by cellular base stations function.

To see the last unit location determined by LBS, use the LBS detector .

In order for the LBS data of the unit to be saved in Wialon, open the Advanced tab of the unit properties, enable message validity filtering  and activate the Allow positioning by cellular base stations option. After that, the LBS coordinates will be used in reports and when displaying the unit on the map. For notifications, activate the Process LBS messages option in their settings.

The LBS coordinates of the unit are saved only if they are determined later than the GPS coordinates in the message.

If the location of the unit is determined by LBS, you can tell this by how it is displayed on the map and by the icon     which is shown opposite the unit name in the work area of the Monitoring  tab.

Send a request to hw@wialon.com indicating the type of device for considering the issue.

If extended expertise is specified for your type of device, send an email to hw@wialon.com  with all the details. You can also ask for help in configuring other devices.

Send a request to support@wialon.com indicating the values of the parameters​​ mcc, mnc, lac, cell_ID.

Make sure that positioning by LBS is configured for the unit on the Advanced tab of its properties. In the case of notifications, also check if the Process LBS messages option is activated in their settings. If the problem is still unresolved, write to support@wialon.com specifying all the details.

Possible explanations and actions:

1. Outliers of data.

To detect such outliers, build a track of unit movement for the appropriate period. Outliers of data will be seen on the track as dashed lines.

Ways to overcome outliers:

• Enable filtering of unit positional information in messages (on the Advanced tab of unit properties). This will not affect old messages but applied to new ones.
• To correct data in reports, change settings of trip detection, in particular, reduce Maximum interval between messages and increase Minimum satellites.

2. Incorrect settings or operation of the mileage counter.

• Check the mileage counter settings on the General tab of unit properties.