Christopher Mitchell’s Class 800 Simulator Turns Prototype Progress Into an Integration Test

Christopher Mitchell’s three-year Class 800 simulator project reached a revealing stage in July, despite several components remaining unfinished. The horizon hackaday listing points readers toward a progress report that is less about completion than integration.

Mitchell’s July 26 update covers a headlight panel, metal dashboard sections, and several Automated Warning System instruments. Each subsystem works differently, yet all must communicate with two train simulation platforms through one physical cab.

That requirement creates the real conflict. A replica can look authentic while behaving like a generic controller. Alternatively, it can function precisely while remaining a fragile collection of prototypes.

Mitchell is trying to preserve both physical fidelity and dependable operation. His newest work shows why that goal becomes harder as a project moves from separate devices into one interconnected machine.

July’s Update Connects Three Unfinished Systems

The important change is that Mitchell is now testing interactions between components, materials, and simulator software.

According to his July progress roundup, Mitchell began this physical simulator more than three years ago. It models the driving cab used across Britain’s Class 80x passenger-train family.

That family includes the Class 800, 801, 802, 805, and 810. Mitchell has obtained some real railway components while fabricating replicas when suitable parts were unavailable.

His previous articles usually documented one completed component or construction stage. The latest report instead collects work completed between January and July 2026 across three active areas.

The first area is the headlight control panel. On an actual Class 800, this panel includes a six-position selector, a hazard-light button, and status LEDs.

Those LEDs form a diagram of the train’s front. Their illuminated colors indicate the selected combination of headlights and tail lights.

Mitchell created a custom printed circuit board containing white and red surface-mount LEDs. The board also serves as a daughterboard for one of his CAN bus transceivers.

A daughterboard is a smaller circuit board that expands another board’s inputs, outputs, or supporting functions. Here, it connects the lighting display, selector, and hazard button.

The design required two circuit-board iterations. Mitchell also tested three red and three white LED options to find visually comparable brightness levels.

He commissioned frosted white diffusers to spread the light. These pieces connect in a thin, branching structure positioned above the board’s individual LEDs.

The selector presented a different problem. Mitchell knew its manufacturer and part number, but obtaining a new example required buying multiple costly units.

He instead combined parts acquired through several online purchases. The result is a six-position switch that he believes matches the prototype’s behavior.

Mitchell tested the completed assembly with Train Simulator Classic and Train Sim World. That exposed an important software limitation rather than a hardware defect.

Train Sim World does not expose every dashboard indicator’s current output state to external hardware. The simulator can accept an input without returning enough information to reproduce its visual response.

That distinction matters. A controller sends commands, while a replica cab must also display the simulated train’s changing state.

The second area concerns the dashboard’s structural panels. Mitchell had previously moved from cardboard to hardboard, a dense fiber panel suited to inexpensive fabrication.

Hardboard allowed fast iteration and proved that five dashboard modules could form the intended layout. It was less suitable as a permanent material.

The panels flexed, appeared less realistic, and remained vulnerable around joints and component openings. Mitchell therefore began replacing them with laser-cut, powder-coated steel.

He first tested this approach with panels for the Train Protection and Warning System and Driver’s Reminder Appliance. Both systems have dedicated controls in British driving cabs.

With assistance from prototyper Tim Keller, Mitchell laser-engraved and painted those steel panels. The process produced durable labels and a finish closer to the original equipment.

That result encouraged him to order metal versions of the remaining panels. He received them in late March and transferred buttons and switches from the earlier prototypes.

The parts fit, and the steel flexed less than hardboard. However, the increased weight placed more stress on the hardboard and medium-density fiberboard supports beneath them.

Mitchell now expects to replace those supports with plywood. The apparently straightforward material upgrade has therefore created another structural task.

Labeling also became harder. White acrylic paint could be removed cleanly from the earlier semi-gloss test surfaces, but it seeped into matte powder coating.

The completed metal panels cannot simply repeat the proven labeling method. Mitchell must modify the process without discarding parts already manufactured.

The third area revisits the Automated Warning System, or AWS. It alerts British train drivers after cautionary signals and significant speed restrictions.

Its familiar “sunflower” indicator alternates between black and yellow patterns. The yellow state reminds a driver that the previous AWS event required acknowledgment.

Mitchell already connected a full-size mechanical sunflower to his simulator. Newer work examines three smaller modules that also contain authentic warning horns and clear bells.

