Real Bus Electrical Behavior — Edges, Levels and Level Shifting

Module 2 has built an idealised node: strong switched paths to ground, one weak permanent path to the supply, dominant LOW, and a rising edge that takes time. Every figure so far has drawn levels as clean rectangles because the argument was about mechanism, not about measurement.

A real bus does not look like those figures, and the differences are not cosmetic. This chapter closes the module by putting the model onto a board — which is where an engineer actually meets it, whether reading a capture during bring-up or deciding whether a proposed layout will work.

1. The Shape of a Real Capture

The first thing that strikes anyone looking at an I²C bus on an oscilloscope is that the two edges do not match.

Falling edges are sharp. A device closes its switch, the conductor is connected to ground through a low-impedance path, and the charge stored on the bus leaves quickly. The transition looks much like any driven digital edge.

Rising edges curve. Nothing is driving. The device has released, and the pull-up is charging the bus capacitance through a deliberately weak path. The voltage climbs quickly at first — when the difference between the conductor and the supply is largest, so is the current through the resistor — and then more slowly as it approaches the supply, producing the characteristic curved shoulder.

That asymmetry is the visual signature of Chapter 2.4's central sentence. A falling edge is a device doing something. A rising edge is a device having stopped. Once you have seen it, an I²C capture becomes readable at a glance, and a symmetric capture is a sign that something is not what you think it is — a push-pull output somewhere it should not be, or a probe on the wrong net.

2. What a Receiver Actually Sees

The curve matters because devices do not read voltages; they read decisions.

The intervals where the two rows disagree are the practical content of this chapter. During them the conductor is not LOW — no device is pulling it — and it is not yet HIGH either, because the receiver has not been persuaded. A device sampling in that window reads LOW, and it is not wrong to do so.

This creates a judgement an engineer has to make repeatedly, and it is worth naming because it is the most common confusion when debugging this bus. A line reading LOW has two completely different explanations: a participant is holding it, or it was released and has not finished rising. They look identical to a device sampling a level, and they have opposite fixes — the first is a protocol or device problem, the second is an electrical loading problem. Distinguishing them means looking at the shape of the transition rather than the level, which is why an oscilloscope answers questions here that a logic analyser cannot.

3. Levels Are Thresholds, Not Values

The second idealisation to drop is that HIGH and LOW are values.

A receiving input does not measure a voltage and report it. It compares the voltage against thresholds and produces a decision. Below one threshold it decides LOW; above another it decides HIGH. Between them is a region where the input's behaviour is not guaranteed — it will report something, but not something a designer may rely on.

Two consequences follow directly.

A driven LOW is not zero volts. A device pulling the conductor holds it near ground, not at ground: its switch has some resistance, and the current the pull-up delivers flows through it, producing a small voltage. The specification bounds how high that residual may be while the device is sinking a specified current, and that bound is precisely the floor on pull-up resistance that Chapter 2.4 derived — a smaller resistor means more current, a larger residual voltage, and eventually a LOW that receivers can no longer be relied upon to read as LOW.

A rising edge has not "arrived" until it crosses the threshold. How long that takes depends on the resistance, the capacitance, and how far up the supply range the threshold sits. That last term is why supply voltage enters the timing argument at all, and it is why the same board can behave differently on a different rail.

The specification defines these thresholds and the LOW-voltage bound precisely, and some of them differ by device family and speed mode. Module 11 presents them against the modes they belong to. What Module 2 needs is the structural fact: a level is a decision made against a threshold, and the region between the thresholds is not a third level but an absence of guarantee.

4. Where the Capacitance Comes From

Chapter 2.4 treated bus capacitance as a given. On a real board it is a sum of identifiable contributions, and knowing where they come from is what makes it a quantity a designer can act on rather than suffer.

The conductors themselves. Copper on a board has capacitance to the planes and traces around it, roughly in proportion to length. A bus routed across a large board carries more than one confined to a corner.

Package pins and device inputs. Every attached device contributes the capacitance of its pin and its input structure. This is the term that grows as devices are added, and it is why a bus that worked with four devices can misbehave with seven.

Connectors and cables. Any inter-board hop adds capacitance, usually far more per unit length than a board trace. A bus leaving the board is the single most common reason a design that worked on the bench fails in the system.

Anything else attached to the net. Test points, protection devices, filters, level-shifting components — all present some capacitance whether or not they are doing anything.

The specification places a ceiling on the total capacitance per line, and it is the same quantity from Chapter 2.4's ceiling-and-floor argument seen from the other side: exceed it and no pull-up value satisfies both bounds, because the resistance needed for an acceptable rise time draws more current than devices can sink. The numeric limit belongs to Module 11.

5. Level Shifting — When the Bus Spans Two Supplies

§5 raised mixed supplies as a problem and named the answer. It deserves developing, because open-drain signalling makes some translation approaches possible that a push-pull signal could not support, and because the naive version of the idea is genuinely unsafe.

Start with what is tempting and wrong: since devices only ever pull LOW, surely two domains can simply share the conductor with one pull-up? Sometimes that even appears to work, which is what makes it dangerous. Three things can go wrong independently:

