I'd like to thank everyone for taking the time to comment on my posting. I've waited to follow up so I could add my thoughts to the comments.
First, I've posted a few more videos on my web page:
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. Once I determine that it is working fairly well, I am going to send the program to whoever can use it. It will probably be distributed under one of 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.
The DCS patent does not talk about the protocol over the tether. 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.
PC control has one (at least) major drawback and that is the need for a wired connection to the TIU. My program only handles one RS-232 port but there is no reason that a program could not be written that uses 5 RS-232 ports, each connected to the 5 TIU possible. In other words, 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 all of the train control commands and AIU commands. I know how to do lashups but I haven't added that to the program. I've not yet looked at a TMCC interface or conventional operation.
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.
My program, RTC, is nothing special. I wrote it 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 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 over the tether 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.
Mark
![]() ![]() ![]()
![]() ![]() ![]()
![]() ![]() ![]()
![]() ![]() ![]()
|