This is the prototype control widget. I originally called them ‘train widgets’ but that is a bit limiting as they should be able to control pretty much any surface vehicle. I wouldn’t use them for flying devices however as the range is only about 300 feet- fine for earthbound machines but a bit too limited for anything that flies.

Nevertheless, since my primary purpose is controlling G scale model trains, this will do nicely. As you can see from the photo, these are very simple devices. An Xbee series 1 and an Atmel Attiny 1634 micro controller. I also have a suite of software modules written to control or monitor each of the functions mentioned in the diagram, plus do all the Xbee network message passing.

Each widget can control servos, motor controllers, discrete outputs (lights etc), a sound card with 8 channels of up to 1000 sounds, an RFID reader (for position sensing) and a configurable set of I/O pins for inputs (speedometer, current sensor, etc) or SSI/SPI to expand the I/O.

The Xbee allows bi-directional radio communications using the 802.15.4 protocol, so any node can communicate with any other node in real time. One Xbee in a hand-held configuration can control multiple locomotives, turnouts and animatronics, while a computer can also control and/or monitor the same (or other) locomotives or devices.

Anyhow, I’m working on a whole series of designs based on this, I have ordered the first set of PCBs, they should be here in a couple of weeks. After that I’ll be designing PCBs for the handheld, working on the sound card (I have a new one, see this link for more info) and expanding the software modules.

Well, after much debugging and trouble shooting I still cannot get either of my Android Interface prototypes to work. I have tickets open with the support guys but so far they have not been much help. This is rather disappointing but perhaps it’s a good thing. Time to move on. I have all of my control and sound s/w and h/w working, now I need to concentrate putting it into widget form with some custom PCB designs. I have the client widget designed, next are the hand held PCBs which will entail a display board and a keyboard circuit. The computer interface is covered, a parallax Xbee to USB board will be used for that, I just have to get the python drivers together and interface it into my websockets design.

I plan on releasing all of this as a series of several components, or widgets as I like to call them. The first will be the client widget. This will be for installation in a locomotive, turnout or animatronic device. It will interface to servos, motor controllers, my sound board, discrete outputs (ex lights). I will also provide inputs for various things like current sensors and feature an RFID reader port (for position sensing).

The second will be a couple of small PCBs, this will be the hand-held widget. I’ll also offer a resin cast/3D printed housing for this. And like the client widget, the s/w will be open source.

The third widget is the mp3 sound player. This will require the client widget to function.

The last widget will require only s/w as it’s based on the parallax Xbee interface board. You will need one of these anyway to program the Xbees for each of the clients and the hand-held. It will then double as a computer control point for the raspberry pi.

I’ll link all this together with some of the software I’ve done for the Wixels, at least on the HTML5/websockets and server side.

The basic idea is two fold. You can drive your trains with the hand-held and control all client nodes with that (locomotive or whatever) AND/OR control them with the computer or some combination of the two. I’ll open source everything so you have something working right away, yet also have the ability to alter the code to whatever you need. I’ll keep the cost of the PCBs to the absolute minimum and offer them bare, as a kit, or populated and programmed. Stay tuned.

As we enter 2014, I thought I would post up a recap of what I’m working on. Primarily I’m developing a wireless method for controlling moving vehicles. In my particular case, this is Garden Scale (G) model train locomotives. However the principles and widgets I’m designing could be used to drive almost anything via real time wireless up to a distance of about 300 ft (100 meters).

The key difference between my method and say standard FHSS (or similar) 2.4Ghz Radio Control is that I am oriented toward a computer driven network, in my case, 802.15.4 as implemented with the Xbee Series 1 modules.

Why a computer network? Well, for one, it gives me fine control over the exact data I’m passing back and forth. Second, it’s bi-directional. The network is oriented as a single to many so any device can talk to any other device. Each Xbee module has a unique 16 bit ‘node address’. You just form a message, add the address of the node you want it to go to and send. The network takes care of getting it there.

This is quite powerful. You can be sending control data to your locomotive and then, as it passes over an RFID tag, it could send that position data back to the computer (or your hand-held, or another device, etc) in real time. Additionally, other data such as speed, current draw, etc could be returned from the locomotive as well. Just because this is a computer type network, it isn’t slow. I’m getting data packet transmission times in the 7ms range which is quite fast. (For reference, your average servo scan time is 20ms)

Anyhow this level of potential automation is, by electronic design standards, fairly simple. I have an Xbee and an Attiny 1634 Microcontroller as the main components of my ‘Train Widget’ and that’s pretty much it. Basically about $22 worth of electronics as the ‘brain’ of all of my devices.


This is a picture of the basic train widget. Xbee does the communications, the Attiny handles the processing and drives the servos and motor controller. It also sequences the mp3 players (2 stereo channels) so you can play sounds via commands sent over the network or by throttle control positions. The two cards are just to the left of the speaker which I’m driving with a generic LM386 amplifier chip and some caps from Radio Shack.


Above is a shot of the front end showing the coupler connected to a micro servo, the ‘back’ coupler servo sitting beside it and the RFID reader in the upper left. I have all of this working including the transmission of the RFID data to the hand-held.


