Mark DiVecchio's O-Gauge Train Layouts

1992 Layout Page

2006 Layout Page

2009 Layout Page

P&LE Postcards by Howard Fogg 

Plasticville Buildings

Portable Layout Page

Train Clubs

Bing Track

Remote Train Control (RTC) Program 

YouTube Channel

Technical Videos

3D Prints for my Layout

ADPCM - Playing clips from .mth sound files

P&LE McKees Rocks Locomotive Shop
3D Printer Project

White Tower Restaurant
3D Printer Project

RFID Train Detection

Engine and Car Operation
Hints and Tricks

RTC Control Language - Scripting

OOK Radio Support for RTC

This Page last updated on .

As I mentioned in the posts on the forum, I am releasing these programs and documentation under the  GNU GENERAL PUBLIC LICENSE Version 3 and GNU Free Documentation License Version 1.3. These licenses permit anyone to use the program and the documentation to produce follow on programs as long as those programs remain covered by the GNU licenses.

The Free Software Foundation web page talks about what "free software" means.

For more information, look on the Open Source Initiative web site which includes a description of what Open Source means and their certification of the GPL version 3.

Here is the copyright notice for those two licenses:


Remote Train Control Program for Windows
© Copyright 2015 by Mark DiVecchio

Remote Train Control is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

Remote Train Control is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with Remote Train Control.  If not, see <>.


This is part of the Remote Train Control Manual.
© Copyright 2015 by Mark DiVecchio

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts and no Back-Cover Texts. You should have received a copy of the GNU Free Documentation License along with Remote Train Control. If not, see <>.

PC Control of MTH Engines by Radio Connection to the TIU


I've been working on understanding the interface between the Remote and TIU for several years. I started with the work done by Mike Hewett  <> in about 2011. He investigated the wired connection (using a phone handset cord) between the two. He figured out a lot of the interface. It was RS-232 (using 0v and 3.3v levels). It was 9600 baud, 8 data bits, no parity, 1 stop bit. He could see command packets going between the Remote the TIU. He wrote software to capture those packets, store them on a PC and send them to the TIU on request.

I took the work that Mike did and expanded on it. I developed a better understanding of the command packet from the Remote and the response packet from the TIU. I put all that I learned into a program called Remote Train Control.

I was still using a wired connection between the PC and the TIU. I thought that I could figure out how the radio connection worked.

Searches on Google developed a few leads:

1. Frequency requests to the FCC for Hand Held RF module and for Base RF module:

This showed that the Remote transmitted on  916.5 MHz and the TIU transmitted on 905.8 MHz

2. This I found this post on an SDR web site:

SDR-noob needs help. Want to decode 9600bps OOK signal at 905.8MHz.

submitted 17 Nov 2014 by playaspec

Hi all. I've been trying to reverse engineer the protocol used by a toy train with little luck. Through a great deal of digging through Google, I've discovered that the remote and the base communicate at 905.8MHz, using OOK at 9600bps. I would like to snoop this protocol to bring the train under computer control. Can anyone lend a hand?

The radio chip in the receiver (and I assume the transmitter) is a TI TRF6901

He never got any responses, except from me, and could not add to his comment at the time. I don't know if he ever got to a solution because I never heard from him again. But at least, if he was right, I could search for OOK and the TRF6901.

3. I needed to find out if anyone sold a radio board using the TRF6901. Searching the Internet turned up nothing.

4. On the TI web page, the TRF6901 was listed as "NRND" - TI speak for "Not Recommended for New Designs". I downloaded the data sheet and saw that the chip supported FSK (Frequency Shift Keying) and OOK (On-Off Keying). So the Remote and TIU probably spoke either FSK or OOK. I found this article: "I'm OOK, You're OOK?" from Maxim. Another big hint was the comment on the TI TRF6901 web page that stated:  "Replaced by CC1101".

