Skip to main content

This post will describe how to build a simple interface between the Lionel LCS system and the MTH TIU. With the impending demise of the MTH DCS remote, I thought there might be interest in running PS2 or PS3 trains with the Lionel Legacy remote.

To cut to the chase, I haven't developed a full system for running DCS with the CAB-2 and don't plan to do so. What I've created is the necessary hardware, and provided a basic software framework for reading Legacy commands from the PDI bus and sending a corresponding command to the TIU. My hope is that this project will enable other people who are interested to pick up where I've left off, and further develop the software side!



This project was an offshoot of my DIY TMCC remote control, which used an RFM69 radio module to transmit commands received over the Lionel LCS bus to control operating cars. @SanDiegoMark has done amazing work reverse-engineering the radio communication between the DCS remote and the TIU and showing how to write your own software to control DCS engines. When Mark extended his system to use the RFM69 radio module, I decided to build a bridge module that would read Legacy commands from the CAB-2 and control a DCS engine based on that input.

While it’s possible to read commands from the TMCC or Legacy base serial port, doing so may require additional hardware such as a SER2 module. Moreover, because the TMCC and Legacy command bases use earth ground as the reference for the serial bus, a separate power supply or optical isolation is necessary to avoid shorting layout common to earth ground (which may interfere with the TMCC signal). Instead, this system plugs into the Lionel LCS PDI bus, and is powered directly from the 12v line on the PDI bus. The total cost of the interface hardware is about $30, including the custom PCB.

Basic Hardware:

Mark had demonstrated communication with the TIU using an Adafruit Feather, which combines an Atmega 32U4 and an RFM69HCW radio module. I used a Moteino Mega, which is a similar module with an Atmega 1284p. The Moteino is easier to power with an external supply, and had the pins I needed for serial communication available.

There are two versions of the Mega: one with a built-in USB converter for the first Serial port, and one without, which requires an FTDI-type USB to serial converter to program the module. Either will work for this application, but be sure to get the version with the RFM69HCW – 868/915 Mhz tranceiver. Instructions on installing the Moteino board files in your Arduino IDE are here; you do not need to install the Moteino libraries. NOTE: If you are using the non-USB version, DO NOT connect your FTDI adapter while the module is powered from the LCS bus – you will feed 12v into your adapter and USB port!

There are two jumpers on the back of the Mega that allow connections between the RFM69HCW and Moteino that are not enabled by default: one between D3 and the RFM69’s reset, and another between D21 and DIO2 on the RFM69. Both of these jumpers should be bridged with solder as shown below:
IMG_2148

Connection to Legacy LCS

The PDI bus uses RS-232 at 115200 baud to transmit commands between the Legacy base and LCS modules. This presented a problem, because Mark’s original implementation used the Arduino SoftwareSerial library at 9600 baud to communicate with the RFM69. The SoftwareSerial library blocks while outputting to the serial port, and at 9600 baud it may block long enough to miss characters coming in from the PDI bus on the hardware port Serial1. (The RFM69 uses inverted signaling to transmit and receive data on DIO2, so we either have to use a software serial port that supports inverted signaling, or implement a hardware inverter).

I used the AltSoftSerial library instead, which provides non-blocking write operations using the Arudino’s timer interrupts. However, AltSoftSerial doesn’t support inverted signaling, so I modified the library to provide an option for inverted signaling like SoftwareSerial. (“InvAltSoftSerial”). The library transmits and receives on pins 13 and 14, which are the output compare and input capture pins for the 1284’s 16-bit timer. Since the RFM69 transmits and receives serial data on the same pin (DIO2), I tied pins 13 and 14 together and connected them to DIO2 via Moteino D21 with a 100 ohm resistor (to limit current in case the RFM69 and 1284 ever try to drive the line in opposite directions).

Connecting to the Lionel LCS is simple: the RS-232 signal from the PDI bus is fed into an ADM3202 chip (which is equivalent to a MAX3232). The ADM3202 converts the RS-232 signals to TTL 3.3v signals that are read by the 1284’s second hardware serial port (Serial1).

PDI_Mega

I created a simple PCB that can be plugged on top of the Moteino Mega with female headers.  A JST header is provided to plug in the PDI cable from the Legacy LCS bus. This version uses 1206 surface-mount capacitors and resistors, but I designed a version that uses through-hole components as well:

IMG_2140

IMG_2145

Software

The Legacy Command Base will echo any TMCC or Legacy commands it receives from the CAB-2 onto the LCS PDI bus.  The Moteino reads the packets coming in on the PDI bus, and parses any TMCC or Legacy 3-byte commands coming from the Command Base. (Legacy also has more “multi-word” commands used for more complex lighting and dialog effects, but the current version of the software doesn’t attempt to parse them.)

The demonstration sketch shows two simple uses of the CAB-2 to control a DCS engine: controlling the speed of an engine, and opening the front and rear couplers. Those are simple conversions of Legacy commands to their DCS equivalents.

Providing full control of DCS engines with the Legacy remote will require mapping many more Legacy commands to a corresponding DCS command sequence – and some of them, like sound commands, do not have a simple DCS equivalent. That project is not something I have the appetite to take on, so my hope that other people will be inspired to take the system further!

If you are interested, the attached ZIP file contains a schematic and Gerber files for the PCB, the demonstration sketch, and the InvAltSoftSerial and other libraries used by the sketch.

Attachments

Images (4)
  • IMG_2140
  • IMG_2145
  • IMG_2148
  • PDI_Mega
Files (1)
Last edited by Professor Chaos
Original Post

Replies sorted oldest to newest

Great project.  Lots of ideas posted here about interfacing existing TIU's or alternatives to remotes for TIU's, etc

I wish someone would try and figure out a solution to the biggest problem with DCS (given all the people buying up MTH).  No TIU's available anymore. If you don't already have one you are out of luck (or pay some of the cretins on Ebay a premium for a potentially defective used one)

Has anyone ever tried to come up with an alternative to the TIU itself?  DCS Explorer has limitations particularly with available sounds.

John

Last edited by Craftech

So how does the Legacy side know when it is supposed to issue the DCS remote commands?

I suppose one could add a placeholder engine to the Legacy remote on a specific address.  Then the "bridge" would need to be programmed to listen for commands on that address.

Each DCS engine would need a corresponding "slot" on the Legacy remote, with each programmed into the bridge.  This would obviously reduce the number of Legacy engines you could run - just like running TMCC engines via the DCS remote/app does.

If one has the DCS remote commands and a means to tx/rx with the TIU I can see doing this from software since the software "knows" there is a different engine control type and is controlling the interactions.

The DCS remote also "knows" there are two types of engine controls and it is communicating with each type, assuming the Legacy base is connected, etc.

I doubt the Legacy remote knows about anything that is not Lionel. Is it possible to hack the Legacy remote, or this idea to just try to broadcast DCS remote commands for each Legacy command that can be translated?

I doubt the Legacy remote knows about anything that is not Lionel. Is it possible to hack the Legacy remote, or this idea to just try to broadcast DCS remote commands for each Legacy command that can be translated?

That's correct. The Legacy remote just assumes it's controlling a Legacy engine, and the bridge just broadcasts DCS commands.

Unlike TMCC/Legacy, which lets you broadcast a command to anything you want, DCS is restricted to those engines registered in the system. I think you would still need to add the engine using the DCS  smartphone app (or remote) before controlling it with the Legacy remote. (Unless Mark figures out how to reproduce that functionality as well!).

The demo program just broadcasts a DCS command when it receives a Legacy engine command, using the same engine ID. Since the bridge can respond to any Legacy command, it would be possible to use defined Legacy commands to "add" an engine to the bridge, such that the bridge module would only send DCS commands for those engines added to the bridge. The bridge could keep a persistent list of those engines in EEPROM.

Again, not a project I have the appetite to undertake - but the tools are there for someone who does!

@carl552 posted:

The next important step is to be able to send DCS commands from JMRI or Train Controller.  DCS's future will be limited if its commands are not made open for this type of innovations.

I actually built an Arduino-based system to communicate with JMRI;  the Arduino pretends to be one or more C/MRI nodes. Although C/MRI is set up to provide control of turnouts and the like, part of the system I developed allowed JMRI to send arbitrary text strings (generated by scripts) to the Arduino.

