PC Control of MTH Engines by Radio Connection to the TIU
Posted: Tue May 17, 2016 3:08 pm
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 https://www.youtube.com/watch?v=MxlUb-YccZw
Chapter 2 https://www.youtube.com/watch?v=IBrhLSVHjIo
Chapter 3 https://www.youtube.com/watch?v=oqaeeR3pgPw
Look at this OGR Forum thread for a followup:
http://ogrforum.ogaugerr.com/topic/wond ... 9459030161
Mike made more progress as shown in this video from 2013
https://www.youtube.com/watch?v=Ug5CSZFwo-c
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:
http://www.silogic.com/trains/RTC_Running.html
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 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.
Conclusion
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.
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 https://www.youtube.com/watch?v=MxlUb-YccZw
Chapter 2 https://www.youtube.com/watch?v=IBrhLSVHjIo
Chapter 3 https://www.youtube.com/watch?v=oqaeeR3pgPw
Look at this OGR Forum thread for a followup:
http://ogrforum.ogaugerr.com/topic/wond ... 9459030161
Mike made more progress as shown in this video from 2013
https://www.youtube.com/watch?v=Ug5CSZFwo-c
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:
http://www.silogic.com/trains/RTC_Running.html
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 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.
Conclusion
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.
