Thanks, I appreciate it! It's a really fun project to work on, and I continue to enjoy that it's making me both flex a few skills I haven't used lately and learn a bunch of new ones, like smaller-pitch hand soldering, more precise 3D printing, crimping, CNC machining, etc.

I'm long overdue for another update; in the last month I spent a lot of time working on extracting measurements of the Class 800 cab/dashboard, then worked with Geekboy1011 to laser-cut prototype pieces and discuss whether I should stick with trying to precisely replicate the Class 800, or aim for something more modular/apartment-friendly/modest to start.

More on that soon, but in the meantime, here's a stream I streamed last night in Train Simulator Classic with the current iteration of my setup:

*bump* I have another update as I try to reach the present, this one from February 2024: Driver's Reminder Appliance (DRA). In this post, I describe the DRA I added to my setup, which given the groundwork I have already laid with my CAN bus controller, most challenged me by requiring me to find a relatively obscure push-pull button that matches prototypical train equipment. As always, I have summarized the blog post here, but I encourage you to read the original blog post (as usual, it has a video!).

Driver's Reminder Appliance (DRA)
I’m replicating the controls present in UK train such as the Class 80x high-speed train, and one of the important controls to include is the Driver’s Reminder Appliance (DRA). The DRA helps the driver avoid passing a signal at danger (that is, a red aspect), and like so many safety innovations, was introduced as a result of deadly accidents. When a driver passes a caution (yellow) signal that indicates the next signal might be a red, but then stops at a station, it’s easy to forget about that yellow signal, even if the AWS sunflower is showing its yellow vanes.

The DRA reminds the driver that they are at a red signal or that they passed a restricting/caution signal by providing both a visual reminder and preventing the train from taking power. Before leaving a cab, or after entering a cab, stopping at a red signal, or stopping after passing a caution signal, the driver pushes the DRA push-pull button, which illuminates in red. As long as the button is depressed, the train will not take power: the driver must wait until they have authority to start the train, a signal ahead has cleared to a non-stop indication, or the signaller (dispatcher) has given them permission to pass a stop signal to pull the DRA button. When pulled, the light extinguishes, and the train can take power.

Thanks to creating my flexible CAN controller, adding a DRA button to my Train Simulator controller was easy. The CAN bus controller provides a set of low-current GPIO pins (in this case, used to check if the button is depressed or extended), and up to three higher-current FETs for powering hardware (in this case, the 12V red LED bulb in the DRA button). The hardest part of this project was actually finding the correct button used in UK trains to make my setup as prototype-accurate as possible. For my first version, I used a chunky red Allen Bradley push-pull mushroom button into which I had embedded a red LED, as the as-delivered button had a 110V bulb. I spent nontrivial time staring at Google Image Search results for “clear mushroom button” and similar phrase until I finally identified a button that is definitely used on at least some UK trains, then purchased the various components necessary to complete it (the actuator, the LED bulb, and the contact unit).


The prototype (left, heavily edited from a larger image to try to see the details) and the correct version I have in my simulator (right).

I wrote a simple addition to the CAN bus controller firmware similar to the AWS firmware module that sends a message indicating the status of the DRA button every 200ms, and also sends an asychronous message every time the button changes state. It also accepts a message from the host with the new state of the LED: this ensures that the LED is not automatically illuminated by pushing or pulling the button, but reflects what the host knows about the button (and allows proper self-testing by pushing and pulling, and ensuring that the LED changes state to match). Video in the blog post: https://z80.me/blog/tsc-dra-1/img/dra_action.mp4

Finally, as of February 2024, the full setup with DRA button, speedometer, air gauge, AWS sunflower, and AWS acknowledgement button.

Sadly, I missed posting an update last month, as I continue to try to catch up to the present. Today's update is from March 2024: Real ATP-Enabled Speedometer. This blog post shares what is almost a complete project itself: determining how ATP-enabled speedometers from UK trains I purchased work through careful detective work, then designing and building a controller PCB I can use with my CAN bus controller and interface to Train Simulator. As always, I have summarized the blog post here, but I encourage you to read the original blog post (and as usual, it has videos!).

Real ATP-Enabled Speedometer for Train Simulator
I started this project by trying to build my own speedometer, experimenting with a stepper motor used for automotive instruments that I later integrated into a CAN-controlled air gauge. Thanks to UK eBay, I eventually got my hands not only real UK train speedometers, but a couple of speedometers that are fitted with the LEDs and alphanumeric display necessary for Automatic Train Protection (ATP). This system uses green and amber LEDs to indicate speed limits: solid green LEDs at the appropriate speed on the dial for the current Maximum Authorized Speed (MAS), flashing green for an upcoming change in the speed limit, and flashing amber for the “release speed” under which the system will no longer make a brake application. Like ACSES, it automatically applies the brakes if it judges the driver (engineer for us US folks) is not slowing sufficiently for an upcoming speed limit. The 3-character alphanumeric display is used in the prototype to display status messages, including about why the brakes were applied, but I wanted to use it to display the current speed and the speed trend (accelerating or decelerating), like the digital speedometer in the Class 395.


