Pod Build-Out Planning Guide

Table of contents

Pod Build-Out Planning Guide

Introduction

This guide focuses on build-out options for multi-node LCC Fusion systems.
Rather than describing individual cards in isolation, it explains how multiple nodes, hubs, and power sources are combined in real layouts.

The key architectural idea introduced here is the pod.

A pod is a physical grouping of one or more Node Bus Hubs, populated with Node Cards and I/O cards, and connected to the rest of the layout through the CAN network. Pods are the primary unit used when scaling a layout horizontally.

This document explains:

how multiple nodes coexist as peers,
how hubs are added to expand I/O capacity,
how power can be introduced at multiple points,
and why these configurations are supported and safe by design.

Nodes Are Peers

All LCC Fusion Node Cards are peers on the CAN network.

No node is a master
No node is designated “primary”
Any node may generate or consume LCC Events
Nodes may be added or removed without re-architecting the system

This peer model applies whether nodes are located:

on the same hub,
on different hubs within a pod,
or across multiple pods.

What a Pod Is (and Is Not)

A pod is a physical planning concept.

A pod:

contains one or more Node Bus Hubs,
may contain multiple Node Cards and I/O cards,
may have multiple power entry points,
shares CAN communications across all contained hubs.

A pod is not:

a logical hierarchy,
a single power domain,
or a control boundary.

Nodes inside a pod remain peers on the CAN network regardless of how power is distributed.

Expanding a Pod with Multiple Hubs

Why Multiple Hubs Exist

Each Node Bus Hub provides:

a fixed number of card slots,
local power distribution,
short, controlled signal paths.

As layouts grow, it is common to:

exceed the slot count of a single hub,
physically spread hardware across a layout,
or group I/O near the devices it controls.

Adding hubs is the intended expansion mechanism.

Power Distribution Philosophy

Power distribution in LCC Fusion is intentionally flexible.

Key design principles:

Power may be introduced at multiple points
Each hub may have its own power source
Built-in diodes prevent harmful back-feeding
Fusing protects against over-current conditions
Power sharing is allowed and expected

This allows real-world build-outs without artificial constraints.

Power Zones (Conceptual)

For planning purposes, it is useful to think in terms of power zones.

A power zone typically aligns with:

one Node Bus Hub,
its installed cards,
and its local power entry.

Power zones help reason about current consumption, but they do not imply strict electrical isolation unless explicitly designed that way.

Hub-to-Hub Connectivity Options

Node Bus Hubs can be connected in two common ways. Both are supported.

1. Board-to-Board (Pin) Connections

Used when hubs are:

physically adjacent,
acting as a local expansion.

Characteristics:

Power rails pass between hubs
CAN and I²C are shared
The hubs behave as a unified local assembly

This is ideal for dense installations where hubs form a compact pod.

2. Network Cable (RJ45) Connections

Used when hubs are:

physically separated,
located across a layout,
or expanded remotely.

Characteristics:

CAN communications are carried
Power may be carried depending on configuration
Each hub may have its own power source

This method is commonly used when hubs are mounted near the devices they serve.

Multiple Power Entry Points (Supported)

It is fully supported to power a pod using multiple power sources, for example:

Hub A receives modest power via a network cable (e.g., under 1A)
Hub B receives higher current from a local computer power supply (e.g., ~3A)
The hubs are connected and share CAN communications
Some power may naturally flow between hubs as loads demand

This is normal behavior.

Built-in diodes ensure:

current flows in safe directions,
supplies do not drive into each other,
and no damage occurs due to imbalance.

No special configuration is required.

Why This Is Useful

This flexibility allows builders to:

inject power close to high-current I/O devices,
reduce long power cable runs,
reuse available supplies,
scale systems incrementally,
and avoid artificial “single supply” limits.

Rather than forcing rigid rules, the system supports practical layouts.

What Users Do Not Need to Manage

Because protection is built in:

users do not need to match supplies precisely,
do not need to balance loads manually,
do not need to configure jumpers,
and do not need to worry about harming hardware.

The system is designed to tolerate real-world variations.

Typical Pod Build-Out Examples

One hub with multiple Node Cards and light I/O
Two hubs sharing local power via pins
Two hubs connected by network cable, each with its own supply
One hub powered over network cable, another powered locally
Multiple hubs spread across a layout, all within one CAN domain

All of these are valid.

Summary

This guide is about build-out choices, not restrictions.

Key takeaways:

Pods are physical groupings of hubs
Nodes are always peers
Hubs are added to expand I/O
Power may be injected at multiple hubs
Mixed power sources are supported and safe
CAN communications remain unified across the pod

By design, LCC Fusion supports growth without forcing rigid power or topology rules.