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.