Fleetrun
Hecterra
NimBus
Other apps
Wialon for Android/iOS
Logistics
Wialon Local
Wialon Hosting
WiaTag
Configurator
LeaseControl
en
Contents
Chronology
  • tables

The Chronology table gives information about all the actions and changes in the unit state during the indicated period of time. Unlike most of the tables that are dedicated to a particular state (parkings, sensors, trips, etc.), this table combines events of various kinds, which allows seeing the complete picture of the movement.

In the Data to display section of the template settings, select the information you want to see in the table: trips, parkings, stops, engine hours, fillings, drains, battery charges, events, drivers, trailers, speedings, connection loss, sensor trigger.

As the Chronology table combines data from several tables, it requires the same pre-configuration as these tables, and the same options are important for it. Below are the types of information from the Chronology table and their corresponding report tables with links to the documentation.

Type of information in the "Chronology" tableReport table 

Trips

Trips
ParkingsParkings
StopsStops
Engine hoursEngine hours
FillingsFuel fillings and battery charges
DrainsFuel drains
Battery chargesFuel fillings and battery charges
EventsEvents
Drivers

Assignments 

(Advanced reports service not required)

Trailers

Assignments

(Advanced reports service not required)

SpeedingsSpeedings
Connection lossConnection problems
Sensor triggerDigital sensors
In the Chronology table, you can select the columns described below.

ColumnDescription
TypeTrip, parking, stop, engine hours, filling (or reg. filling), drain, event (or violation), driver, connection loss, sensor.
Beginning

The time taken from the message that precedes the one in which the beginning of the given state was fixed.

In the case of fuel fillings, drains and battery charges, this column shows their time, that is, the time of the maximum fuel or battery level difference. 

Initial location

The location of the unit at the initial moment.

In the case of fuel fillings, drains and battery charges, this column shows the location at the time they were detected, that is, at the moment of the maximum fuel or battery level difference.

End

The moment when the detected activity finished.

In the case of fuel fillings, drains and battery charges, this column shows the same time as the Beginning column.

Final location

The location of the unit at the final moment.

In the case of fuel fillings, drains and battery charges, this column shows the same location as the Initial location column.

Duration

The duration of the state.

In the case of fuel fillings, drains and battery charges, this column shows 0 because the system doesn’t calculate their duration.

DescriptionFor trips and speedings — mileage, for events and violations — the text of notification, for engine hours — duration, for drivers — driver's assignment/separation and name, for fuel fillings, fuel drains and battery charges — the volume of fuel (amount of energy) and sensor name, for sensors — sensor activation/deactivation.
NotesAn empty column for your custom comments.

If you want the Cronology table to contain information about triggering of only certain sensors, you can configure the Sensor masks filter in the table settings. The Chronology table can only show information about sensors from the Digital group.

The Chronology table may show rows with fillings and drains marked as false. To do this, the Show false events option must be enabled in the report settings.

The system does not calculate the duration of the state for fuel fillings, fuel drains and battery charges. Therefore, the beginning and end time for fillings, drains and charges, as well as the initial and final location coincide in the Chronology table, and the duration column displays zero value.


Questions and answers

  A vehicle has completed a trip. There are messages with 70 kph speed, but the trip is not shown in the report. What is the reason and what should I do?

Possible explanations and actions:

  • Movement detection is set incorrectly in the trip detector, e. g., the ignition sensor is out of operation or configured improperly.
  • If some filtration of intervals is selected in the reports template (by minimum mileage, by stops, etc.), those filters can weed out this trip. Clear the filters or correct them.
  • The interval for data transmission which is set in the device is bigger than Minimum parking time option set in the trip detector. Either configure the tracker to send data more often or increase minimum parking time value.
  • Check other parameters of the trip detector.

  Do reports display the data on the manual assignment of the driver after the data storage period expires?

Yes, but only if the driver has not had other assignments since they were last assigned to the unit.

  A vehicle has been refuelled, but I cannot find this filling in the report. Why?

Possible explanations and actions:

  • Incorrect settings for trip detector
    The option to analyze fuel filling only at stops is set in the properties of the fuel level sensor, however, the trip detection is not adjusted correctly. Either disable filling detection at stops or change trip detector settings (in particular, increase minimum moving speed or maximum distance between messages).
  • High filtration level of FLS
    Decrease the filtration level of FLS in its properties (recommended are values up to 15) or set the Calculate filling volume by raw data option.
  • High value of minimum filling
    Decrease the value of the minimum filling volume in the properties of the fuel level sensor.

  There has been a fuel drain, but it is not shown in the report. Why?

Possible explanations and actions:

  • Test drain right before fuel filling
    If you made a defueling for test purposes and then refueled the vehicle right away, the system may regard this as an outlier of data. In real situation, when a drain is not followed by immediate refueling, such drain will be detected.
  • Drain during a prolonged shutdown of the device
    A drain can be detected only if the Calculate fuel consumption by time option is off (see the properties of the fuel level sensor) and if there is a trip after switching on the device again.
  • High filtration level of FLS
    Decrease the filtration level of FLS in its properties (recommended are values up to 15) or set the Calculate drain volume by raw data option.
  • High value of minimum drain
    Decrease the value of the minimum drain volume in the properties of the fuel level sensor.

  What is the difference between time-based and mileage-based calculation of fuel level?

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. ​

  Why doesn't consumption by math work?

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.

  How to configure consumption by math if the unit doesn't have ignition?

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.

  Why does mathematical calculation show enormous values?

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.
  How to determine fuel consumption, if I know how much fuel the unit consumes within the city, and how much outside it?

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.

  How does the mathematical calculation algorithm work?

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.

If you find a mistake in the text, please select it and press Ctrl+Enter.
Thank you for your feedback!
Report a mistake
Text with the mistake Comment
Maximum 500 characters