One of these ATP-enabled speedometers with other instruments, before I worked out how to control it

Getting these real speedometers working with Train Simulator was a particularly fun proposition, because no documentation existed about how they are controlled that I could find on the public internet. Two terminals provide an obvious analog current-controlled input for the needle, but an opaque 35-pin DIN socket (a wider sibling of the now-thoroughly retired 25-pin PC parallel port) provides an interface to the LEDs around the face and to the three alphanumeric digits in the center. I didn’t want to send random voltages through what could be a sensitive driver circuit, so the clear next step was disassembly. I thoroughly documented the disassembly process to make sure I would be able to put it back together again, and when I got to the PCB, I took enough photos that I hoped I could follow traces from the 35-pin DIN socket to the ICs or LEDs they control.



I discovered that the LEDs around the perimeter to indicate speed limits are arranged into a conceptual LED matrix of rows and columns (more detail in the blog post), with the alphanumeric displays being relatively smart units with internal character ROM and the ability to retain the latest character displayed.

I wanted to control both the speed LEDs and the alphanumeric display, and like all my other instruments, I wanted my CAN controller to be the brains behind the unit. I therefore resolved to design a new PCB I could “backpack” on my CAN controller, that would plug neatly into the DIN socket. To avoid wasted time, money, and parts, I started by sketching a design with four shift registers and all of the necessary support components that I laid out on a breadboard. The first image shows the beginning of assembly, the second image the completed prototype:



Planning and testing on a breadboard was a good choice: as I debugged the hardware and wrote the relevant firmware module for the CAN controller, I encountered a few bumps (this was supposed to say “Hel”, as in “Hello, World!”):



Finally, I got the hardware and software working, and was ready to turn the design into a PCB (videos in the blog post). I designed and asssembled the PCB with generally smaller components that I have hand-soldered before, a necessity to fit the four shift registers, 12 LED-driving transistors with associated resistors, plus a trimmer for fine calibration of the analog speedometer needle. I also left holes for future screws to permanently secure this to the speedometer, and it stacks neatly with my CAN bus controller, connected via the 11-pin GPIO header on the controller. For future configurability and compatibility, it includes three 2-pin jumpers to set the type of speedometer to which the speedometer controller is connected. The completed PCB, then installed on the speedometer:



Finally, I could connect the speedometer to my setup (using the 120mph version), drive Class 80x trains around the UK railway network, and get digital and analog speed indications plus useful speed limit information!

*bump* Not a full update, but in the interest of posting in this topic more frequently, I spent an hour yesterday doing some tracing on a power/brake controller I acquired a few months ago. As you know if you've been following along with this thread, one of my biggest obstacles was building the combined power/brake controller you use to make many modern passenger MU trains go and stop. I wanted to build a realistic UK version, and it was turning out to be a time-consuming task. To my pleasant surprise, I was able to buy a real UK Networker power/brake controller from eBay UK, and thanks to my fiancée's endless patience and support, ship it to her, partially disassemble it, and bring it home. It weighs about 60 pounds, so it's no slouch, and I have quite the task cut out for me cleaning and lubricating it, making a housing for it, and interfacing it.

Here's the power/brake controller pre-shipping:


And yesterday, I sat down with a continuity tester, a flashlight, and my notebook, and started tracing out the connections between the roller switches inside the PBC and the massive milspec 48-position 36-10 connector the PBC uses:

At this point I assume it's only a matter of time until we see CPRR2 on the tracks at the Shore Line Trolley Museum, because that looks like a ridiculous pile of bits to integrate into a mere sim rig.

You're not wrong that I have aspirations of building my own (small) locomotive at the Shore Line Trolley Museum, aspirations that are the reason behind why, for example, I decided to design my sim rig around a CAN bus rather than something simpler. But in the meantime, I aim to have one of the best and realistic home train simulators around.

*bump*

Today, an update from late April to early May 2024: Laser-Cutting a Door Control Panel. With the electronics of new instruments and controls getting easier and easier, thanks to my flexible CAN bus controller, I turned my focus to prototyping door control panels for my Train Simulator rig. With help from geekboy1011, we took cardboard prototypes loaded with the actual buttons used in Class 80x trains (and other UK trains) to laser-cut wood prototypes, and I further developed the computer software to interface with the buttons. As always, I have summarized the blog post here, but I encourage you to read the original blog post.

Laser-Cutting a Door Control Panel for Train Simulator
As previous posts have mentioned, I had intended to make as nearly perfect a replica of a Class 80x dashboard as I could, shaped, scaled, and laid out exactly like the prototype. I have the right buttons, many of the right types of instruments (if not the exact types used in the Class 80x), and I of course have the correct train in Train Simulator. However, when I sat down with geekboy1011 to discuss the logistics of building the physical modules into which the controls will be placed, he suggested starting smaller. Before (or instead of) building those Class 80x-esque panels from laser-cut metal, he advocated a version 1 (a) built of wood and (b) laid out to be modular, easily disassembled, stowable, and movable. With that in mind, I picked a simple unit of the dashboard, one of the two door control panels present on every Class 80x dash, and began prototyping.