This is a picture of my stand alone ‘simple’ hand held throttle prototype. I also have all of this working, however only at a basic level of controlling one locomotive at a time, I don’t have any multiple unit code in there yet. I’m also thinking of going with a graphic display instead of this ASCII only one and also designing a ‘cradle’ or appliance of some sort so I can use my tablet as a user interface instead of a LCD. (See the post below this one)


Finally, this is a pic of my uncoupler device. One of these per car with the locomotive in charge of each one. The handheld would allow you to address the locomotive and then each car individually to uncouple anywhere. Each of these consist of one Attiny Microcontroller and a small 2.4Ghz transceiver. The locomotive has the ‘master’ transceiver and can talk to each car in the train that has a ‘slave’. The Attiny then controls the servo motor to move the coupler. This is clocking in at about $2 for the Attiny and $8 for the transceiver. Add $4 for a servo. Not super cheap but not too bad. $18 per car? I guess. Hmm, need batteries too…

I’m getting ready to refactor the software for both the client and master so I decided it would probably be good to shoot a bit of video showing everything working and driving servos before I break it for a while. This shows servos on channel 1 of both clients moving via the knob on the master. There is a bit of dead space on both ends of the knob rotation but other than that it tracks really well. Note that I click the somewhat silly keyboard to select between the two clients. Anyhow, you can see other posts I’ve made of the timings and message passing but I wanted some real world video to show just how well it’s working. So here ya go. Next up is getting the RFID via Xbee and the slave sound card up and running. Almost there. That’s up next.


It figures that the only modern large scale GE Evolution series locomotive (or at least a predecessor, the Dash 9-40CW evolved into the ES44 series) is available no more. Aristocraft is out of business and basically having a fire sale on all their remaining stock. So I count myself lucky to get one of these. Perhaps another used one somewhere someday and have it custom painted in NS heritage colors? Ah well.


Not much new, I have gotten the Xbees to communicate in API mode. The only subsystem left to develop is the servo driver. Turns out I’m going to have to roll my own incarnation using timer 1. But that’s actually good, I don’t like depending on ‘libraries’ from third parties which often have deep dependency lists.

I’m also doing another pass on the RaspberryPi/Wixel/HTML5/Websockets project with the idea of releasing it open source or at least a collection of source code that mostly works. I hope to include the Master/Slave Wixel protocol thing I’ve had laying around for a while too.

Some very sad news too, Aristocraft Trains, who make one of the locomotives I really really want (pic above), is going out of business. Perhaps I can pick up a NS Dash9 before they go completely extinct but damn, that messes up some of my plans. Oh well. Shit happens.


Spent most of the Holiday weekend finishing up the soldering on my various train widgets.

On the left is the Pololu 18v7 7 amp DC motor controller. This is a commercial board. It works great in my Aristo RS3 and allows bi-directional control without a reversing switch. It’s very configurable. You can run it bi-directional or single direction and it has configuration items for acceleration and braking although I have not tried those yet.

To the right of that is my ‘helper r/c’ design. This board reads r/c channels and converts the servo pulses to flip a relay (for reverse) and turn on up to three MOSFETs (for lights) using standard R/C airplane sorts of radios (one channel per). I noticed some people who use cheaper airplane ESCs are dedicating a servo to flipping a toggle switch onboard the locomotive, this eliminates that. (Personally, I like having a reverse switch so I configure my Pololu that way anyhow). This is a very inexpensive board based on the ATTiny84 micro-controller.

Not shown is an R/C sound board, it allows you to play any mp3 sound, triggered by a channel on the radio. Stick all the way to the left, play sound 1, all the way to the right, trigger sound 2, in the middle, silence. So horns, bells, or music even if you are so inclined. I’m thinking 1-4 channels of sound depending but I have not finalized that yet.

Next on the left, below the motor controller is my Xbee widget. This is going to be the basis of all of my new wireless designs. I can re-use the basice design and populate the board with different s/w only, no need to change the h/w to have several different ‘widgets’.

Depending on the s/w, I’ll be able to control servos, DC motor controllers, MOSFETS (on/off power switches) and drive my 4 channel mp3 sound card. I’d also like to provide the option of DCC outputs to feed various decoders but that s/w hasn’t been developed yet.

It will also provide serial inputs for things like RFID readers, speed and distance counters, current sensors and other things like that. Note that this doesn’t have to be a locomotive unit, this node could go anywhere to control turnouts or animatronics, etc.

With another set of firmware, it will act as a hand-held controller. A rather large prototype of that is in the center of the picture. (This should fit down into a nice sized handheld unit once it’s put on a PCB)

Yet another incarnation of s/w will produce a widget that will interface to your computer, allowing control of any other widget.

The radio for the wireless is the Xbee series 1. These are low cost radio nodes, come ALREADY FCC certified and have a range of 300ft. They also provide a set of firmware called digimesh that turns your network of nodes into a self-healing mesh network. VERY COOL. The proctocol is also open source so no more proprietary radio communications! Love that.