For quite a few years now, I have been an avid Train Simulator player, operating virtual trains from the United States, the UK, and beyond. I’ve played Dovetail Games' Train Simulator 2015 to 2022 and now “Train Simulator Classic”, FIFA-style annual upgrades that have incrementally improved the core game - and I’ve spent a decent amount of money on the much-memed Train Simulator DLC. The game is pretty immersive, but since part of my life also includes running real-life rail vehicles, I naturally want to make it feel even more real. The next logical step would be to build a physical controller for Train Simulator.

This has been done before: the best-known option is the RailDriver controller, a dashboard-esque plastic slab with most of the controls you’d need for a (virtual) train: independent and automatic brake levers, a combined throttle/dynamic brake lever, reverser, high/low horn lever, a digital speedometer, and a host of buttons that can be programmed and hand-labeled to be other train controls. While I have been intrigued by the RailDriver, the price has intimidated me ($200), and I also have mixed feelings about the plasticy, unrealistic look.

More recently, Alan Thomson Simulation has released a set of pricey but sturdier, more realistic-looking controller components for Train Simulation (https://tscontrollers.com/), such as a door controller unit, a power/brake handle, and an AWS plunger. Each of these looks like a fine product, but each is also expensive, and most are sold out. What I really want is something that feels even more like the dashboard of a real train, and that’s the challenge I’m setting for myself. In particular, I want to model my Train Simulator controller after the cab of a Class 80x (800, 801, 802, 805...) UK train.



Since November 2022, I have been working on various aspects of this project, including:
  • Starting from taking apart standard instruments like an aftermarket automobile tachometer to understand how modern electromechanical instruments work, documented in "Train Simulator Controller: Stepper Speedometer Begins".
  • Beginning to design a master controller (the unit and handle(s) that control the throttle or combined throttle and brake), drawing on 108-year-old documentation and my 3D printer. My first steps here are documented in "Train Simulator Controller: Master Controllers and Starwheels".
  • Exploring making, acquiring, and eventually successfully acquiring the excitingly named "AWS sunflower" used in most UK trains, getting it to work, and then getting it to work with Train Simulator. The basics of the AWS sunflower is documented in "Train Simulator Controller: Inside an AWS Sunflower"
  • Further refinements, redesigns, and more 3D printing to ultimately build my first master controller prototype in May - June 2023 (blog post not yet written).
  • Never one to underengineer, I decided to link all of the instruments in my controller together with a CAN bus, just like a real modern vehicle (although my research suggests modern trains usually use buses that are not specifically CAN). I have designed, iterated on, and created at least five versions of the hardware and firmware to date of a Raspberry Pi Pico-based CAN transceiver/GPIO board designed as a universal component of my Train Simulator Controller instruments. This versatile little board lets me control stepper motors, solenoids, I2C hardware such as LED and LCD displays, and backlight/illumination and signal LEDs, and can read input from buttons, switches, rotation/position sensors, and just about anything I will need to incorporate. Many photos and blog posts still pending on this particular rabbit hole.
  • Gutting (sorry, Jeff) and modifying a real Salem dual-needle locomotive air gauge to work with a coaxial dual stepper motor controlled by my CAN transceiver, as my first prototype CAN-compatible instrument for my dashboard (blog post not yet written - are you seeing the pattern?).
  • Extensive research and purchasing of ex-train dashboard parts such as gauges, buttons, and switches, including painstaking Google Image-searching to try to (eventually successfully) determine exactly what makes and models of buttons and other standard industrial controls were used in some of the UK trains that are inspiring this project.


I have been dragging my feet on actually posting about this project on Cemetech (save for this oblique topic about stepper motors), but now that I have finally gotten it started, I intend to post much more frequently about the project, including plenty of visuals that are missing from this introduction. Don't hesitate to post any comments, questions, and suggestions - and if you happen to be a Train Simulator enthusiast, a current or past driver, or especially have good (legal) sources for scrapped or OEM equipment (especially master controllers - anyone have a connection at Faverly?), please let me know!

Neat. Love things like this (arcade machines, simulators, etc.) Thanks for posting! Good luck, and keep us updated!
CoolModder wrote:
Neat. Love things like this (arcade machines, simulators, etc.) Thanks for posting! Good luck, and keep us updated!
Thanks! I'll do my best.

Yesterday evening, I spent some time with the CAN transceiver software, focusing especially on my two-needle air gauge. I was previously pausing the firmware to display blink codes on the Raspberry Pi Pico's onboard GPIO-connected LED, but this was having knock-on effects. For example, while blinking a code to indicate that the CAN RX or TX queues were full, other messages would back up, and it would therefore be stuck in a loop. I switched to a cooperative multitasking-esque solution with a singleton class in charge of the LED, with a queue of pending blink codes (specified as positive microseconds to illuminate the LED, and negative microseconds to extinguish the LED), advanced through by a tick() method called in the firmware's main event loop. This cleared up all my problems, and I was able to run the needles of the air gauge continuously from 0 to 160 PSI and back for a half-hour without it noticeably pausing.

Today, I soldered up a third CAN transceiver board from my latest produced iteration (v0.7 - a newer iteration that has uses the RJ-45 activity LEDs to indicate CAN bus activity is currently at OSHPark), and used this to build a new version of my AWS (Automated Warning System) controller, with the same CAN firmware as on every other instrument but set to act as the AWS controller. A note of interest: I use three GPIO pins on the RP2040 to encode up to 27 unique instrument addresses: each pin can be left floating, pulled low, or pulled high by way of three sets of three solder-bridgeable pads on each CAN transceiver board. I hooked my authentic AWS acknowledge button pulled from a UK Class 507 train and purchased on eBay and my AWS sunflower to the board, wrote a bit of Python code to interface Train Simulator Classic and the USB serial exposed by my CAN transceiver set to act as a serial-CAN bridge, and voila, brake pipe/cylinder and main res pressures, AWS indications, and proper AWS acknowledgement! It did turn up an issue: the AWS acknowledgment is bouncing badly, even just from touching it (perhaps a capacitor is needed - the long wires leading to the button may be introducing a bunch of noise - or perhaps I forgot to turn on a pull-up resistor in the firmware?), and the air gauge, which has a minimum value of 5 PSI on the dial, grinds infinitely trying to reach 0 PSI. Both issues will be on my agenda to fix soon.

The following two days, I put together two more of the CAN transceiver boards, and wrote the firmware for left- and right-side door control modules and for the Driver's Reminder Appliance (DRA) module. It was this latter that I had the parts to fully prototype: I hacked up a Siemens push/pull industrial illuminated mushroom to cut the 120V-to-24V AC transformer out of the illumination circuit, and connected the LED and the NC contactor in the button to one of the CAN transceivers. For maximum safety, the LED isn't tied directly into the button, but is illuminated and extinguished by a separate CAN message from the host after it confirms the DRA button has been pulled or pushed. With this, I was able to drive a Class 802 in Train Simulator with DRA, AWS indication and acknowledgment, and MR and BP pressure on the gauge.

Video of the DRA in action here: https://z80.me/blog/tsc-dra-1/img/dra_action.webm

Wow that's super cool. I also live wiring buttons and things for playing games. Very Happy
This reminds me of a custom-wired Xbox controller I saw on ebay...
Suffice it to say, it was not shaped like a normal gaming controller and it honestly looked very uncomfortable to hold, but it reminds me of the crazy things people can do to make a game more immersive and way cooler to play!
How much longer do you expect you will need to work to achieve the finished product?
This looks super cool but also I have no idea the level of effort this must require Wacko
icyshadowking wrote:
How much longer do you expect you will need to work to achieve the finished product?
This looks super cool but also I have no idea the level of effort this must require Wacko
I've been working on it for over a year now, and realistically I expect it'll take the better part of this year to complete it. The items I expect to be most time-consuming:
  • Designing and getting cut the sheet metal panels that will form the angled surface of the dashboard.
  • Designing and building the wooden or metal framework that will serve as the desk and support for the angled surface of the dashboard.
  • Continuing to build, or sourcing, a master controller.
  • Learning to apply silkscreens to sheet metal, and doing so.
Last May, I prototyped a full master controller, starting from the starwheels that allow the controller handle to go into and stay in well-defined positions or "notches". I expanded from a variety of increasingly large and complex 3D printed prototypes of the starwheel itself to a set of two complementary starwheels, a disk containing the controller handle, two spring-loaded notching arms, a preliminary design for mechanical components to interlock a key switch and reverser switch, and a base onto which the other components could mount. My final prototype looked like this:



I outline more of the process of designing this prototype in a short post on my blog, and include a video of notching this prototype up and down. While it functions mostly as designed, I also found it to require more force to notch up and down than I wanted, and I was dissatisfied with the strength of the 3D-printed ABS plastic parts. In the future, I may try even larger starwheels, I may switch to more starwheels with fewer, better-defined notches each that allow larger, easier-rolling rollers, and I may even experiment with inverting the design: spring-loaded roller that moves, with a static arc of notches surrounding the moving parts.

Edit: Because I thought it needed a bit of visual clarity, here's where the notches actually are in the starwheel. As in the prototype (that is, real trains), pulling the controller handle towards you increases the throttle power, moving the notching arms through successive notches towards the right of this image, while pushing it away from you brakes, moving the notching arms towards the left of this image.



Video and more details: Train Simulator Controller: First Master Controller Prototype
You say it's just a controller but in reality you're going to 3D print and entire train right?
tr1p1ea wrote:
You say it's just a controller but in reality you're going to 3D print and entire train right?
Haha, I'm not not going to make a train...
Kerm you have outdone yourself this is so cool. Can't wait for you to post the video where you 3d printed a train Wink
Thank you, that would be my crowning achievement. For now, I seem to be managing by just collecting all the parts of a train, piece by piece. The month and a half lapse since I last updated this thread is by no means indicative of how hard I've been working on this project: in fact, I have been doing a remarkably poor job of pausing my furious pursuit of this project to actually take some photos, do a Train Simulator stream, and write some documentation. Without further ado, here's an update that covers progress I made back around June 2023, and my full blog post about it is here: https://z80.me/blog/can-controller-1/.

CAN Controller Part 1

So as I have been posting, I have a grand vision for this project: the equivalent of a real train dashboard that I can use to control simulated trains. I'm sourcing all of the instruments and controls that I can from real trains, with hopefully minimal need to fall back on creating simulated versions of instruments (like my paused master controller re-creation). All of the instruments (outputs) and controls (inputs) need to be interfaced to my computer somehow. The engineer or hobbyist interested in getting this project ready expediently would probably find their favorite microcontroller, figure out how to interface enough GPIO pins to it (maybe an Arduino Mega?), and connect all their hardware to that microcontroller. Not me.

Ever dedicated to over diligently engineering my projects, I decided to build each component of my Train Simulator setup with a controller capable of speaking connecting to a CAN bus. This would allow me to build truly modular components that could be arbitrary added and removed, and there’s another method to my madness: the possibility of one day being able to control an actual train with my Train Simulator setup. For the immediate future, I set out to design a CAN controller board that would provide all the different interfaces I would need for my various controls and instruments, would be easily programmable, and would provide at least some of the safety features of a real CAN bus transceiver, including proper isolation.

I sat down and enumerated all the capabilities, voltages, and I/O I would need for my various instruments and controls. I came up with an assortment of low-voltage, low-current GPIO, 3.3V, 5V, and 12V power, up to three high-voltage (12V) and/or high-current (up to 1A) binary-state or PWM-controllable outputs, an I²C interface, and interfacing with more complex sensors like digital angle sensors, at the very least. With this set of requirements, I was able to select the brains behind the operation: having recently worked a bit with the Raspberry Pi Pico and the powerful RP2040 at its core when I performed my speedometer experiments, and having discovered Kevin O’Connor’s CAN2040 library, I selected the Raspbery Pi Pico as my microcontroller of choice. Here’s how I designed the board to work:



The Pi Pico is powered by a 5V supply (USB or a 5V bus), and directly interfaces with hardware through its GPIO lines, including where relevant via FETs to provide high-voltage and/or high-current control. Following proper CAN bus principles, the power supply for the CAN side of the CAN transceiver is provided by an isolated DC-DC power supply, and the Pico can then communicate via an isolated CAN bus with other CAN transceivers (namely others of this controller board). In addition, one of these boards is designed to be used as a bridge communicating with the computer running Train Simulator (e.g. over USB) and translating messages to and from the computer off of and onto the CAN bus. Thanks to KiCAD, OSHPark, Digikey, and my soldering iron, I soon had a first prototype (the H-bridges for the steppers live underneath the socketed Pi Pico):



I used it as a testbed for three aspects of the CAN controller: powering and interfacing with the Raspberry Pi Pico, controlling hardware like my AWS sunflower and LED matrices, and of course the CAN interface itself.
[list][*] First, testing its ability to control higher current/voltage hardware, like the 12V coils in the AWS sunflower. Video here of it clicking the AWS sunflower on and off: https://z80.me/blog/can-controller-1/img/auto_aws.mp4
[*] Second, testing its ability to interface with a computer and drive a pair of LED matrices, using an extra 3.3V regulator on the controller board. This test brings Train Simulator Classic into the fold, transmitting the current speed of a train as it accelerates out of Orpington, and additionally indicating whether the train is accelerating or decelerating (video): https://z80.me/blog/can-controller-1/img/digitalspeedo.mp4
[*] Finally, my CAN test, which yielded an early success! The CAN bus transceiver IC (ISO1042), DC-DC converter (UCC12040), and other components are sufficiently expensive that I undertook a simple test populating only the CAN transceiver of a second controller PCB with its support passives, using the power supply from the “host” board and even directly connecting the differential CAN bus lines instead of installing RJ-45 sockets (especially since the sockets ended up facing backwards on this first fabricated board version!).



Video and more details: Train Simulator Controller: CAN Controller, Part 1

In my next update: I hacked a beautiful Salem air gauge for stepper motor control (sorry, Jeff) and had myself a second instrument
Nice job Kerm, I enjoyed reading your post. I look forward to your next post and your ongoing progress. I really should pull out my arduino and pi and mess around with something like this. Also, what train simulator would you recommend to someone short on money? Razz
Invalid_Jake wrote:
Nice job Kerm, I enjoyed reading your post. I look forward to your next post and your ongoing progress. I really should pull out my arduino and pi and mess around with something like this. Also, what train simulator would you recommend to someone short on money? Razz
Thank you, I hope I can inspire you to do some embedded development work (not that our beloved calculators don't count there!). There have been a few great and inexpensive Train Simulator Classic bundles on Humble Bundle, although alas nothing right now.

This evening's Train Simulator controller work: write the component of the (currently) Python draft interface to allow speed limits from Train Simulator to be displayed on the ring of LEDs around the edge of my ATP-enabled British Rail speedometers. Train Simulator's hardware interface shows the upcoming speed restriction, in which LEDs blink, by toggling the speed limit between the actual limit and a small negative floating point value, so this required a bit of extra logic to infer the steady restriction limit from the varying floating point values. Video, by way of a stream, coming soon!
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement