 Hi, everybody. If you're standing up, get out or sit down because we have my favorite train guy who only talks about trains, and that's all we invite him for because we like trains, too. Please sit down and enjoy the wonderful world of hacking model trains. All right, thanks. I'm Eric Ritter. I am a fan of radios and trains. And last year I did a talk on wireless protocols for real trains. And at the risk of getting pigeonholed, I'm going to talk about model trains this year. G. So model trains have been around as long as real trains. And for the last 100 years or so, they've been mostly powered by electricity. And for most of that history, trains are powered by track electricity being applied to the track, usually DC, picked up through wheels and applied to a motor. So the train speed is proportional to the voltage. But about 25 years ago, the industry shifted considerably and went to a system called DCC, digital command control, that allows the power and control signals to be separate, although applied still through a track circuit. DCC works like this. It's a differential, essentially polarity switching signal that goes to the to the two rails. And the symbol is encoded using the period of a square wave that's nominally 50% duty cycle. So you have to encode a one, you have 55 microseconds one way and then the other way to get a full cycle. And then with a zero, you have to have at least 90 microseconds, but you can stretch a zero out so that you get an average voltage that's higher or lower that will allow you to actually operate a DC engine on that track. But the harmonics tend to frighten motors. To separate the two signals, you rectify the track power and get DC to power whatever you're trying to power, motors, micro controls, whatever. And then you run the signal through a couple or some sort to get the data stream. DCC packet looks like this. There are three bytes is a preamble for synchronization, three bytes, two of which are information and the third is checks, separated by zero start bets. The packets are several different types of packets. The first two here are used for actual moving equipment, engines and things of that nature. One is speed and direction, which is self explanatory, a function packet is used to control lights and sound effects and that sort of thing. And then there's this other class of packet called an accessory packet that's generally used to control track side equipment. One of the principal uses of this is to control the position of a switch or turnout. So you can do that from a handheld controller throttle controller. And then all of this equipment is configured through DC also. So there are packets for that. So typical wired setup, traditional setup looks like this. You have at least one handheld throttle, which looks something like this. And it's either wired or wireless, but it connects to some kind of proprietary throttle bus. That goes into a command station, which aggregates all the commands from the throttles and creates a DCC bit stream, which is essentially a circular buffer that just rotates through the commands for all the different engines and accessories. That goes to a booster, which is basically an H bridge that does the polarity switching for the track. And then you can also take that bus and run it to an accessory decoder to get both power and data. So for smaller scales like HO, which is a very common scale and scale, this is the most practical way to operate a model railroad because you need to supply the power through some external means. The scale that I model is G scale, which is about three times in scale the size of HO. So in G scale it's practical to actually put lithium ion batteries inside of an engine, because an engine is this big, and run the trains without any track power. And this is desirable because many of us, myself included, operate these trains outdoors where keeping track clean for conductivity is a challenge. But when you lose the track power, you also lose the data. So generally these systems are controlled by wireless connections that are directly from a handheld controller to the locomotive. And to give you a sense of the scale, I debated which movie to use, but this is a test of a G scale locomotive pulling a case of beer. And you can see that I'm really didn't flinch. But that you can see the size of a beer can and some of them are seltzers, but it's the weight that matters. All right, so I'm going next slide here. There are several competing wireless systems, and this has never really been standardized the way that DCC was. And there have been attempts at it, but it didn't go very far. The one I use is called Airwire that's made by CVP. And this is the handheld controller here. It's pretty straightforward. There's a rotary encoder in the center, and then you press that to change direction. So what you see on the screen is the number of the engine, 3841, the speed, and then the arrow indicates direction. And then the yellow button on the left right by my thumb is the accessory button. So you can hit accessory and then a number and throw a switch or turn the signal on and off or whatever you want to do. And this connects to a decoder that's in an engine. And this works, this particular system operates in the 900 megahertz ISM band, which is what attracted me to it as a ham. I have privileges in that band, and I thought it might allow for some interesting reverse engineering hacking kind of stuff. So I wanted to figure out how the signal is actually encoded and sent to the engines. So the first step was sort of a non-destructive look at it in GQRX or some software to display SDR. It's pretty clear this is a 2FSK signal. But what surprised me was that it's continuous. What I expected was that if I made some change, some control change, that it would send that change, and then it would sort of be quiet until the next thing, you know, happened. But this is actually a continuous signal. So I dumped some IQ samples and opened it up in a spectrum. And this is what it looks like. And this packet might look familiar. So I wanted to figure it out from five minutes ago when I explained the DCC packet. So this handheld throttle is actually encoding a DCC bit stream and modulating it as an FSK signal, which seems like a kind of brute force way to do this. But that's what's going on here. So I wanted to figure out how that's being encoded, what's going on. So the next step is to open it up and pretty straightforward, ignoring the gray wires there, which I'll explain in a second. So it's a microcontroller and then this anor and R9A wireless modem. And the R9A is based on the TI-CC-1101, which is very common modem chip packaged with an antenna and some filtering and PIN smatching and that sort of thing. And looking at the PIN out, it's essentially a lot of do not connect or no connection and then power and ground and then an SPI interface and then some GPIO that you can configure through the SPI interface. So to do analysis, I soldered some wires onto the four SPI lines and also eventually one of the GPIO lines and then ran them out the battery. Connector and terminated them with DuPont connectors so I could do some analysis just using a logic analyzer. In this case, the Soleil logic 8 device and then the associated logic software. This is the startup sequence when you first power up the device, the throttle and zooming in on this you can see each of these spikes is a byte and the software decodes all that and essentially there's nothing going from the modem to the microcontroller. It's all the microcontroller telling the modem what to do. You can export this to a CSV and then look at the contents and this is essentially the registers and their contents to configure the modems. This allows you to configure modulation, frequency, whether you're transmitting or receiving, transmit power and that kind of thing. And you can go through the data sheet and figure out what all these registers are and the one that I found interesting was this register 08, hex 08 which puts the, if you set this bit, it puts the modem into asynchronous mode. So the great thing with 1101, the reason it's used in so many different devices is it does all this cool packetization and error correction and stuff, but if you put it in asynchronous mode it essentially bypasses all of that and one of the GPIO lines directly modulates the FSK output. So the connection is just the microcontroller SPI to the modem which configures the modem and then just a bit stream that directly modulates the FSK output. The same setup is present in the receiver. This is what would go inside of a locomotive and there's also an anterin module there. This one has an antenna but it's the same line and so it's really just a mirror image of the transmitter. They're both in asynchronous mode so it creates a virtual wire carrying a logic local DCC signal between the two. So now that I know this, I can create my own transmitters, receivers, whatever I want to do. I'm pretty happy with the off the shelf throttle and as far as a motion decoder that you put in an engine, they're pretty robust and you don't want your engines running away, they're very expensive and heavy. But what I was really interested in primarily was the accessory decoder because the accessory decoders from the manufacturer were very expensive and with six or eight dollars worth of hardware you can put together an accessory decoder that will control as many accessories as you want or as you have GPIO lines for. So as an example, I put together a very simple one just using a very old Arduino Nano or Micro and 1101 module that you can get on eBay. It's probably a clone. I changed the antenna for a more appropriate antenna. And putting these together, you can create either a transmitter or a receiver and there are plenty of DCC libraries available for the Arduino ecosystem because people have been building their own wired DCC components for years. So the only missing piece is to do the modem configuration. So I wrote a library that takes these four inputs and allows you to dynamically configure the modem to do either transmit or receive, transmit power if appropriate. The RF channel, the manufacturer of the throttle is defined 16 channels and then the slave select pin. So you can put as many modems as you want also on this SPI connection and operate them simultaneously provided you talk to them individually. So the library is set up like this. You just set up the four parameters, instantiate the modem. You could do many modems if you wanted with different enable pins and then you can dynamically start it. There are other things you can do, change channel and that sort of thing. This is a little demo contraption that I put together just to show a sample accessory decoder and it looks like this. I have it here but you wouldn't be able to see it because it's quite small so I just put it up on the screen. Essentially the components that I showed you and then I put four servos on it and eight open collector outputs and these are controlled by accessory numbers one through eight. You could code them to be whatever you want. I was going to try to demo this live but I just made a video instead because it will be easier to see from where you're sitting. Essentially I'm going to power this up and then it will read from the EEPROM the last position of the servos or the last binary position of those outputs. Here I'm just hitting accessory one and then the one and three buttons control the accessory number one. I'll go through a couple others here. Excluding the battery this is probably $10 or $12 worth of parts and that would cost to do that with the manufacturer's equipment it would cost you $250 for four channels. For people in this very specific corner of this very specific hobby it provides some options for creating low cost accessory coders and of course you can also transmit by reversing the process and generating a DCC bit stream in their libraries to do that as well. This device which I have hooked up here is a monitor and this is essentially using the library and it's cycling through, I asked somebody to take a picture so that maybe it's just cycling through the 16 channels. With some defined dwell time and this is, I was going to do a real time demo of this but it doesn't seem to be working but this is five different throttles set to different frequencies showing the engine number, direction and speed and we did this at a club meeting with actually five different independent throttles. And all it's doing is looping through this very simple loop on the Arduino and the DCC process has call back that sends limited serial data to the host and then there's a Python program running on the host to display it. But essentially just goes through, waits till the dwell time is over and then switches to the next channel and moves on. I'm going to see if I can get it to work. It doesn't seem to be working for some reason but there's a lot of RF going on in here, maybe the problem. So that's all I have. Thanks for your attention. I have some of the, thank you. I have these gadgets here if you want to see them I'll be around so be happy to show you. No, it may be. I've never seen any, there's no FCC information or anything on any of the equipment. No, that's a good question. There are 16 frequencies but the carrier frequencies are fixed. You can change it on the throttle. One of the drawbacks to this type of system is it's a one to one, well you're going to have one throttle and multiple locomotives but you can't control one locomotive with multiple throttles because they would just step on each other. Some of the other systems, competing systems are mesh networks to overcome that issue. All right. I think I'm out of time so I'm going to get off the stage but thanks very much.