Skip to content
Sign inGet Started

False Alarms Are a Two-Layer Problem: The Debounce Settings Already in Your Devices

By Saeed Baatiah · Published:

Short answer

Most false alarms are fixable in two places that already ship the tools. At the device, Teltonika provides asymmetric enter and exit delays, minimum event durations, and a dual-threshold hysteresis operand. At the platform, a geofence must be sized for real multipath error, over 50 metres in urban canyons, not the 2-metre signal specification.

Key takeaways

  • Teltonika ships asymmetric debounce by default: Time to stopped is 5 seconds while Time to moving is 2.
  • The Unplug Delay discards the event entirely if the state keeps changing during the delay period, persistence, not just a timer.
  • Teltonika warns explicitly that its averaging constant is a filter and "is not used as an activation timer or delay timer".
  • The 2-metre GPS accuracy figure is a signal-in-space commitment that excludes multipath; peer-reviewed work measures over 50 metres of error in deep urban canyons.
  • The often-quoted "150 alarms per operator per day" was removed from ISA-18.2 in its 2016 revision.

01Two layers, each with a tool already in it

A flood of false alerts is usually treated as a platform problem to be solved with better rules, and that diagnosis is half right. False alarms arise in two distinct layers, and each layer already ships primitives designed for exactly this, which most installations leave at their defaults. The device layer decides whether an event is generated at all, and carries timers, minimum durations and hysteresis operands for that purpose. The platform layer decides whether a generated event deserves a person's attention, and its hardest problem is not logic but position uncertainty. Fixing one layer while ignoring the other produces the familiar pattern where a team writes increasingly elaborate server-side suppression rules to compensate for a device that is generating events it was configured to suppress. Reading what the device already offers is cheaper than any rule written above it.

02Asymmetric delays, and why they are asymmetric

Teltonika's Excessive Idling scenario is a clean example of a debounce that is deliberately not symmetric. Parameter 11205, Time to stopped, defaults to 5 seconds with a configurable range of 0 to 3,600. Parameter 11206, Time to moving, defaults to 2 seconds over the same range. The documented behaviour explains the asymmetry: the vehicle enters the idling state only if detected speed stays below the configured start-speed threshold for the whole Time to stopped timeout, and leaves only when the exit condition holds for the Time to moving timeout. Entering a state is made harder than leaving it, which biases the logic against generating an event at all, the right bias for anything that will page a human. Copying the entry delay into the exit delay, a common tidy-up, removes that bias and reintroduces flapping at the boundary.

03Persistence is stronger than a timer

There is a stronger primitive than a delay, and Teltonika implements it for unplug detection. The Unplug Delay parameter generates a record only if the unplug event is detected and persists for the delay period, and, this is the important clause, if the unplug state keeps changing during the delay period, the unplug event is ignored entirely. A plain delay merely postpones the decision and then fires on whatever the state happens to be at the end. A persistence rule requires stability throughout the window and discards the event when the signal is unstable, which is exactly the right treatment for a loose connector or an intermittent contact: the flapping itself is the evidence that this is not a real unplug. Any alert whose underlying signal can chatter deserves this shape rather than a delay, and the distinction is worth checking wherever a platform offers both.

04The minimum-duration gate

A third primitive requires the triggering condition to hold long enough to be real, and its defaults show how much the appropriate value varies by event type. Teltonika's towing Duration parameter sets the minimal period for which acceleration and angle values must exceed the threshold before an event triggers, defaulting to 1,000 milliseconds with a range of 1 to 5,000. The crash-detection equivalent defaults to just 5 milliseconds with a range of 0 to 1,000 and a 1,500 mG threshold, three orders of magnitude shorter, because a genuine collision is a very short, very large event and waiting a second would miss it. The lesson is that a single organisational default for event duration is wrong by construction. There is also a separate Event Timeout on towing, documented as filtering out redundant events and delaying the ignition check so movement during that window is ignored.

05A real hysteresis band, not one threshold

For any alert driven by a measured value hovering near a setpoint, no delay length solves the underlying problem, because the value genuinely does cross the threshold repeatedly. Teltonika exposes the structural fix as an input operand: with On Hysteresis, a record is generated when the input value crosses the high limit having come from below the low limit, or the reverse. Two thresholds define a band, and the signal must traverse the whole band to produce another event, which makes chattering on a value sitting at one setpoint impossible rather than merely unlikely. Two related scenarios are latched by the same principle: Green Driving stays active until the measured acceleration, braking or cornering value decreases below the set parameter, and Over Speeding stays active until speed drops below the configured limit, so one excursion yields one event.