I learned that OOK, which stands for "On-Off Keying" is a simple bit serial protocol where the transmitter is just turned on and off based on the "1" or "0" value of the bit being transmitted. Kind of like Morse Code or what we hams call "CW" - Continuous Wave - transmission.

5. Since the TRF6901 was obsolete, maybe the CC1101 could be used. The data sheet said that it could do OOK. It was worth investigating.

6. Now did anyone make a board using the CC1101?  I found Erwan's Blog which talks about connecting a CC1101 to a 3.3v Arduino variant called the Infiduino. He used a board from Elechouse which contains the CC1101. 

9. The Infiduino is programmed using the standard Arduino IDE.

10. 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 Atmega328p MCU finally led me to a working receiver. Then a working transmitter. I called my 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.)

11. To program the CC1101, I took the code examples written by Elechouse and added routines to implement OOK.

12. The protocol over the radio is just like the RS-232 TTL level wired connection. You might think of it as inverted, though. When the RS-232 signal is a '1' or "Marking", the transmitter is off. In RS-232-land, this is the idle state. With a radio, we want the transmitter to be off when the connection is idle. This lets other remotes transmit and control the TIU. It also saves our battery power. When the RS-232 signal is a '0' or "Spacing", the transmitter is on.

13. I found that both the Remote and the TIU require what I call a "wakeup" signal be transmitted to them before data is transmitted. I'm guessing that the receiver circuit needs a carrier signal for some amount of time in order for it to lock onto the incoming signal. I found by experimentation that a carrier on signal of about 2000 microseconds followed by a carrier off signal of about 600 microseconds worked. Following this wakeup pulse, the next carrier on is the START bit of the first character of the packet of data. If you look at the code, you can see where I do this. Look at this link (on this page) for more that I've learned about this wakeup pulse.

For details on the previous steps look at this document.

Here are two articles that I wrote about RTC. They give simple operating instructions and might be of use. The articles were originally published in the TTOS Southern Pacific Division newsletter "Daylighter" in March 2016:

Article with screen shots and startup instructions
Article with more technical description of the program's operation

You can also access these videos on my YouTube Channel.

Radio based interface between the PC and TIU

My original work was done with a radio that is no longer available. That radio consisted of of an Arduino-like processor using the ATMega328 along with a TI CC1101 radio chip.  Its programmed using the Arduino IDE.

  Jan 2019 - The original radio that I used is no longer available. Look at the solution using the Infiduino or Seeeduino (3.3v Arduino variants) and the ElecHouse CC1101 radio.

One thing the I will point out over and over (because I messed up here) is that the TI CC1101 is a 3.3v part and can only connect to 3.3v circuitry. A plain Arduino is a 5v part and will NOT directly connect with the TI CC1101 (safely). In the examples below, I used an Infiduino which can be switched to operate at 3.3v. And I show an example of a Seeeduino also switched to operate at 3.3v.

Retro Transformer

This is my first project using the original radio. Recorded 21 Sep 2015. Its only an example of what could be done. I built it in a cardboard shipping box. Inside are the radio, 2 AA batteries for power, a few switches, pushbuttons and an old joystick (really just a fancy potentiometer). When you are not transmitting, the board draws about 3ma. Great for battery operation.

  Jan 2019 - The original radio that I used is no longer available. Look at the solution using the Infiduino or Seeeduino (3.3v Arduino variants) and the ElecHouse CC1101 radio.

Take a look:

Image loading....

First Project - a Retro Transformer

This box performs just a sub-set of the functions performed by the remote. It is hardcoded to control one engine and communicate with one TIU. But I could see a controller built with large buttons, something really kid friendly. Or how about a track activation device that sounds the whistle/horn automatically when the engine approaches a grade crossing. Maybe even an automatic speed control as the engine is approaching a station. It can be extended to control accessories and switches. Mike Hewett has developed a scheme with which he can identify the position of each engine on the layout. With that, you can develop a system that performs different functions depending on which engine is coming into town. Maybe routes them onto different sidings or to different industries (by commanding the AIU).