I had already (finally) determined what real buttons were used on the panel and sourced quite a few of them, in part by purchasing the buttons, their components, and the switch elements that attach to the back of the buttons, in part by purchasing two real Class 313 dashboards and partially disassembling them. Don’t worry: I’ve saved the metal dashboards and the gauges, and thoroughly photographed them should there ever be interest in rebuilding these scrap-salvaged dashboards.



With the real buttons in hand, I measured the distances between the door control buttons in photographs of Class 80x dashboards, using the buttons themselves for scale. These five buttons are a green Signal button that signals the guard ("conductor", for us US folks) via buzzer, two red Door Open buttons that must be depressed simultaneously and illuminate when the doors on that side are open, a blue Door Close/Interlock illuminated button that also shows when the train’s doors are interlocked (that is, all doors are provably closed and power can be applied), and a yellow Train Door Control button that switches door control modes. The real train, and my cardboard prototype:



As with all of my instruments and controls, one of my CAN bus controllers links the buttons and LEDs in the door controls to the PC running Train Simulator via a single CAN bus adapter. I used this for a while in my Train Simulator setup, to see how it worked and to fine-tune the PC software and the firmware. To my chagrin, Train Simulator doesn’t really support door controls properly: in the game, you usually press T to open the doors, and they automatically close (in fact, in most trains they cannot be manually closed). Different trains support different subsets of controls, and very few support separate left and right controls, let alone actually opening train doors via with the RailDriver interface instead of with the keyboard. My experiments with Armstrong Powerhouse’s Class 80x were more successful than with any of Dovetail’s trains, but still did not allow full door control. I was quite surprised to discover how different the RailDriver interfaces presented by different trains are, and this will surely be the subject of both a future blog post and significant PC-side software development.

Over two days with geekboy1011, we prototyped and refined thin laser-cut plywood versions of this door control panel, in both left-side and right-side versions, complete with the accurate text and icons from the real Class 80x. A few days later, I dove back into my pile of buttons, crimp lugs, and wire, and wired these door controls up.



And finally, I connected these up to my full setup, and continued testing and developing the software.

I was able to finish reassembly the power/brake controller. First, I had to take the first piece I brought over apart more, to get to where the throttle/brake and direction arms are installed.



Then, I reinstalled the arms, checked the alignment, and attached the top protective face. I was pleasantly surprised to find that the arms move more freely and bind less than they did before I took everything apart, although I find that with casual experimentation I tend to double-notch the controller, especially in power notches. I need to find some UK train drivers who have operated the Class 365 that might have advice.



Finally, entirely back together!

I will of course go back and write up my process thus far of prototyping the interface between the Class 365 power/brake controller above, my CAN bus controller, and Train Simulator, but I've succeeded in making Train Simulator (in this case, a Class 80x UK passenger train) be controlled by the reverser (power and direction) and combined throttle/brake in my PBC:

As promised, the Part 1 prelude that eventually led to the above video: Power-Brake Controller, Part 1. The core of a train simulator setup could be considered its throttle and brake, the control or controls that make a train go and stop. In previous blog posts, I detailed my exploration of building my own controller from scratch, but a fortuitous eBay listing provided me a real Power/Brake Controller (PBC) from a UK Class 365 train. Here's how I got it home and reassembled. As always, I have summarized the blog post here, but I encourage you to read the original blog post.

Power/Brake Controller for Train Simulator, Part 1
Among my very first steps in building a train simulator rig was exploring building my own throttle from scratch. I eventually built a full-scale prototype of a combined throttle/brake, but it was clear I would need to do significant engineering and machining before it was ready for prime-time. I was thrilled to therefore discover a real power/brake controller from a UK Class 365 train on eBay in May 2024. I of course jumped at it immediately, and didn’t have too much competition to buy this hefty, 70lb (32kg) chunk of metal, wires, and switches.


eBay seller's photo of Class 365 Power/Brake Controller

This Power/Brake Controller (PBC) lets you control the direction of the train via a control called the reverser, and the speed of the train with a combined power/brake handle. The available power/brake handle notches are:

• Emergency Brake
  
• Brake 3 - Brake 1
  
• Off
  
• Power 1 - Power 4

This is enough for most of the EMU passenger trains that I want to simulate in Train Simulator, although it will fall short for trains with separate power and brake handles, trains with brake handles that can be arbitrarily set to any position, and trains with more than 3 brake notches or more than 4 power notches. This should work fairly well for the Class 80x trains (Class 800, Class 801, Class 802, etc.) that I particularly want to simulate, which have 4 power notches, 3 brake notches, and an emergency setting. This Class 365 controller also has a neat feature that I haven’t seen in a lot of passenger trains: a red “brake holdover” button sticking out of the power handle, which when depressed will keep one notch of brake engaged even when off or in a power notch. This serves two purposes in the real trains: allowing hill starts without rolling back, and controlling wheel slip while accelerating on slippery rails. It remains to be seen if I will be able to convince Train Simulator to understand power and brake applied simultaneously on any of the relevant passenger trains.