06The misconfiguration the manufacturer warns about

One mistake is common enough that Teltonika documents a warning against it in capitals. The averaging constant is an exponential input filter with documented sampling behaviour: internal sampling happens every 40 milliseconds, so 25 samples are taken per second, and an Avg Const of 10 means a new value must be present for one second to register the change. That looks exactly like a debounce timer, and it is not one. The wiki states plainly that Average Constant is not used as an activation timer or delay timer, but is used as a filter. The difference is real: a filter changes the value the logic evaluates, while a delay changes when the logic is allowed to act on it. Raising the averaging constant to suppress alerts degrades the measurement everything else depends on, including reports and thresholds that were correct.

07The GPS number everyone designs against is the wrong one

The platform layer's hardest false-alarm source is the geofence, and it is mis-sized because the accuracy figure in circulation does not mean what it appears to mean. GPS.gov commits to broadcasting the GPS signal in space with a daily global average user range error of 2.0 metres or better at 95 percent probability, and reports a measured 0.643 metres on one date. That is a signal-in-space commitment. The same page states that the accuracy a receiver actually achieves depends on satellite geometry, that user range error, and local factors including signal blockage by buildings, bridges and trees, multipath reflection off buildings or walls, atmospheric conditions, and receiver quality. The 2-metre figure therefore excludes, by definition, the precise mechanisms that push a vehicle across a fence line it never crossed.

08How large the real error gets

Peer-reviewed measurement gives the magnitude, and it is not a small correction to the specification. Work published in IEEE Sensors Journal on GNSS positioning in urban canyons reports that reflection errors are common in deep urban canyons and result in extra travelling distance for the signal, introducing positioning error of more than 50 metres. In Hong Kong experiments even a 3D-mapping-aided correction method achieved around 15 metres of two-dimensional average accuracy. The same paper notes that conventional receiver-side mitigation has less capability against non-line-of-sight reception, potentially leaving several tens of metres of error. Two conclusions follow directly. A geofence buffer sized on the 2-metre figure is wrong by more than an order of magnitude in exactly the dense environments where depots and yards sit. And no hardware upgrade fixes it, because the error arises outside the receiver.

09What actually fixes a geofence

Since the error is external, the remedy is logical rather than physical: a buffer sized for realistic error, plus a dwell requirement so a momentary excursion does not qualify as a crossing. Teltonika's AutoGeofence shows both ideas implemented at the device. Its Activation timeout defaults to 5 minutes with a range up to 65,535, delaying geofence creation after ignition off, and the documentation adds a second role: if GNSS fix is achieved the timeout pauses and continues once the conditions are satisfied again, an explicit mechanism preventing a fix loss from being read as an event. Excessive Idling has the equivalent protection, falling back to accelerometer-derived movement when there is no GPS fix, so a tunnel or a covered dock does not register as a stop. Both are examples of the device already handling a failure mode a server rule would handle worse.

10The alarm-rate figure that was withdrawn

Teams setting a target usually reach for a familiar number, and the most familiar one is no longer current. According to an industry paper that cites the standards with page references, ISA-18.2 stated on its 2009 release that about 150 alarms per day would be acceptable as a key performance indicator, and IEC 62682 gave about 144 per day in 2014, but the 2016 revision of ISA-18.2 omitted that indicator, along with others including the percentage of hours containing more than thirty alarms. Quoting 150 per operator per day as a current ISA-18.2 target therefore cites a withdrawn figure. Note also the attribution: ISA-18.2 and EEMUA 191 are paywalled and we did not read them directly, so every figure in this section is attributed to the paper that cites them with page numbers rather than to the standards as if read first-hand.

11The scale that is current, and how to read it

What the same source reports as the live guidance is a four-tier ladder rather than a single number. Citing EEMUA 191 Third Edition page 96, it gives an average of fewer than one alarm per ten minutes in steady state as very likely acceptable, one per five minutes as manageable, one per two minutes as likely over-demanding, and more than one per minute as very likely unacceptable. For the first ten minutes after a major upset, page 97 gives fewer than ten alarms per operator as manageable, twenty to a hundred as hard to cope with, and more than a hundred as excessive and very likely to lead to the operator abandoning the system entirely. Crucially, the source states the ten-minute figure is a per-alarm handling-time budget and cannot be converted to six per hour, and certainly not extrapolated to 144 per day.

