Fuel-Sender Refueling Events: Separate Real Level Steps from Slosh Filtering

System boundary

The resistor-card sender, acquisition validity, tank calibration and controller event/display states define the reviewed interface. Refueling recognition and system safety are owned by the complete equipment design.

Integration interfaces

Integration risks

Keep event handling separate from the static calibration curve

Begin with an already defined mapping from sender resistance or voltage to level or volume at a stated tank attitude. A refueling algorithm cannot correct an incorrect float linkage, tank table or electrical scaling. The task here is narrower: decide when a persistent change represents a new operating state rather than a disturbance to be suppressed.

Name the signal used for that decision. A heavily filtered display is a poor sole witness for an event whose recognition the same filter delays. Retain time-stamped raw electrical data, its validity state and the calibrated but unfiltered quantity. Motion, attitude and any available refueling-context signals belong to the controller interface, not to a claimed capability of the printed card.

Quantify the delay that the old filter state creates

For an illustrative first-order display model with time constant 60 seconds, suppose the accepted pre-fill quantity is 15 litres and the newly stabilized true input is 40 litres. After 30 seconds of ordinary filtering, the display is approximately 24.84 litres, still 15.16 litres below the new input. Reaching within one litre takes approximately 193.1 seconds. These assumed values show a state-memory effect; they are not fuel-gauge requirements.

A separate upward rate limit can preserve delay even if the smoother is reset. At an illustrative 0.2 litre per second display limit, a 25-litre rise requires at least 125 seconds. Inventory every stateful block between raw signal and display. Resetting one variable while leaving a downstream limiter initialized to the old level does not produce the intended refueling response.

Require context before accepting a level increase

A rising sender signal can also come from attitude change, fluid movement, a sticking float that releases, a wiring interruption or acquisition recovery. The event decision therefore needs more than a positive slope. Specify the available contextual evidence, such as a stationary operating state, a valid pre-event baseline and a sustained post-event electrical reading under permitted attitude conditions.

No single contextual input is universally available or sufficient. Ignition state alone does not prove that fuel was added, and a stable sender does not prove a level tank. Where context is unavailable, the product owner must define a conservative response and its display consequences. Do not label a threshold or dwell time as universal across tank shapes, sender mechanisms and controller architectures.

Make state transitions and exit conditions explicit

Use a state record that separates observation from acceptance. A candidate event can collect evidence without immediately overwriting the last accepted level. If the evidence becomes invalid, retain that distinction rather than quietly treating a partial sequence as successful refueling.

Measure confirmation time from valid evidence

A confirmation interval should describe elapsed time with acceptable evidence, not merely a count of loop executions. Missing samples, task delays and stale communication values can otherwise make a short or interrupted record appear stable. State whether an interruption restarts the dwell, pauses it or abandons the candidate, and retain the reason in the event log.

Define which value is committed at the end of confirmation: a specified post-event estimator, a bounded sample group or another reviewed quantity. The final sample alone may coincide with residual motion. Keep the commit operation coherent across filter memory, rate-limit state, displayed value and any consumption estimate that uses the fuel baseline. Partial updates can create a jump that is later mistakenly attributed to the resistor card.

Do not accept a clipped signal as a confirmed full tank

The sender may reach a mechanical stop, the acquisition may saturate, or software may clip values to a displayed full limit. Those states have different meanings. A repeated maximum code can look perfectly stable while carrying no information about further level change. Retain unclipped acquisition diagnostics and distinguish a valid full-region reading from an electrical overrange or a frozen communication value.

Open circuits and intermittent wiper contact require an independent validity rule appropriate to the actual excitation and receiver. Depending on the interface, an open can drive the reading high, low or to a plausible biased value. Do not clear an electrical fault simply because an event detector sees a large increase. Likewise, a candidate that ends when the vehicle changes attitude should not automatically establish that the apparent increase was genuine fuel addition.

Verify event logic with labelled signal sequences

Begin controller verification with safe electrical replay or recorded-data replay, using independently labelled sequences. Include a genuine persistent increase, a temporary rise that returns to baseline, a rise followed by contact loss, a missing-data interval, a saturated endpoint and a power interruption during commit. Record the raw input, validity, event state, filter state and final display on the same time base.

Then correlate the selected behaviour with representative system evidence obtained under the equipment owner's approved fuel-handling and test procedures. This page does not prescribe fuel transfer or tank access operations. The replay checks logic consistency; physical validation establishes whether the assumed signal patterns and context actually represent the tank and sender. Neither one alone proves complete gauge accuracy or vehicle safety.

Release the event behaviour as a versioned interface

The acceptance record identifies the baseline rule, candidate evidence, confirmation estimator, elapsed-time handling, commit targets and invalid-state response. Include the expected display trajectory for each labelled sequence, not just the final number. Specify when normal tracking resumes and how a controller restart recovers an interrupted event.

Reopen the review after changing tank calibration, card transfer, sample timing, communication handling or display smoothing. A resistor card with unchanged geometry can appear unresponsive when downstream state handling changes. Keeping the event logic separate from the static curve allows the team to correct the actual cause without reshaping a valid printed track to compensate for stale software memory.