Table of contents

Why LCC Fusion Uses I²C for Inter-Card Communication

Why LCC Fusion Uses I²C for Inter-Card Communication

Choosing the right tool for short-range coordination inside the Fusion Node Bus Hub.

LCC Fusion uses CAN for layout-wide communication between nodes. It uses I²C for communication between cards inside a Fusion Node Bus Hub.

This is a deliberate design choice based on role, distance, cost, and responsibility.

Understanding this distinction helps clarify why Fusion scales cleanly without unnecessary complexity.

1. Inter-Card Communication Is a Different Problem Than Layout Communication

CAN is designed for:

long cable runs
electrically noisy environments
independently powered devices
distributed intelligence
arbitration between peers

That makes CAN ideal for node-to-node communication across a layout.

Inter-card communication inside a Fusion Node Bus Hub is fundamentally different:

very short distances
shared power and ground
known topology
controlled electrical environment
centralized decision-making

Using the same solution for both problems would add complexity without adding value.

2. Using CAN Internally Would Require MCUs on Every Card

A CAN-based card would require:

a CAN controller
a CAN transceiver
firmware
node identity management
arbitration handling

That would turn every I/O card into a miniature node.

Fusion intentionally avoids this.

Instead:

only the Node Card is an LCC node
I/O cards act as extensions of the Node Card
decision-making remains centralized

This keeps the architecture simpler and more predictable.

3. I²C Fits the Inter-Card Role Cleanly

I²C is well suited for:

short-distance communication
simple command and status exchange
device identification
structured discovery
shared control by a single master

In Fusion:

the Node Card is the master
cards do not arbitrate
cards do not generate LCC events
cards do not make independent decisions

I²C matches this model exactly.

4. This Keeps I/O Cards Simple and Affordable

By using I²C internally, many Fusion cards can be built without:

microcontrollers
firmware updates
complex debug paths

This results in:

lower per-card cost
simpler assembly
fewer failure modes
easier troubleshooting

It also allows Fusion to offer many specialized I/O cards rather than a few expensive all-in-one boards.

5. Reliability Is Engineered Into the Hub, Not Left to the User

I²C is not intended for long cables—and Fusion does not use it that way.

The Fusion Node Bus Hub provides:

short, controlled signal paths
filtering and conditioning
managed pull-ups
known device count

All of this is handled by design.

The user does not tune, configure, or manage I²C behavior.

6. Clear Separation of Responsibilities

Fusion deliberately assigns each technology a clear role:

CAN
- layout-wide communication
- node-to-node messaging
- standards-based interoperability
I²C
- internal coordination
- card discovery
- capability reporting
- short-range signaling

This separation keeps each layer focused and prevents overlap.

Why This Matters

Using I²C for inter-card communication allows Fusion to:

centralize intelligence in the Node Card
avoid unnecessary MCUs
reduce system cost
simplify firmware
keep internal complexity invisible to the user

CAN remains the backbone of LCC communication. I²C quietly does its job behind the scenes.

Each is used exactly where it makes sense.

Where This Fits in the Bigger Picture

This design choice directly supports:

the four-tier architecture
specialized I/O cards
breakout board flexibility
auto-discovery
predictable expansion

Fusion does not chase technical novelty—it applies proven tools thoughtfully.

← Back to Understanding LCC Fusion