You may have seen the posts about my Remote Train Control (RTC) program that I wrote which lets me control my MTH engines from my PC.
The limitation of that program has been that it required a wired RS-232 connection between the PC and TIU. This wired connection meant that the PC could only control one TIU (there were work-arounds to get past this) and when the PC was communicating with the TIU, other Remotes were locked out.
I've now been able to figure out a solution to this by working out a method to connect the PC to TIU over a radio just like the Remote.
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 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:
https://fccid.io/OT8RFMR#axzz3RPE7qRYL
https://fccid.io/OT8RFMT#axzz3RPE7qRYL
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? If I've left out any key information, just ask! Thanks for taking a look. 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. I don't know if he ever got to a solution.
But at least, if he was right, I could search for OOK and the TRF6901.
3. On the TI web page, the device 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. So the Remote and TIU probably spoke either FSK or OOK. I found this article: "I'm OOK, You're OOK?" from Maxim. Another bit hint was the comment on the TI TRF6901 web page that stated: "Replaced by CC1101".
4. I needed to find out if anyone sold a radio board using the TRF6901. Searching the Internet turned up nothing.
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 an Arduino. Then I found the panStamp web site and product called the "panStamp AVR 1". Exactly what I needed, an Atmega328p MCU and CC1101 on a small circuit board along with a carrier board containing a USB port for a PC. I've used the Atmega328p MCU in other projects so I was familiar with it. Easily covers the two frequencies I needed to cover. I ordered one. Took about 2 months to get it from Spain - I didn't get the expedited shipping. Next time, pay for the faster shipping.
7. The Atmega328p MCU is programmed using the standard Arduino IDE and board files from panStamp. Their web page shows you everything you need to know about installing the IDE with panStamp support. I learned that panStamp supported the CC1101 using only a protocol called "SWAP". A very complex high level protocol. For most users it is the best choice - as long as the radio on the other end of your connection is speaking SWAP. I needed to be speaking OOK.
8. I learned how to program the CC1101 from scratch. I searched the Internet and got little bits of help. 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 wrote a program based on the example program "modem.ino". I could communicate between the PC and the TIU with my Remote Train Control program. (note: this paragraph took about 5 months actual work.)
9. To program the CC1101, I took the code written by the panStamp developers that supports SWAP, deleted all of the SWAP routines and added routines to implement OOK.
That was the good news, here is the bad news: the panStamp AVR 1 is no longer available. Their web page promises that there is going to be a panStamp AVR 2 soon. Maybe in September.
As with the RTC program, once I port this OOK code to the panStamp AVR 2. I will give the code to anyone who wants to try it.
A video and other information on my web page: http://www.silogic.com/trains/...Radio%20Support.html
Mark