• A device may see a voltage above what its pin tolerates. A pull-up to the higher rail holds the released line near that rail, and a device built for the lower rail then has its input sitting above its supply. Whether that is acceptable is a property of that specific pin — some are specified to tolerate it, many are not, and the datasheet is the only authority.
• A device may not see a valid HIGH. A pull-up to the lower rail leaves the released line below what a higher-rail device needs to cross its own threshold. Nothing is damaged; the bus simply does not work, and it may work at room temperature and stop elsewhere.
• Current can flow through a powered-down device. Pin protection structures conduct toward a supply that is not there, so a conductor held HIGH can push current into an unpowered part. That is why power sequencing is a bus question and not only a board question, and why a design where one domain may be off while the bus stays active needs explicit thought.

The structural answer is a bidirectional level shifter — a bus translator placed between two segments, each segment carrying its own pull-up to its own rail.

Two requirements follow from everything this module has established, and both are non-negotiable:

It must be bidirectional. Either side may assert the bus, so translation cannot have a direction. A one-directional buffer — perfectly adequate for an ordinary signal — removes one segment's ability to signal at all.

It must preserve dominant LOW. A device on either segment must be able to pull the whole bus low, or every mechanism built on the wired-AND property stops working. A translator that isolates the segments leaves two buses that cannot hear each other.

One design consequence worth noting: each segment now has its own capacitance and its own pull-up, so each gets its own sizing window from Chapter 2.4. Splitting a heavily loaded bus is therefore sometimes the right answer to a closed design window — two lightly loaded segments each have a window even when one combined bus does not. Module 3.3 covers wiring and segmentation properly.

6. Reading a Real Capture — Seven Questions

Everything in this module converges on one practical skill: looking at a conductor and deciding what is wrong. This is the checklist, in the order that costs the least time, and the ordering is the content — each question is cheaper than the next and eliminates a whole class of cause.

1. Is LOW actually low enough? A driven LOW should sit close to ground. If it is visibly elevated, the pulling device is struggling to sink the current the pull-up delivers — which points at a pull-up that is too strong for the weakest device, or a device that is not driving properly. This is the Chapter 2.4 lower bound being violated, and it presents as data corruption rather than as an obvious electrical fault.

2. Is HIGH actually high enough? A released line should reach a level every receiver reads as HIGH. If it plateaus short of that, suspect a pull-up to the wrong rail, a level-translation problem, or a device leaking current into the conductor.

3. How long does the rise take? Measure it between two defined fractions, as Chapter 2.4 explained. A slow edge is the single most common electrical failure, and it means R x C grew — almost always C.

4. Is the edge monotonic? A healthy RC rise climbs steadily and flattens. A rise with a step, a shoulder, or a reversal is not an RC curve, and that is a finding: something else is contributing — a translator switching, a device's protection structure conducting, or reflections on a long conductor.

5. Is another device holding the line? If the conductor sits LOW when nothing should be asserting it, somebody is. This is a different fault from a slow rise even though both read LOW, and §2 gave the discriminator: a held line is flat, a rising line has shape.

6. Did loading change when hardware was added? The most useful question on a board that used to work. Devices, connectors, cables and probes all add capacitance, and the failure appears at the moment loading crosses what the fitted pull-up can drive.

7. Is the problem electrical before it is protocol? The question this whole module exists to make answerable. A protocol trace of a bus with marginal edges is a trace of corrupted data, and reading it as a protocol bug sends you looking in the wrong layer entirely.

7. Failure Modes and How to Diagnose Them

Symptoms map to causes, and the mapping is worth knowing as a table because bring-up rarely allows the luxury of reasoning from first principles.

Two diagnostic habits are worth more than the table.

Remove participants. A shared conductor's faults often belong to the combination rather than to any device. Detaching devices one at a time separates "somebody is holding it" from "the conductor itself is faulty" faster than any amount of staring at a trace.

Measure with the system in its real state. Almost every failure in the last row of that table exists because a bus was characterised on a bench with two devices and shipped into a system with seven. The bench measurement was not wrong; it measured a different bus.

8. Debugging — The Capture That Was Read as a Protocol Bug

// The situation, not a code bug. A design is validated on a bench: host plus two
// devices, short traces, 4.7 kilohm pull-ups, everything passes. It ships into the
// real system: seven devices, a longer route, and a ribbon cable to a daughter
// board. Pull-ups unchanged, RTL unchanged, firmware unchanged.
//
// Transfers now fail intermittently. The team captures the bus with a LOGIC
// ANALYSER, which shows clean ones and zeros with occasional wrong bytes. The
// wrong bytes look like a protocol problem, so the investigation starts in the
// controller: reviewing sequencing, adding retries, checking the driver.
//
// Days later nothing is found, because there is nothing wrong in that layer.

