Train Simulator Controller: Simulating a GSM-R Driver's Control Panel

GSM-R is the digital radio system used on modern UK railways to provide voice and data communication between drivers, signallers, and onboard systems. In service, it replaces older analog cab radios and integrates tightly with train control, with the Driver’s Control Panel (DCP) acting as the primary human interface for selecting functions, initiating calls, and displaying status information. The DCP is therefore a critical, safety-adjacent component in a real cab, even though by itself it is “only” a terminal.

Over the past year, I have been working intermittently on integrating a real GSM-R DCP into my UK Class 800-inspired train simulator, with the aim of having it operate as a functional, bidirectional interface rather than as a purely visual prop. The panel is a self-contained unit incorporating an RS-485 interface, a vacuum fluorescent display (VFD), a keypad with backlit buttons, and an ambient light sensor, but it was never intended to be used outside of its original railway context and comes with no publicly available documentation. I wished specifically to figure out how to display text on the DCP, change the VFD and keypad backlight brightness, and read the brighness sensor: my project is entirely independent of GSM-R, and has nothing to do with radio communication.

The work to interface the GSM-R DCP began with passive observation. After placing the DCP on an RS-485 bus and monitoring traffic during power-up and steady-state operation, I initially observed only a small set of repeating messages transmitted by the panel. Pressing keys, changing room lighting, or otherwise interacting with the device produced no visible change in the data stream. For some time, the DCP appeared to be entirely unresponsive, emitting periodic frames that suggested it was alive but unwilling to volunteer any additional information on its own. It stubbornly sat with its default power-on message displayed.

At one point, I considered connecting an actual GSM-R radio to the DCP and observing how the two devices communicated, which would almost certainly have accelerated the reverse-engineering process by providing a reference implementation. I ultimately decided against this approach, as I was uncomfortable with the legal and regulatory implications of operating an actual GSM-R radio (even with its transceiver removed or disabled) outside of an authorised environment.

Progress therefore depended on learning how to initiate communication rather than simply listen. By experimenting with carefully constructed messages based on the observed traffic, I eventually identified a set of inputs that caused the DCP to alter its behavior and begin sending additional data. Once this threshold was crossed, the panel transitioned from a silent peripheral into an active participant on the bus, reporting events and state changes that had previously been invisible.

One of the earliest practical results of this was decoding keypad input. Each key press generates a distinct RS-485 message, and once the panel was in the correct operating mode these messages became straightforward to capture and classify. Mapping the keypad was therefore an early success, allowing physical inputs on the DCP to be translated directly into simulator actions long before any meaningful control over the display was achieved.

Driving the VFD proved to be significantly more complex. While input messages were relatively concise and consistent, output control involved longer frames, more rigid sequencing, and a clearer sensitivity to internal panel state. Achieving reliable text output on the display required a much deeper understanding of how the DCP expected commands to be structured and timed. The first successful appearance of arbitrary text on the VFD marked a major turning point, confirming that full display control was possible.

Brightness control followed later and turned out to be closely related to the panel’s handling of ambient light. By correlating changes in display intensity with internal messages associated with lighting conditions, I was able to reproduce this behavior under software control, allowing the DCP to react naturally to the real ambient lighting rather than operating at a fixed intensity.

GSM-R DCP functions in action: drawing text, reading keypresses, and controlling brightness

Finally, I created another daughterboard for my CAN bus transceiver, allowing me to interface Train Sim World 6 with the GSM-R DCP. The final result is a GSM-R Driver’s Control Panel that functions as a living part of the simulator, with real hardware inputs driving in-game behavior and the display responding dynamically to simulator state. The photos and videos below document both intermediate stages of experimentation and the completed installation, illustrating a process that unfolded slowly and irregularly, but ultimately transformed an opaque, undocumented device into a working component of a modern simulation setup.

GSM-R DCP integrated with Train Sim World