LCC Fusion Project
Welcome to the Planner’s Guides — your starting point for designing an LCC-enabled layout. Whether you’re planning detection zones, signal logic, card deployments, or power distribution, this section helps you design with intention and clarity before you build.
Ready to build? Once your layout plan is in place, head over to our Builder’s Hardware Assembly Guides for:
Step-by-step build instructions for every LCC Fusion card (Node, BOD, Button, PWM, Power-CAN, etc.)
Solution-based hardware selections and
recommended parts lists for common layout tasks (block detection,
turnout control, signaling, power distribution)
Complete BOMs and alternative component options
to fit different budgets or power requirements
Best-practice tips for cabling, mounting, and integrating each card into your accessory bus
Use the guides below to understand key layout planning strategies and how to best utilize the LCC Fusion system components.
Node
Power Planning Guide
Understand how to power your nodes safely and efficiently.
Pod
Build-Out Planning Guide
Strategies for scaling a multi-node layout.
Wireless
Node-to-Node Planning Guide
Design considerations for wireless communication between LCC
Nodes.
Terminology
Definitions and common language used across LCC Fusion
documentation.
Sensor
Planning Guide
Choosing and placing sensors (analog/digital) for occupancy and
triggering.
BOD
Card Planning Guide
Design blocks with detection using the BOD Card.
Button
Card Planning Guide
Planning control points for pushbuttons, toggles, and panel
input.
LED
Card Planning Guide
Design layout lighting and LED-based indications.
Sound
Card Planning Guide
Placement and event planning for audio outputs.
Servo
Motor Card Planning Guide
Integrate servos for semaphores or other mechanical devices.
Turnout
Card Planning Guide
Plan switch machine control and frog polarity handling.
Signal
Planning Guide
Basics of signal system design.
Signal
Aspects Planning Guide
Choose which aspects (e.g., Stop, Clear, Approach) to use.
Signal
Complex Planning Guide
Advanced signal logic for interlockings and multi-block
lookaheads.
Signal
Types & Deployments
Real-world signal examples and where to deploy them.
See the How to Use Assembly Guides for detailed instructions.
The Audio Card works in conjunction with the LCC Fusion Node Card and a Node Bus Hub to provide advanced audio playback capabilities, including text-to-speech and .wav file playback, through up to four connected speakers. The Audio Card allows administrators to assign specific LCC Event IDs to trigger the playback of either pre-recorded sounds or synthesized speech, which is highly configurable via the LCC Configuration Tool.
Typical applications for the Audio Card include: - Audio feedback for LCC system users: - Playback of error notifications, system status updates, and operational messages. - User-defined voice messages triggered by specific LCC Event IDs configured through the CDI (Configuration Description Information).
The Audio Card also integrates with other LCC modules, enabling synchronized responses across devices for complex audio-visual effects on model train layouts.
The Audio Card is equipped with a robust hardware setup designed to handle both text-to-speech conversion and high-quality audio playback from external sound files. Its hardware configuration includes:
ESP32 DevKit-C Module:
The core of the Audio Card, the ESP32, runs the firmware responsible for managing both text-to-speech (TTS) and audio file playback capabilities:
Audio Amplifier:
The Audio Card supports up to four MAX98357A IC audio amplifiers, capable of sending audio signals to individual speakers. These amplifiers feature the following:
Supports up to four speakers via RJ45 or 2-pin terminal connectors. This provides flexibility for different speaker setups.
Class-D audio amplifiers with low power consumption, making them ideal for compact and power-efficient installations.
Each amplifier can drive a separate speaker, allowing simultaneous playback of different audio tracks or messages on different channels.
Power Supply and Configuration:
Communication and Control:
The Audio Card is designed for multiple use cases in model train layout automation, where immersive audio effects and feedback are critical:
The following outlines the flow of activity for the Audio Card:
` Diagram Explanation
Here’s an explanation of the diagram above. Click to listen to an audio explanation.
The Audio Card interfaces with the LCC Fusion Node Card, which processes and triggers LCC Events. When an event is triggered (such as a sensor detecting a train or a command issued from the control panel), the Audio Card plays the corresponding audio message or sound effect. The system can perform either text-to-speech conversion or playback pre-recorded .wav files stored on the micro-SD card.
Audio Playback Process:
This flexible design ensures that audio feedback, from synthesized voice messages to rich sound effects, is an integral part of the model train layout, enhancing both the realism and interactivity of the environment.
This section combines both the component specifications and the assembly instructions to ensure a smooth assembly process. Below is a comprehensive list of components, their placement on the PCB, and orientation details to assist you during assembly.
High-Level Steps for Assembly:
Below is a list of the PCB components used for this card (see diagram before reference):
| Component Identifier | Count | Type | Value | Package | Purpose | Orientation |
|---|---|---|---|---|---|---|
| Capacitors | ||||||
| C1, C3, C5, C7, C9, C11, C13 | 7 | Capacitor-Ceramic | 0.1uF | 1206 SMD | Decoupling Capacitor for IC Protection | None |
| C2, C4, C6, C8, C10, C12, C14 | 7 | Capacitor-Ceramic | 10uF | 1206 SMD | Decoupling Capacitor for IC Protection | None |
| Diodes | ||||||
| D1 - D8 | 8 | Diode-Schottky | SS310 | SMD | Circuit protection from reverse current from speaker connections. | Cathode end has a white line and positioned towards PCB left edge |
| D5 | 1 | ESD Diode | PESD1CAN | SOT-23 SMD | I2C data bus electrostatic discharge (ESD) | Cathode end has a white line and positioned towards PCB left edge |
| Fuses & Protection | ||||||
| F1 | 1 | Fuse-PTC Polymer | 0.2A, 3V (or higher) | 1206 SMD | Protects overload from SD Module | None |
| F2 | 1 | Fuse-PTC Polymer | 1A, 5V (or higher) | 1206 SMD | Protects overload from audio speakers | None |
| Filters & Noise Suppression | ||||||
| FB1, FB2 | 2 | Ferrite Bead | BLM31PG121 | 1206 SMD | I2C Network Bus Data Line Noise Suppression | None |
| FB3, FB4 | 2 | Ferrite Bead | BLM31PG121 | 1206 SMD | 3V3 Noise Suppression for SD card reader and I2C display | None |
| Connectors | ||||||
| J1 - J4 | 4 | JST XH Socket or 2-Position Spring Terminal Connector | 2P, 2.54mm | PTH, vertical or horizontalPTH or Spring Terminal | Connectors to speakers | None |
| J5 | 1 | RJ45 Socket | 8P8C | PTH | Network cable (CAT5/6) connections to speakers (4 pairs). | Fits only one way |
| J6, J7 | 2 | Female Header | 19-Pin | PTH | Socket for ESP32 DevKit-C board | None |
| J8 | 1 | Female Header | 8-Pin | PTH | Required when using Micro-SD Card Reader for playing .wav files. | None |
| J9 | 1 | Female header | 2-Pin, 2.54mm | PTH | OLED Display Connection | None |
| Resistors | ||||||
| R1, R2, R3 | 3 | Resistor | 1kΩ | 1206 SMD | Used to limit the current to SW1 and MCP23017 for the I2C address | None |
| R4 | 1 | Resistor | 3.3kΩ | 1206 SMD | Current limiting for LED | None |
| R5 | 1 | Resistor | 10k Ω | 1206 SMD | Voltage Divider (high/low ends) | None |
| R6 | 1 | Resistor | 1.8k Ω | 1206 SMD | Voltage Divider (high/low ends) | None |
| Switches & Indicators | ||||||
| LED1 | 1 | LED (Red) | 2 mA | 1206 SMD | 5V Power Indicator | Reference back of LED, position cathode towards PCB
left edge |
| JP1, JP2 | 2 | Male Header | 3P, 0.1” | PTH | Used for COMM BUS selection (I2C hardware bus) for either BUS A or BUS B. | None |
| SH1, SH2 | 2 | Jumper Cap (Shunt) | 2.54mm | - | Used to set the COMM BUS selection (JP1, JP2) | None |
| SW1 | 1 | Slide Switch | 3P, 2.54mm | PTH | Used for COMM ADDR selection (I2C address offset, 0-7). | Position ON towards PCB top edge |
| ICs | ||||||
| U1, U2, U3, U4 | 4 | Audio Amp | MAX98357A | 16TQFN | Class D audio amplifier supporting I2S connections | Small dot (pin 1) on package is positioned to PCB bottom and right edges |
| U5 | 1 | ESP32 Module | ESP32 DevKitC | DevKitC | Processes I2C text messages from the Node Card and sends player commands via UART | Position USB connection to PCB bottom edge |
| Miscellaneous | ||||||
| Micro-SD Card Reader | 1 | Module | SPI | N/A | Micro-SD Card Reader is required for playing .wav files. | |
| Micro-SD Card | 1 | SD Card | N/A | N/A | Required for storing .wav files. | N/A |
| 1 | OLED Display | SSD1309, SSD1306 | 4-Pin, I2C | Display serial messages from firmware | Refer to silk screen of OLED and card, display extends out from card. |
The following test and verifications of the card should be performed after a through inspection of the card’s soldering. Check all of the PTH component pins and SMD pads. Make sure there are no solder bridges between pins and pads.
T to start the firmware’s
self-test, then review the results.
BCLK, LRCLK,
DIN[1..4] driven and verified as
Outputs.SCK, MOSI,
CS as Outputs; MISO checked
as an Input.SDA/SCL briefly
exercised as open-drain I/O to confirm upstream Hub
pull-ups and line integrity.If you connect the Audio Card’s RJ45 output to the
Card Monitor Board, the LEDs will show faint flicker or
shimmer in response to sound output across all eight lines.
This test is optional but can confirm that the ESP32,
amplifier, and output drivers are active before connecting speakers.
| Lines | What You Should See | How to Read It |
|---|---|---|
| L1–L8 | Dim flicker or variable brightness when audio is playing | LEDs react only to the positive half of the AC audio signal. You’ll see subtle glow/flicker that follows loudness or rhythm. If all remain dark, the card is silent or inactive. |
| Item | Setting / Action | Purpose |
|---|---|---|
| JP1 (L8: GND / OUTPUT) | OUTPUT | Select OUTUT since the Audio Card does not provide a GND line on the RJ45. |
| J1 (PWR BUS GND) | Connect to the Audio Card’s supply GND | Provides the only return path so the LEDs can light. Must share the same power ground as the Audio Card (Node Bus Hub) |
Notes: 1. The Audio Card does not supply GND on the RJ45 audio lines. You must connect J1 GND to the Audio Card’s power-supply ground (common return). 2. LEDs are activity indicators only—they do not represent tone, volume, or fidelity. 3. LEDs light only on the positive half-cycles, so flicker may be faint or uneven—this is normal. 4. Speaker pair mapping: adjacent lines form pairs (e.g., L1/L2, L3/L4, L5/L6, L7/L8). In stereo builds, you’ll typically see different flicker patterns between left/right pairs. 5. For meaningful audio testing (quality, channel balance), use speakers.
Tip: Use this LED check just to confirm the Audio Card is alive before you hook up speakers; faint flicker is expected.
The card’s specifications are as follows:
(This notes table is intended for optional annotations. It can be edited directly in LibreOffice or Microsoft Word, or annotated in PDF readers that support text annotations. Empty rows may collapse in EPUB or PDF exports; this is expected.)
This page provides a capabilities overview of the LCC Fusion Project. It is intended to show what the system can do, not to explain configuration steps or installation details.
LCC Fusion supports a wide range of automation, sensing, control, and integration scenarios. Some capabilities listed here are fully implemented today, while others are marked as Planned and represent future expansion of the platform. Detailed planning, assembly, installation, and configuration guidance for each capability is provided in the linked guides throughout the documentation.
Use this page to understand the scope of the system and identify which capabilities are relevant to your layout, then follow the referenced guides to learn how to implement them.
Capabilities labeled Planned represent future capabilities and are not yet available. All other capabilities described are implemented and in active use.
LCC Fusion supports both layout automation and train control, allowing the system to participate in detection, signaling, and turnout logic as well as optional locomotive control through a DCC Card.
The Digital I/O Card is intended for simple digital states, such as switches, buttons, or relay contacts, where inputs represent direct on/off conditions.
The Sensor Card is designed for active sensors that
generate events based on measured conditions, such as light, proximity,
or occupancy, rather than simple on/off states. - IR modules
- Hall effect
- HTTM capacitive touch
- Ultrasonic triggers
- Phototransistors
Each port includes: - GND
- 3.3 VDC
- Protected signal line
Generates LCC events for automation, lighting, announcements, or turnout control.
This integration is implemented entirely in firmware and is already in active use within LCC Fusion layouts; no additional hardware is required.
Example commands:
- “Alexa, set Station 4 to 50%”
- “Alexa, trigger Train Departure”
- “Alexa, turn on Yard Lights”
Multiple Node Cards may be deployed across one or more hubs to distribute processing, roles, and I/O responsibilities as layouts scale.
The Node Bus Hub provides the physical foundation for scaling systems by aggregating Node Cards and I/O cards in a structured, repeatable way.
System scale is determined by how many hubs and power entry points are deployed, rather than a fixed node count. Practical limits depend on power distribution, physical layout, and CAN bus considerations.
Large layouts are typically organized into pods, each consisting of one or more Node Bus Hubs installed near the devices they serve.
This approach allows systems to scale incrementally without redesign.
Educational Media
– Understanding LCC Fusion – A Clear On-Ramp into LCC-Based Layout Automation – LCC Fusion Podcast – Fusion Hardware Architecture Overview – LCC Fusion Podcast – Cards & Node Basics
Block Occupancy Detection (BOD) on a model train layout provides real-time awareness of train presence, enabling automation, safety features, and responsive layout behavior.
In the LCC Fusion Project, BOD is implemented using the BOD Card, which senses track occupancy and generates LCC events that drive logic, signaling, and automation.
Block Occupancy Detection defines where trains are detected; logic, signaling, and automation define how that information is used. The BOD Card reports presence state via events only and never encodes behavior.
BOD is introduced during layout planning when you decide where trains need to be detected and why. Each detected block exists for a purpose, such as enforcing safety, driving signals, triggering automation, or providing operator feedback.
The BOD Card supports up to eight track blocks, so planning begins by identifying block boundaries and grouping related blocks that can be served by a single card.
A BOD Card is installed in a Node Bus Hub and connects via cable to one or more Block Breakout Boards. Block Breakout Boards are typically positioned close to the track blocks they serve to simplify wiring and reduce cable runs.
When planning block occupancy detection: - Group nearby blocks so they can be served by the same BOD Card - Consider physical distance from the Node Bus Hub to the track - Plan block boundaries based on detection needs, not just rail length - Ensure blocks are electrically isolated according to the chosen detection method
Each use case below represents a reason to create one or more track blocks. During planning, you should be able to point to a specific operational goal for every block you define.
While block occupancy detection is commonly associated with signaling systems, it is equally useful for automation, safety, and operator feedback on layouts without signals.
Below is an assortment of ways the BOD Card can be utilized:
| Block Detection Use | Description |
|---|---|
| Detect Train Presence | The card senses when a train enters a block, allowing the system to update signal aspects and turnout positions accordingly. |
| Occupancy-Based Signaling | Triggers signals to display a ‘stop’ aspect when a train is detected, ensuring other trains do not enter the occupied block. |
| Route Setting Based on Occupancy | Automatically adjusts turnouts to route trains correctly based on block occupancy to prevent collisions. |
| Support for Automated Train Operation | Facilitates automatic train control by providing real-time occupancy status to the system, which can be used to start, stop, and control train speeds without manual intervention. |
| Emergency Brake Trigger | In case of a detected issue, such as unexpected occupancy, the system can trigger an emergency stop to prevent accidents. |
| Aid in Traffic Management | Helps manage train traffic by allowing more sophisticated logic for track reservations and train scheduling based on block occupancy. |
| Prevent Dispatcher Errors | Provides an additional layer of safety by confirming the status of track occupancy to prevent dispatcher errors in manual control systems. |
| Enhance Layout Realism | Contributes to the realism of the layout by automating train movements and interactions just like in the real world. |
| Diagnostics and Maintenance | Block detection cards can log occupancy data for diagnostics, helping to identify potential issues with train detection or track integrity. |
| Multi-train Coordination | Allows multiple trains to be coordinated smoothly by providing essential data for synchronization and timing of train movements. |
Educational Media
– Understanding LCC Fusion – A Clear On-Ramp into LCC-Based Layout Automation – LCC Fusion Podcast – Fusion Hardware Architecture Overview – LCC Fusion Podcast – Cards & Node Basics
Buttons on a model railroad layout provide direct, intentional operator input, enabling manual control, overrides, and interaction with automated systems.
In the LCC Fusion Project, button inputs are implemented using the Button Card, which detects button presses and releases and generates LCC events. These events are consumed by other nodes to control turnouts, signals, lighting, sound, automation sequences, or safety functions.
Buttons define when an operator intervenes; logic, signaling, and automation define how the system responds. The Button Card reports button state changes via events only and never encodes behavior.
Button planning begins when you decide where human interaction is required and why. Each button should exist for a clear operational purpose, such as initiating an action, overriding automation, acknowledging a condition, or triggering a predefined sequence.
Planning involves determining: - Which actions should be manual versus automated - Where operators naturally expect controls to be located - How buttons interact with existing logic and automation - How many buttons are needed and how they are grouped per card
The table below lists common planning use cases that drive the need for this card. Each entry represents a reason to introduce this capability into a layout design.
| Button Use | Description |
|---|---|
| Start/Stop Trains | Use buttons to manually start or stop trains on various tracks. |
| Change Train Directions | Allow operators to change the direction of a train’s travel. |
| Activate Sound Effects | Trigger sound effects like train whistles, station announcements, or ambient noises. |
| Control Lighting Effects | Turn on or off specific lighting elements, or change lighting scenarios (e.g., day to night). |
| Operate Turnouts | Switch rail turnouts to direct trains to different tracks |
| Animate Scenery | Activate moving parts in the scenery, such as opening bridge, rotating windmill, or animated figures. |
| Control Level Crossings | Operate gates and signals at level crossings manually. |
| Activate Special Effects | Trigger special effects like smoke from chimneys, fire scenes, or water effects. |
| Emergency Stop | A safety feature to immediately stop all trains and moving parts in case of an issue. |
| Cycle Through Scenes | Change between different scenes or layouts, for modular train setups. |
| Activate Display Lights | Control additional lighting for display purposes, not part of the layout’s operational lighting. |
| Launch Automated Sequences | Start a sequence of events, like a complete train journey with multiple actions. |
Educational Media
– Understanding LCC Fusion – A Clear On-Ramp into LCC-Based Layout Automation – LCC Fusion Podcast – Fusion Hardware Architecture Overview – LCC Fusion Podcast – Cards & Node Basics
Complex signaling is used on layouts where a single downstream condition is insufficient to safely or realistically convey operating instructions to train crews. These situations arise when multiple routes, graduated speed restrictions, overlapping blocks, or special operating conditions must be considered simultaneously.
In the LCC Fusion Project, complex signaling is a planning decision, not a hardware feature. It determines how many downstream conditions must be evaluated before setting the aspect of a signal mast and how signal logic must be structured to support safe and predictable operation.
Complex signaling defines how far ahead the system must reason. Logic, aspects, and configuration define how that reasoning is implemented.
Complex signaling is introduced during signal planning when simpler models - such as evaluating a single downstream block or mast—are no longer sufficient.
You should consider complex signaling when: - Train speeds change gradually rather than abruptly - Multiple downstream routes affect current movement authority - Signal blocks overlap to provide additional safety margin - Route-dependent speed profiles exist - Advance warning is required beyond the next signal
This guide focuses on planning the logic structure required to support these scenarios. It does not prescribe hardware choices, wiring, or CDI configuration.
Only after determining that complex signaling is required should you proceed to: - Define the number of downstream masts or blocks involved - Select signal aspects - Implement logic groups and statements
In complex rail networks, it may be necessary to evaluate the speeds of two or more downstream masts before setting the aspect of the current mast. This approach ensures safety and operational efficiency in scenarios with high train density, intricate track layouts, or varying speed requirements. > Downstream signals are ahead of the train in its direction of travel, while upstream signals are behind it.
Here are a few situations where such an approach would be necessary:
When a train approaches a junction or an interlocking area with multiple possible routes, it may be necessary to consider the speeds allowed on the routes beyond the immediate next signal. This ensures that the train can safely proceed through the junction and continue at an appropriate speed for the conditions that will be encountered further ahead.
In situations where there’s a need for a graduated speed reduction—perhaps due to a gradient, curve, or approaching a congested station area—checking two downstream masts allows for a smoother transition. The current mast can display an aspect that prepares the train for the speed restrictions that will come into effect not just at the next signal but the one after that, facilitating a gradual deceleration.
In dense rail corridors or high-speed sections, there might be overlapping signal blocks where the conditions of two downstream blocks affect the current signal aspect. This is to provide an additional safety margin by ensuring that a train has sufficient warning and space to stop or slow down, even if a problem is detected two blocks ahead.
When divergent routes from a signal have significantly different speed profiles—such as one route leading to a high-speed line and another leading to a slow-speed yard—checking two downstream masts helps in setting the current aspect. This approach ensures that the train is not only warned about the immediate next signal but also about the speed expectations of the route it will be taking thereafter.
In cases where special operations are in effect, such as track maintenance, construction work, or emergency situations, the signaling system may need to incorporate conditions from further down the line to preemptively adjust train speeds. This can involve taking into account the aspects of two downstream masts to set the current mast’s aspect accordingly, ensuring trains are at the correct speed for upcoming restrictions.
Once it’s determined a complex signaling configuration involving aspects of 2 (or more) downstream masts need to be checked before setting the aspect of a current mast, the process revolves around a common set of logics and checks. These foundational principles ensure the system’s consistency, safety, and efficiency. Let’s outline how this typically works in practice:
For users configuring signals without track circuits, signal aspects are determined by evaluating the occupancy status of at least two downstream blocks. This ensures the upstream mast aspect reflects the safest and most appropriate condition for train operations.
Key Characteristics:
A 3-Aspect signal using block status can be managed
by checking two downstream blocks. Use a single logic
group with 2 logic statements, where the last
statement determines one of two possible aspects (Advance
or Clear).
| Logic Statement | Downstream Block 1 | Downstream Block 2 | Upstream Mast Aspect | Logic Statement |
|---|---|---|---|---|
| 1 | Occupied | - | Stop | 1. If
Downstream Block 1 is Occupied,
Then Set Upstream Mast Aspect to
Stop and Exit. Else
Continue. |
| 2 | Clear | Occupied | Approach or Clear | 2. If
Downstream Block 2 is Occupied,
Then Set Upstream Mast Aspect to
Approach and Exit. Else
Set Upstream Mast Aspect to Clear and
Exit. |
A 5-Aspect signal using block status refines this
logic further by differentiating additional aspects such as
Approach Medium and Advance Clear. Use
a single logic group with 4 logic
statements, where the last statement determines one of two
possible aspects (Advance Clear or Clear).
| Logic Statement | Downstream Block 1 | Downstream Block 2 | Downstream Block 3 | Upstream Mast Aspect | Logic Statement |
|---|---|---|---|---|---|
| 1 | Occupied | - | - | Stop | If Downstream Block 1 is
Occupied, Then Set
Upstream Mast Aspect to Stop and
Exit. Else Continue. |
| 2 | Clear | Occupied | - | Approach | If Downstream Block 2 is
Occupied, Then Set
Upstream Mast Aspect to Approach and
Exit. Else Continue. |
| 3 | Clear | Clear | Occupied | Approach Medium | If Downstream Block 3 is
Occupied, Then Set
Upstream Mast Aspect to Approach Medium and
Exit. Else Continue. |
| 4 | Clear | Clear | Clear | Advance Clear or Clear | If Downstream Block 3 is
Clear, Then Set
Upstream Mast Aspect to Advance Clear and
Exit. Else Set
Upstream Mast Aspect to Clear and
Exit. |
This configuration uses block status and turnout points to determine the aspects of the signal mast for both the mainline and the divergent route. The turnout determines which route is active, and the corresponding signal head governs train movement.
In the following example, the Mast before the turnout has 2 heads, one the mainline route and one for the divergent route. This can be configured using 2 separate logic blocks, one for each head.
Mainline Route: 3-Aspect Signal Head
| Logic Statement | Turnout Block | Point Position | Mainline Block 1 | Mainline Block 2 | Mainline Head Aspect | Logic Statement |
|---|---|---|---|---|---|---|
| 1 | Occupied | Open/Thrown | - | - | Stop | If Points are Open/Thrown
Or Turnout Block is Occupied,
Then Set Mainline Head to
Stop and Exit. Else
Continue. |
| 2 | Clear | Closed | Occupied | - | Stop | If Mainline Block 1 is
Occupied, Then Set
Mainline Head to Stop and
Exit. Else Continue. |
| 3 | Clear | Closed | Clear | Occupied / Clear | Approach / Clear | If Mainline Block 2 is
Occupied, Then Set
Mainline Head to Approach and
Exit. Else Set
Mainline Head to Clear and
Exit. |
Divergent Route: 3-Aspect Signal Head
| Logic Statement | Turnout Block | Point Position | Divergent Block 1 | Divergent Block 2 | Divergent Head Aspect | Logic Statement |
|---|---|---|---|---|---|---|
| 1 | Occupied | Closed | - | - | Stop | If Points are Closed
Or Turnout Block is Occupied,
Then Set Divergent Head to
Stop and Exit. Else
Continue. |
| 2 | Clear | Open/Thrown | Occupied | - | Stop | If Divergent Block 1 is
Occupied, Then Set
Divergent Head to Stop and
Exit. Else Continue. |
| 3 | Clear | Open/Thrown | Clear | Occupied / Clear | Approach / Clear | If Divergent Block 2 is
Occupied, Then Set
Divergent Head to Approach and
Exit. Else Set
Divergent Head to Clear and
Exit. |
Signal aspects are critical for ensuring safe train operations by providing advanced warnings to train crews about track conditions. The logic for setting signal aspects leverages track circuits, which report the aspect (speed) of the downstream mast. This information determines how the current signal should behave.
By utilizing track circuits, the signaling system simplifies decision-making, ensuring that upstream signals dynamically respond to downstream conditions for both safety and operational efficiency.
A 3-Aspect signal** can be managed by checking 1 downstream block and
mast. Use a single logic group with 2 logic
statements, where the last statement determines one of two
possible aspects (Approach or Clear).
| Logic Statement | Downstream Block | Downstream Mast Aspect | Upstream Mast Aspect | Logic Statement |
|---|---|---|---|---|
| 1 | Occupied | - | Stop | If Downstream Block is
Occupied, Then Set
Upstream Mast Aspect aspect to Stop and
Exit, Else Continue |
| 2 | Clear | Stop or Approach | Approach or Clear | If Downstream Mast Aspect is
Stop, Then
Upstream Mast Aspect aspect to Approach, and
Exit. Else Set to
Upstream Mast Aspect to Clear and
Exit |
A 5-Aspect signal can be managed by checking the
Downstream Block and a single Downstream
Mast. Use a single logic group with 4
logic statements, where the last statement determines one of
two possible aspects (Advance Clear or
Clear).
| Logic Statement | Downstream Block | Downstream Mast Aspect | Upstream Mast Aspect | Logic Statement |
|---|---|---|---|---|
| 1 | Occupied | - | Stop | 1. If
Downstream Block is Occupied,
Then Set Upstream Mast Aspect to
Stop and Exit. Else
Continue. |
| 2 | Clear | Stop | Approach | 2. If
Downstream Mast Aspect is Stop,
Then Set Upstream Mast Aspect to
Approach and Exit. |
| 3 | Clear | Approach | Approach Medium | 3. If
Downstream Mast Aspect is Approach,
Then Set Upstream Mast Aspect to
Approach Medium and Exit. |
| 4 | Clear | Approach Medium or Clear | Advance-Clear or Clear | 4. If
Downstream Mast Aspect is Approach Medium,
Then Set Upstream Mast Aspect to
Advance-Clear and Exit.
Else Set Upstream Mast Aspect to
Clear and Exit. |
After thoroughly examining the table of logic statements and their corresponding conditionals and actions, we now present a comprehensive flow diagram. This diagram serves as a visual representation of the logic flow dictated by the conditions and actions detailed in the preceding table. Each conditional check and subsequent action, as described in our logic statements, is illustrated to provide a clearer understanding of how each signal aspect is determined based on the states of two downstream masts.
The flow diagram is structured to mirror the sequential processing of the logic statements, beginning with the initial condition check of Mast 1’s aspect and progressing through the various potential outcomes and actions. By following the diagram, readers can visually trace the decision-making path for setting the current signal mast’s aspect, offering an intuitive grasp of the process that complements the tabular data.
Key Features of the Diagram:
This diagram not only aids in visualizing the operational logic behind signal aspect setting but also serves as a practical reference for those configuring or troubleshooting signal systems. By aligning the visual flow with the logic statements covered earlier, we aim to provide a dual-perspective understanding—both textual and visual—of the intricate decision-making process involved in railway signaling.”
Educational Media – Understanding LCC Fusion – A Clear On-Ramp into LCC-Based Layout Automation – LCC Fusion Podcast – Fusion Hardware Architecture Overview – LCC Fusion Podcast – Cards & Node Basics
Lighting on a model railroad layout provides visual feedback, realism, and atmosphere, helping convey layout state, time of day, and operational intent.
In the LCC Fusion Project, LED lighting is implemented using the PWM Card, which generates variable-duty PWM outputs in response to LCC events. These outputs are used to control brightness, fading, flashing, and sequencing of LEDs and other low-power loads.
Lighting defines what is shown on the layout; logic, signaling, and automation define when and why it changes. The PWM Card controls output intensity only and never encodes behavior.
PWM planning begins when you decide which visual elements on the layout need dynamic control and why. Each lighting output should exist for a clear purpose, such as conveying status, enhancing realism, or responding to operator or sensor input.
Planning involves determining: - Which scene elements require controllable lighting - Whether lighting is static, animated, or event-driven - How many independent lighting channels are needed - How lighting integrates with signals, sensors, buttons, and automation
The PWM Card supports multiple independently controlled outputs, so planning focuses on grouping related lighting elements that can share a card.
A PWM Card is installed in a Node Bus Hub and connects via cable to one or more Digital I/O Breakout Boards or Signal Breakout Boards. Breakout boards are typically placed close to the LEDs they serve to minimize wiring complexity and voltage drop.
When planning PWM-controlled lighting:
Each use case below represents a reason to introduce PWM-controlled lighting into a layout design. You do not need to implement every item; each entry reflects a potential planning motivation rather than a required feature.
| Light Use | Description |
|---|---|
| Train Headlights and Taillights | Install LEDs as realistic headlights and taillights on locomotives and cabooses. |
| Interior Car Lighting | Illuminate passenger cars, freight cars, or other rolling stock interiors with small LEDs. |
| Street Lights | Use LEDs to create street lamps that add life and realism to your towns and cities. |
| Building Lighting | Light up windows in houses, office buildings, and other structures to create a lived-in look. |
| Signal Lights | Implement LEDs in railway signals to control train movements, just like in real-world railroading. |
| Level Crossing Lights | Equip level crossings with flashing red LEDs to indicate when trains are passing. |
| Platform and Station Lighting | Illuminate station platforms and buildings for a realistic night-time scene. |
| Scenery Accent Lighting | Use LEDs to highlight landscape features like rivers, cliffs, or trees. |
| Emergency Vehicle Lights | Create realistic emergency scenes with flashing LEDs on police cars, fire trucks, or ambulances. |
| Vehicle Headlights and Taillights | Add headlights and taillights to cars and trucks on roads and highways. |
| Airport Runway Lights | If your layout includes an airport, use LEDs for runway and taxiway lighting. |
| Dock and Ship Lighting | Illuminate docks and ships in maritime-themed areas. |
| Amusement Park Lighting | Create a vibrant and colorful amusement park with LEDs on rides and attractions. |
| Industrial Area Lighting | Light up factories, warehouses, and other industrial structures for a working environment look. |
| Fire and Explosion Effects | Simulate fires or explosions in dynamic scenes using flickering red and orange LEDs. |
Educational Media – Understanding LCC Fusion – A Clear On-Ramp into LCC-Based Layout Automation – LCC Fusion Podcast – Fusion Hardware Architecture Overview – LCC Fusion Podcast – Cards & Node Basics
Signal aspects define the meaning conveyed to a train operator by one or more signal heads acting together. An aspect represents a single instruction - such as stop, proceed, or proceed with restriction - regardless of how many lamps or heads are used to display it.
In the LCC Fusion Project, signal aspects are planning constructs, not hardware features. An aspect describes what information must be conveyed; the physical signal heads and lamps describe how that information is shown.
Signal aspects define what the operator must know; signal hardware defines how that information is displayed. Aspect planning always precedes hardware selection.
Signal aspect planning occurs early, alongside track and route planning, when you decide what instructions trains must receive at specific locations and how much information must be conveyed.
Planning signal aspects involves determining: - How many distinct instructions are required at a location - Whether a single route or multiple routes must be indicated - How much visual complexity is appropriate for the layout - How closely the model should follow prototype signaling practices
Only after aspects are defined should you decide: - How many signal heads are needed - How many lamps per head are required - Whether multiple heads work together to display a single aspect
An aspect may be displayed using: - A single multi-lamp head - Multiple heads acting together - Different lamp counts depending on route complexity
The number of heads or lamps does not determine the number of aspects. An aspect is defined by the instruction conveyed, not the physical implementation.
| # Aspects Shown (Per Mast) | # Heads | # Lamps (Per Head) | Usage | Comments |
|---|---|---|---|---|
| 1 | 1 | 3 | Used for simple track layouts where a single head can convey clear, caution, or stop for a single route. | A single head with a red, yellow, and green lamp used to indicate stop, caution, and go on a main line. |
| 1 | 2 | 2 | Utilized in scenarios where two heads work together to show a single aspect across both heads for enhanced visibility or redundancy. | Two heads, each with a green and red lamp. Both display green to indicate a clear route ahead. |
| 2 | 2 | 3 | Suitable for junctions or diverging tracks where each head can independently signal the status of the main route and a diverging route. | Upper head shows green for a clear main route, lower head shows yellow to indicate caution on a diverging route. |
| Multiple | Multiple | Varied | Used in complex rail network sections with multiple potential routes, each requiring its own signal indication. | Several heads, each potentially with a different number of lamps, to manage complex junctions with multiple diverging paths. |
The decision to use a single 3-lamp head to show both main and divergent route aspects versus using two separate heads, one for each route, on a signal mast in a real-world railway system depends on several factors including operational requirements, space constraints, clarity of signaling to the train operator, and historical practices of the railway.
In model railroading and simulation projects like the LCC Fusion Project, these considerations can be simplified, but understanding the logic behind real-world practices can help in creating realistic and functional model systems. When documenting or configuring signals within the LCC Fusion framework, consider how these factors translate into the scale and objectives of your model railway system, especially in terms of signaling complexity and the desired level of realism. When documenting or configuring signals within the LCC Fusion Framework, consider how these factors translate into the scale and objectives of your model railway system, especially in terms of signaling complexity and the desired level of realism.
Educational Media – Understanding LCC Fusion – A Clear On-Ramp into LCC-Based Layout Automation – LCC Fusion Podcast – Fusion Hardware Architecture Overview – LCC Fusion Podcast – Cards & Node Basics
Signals on a model railroad convey operational instructions to train operators by presenting specific signal aspects at defined locations on the layout. Effective signal planning focuses on what information must be conveyed and under what conditions, rather than on the physical construction of signal masts or lamps.
In the LCC Fusion Project, signal planning is centered on: - Defining the signal aspects required at each location - Determining the downstream conditions that influence those aspects - Structuring logic statements that evaluate conditions and set aspects accordingly
This guide focuses on planning signal behavior using logic statements and signal groups. Physical implementation details - such as mast wiring, lamp connections, and PWM channel assignment - are intentionally out of scope.
Signal planning defines what instructions are shown and when they change. Hardware and configuration define how those instructions are displayed.
Signal planning occurs after track, turnout, and block planning, when you understand: - Where trains may travel - Where routes diverge or converge - Which blocks must be protected - Which downstream conditions influence train movement
Planning signal behavior involves deciding: - Which aspects are required at each mast - How many downstream elements influence each signal - How logic statements should be ordered to enforce safe operation - When logic processing should stop or continue within a signal group
Only after signal behavior is planned should physical signal hardware and lamp layouts be selected.
Signals in LCC Fusion are controlled by logic groups, each consisting of one or more logic statements. During planning, logic is expressed using an if-then-else structure to clearly describe behavior without committing to configuration details.
This planning approach allows: - Complex signal behavior to be reasoned about before configuration - Incremental refinement of logic without hardware changes - Consistent behavior across different signal hardware types
Below is a set of terms used in both planning and configuring of signal aspects:
Logic Statement: for planning purposes, a logic statement is in the form of a typical if-then-else statement as shown here:
IF conditional THEN
action(s) for true conditions ELSE
actions for false conditions
Example: 1. If Block is Occupied,
Then Set aspect to Stop and
Exit Else Set aspect to Clear
and Continue.
Explanation:
- `1.`: indicates this is the first logic statement in the group.
- `Block is Occupied`: is the conditional, consisting of a single variable to be checked for true or false. Up to two variables can be specified, separated by a logic operator like `OR` and `AND`
- `Set aspect to Stop` is the action that to be performed when the conditional is true.
- `Continue` determines that the processing of additional logic statements should continue. If this is the last (or only) logic statement in the group, then processing of the group will stop and proceed with the next logic group.
- `Set aspect to Clear` is the action to be performed when the conditional is false. Conditionals: condition(s) to be evaluated,
resulting in either true or false. Conditionals contain either one or
two variables. When two variables are define, a logic operator is used;
V1 and V2, V1 OR V2, V1 Only,
etc.
Actions: is what happens when the conditional is true or false. Typically the action sets the aspect or does nothing.
Logic Group: represents a collection of logic configurations accessible via the CDI tool in the Logics and Conditionals section.
Stop and Exit Else
Continue.Stop, Then Set aspect to
Approach and Continue Else
Set aspect to Clear and Continue.Logic Processing determines what happens after
the a logic statement is processed, Exit to stop processing
the logic statements in the group, or Continue to continue
with the next logic statement (e.g. additional conditions need to be
evaluated and aspects set). Note that processing the last logic
statement in the group will automatically exit the group upon
completion.
Track Circuit: Track Circuits report the downstream track speed as shown by a mast linked to the track, simplifying the number of conditions that need checking and are particularly useful when dealing with downstream masts. During configuration, a track circuit is used as a variable in the conditions. For example, when the downstream signal aspect is reporting a stop speed, the current mast typically would show an approach speed.
Stop, Then Set aspect to
Approach and Continue Else
Set aspect to Clearand Continue.| Aspects | Mast Name | Signal Type | Purpose/Use | Example Triggers |
|---|---|---|---|---|
| Caution, Clear | Mainline Distance Signal | Two-Aspect Signal | Provide advance warning of mainline signal status. | Next Block Occupied or Clear |
| Stop | Yard Entry Mast | Single-Aspect Signal | Signal yard entry restrictions. | Yard Block Occupied |
| Stop, Approach, Clear | Crossover Signal Mast 3 | Three-Aspect Signal | Indicate safe crossover alignment. | Turnout Aligned or Block Status |
| Stop, Clear | Mainline Signal Mast 1 | Two-Aspect Signal | Control train movement on a mainline. | Block Occupied or Turnout Misaligned |
| Stop, Clear | Yard Exit Mast 6 | Two-Aspect Signal | Signal safe yard exit onto mainline. | Mainline Block Status |
| Stop, Diverging Clear, Clear | Junction Mast A | Three-Aspect Signal | Control train movement at a turnout junction. | Turnout Alignment and Block Status |
| Stop, Restrict, Clear | Siding Signal Mast 2 | Three-Aspect Signal | Indicate siding availability. | Siding and Mainline Block Status |
| Stop, Restrict, Approach, Advance Approach, Clear | Mainline Mast 4 | Multi-Aspect Signal | Provide multiple aspects for mainline operations. | Turnout and Block Status |
The following table is provided to assist in simplifying the configuration of signal mast aspects. The configurations are listed based on the number of signal aspects to be set (heads and lamps) and what is influences the aspect downstream of the signal (blocks, turnouts, masts).
To further simplify the planning:
Stop,
Approach, and Clear.Stop,
followed by conditions for Approach, and finally
Clear.Note that up to 4 actions can be executed for true and false conditions, allowing for a tumble-down to be configured for setting up to 4 aspects. For example, when configuring the first signal located at the beginning of a set of blocks between sidings (headblock), configure multiple actions for this signal where each action sets the same aspect downstream signals, thus creating a tumple-down of the signals being set (all appear the same).
The use of Exit and Continue within the
logic statements’ actions signals whether the logic processing for that
group should cease (‘Exit’) or proceed to evaluate the next logic
statement (‘Continue’). Generally, once the appropriate aspect is
displayed based on the evaluated conditions, the logic processing for
that group concludes.
Ordering Conditionals: When crafting a logic statement for a signal, it is standard practice to first assess conditions that necessitate the most restrictive track speed (e.g., Stop), followed by conditions for intermediate speeds (e.g., Approach), and lastly, conditions allowing the least restrictive speeds (e.g., Clear).
| Signal Mast Configuration | Downstream Elements | Logic Group (one or more logic statements) | Visual |
|---|---|---|---|
| Single 2-Lamp Head | 1 Block, 1 Masts, 0 Turnouts | 1. If Block is Occupied, Then Set
aspect to Stop and Continue
Else Set aspect to Clear and
Continue. |
 |
| Single 3-Lamp Head | 1 Block, 2 Mast, 0 Turnouts | 1. If Block is Occupied, Then Set
aspect to Stop and ExitElse
Continue. 2. If Downstream Mast shows Stop, Then Set aspect to
Approach and Continue Else
Set aspect to Clearand Continue. |
 |
| 3-Lamp Head over 2-Lamp Head | 3 Blocks, 3 Masts, 1 Turnout | 1. If Turnout Block is Occupied,
Then Set Upper Head aspect to Stop, Lower
Head aspect to Stop, and Exit
Else Continue.2. If Turnout is Thrown, Then Set Upper Head to
Stop and Continue Else
Continue3. If Downstream Mast shows NOT Clear Then Set Upper Head aspect to
Approach and Continue Else
Set Upper Head aspect to Clear and
Continue.4. If Turnout is Closed OR Divergent Mast shows NOT Clear,
Then Set Lower Head aspect to Stop and
Continue Else Set Lower Head aspect to
Clear and Continue |
 |
| 3-Lamp Head over 3-Lamp Head | 2 Blocks, 2 Masts, 1 Turnout | 1. If Turnout is Diverging, Then
Upper Head Red, Lower Head Green for Diverging Route; 2. If First Block is Occupied, Then Upper Head Red, Lower Head Yellow; 3. Else Upper Head Green, Lower Head Green; |
|
| 2-Lamp Head over 2-Lamp Head | 1 Block, 1 Mast, 1 Turnout (Diverging) | 1. If Turnout is Diverging, Then
Upper Head Red, Lower Head Green; 2. If Block is Occupied, Then Both Heads Red; 3. Else Both Heads Green; |
|
| Twin 3-Lamp Heads (Side by Side) | 2 Blocks, 2 Masts, 2 Turnouts | 1. If Either Turnout is Diverging,
Then Corresponding Head Shows Yellow; 2. If Either Block is Occupied, Then Corresponding Head Shows Red; 3. Else Both Heads Show Green; |
|
| 2-Lamp Head over 3-Lamp Head | 1 Block, 2 Masts, 1 Turnout | 1. If Turnout is Diverging, Then
Upper Head Green, Lower Head Yellow; 2. If Block is Occupied, Then Upper Head Red, Lower Head Red; 3. Else Upper Head Green, Lower Head Green; |
|
| Dwarf Signal, 3-Lamp | 1 Block, 0 Masts, 1 Turnout (Diverging) | 1. If Turnout is Diverging And
Block is Occupied, Then Display Red; 2. If Turnout is Diverging, Then Display Yellow; 3. Else Display Green; |
|
| Vertical Stack of 3-Lamp Heads | 3 Blocks, 3 Masts, Multiple Turnouts | 1. If Any Turnout is Diverging,
Then Corresponding Head Red; 2. If Any Block is Occupied, Then Corresponding Head Yellow; 3. Else All Heads Green; |
|
| 4-Lamp Head (Single or Multiple) | Specialty areas like speed-controlled zones | 1. If Speed Restriction in Place,
Then Display Aspect According to Restriction; 2. If Block Ahead is Occupied, Then Display Yellow; 3. Else Display Green; |
Educational Media – Understanding LCC Fusion – A Clear On-Ramp into LCC-Based Layout Automation – LCC Fusion Podcast – Fusion Hardware Architecture Overview – LCC Fusion Podcast – Cards & Node Basics
Railroad signal systems use different signal types to convey specific operational instructions to train crews. Each signal type exists to answer a particular question, such as whether a block is occupied, whether a route is set, or whether a speed restriction applies.
In the LCC Fusion Project, signal types and deployments are planning concepts, not hardware requirements. They help determine: - What information must be conveyed to operators - Where signals are needed on the layout - How signal behavior should be structured before hardware or configuration decisions are made
This guide provides a conceptual catalog of common railroad signal types and describes where they are typically deployed. It is intended to support early signaling design decisions, not to prescribe how signals are wired, configured, or implemented.
Signal types define why a signal exists and what role it plays. Signal aspects, hardware, and logic define how that role is implemented.
Signal type selection occurs after basic track and route planning but before signal hardware or logic configuration.
During planning, signal types help answer questions such as: - Where must train movement be protected or restricted? - Where advance warning is required before a condition changes - Which locations require operator-facing instructions versus automation-only control - Whether a location requires simple stop/go indication or richer information
A single physical signal mast may serve multiple signal roles depending on layout complexity and operating goals.
The table below lists common signal types, their operational role, and typical deployment locations. Each entry represents a reason to introduce signaling at a location, not a required feature or a mandatory hardware choice.
You do not need to implement every signal type shown. Instead, use this table to identify which roles apply to your layout and which can be omitted.
| Signal Type | Role Description | Typical Deployment Location |
|---|---|---|
| Block Signals | Indicate the status of a block section to ensure only one train occupies a block. | Deployed along the mainline to indicate block occupancy and maintain safe spacing between trains. |
| Speed Signals | Warn of upcoming conditions that require speed reduction or stopping. | Placed before areas where speed reductions are required, such as stations or junctions. |
| Diverging Signals | Indicate a diverging route and the speed at which a train should proceed. | Positioned at junctions or where tracks diverge to indicate route selection and speed. |
| Crossover Signals | Control train movements over crossovers between parallel tracks. | At crossovers between parallel tracks to manage train movements across these tracks. |
| Interlocking Signals | Govern entry into and exit from interlocking limits, controlling movements through junctions. | At the entrance and exit of interlocking areas to control movements through complex track layouts. |
| Distant Signals | Act as a preliminary warning to an upcoming stop signal or condition. | Before stop signals or significant track conditions to provide advance warning to train crews. |
| Shunting Signals | Permit trains to move into or out of sidings or perform shunting movements. | In yards, sidings, or where trains or cars are assembled or disassembled. |
| Stop Signals | Require trains to come to a complete stop. | At points where trains must stop for operational reasons, such as station platforms or block endpoints. |
| Aspect Signals | Convey how a train should proceed using defined visual indications. | Used wherever detailed operator-facing instructions are required. |
| Cab Signals | Provide track condition information directly within the train cab. | Used in conjunction with trackside signals or as a primary signaling system within the train cab. |
| Automatic Block Signals | Operate automatically based on track conditions and train presence. | Used along mainlines where signaling responds directly to train movement. |
| Temporary Speed Restriction Signals | Indicate a temporary reduction in speed due to track work, obstructions, or other conditions. | At locations where temporary conditions necessitate a reduction in speed. |
This list covers the most common types of signals based on their roles in railroad operations. The specific implementation and appearance of these signals can vary by country and rail system, but their fundamental purposes are generally consistent worldwide.
Educational Media – Understanding LCC Fusion – A Clear On-Ramp into LCC-Based Layout Automation – LCC Fusion Podcast – Fusion Hardware Architecture Overview – LCC Fusion Podcast – Cards & Node Basics
Sound on a model railroad layout provides auditory feedback, atmosphere, and narrative context, enhancing realism and helping convey what is happening on the layout beyond what can be seen.
In the LCC Fusion Project, sound playback is implemented using the Sound Card, which plays preloaded audio in response to LCC events. These events may originate from sensors, buttons, logic rules, automation sequences, or other nodes on the network.
Sound defines what is heard on the layout; logic, signaling, and automation define when and why it plays. The Sound Card executes audio playback only and never encodes behavior.
Sound planning begins when you decide which moments, locations, or conditions on the layout should produce audible feedback and why. Each sound should serve a purpose, such as providing operator confirmation, enhancing immersion, guiding visitor attention, or explaining scene context.
Planning involves determining: - Where sound adds meaningful value versus distraction - Whether sounds are ambient, event-driven, or instructional - How many independent audio zones are needed - Physical placement of speakers relative to the scene elements they support
A Sound Card is installed in a Node Bus Hub and connects to one or more speakers either directly or via a Digital I/O Breakout Board. Speakers are typically placed close to the scene they represent to maintain spatial realism and reduce wiring complexity.
When planning sound integration: - Group related sounds so they can be served by the same Sound Card - Consider speaker placement, enclosure, and sound direction - Plan for accessibility to adjust or replace speakers if needed - Allow for expansion if additional scenes or narration are added later
The table below lists common planning use cases that drive the need for sound playback on a layout. Each entry represents a potential reason to include sound, not a required feature.
| Sound Category | Description |
|---|---|
| Locomotive Engine Sounds | Recreate the sounds of steam, diesel, or electric engines, including startup, running, and shutdown noises. |
| Train Whistles and Horns | Different types of whistles and horns for various locomotives, signaling arrivals, departures, and crossings. |
| Rail Clack and Wheel Sounds | The rhythmic sound of train wheels rolling over track joints, creating the classic ‘clickety-clack’ noise. |
| Station Announcements | Automated announcements for arrivals, departures, and other station information. |
| Ambient Station Sounds | Background noise found in stations, like crowd chatter, footsteps, and luggage movement. |
| Level Crossing Bells and Warnings | The sound of bells or alarms at crossings as trains approach. |
| Industrial Sounds | For industrial areas, include sounds like machinery, factory whistles, or trucks loading and unloading. |
| Scenic Nature Sounds | Birdsong, water flowing, wind, and other nature sounds for rural or wilderness areas. |
| City and Urban Sounds | Traffic noise, car horns, sirens, and general city bustle for urban landscapes. |
| Emergency Vehicle Sirens | Police, ambulance, and fire engine sirens for emergency scene recreations. |
| Airplane or Airport Sounds | If your layout includes an airport, sounds of airplanes taking off and landing add realism. |
| Harbor and Maritime Sounds | Sounds of boats, foghorns, and seagulls for layouts with water features or docks. |
| Amusement Park or Carnival Sounds | Music, laughter, and ride sounds for layouts featuring a fairground or amusement park. |
| Weather Effects | Thunderstorms, rain, or wind sounds to simulate weather conditions. |
| Animal Sounds | Farm animal noises or wildlife sounds for rural areas. |
Educational Media – Understanding LCC Fusion – A Clear On-Ramp into LCC-Based Layout Automation – LCC Fusion Podcast – Fusion Hardware Architecture Overview – LCC Fusion Podcast – Cards & Node Basics
Turnouts define how trains move through a layout by determining which routes are available at any given time. In the LCC Fusion Project, turnout control is implemented using the Turnout Card, which drives turnout motors and generates events reflecting turnout state.
The Turnout Card does not decide when a turnout should move; it executes movement in response to LCC events generated by buttons, logic, schedules, or other automation.
Turnouts define where trains can go; logic, signaling, and automation define when and why routes change. The Turnout Card performs motion only and never encodes behavior.
Turnout planning begins during layout design when you decide where routes diverge and how those routes should be controlled. Each turnout exists for a reason, such as enabling alternate paths, supporting operational flexibility, or enforcing safe train movement.
Planning involves determining: - Which turnouts are required for the intended operating scheme - How turnouts are grouped by location and function - Whether control is manual, automated, or a combination - How turnout state interacts with signals, detection, and routing logic
The Turnout Card supports multiple turnout outputs, so planning focuses on grouping related turnouts that can be served by the same card.
A Turnout Card is installed in a Node Bus Hub and connects via cable to one or more Turnout Breakout Boards, or directly to turnout machines depending on the installation approach.
When planning turnout control: - Group nearby turnouts to minimize wiring runs - Consider the type of turnout motor being used (stall, servo, coil) - Plan for frog polarity control if required - Allow spare capacity for future track expansion
Breakout boards are typically placed near turnout machines to simplify wiring and improve serviceability.
Each use case below represents a reason to include automated turnout control in a layout design. You do not need to implement every item; each entry reflects a planning motivation rather than a required feature.
| Category | Turnout control use | Description |
|---|---|---|
| Operations | Managing turnout positions | Control the precise position of each turnout, switching between “thrown” and “closed”. |
| Operations | Automating route selection | Automatically select routes for trains to ensure smooth transitions at junctions. |
| Operations | Creating complex track layouts | Operate layouts with multiple junctions and crossover points. |
| Operations | Reducing manual intervention | Minimize manual turnout operation during exhibitions or automated running. |
| Automation | Sequencing turnout movements | Execute predefined sequences of turnout movements for scenarios or displays. |
| Signaling | Integrating with signal systems | Synchronize turnout positions with signals for safe and realistic operation. |
| Coordination | Coordinating with train schedules | Align turnout movements with scheduled train movements. |
| Safety | Implementing fail-safe operations | Automatically set turnouts to a safe position during faults or emergencies. |
| Interaction | Enhancing layout interactivity | Allow operators to manually command turnout positions when desired. |
Educational Media – Understanding LCC Fusion – A Clear On-Ramp into LCC-Based Layout Automation – LCC Fusion Podcast – Fusion Hardware Architecture Overview – LCC Fusion Podcast – Cards & Node Basics
In the LCC Fusion Project, reliable wired communication between nodes is achieved using the CAN Bus standard. CAN (Controller Area Network) provides robust, differential signaling that is ideal for noisy environments and long cable runs.
In addition to wireless options such as Wi-Fi and ESP-NOW (which are optional and not required to understand this guide), LCC Fusion supports wired node-to-node connections using a wired CAN Bus.
Identify the Bus Ends
In the LCC Fusion Project:
The Node Card, Quad-Node Card, and Node Bus Hub all include automatic termination circuits.
Automatic CAN termination applies when using LCC Fusion hardware exclusively; manual termination is only required when integrating non-Fusion CAN devices at the ends of the bus.
Termination is engaged only when the device is physically at the end of the bus.
No jumpers, switches, or manual configuration are required.
When sharing the CAN Bus with other LCC devices (non-Fusion):
Select Cabling
Chain Hubs if Needed
Multiple LCC Fusion Project Node Bus Hubs (PCB boards) can be interconnected to expand the system.
Each hub provides both multiple 8-pin headers (for direct board-to-board connections) and a pair of RJ45 sockets (for remote connections using standard CAT5/6 network cables).
Node Bus Hubs may be chained together as a planning option when layouts expand beyond a single physical hub.
This flexibility allows hubs to be chained together locally or over longer distances while maintaining proper signal integrity on the CAN backbone.
Automatic termination still ensures that only the physical endpoints of the combined chain are terminated.
The diagram below is a conceptual illustration of CAN topology and hub relationships; it is not intended to represent exact wiring or physical placement.
flowchart LR;
nonFusionNode["Non-LCC Fusion<br>Node/Device<br>(CAN Bus Termination)"]
can(("CAN Bus"));
hub[["LCC Fusion<br>Node Bus Hub"]];
hub2[["LCC Fusion<br>Node Bus Hub"]];
n1[["LCC Fusion<br>Node Card<br>(CAN Bus Auto-termination)"]];
n2[["LCC Fusion<br>Node Card<br>(CAN Bus Auto-termination)"]];
pc[["LCC Fusion<br>Power-CAN Card"]];
iocards[["LCC Fusion<br>I/O Cards"]];
iocards2[["LCC Fusion<br>I/O Cards"]];
bb1[["LCC Fusion<br>Breakout Boards"]];
bb2[["LCC Fusion<br>Breakout Boards"]];
subgraph layout ["Train Layout"];
direction LR;
nonFusionNode --> can;
can --> n1;
can --> pc;
subgraph Installation ["LCC Fusion<br>Installation"]
n1 <--> |"CAN"|hub;
pc --> hub;
hub <--> |"CAN"|hub2;
hub --> |"Network Cable, or <br/> Direct Connection"| hub2;
hub --> iocards;
hub2 --> iocards2;
n2 <--> |"CAN"|hub2;
end;
iocards <--> bb1 <--> devices((Devices));
iocards2 <--> bb2 <--> devices2((Devices));
end;
classDef lSalmonStyle fill:#FFA07A,stroke:#333,stroke-width:2px,font-size:24px;
class hub,hub2 lSalmonStyle;
classDef lightGrayStyle fill:#d3d3d3,stroke:#333,stroke-width:2px,font-size:24px;
class layout lightGrayStyle; For general questions about CAN wiring and behavior, see the main FAQ.
Educational Media
– Understanding LCC Fusion – A Clear On-Ramp into LCC-Based Layout Automation – LCC Fusion Podcast – Fusion Hardware Architecture Overview – LCC Fusion Podcast – Cards & Node Basics
Wireless node-to-node communication is an optional planning tool in LCC Fusion. It supplements wired CAN Bus in cases where cabling is impractical, temporary, or mobile.
LCC Fusion supports two wireless transport mechanisms, each with different planning implications:
Wireless connectivity extends CAN communications between nodes without changing how hardware is physically organized.
In a wireless configuration:
Wireless links do not create a new grouping type and do not replace hubs, pods, or power planning. They provide an alternative transport mechanism for CAN participation when physical wiring is impractical or undesirable.
Educational Media – Understanding LCC Fusion – A Clear On-Ramp into LCC-Based Layout Automation – LCC Fusion Podcast – Fusion Hardware Architecture Overview – LCC Fusion Podcast – Cards & Node Basics
This example illustrates how LCC Fusion can be used to build an interactive, self-contained diorama that demonstrates automation, sensing, sound, lighting, and optional train interaction.
Unlike operational track scenarios, a diorama emphasizes experience and interaction:
This guide focuses on planning decisions, not installation or configuration.
The diorama includes:
All components are contained within a single Pod, with breakout boards placed near scene elements.
The table below identifies required hardware and optional capabilities commonly planned for an interactive diorama.
| LCC Fusion Hardware | Quantity | Purpose |
|---|---|---|
| Node Bus Hub | 1 | Required. Distributes power and communication to all cards |
| Node Card | 1 | Required. Hosts the diorama logic, events, and configuration |
| Digital I/O Breakout Board | 1 | Optional. Connects buttons and diorama lighting |
| Button Card | 1 | Required. Handles visitor interaction via push buttons |
| Button Breakout Board | 1 | Required. Connects physical buttons to the Button Card |
| Sensor Card | 1 | Optional. Supports proximity or presence detection (e.g., visitor approaches) |
| Sensor Breakout Board | 1 | Optional. Connects IR, ultrasonic, or other sensors |
| Audio Card | 1 | Optional. Provides sound effects or narration to a diorama speaker |
| PWM Card | 1 | Optional. Controls scene lighting or simple signal lamps |
| Signal Breakout Board | 1 | Optional. Connects to LEDs and lighting circuits |
| UOD Card | 1 | Optional. Detects a person approaching the diorama |
| UOD Breakout Board | 1 | Optional. Connects ultrasonic or proximity sensors |
| BOD Card | 1 | Optional. Detects occupancy if a locomotive is added |
| Block Breakout Board | 1 | Optional. Connects to track feeders |
| DCC Card | 1 | Optional. Provides DCC power for a short track section |
| BSD Card (Block Reversing Detection) | 1 | Optional. Enables unattended or reversing track operation |
| BRD Breakout Board | 1 | Optional. Connects to mainline and reversing loop blocks |
Key planning takeaway: A compelling diorama can be built with just a Node Card, Node Bus Hub, and Button Card, with all other hardware added incrementally to enhance interaction and realism.
All logic and control cards are typically centralized in a compact Pod:
This simplifies:
Breakout boards are placed near scene elements:
This keeps wiring short and unobtrusive.
Buttons may be planned to:
Buttons define intentional interaction, distinct from automated sensing.
Using a Sensor Card or UOD Card, the diorama can respond when a person approaches:
This supports hands-off operation in public settings.
Audio can be planned for:
Audio playback is event-driven and can be triggered by:
Using a PWM Card, lighting may include:
Lighting reinforces interaction and provides immediate visual feedback.
If a locomotive is added later:
Planning for this early avoids redesign but does not require immediate implementation.
This separation is especially important in compact diorama builds.
This example demonstrates that LCC Fusion supports:
It reinforces that LCC Fusion is not limited to track-centric automation.
Educational Media
– Understanding LCC Fusion – A Clear On-Ramp into LCC-Based Layout Automation – LCC Fusion Podcast – Fusion Hardware Architecture Overview – LCC Fusion Podcast – Cards & Node Basics
LCC Fusion is an open‑source automation platform for model railroads built on NMRA LCC (Layout Command Control). It combines inexpensive hardware, modular PCBs, and event‑driven networking to let you design, build, and expand layout automation in a structured, scalable way.
This page is your orientation guide. Its purpose is not to teach every detail, but to help you understand where to begin, how the documentation is organized, and which path makes sense for you.
If you are completely new to LCC or want the architectural “big picture,” start here first:
If you want help navigating the documentation and posts ecosystem:
LCC Fusion spans hardware, firmware, wiring, and system design. Most users wear more than one hat, but thinking in terms of roles helps you find the right documentation quickly.
Use the site navigation and the Explore Subjects page to browse documentation by role and topic.
The table below maps common roles to the parts of the documentation most relevant to them.
Not sure where to begin? Start with the Quickstart Paths to try a simple working example.
| Role | Responsibility | Start Here |
|---|---|---|
| Builder | Expert in assembling, wiring, and troubleshooting hardware cards and breakout boards. Recommends component choices and PCB build practices. | Builder’s Guides |
| Layout Planner | Designs the block structure, signal plans, and sensor layout for the railroad. Focuses on automation flow and system behavior. | Planner’s Guides |
| Layout Installer | Does the wiring and network setup. Connects LCC nodes. Connects the Fusion nodes, cards, breakout boards, and devices. | Installer’s Guides |
| Administrator | Configures the firmware for the installed devices. Configures CDI, and ensures LCC events are routed correctly across the system. | Configurator’s Guides |
| Firmware Developer | Writes and customizes firmware for LCC Node devices, manages CDI structure, and builds automated test logic. | Developer’s Guides |
LCC Fusion documentation is organized by intent, not by board name alone:
This structure lets you enter at different points depending on your experience and goals.
LCC Fusion is built around modular hardware:
You do not need every card to get started. Most users begin with a single Node Card and expand as needed.
If your goal is to assemble boards:
Hardware guides are written to assume basic soldering skills and a multimeter, not professional electronics experience.
LCC Fusion uses CDI (Configuration Description Information) to define behavior such as:
To get started with configuration:
These tools allow configuration without writing code and are central to how Fusion remains flexible as layouts grow.
Installation covers:
Use the Installer’s Guides for wiring diagrams, connection tables, and best practices.
Once installed and configured, LCC Fusion supports:
Examples and scenarios are documented throughout the Planner’s and Quickstart sections.
If something does not behave as expected:
This project is licensed under the CERN Open Hardware License Version 2 - Permissive (CERN-OHL-P v2.0).
This license allows you to use and modify this design for any purpose, including commercial, provided that you:
Attribute the original source of the design to us by including the following copyright notice in all copies or substantial portions of the licensed material:
“Copyright (C) [Year] [Your Name or Organization’s Name]. This work is licensed under the CERN OHL-P v2.0.”
Include a copy of the license itself with the distributed work. The license text is available at: https://ohwr.org/cern_ohl_p_v2.txt
Indicate if changes were made to the original design, in a way that is trackable from the modified work back to the original source.
Applying the License
To apply the CERN OHL-P v2.0 to your work, include a file named
LICENSE or LICENSE.txt in the root of your
project source repository, containing the full text of the license, and
reference the license in your README as shown here.
For more details on the license, its permissions, conditions, and limitations, please read the full license text at the link provided above.
Based on the copyright notice and license conditions you’ve provided, it seems you are using a license similar to the BSD 2-Clause “Simplified” License for your firmware. Here is a Markdown (MD) template for the “License” section of your README file that reflects this license. Make sure to replace [firmware Name] with the actual name of your firmware project.
This firmware is licensed under the BSD 2-Clause “Simplified” License.
Copyright
This license permits personal and commercial use, distribution, and modification of the firmware under the following conditions:
Redistribution: Redistribution of source code must retain the above copyright notice, this list of conditions, and the following disclaimer. Redistribution in binary form must reproduce the copyright notice, this list of conditions, and the following disclaimer in the documentation and/or other materials provided with the distribution.
Disclaimer: THIS FIRMWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS FIRMWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Applying the License
To apply this license to your firmware, include a file named
LICENSE or LICENSE.txt in the root directory
of your project source repository, containing the full text of this
license. Reference this license in your project’s README file as shown
here to inform users and contributors of the licensing terms.
For more information on the BSD 2-Clause “Simplified” License, visit https://opensource.org/licenses/BSD-2-Clause.
LCC Fusion is provided “as is”, without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose, and noninfringement. In no event shall the authors or copyright holders be liable for any claim, damages, or other liability, whether in an action of contract, tort or otherwise, arising from, out of, or in connection with the firmware or the use or other dealings in the firmware/hardware.
The user assumes all responsibility and risk for the use of this firmware/hardware. The information and powered hardware provided are subject to change without notice and should not be construed as a commitment by the author.
Use caution and common sense when working with electrical components and always follow the manufacturer’s instructions and safety guidelines. The creator of this project cannot be held responsible for any injuries, damages, or violations of local codes or laws that may arise from the use of this project.
This guide defines the minimum LCC Fusion hardware
required to implement a simple half-siding within a single Pod.
It is intended as a planning reference, not an
installation or configuration guide.
The half-siding example represents a common real-world scenario: - A turnout branching from a mainline - A siding track protected by signals - Occupancy detection used to influence signaling and turnout behavior
This guide focuses on what hardware is required, where it is physically placed, and how capacity is planned.
This example assumes familiarity with earlier planning guides and focuses on applying those concepts to a concrete layout scenario.
The half-siding includes:
No node-to-node networking is assumed.
| LCC Fusion Hardware | Quantity | Purpose |
|---|---|---|
| Node Card | 1 | Hosts firmware, logic execution, and LCC event handling for the half-siding |
| Node Bus Hub | 1 | Interconnects all cards in the pod and distributes power and communication |
| Turnout Card | 1 | Controls the turnout motor and reports turnout position |
| Turnout Breakout Board | 1 | Connects the Turnout Card to the physical turnout machine |
| PWM Card | 1 | Drives signal LEDs with controlled brightness and aspect control |
| Signal Breakout Board | 1 | Connects signal heads to PWM outputs |
| BOD Card | 1 | Detects block occupancy for the siding and mainline |
| Block Breakout Board | 1 | Interfaces between track wiring and the BOD Card inputs |
The following components are typically centralized in one physical location, such as under the layout or inside a control enclosure:
These cards: - Share power and communication via the Node Bus - Benefit from short, clean interconnections - Are easier to service and expand when grouped together
This centralized arrangement forms the pod core.
Breakout boards are placed near the physical devices they serve:
This placement: - Minimizes long runs of device wiring - Keeps high-current or layout-voltage wiring off the pod - Simplifies troubleshooting and future changes
A typical half-siding may be divided into the following occupancy blocks:
This results in 6 blocks total, well within the capacity of a single BOD Card.
A single BOD Card supports up to 8 blocks, allowing headroom for expansion or refinement.
Signal planning directly affects PWM and Signal Breakout Board requirements.
Example signal usage for a half-siding:
This example might include: - 5 × 3-lamp signals - 8 × 2-lamp signals
A single Signal Breakout Board supports up to: - 16 individual lamps - Or combinations such as: - Five 3-lamp signals (15 lamps total) - Eight 2-lamp signals (16 lamps total)
Proper lamp counting during planning ensures: - Correct selection of PWM Cards - Correct number of Signal Breakout Boards - No redesign later due to capacity limits
This keeps the pod compact and modular.
Breakout boards connect to the layout accessory bus, not the Node Bus.
Typical uses include: - Turnout motor power - Signal LED power - Track connections for occupancy detection
This separation ensures: - High-current or layout-voltage wiring stays off the pod - Logic electronics remain isolated - Cleaner wiring and safer expansion
When planning a half-siding, consider:
These decisions influence capacity planning, not basic hardware selection.
This half-siding example serves as:
Educational Media
– Understanding LCC Fusion – A Clear On-Ramp into LCC-Based Layout Automation – LCC Fusion Podcast – Fusion Hardware Architecture Overview – LCC Fusion Podcast – Cards & Node Basics
A Technical Overview of the LCC Fusion Hardware & Software Ecosystem
This page provides a structured look at everything the LCC Fusion Project can do — from automation and sensing to audio, voice control, and external system integration.
LCC Fusion uses inexpensive ESP32 hardware, NMRA LCC standards, and more than 50 open-source cards and breakout boards designed for DIY hobbyists.
Once configured, layouts can operate fully standalone with no computer required during normal operation.
Supports 3-wire active sensors: - IR modules
- Hall effect
- HTTM capacitive touch
- Ultrasonic triggers
- Phototransistors
Each port includes: - GND
- 3.3 VDC
- Protected signal line
Generates LCC Events for automation, lighting, announcements, or turnout control.
### Alexa / Hue Integration - No extra hardware
- Firmware translates voice commands into LCC Events
- Supports:
- On/off devices
- Dimmable devices
- Scenes
- Variable outputs (0–255)
- Custom announcements
Example commands:
- “Alexa, set Station 4 to 50%”
- “Alexa, trigger Train Departure”
- “Alexa, turn on Yard Lights”
When setting up your LCC Fusion Node Cluster(s) for model railroad automation, a crucial consideration is the choice of power supply configuration. Efficient power management ensures stable operations, longevity of the components, and safety. It is essential to understand the power requirements of each component within the cluster to ensure that your chosen power supply can adequately support the entire system without risk of overload or insufficient power delivery.
Below are options for powering the LCC Fusion Node Cluster using one or more power supplies and various connection option. Select a method that works best based on planned usage.
Note: This document specifically addresses DC power supply configurations, as the LCC Fusion Node Cluster is designed to operate exclusively with DC power supplies. AC power configurations are not supported and are not covered here.
A Common Ground is the shared 0 VDC reference that ties together all logic, power, and devices in an LCC Fusion system. Without a common ground, signals between cards and breakout boards cannot be interpreted reliably, and current may return through unsafe or undefined paths.
Rule of Thumb
All signals and devices must share one common ground for reliable operation. Tie all DC− rails to the Node’s ground plane at a single point, and never attempt to bond power supplies at the AC input side.
Power consumption can often be misunderstood when looking at individual component current ratings. At first glance, it may seem like an ESP32 drawing 200 mA could quickly consume available power in a 3A system. However, real-world power distribution accounts for voltage levels, regulator efficiency, and actual current needs at different supply voltages.
Higher input voltages reduce current draw at the source while allowing efficient conversion to lower voltages using switching regulators. This means that a 65W power supply is more than sufficient to support an LCC Node Cluster with multiple I/O cards, breakout boards, and ESP32-based components.
This guide provides realistic power consumption estimates to help users select an appropriate DC power supply based on actual energy needs, rather than just summing up component current ratings.
| LCC Fusion Cards/Boards | 12 VDC Load (mA) | 5 VDC Load (mA) | 3.3 VDC Load (mA) | Power (W) | 16 VDC Input (mA) | 24 VDC Input (mA) | 35 VDC Input (mA) | Notes |
|---|---|---|---|---|---|---|---|---|
| LCC Node Card (no I/O, WiFi, or Bluetooth) | 5 | 80 | 2 | 0.48W | 30 | 20 | 14 | 80 mA for ESP32 and manages Node Bus communication without Bluetooth and WiFi enabled. 7mA for idle regulators. |
| BOD Card (1 detection) | 0 | 0 | 20 | 0.16W | 10 | 7 | 5 | 27 mA for IC + 3mA for 1 LED on. |
| PWM Card (16 lamps @ 15%) | 0 | 16×3 | 0 | 0.32W | 20 | 13 | 9 | 3mA per LED. |
| Turnout Card (1 Tortoise) | 20+20 | 0 | 1 | 0.48W | 46 | 32 | 22 | 21 mA for Turnout Card components + 20 mA Tortoise |
| Output Card (8 LEDs @ 15%) | 0 | 8×3 | 0 | 0.16W | 10 | 7 | 5 | 7mA for ICs, 3mA per LED at 15% brightness with 1K resistor. |
The estimated power consumption for a basic signaling configuration (Node Card with 5 I/O cards and breakout boards) is only ~2.6W as shown below. This is significantly lower than the typical computer laptop 65W power supply capacity, indicating plenty of available power for expansion.
Additionally, the maximum current capacity of the Node Card power traces and regulators is 3A, which is well above the estimated current draw in typical configurations. This means that a single LCC Node Cluster can support a large number of hardware devices within the network without exceeding power limitations.
| Use Case | Card / Breakout Board | Power Supply @ 24 VDC (mA) |
|---|---|---|
| Detection, turnout, signaling for track spur | 1x LCC Node Card 1x BOD Card /w 4 detections 1x PWM Card /w 16x LEDs on 1x Turnout Card /w 1x Tortoise |
20 07 13 32 Total 72 mA (1.7W) |
| Detection, turnouts, signaling for track siding | 1x LCC Node Card 2x BOD Card /w 8 detections 2x PWM Card ea/w 16x LEDs 1x Turnout Card /w 2x Tortoise |
20 14 26 48 Total 108 mA (2.6W) |
| Component/Board | Power Supply (DC) | Node Bus Hub (DC) | Layout Power Bus (AC/DC/DCC | Notes | Ground Reference Requirements |
|---|---|---|---|---|---|
| LCC Node Card | Yes | No | No | Main processing and network hub. | Provides the system ground plane. |
| All I/O cards | No | Yes | No | Automatically share ground via Node Bus Hub. | |
| Block Breakout Board BLVD Breakout Board BRD Breakout Board |
No | No | DCC | Routes Track Bus and Track Rails to attached card. | N/A – Wiring-only breakout board. Ground not used. |
| DC Motor Driver Breakout Board | No | No | AC DC DCC |
Layout Power Bus AC, DC, and DCC supported via bridge rectifier | Either: 1) Line 8 of PWM Card configured for GND 2) DC Layout Power bus shared with the Node Card’s power supply. |
| Digital I/O Breakout Board | No | Yes | AC DC DCC 5V |
Layout Power Bus AC, DC, and DCC supported via bridge
rectifier.< 5V from Node Card I/O, Digital I/O Card, or Output Card (requires LINE 8 configuration) |
Either: 1) Line 8 of PWM Card configured for GND 2) DC Layout Power bus shared with the Node Card’s power supply. |
| Digital Sensor Breakout Board | No | Yes | No | Uses Node Card (or Sensor Card) 5V/GND, converted to 3V3 and 5V for sensors (requires LINES 7/8 configuration for 5V/GND) | Line 8 of Sensor Card is used. No configuration required. |
| NeoPixel Breakout Board | No | Yes | AC DC DCC |
Layout Power Bus AC, DC, and DCC supported via bridge
rectifier.< 5V from Node Card I/O or PWM Card (requires LINE 8 configuration for GND) |
Either: 1) Line 8 of PWM Card configured for GND 2) DC Layout Power bus shared with the Node Card’s power supply. |
| Node Analog Sensor Breakout Board | No | Yes | No | Uses Node Card 5V/GND, converted to 3V3 for 3-wire sensors. | Always uses Node GND via Line 8 (required). |
| NFC Tag Reader Breakout Board | No | Yes | No | Always uses Node GND via Line 8 (required). | |
| POD Breakout Board | No | Yes | No | Comparator outputs must be tied to Node GND. | |
| Relay Breakout Board | No | Yes | AC DC DCC 5V |
Layout Power Bus AC, DC, and DCC supported via bridge
rectifier. 5V from attached card (requires LINE 8 configuration for GND) |
Either: 1) Line 8 of Node Card I/O, Digital I/O Card, or Output Card configured for GND 2) DC Layout Power bus shared with the Node Card’s power supply. |
| Servo Motor Breakout Board | No | Yes | AC DC DCC |
Uses either: Layout Power Bus (AC, DC, and DCC) supported via bridge rectifier. 12V from PWM Card (requires LINES 7/8 configuration for 12V/GND) |
Either: 1) Line 8 of PWM Card configured for GND 2) DC Layout Power bus shared with the Node Card’s power supply. |
| Signal Masts Breakout Board | No | Yes | AC DC DCC |
Uses either: Layout Power Bus (AC, DC, and DCC) supported via bridge rectifier. 5V/12V from PWM Card (requires LINES 7/8, 15/16 configuration for VDC+/GND) |
Either: 1) Lines 8/16 of PWM Card configured for GND 2) DC Layout Power bus shared with the Node Card’s power supply. |
| Stepper Motor Breakout Board | No | No | AC DC DCC |
AC, DC, and DCC supported via bridge rectifier. | Motor supply DC− must be bonded to Node GND for control signals. |
| Test Breakout Board | No | No | AC DC DCC |
AC, DC, and DCC supported via bridge rectifier. | Rectifier DC− must be tied to Node GND. |
| Turnout - Twin-Coils Switch Machine Breakout Board | No | No | AC DC DCC |
AC, DC, and DCC supported via bridge rectifier. | Coil supply DC− must be tied to Node GND. |
| Turnout - Servo Switch Machine Breakout Board | No | No | AC DC DCC |
AC, DC, and DCC supported via bridge rectifier. | Servo supply DC− must be tied to Node GND. |
| UOD Breakout Board | No | Yes | No | Comparator outputs must be tied to Node GND. |
| Component/Board | Power Supply (DC) | Node Bus Hub (DC) | ACC BUS (DC) | Track Bus (DCC) | ACC BUS (AC) | Notes |
|---|---|---|---|---|---|---|
| LCC Node Card | Yes | No | No | No | No | Main processing and network hub. |
| All I/O cards | No | Yes | No | No | No | |
| Audio Breakout Board | No | Yes | No | No | No | |
| Block Breakout Board | No | No | No | Yes | No | |
| DC Motor Driver Breakout Board | No | No | Yes | Yes | Yes | Required 5V or 12 VDC from a power bus. AC, DC, and DCC supported via bridge rectifier. |
| Digital I/O Breakout Board | No | Yes | Yes | Yes | Yes | AC, DC, and DCC supported via bridge rectifier, or 5V via attached card (lines 7/8) |
| Digital Sensor Breakout Board | No | Yes | No | No | No | Uses Node Card (or Sensor Card) 5V/GND, converted to 3V3 and 5V for sensors. |
| NeoPixel Breakout Board | No | No | Yes | Yes | Yes | AC, DC, and DCC supported via bridge rectifier. |
| Node Analog Sensor Breakout Board | No | Yes | No | No | No | Uses Node Card 5V/GND, converted to 3V3 for 3-wire sensors. |
| NFC Tag Reader Breakout Board | No | Yes | No | No | No | |
| POD Breakout Board | No | Yes | No | No | No | |
| Relay Breakout Board | No | Yes | Yes | Yes | Yes | AC, DC, and DCC supported via bridge rectifier, or 5V via attached card (lines 7/8) |
| Servo Motor Breakout Board | No | Yes | Yes | Yes | Yes | AC, DC, and DCC supported via bridge rectifier. 12 VDC from Node Bus Hub via PWM Card |
| Signal Masts Breakout Board | No | Yes | Yes | No | No | Use of ACC BUS is optional |
| Stepper Motor Breakout Board | No | No | Yes | Yes | Yes | AC, DC, and DCC supported via bridge rectifier. |
| Test Breakout Board | No | No | Yes | Yes | Yes | AC, DC, and DCC supported via bridge rectifier. |
| Turnout - Twin-Coils Switch Machine Breakout Board | No | No | Yes | Yes | Yes | AC, DC, and DCC supported via bridge rectifier. |
| Turnout - Servo Switch Machine Breakout Board | No | No | Yes | Yes | Yes | AC, DC, and DCC supported via bridge rectifier. |
| UOD Breakout Board | No | Yes | No | No | No |
Note: While the Node Card itself usually receives its power from the accessory bus (if not from a dedicated power supply), many breakout boards will also draw some current from the same accessory bus. In several cases this is not just for the board’s logic, but also to power attached I/O devices such as LEDs, relays, servos, or motors. When planning total accessory bus capacity, be sure to account for both the Node Cards and the cumulative loads from all connected breakout boards.
There are two main approaches to powering your LCC Node I/O cards and the attached LEDs, each with its benefits and considerations.
The simplest method is to employ a single power supply to power both the LCC Fusion Node Cluster(s) and the layout accessories. In this configuration, all LCC Fusion Project components, including layout accessories like LEDs attached to the I/O cards, share a common ground. This approach minimizes complexity and reduces the number of components required. It’s ideal for setups where all of the power requirements of the layout accessories and the LCC Fusion Node Cluster are within the capacity of a single power supply, ensuring a streamlined and efficient power management system.
Advantages of the single power supply configuration include:
For more extensive setups or where the power demands exceed the capacity of a single supply, a dual power supply configuration can be used. In this scenario, one power supply is dedicated to the LCC Fusion Node Cluster and its I/O cards, while a second, separate power supply is responsible for providing power to layout accessory devices (i.e. LEDs, etc.). Importantly, these devices will ground through a layout accessory bus’s common ground back to the second power supply. Despite using two power sources, both power supplies share the same ground—this can be achieved through a common power strip or connected to the layout room ground to ensure stability and prevent potential electrical interference.
The dual power supply configuration offers several benefits:
In summary, the choice between a single or dual power supply configuration depends on your specific needs, including the scale of your LCC Fusion Node Cluster, power requirements, and considerations for cost, complexity, and safety. It’s essential to carefully plan your power supply strategy to ensure a stable and efficient operation of your model railroad automation system.
The LCC Fusion Project provides several methods of power a LCC Fusion Node Cluster, a single LCC Card, or just I/O cards. This can be useful while testing new hardware, configuring an LCC Node, or for distributing multiple LCC Node Clusters or I/O cards around an under your layout. These options can be use for both convience and simplifying layout wiring while providing optins for integration with a layout power grid.
Below is a table summarizing the use cases for each type of power input connector available with the LCC Fusion Project hardware. This table is designed to help planners choose the most appropriate connector based on their requirements, including the number of secondary LCC Nodes, LCC Node Clusters, LCC Node Bus Hub(s), and I/O cards to connect and their preferred power sources.
Refer to Terminology for an explanation of terms used below
| Connector Location | Power Input Connector | Power Module | Max Current / Voltage | Use Cases | Why Choose This? | Considerations |
|---|---|---|---|---|---|---|
| DevKit-C Module on LCC Fusion Node Card | USB Connector | No | 2A / 5V | Use while testing a LCC Fusion Node Cluster and using the computer’s serial monitor. | LCC Node has an integrated management system for bench testing hardware. Don’t use for non-testing to prevent damage to the DevKit-C Module circuitry. | Use computer based serial monitors such as Arduino IDE, PuTTY, RealTerm,Tera Term, CoolTerm, and YAT. |
| LCC Node Bus Hub | USB-C Connector | No | 3A / 5V | Use while testing or temporarily powering a small LCC Fusion Node Cluster. | Simplifies adding power from any location using a USB cable. When using a LCC Fusion Node Card, consider using a Power Module for more robust power supply and protection. | Use temporarily when 12 VDC+ is not required and working with a small LCC configuration. Computer power adapters can provide up to 3A with a USB-C plug. |
| LCC Node Bus Hub | 1) Network Cable Sockets (RJ45) 2) 8-Pin Female Pin Headers |
No | 600 mA / 3V3, 5V, 12 VDC+ | Use when expanding the LCC LCC Fusion Node Bus with additional LCC Node Bus Hubs without a Primary LCC Fusion Node Card. | Required for expansion (secondary) LCC Node Bus Hub to receive power
and communications from another LCC Node Bus Hub. Useful when powering additional Node Bus Hubs with centralized locations around the layout. |
Use CAT6 network cable to carry more current. Secondary Node Bus Hub can be daisy chained together. |
| LCC Fusion Node Card | CAN Bus Network Cable Sockets (RJ45) | Yes | 600 mA / 12-35 VDC | Smaller networks with a focus on simplicity and integration of power and communication in one cable. Ideal for scenarios where the layout is compact or the number of secondary LCC Nodes is limited. | Simplifies cabling by integrating power and communications. Less clutter and easier to manage in smaller setups. | Limited to 3-5 secondary LCC Nodes. Requires network cable between LCC Nodes. |
| Power-CAN Card | USB-C or DC-005 (barrel connector) | Yes | 2A / 12-35 VDC | Medium-sized networks requiring more secondary LCC Nodes.
Suitable for users with readily available USB-C power supplies (e.g., laptop chargers). Good balance between power capacity and convenience. |
Easy connect/disconnect of power. Utilizes common, modern power supplies. Offers a good mix of power capacity and ease of use. |
Suitable for a moderate number of secondary LCC Nodes. |
| Power CAN-Card | Spring/Screw Terminal, or ATX 5557 Connector | Yes | 3A / 12-35 VDC | Larger networks with a higher number of secondary LCC Nodes. Ideal for users who prefer to use their layout accessory power supply, providing the highest power capacity. | Maximizes the number of secondary LCC Nodes that can be connected. Best for extensive layouts requiring significant power distribution. | Leverages existing layout accessory power supply. Supports max number of LCC Nodes. LCC Fusion Node Cluster can be serially connected using both input and output ATX connectors. |
This table offers a straightforward comparison to help planners make informed decisions based on their specific needs and preferences for their model railroad automation projects. Each connector option caters to different scales and complexities of layout setups, ensuring flexibility and adaptability in planning and implementation.
Educational Media – Understanding LCC Fusion – A Clear On-Ramp into LCC-Based Layout Automation – LCC Fusion Podcast – Fusion Hardware Architecture Overview – LCC Fusion Podcast – Cards & Node Basics
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.
All LCC Fusion Node Cards are peers on the CAN network.
This peer model applies whether nodes are located: - on the same hub, - on different hubs within a pod, - or across multiple pods.
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.
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 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.
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.
Node Bus Hubs can be connected in two common ways. Both are supported.
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.
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.
It is fully supported to power a pod using multiple power sources, for example:
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.
This flexibility allows builders to:
Rather than forcing rigid rules, the system supports practical layouts.
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.
All of these are valid.
This guide is about build-out choices, not restrictions.
Key takeaways:
By design, LCC Fusion supports growth without forcing rigid power or topology rules.
Educational Media
– Understanding LCC Fusion – A Clear On-Ramp into LCC-Based Layout Automation – LCC Fusion Podcast – Fusion Hardware Architecture Overview – LCC Fusion Podcast – Cards & Node Basics
Servo motors on a model railroad layout provide controlled, repeatable mechanical movement, enabling realistic animation and precise positioning of layout elements.
In the LCC Fusion Project, servo-driven devices are implemented using the Servo Card, which generates controlled PWM signals in response to LCC events. These events originate from buttons, sensors, logic rules, or automation sequences elsewhere in the system.
Servos define how something moves; logic, signaling, and automation define when and why it moves. The Servo Card executes movement commands only and never encodes behavior.
| Category | Servo Use | Description |
|---|---|---|
| Turnouts | Turnout control | Use servos to control turnouts (switches), enabling smooth and reliable route changes. |
| Signaling | Signal operation | Operate semaphore or mechanically driven signal aspects using servos. |
| Signaling | Level crossing gates | Open and close crossing gates in coordination with train movement. |
| Operations | Coupler operation | Automate coupling and uncoupling of rolling stock. |
| Operations | Transfer tables | Move transfer tables to align tracks in engine or service facilities. |
| Operations | Turntables | Rotate turntables for directing locomotives. |
| Operations | Cargo and crane operations | Drive cranes, loaders, or hoists for industrial scenes. |
| Structures | Drawbridge movement | Raise and lower drawbridges or lift bridges. |
| Structures | Engine house doors | Open and close engine house or workshop doors. |
| Structures | Station platform doors | Simulate platform doors synchronized with train arrivals. |
| Scenery | Animated scenery elements | Animate windmills, water wheels, cable cars, or similar features. |
| Scenery | Pop-up scenery | Trigger pop-up figures, animals, or scenic elements. |
| Scenery | Variable terrain | Adjust terrain elements such as mine elevators or water levels. |
| Scenery | Scenic effects | Create dynamic scenic motion effects. |
| Scenery | Diorama movements | Add motion to diorama scenes for enhanced realism. |
| Vehicles | Moving vehicles | Control steering or motion of road vehicles. |
| Facilities | Load/unload mechanisms | Automate loading and unloading of cargo. |
| Facilities | Track cleaning | Operate track-cleaning mechanisms. |
| Information | Station announcement boards | Animate mechanical or visual announcement boards. |
| Infrastructure | Rotating antennas or dishes | Rotate radar dishes or antennas for industrial or military scenes. |
Servo planning begins when you decide what elements of the layout should move and why. Each servo-controlled device should exist for a clear operational or scenic purpose, such as controlling turnouts, operating signals, animating scenery, or enabling interactive features.
Planning involves determining: - Which layout elements require precise or repeatable motion - Whether movement is operator-driven, automated, or both - How many servos are needed and how they are grouped per card - Physical placement of servos relative to the mechanisms they drive
The table below lists common planning use cases that drive the need for this card. Each entry represents a reason to introduce this capability into a layout design.