Together, these three workstreams define the July update. They are unfinished, but each has advanced far enough to expose the next integration constraint.

Why Physical Fidelity Keeps Creating Engineering Work

Every authentic detail adds another electrical, mechanical, or software contract that the complete simulator must satisfy.

A commercial desktop controller can map levers and buttons to standardized commands. It generally does not need to reproduce a specific cab’s dimensions, lamps, warnings, or material finishes.

Mitchell’s project sets a stricter target. His controls should occupy the expected positions, feel appropriate, and reflect conditions inside the simulated train.

That target transforms small details into engineering dependencies. A six-position headlight switch is not merely a rotary input with six readable values.

Its electrical behavior must suit the interface board. Its shaft, detents, dimensions, and panel position must also correspond with the original control.

The LED diagram introduces a second path. The simulator should report which lights are active, then the hardware must convert that state into suitable outputs.

Train Simulator Classic and Train Sim World do not expose identical interfaces. Hardware that behaves correctly with one title can therefore lose feedback when used with the other.

The headlight test illustrates this mismatch. Train Sim World can receive control input, but Mitchell reports that it does not expose every required indicator state.

Software support becomes the limiting component even when the physical panel works. That is a recurring issue for specialized simulation hardware.

A generic USB device can emulate keys or joystick axes with relatively little game-specific knowledge. A bidirectional cab needs access to internal variables representing lamps, gauges, and safety systems.

Each simulated locomotive can also implement those variables differently. A stable physical instrument may require separate mappings for different software vehicles.

Mitchell addresses the hardware side with a CAN bus. A Controller Area Network lets multiple electronic modules exchange messages over a shared pair of wires.

The approach originated in vehicles, where many controllers must communicate reliably without separate wiring between every possible pair. It is well suited to a modular simulator.

Mitchell’s earlier dashboard prototype connected most instruments and controls through his CAN transceivers. Specialized daughterboards adapted devices with unusual electrical requirements.

That architecture reduces the need for one central board containing every connector. New controls can join the common network while retaining circuitry designed for their particular signals.

However, modularity does not erase variation. It relocates variation into interface boards, firmware, connectors, and message definitions.

The AWS work demonstrates that point. Mitchell’s original transceiver board used field-effect transistors, or FETs, for low-side switching.

Low-side switching connects a device’s return path to ground. High-side switching controls the supply voltage delivered to the device.

The smaller AWS module uses common-cathode wiring and needs high-side switching. Mitchell’s existing outputs were designed for the opposite arrangement.

The unit’s horn and bell worked during testing, but they could not be driven through the original circuit without an electrical redesign. He revised the I/O daughterboard accordingly.

Four of its five FET outputs can now be configured for high-side or low-side operation. That modification expands the board beyond its original assumptions.

The change also shows the value of testing real parts early. A data sheet or continuity check might describe terminal behavior, but integration reveals system-level consequences.

Physical fidelity creates similar pressure in the dashboard structure. Steel offers the stiffness, weight, and appearance missing from hardboard.

Yet steel also transfers more load into its backing structure. The material improvement therefore weakens another part of the assembly unless that support changes too.

The matte finish provides a better visual match, but its surface retains paint differently. A cosmetic choice becomes a manufacturing constraint.

This chain of consequences distinguishes a replica from a themed control desk. The design cannot optimize electronics, structure, appearance, and software independently.

Each improvement changes the surrounding system. Progress depends on discovering those changes before the design becomes too expensive or difficult to revise.

The Real Opponent Is Integration, Not Another Controller

Mitchell’s project is competing against the complexity created by its own standard of authenticity.

It would be easy to frame this build against RailDriver or newer desktop train controllers. That comparison would miss the project’s purpose.

Commercial controllers prioritize broad usefulness, compact dimensions, and repeatable production. They must serve several trains or simulation titles without duplicating one cab exactly.

Mitchell’s simulator prioritizes the Class 80x experience. It surrounds the user with five dashboard sections arranged around a dedicated support surface.

His custom simulator table uses plywood cut into two joined sections. Clamps attach it to an existing desk, while adjustable legs support its outer edge.

This solution responds to a practical constraint. Mitchell is building the cab in an apartment, where the structure must be stable during use and removable afterward.

