Model Train Forum banner

1 - 4 of 4 Posts

21 Posts
Discussion Starter #1
To me, MTH makes the best engines and rolling stock for my railroads of choice, the Pittsburgh & Lake Erie Railroad and the Aliquippa & Southern Railroad (where my grandfather worked). MTH has many many engines and dozen of pieces of rolling stock for these railroads. My layout uses only MTH's DCS.

DCS has been out for almost 15 years. I've been waiting for a way to control my layout using my PC. I've always used Windows PC's so this effort was done originally using XP and more recently Windows 7 and Windows 10.

A few years ago, Mike Hewett presented a PC interface to the tethered mode of operation of DCS. He showed how to sniff out the RS-232 packets running between the Remote and the TIU, how to save those packets and how to later transmit those packets to the TIU from the PC. He connected to the TIU using a tether (phone cable).

Mike presented his findings in three videos which he produced around May of 2011. Look at those three videos before you continue with my description.

Chapter 1
Chapter 2
Chapter 3

Look at this OGR Forum thread for a followup:

Mike made more progress as shown in this video from 2013

I think that I first saw what Mike did around October of 2011 as my earliest date stamps on files that I've saved are from that date.

Mike's methodology was to record the packets sent by the Remote when each key on the Remote was pressed. Without regard to the contents of the packets, he saved them in a file. Then, later, his PC program could read up those saved packets and send them to the TIU. He created a very nice touch screen interface and he could run his DCS trains from his PC.

I contacted Mike back then and he sent me copies of his program and I was able to build up his interface to the TIU, sniff out the needed packets and I had a way to control my trains from my PC.

This worked up to a point. When I added a new engine number, I had to run the packet sniffer again and pick up the packets needed for the new engine number. Mike's program only captured a subset of the many, many types of commands that could be sent to the TIU. Mike did not read back responses from the TIU or process any of those returned packets.

I was looking for something more. I wanted to understand the protocol over the tether cable.

With a lot of effort, I was able to understand almost all of the communications between the Remote and TIU. I am now able to create packets to control the DCS engines. The packets are complete with correct addressing, command syntax and CRC.

I figured this out by examination of the packets that I could sniff using Mike's original RS-232 interface design and the port settings that he found. Without Mike's insights into the RS-232 data stream, I don't think that would have been able to get a foothold into this protocol.

So again, I figured this out just by looking at the RS-232 stream over the tether cable. No code disassembly, no logic analyzers, no opening up of Remotes or TIU's.

I made up videos (Screen Captures) of the operation of my RTC or Remote Train Control program. These videos demonstrates part of its use:

My purpose in what I did was to develop a new way to run my trains. I'm not competing with anyone else, especially MTH since they don't have a product for PC control that they sell or give away. I'm not selling anything that I've done. The program and source code are freely available on my web page. It is distributed under the GNU Public Licenses.

