RS-485 Local Echo: Keep a Transmitted Request from Becoming Its Own Response
Determine whether the serial interface returns locally transmitted bytes before using received bytes as evidence of a peer response. Some Modbus operations have normal responses identical to their requests, so byte equality and a valid checksum cannot distinguish local echo from a real reply. Echo handling needs a qualified interface contract, not a rule that drops every packet matching the last transmission.
This guide pins Linux 6.12 RS-485 serial interfaces and Modbus Application Protocol V1.1b3. It targets a known half-duplex adapter and driver path. Only an original offline byte-identity fixture was executed; no UART, ioctl, transceiver or timing measurement was performed.
Locate the source of the returned bytes
Record the adapter model, hardware revision, driver, kernel build and receive-enable wiring. Determine whether receive remains active during transmission and whether the adapter or driver removes local echo before userspace sees it. Separate bytes at the UART receiver from bytes delivered by the host API.
Linux exposes SER_RS485_RX_DURING_TX for receiving while sending on supported hardware. The serial core sanitizes requested settings against driver capabilities; TIOCGRS485 reports the accepted configuration. Readback is useful evidence of the requested operating mode, but it does not prove that a particular board delivers exactly one copy of every transmitted byte.
Do not interpret the flag as a universal “strip echo” control. A USB adapter may have its own automatic direction or echo behavior, and some paths do not implement these ioctls. Qualify the actual combination rather than substituting a generic Linux setting for hardware evidence.

Prove why content-only filtering fails
Section 6.6 defines a normal Write Single Register response as an echo of the request after the register is written. For an invented offline operation, the request PDU 06 00 20 12 34 and normal response PDU are identical. The example is not a command to send to equipment.
If the local receive path returns that transmitted request while no peer responds, a parser looking only for the expected function, address and value can falsely report success. Conversely, dropping every matching frame would discard the legitimate normal response as well.
The original fixture compared two streams: echo followed by response, and response alone. Removing exactly one request-sized prefix worked only for the declared echo-enabled stream. Applying that policy to an echo-disabled stream swallowed the real response. Treating every copy as a response accepted an echo-only stream. These are byte-level counterexamples, not measured adapter behavior.
Choose one supported receive contract
| Qualified path | Transaction handling | Critical assumption |
|---|---|---|
| Echo disabled or removed below the parser | Validate received peer candidates normally | Local transmission is not delivered as a response candidate |
| Exactly one ordered local echo | Consume the qualified echo before admitting the peer response | Complete echo precedes peer bytes without loss or ambiguity |
| Variable, missing or indistinguishable echo | Hold origin-dependent success claims | A stronger interface or separate completion evidence is required |
Prefer disabling local echo through a supported, verified path when the application does not need it. If echo is retained for diagnostics, give it a separate bounded state and preserve its comparison result without delivering it to the response decoder.
A fixed-length discard is not safe when the promised echo may disappear. For a byte-identical response, no content-only algorithm can discover that the first matching copy was the peer rather than the missing echo. Where that ambiguity is unacceptable, change the qualified interface or obtain an independent device-completion observation.
Define the echo-enabled state transitions
Before transmitting, retain an immutable copy of the exact bytes expected to echo and assign a transaction generation. Track how many expected echo bytes have been observed. Support partial delivery without assuming one read call equals one frame.
Compare only under the qualified provenance and ordering contract. A mismatch, overrun or unexpected timing condition invalidates that transaction’s echo assumption; do not keep searching indefinitely for a matching prefix. Bound retained bytes and the decision deadline.
Once the complete qualified echo is consumed, preserve any remaining bytes from the same read call for the response path. A single host read can contain both delayed echo and a fast peer response. Flushing the entire receive buffer at transmit completion can therefore erase legitimate data.
On timeout, cancellation or reconnect of an adapter path, invalidate the old transaction generation and reconcile buffered bytes through the documented recovery procedure. Old echo must not satisfy the next request’s prefix just because the application repeats the same operation.
Measure origin and delivery separately
On an isolated bench, use a harmless documented read request or a simulator. Capture local transmit data, receive data where available, driver-enable state and the peer’s activity with equipment appropriate to the electrical and isolation arrangement. Do not defeat an isolation barrier with an unsuitable grounded probe.
First run with the peer intentionally not responding through an approved lab setup. Any received request copy then exposes the local path without relying on payload interpretation. Repeat with the peer responding, including the fastest supported response and delayed host reads.
Application timestamps show when software handled data, not necessarily when the UART received it. A delayed echo can appear after the write call returns, so “received after write” is not enough to classify it as a reply. Correlate host delivery with the physical trace and the driver’s documented buffering behavior.
Acceptance cases
- Echo enabled and disabled, with accepted settings recorded independently
- No peer response: local echo must not complete the operation
- Partial echo and echo-plus-response delivered in one host read
- Echo mismatch, missing bytes, overrun and bounded timeout handling
- Repeated identical requests across transaction generations
- Offline byte-identical normal-response fixtures without actuating hardware
The release artifact is an explicit TX/echo/RX contract tied to the adapter and driver versions. If the interface cannot reliably separate local transmission from the response needed for a consequential operation, report that limitation. A valid frame is useful protocol evidence only after its origin and transaction association are established.