The table also contains openings for instruments extending below angled panels. Its shape follows the footprint created by the five dashboard modules.

Those physical relationships matter because the project is no longer a group of independent desk accessories. A change in one panel can affect supports, wiring, sightlines, and storage.

The July metal-panel update makes that dependency visible. Buttons transferred successfully, yet the heavier panels now require stronger backing.

Replacing the support material can affect mounting holes and cable routing. It can also alter how the five modules meet at their edges.

This is the project’s central reversal. More finished-looking components do not automatically make the simulator closer to completion.

A polished metal panel can reveal inadequate support. A working warning instrument can expose incompatible switching. A functional selector can expose missing software telemetry.

The better each individual component becomes, the more precisely the rest of the system must respond. Integration difficulty rises alongside component fidelity.

This does not mean the architecture is failing. The CAN network and daughterboard strategy give Mitchell a way to contain many differences.

The revised I/O board is a good example. Supporting both switching arrangements turns one unexpected railway instrument into a reusable capability.

Future devices with similar wiring can use that option without another core-board redesign. A local obstacle becomes an architectural improvement.

The same iterative logic shaped the dashboard. Cardboard established dimensions, hardboard enabled functional trials, and steel tests long-term construction.

Discarding those early stages would misunderstand their role. Each version answered different questions at an appropriate commitment level.

The cardboard panels asked whether the layout was plausible. Hardboard asked whether instruments could be mounted, connected, and operated together.

Steel asks whether the design can become durable and visually convincing. It also reveals which earlier supports were only adequate for prototypes.

This progression resembles hardware product development more than ordinary controller customization. The builder is validating geometry, electronics, firmware, software compatibility, and manufacturing methods.

The difference is scale and intent. Mitchell is producing one evolving cab, not preparing a standardized device for a production line.

That freedom enables unusual choices, including the use of real railway equipment. It also removes the simplifications that make mass-market controllers manageable.

A manufacturer can select one switch based on availability and electrical compatibility. Mitchell may reject it because the detents, shape, or placement differ from the Class 800 part.

He can reconstruct the correct behavior from several components. That choice preserves fidelity but adds sourcing and assembly risks.

The resulting simulator is not a direct substitute for a compact controller. It is an experiment in how much of a specific machine can enter a home environment.

That distinction also explains the attention from broader technology outlets. A recent project profile emphasized the contrast between Mitchell’s tactile cab and screen-heavy simulation setups.

The spectacle attracts interest, but the integration method is more instructive. It shows how prototypes become systems through repeated encounters with mismatched assumptions.

What the July Roundup Still Cannot Prove

The cab looks increasingly complete, but several unresolved interfaces still prevent a final judgment about reliability and fidelity.

The first uncertainty comes from software telemetry. Mitchell reports that Train Sim World does not expose every dashboard output needed by the headlight panel.

This limitation can leave a physical indicator disconnected from the simulated train’s actual state. The user might move a control without receiving corresponding visual feedback.

Input-only operation remains useful, but it breaks the illusion of one coherent cab. The hardware and virtual vehicle can drift apart.

The software developer might expose additional variables later. Mitchell might also find a train-specific integration route or derive state from another available signal.

None of those outcomes is confirmed in the July report. The limitation should therefore be treated as open, not solved.

The second uncertainty concerns long-term mechanical stability. Steel panels reduce flex, but their greater weight has already challenged the existing supports.

Plywood backing appears to be the next response. The completed assembly still needs repeated use before its durability can be assessed.

That test matters because simulator controls experience concentrated loads. Levers, guarded switches, and frequent button presses transfer force into their panels and mounting structure.

A cab that remains stable during a short demonstration might loosen after months of operation. Mitchell has not claimed that the final structure is complete.

The third uncertainty involves the panel-labeling process. The TPWS and Driver’s Reminder Appliance tests succeeded on particular powder-coated finishes.

The matte coating used elsewhere absorbed white acrylic paint. Repeating the earlier engraving and painting method produced unsatisfactory results.

Mitchell hopes to preserve the fabricated panels while changing the finishing process. The report does not identify a validated replacement technique.

Possible approaches would introduce their own compromises. Surface printing, filled engraving, transfers, or separate label plates can differ in texture and durability.

The article should not assume which method he will choose. His stated next step is further fabrication testing.

The AWS redesign presents another open loop. Mitchell validated the module’s horn and bell, then designed a configurable daughterboard for the required switching method.