// Diagnose in the right layer first. Put an OSCILLOSCOPE on the conductor and
// answer Chapter 2.6's questions 1 to 3:
//   - LOW level:  clean and near ground?      -> yes, so the pulling side is fine
//   - HIGH level: reaching a valid HIGH?       -> eventually, but slowly
//   - rise time:  measured 30% to 70%          -> far longer than on the bench
// An asymmetric capture with normal falls and stretched rises says the pulling
// mechanism is healthy and the RECOVERY mechanism is out of margin. That is
// capacitance or pull-up, not protocol.
//
// Then apply Chapter 2.4's window rather than guessing:
//   1. estimate the new C (devices + trace + cable);
//   2. compute the pull-up CEILING from the rise-time budget at the target speed;
//   3. compute the FLOOR from the weakest device's sink capability;
//   4. if ceiling < floor, no resistor works -- reduce C instead: shorten or
//      remove the cable, split the bus into segments each with its own pull-up,
//      or move devices off the loaded segment.
//
// The verification that would have caught it before shipping: characterise the
// bus at its WORST-CASE loading, not its bench loading. The bench measurement was
// not wrong -- it measured a different bus. Retries were the clue that the fault
// was analog: they trade time for margin, which helps a marginal edge slightly
// and does nothing for a logic error.

The engineering lesson, and it is the one this module has been building toward: on a shared open-drain bus, establish the electrical layer before interpreting the protocol layer. A protocol trace is a record of decisions receivers made about voltages, so a trace taken from a bus with marginal edges is a record of wrong decisions — and it will look like a protocol fault no matter how carefully it is read. The diagnostic order is fixed and it is cheap: confirm LOW is low enough, HIGH is high enough and the rise completes in time, then read what the bytes say. Reversing that order is the most expensive mistake available on this bus, and the fact that a logic analyser cannot reveal the difference is what makes it so common.

9. Common Misconceptions

10. Reason It Through

Work this through before reading the answers.

A bus works on the bench. In the system, the same board drives the same devices through a short ribbon cable to a daughter board, and transfers fail intermittently. On a scope, SDA's falling edges look normal and its rising edges are noticeably slower than on the bench.

What does the edge asymmetry tell you? That the pulling mechanism is fine and the recovery mechanism is struggling. Falling edges are driven, so their being unchanged says the devices' switches are working normally. Rising edges are the pull-up charging capacitance, so their being slower says the capacitance rose, the pull-up weakened, or both — and nothing about the resistors changed.

Where did the capacitance come from? The cable and connectors, plus the additional trace on the daughter board. An inter-board hop typically contributes far more per unit length than board copper, which is why this failure mode appears exactly when a bus leaves the board.

Why intermittent rather than constant? Because failure requires a device to sample while an edge is still in flight, which depends on where in the transfer the slow edge falls, on temperature, and on part-to-part variation. A slow rise does not corrupt every transfer — it removes margin, and the transfers that fail are the ones that had least to spare.

What are the options, and what bounds them? Lower the pull-up resistance to deliver more charging current — bounded below by what the weakest device can sink while still holding a valid LOW, exactly the floor from Chapter 2.4. If the required resistance falls under that floor, no value works and the capacitance itself must come down: shorten or remove the cable, reduce the device count on that segment, or split the bus into segments with their own pull-ups. Note that the diagnosis came entirely from edge shape, which a logic analyser would have hidden by reporting only ones and zeros.

11. Understanding Check

12. Summary

On a real board the idealised node acquires four properties worth carrying forward.

Edges are asymmetric, and that asymmetry is the signature of the architecture. Falling edges are driven and sharp; rising edges are the pull-up charging capacitance and curve toward the supply. A symmetric capture is a finding, not a reassurance.

Levels are threshold decisions, not values. A receiver compares against thresholds and reports a decision; between the thresholds there is no guarantee. A driven LOW sits near ground rather than at it, because current flows through the pulling device's switch resistance — which is the same bound that floors the pull-up resistance.

Capacitance is a sum of controllable contributions — trace length, attached device count, connectors and cables, and anything else on the net. It is the quantity that changes when a working bus stops working, and the specification caps it per line precisely because no pull-up value can satisfy both bounds once it is exceeded.

Mixed supplies require bidirectional translation that preserves dominant LOW. The requirement comes from the wired-AND property rather than from any protocol rule, and it is the first place the module's electrical architecture constrains a component choice outright.

Underneath all four sits the diagnostic question this module has been building toward: a line reading LOW is either held or still rising, and telling those apart is an electrical judgement made from edge shape, not a protocol one made from levels.

13. What Comes Next

Module 2 is complete. It began with a debt from Module 1 — that several devices were assumed able to share a conductor safely — and discharged it as one continuous argument: an ordinary push-pull output cannot share a node, so active HIGH drive is deleted, so a pull-up must restore the released line, so HIGH is recovered rather than driven, so any participant can assert and all must release, and so every rising edge costs real board-dependent time.

Module 3 — I²C Bus Architecture builds on that foundation rather than beside it. Now that the wires are known to work, it asks who is on them: which participant initiates a transfer and what that entitles it to, how the specification's role terminology has evolved, how one pair of conductors serves an entire board, and how a real bus is wired, supplied and segmented — a question this chapter has already made concrete by showing what a connector or a second supply rail does to it.

Browse the full path on the I²C tutorials index. For the constraint that produced this topology, revisit Why Chips on a Board Need a Bus.