You can get the RetroXFMRE (ElectHouse CC1101 version) program here <download ZIP file>.

See below for instructions on how to use the Arduino IDE to compile and download these programs. Each also requires a support library.

Each of these ZIP files contain a circuit schematic of how I connected up the switches, pushbuttons and pot. The schematic is for the original radio but you can translate the pin numbers to match the Infiduino/Seeeduino used in the Elechouse CC1101 version. You need to download the free program KiCad EDA to view these files. Look here:

Below, you can see an implementation of RetroXFMRE by Ray.

Developer's  note: If you are interested in learning how to use the Infiduino/Seeeduino to control your trains, this RetroXFMR is the best place to start. Look at the code to learn how to take a command and add all of the bytes around it to build a packet that can just be sent over the radio. Once you understand this, you can use my routines to build up and send your own commands.

Infiduino with Elechouse CC1101

Earlier in this page, I mentioned Erwan's Blog which talks about connecting a CC1101 to an Arduino. He used a radio board from Elechouse which contains the CC1101 connected using the Arduino's SPI interface.

First let me point out (again!) that the maximum voltage on any pin of the CC1101 is 3.3v. You cannot use a regular Arduino UNO but you have to use one that operates at 3.3v. There are many of these available. I used a version called an Infiduino. It has a switch for either 3.3v or 5v operation. I got it on eBay.

So I thought that I could port my RTCModem program to an Infiduino/Elechouse CC1101 setup. The time I spent learning about the CC1101 in the original radio should be directly useable. It was. The developers of the Elechouse CC1101 had written code for the Arduino to communicate with the CC1101. Since I now understood how all this worked, it was easy to port the code. I added an "E" to the program name to indicate that it is the Elechouse CC1101 port - "RTCModemE".

Click here for a source for the Elechouse 915MHz CC1101 Wireless Module (directly from Elechouse). The page shows this module as "RF1100SE" but the boards that I received are marked "RF1101SE-V3.1". The web page claims that this board is designed specifically for operation in the 915MHz band. As of Jun 2019, it was $18.90 + shipping. Elechouse ships from a US address.

Most of the boards on eBay are V2 and may not work at 915MHz. They appear to be 433 MHz boards but you never know. They are pretty cheap so there is not much to lose if you try them.

I've found two other sources for TI CC1101 radio boards that work with RTC:

Chengdu Ebyte Electronic Technology Co.Ltd has a board E07-915MS10. This eByte board will require some soldering of wires and an antenna (3 inch wire). You can find it by searching eBay. These boards are really cheap, in Jun of 2019, they were $3.70 each + shipping. They come over on a slow boat, my order took almost 5 weeks. See below for the wiring diagram.

This board on eBay is marked "RF1100SE" but like the Elechouse board, I actually received a board  marked "RF1101SE-V3.1". This board looks exactly like the Elechouse board except that it has a small wire antenna instead of the black SMA antenna. You wire it up with the same connections as the Elechouse CC1101 radio (see beow). As of June 2019, it was $8.71 + free shipping. Cost was less if you bought more than one. Worked just fine. Like the shipment from eByte, it took almost five weeks to arrive via "SpeedPAK" from Hong Kong. I get the feeling that this is a knock-off of the Elechouse board.

Here is an eBay search for the CC1101 radio. If the link does not work anymore, use this search "915MHZ wireless module/CC1101 wireless data ".
Here are some other links:

        Search eBay for the Infiduino.

        Search eBay for the jumper cables. These are called Dupont Cables. They are used to interconnect the Infiduino and the ElecHouse CC1101 radio. You will need male to female jumper cables.

        Elechouse page for the CC1101 Radio.

In the spring of 2020, the Infiduino has, for some reason, become very difficult to find. Mike Hewett, one of the RTC users, found a Seeeduino variant manufactured by Seeed. A little further down this page, there are a couple of photos of Mike's implementation.

