RS-485¶

This draft teaches RS-485 as electrical and timing evidence, not as an application protocol.

Status	Examples	Runtime example	Source posture
`draft-core-lab`	`synthetic/passive`	`not yet available`	standards metadata plus tooling context

Draft status

draft-core-lab: this page is in Core Lab scope but is not yet promoted to final copy. It has a useful electrical inspection boundary; it still needs a stronger waveform/line-state artifact and reviewer-validated ambiguity case before final-copy status.

A Concrete Artifact¶

# synthetic RS-485 observation shape
t=0.000 ms  driver A burst:  11 03 00 6b 00 03 76 87
t=3.700 ms  silent gap
t=7.100 ms  driver B burst:  11 03 06 02 2b 00 00 00 64 c8 ba

Synthetic

Synthetic offline sample for explanation; not a real operational trace or live-system instruction.

Inspection Trap¶

RS-485 is often treated as shorthand for Modbus RTU or another byte protocol. That is a category error. RS-485 tells you about a balanced multipoint electrical interface and driver-enable timing. It does not define addresses, registers, commands, checksums, or application meaning.

The safer claim is electrical: a passive observer can describe bursts, silence gaps, direction changes, possible contention, and the need for a carried protocol before interpreting bytes.

Worked Decode¶

The alternating bursts suggest half-duplex driver-enable behavior.
The silence gaps may be frame boundaries, turnaround time, or capture artifacts.
The bytes look Modbus-RTU-shaped in this teaching artifact, but RS-485 alone does not define Modbus addressing or register meaning.
A passive observer should first separate electrical evidence from the carried byte protocol.
Final-copy promotion needs a stronger waveform or line-state artifact so the page can teach RS-485-specific ambiguity rather than leaning on Modbus bytes.

What The Evidence Supports¶

The artifact supports a draft electrical claim: the observed record has two bursts separated by silence on a half-duplex-looking multipoint link. It also supports a next-step question: which byte protocol, if any, explains the burst content and timing?

What The Evidence Does Not Support¶

The artifact does not prove Modbus RTU, node identity, register meaning, bus health, termination quality, biasing correctness, or application state. It also does not prove which device controlled driver-enable without additional capture context.

Field Layout / Anatomy¶

Element	Shape	Inspection meaning
Differential pair	balanced multipoint medium	Electrical layer evidence.
Termination/biasing	installation design	Idle-state and reflection context, not app meaning.
Driver enable	timing control	Determines which transceiver may drive the pair.
Silence gap	timing evidence	May bound frames for a carried byte protocol.
Carried protocol	external byte interpretation	Defines addresses, checksums, and payload meaning.

Visual Model¶

flowchart LR master["Device A"] --- bus[("RS-485 pair")] slave1["Device B"] --- bus slave2["Device C"] --- bus observer["Offline captured evidence"] -. inspected as .-> bus bus --> evidence["bursts, gaps, direction, contention"] evidence --> protocol["carried byte protocol?"]

Timing And Authority¶

RS-485 timing evidence often comes from driver-enable discipline and silence gaps. A carried protocol such as Modbus RTU may define address fields and frame boundaries, but that authority is above RS-485.

Semantic authority

RS-485 electrical evidence does not name registers, commands, or engineering values. Semantic authority comes from the carried protocol and its source context.

Failure And Ambiguity¶

Treating every RS-485 burst as Modbus RTU hides proprietary or alternate byte protocols.
Contention can look like noise, framing errors, or corrupt bytes.
Idle biasing problems can create phantom starts.
Gateway buffering can hide true line timing.
Without waveform or line-state evidence, termination and biasing claims remain limited.

Python Model¶

No current runtime example is claimed for this draft page. Keep reader claims at the artifact and source level until a separate implementation plan adds a tested model.

Source Notes¶

Teaching claim	Source role	Limit
RS-485 is an electrical interface, not an app protocol.	canonical metadata	Not a reproduced TIA electrical specification.
Burst/gap timing can suggest half-duplex behavior.	synthetic teaching artifact	Needs stronger waveform evidence before final-copy.
PySerial is serial tooling context.	tooling reference	It does not make RS-485 a particular application layer.
Modbus-shaped bytes require Modbus authority.	schoolbus governance/source policy	The page does not decode registers here.

Field	Value
Governance tier	Tier 1 Core Lab
Canonical source status	yes
Public explainer status	no
Open-source tool status	yes
Sample-data status	none listed; use synthetic teaching artifacts
Confidence	medium
Citation specificity	document-metadata-level

References¶

Public Sources¶

TIA
TIA-485 balanced digital multipoint systems
- standards-body metadata.
Tooling references
pyserial - serial-port tooling context.

Project posture is aggregated in the protocol support policy, source policy, and project charter.

Simplification

The burst record is synthetic. The page omits line voltage thresholds, termination design, cable-length limits, common-mode behavior, isolation, surge protection, and installation guidance.