12Chattering is its own defect class

The standards treat repeat-flapping alerts as a distinct problem from alarm volume, which validates the device-layer emphasis of this article. The same paper notes that chattering and fleeting alarms, and stale alarms, are listed as their own named performance indicators in table 7 of the standards, partly because they are excluded from average-response-time calculations. That separation is the practical point: a system can sit inside an acceptable average rate while being unusable, because a handful of chattering sources generate most of the volume and train operators to dismiss alerts without reading them. Counting alerts per operator per hour will not surface that; counting distinct sources and their repeat rates will. And the remedy for a chattering source is the hysteresis band or the persistence rule at the device, not a suppression rule at the platform that hides the symptom.

13What ENTEK.AI does not claim here

Three limits belong on the record. The ISA and EEMUA figures above are attributed to the industry paper that cites them with page numbers, because both standards are paywalled and we did not read them; treat them as reported, not as quoted from source. Second, we intended to document a comparable platform-side minimum-duration parameter, and excluded it: every Wialon documentation host failed to resolve during our research, and although search results consistently reported the relevant text, we will not present as verified something we could not read on the page. Third, the alarm-rate guidance is process-industry material and transfers to fleet and asset monitoring by analogy only, we found no citable study establishing an operator alarm-fatigue threshold for telematics specifically, and we would rather say so than borrow a control-room number as if it had been measured on a dispatch desk.

Which primitive fits which false-alarm cause
False-alarm causeWrong fixRight primitiveWhere it lives
Value hovering at a thresholdA longer delayDual-threshold hysteresis bandDevice I/O operand
Intermittent contact or loose wiringA delay that fires anywayPersistence rule that discards on flappingDevice (Unplug Delay)
Very short spurious spikesRaising the averaging constantMinimum event durationDevice (Duration parameter)
State flapping at a boundarySymmetric delaysAsymmetric enter/exit timersDevice (5 s in, 2 s out)
Noisy analog inputA debounce timerThe averaging constant, as a filterDevice (Avg Const)
Geofence edge triggeringA more accurate receiverBuffer sized for multipath, plus dwell timePlatform and device
GNSS fix loss read as an eventA server suppression ruleAccelerometer fallback; timeout pause on fixDevice
Overall alert volumeA per-day alarm targetPer-source repeat rate, chattering as its own KPIPlatform reporting

Teltonika FMB120 default Green Driving thresholds

Acceleration2.5 m/s²
Braking2.7 m/s²
Cornering3.4 m/s²

Teltonika Telematics Wiki, FMB120 Parameter list

Figures and sources

Questions

Should I raise the averaging constant to stop false alerts?

No. Teltonika warns explicitly that the averaging constant is a filter and is not used as an activation or delay timer. A filter changes the value your logic evaluates, degrading reports and thresholds that were correct. Use the minimum-duration or hysteresis parameters for debounce instead.

How wide should a geofence buffer be?

Wider than the 2-metre GPS figure suggests. That figure is a signal-in-space commitment that excludes multipath by definition, and peer-reviewed measurement records errors above 50 metres in deep urban canyons. Size the buffer for the site's real conditions and add a dwell-time requirement so a momentary excursion does not count as a crossing.

Is 150 alarms per operator per day still the ISA-18.2 target?

No. According to an industry paper citing the standards with page references, ISA-18.2 stated about 150 per day in its 2009 release, but the 2016 revision omitted that indicator entirely along with others. Quoting it as current cites a withdrawn figure.

Why do a few alert sources produce most of the noise?

Because chattering is a distinct defect from volume, which is why the standards list chattering, fleeting and stale alarms as their own performance indicators in table 7. A system can sit inside an acceptable average rate while a handful of flapping sources generate most of the traffic and train operators to dismiss alerts unread.

Why are the enter and exit delays different by default?

By design, to bias the logic against generating an event. Teltonika defaults Time to stopped to 5 seconds and Time to moving to 2, making a state harder to enter than to leave. Copying the entry delay into the exit delay removes that bias and reintroduces flapping at the boundary.

Sources

Related insights