Short answer
A harsh-event score measures acceleration crossing a configured threshold, not driving skill. The same braking event can come from a careless driver or from a narrow site road, and the accelerometer cannot tell them apart. A score is therefore useful for comparison and coaching, and unsafe as a ranking on its own.
Key takeaways
- A harsh event is a threshold crossing, not a judgement, the device compares acceleration against a number you chose.
- Wialon states plainly that no generally recommended threshold values exist, because acceleration depends on the vehicle and the road.
- Raw event counts penalise whoever drives the most kilometres; normalise per distance or per hour before comparing anyone.
- Cornering is the noisiest of the three signals and needs a heading value to be detected at all.
- Score to open a coaching conversation. Ranking drivers in week one measures their routes, not their driving.
01What a harsh event actually is
A harsh event is not a verdict the device reaches about a driver. It is arithmetic. The tracker measures acceleration, compares the figure against a threshold someone configured, and writes a record when the threshold is crossed. On a Teltonika FMC650 those thresholds are expressed in metres per second squared and ship with defaults of 2.2 m/s² for acceleration, 2.5 m/s² for braking and 3.4 m/s² for cornering, each adjustable anywhere between 0.5 and 10 m/s². Nothing about those numbers is a safety standard. They are starting values, and the parameter IDs behind them exist precisely because a fleet is expected to change them. Understanding this is the whole foundation of using a score fairly: every event in your report exists because a number was chosen, and a different number would have produced a different report from identical driving.
02What the accelerometer cannot distinguish
This is the limit that decides how a score may honestly be used. An accelerometer measures the vehicle's motion; it has no way of knowing why the motion happened. Wialon's own driver-behaviour documentation states that acceleration depends on engine power, vehicle condition, weight, body load, tyre grip, road surface quality and weather, and follows that by saying no generally recommended threshold standards exist. That is a platform vendor declining to publish the numbers a buyer most wants, because the honest answer is that they are specific to the vehicle and the route. A loaded truck and an empty one produce different readings from the same pedal input. A worn tyre on a rough site road produces an event a new tyre on asphalt would not. The device reports all of it identically, as a threshold crossing.
03How the device separates a real event from road noise
Device makers know the confounding problem and filter for it, which is worth understanding because the filter shapes your data. Teltonika's eco-driving implementation applies a noise filter with an acceptance value, requires the shortest harsh event to last at least 500 milliseconds, and writes a single record only when an event runs longer than one second. It also gates detection by speed: acceleration and braking are only evaluated at or above 10 km/h, and cornering only at or above 30 km/h. Those gates exist because a pothole strike at low speed reads like harsh braking to a raw sensor. The practical consequence is that your event count is already the output of a filter chain, not a raw physical record, and two fleets running different filter settings cannot compare their event counts to each other at all.
04Where the number comes from changes what it means
The same event can be computed from two different instruments, and they are not equivalent. Teltonika's green-driving feature offers four selectable data sources, GNSS, accelerometer, and an algorithm variant of each. With the GNSS source, the device derives acceleration from the change in position over time, and Teltonika's own documentation states its duration accuracy is resolved to the second, coarser than the accelerometer, which reads motion directly at the sensor. Wialon ranks these approaches explicitly: device-calculated eco-driving parameters are high accuracy, raw per-axis values are average, and GPS-only calculation without an accelerometer is low accuracy. If a supplier tells you their scoring is accurate without saying which source produced it, that is an incomplete answer, and the difference between the best and worst option is not marginal.
05Calibration is a prerequisite, not a refinement
An accelerometer reports acceleration along its own axes, which means the device must first learn how it is oriented in the vehicle. Teltonika's procedure is concrete: stop the vehicle on a straight road, send an auto-calibration command, then accelerate above 30 km/h for five seconds; the result is written to internal flash and survives a reset. After calibration the axis convention is fixed, X forward, Y left, Z down, and forward motion produces negative values, so acceleration reads as negative X and braking as positive X. Advanced detection will not run at all without a non-empty calibration. Wialon states a related tolerance directly: even with correct calibration, readings from the built-in accelerometer will not differ from the vehicle's true acceleration by more than about 15%, and that gap widens if calibration is skipped or done on a curved road. This matters for a fleet because an uncalibrated or re-mounted device does not fail loudly, it reports events with the wrong axis attribution, and those events look exactly as legitimate as any other in the report.
06Why raw event counts rank the wrong drivers
A raw count of harsh events is a measure of exposure before it is a measure of behaviour. A driver who covers 3,000 km in a month has far more opportunity to cross a threshold than one who covers 800 km, and will top the list even if the second driver is more aggressive per kilometre. The fix is normalisation: express events per 100 km, or per driving hour, before comparing anyone to anyone. Distance and time give different pictures, a driver stuck in stop-start city traffic accumulates driving hours without covering much distance, so a per-hour figure can flatter a genuinely harsh driver in slow traffic while a per-kilometre figure would not. Wialon's own scoring model converts penalty points onto a bounded ten-point assessment scale rather than reporting counts, which is the same instinct applied at the platform level. Any report that ranks drivers by absolute event count is ranking them by how much work they were assigned, and a fleet that acts on it is disciplining its busiest people.
07Route and duty type are the largest confounders
Two drivers doing genuinely different jobs cannot be compared on one scale, however the score is normalised. A distribution driver working Riyadh city centre faces junctions, merges and constant speed changes; a driver on a Dammam–Riyadh highway run faces almost none of that. A site vehicle on unpaved ground triggers vertical and lateral accelerations that have nothing to do with pedal discipline, and Wialon excludes the Z axis from driver-behaviour calculation entirely for that reason, using X for acceleration and braking and Y for turns. Grouping matters more than the score itself: compare urban drivers to urban drivers, highway to highway, site to site. A single fleet-wide league table silently makes route assignment the strongest predictor of a driver's rank.
08The first-week problem
The most damaging thing a fleet can do with a new scoring system is publish a ranking from it immediately. In week one nobody knows what a normal event rate looks like for these vehicles on these routes, so the thresholds are still whatever the device shipped with, the calibration may be fresh, and the route mix has not been characterised. A ranking produced under those conditions is close to arbitrary, and it is read by drivers as a permanent judgement. The cost is not only unfairness; it is the loss of the programme itself. Once drivers conclude the score is a punishment lottery, they stop treating any of its output as information, and the coaching value the system was bought for never arrives.
09Establishing a baseline before anyone is ranked
The alternative is to spend the first period measuring the fleet rather than judging it. Run the system with defaults, collect events for several weeks, and look at the distribution by route type and vehicle class rather than by driver name. Two things emerge. First, the real spread of event rates for your operation, which tells you whether the shipped thresholds are producing useful signal or noise, thresholds are adjustable from 0.5 to 10 m/s² for exactly this reason. Second, the outliers that survive normalisation and grouping, which are the genuine findings. A driver who is still an outlier after you have controlled for distance, route and vehicle is worth a conversation, and that conversation can be evidenced rather than asserted.
10Cornering: the noisiest of the three signals
Cornering deserves separate treatment because it is the least reliable of the three criteria and the most likely to generate disputes. It has the highest default threshold of the three at 3.4 m/s², it is only evaluated above 30 km/h, and it depends on a data element the other two do not need: without a heading value, turn-type criteria cannot detect a violation at all. Lateral acceleration is also the signal most affected by road geometry, a tight roundabout, a sharp site entrance or a highway off-ramp produce it by design, not by driver error. Treating cornering events as a lower-weight input than braking, or reviewing them against the map before raising them with anyone, avoids the most common false accusation in behaviour scoring.
11Crash detection is a different mechanism entirely
Crash detection sits alongside harsh-event scoring and should never be conflated with it. It uses the same accelerometer but a different purpose and a different data product: on an FMC920 the crash trace can capture acceleration for up to 15 seconds before and 15 seconds after the event, and GNSS and I/O data for up to 30 seconds either side. That is an evidence capture designed for reconstructing an incident, not a coaching input. The distinction matters commercially too. A crash trace is the kind of record that answers an insurer or a liability question, and it retains value whether or not the fleet runs a behaviour programme at all. Specifying the two separately keeps a safety-critical function from being switched off along with a scoring feature drivers disliked.
12What to do with a score once you have one
A score earns its cost only inside a loop that changes something. The loop that works is narrow: identify a driver who is a genuine outlier after normalisation and grouping, look at the specific events with their locations and times, discuss those specific events with the driver, and re-measure the same driver on the same route type a month later. Wialon states the limit of the instrument precisely, it detects violations against configured criteria and enables comparative assessment between units or drivers, rather than providing an absolute measure. Its own driving-quality model reflects the same restraint: seven criteria, speeding, acceleration, braking, cornering, reckless driving, idling and custom parameters, feed a penalty count that converts to a bounded ten-point scale, running from 10.0 at zero penalties down to 1.0–2.0 once penalties pass roughly a thousand. Comparative and coachable is exactly the right claim. Everything a fleet gains from behaviour data comes from that narrow loop; nothing comes from the league table, and the league table is what most deployments produce instead.
13Where ENTEK.AI stands on driver behaviour scoring
ENTEK.AI does not score drivers today. The Fleet solution shows each vehicle as moving, idling, parked or offline, with route playback and fuel data, but harsh-event scoring is not part of it, and we would rather say that than imply a feature that does not exist. The method in this article is general guidance for any scoring tool you evaluate: treat behaviour data as a coaching input with a stated limit rather than a performance verdict, and accept a score only when it can be traced back to the threshold that produced it and the source that computed it, because a score a driver cannot interrogate is a score no supervisor should act on.
| Input | Accuracy per Wialon | Good for | Cannot support |
|---|---|---|---|
| Device-calculated eco parameters | High | Comparing drivers on the same route type | An absolute safety rating |
| Raw per-axis accelerometer values | Average | Investigating a specific event | Fleet-wide ranking without normalisation |
| GPS-only calculation (no accelerometer) | Low | A rough trend over months | Any individual accusation |
| Raw event count, un-normalised | Not a measure of behaviour | Nothing on its own | Comparing drivers with different mileage |
| Crash trace | Evidence capture, not scoring | Reconstructing an incident | Routine coaching input |
Teltonika FMC650 default harsh-event thresholds
Teltonika Wiki, FMC650 Parameter list (parameter IDs 11004, 11005 and 11006)
Figures and sources
- Teltonika FMC650 harsh-event thresholds are configured in: m/s² (Source: Teltonika Wiki, FMC650 Features settings (Green Driving), as of 2026-08-31)
- FMC650 default Max Acceleration threshold (parameter ID 11004): 2.2 m/s² (range 0.5–10) (Source: Teltonika Wiki, FMC650 Parameter list, as of 2026-08-31)
- FMC650 default Max Braking threshold (parameter ID 11005): 2.5 m/s² (range 0.5–10) (Source: Teltonika Wiki, FMC650 Parameter list, as of 2026-08-31)
- FMC650 default Max Cornering threshold (parameter ID 11006): 3.4 m/s² (range 0.5–10) (Source: Teltonika Wiki, FMC650 Parameter list, as of 2026-08-31)
- Selectable green-driving data sources on the FMC650: GNSS, Accelerometer, GNSS Algorithm A1, Accelerometer Algorithm A1 (Source: Teltonika Wiki, FMC650 Features settings (Green Driving), as of 2026-08-31)
- Minimum speed at which acceleration and braking events are evaluated: 10 km/h (cornering: 30 km/h) (Source: Teltonika Telematics Wiki, Simple Eco Driving (FMB920/FMC920 firmware family), as of 2026-08-31)
- Minimum duration for a harsh event to be accepted, and to be recorded: 500 ms to accept; >1 s to write a record (Source: Teltonika Telematics Wiki, Simple Eco Driving (FMB920/FMC920 firmware family), as of 2026-08-31)
- GNSS-source duration accuracy when GPS is selected as the eco-driving data source: accuracy to the second (1 s resolution) (Source: Teltonika Telematics Wiki, FMC920 Features settings (GPS Source), as of 2026-08-31)
- Accelerometer auto-calibration procedure required before advanced detection runs: stopped on a straight road, then >30 km/h for 5 s (Source: Teltonika Wiki, FMC650 Features settings (Auto calibration), as of 2026-08-31)
- Vehicle and road variables Wialon states affect the acceleration reading: engine power, vehicle condition, weight, body load, tyre grip, road surface, weather (Source: Wialon Help Center, Eco driving control (recommended criteria values), as of 2026-08-31)
- Wialon's stated position on published threshold standards: no generally recommended standards exist (Source: Wialon Help Center, Eco driving control (recommended criteria values), as of 2026-08-31)
- Wialon accuracy ranking of the three driver-behaviour data approaches: device-calculated = high; raw per-axis = average; GPS-only = low (Source: Wialon Help Center, Eco driving control, as of 2026-08-31)
- Accelerometer axis Wialon excludes from driver-behaviour calculation: Z (vertical), X is acceleration/braking, Y is turns (Source: Wialon Help Center, Eco driving control, as of 2026-08-31)
- Data element without which cornering violations cannot be detected at all: course (heading) (Source: Wialon Help Center, Eco driving control, as of 2026-08-31)
- Crash trace capture window on the FMC920: acceleration ±15 s; GNSS and I/O ±30 s (Source: Teltonika Wiki, FMC920 Accelerometer Features settings (Crash Detection), as of 2026-08-31)
- FMC650 GNSS position accuracy, which locates each event: < 2.5 m CEP (Source: Teltonika Wiki, FMC650 General description, as of 2026-08-31)
- Ignition sources selectable on the FMC920, which gate eco-driving evaluation: DIN1, Power Voltage, Engine RPM (OBD II/CAN), Accelerometer (Source: Teltonika Wiki, FMC920 System settings (Ignition Source), as of 2026-08-31)
Questions
What threshold values should we use for harsh braking?
There is no published answer, and Wialon says so directly: no generally recommended standards exist, because acceleration depends on vehicle weight, load, tyre grip, road surface and weather. Start from the device defaults, 2.2, 2.5 and 3.4 m/s² on an FMC650, measure your own distribution for a few weeks, then adjust.
Can we rank drivers by their event count?
Not fairly. A raw count measures exposure first: whoever drives the most kilometres has the most chances to cross a threshold. Normalise to events per 100 km or per driving hour, and compare only drivers doing the same kind of work, urban with urban, highway with highway.
Why do site vehicles generate so many events?
Because unpaved ground produces accelerations the sensor cannot attribute to a driver. Devices filter for this, a minimum 500 ms duration and speed gates of 10 and 30 km/h, but filtering reduces the noise rather than removing it. Site vehicles need their own comparison group and usually their own thresholds.
Does a behaviour score prove a driver was at fault in an incident?
No. Wialon describes the instrument as detecting violations against configured criteria and enabling comparative assessment, not as an absolute measure. For an incident you want the crash trace, which captures acceleration for 15 seconds either side and GNSS and I/O data for 30, a different mechanism built for that question.