PC Control of MTH Engines by Serial Connection to the TIU

Back in the beta days of DCS, the remote was not yet made.  We had a picture of the remote on a laptop.  It was touch screen to operate the trains.  There was nothing fun about doing that.  When we first got the DCS remote, life was good.

"I'm intrigued by your ideas and wish to subscribe to your newsletter."  

Seriously, though very nice work.  I looked into the method of recording the packets  but actually writing them is great.  As I don't own a DCS system or any PS2/3 locos i've been a bit lax in researching this, but I would like to get as much information as you're willing to provide for future use.  I'll have an email on my profile shortly if you'd like to send any info on how to work the data, or the implementation of your program.  

Thanks for posting. 

Wouldn't it be great if MTH would actually publish the interface details like Lionel does.

Seems the last time I heard of this being done MTH sent a cease and desist letter. Has something changed?  

But it watching the video it looks pretty thorough and cool. 

I don't think it has, if you release anything like this, my guess is MTH will come after you.  I speak from experience.

 I have a few more questions like is adding the engine type done automatically? Consists control? more than one TIU? more than one layout at the same time? touch screen use on I pad device? etc. etc.

What I see looks great! Nice work!

Not if he donates it.  And we make a donation. Or he takes it to China. 

Now this is a post to follow

This looks good. Now if the program can control the rest of the layout switches/accessories, additional TIU and AIUs, control legacy/TMCC engines at the same time, this could be beneficial for large and somewhat complicated layouts. 

Connecting all the systems, and running everything from one interface is not all that complex, once one knows how each system talks.  TMCC put this information right in the user manual from day one.  Legacy they released about a year ago.  as far as I can tell, Mark here now has all the information needed for control of DCS, so it is surely possible, if he's willing to share.  The problem, from what little information I can find, is that MTH will stomp, hard, on anyone that tries to market a product that talks to their system.

Using a $9.99 arduino clone I was able to make a cab1/TMCC issue psudo-dcs commands. Don't own a DCS system, so no real test, but I assumed that Mike, referenced in the original post had done good work, and that the system would read copied packets.  

Mark,

This application is very nice, however, be aware that Hikel O Gauge has already done this to an advanced degree.

The Hikel system works with both licensed software (Train Controller) and shareware (JDRI), and is operational on a number of layouts, including the Northwest Trunk Lines.