Here is a photo of my Infiduino jumpered over to an Elechouse CC1101 (using a Screw Shield - but the Screw Shield is not really needed - you can connect the jumpers directly to the Infiduino). I also added a 100uF electrolytic decoupling capacitor arcross the power pins on the CC1101. I don't really know if this is needed or not - seems to work fine with it and without it.

This is solderless solution..... Source for jumpers - .

Here are the pinouts of the Elechouse CC1101 board using the SPI interface. This drawing is linked from Erwan's blog. Note that this is the top view of the boards, the pins themselves actually stick out on the other side of the board. It seems that on these boards, pins 1 & 2 are labeled "VCC" instead of "VDD". VDD is typically 3.3v.

Here is a drawing that shows how to interconnect the two devices. This drawing is linked from Erwan's blog with one modification. My OOK implementation requires one more interconnection than Erwan used, from Infiduino 03 to CC1101 GDO2 / 6.

Here is the wiring for the eByte super cheap CC1101 radio.

Here is the eByte radio connected to an Infiduino

Seeeduino based radio.

Mike Hewett, one of the RTC users, found a Seeeduino variant manufactured by Seeed. It has a switch on it to change the operating voltage to 3.3v.

Here is an eBay search for the CC1101 radio that Mike used. If the link does not work anymore, use this search "915MHZ wireless module/CC1101 wireless data ". It is very important that the radio be advertised as "915MHz". These radios have an antenna system designed for the correct frequency. The radios advertised as "315-433-868-915MHZ" have antennas systems designed for 433MHz and will not work as well in this application. This board on eBay is marked "RF1100SE" but like the Elechouse board, I actually received a board  marked "RF1101SE-V3.1". This board looks exactly like the Elechouse board except that it has a small wire antenna instead of the black SMA antenna. You wire it up with the same connections as the Elechouse CC1101 radio (see beow). As of June 2019, it was $8.71 + free shipping. Cost was less if you bought more than one. Worked just fine. Like the shipment from eByte, it took almost five weeks to arrive via "SpeedPAK" from Hong Kong. I get the feeling that this is a knock-off of the Elechouse board.

Click here for a source for the Elechouse 915MHz CC1101 Wireless Module (directly from Elechouse). The page shows this module as "RF1100SE" but the boards that I received are marked "RF1101SE-V3.1". The web page claims that this board is designed specifically for operation in the 915MHz band. As of Jun 2019, it was $18.90 + shipping. Elechouse ships from a US address. This board is more expensive and possibility higher quality than the knock-off board but both boards seem to work fine.

Mike wrote: "I used double backed adhesive tape and wire wrapped to header pins pushed into the seeeduino board mounted female headers"

Using a 5v Arduino instead of 3.3v Infiduino/Seeeduino

It is possible to use a regular 5v Arduino for this application. The Arduino has a 3.3v voltage regulator on board and that voltage pin can be used to power the radio. The Arduino's input pins can (usually) accept the lower 3.3v signals from the radio (for the MOSI, the GD02 and the GD03 pins). Arduino output pins, though, would be 5v signals and cannot be directly connected to the radio (for the CSN(SS), the SCK, and the MISO pins). These three signals must have their voltage lowered to 3.3v before connecting to the radio.

You can do this two ways that I know of.
There are chips which take in a signal at 5v levels and convert them to 3.3v. Many possibilies available. Look at these web pages for options:
or .
Often called a poor man's level converter, put a 1K-5.2Kohm reisistor in the three signals (the CSN(SS), the SCK, and the MISO pins) from the Arduino to the radio. This resistor will just provide about a 2 volt drop to lower the voltage but still might damage the radio. This is not an ideal solution as the signal waveform will get distorted somewhat. But,well, this is not rocket science.

Compiling the Modem Program

You compile the RTCModemE program using the standard Arduino IDE and the standard Arduino libaries along with my "CC1101E" library as described below.

Install the Arduino IDE. When I wrote this, 1.6.5-r2 was the lastest version.  Get it here:
Make sure that "Arduino AVR Boards Built-In" is installed. I'm using version 1.6.8.