In order to ship it from the United Kingdom to the United States, I needed to disassemble this unwieldy component into lighter and smaller pieces. Thus began a carefully photographed and documented disassembly process: I removed two long arms, one for the reverser handle and one for the power/brake handle, each of which has a large metal plate with patterns to actuate roller lever switches. Four banks of these roller lever switches were wired together into a substantial cable bundle leading to a circular 48-pin, environment-sealed milspec conector. Switches for the emergency brake and brake holdover switch are also inside. Heavy metal covers wrap the whole PBC unit, fastened with a variety of metric hardware. As I incrementally disassembled the PBC, here are some of the photos I captured:



Here’s how it works: as you move the two handles backwards and forwards, the projections and grooves on the metal plates either depress or release the rollers on the roller lever switches. There’s a power switch that when in the “off” position physically prevents the reverser handle from moving out of the “Off” position to the “Forward”, “Neutral”, or “Reverse” positions. And when the reverser handle is in the “Off” or “Neutral” position, it in turn prevents the power handle from going into any of the 4 power notches.

After this disassembly and careful padding and packing, the bits of the PBC were ready to travel from the UK to America. And once they arrived, I repeated the process in reverse, following my photos and notes to reassemble the PBC. Shortly thereafter, I prototyped a circuit to connect it into my Train Simulator setup and successfully tested this, coming soon in the next blog post!

And now, Power-Brake Controller, Part 2. The core of a train simulator setup could be considered its throttle and brake. Having lugged a combined throttle/brake from a real UK Class 365 passenger train home, I reverse-engineered how it worked, then figured out how to interface it with Train Simulator. As always, I have summarized the blog post here, but I encourage you to read the original blog post (and you can find Part 1 here).

Power/Brake Controller for Train Simulator, Part 2
In my last blog post, I showed the Class 365 power/brake controller that I acquired from the UK, inside and out. I got it to control trains in Train Simulator, but all I had was the hardware itself, with no documentation, and no hardware to interface with it. I needed to first reverse-engineer the schematic and sequence diagram for the power/brake controller (PBC), then design and test how I would interface the PBC to Train Simulator.

My process started with reverse-engineering the schematic for the PBC, including figuring out all the wires connected to its huge circular connector. Of the 48 possible pin positions in this milspec connector, 36 are populated, connected to 36 wires that lead to various of the 27 switches in the PBC. There's also one wire that is only internally connected. I recorded the wire numbers for every switch, some of which are wired normally closed (NC), others normally open (NO), a task made much easier by Westinghouse labeling every wire internally. I then used a multimeter to buzz out all of the wires to the circular connector.

I wanted to interface it cleanly, using it as unmodified as possible. Therefore, my next step was to get or make a female connector to mate with the PBC's male connector. I didn't want to pay hundreds of dollars for a new female connector and pins, but eBay yielded a compatible (unpopulated) mating housing and the female pins I needed to populate it. And on a productive Saturday in August, I sat with the female pins, crimpers, spools of wire, and heat shrink tubing, and prepared and inserted all 36 female pins needed into the housing.



Of course, this huge connector needed to be interfaced with my CAN bus to which all of my instruments and controls are connected. I used the standard CAN bus transceiver that I built for every component of the simulation rig, and as with the speedometer, I developed a daughterboard to connect the PBC to the CAN bus transceiver. I initially anticipated that I would need to include a demultiplexer to interface the 36 wires connected to the 27 switches in the PBC, as the CAN bus transceiver has only 17 GPIO pins exposed. To determine if that was the case, I reverse-engineered a sequence diagram of how the 27 switches in the PBC open and close as the reverser and power/brake handles travel. I began this reverse-engineering simply from studying the actuator plates shown in the preceding blog post, then verified my results by hooking my multimeter up to each switch and running the handles through each position.


Sequence diagrams for power/brake handle (left) and reverse (right)

After studying these sequence diagrams, I determined that I could detect all four different reverser positions, all 9 power/brake positions including emergency braking, and the holdover feature with only 15 GPIO pins. This simplified what interface hardware would be necessary, but with potentially noisy switches and long wires, I still wanted to make the daughterboard apply hardware debouncing to each switch. I also wanted to isolate the switches from the Raspberry Pi Pico on the CAN bus transceiver board, so I designed a circuit and printed circuit board with an RC low-pass filter and a simple transistor switch connected to each switch input. First I tested the circuit for a single switch on a breadboard, then built the full circuit for every switch:



This breadboarded circuit allowed me to fully test the interface and verify first that all connections to the PBC in the circuit design were correct, then that the debouncing and noise reduction circuitry was working as designed, and finally that the firmware on the CAN controller correctly interpreted the inputs from the PBC as accurate reverser, power, and brake settings. In fact, the primary bug that required tracing was in the software debouncing acting as a second layer after the hardware debouncing and denoising. This sample output from the debugging process shows the raw outputs from the switches (left column) followed by the interpreted level or value of the power, brake, reverser (direction), emergency brake, and brake holdover. Here is the output with both handles in the OFF positions.



With the interface hardware built, the firmware debugged, and my temporary Python driver that talks to Train Simulator updated, I could finally control a train with a real throttle/brake.

