Input Smoothing vs Alert Delay: Why They Are Not the Same

Short answer

A smoothing filter replaces each raw reading with an average of recent readings, so the number your logic evaluates is no longer the number the sensor measured. A delay leaves the value alone and only changes when the logic may act. Teltonika warns explicitly that its averaging constant is a filter, not a timer.

Key takeaways

Teltonika states the distinction in its own documentation: "Average Constant is not used as an activation timer or delay timer. But it is used as a filter."
The device samples internally every 40 ms, which is 25 samples per second, and an averaging constant of 10 corresponds to roughly one second of persistence.
A filter rewrites the value that gets stored and reported, so a report that was correct before smoothing can become wrong afterwards without any alert changing.
A delay leaves the value intact and only gates when logic may act, which is why smoothing and debounce are not interchangeable cures for the same noise.
Teltonika warns about its own cure: setting the averaging constant too high delays the response to real changes in fuel consumption.

01Two cures that look identical from the dashboard

An operator with a noisy alert has two settings within reach that both appear to work. Raise the averaging constant and the alert quietens. Raise the debounce timer and the alert quietens too. From the notification list the outcome looks the same, so the choice feels arbitrary and people pick whichever field they understood first. The two cures are not equivalent, and the difference is not subtle once you look past the alert. Smoothing operates on the measurement itself: it substitutes a computed average for the raw reading before any rule sees it. Debounce operates on the rule: it leaves the reading exactly as measured and only constrains when a state change is allowed. One rewrites the data, the other rewrites the logic, and only one of them silently changes every report built on that channel.

02What the manufacturer actually says

This is not an interpretation imposed from outside. Teltonika addresses the confusion directly in its input-output documentation, in a sentence worth quoting because it forecloses the argument: "Average Constant is not used as an activation timer or delay timer. But it is used as a filter." A vendor does not write a warning like that unless the mistake is common enough to generate support tickets, which tells you something about how often the two settings get swapped. The documentation also gives the mechanics that make the statement concrete. The device samples internally every 40 milliseconds, which is 25 samples per second, and an averaging constant of 10 corresponds to roughly one second of persistence. Those numbers describe how much history is being folded into each reported value, not how long anything waits.

03A filter changes the number that gets stored

Here is the consequence that matters most and gets noticed least. Once a channel is smoothed, the value that reaches the database is the average, not the measurement. Every downstream consumer of that column inherits the filter whether it wanted it or not: the alert rule, the chart, the monthly report, the export to the customer, the threshold comparison someone wrote last year. A peak-detection report is the clearest casualty, because averaging is precisely the operation that removes peaks. A report that correctly showed a maximum analog reading of a certain magnitude will, after smoothing is enabled, show a lower maximum for identical physical behaviour. Nothing in the alert configuration changed and no error was logged. The number simply means something different now, and the change is retroactively invisible.

04A delay leaves the number alone

A debounce or activation timer has the opposite property, and it is a genuinely useful one. The stored value remains whatever the sensor reported; only the state machine is constrained. If a channel is debounced and you later decide the timer was wrong, you can re-derive the correct events from the retained raw values because the raw values were never modified. If a channel was smoothed and you later decide the constant was wrong, you cannot recover the original readings from the averaged ones, because averaging discards information irreversibly. That asymmetry is the strongest practical argument for reaching for the timer first. A timing rule is a reversible decision recorded in configuration; a filter is an irreversible transformation applied to your measurements before they were ever written down.

05When smoothing is the right answer anyway

None of this makes filters wrong. Some signals are physically noisy in a way that no timing rule can address, and fuel level is the standard example: the liquid genuinely sloshes, so the sensor genuinely reports a changing level while the tank contents are constant. Teltonika publishes guidance for exactly this case, recommending an averaging constant of 2,500 to 5,000 for moderate instability and 6,000 or above for very unstable signals. Those are large numbers precisely because the noise is large and real. The test for whether a filter is appropriate is whether the raw reading is a faithful measurement of a quantity you care about. Slosh is not, the level you want is the settled level. In that situation the average is closer to the truth than the sample, and filtering improves the data rather than degrading it.

06The cost the vendor admits to

Teltonika is unusually candid about the downside of its own recommendation, and the warning deserves reading alongside the guidance rather than after it. The documentation notes that setting the averaging constant too high could delay the response to real changes in fuel consumption. This is the trade nobody escapes: a filter that removes noise of a given magnitude also removes genuine change of that magnitude, because the filter has no way to distinguish them. A theft that draws off a modest volume slowly produces the same signal shape as slosh, so a constant tuned to erase slosh will erase the theft too. There is no setting that keeps one and drops the other. Recognising that is what turns a filter from a fix into an engineering decision with a stated cost.