I had the Hikel system installed for a while (I decided that I didn't really desire PC control) and can testify that it was very full-featured, including the following:

• Connected to TIUs, Legacy Command Base and TMCC Command Base. I expect that it would also accommodate a Base 1L
• Operated DCS, TMCC and Legacy (in TMCC mode) engines, including lashups, with all engine soft keys
• Operated switch tracks and accessories connected to AIUs
• Allowed on-screen construction of a layout track plan
• Allowed automatic block detection of trains
• Allowed automatic operation for unattended routing of a train from point A to point B
• The Train Controller version of the system includes abuilt-in web server tho allow train operation, and switch track and accessory operation from a smartphone or tablet, either locally or over the Internet
• Many other features and functions.

Hikel O gauge has a license from MTH to use the DCS software.

I've used Mike's method to build an Arduino-based system that automatically routes both DCS and TMCC trains.

Being able to build the command sequences rather than capture them would be very nice!

As far as intellectual property goes, no license is required to send commands to the TIU, and reverse-engineering a command protocol is not a violation either of the Copyright Act or the Digital Millennium Copyright Act.

I am replying to this post only because Mark asked me to take a look at his video.

I think he will confirm that I predicted all the responses he has received so far pretty much duplicating the responses I received 3 years ago when I tried to share my project.

Mark has done incredible work and has taken a different approach to the same end i.e. controlling the MTH engine with a PC in lieu of a remote. There is no question that this is not for everybody and it is not Mark's nor was it my desire to make it for every one. Me personally I run up to 8 trains simultaneously on a complex layout and I am much quicker getting timely commands out on a properly designed touch screen then the MTH remote but more importantly to me and many of the folks out there who are using my system, is to control train operations with software and sensors with no remote, when I want to but not necessarily always.

I have continued to give people my solution for free on the internet outside of this forum and have several around the country using it happily. The system has much improved and I have simplified the hardware as I  learned more about computers ,data protocols etc. We have accumulated command data files for nearly every function on  the remote and are controlling multiple TIU's and AIU's. My new friend Tom Niemi who has been using my method for over 3 years, controls both DCS and Conventional engines simultaneously through the TIU connected to a PC with my application.

I HAVE NOT RECIEVED ANY THREATING CORRESPONDENCE EVER FROM MTH. As I believe as Professor Chaos that  there are no license or copyright violations.

I am interested in Mark's approach to see if there is any improvement in command response time or lost commands when multiple commands are sent close together. So far this has not been a problem with my method. Mark is a lot sharper than I am on this stuff.

Mark's method requires a good working knowledge of  C++/compiler  and binary data communications management and other Display screen software.

Because I am limited in my knowledge of C++ I chose a user friendly Train Brain software, that is C+ based, to execute my engine commands but also control all the other hardware in my layout which includes multiple Train Brain CTI modules, 2 TIU's and an AIU. The Train Brain software contains all the tools to build descent Screen displays and software subroutines that respond either to a time clock/elapse time or various types of sensors.

I hope you all will treat Mark with the respect he deserves for sharing  his project with the forum while having no commercial expectations. Even if computers are not your thing it may be for someone else.

Professor Chaos I would like to thank you for turning me toward the Arduino ! I have become addicted to programming them and using them all over my layout. I buy the Arduino Nano's and combine them with stepper motors, LED's and all kinds of gadgets that I can construct for my layout combined with my 3D printer. Its been a lot of fun !

My latest completed project is a coal car with a RFID reader, Arduino Nano and a XBEE transmitter contained inside the car that reads RFID credit card type tags under the road beds of the track and transmits its ID and its position to my PC as it moves around the layout. With one of these cars/Dummy Engines behind the lead engine on each of my trains should bring me a step closer to autonomous operations.

Mike Hewett

A few things

Looks to me everyone is supportive of the cause even though a few have brought up that there were Others doing similar things. 

Second, just because you haven't gotten a letter from MTH doesn't mean they are not keeping and eye on the project and if it's offered to others. It has happened in the past to a member of this forum. I imagine as long as it's a personal project they'll leave you alone. 

Personally I think it looks pretty dang cool. While certainly not for everyone as you pointed out. 

General guidelines about copyright are you can pretty much do whatever you want for your own use. It's when you try to market it that you get in trouble. You can (and several have) retrieve all the DCS codes and do some programming yourself. You could  even publish a paper with the codes and discuss how they are used.  But when you try to sell "Bob's Train House DCS Controller" you are probably going to have an issue.

So far the only person known to have legal rights to market a DCS third party product is Hikel O Gauge, however even the status of that project is unknown at this time.

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

Thank you! Great work. I wish I knew how to do this stuff to help.

Mark,

Thank you for sharing!  You have something very cool there!  

Mike has done some great things in the past for a customer of mine who is unable to run trains with a remote due to physical limitations so there is definitely a need for this.

Sorry about all of the internet lawyers posting here.

Great job!

Dave

Excellent job, obviously the result of considerable effort.

David:  The so-called "internet lawyers" should not be criticized.  They are understandably protective of a fellow forumite.  I read his posts as indicating he is fully aware of restrictions.

I have seen much mention on the forum on Arduino.  Is there any good and understandable basic material, an Arduino 101 if you will, to explain basic concepts.

Not to hijack the thread I'll keep this short.  I've found this series by Jeremy Blum the most clear, and well done of the many available on YouTube.  the series starts with explaining what it is, and goes on from there with little projects that show many of the built in functions that make this a wonderfully simple solution for many projects.  

The Arduino forums are also very useful and folks there can usually help with any level of question.  

Also to note the Uno which is the board often used in examples is about 2.5x3.5 inches.  Other, smaller boards offer similar functionality, but have fewer GPIO pins.  

Marty,

Your quote 'legally correct or not' pretty much justifies my comment.

Nuff sed.

Dave

Dave

My quote "Whether legally correct or not." pertained to the MTH and their letters of cease and desist, not the folks here just sharing the experiences of the past.

But you're right, most of us are not lawyers but are willing to help out.  So even if anyone here that suggested he might have an issue gives him a little insight to protect his work them maybe we accomplished the goal of "helping".

Internet Armchair Lawyer Out.  I need to get up to your place again soon.  Been too long.

Right now, you still need the Remote to change the engine number off of "factory reset" to a DCS number, so you still have to do an Add Engine from the Remote.

Once the engine has a valid DCS engine number, my program can detect it. The program can only connect to one TIU right now over one serial port. Runs only on a Windows PC.

I've been interested in controlling the TIU via a PC mainly to automate my layout.  For instance, entering and leaving a switchback.  It's annoying to use the remote for this all the time.  Another is automatically sending the watchdog signal when a siding is powered up (i.e. Andrino or something throws a relay to apply power, and then commands the TIU to send the watchdog).

It would nice to have the ability to ask the TIU to send the watchdog signal but I've not found a command to do that. I've always thought that the watchdog signal came out of the power on sequence of the TIU.

The WD is generated whenever an individual channel initially gets input power.

How long does power have to be off before WD will result from tuning on power to that channel again.  If less than the time it takes a PS2 or PS3 to shut down, that might be an answer.

Interesting question, I don't actually have the answer to that one.  I'm guessing it'll happen pretty quickly, but that's just a guess.

John & Robert,

The WD is generated whenever an individual channel initially gets input power.

Not exactly.

The watchdog signal is sent for 5 seconds whenever voltage changes from 0 to any other value at the output a TIU channel.

How long does power have to be off before WD will result from tuning on power to that channel again

There is no perceptible delay time.

You're right Barry, I forgot passive mode.

I've added some extensions to my RTC program for conventional operation and for LashUps. Look on my web page for three new videos:

http://www.silogic.com/trains/RTC_Running.html

In the emails that I received about the program, several people asked about conventional operation. I hadn't considered that at first but it was not too hard to add.

What was a little harder was LashUps. As I dug into this, I saw that 90% of the intelligence about LashUps was in the TIU. When my program sends commands to the TIU, it only has to send the command and the engines in the LashUp. The TIU figures out which commands go to which engine and which commands have to get modified before they are sent (like for reverse running engines). I was impressed with what the TIU does.

Most of the work in the PC is managing the list of engines in the LashUp.

If your screen is big enough, the RTC program can display operation windows for 99 engines, two variable channels, and 20 LashUps at the same time.

I received an email from a person in the JMRI group. They were interested in incorporating the protocol in their train control program.

I'm preparing the RTC program for beta testing and I've written up a description of the protocol. So far, I've sent the program and protocol description to one person.

My intention is to release both pieces under the Free Software Foundation GPLv3.

To say it 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.

Mark

Very nice work. Answering a lot of questions I had initially about how it would handle things.

 I'm wondering about the soundsets in each engine being different and having their own soft keys that can be moved in the remote. I see there's a button marked cab chatter. I'm guessing that's to turn it on or off?

 How do you access the individual softkey sounds or functions?

( I do see ones for ditch lights for example, but some have softkeys and control function duplicated).

Do they stay the same for each engine?

 I would like to run this program someday. I'm thinking an advanced program that could monitor the layout and automatically run things would be great!

So I'm curious.  Has anyone tried using a double pole single throw switch such that the common is connected to the transformer, the other poles connect to TIU hot input 2 and 3, and the TIU 2 and 3 hot outputs are connected together, and then to the track?  Except for voltage spikes when toggling the switch (perhaps a TVS would stop that?), it should generate the watchdog whenever the switch is toggled.  Any running engines should continue running since the power isn't really interrupted.

I just reread Barry's comment above again.  So instead of having the DPST switch on the TIU inputs, have it on the outputs.  Anyone try that?

Eric

Joe,

Since I can monitor the softkeys from the remote, I can capture and decode the commands for them. So I need to have an engine with ditch lights, for example, to determine the commands for ditch lights. I have found so far, that each softkey function has a different command. Might not be true overall, though.

The Cab Chatter switch sends the command sent by the Menu->Sound->CabChatter selection in the remote.

I am looking for a few "alpha" testers for my RTC program. I think the program is fairly stable and I need to find out if it works on other computers. I developed RTC on Windows XP. I've run it quite a bit on Windows 7. I've started it on Windows 10 (technical preview version) but have not actually connected that computer to a TIU.

For "alpha" testers, I need people who are fearless and can figure things out. People who can work in a environment of no documentation (the videos on my web page are it) and very little support. The program may be buggy. Your layout should have an emergency power off button (I use a Christmas Tree keychain remote control box). I can 't be responsible for anything that happens on your layout or your electronics. I will ask to you affirm that you won't distribute RTC to anyone else during this "alpha" testing. That said, I have run the program a lot and it seems like it works.

Several of you have offered to test the program. I'm putting out this request so that if you do want to volunteer, you know what you will be up against.

The PC to TIU interface is described on my web page:

http://www.silogic.com/trains/RTC_Running.html

You will need some skills at wiring and assembly to build up the interface.

Mark

sent email

E-mail Sent.

Mark,

I am very interested in you findings about the Remote to TIU Protocol.

What happens with Multiple TIUs and Multiple Remotes?

How do the TIU address numbers play into the protocol?

What is different between super mode and normal mode?