Not a moment too soon, I wanted to share my last blog post on this project of 2024, Train Simulator Controller: Power/Brake Controller, Part 3, wherein I have built a proper circuit board to interface with my real train throttle from the previous post. In brief, I turned my breadboarded design tested in the previous post into a KiCAD design, fabricated it with JLCPBC and my own soldering iron, and voila, it worked!



I end the blog post with a photograph of my full setup as of September 2024. Unfortunately, since then personal and professional commitments have prevented me from making much further progress, although I have been finally playing Train Simulator again (albeit without my physical controls) with a new and very large monitor. In 2025 I plan to finish this first version of my simulator setup, and hopefully enjoy it for a while before feeling the need to tear it apart or upgrade it to version 2.

I have been writing for two years about the instruments, controls, and gauges in my physical Train Simulator controller, but one topic has received little attention: the dashboard into which I'll install all these components. In my latest blog post, summarized here, I discuss nine (sporadic) months of work to try to measure a real Class 800 UK train's dashboard without actually having access to the train, then beginning to design what my own dashboard might look like.

Train Simulator Controller: Designing a Dashboard

I have written at length about the many electromechanical components of this Train Simulator controller project, but the biggest missing part of the project has been the actual dashboard into which to place all these different controls. As I mentioned in my blog post about my master controller prototype back in May 2023, for most of this project I have dreamed of reconstructing a dashboard resembling that of the UK Class 800, known currently as the LNER Azuma and the GWR Intercity Express Train (IET). It’s far from a small setup, and at various points I’ve considered scaling it back, including at the urging of my friend and colleague Tim “geekboy1011” Keller when we worked on door control modules together. Nevertheless, it’s my eventual objective, and for the moment design is proceeding along those lines.


Mockup of Class 800 cab. Credit to DCA Design.

I don’t have access to a Class 80x cab: I don’t operate UK trains, and even the cab of a Class 800 currently in residence at the National Railway Museum in York, England has its doors blocked off. As I detail in the complete blog post, I was able to deduce a COLLADA 3D model of the locations of buttons on the Class 800's dashboard from an non-encrypted GeoPcDx 3D model, and painstakingly measure the rough 3D position of each of the buttons.


Several LODs of a Class 43 HST power car 3D model, a test for reading non-encrypted GeoPcDx files

I used the positions of each of those buttons to extrapolate the planes in which each of those buttons lies, roughly determining the surfaces of parts of the dashboard. With Python, matplotlib, and numpy, in April 2024 I soon had three of the main planes mapped out: the primary surface in front of the driver, and the two angled side panels on which the left and right door controls are situated. It’s a little hard to visualize, but the red circles of the buttons provide some context.



Life, work, and other parts of this project intervened, but in January 2025, I turned my attention back to this part of the project, and quickly mapped out much more of the dashboard, using a mix of precise measurements from the button positions, educated guesswork from reference items in photographs (e.g., a clipboard), and pure guesswork. In the interest of both space and functionality, I also removed two screens at the left of the driver in the real train that show CCTV footage, as I have no way to be able to see those views without essentially writing my own train simulator software.



And finally, from all of these measurements, I designed papercraft prototypes, starting with a 1:10-scale paper and cardboard model. I diagrammed the components in Inkscape, printed and glued it onto thin cardboard, then folded and glued the pieces into a passable visualization of what I intend to create from wood, paint, and the many components I have collected over the last two years. From here, the design and construction continue!


1:10 scale prototype of modified Class 80x dashboard

Over a year ago, I posted about my CAN-connected air pressure gauge, an important instrument that allows a train operator/driver to know several facts about their air brakes, including how much the brakes are applied, and how much air is available to apply the brakes when needed. My first version of this instrument embedded the CAN controller PCB into the gauge, but it stuck out the side. This turned out to be incompatible with inserting the gauge into a dashboard, so I pulled the PCB out of the instrument, and along the way, had my first experience working with lead-free solder. As always, you can read the full post on my blog, https://z80.me/blog: Train Simulator Controller: CAN-Connected Air Gauge, Part 2

Train Simulator Controller: CAN-Connected Air Gauge, Part 2
My Train Simulator Controller project has moved forward as time has permitted over the last two years, and I have primarily focused on completing a first version of the setup, deferring improvements to a future version 2. However, I find that occasionally a later stage in the project has forced me to rethink an earlier stage, and the air pressure gauge I completed in December 2023 is one such element. As discussed at some length in my very first post about this project, I knew I would need to control stepper motors for various gauges. To solve this, I stuffed a CAN controller and a stepper motor into a two-needle Graham-White air gauge, and successfully used it to operate trains in Train Simulator with my instruments laid out on a desk.

I tried to make the air gauge as self-contained as possible, and when making it compatible with Train Simulator (and my CAN bus) in December 2023, I was pleased to see that the CAN controller board fit neatly into the air gauge housing. Unfortunately, the axes of the X40 biaxial stepper motor are not in the center of the board, and I also needed to access the RJ-45 CAN bus ports, so I had to cut a hole in the side of the housing.