At publication, the revised circuit boards had not yet arrived. Their electrical behavior inside the full CAN system therefore remained unverified.

The new design must safely drive the instrument while preserving the board’s other output functions. It must also fit within the project’s existing wiring and firmware.

Mitchell’s original AWS instrument used a roughly five-inch-square mechanical unit with a three-inch depth. Two coils changed its visual state.

That earlier device provided an imposing mechanical action. The smaller alternatives integrate authentic sounds and offer dimensions closer to newer equipment.

Choosing between them creates a genuine tradeoff. The larger mechanism offers a pronounced physical effect, while the smaller modules may match the intended dashboard more closely.

Mitchell says he is seriously considering an LED sunflower. That would sacrifice the mechanical movement he values while improving prototype fidelity.

Noise also matters in an apartment. A real warning horn designed for a driving cab can be excessive in a residential room.

Authenticity is not a single variable here. Visual match, sound, mechanical behavior, size, safety, and domestic usability can point toward different components.

The July progress report succeeds because it does not hide these conflicts. It presents unfinished work and records why apparently minor tasks remain unresolved.

However, readers should distinguish transparent iteration from proven completion. The report documents credible engineering progress, not a finished simulator specification.

The same caution applies to media descriptions calling the build exceptionally elaborate. Such judgments describe its visible ambition, not measured reliability or compatibility.

No independent endurance test has been published. There is also no standardized comparison covering input latency, software support, or behavior across multiple Class 80x models.

Those omissions do not reduce the project’s value. They define what remains unknown and prevent a hobby build from being evaluated like a commercial product.

What to Watch After the Horizon Hackaday Roundup

The next meaningful milestones are software feedback, validated power switching, and a durable final dashboard structure.

The first signal is a successful bidirectional headlight demonstration. The selector should change the simulated train, while the physical LED diagram should mirror its resulting state.

Train Simulator Classic appears to provide a workable path for further testing. Train Sim World remains the more revealing compatibility test.

If Mitchell retrieves complete indicator states from Train Sim World, the cab’s cross-platform case becomes stronger. If not, the project will need title-specific compromises.

That outcome will also clarify a broader problem for specialist peripherals. Standard input support is not enough when external hardware needs live access to instrument states.

The second signal is the arrival and validation of the revised I/O daughterboard. Its configurable FET channels should operate the smaller AWS module’s sounds correctly.

A successful test would confirm that Mitchell’s modular electronics can absorb incompatible railway wiring without replacing the main CAN transceiver.

It would also support other instruments needing high-side control. That makes the test more consequential than one working horn or bell.

Failure would not end the project, but it would expose another boundary. The system might need separate driver boards, protection components, or revised power distribution.

The third signal is a repeatable process for finishing and supporting all steel panels. That includes labels that remain clean on matte powder coating.

It also requires plywood or another support material capable of carrying the added weight. The full cab must remain aligned while controls are operated.

Success would move the dashboard from prototype validation toward a durable assembly. It would also allow later work to focus on displays, remaining controls, and software.

A continuing cycle of panel rework would weaken the idea that fabrication is nearing completion. It would show that material and finishing choices still require foundational decisions.

These signals should arrive through detailed component posts, which Mitchell says he plans to publish as each area reaches completion. His project archive already records the progression from individual instruments to a five-panel cab.

For builders, that archive offers more value than a single dramatic reveal. It preserves failed assumptions, material transitions, and interface changes that finished photographs usually conceal.

People managing other long-running technical projects can apply the same lesson. Progress notes become more useful when they connect decisions, evidence, failures, and pending tests.

A searchable engineering knowledge base can help preserve those relationships across circuit revisions, fabrication files, and test results. The principle matters whether one person or a team owns the work.

The horizon hackaday phrase may bring searchers to this update, but the collector label is not the story. Mitchell’s integration process is.

His Class 800 simulator now faces the stage where every polished component must survive contact with the complete system. That is harder than building another isolated control.

Watch the next demonstrations for closed feedback loops, not just convincing surfaces. Do the lamps follow the software, do the warning modules switch safely, and do the panels remain stable?

Those results will show whether this apartment-built cab has crossed from an impressive collection of replicas into one dependable simulator. Follow the next component tests, then judge the project by how consistently its physical and virtual states agree.