Note: in Aug of 2016, one of my users wrote: "I used Arduino IDE 1.6.8 and AVR Board 1.6.13 (instead of 1.6.8) - For some reason, AVR Board 1.6.8 did not include TimerOne.  I was getting include errors initially looking for TimerOne.h.  I went and downloaded TimerOne from GitHub, but also the switch to 1.6.13 might have helped."

Detailed installation instructions are here:

Make sure that the Arduino AVR Libraries (I'm using version 1.6.8) are loaded.

Newer versions of the IDE and AVR Libraries should work but I've not tried them.

In your Arduino Sketch folder, create a folder named "RTCModemE" and put these two files in it:

You can get my RTCModemE (Elechouse CC1101 version) program here <download ZIP file>.

This library is my implementation of OOK protocol on the Infiduino with the Elechouse CC1101. You can get the my CC1101E_OOK library (Version 1.0.4) here <download ZIP file>. In the zip archive, look for the folder CC1101E. Move that folder and its contents into your Arduino libraries folder - on my Win 7 computer, its a folder named: C:\Users\<user>\Documents\Arduino\libraries.

In your local Arduino Library folder, create a folder named "CC1101E" and put the CC1101E_OOK library files in it.

You might need the USB VCP drivers from the FTDI web site. This is only if the drivers do not load automatically. Get the latest version for Win 7, Win 8 and Win 10. At the time of this writing, that is version (dated 1/27/2014). Get the older, no longer supported, version 2.8.30 (dated 7/12/2013) for Win XP (still works fine). NOTE - this version for XP seems to be gone from the FTDI web site - in its place, get the latest version 2.08.24 dated 4/13/2012.

Install the "Arduino AVR Boards"  support as follows:

1. Start the Arduino IDE.

2. Click on "Tools->Board->Boards Manager" and scroll down the window until you find the "Arduino AVR Boards" entry. Then click on [INSTALL] -- unless its already installed.

3. Click on "Tools->Board" and select the "Arduino Uno" board. NOTE: you can use any Arduino board, does not have to be a Uno.

4. Connect the Arduino to the PC into a USB port. Drivers for the board should install. Note which COM port that it configured as.

5. Select that COM port on the "Tools->Port" menu item.

6. Open the "File->Open" menu and select the RTCModemE.ino file

7. Click on "Sketch->Upload" to complile and upload the code into the Arduino.

8. Start your program, might be RTC or one of Mike's programs. Select the correct COM port. Turn on your TIU, press CONNECT, READ, and then STARTUP and run an engine.

Email me if you have questions or clarifications (or if your setup actually worked!).  email :


1. Requires TimerOne which is installed when the Arduino AVR Boards support is installed.

2. Requires SoftwareSerial which is installed when the Arduino AVR Boards support is installed. SoftwareSerial inverts the data in both directions. Required so that when the serial data is "1", the transmitter is off and when its a "0", the transmitter is on. RS-232 Marking state ("1") is its idle state and we don't want the transmitter on when the channel is idle.

I had to make a few patches to the Software Serial routines as received with the Arduino AVR library. If you download the Board Mangaer files for the "Arduino AVR Boards" boards, you will have to make these patches. They increase the buffer size to insure that the 173 byte packet from the TIU can be received without the possibility of overflow.

Increase the buffer size from 64 bytes to 256 bytes:
#define _SS_MAX_RX_BUFF 256 // RX buffer size    MCD was 64
Change the buffer pointers from 8 bit to 16 bit:
  static volatile uint16_t _receive_buffer_tail;    // MCD was uint8_t
  static volatile uint16_t _receive_buffer_head;

Change the buffer pointer from 8 bit to 16 bit:
volatile uint16_t SoftwareSerial::_receive_buffer_tail = 0;    // MCD was uint8_t
volatile uint16_t SoftwareSerial::_receive_buffer_head = 0;

3. I get these two warning messages when I compile. They don't seem to have any effect on the operation of the sketch.

...\SoftwareSerial.cpp:375:6: warning: always_inline function might not be inlinable [-Wattributes]
 void SoftwareSerial::setRxIntMsk(bool enable)
...\SoftwareSerial.cpp:121:6: warning: always_inline function might not be inlinable [-Wattributes]
 void SoftwareSerial::recv()

Adafruit Feather 32U4 Based Radio

Paul Reynolds, who is working on his own version of radio control, alerted me a radio which I had seen before. Its from Adafruit and is called the "Adafruit Feather 32u4 RFM69HCW Packet Radio - 868 or 915 MHz". Like the other radios that I've used, it is much, much more capable and handles very sophisticated transmission protocols. We only need OOK to talk to the TIU and when I looked up the radio chip used, the SEMTECH SX1231 Low Power Integrated UHF Transciever, the specs said it could handle OOK.

Here is a photo of the radio:

I was able to take the RadioHead library and make it work for me using OOK. So this is another good radio to use for the RTC program. It is nice in that is single board and costs about $25 but it is not a solderless solution.

Because the USB is built into the Feather 32U4, instead of an external chip as on a regular Arduino, it requires that DTR be high otherwise the Feather will never send anything to the PC. The Arduino IDE does this automatically if you use the builtin terminal. If you use a standalone terminal, you will have to set it to turn on DTR. I had to modify the RTC program with a new setup option [x] DTR Always on - added in version 4.3.2 of RTC. You must set this before connecting to the TIU. The setting is remembered so you only need to set it once.

Then as you can see in the photo above, a jumper is required on the Feather. Solder a jumper between pin 2 of the radio to pin D9 of 32U4. Please do a better job of soldering than I did :-(.

I also soldered on a spring antenna that I bought along with the radio from Adafruit. You can also use a simple 3 inch piece of wire.

Here are the sketches I have so far and the modified library. I've not used these for any long term testing so you might find a bug or two. If you do, let me know and I will (hopefully) fix them.

RTCModemF_v1.0.1 - Connects the RTC program to the TIU. Includes the "hex" file which can be uploaded into the Feather using the XLoader program (see just below).
RTCSnoopF_v1.0.0 - Monitors radio communications between the Remote/RTC and the TIU. Displays the packets heard on the air. Includes the "hex" file which can be uploaded into the Feather using the XLoader program (see just below).
RadioHead_OOK - The RadioHead library modified to support OOK protocol. You will need this if you want to recompile the Feather sketches.

ATMEGA1284P based Radio - Moteino + RFM69HCW

Jeff Lefstin saw the work that I did with the Adafruit Feather 32U4 and RFM69HCW radio. He took my port of RTCModem to that board and ported it to a Moteino Mega. The Moteino combines an ATMEGA 1284P with the RFM69HCW radio. He developed a interface between the Lionel Legacy remote and the MTH TIU. That is - being able to control DCS engines with the Legacy remote.  Here is what he wrote (also appears on this OGR Forum posting):

With the impending demise of the MTH DCS remote, I wanted to explore the possibility of controlling PS2 and PS3 trains with the Lionel Legacy remote.

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, which provides a 12v power line.

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:

Connection to the 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 PSI 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).

I created a basic 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:


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.

So this concept still needs a lot of work. Mostly mapping the Legacy commands to the DCS commands.

XLoader - Uploading code images to the Infiduino without having to install the IDE and compile the code

Here is a way to upload a precompiled binary image of these programs without having to load the Arduino IDE and compiling the code. The precompiled code is available below for the Infiduino/Elechouse CC1101.

This procedure is based on Xloader by Geir Lunde:
Copyright (c) 2012, Geir Lunde
All rights reserved.

I have updated Geir's software with programs and files compiled with v1.6.5 of the Arduino IDE. The zip file contains a program which will load a hex file into an Arduino based board. Make a folder (maybe called XLoader) and extract all of the files in the ZIP into that folder.

The ZIP file below conatins the XLoader program and all of the *.hex files.

To run click on XLoader.exe

Choose the Hex file to load.
Choose the Device.
Choose the COM port.

The Baud rate will be set automatically.

Click on "Upload".


My RTC files included were the latest versions of the programs at the time. The compliled output files are named <program>.cpp.hex

Remember than any system that uses the Elechouse CC1101 radio requires an Arduino implementation that operates at 3.3V (such as the Infiduino or Seeeduino).

RTCModemE - provides radio communications between the PC and the TIU for the Remote Train Control (RTC) program as described earlier on this page. The receiver bandwidth is set to 162.5 kHz. This bandwidth has worked for me using Rev I, Rev I3A and Rev L TIU.

RTCModemF - Adafruit Feather 32U4 version of RTCModemE.

RetroXFMRE - My simple implementation of a toy train transformer as described earlier on this page.

RTCEngineE - A program which emulates an Engine connected to a TIU. It outputs the commands it receives and responses that it sends to the Arduino IDE Serial Monitor Port. Look at Technical Video 7 at

RTCSnoopE - A program which monitors the radio communcations between the Remote and TIU and logs the packets to PC using the Arduino IDE Serial Monitor (or any terminal emulator). To decode these packets copy/paste them into RTC's TIU buffer using RTC's debug mode. Then from the TIU Buffer's context menu, click on "Decode Strings in TIU Buffer". This will put the decoded strings into the CRC Buffer. You can copy and paste or save them from there.

You can leave comments in the logged packets to reminder of what button you just pushed. In the serial monitor just type a note to yourself and press [Send]. A note could be something like "Press the Startup button".

If you use the XLoader downloaded version, you can use any terminal emulator to capture the packets. I've used Termite: with success. Set the baud rate to 57600.

RTCSnoopF - Adafruit Feather 32U4 version of RTCSnoopE.

TwoEngineE - A program which runs two engines around and around on your layout. Requires a Sharp GP2Y0A21YK infrared (IR) detector, a pushbutton and an LED. Written only for an Infiduino and an Elechouse CC1101 radio. Requires DistanceGP2Y0A21YK.h and TimerOne.h. Look at Technical Video 6 at


    Model railroad fast clock master and slave. Requires TM1637.h,  TimerOne.h and EEPROM.h. Hardware requirements spelled out in the source code file.


You can download the XLoader program and compiled binary versions of my programs <download ZIP file>. There have been some comments that the XLoader.exe program in the ZIP file has a virus but I checked it with Malwarebytes and found none. I have run it on my computer with no apparent problem. Requires dotNET v4.0.30319 (at least on WinXP). On my Win7 computer, I have dotNET version 4.6.1. Win10 includes dotNET 4.6.1 automatically.

You can download the source code for all of these programs here <download ZIP file>.

Mar 2016 Demo of RTC at the TTOS SP Meet in Anaheim, CA

Here is a video taken at the March 2016 meet of the Toy Train Operating Society in Anaheim. Photos and videos taken by one of the RTC users, Tom Niemi. It shows my simple demo layout and some of the portable layouts at the meet. I didn't bring my portable to this meet.

Image loading....

 Examples of Implementations by Users of RTC

Ray was the first person to report success at installing the Arduino IDE, buying an Infiduino and Elechouse CC1101 radio, compiling RTCModemE and actually running trains! Here are a few photos that he sent me:

Here is the Infiduino wired to an Elechouse CC1101
Ray, is this a real breadboard?

Ray's PC running RTC

RTC Screens

Ray then went on to build the Retro Transformer. Here is a video that he sent me:

Image loading....

In 2017, Ray built an upgraded and repackaged version of the Retro Transformer.

From:    "Ray Leiter"
Subject:    RetroXFMR finally done
Date sent:    Fri, 7 Jul 2017 19:34:45 -0400


Here is a picture of the Retro Transformer finally completed.

I hate to admit it but the crazy thing was working all along. The reason it appeared to not work was because I wired the speed pot backwards. When the knob was turned fully CCW (which would normally be 0 smph), it was actually full speed and as you well know, you can’t do a startup in that condition.

I discovered it after I made it work without any controls. I since then wired it correctly and it now works as it did before.

On another matter; I am still waiting on my parts order from Futurlec. I need the parts to build Adrian’s UHF Block Detector circuit. I don’t think I’ll ever order from them again.


Wakeup Pulse

With the help of Kevin Rice and his Software Defined Radio (SDR), I've been able to learn more about the wakeup pulse.

I found that both the Remote and the TIU require what I call a "wakeup" signal be transmitted to them before data is transmitted. I'm guessing that the receiver circuit needs a carrier signal for some amount of time in order for it to lock onto the incoming signal. I found by experimentation that a carrier on signal of about 2000 microseconds followed by a carrier off signal of about 600 microseconds worked. Following this wakeup pulse, the next carrier on is the START bit of the first character of the packet of data.

When I first discovered this pulse, my knowledge and equipment was pretty primitive. I estimated the pulse to be about 2000 µsec in length with a quiet time of about 600 µsec before the data began.

Now Kevin has helped me better define the pulse. He used an SDR to actually listen to and record the transmission from a Remote. He captured the signal into a WAV file and emailed it to me. I loaded it into Audacity. Here is a screen grab:

If I had this image a few years ago when I was first experimenting with OOK, it would have made my work a lot easier.

This is a transmission from the Remote of a "bell on" command. The wakeup pulse is clearly visible on the left. Then you can see the quiet time before the first start bit of the first byte of the command. I wrote this short description a while ago:

When either the TIU or Remote begin a transmission, they output a carrier for some period of time (1000-2000 microseconds), then carrier off for about 500 microseconds. I call this a "wakeup pulse". It might be there to let the Phase Locked Loop in the radio lock onto the carrier.

Then when the carrier goes on the next time, that is the beginning of the start bit of the simulated RS-232 character. The carrier on indicates a "0" bit and the carrier off indicates a "1" bit.

To the radio, the idle condition is carrier off or "1" condition thus saving the batteries. In the old time world of baudot radio transmission, a "1" was called a "mark" and a "0" was called a "space". So an idle line was "marking".

At 9600 baud, each bit occupies about 104 microseconds.The bits in each data byte are transmitted LSB first.

Look on my RTC web page and in my code for "4b8b" and Morton encoding which are both used on the data.

These encodings take the 8 bit data byte, convert it to 16 bits and then encode the data in such a way that there is never more than 2 "1"s or 2 "0"s in a row in the transmitted signal.

Now I can measure the pulse using Audacity. The carrier comes on for 8.0 ms which is the "wakeup pulse". Then the carrier goes off for 1.3 ms. (In my OOK code, I use 2.0 ms and 0.6 ms which seem to work fine.) Then the carrier starts going on and off with the data. Each carrier on-time represents a "0" bit and off-time represents a "1". Each byte of data consists of a "0" start bit, followed by 8 bits of the actual data (LSB first), followed by a "1" stop bit. This repeats for each byte of data. Since the radio communicates at 9600 baud, each bit is 104 microseconds long. I can also measure that from the wav file.

Of course, I can see all of this only because I spent untold number of hours analyzing the signal with the CC1101 based radio.

I used Embarcadero C++ Builder v10.1 Berlin to compile the program.

I used Audacity and WavePad to try different decodes on the ".mth" file.

I used hex editor HxD in understanding the format of the sound file and in editing the sound file.

I used SOX to understand and convert audio files from one format to another.

I use Lame to convert clips to mp3 format.

Screen recording performed with CamStudio. and with Icecream Screen Recorder.
This site prepared and maintained by Mark DiVecchio

email :

 Mark's Home Page

The DiVecchio genealogy home page
The Frazzini genealogy home page

This site will be under construction for a while forever.