This was predicated on mounting the stepper motor directly on the CAN controller board, as designed, but when fellow Cemetechian and hardware hacker geekboy1011 and I tried laser-cutting some plywood prototype panels into which to mount the components, we discovered that an extra hole had to be cut in the side of the aperture for the gauge to accommodate the circuit board as the gauge was inserted into the panel. Therefore, it became clear as I built paper, then cardboard prototypes of the dashboard increasingly close to 1:1 scale that I would need to reduce the external dimensions of the air gauge back to its original 2" radius. This was further driven home by determining exactly the template I would need to cut out of the dashboard to snugly fit the air gauge, which I did with a hand-drawn template followed by increasingly correct Inkscape drawings:



I therefore followed a straightforward, if delicate, series of steps to move the stepper motor off of the CAN controller:

1. I desoldered the stepper motor from the board, thanks to the excellent Japanese Engineer-brand SS-02 solder sucker that has served me very well over the past few years.
   
2. I soldered wires in place of the now-removed 8 motor leads, using for the first time lead-free solder. This turned out to be the least trivial part of the project: having only used leaded solder in the past, properly using lead-free solder, including correct temperatures, was a learning curve. Thanks to guidance from geekboy1011, I zeroed in on some better practices: as the picture below shows, my earliest joints were overheated and poor, but my later joints improved.
   
   
3. I crimped an 8-position JST-SM female male connector onto these wires, then crimped the matching female connector onto another set of 8 wires that I soldered onto the stepper motor, adding heat shrink tubing for mechanical stability.
   
4. I could now mount the motor directly into the air gauge, on the back of the faceplate. Unfortunately, I didn’t have the long, very-thin-diameter screws I would have needed to use with the stepper’s own tiny mounting holes, so I instead used cyanoacrylate to glue the motor in place. I anticipate correcting this in the future.

The resulting setup provided exactly what I needed: I can tuck the connector to the motor inside the gauge housing to insert it into the dashboard, screw it into place, then extract the connector and connect it to its CAN controller board, mounting the CAN controller board on the back of the dashboard. For a future iteration, I am considering alternatives that would allow the air gauge to be as self-contained as originally designed.



I could then test the result, connecting my CAN to USB serial bridge and writing a quick Python program to repeatedly move the MR and BP needles up and down along their range, graduating the backlight to match. Video demo: https://z80.me/blog/can-air-gauge-2/img/external_controller.mp4

Full blog post here: Train Simulator Controller: CAN-Connected Air Gauge, Part 2

As I build my realistic Train Simulator dashboard and controller, each foundational component I have constructed upon the way has made subsequent additions increasingly straightforward. The CAN bus controller in particular has made slotting each new control and gauge into the setup sufficiently easy that I was able to add a horn control to the setup in just a few hours, most of which were spent soldering and crimping. I can now sound the horn on my virtual trains much the way a driver would in a real UK train. As always, you can read the full post on my blog, https://z80.me/blog: Train Simulator Controller: Horn Control.

Train Simulator Controller: Horn Control

Train Simulator physical controller train horn control

Unlike the United States, where train horns are often multiple simultaneous tones (and extremely loud) to distinguish them from car horns, UK train horns typically have two different tones that can be separately and sequentially triggered for the same purpose (as Wikipedia notes). Many trains actually have four options: two loud tones, and the same two tones at a reduced volume. As explained in the linked Wikipedia article, noise complaints triggered new rules that have both reduced when drivers sound horns at all, and generally shifted towards softer horn sounds. To support emulating as wide a range of train as possible, I elected to support those four possible horn sounds: following the example of the venerable Class 125, and compatible with the single volume supported by the Class 80x I’m trying to emulate, loud high and low tones will be up and down respectively, while soft high and low tones will be right and left respectively. However, to provide maximum flexibility, the translation from joystick direction to horn command will take place in the PC-side software.

Prototypical UK horn controls, from a Class 125 HST (left) and Class 802.


The horn control consists of only two items: a four-way industrial joystick, chosen to resemble the horn control on some UK passenger trains, and one of my CAN controllers, its firmware updated to know how to send horn messages over the CAN bus. The first step was to wire up my joystick’s NO (normally open) contacts to a fresh CAN bus controller. The 8+ GPIO pins broken out from the Raspberry Pi Pico that provides its brains are more than sufficient to handle the four digital inputs for the direction in which the joystick has been pushed, so no modifications to the CAN bus controller were necessary. For previous controls I have used simple 0.1" male and female headers (pins and sockets), but I have wanted to start moving towards something a little more mechanically secure - not least because my DRA button keeps getting disconnected! I elected to use JST-SM connectors, similar in pitch to those simple headers (2.5mm or just under 0.1"), supporting up to 3 amps at 250 volts, and most importantly, locking with some force needed to unlock the latch. Without further ado, I soldered and crimped wires onto the CAN bus PCB side, then onto the joystick side, sharing a common ground between each of the switches in the joystick to reduce 8 potential wires to 5.


Wires attached to four-direction joystick for Class 80x horn control, connected to a JST-SM connector soldered to the CAN bus controller.