07A working rule for which knob to turn

Start by asking what the raw reading actually is. If it is a faithful measurement and the problem is that your rule reacts to brief excursions, use a timing primitive and leave the data intact. If the raw reading is not a faithful measurement of the quantity you want, because the physical medium is in motion, then filter, and record the constant in the vehicle record so the numbers stay interpretable. Our catalogue Teltonika FMC003 lists one analog input rated 0 to 30 V, an RS-232 port that connects directly to a fuel sensor, and 1-Wire, and each of those is a channel where the choice arises separately. The one thing never to do is enable smoothing to fix an alert and then keep reporting from the same column as though nothing happened, because that is how a correct report quietly becomes a wrong one.

A filter and a delay, compared on what each one actually touches
Property	Smoothing filter (averaging constant)	Timing rule (debounce / activation delay)
Acts on	The measured value, before any rule	The state transition, after the value
Stored number	Rewritten as an average	Unchanged
Reversible later	No, averaging discards information	Yes, re-derive from retained raw values
Effect on peak reports	Peaks flattened	Peaks intact
Right for slosh in a fuel tank	Yes, the settled level is the truth	No, the signal is genuinely changing
Right for a rule reacting to brief excursions	No, degrades the data to fix the rule	Yes, the intended tool

Figures and sources

Manufacturer warning distinguishing an input filter from an alert debounce timer: "Average Constant is not used as an activation timer or delay timer. But it is used as a filter." (Source: Teltonika Telematics Wiki, FMB920 I/O settings, as of 2026-08-31)
Averaging-constant sampling behaviour, in samples per second and persistence time: internal sampling every 40 ms (25 samples/second); Avg Const 10 ≈ 1 second persistence (Source: Teltonika Telematics Wiki, FMB920 I/O settings, as of 2026-08-31)
Teltonika recommended smoothing constants for a genuinely unstable physical signal: Averaging Const 2,500–5,000 moderate; 6,000+ for very unstable signals (Source: Teltonika Telematics Wiki, How to Fix Fuel Level Jumps in CAN or OBD Data, as of 2026-08-31)
Teltonika warning that its own smoothing cure delays detection of genuine fuel change: "setting it too high could delay the response to real changes in fuel consumption" (Source: Teltonika Telematics Wiki, How to Fix Fuel Level Jumps in CAN or OBD Data, as of 2026-08-31)
The timing primitive that leaves the stored value untouched, for contrast: Parameter 11205 "Time to stopped": default 5 s, range 0–3,600 s (Source: Teltonika Telematics Wiki, FMB120 Parameter list, as of 2026-08-31)
Granularity at which movement state is available, versus the smoothed analogue level: movement criteria checked every second (Source: Teltonika Telematics Wiki, FMB120 Data acquisition settings, as of 2026-08-31)
Teltonika FMC003 analogue and serial channels where the filter-or-timer choice arises, per our catalogue: 1 analog input (0–30 V), 1× RS-232, 1-Wire (Source: ENTEK.AI product catalogue, as of 2026-08-31)
Teltonika FMC003 fuel-sensor connection our catalogue lists, the classic smoothing case: RS-232 connects directly to OMNICOMM fuel sensors (Source: ENTEK.AI product catalogue, as of 2026-08-31)

Questions

Can I use the averaging constant as an alert delay?

No, and Teltonika says so in its own documentation: "Average Constant is not used as an activation timer or delay timer. But it is used as a filter." It changes the value your logic evaluates rather than when the logic may act.

How much history does an averaging constant of 10 represent?

Roughly one second. The device samples internally every 40 milliseconds, which is 25 samples per second, so a constant of 10 corresponds to about one second of persistence folded into each reported value.

Why does smoothing break reports that were correct?

Because the value stored in the database becomes the average, not the measurement, and every consumer of that column inherits the filter. Peak-detection reports suffer most, since averaging is exactly the operation that removes peaks, the report shows a lower maximum for identical physical behaviour.

Is smoothing ever the right choice?

Yes, when the raw reading is not a faithful measurement of what you want. Fuel level is the standard case, because the liquid sloshes while the contents are constant. Teltonika recommends an averaging constant of 2,500 to 5,000 for moderate instability and 6,000 or above for very unstable signals.

What does a high averaging constant cost me?

Detection of real change at the same magnitude as the noise. Teltonika warns that setting it too high could delay the response to real changes in fuel consumption. A slow modest drawdown has the same signal shape as slosh, so no constant keeps one and drops the other.

Input Smoothing Is Not Alert Delay: A Filter Changes the Value, Not the Timing