Not the most elegant solution, but if you build the DCS command strings on the JMRI end, then it's easy to pass those strings to the TIU. That is essentially what SanDiegoMark's RTCModem program does.

Or you could have JMRI communicate the commands in some other format to the Moteino, and the Moteino could build and transmit the DCS command strings like this demo program does.

From my limited experience with the DCS remote and from what I've read regarding the app/WIU I understand the database is not kept on the TIU but rather the remote or app. At least the remote has nvram to store states between sessions, the app must read the environment each time and the user must prompt this action.

I think the remote solution needs a lot more smarts (software) than we realize and I understand why you wouldn't wish to get into it.

From my limited experience with the DCS remote and from what I've read regarding the app/WIU I understand the database is not kept on the TIU but rather the remote or app. At least the remote has nvram to store states between sessions, the app must read the environment each time and the user must prompt this action.

How does the user prompt this action on the app?  When I load the app, it remembers all my locomotives just like the TIU.

I thought I had read recently that the app with the new WIU would come up with everything inactive until this refresh was done. The DCS remote seems to do something like this on its own when it connects to the TIU.

I really only brought this up to point out even the DCS remote and app seem to behave somewhat differently. I don't know exactly how differently.

rplst8,

I am not completely sure of the context of what I read, I'll see if I can find it. I do remember noting in my mind at the time that this seemed to be different from a app/wifi unit/tiu and the new all in one WTIU, I guess its called. I only have a remote and TIU but I try keep my ears open to how things are progressing without the remote.

Last edited by turkey_hollow_rr

Thank you for the very kind words to all above! @Dennis-LaRock you literally just made my day, thanks and it means a lot to me.

@turkey_hollow_rr thanks, you certainly hit the nail on the head, all the possibilities of things that could be done are what got me into this hobby in the first place (aside from childhood memories). I love adding new functionality to existing things like that. And when I hear that something can't be done I love to turn it into a personal challenge to make it happen.

@RickO thanks for sharing my video and letting me know about these new efforts, awesome to see another member working for the same mission with a different approach.

@Professor Chaos you have quite a talent for embedded hardware work and it's awesome to see you tackle this via the PDI bus directly, that was on my short list of things to get into considering I have the documentation as an LCS partner myself it's just been a matter of getting the right push forward.

My current efforts have actually been to work on a project enabling a totally blind train operator on the form here to have a much more accessible interface to the legacy functionality. Along with that I want to provide audio cues via windows narrator about the positions of trains using a combination of IR sensor tracks and my homemade recreation of the IR transmitter to retrofit other trains and cars with IR capability for position feedback on the track. The only way Lionel wants to enable position reading is via the LCS Wi-Fi adapter, but that adds a level of complication and a failure point that I want to avoid. Even using Lionel zone monitor program I find frequent disconnections over the Wi-Fi network. direct connection Wi-Fi is more reliable but a bigger hassle for the user. Your efforts on the PDI bus interface certainly give me all the push I need to make massive progress with this effort now.

As for the DCS remote system it sounds like I should get to work on trying to reverse engineer the process of adding new locomotives without a DCS Wi-Fi or DCS remote. If you take a look at my video demo of using the cab2 to control LionChief: https://youtu.be/4Ujb8xEGKEk you will see I have mapped almost all of the cab2 TMCC buttons, that can certainly be mapped to the functions made available by Mark's RF code. But something I need to build up some additional mental fortitude for is reverse engineering DCS functions beyond what Mark's software currently has implemented. For example mapping the RPM functions, additional sound effects, or the ability to add and delete locomotives from the TIU. All I need now is more spare time.

Regards, Ryan

Without the ability to address individual engines from the remote I don't see how this would get to running MTH trains. That implies a whole 'nother realm of control. Is there a plan for how to move from broadcasting to one-to-one communication using the remote? I can see a raspberry pi project, but not how it would extend to a remote interface.

Without the ability to address individual engines from the remote I don't see how this would get to running MTH trains. That implies a whole 'nother realm of control. Is there a plan for how to move from broadcasting to one-to-one communication using the remote? I can see a raspberry pi project, but not how it would extend to a remote interface.

If the data on the PDI bus includes the engine or train number in the data, the bridge could be programmed to only respond to certain addresses that are reserved for DCS locomotives.