With the hardware complete, next up was the firmware. Each CAN bus controller PCB has a set of solder pads to set its identity (visible as A1, A2, and A3 if you look closely in the above images), and associates that ID with a particular function in the firmware. Copying and slightly modifying the DRA/AWS acknowledge button board’s C++ module produced a new horn module that will periodically send the current horn state over the CAN bus, and will also send state change messages every time the horn input changes. Finally, I slightly modified the PC-side Python driver I am temporarily using to interface with Train Simulator Classic to pass this information to the Class 80x, and voila, a functioning horn! I’m pleased that adding new controls has become increasingly simple, and as I continue to iterate on the physical construction of the dashboard, I look forward to adding more controls, such as headlights/taillights, windshield wipers, and pantograph/third rail/diesel engine controls.

Playing the high and low tones of a Class 800 UK passenger train horn. 🔊 unmute to hear that classic two-tone sound.
https://z80.me/blog/tsc-horn-control/img/horn.mp4

Full blog post with more photos and videos on z80.me: Train Simulator Controller: Horn Control

As I continue towards a first complete version of this dashboard, my focus has shifted from designing electrical components to the construction details of its panels and structures. Since early 2025, that process continued with fine-tuning the math used to derive the overall shape and size of the prototypical dashboard. I then developed a cardboard prototype, iterated on a CAD model to be used to get steel and wood components fabricated, and cataloged what buttons I still need. As always, you can read the full post on my blog, Train Simulator Controller: Dashboard Prototyping, Part 1.

Train Simulator Controller: Dashboard Prototyping, Part 1
Thus far in my journey, I have shared my design process up to the end of January 2025, including referencing existing 3D models to guess the slopes and sizes of the various panels of the dashboard and creating 1:5 and 1:10 scale models. Since January, I have continued the prototyping process with:

• Cataloging the buttons and indicators I have available, and discovering that I have quite a few more to find and order. Examples of components I still need to find include latching (maintained) button actuators, bayonet-style LED bulb holders, emergency stop buttons, and smaller buttons for a mock TPWS panel.
  
• Diagramming the panels within the dashboard, including accounting for the depth of the material to be used for the panels.
  
• Using these diagrams to construct cardboard prototypes of each panel, then gluing them together to get a sense of the size of the result - and whether it will even fit on my desk.
  
• Using the diagrams and 1:1 cardboard model to refine the design into steel and wooden components that can be fabricated - and soon, to resist the friendly nibbles of two cats that love chewing on cardboard.
  
• Focusing in particular on the placement of buttons, such as within a mock TPWS panel, and the array of indicators flanking the speedometer panel.

I started with nailing down the precise dimensions of each of the panels in the dashboard, using the geometry calculations from the Python script discussed in my January 2025 blog post and accounting for the thickness of the neighboring panels and supports. At this stage, I was envisioning laser-cut 1/4" plywood (actually 0.56cm thick), the thickest (and thus strongest) readily available plywood that would be thin enough for the various buttons I am using to be correctly mounted. I covered pages of notebooks with dimensioned diagrams.

As I nailed down an initial set of dimensions for each panel, I then began to create 1:1 cardboard versions of each, including sandwiching together two pieces of corrugated cardboard with grains at right angles for maximum strength and the correct thickness. Over six months, I added pieces to this collection, plus three of the four supports necessary to let the cardboard prototype be freestanding. And a few weeks ago, I began cataloging exactly how many indicators and buttons I have, and how many I still need to acquire. With this inventory in hand, I resumed my US and UK eBay research for the missing lenses, actuators, bulbs, and whole button assemblies that would be needed to complete the dashboard. Many of my existing button components come from disassembling two Class 313 dashboards - hence, for example, the smiley face-adorned actuator in my collection.



I also began translating my hand-drawn diagrams and unassembled cardboard components into CAD drawings that could be sent to a fabricating company to create hardboard and/or steel versions of these panels. Along the way, I refined the dimensions, the button layouts, and the cutouts for various one-off components like my air gauge and AWS sunflower. I also switched from directly cutting out every button cutout from large panels to using smaller panels for some sections, such as the TPWS interface and the DRA button, matching the prototypical Class 80x’s excellent example.



Shortly before The Greatest Gathering at the beginning of August 2025 in the UK, I was motivated by knowing that I would see several simulators to finally start putting these cardboard components together. I hoped a more completed prototype would allow me to judge the size and shape of the result. A few days of sporadic gluing later (not least of the cardboard supports behind the dashboard), I placed the dashboard prototype on my desk. My immediate discovery was that it was about two centimeters too tall to fit under my 55" Samsung Odyssey Ark monitor, even with its stand raised as high as possible. Helpfully, while I was placing the buttons on the left-center panel, I discovered that it also seemed taller than the real thing: no matter where I placed the Snow Brake button, it was either too close to the Emergency Stop button above it or to the bottom of the panel. Therefore, I intend to shorten the bottom section of the center panel, solving both the button placement and fitting the dashboard under the monitor. And if I can get a better sense of the size of these panels from the Class 80x at The Greatest Gathering, all the better for the realism of my simulator. Next, I’ll be completing my cardboard prototype and rapidly moving on to a steel-and-wood version, including added a wooden framework behind the panels to save needing the edge-to-edge mounting of the panels to provide all of its strength.

