RailCommand Supported Hardware

Concept

RailCommand talks to your command station and your detection bus directly, through a native driver per protocol rather than through a single bridge. The public page at /hardware lists every driver that ships, and it rates each one by evidence, not by how finished the code is. Five tiers, used the same way in every row:

• Field-tested: run on a real layout by us or by a beta partner, with the connection, detection, track power, and occupancy path all exercised.
• Implemented, awaiting a layout: the driver is complete and tested against protocol captures and conformance vectors; nobody has run it on the physical system yet. We say so, and we ask owners of that system to test with us.
• Train control only: the driver runs trains but does not yet read or drive layout devices over that bus.
• Built in: ships inside RailCommand and needs no hardware; for learning the app and testing without a layout.
• Accepted, not yet built: designed and approved for a later release; not in the shipped app. A row carrying this tier says what RailCommand will do, never what it does today.

The bare word "supported" is never used for a system nobody has run on a layout. A row moves from "implemented, awaiting a layout" to "field-tested" only when a layout run happens and is recorded here with its date and its layout; the page never promotes a row on its own.

The driver list itself is not prose. It is generated from RcDriverTypes.Canonical (src/RailScanPro.Domain/RailCommand/Hardware/RcDriverTypes.cs), the 20 canonical DriverType tokens the database CHECK constraint accepts, through SupportedHardwareCatalog. A unit test asserts every canonical token appears exactly once in the catalog and that the catalog names no token outside it, so a new driver cannot ship without a row and a retired one cannot linger. Driver status evidence is section 15 of docs/features/railcommand/world-and-environment/ue-runtime/HARDWARE-DRIVER-REQUIREMENTS.md.

What RailCommand runs today

The BiDiB row covers two canonical tokens, BIDIB (the command-station driver) and BIDIB_FEEDBACK (the detector-module bus), because an owner buys and installs them as one system. Every other row is one token.

Hardware is detected automatically wherever the protocol allows it: USB vendor and product ids, an LCC port probe, a Z21 UDP probe, TCP probes for ECoS, Märklin and JMRI, and serial probes on an opened port. Anything the app cannot name is set by hand. One RailCommand can also run more than one connection at once, so a command station for the trains plus a separate detection bus for occupancy is an ordinary setup rather than a special case.

How To

Read the tiers before the table: the tier is the promise, and the row is the detail.

1. Open /hardware on the public site, or reach it from the Resources menu or from the Downloads page.
2. Find your command station in the System column. If it is not there, RailCommand has no driver for it and no page row will appear for it.
3. Read the Tier today badge against the definitions at the top of the page.
4. If the row reads Implemented, awaiting a layout, the driver is written and vetted against protocol captures, and yours would be the first physical system it has met. Get in touch and we will do the bring-up with you.
5. If the row reads Train control only, expect the driver to run trains over that bus and expect to wire layout devices (turnouts, sensors, signals) through another connection.
6. Install the desktop app from /downloads, then configure the connection in the desktop's Hardware Setup. The picker covers 20 of the 20 systems: every driver on this page has a row, because the picker is built from the same canonical driver list this page is. Phone throttles are the one row that is not a command station: pick "WiThrottle server (phone throttles)", which offers 0.0.0.0:12090 as the interface and the port RailCommand should listen on (0.0.0.0 accepts phones on every network this machine is on), change it if you want one interface only, then point Engine Driver or WiThrottle at this computer.

To offer a layout for testing, use the feedback form or write to support@railscanpro.com and say which system you run, which interface, and what the layout has for detection.

Troubleshooting

• My command station is not on the page. RailCommand has no driver for it. The page is generated from the shipped driver list, so an absent system is genuinely absent rather than an omission in the copy. Massoth DiMAX is the known case: no published serial protocol, so it has no native driver.
• My system says "Implemented, awaiting a layout" and I have it working. Tell us. That is exactly the run that promotes the row, and we record the date and the layout with it.
• I run LCC and my turnouts and sensors are not seen. Expected today. LCC is train control only: train search, controller assign and release, and CV programming over LCC work; layout events (turnouts, sensors, signals as LCC events) are designed and accepted for a later release, and not yet built.
• I bought a SPROG and my trains will not move. Expected. SPROG is a programming-track device: RailCommand writes CVs to it and nothing else. Run the layout from a command station and keep the SPROG for programming.
• My Digikeijs DR5000 is not listed separately. It speaks the Z21 protocol and runs on the Z21 row. It was never a distinct driver.
• My system is on the page but not in the desktop's Hardware Setup picker. No longer a state any system is in. Five used to be: SPROG, BiDiB, the BiDiB feedback bus, MQTT sensor nodes and the simulator shipped a driver the setup screen had no row for. The picker is now built from the canonical driver list rather than a hand-kept one, so a driver cannot reach this page without reaching the picker. If a system on this page is genuinely missing from your picker, that is a defect and not a gap: write to support@railscanpro.com with your desktop version.
• Detection did not find my interface. Automatic detection covers the probes listed above. Where a device shares a generic USB chip with other hardware, or sits behind a transport with no probe, set the connection by hand in Hardware Setup.
• I want to run trains from my phone. RailCommand hosts phone throttles itself, the way JMRI and DCC-EX do: it listens on port 12090 and Engine Driver, WiThrottle and other compatible apps connect to it. Add the "WiThrottle server (phone throttles)" connection in Hardware Setup, give it the interface and port to listen on, and point the phone at this computer. That row reads "implemented, awaiting a layout", so yours may be the first physical railroad it meets.
• The phone throttle connection will not save. That connection takes two things, an interface and a port, written as 0.0.0.0:12090. Picking "WiThrottle server (phone throttles)" puts that default into the field for you, where you can read it and change it: 0.0.0.0 accepts phones on every network the computer is on, and naming one interface instead accepts them on that network only. The interface is an IP address, either an IPv4 address like 192.168.1.50 or an IPv6 address in square brackets like [::]. A name such as localhost is refused, because a name is looked up later and can answer with a different address each time, and this field has to say exactly which interface the computer binds. What is never filled in for you is the SAVE: a port on its own is refused, so is a port outside 1 to 65535, and so is an interface that is not an IP address. The message says which of the three is wrong, because which interface the listener binds decides who on the network can reach it and that is your decision to make.
• The phone throttle connection cannot be the primary command station. That checkbox is not offered for it, and the role is cleared if a connection that had it is changed to this one. A phone throttle carries your instructions in and drives nothing on the railroad, so it is never the connection the layout falls back to; give the role to the command station instead.
• I need two systems at once. Supported by design: a command station and a separate detection bus can run as two connections on the same RailCommand.

Safety Notes

The tier is a statement about evidence, not a safety certification. A field-tested row means the connection, detection, track power, and occupancy path were exercised on a layout; it does not remove the operator's responsibility for the physical railroad. A row in implemented, awaiting a layout has never met the physical system at all, so treat a first run as a bring-up: keep track power under your hand, watch the first movement, and be ready to cut power.

Neither the public site nor the desktop app drives hardware or moves trains. The local runtime owns all safety-critical execution (occupancy enforcement, interlocking, movement authority). Reading a row on this page tells you what RailCommand can talk to; it never tells you a movement is authorized.