Understanding the protocol over the tether is what is most useful. Mike (skylar) wrote about wanting to build a system with sensors that adds location information to the mix. I can envision something like the operation of the Lionel 132 Automatic Stop Station that you could automate with location sensors and PC control. (Something that you could do 60 years ago but can't do today!)

The DCS patent does not talk about the serial protocol. I've learned from my analysis that the protocol is an industry standard RLL(0,1) which is just a fancy way of saying how often the RS-232 signal changes from 1 to 0. Part of the encoding is actually patented and not by MTH - #5,625,644 issued in 1997. The next part uses Morton or Z-Curve encodings. You can Google that. Third are the commands themselves. They are in ASCII and are based on an Application Note published by Microchip Technology in 2002, look for AN759. These public documents describe the protocol completely, it was just adapted to model train control. All of these documents were found on the Internet.

The original wired tethered connection to the TIU was the next to be replaced. I dug into understanding the radio connection between the Remote and TIU. Again, searches on the Internet provided the frequencies used. A hint on a blog pointed me toward OOK (On-Off Keying) as the mode of data transmission. I guessed that the command protocol over the radio was the same as used on the tether (it was). I learned about two different boards that use the TI CC1101 radio. This radio covers the frequencies required and speaks OOK.

I learned how to program the CC1101 from scratch. I searched the Internet and got little bits of help. I found a program called SmartRF Studio 7 from TI which helps set the values needed for the CC1101 configuration registers. Months of digging through the CC1101 data sheet and test code for the Arduino's Atmega328p MCU finally led me to a working receiver. Then a working transmitter. I called my Arduino program "RTCModem". I could communicate between the PC and the TIU with my Remote Train Control program. (note: this paragraph took about 5 months actual work.)

I wrote RTC using Borland C++ Builder because that is the software that I used years ago when I was still working. There are probably other better environments which would better handle the real-time control aspects (like asynchronous RS-232 characters arriving). C++ Builder is not really good at that. When I started writing the program, I had no idea what the protocol to the TIU was. I had to write my program to handle many different protocols, of which all except one turned out to be deadends. For example, I used CRC code that could handle dozens of CRC algorithms. But only one was needed once I understood which one. All of that extra code is still in the program. The CRC code, by the way, was written by Ross Williams, who placed it in the public domain in 1993.

So the program is free from my web page. You can build a tether interface for a few dollars or buy one of two different radio implementations (about $50-$60). Not bought from me, one radio from a company in Spain and one from a company in China. Details on my web page.


Once the protocol is known, practically anything can be done by writing software. I haven't yet completed my analysis of the protocol. My program knows most of the train control commands and AIU commands. It can handle lashups and conventional operation. It can do routes and scenes. I've started writing the TMCC code but I need to borrow a TMCC system and engine as I don't have any.

Writing a program that encompasses every aspect of train operation is not something one person can do alone. Maybe because of that, PC control will never be practicable. It is not possible for me to singlehandedly write a program that will satisfy everyone. But I can probably do enough to let enterprising and interested hobbyists have the ability to operate their trains in a different way.

1,101 Posts
Looks like you and Mike did a lot of work. I'll take a look at all the videos and read the rest tomorrow. Didn't want you to think no one was looking.

Sent from my iPad using Tapatalk

21 Posts
Discussion Starter #4
Version 3.20 of the Remote Train Control program is available on the web page.

The big addition are Hot Buttons. This is a window of 20 buttons that you can program to perform most any operation, on any engine, on any TIU or AIU. So if there are functions that you do over and over, on any TIU or to any engine, you can setup this window to do that function with one click of a button. You can popup this window and keep it on the screen to use as needed.

The program and source code are freely distributed under the Gnu Public License v3.0.



1. Added Hot Buttons:

Up to 20 Hot Buttons can be defined. Once defined, a click on the button will immediately send that command. To open the Hot Buttons Window, click on the [Hot Buttons] button on the Main screen.

To edit a button, right click on that button. Fill in the fields:
- Button Label that will appear on the Hot Buttons Window. Use "&&" for "&", ie "P&&LE".
- Command to be executed selected from the drop down Command List
- TIU Number 1-5
- Engine/Lashup Number: Engines 1-99, All Engine Operation 100, or LashUp 101
- for AIU commands, the AIU Number 1-5 and the Port Number 1-10
- for LashUps, the LashUp String - engine numbers separated by commas, using a minus sign to indicate Reverse Running.
- for engine sounds, enter the sound number 1-255

Press the [OK] button to accept that command.

To undefine a button, right click on it, press [Clear] and then press [OK].

A special function "Playback of a Recorded File" lets you associate a recorded file with a hot button. When you press the button, the recorded file will play. You can cancel playback by pressing the [Cancel] button on the playback popup. You can repeat the playback by checking [X]Repeat.

The program, internally, maintains the Command list. If you want to add a command, right click the Hot Buttons Window outside of the Hot Buttons themselves and select "Edit Command List". Each line in this list is a command. The format is "Command Description"="Command". Press [Done] to save the edited list. The edited list is saved in the RTC folder with the name "HotCommands.txt". You can delete this file at any time to return to the internally maintained list.

2. Moved position of Quick Controls button

3. The buttons for Startup All Active Engines and Shutdown All Engines have been removed. To perform these functions, right click on the Main Window and when you get the popup menu, you can select these functions.

4. In the setup, you can select [X]Allow 255 Sounds. This sets the Engine Sound knob on the Sound Controls window to show sounds 1-255 on the knob. With this, you can play all 255 sounds in the engine. On the remote, "S01" hot key selects sound 177, "S02" selects sound 178 and so on. The 1-255 number corresponds to the index into the sound file as shown by the ADPCM program.

4a. For touch screen users, I added up/down buttons to both the Engine and Idle Sounds knobs. With a touch screen, the knobs are too hard to accurately control. The knobs themselves may disappear someday.

5. Totally rewrote the recorded file playback routine. Now when you select a recorded file for playback from either the Setup window or the Hot Buttons window, the playback runs as a separate thread. That means you can do other operations or even other playbacks while the playback is running.
1 - 4 of 4 Posts