Earlier in September, I posted another blog post about my continuing adventures designing and building the physical structure of my Class 80x-esque Train Simulator controller, but I never cross-posted the highlights here. I'm now attempting to remedy this; as always, feel free to check out the original post on my blog: Train Simulator Controller: Dashboard Prototyping, Part 2

Train Simulator Controller: Dashboard Prototyping, Part 2
As in the previous post, my initial attempts to determine realistic dimensions of the Class 80x dashboard from photos and other materials yielded a cardboard prototype. That prototype revealed several key errors, including lower portions that were too steeply angled and too tall, and an upper section that was too wide. It also was just barely too tall to fit underneath my large monitor even when the monitor is raised as high as possible on its stand (which may be fine). The cardboard prototype thus served its primary purpose, allowing me to compare the shape and layout of my recreation to its apparent size and shape in photographs. It served a secondary purpose of allowing me to test the size and shape of the apertures for my various buttons, selectors, and gauges: and correct the dimensions as needed.

The next step was to incorporate these discoveries into a refined set of 2D CAD drawings, which I continued to do in QCAD. I also carefully adjusted the measurements to allow for the 3.2mm of thickness at certain edges: I determined that I would have the prototype laser-cut out of 3.2mm-thick hardboard, the same material used for the backing of stereotypical clipboards. I added crenellations (regular rectangular cutouts) at the edges of these pieces to allow them to be fitted and glued together. To make sure I hadn’t made any mistakes, I extruded and virtually assembled the components in Autodesk Fusion, then sent them off for fabrication.



The pieces eventually arrived back, wrapped very thoroughly in a great deal of cardboard and tape, helpfully looking exactly like my 2D design. For a quick sanity check, I assembled the components without any glue or fasteners, and everything appeared to fit where it belonged.



The next step of course was gluing these components together, interleaved with making sure the apertures for the instruments, buttons, and other components remained the right size. I first constructed the upper center portion, gluing together four of the pieces and bolting in the three panels that populate this upper section: TPWS, DRA button, and a combined air gauge, AWS sunflower, and couple/uncouple buttons panel. I haven’t yet inserted the AWS sunflower in the following photos, as it is (very) heavy, and I have doubts about the strength of the hardboard to hold it unsupported (I later discovered it's just fine). I then also began to glue together the lower center portion of this center console, in which the speedometer and ETCS touchscreen normally live: since I don’t have an appropriate touchscreen yet, I am proceeding with only installing a speedometer. In Part 3, I will show the remainder of the assembly process, how I added icons inside the buttons, and this console of the dashboard ready to test.

This is absolutely amazing progress. Inspiring me to finally make a driving sim dashboard.
Can't wait to see the touchscreen installed, and how this looks with the rest of the controls.
Keep it up, Kerm!

P.S.: Thank you for introducing us to new words. "Crenellations" is a very creative use of imagery.

Thanks for the kind words, NoahK! I hope your project is going well.

I've published a post about the next component of my project! TPWS is a key safety system in UK trains, so my Class 80x cab needed a precisely replicated TPWS control panel. Here's how I created it: Train Simulator Controller: TPWS Control Panel.

Train Simulator Controller: TPWS Control Panel
As I continue to build my adaptation of a UK Class 800 dashboard and cab for train simulation, I often need to create replicas of equipment from scratch, when it is impossible or infeasible to get the real thing. One important panel interfaces with the Train Protection and Warning System (TPWS), which automatically stops a train if it passes a stop signal without permission (SPAD), exceeds permitted speeds in several situations, or approaches buffers at end-of-track too quickly. Alongside the Automated Warning System (AWS), TPWS provides similar protections to Positive Train Control (PTC), preventing trains from entering blocks without permission, overspeeding through sharp curves, and overrunning end-of-track at speed.

TPWS panels are available in a “standard” version, with two buttons and one illuminated indicator, or an “enhanced” version, with five buttons (four of which illuminate) and one illuminated indicator. The Class 80x trains are fitted with the enhanced version, shown here in situ in 802016, with red and yellow buttons at upper left of panel:

Cab of Class 802, center panel, CC BY-SA 4.0 by DoctorWhoEditor2

Thanks to knowing what make and model of buttons are used in the panel, I was able to deduce the overall dimensions and layout from photographs, and used SendCutSend to get a piece of mild steel cut and powder-coated to spec. When it arrived, a test-fit showed that the requisite buttons fit snugly into their apertures:


Test-fitting buttons in fabricated TPWS panel

As with many of the other components of my train simulator, I sourced both new and used button components, gradually collecting everything I needed. And as with my other components, I wired the buttons and indicators up to one of my CAN bus transceiver boards, now with a new I/O Expander daughterboard that allows robust, debounced inputs and low- to high-current outputs to be connected to the CAN bus board.


Wiring up TPWS buttons and indicators

When completely wired up, I was able to test the result with my on-computer Train Simulator interface software, illuminate the indicators, and register button presses. The final missing piece is to print the necessary labels on the powder-coated metal, which will be covered in a future post.


TPWS panel, all indicators illuminated