Sure, and a cpld could be added and programmed to mimic all DCS remote functions, assuming all of that can be sniffed and sorted out. There is still the issue of how a user would use the Legacy remote to address those engines not controlled by Legacy. What would be the user interface to the MTH information?

I think TMCC engines have to be added to the Legacy remote manually, correct?  In addition, there is no "confirmation" that the engine exists on the track in the TMCC world.  It's unidirectional. 

I would think the process would be:

1) Allocate a set of TMCC/Legacy ID numbers for DCS locomotives
2) Enter the information for the DCS locomotive (or add it) to the "Legacy-DCS bridge" device (TBD) and assign it to a TMCC ID
3) Add the "placeholder" TMCC/Legacy "engine" to the Legacy Remote with the same TMCC ID used in step 2
4) Operate the locomotive by selecting the reserved placeholder ID on the Legacy Remote
   a) commands get broadcast to PDI
   b) bridge device reads commands, when it sees one with an ID that it has mapped in step 2, it translates and relays the commands in DCS to the TIU

Obviously, we'll need that software piece to add the engines and TMCC mappings to the the bridge - and I think that's part of the software work that @Professor Chaos was suggesting others could continue with.  Definitely work to be done in the decoding and translating of the full command set for both TMCC/Legacy and DCS - mapping them, etc. etc.  But this is a logical design that based on the work that has been done so far seems very feasible. I'm not familiar with the worth @Ryaninspiron has done, but he may have some of these pieces already completed or started.

Ryan overall the Legacy DCS programming side is outside of my wheel house, but it's something I'm definitely interested in following here. I can answer a couple questions you raised.  Please see inside quote box and below it.

@rplst8 posted:

I think TMCC engines have to be added to the Legacy remote manually, correct?  Yes, but once entered, their information is stored in the Legacy base's memory and can also be saved to a Legacy memory module.  In addition, there is no "confirmation" that the engine exists on the track in the TMCC world.  It's unidirectional.  Yes the 455kHz legacy signal is one way, from the Base to the Locos, etc.

I would think the process would be...

I'm not familiar with the worth @Ryaninspiron has done, but he may have some of these pieces already completed or started.

Here are links to @Ryaninspiron 's work with Lionchief and Legacy:

LionChief Bluetooth Gateway Project (Updated 2-8-20)

Legacy Cab-2 finally running LionChief Trains

@rplst8 posted:

I think TMCC engines have to be added to the Legacy remote manually, correct?  In addition, there is no "confirmation" that the engine exists on the track in the TMCC world.  It's unidirectional.

Technically,  as long as the engine has been programmed with an I.D.#

I believe you can simply address any TMCC locomotive and operate it ( and probably Legacy for that matter) albiet in TMCC mode in either case.

Loading the Legacy info gets you the legacy speed steps and other goodies, but Legacy engines will operating under basic TMCC without loading.

I'm not sure how this effects any of the techno jargon you guys are discussing, wayyyy over my head LOL! Just thought I'd add this comment from an "electronics dummy".

I'll just wait patiently for a mass produced bridge once you guys iron everything out

Could whoever decides to take this on not shave off a great deal of time and effort and try your scheme with DCC? I'm suggesting this on the assumption that the DCC commands are already known, sorry if that isn't the case.

There is potential there to save some time.  However, only ProtoSound 3.0 locomotives have DCC compatibility.  Additionally, I think the work that Professor Chaos has done has been to rebroadcast the commands on the 900 MHz band.  To communicate with DCC, some interface to a DCC controller would need to be made or transmit DCC commands directly onto the rails.  All possible, just different paths.

@cbojanower posted:

From what I remember he said they got it to work in Dr. ZW's lab, but figured it wasn't worth the litigation to pursue it.

Litigation?  For what - converting bytes from one thing to another?  AFAIK all the DCS patents should have expired by now, and I'm sure Lionel would welcome an ability to run MTH locos with their remote - not having spent a dime on R&D.  Legacy remotes will be flying off the shelves.

Add Reply

Post
The DCS Forum is sponsored by
OGR Publishing, Inc., 1310 Eastside Centre Ct, Suite 6, Mountain Home, AR 72653
330-757-3020

www.ogaugerr.com
×
×
×
×
Link copied to your clipboard.
×
×