First Power up of the TCS decoder and the Bluetooth Enabled Control Widget

This is the first power on test of the decoder. I have not changed anything in the firmware or Android App from what I had with the Economi Decoder. I am using the 28/128 speed step which is the default in both decoders – so the extended packet format of DCC. The throttle, Bell and Horn all work out of the box, no configuration was done to the decoder before I tried this.

Because the TCS has some additional features and requirements, I will probably have to change the firmware and app side a little from the Economi implementation. It also has some sort of ‘mode’ to switch between the lights and sound functions so I will have to figure that out. That is the nice thing about a custom app, I can tailor it to each decoder.

I also will be controlling a few extra things with this particular installation – I’ve got a temperature sensor mounted on the heatsink of the DCC amp. I also had a current sensor in there but it proved to be defective so I had to remove it for now. I’ve got two fans wired to function outputs on the decoder so I can turn those on and off. Two servos will be used to control the couplers as well. These will be implemented in the widget layer, they won’t be controlled by DCC so I can tailor that profile as well. Just yanking the couplers open doesn’t work very well, you need a smooth motion.

One other option will require a PCB mod. I want to be able to ‘name’ each BT module so it shows up in the phone as a locomotive number and description. The docs say I can use up to 20 characters for this. However it requires that you power up the device with a pin held low, then let it go high so it enters ‘AT’ mode. This will require either a special app or an extension to the one I have to set this plus a jumper on the PCB. I can work around this for now but I will add it to the PCB layout along with a couple of other spacing fixes for the next pass.


Temperature Sensor

Front Speaker and LEDs

Fan 1

Servo and Coupler

Wheel Counter and Main Speaker

I think I’ve finally gotten to a beta release point on my Phone App and Widget Firmware. The firmware is universal but the phone app is customized for the Soundtraxx Economi DCC decoder. This app lets you control and program a battery powered locomotive via wireless DCC on your Android phone.. Above are the four screens. Some of the controls, the couplers in particular, are not implemented quite yet, or are implemented but untested. Everything else works. The coupler buttons are intended to control servos to actuate the couplers ala switching moves.

Below is a (rather long) video of the app driving the decoder on my little test setup. The blue readout is a current meter. Not pulling much here.

I have a new locomotive, a USAT GP9, that I will be putting a TCS WOW decoder into. That will get it’s own phone app, although it should look very similar to this one. I’m finding the various decoders, while all adhering to the DCC spec, are a little different in certain areas, particularly the CV programming. Also, one thing I didn’t consider is getting data FROM the decoder. I have the circuit and s/w design for that but it’s not implemented yet. That’s next.

At some point I may try to merge the various incarnations of the phone app into one, but for now I’ll be doing one for each. I plan to support the three decoders I currently have, the QSI, the Economi and the TCS Wow.

Here is a demo of the phone app. It doesn’t actually do anything, just lets you change screens and move the throttle slider etc. But I’d be interested in feedback from other train folks – Drop me an email:

Below is a diagram of how it all fits together

Got my new boards in for the latest widget design. On the left is the DCC Amplifier, it turns the logic level signal from the widget into a 15v DCC signal. The board on the right is the new Megawidget.

I have moved away from SOIC components as they are hard as heck to solder by hand. So this one sports an Atmega328 28 pin thru-hole microcontroller. I still have one SOIC component, the 3.3v regulator for the network module but it’s a pretty easy hand solder and the thru-hole version is ridiculously large.

Another advantage to this microcontroller is I can run it at 16mhz using an external crystal. It’s a pretty speedy little sucker at that clock rate.

The boards came out perfect in terms of electrical connections, I didn’t have to cut any traces or add any jumper wires. However I do have a bit of a spacing problem on both the controller and the DCC amp that I will have to address on the next pass. The ISP programmer port is too close to the bluetooth module and the logic input on the AMP requires that I wire it instead of putting a pin header – but for now they are ok.

The plan is to refactor all of my existing code on the firmware side and get it all squeaky clean- bluetooth network, servo control and the DCC output. Hope to have that done this weekend. Eventually it will drive a TCS WOW Sound 5A DCC controller.

I pulled another project off the back burner and got the basics working. This is a Android Phone App I wrote in Python that interfaces to my control widget but with Bluetooth instead of 802.15.4. It uses the same DCC output code as all my other widgets but with a Bluetooth Network interface instead of Xbee. I seem to be late to the party all the time but I found this unit- it’s a pin Xbee compatible unit so it will fit right into my Control Widget design with no problems, just some different software. In the picture above, the unit on the left is my Asus 7″ tablet and the one on the right is a cheapo smart phone I got off of Amazon. Both work quite well. Not sure on the range yet, once I get the boards built I’ll be installing it all in my Aristo U25B for some real world testing.

I don’t have all the function codes working quite yet, but the throttle works great. This is all done with a BT board I’ve had laying around for a while- I have one of the above Xbee type units coming so I will be refactoring the code a bit for that anyhow. I should have boards for testing in about a week.


Above is the GE Locomotive ‘Trip Optimizer’ Software. You can see a nice video about it here -> GE Locomotive Trip Optimizer

And here is a really cool video of GE intermodal at work, with the Trip Optimizer of course.

I’ve borrowed some of the graphic layout ideas from this to make the GUI for my phone app- Not quite sure what I want yet but I like this minimalistic implementation.


Again, the idea here is that the phone sits in the cradle (see below) and communicates with the Xbee master in the cradle via bluetooth. The Xbee master reads the knob and the buttons and syncs up with the phone app to keep the display refreshed. The Xbee master controls the Xbee client in the locomotive and also can query the locomotive for speed (via a wheel encoder) and current draw (via a pololu current sensor). There are also hooks available for an RFID reader (I use a somewhat pricey one from Sparkfun – $33) for position information.


Latest incarnation of the Phone Throttle Contraption. The phone communicates with the Xbee Controller via bluetooth, a custom app runs on the phone. This is based on previous experiments with an android tablet, you can read about that here- Android, Bluetooth and Xbee

I’m trying to emulate a generic sort of DCC throttle ‘feel’ with this. I have all of the base code written and tested, it’s just a matter of pulling all the parts together. Slowly I’m getting everything working.


I’ve started some development for a new throttle controller, this one is based on an Android tablet for the user interface. My approach is a bit different than what is out there for tablets and smartphones though. I don’t like ‘sliders’ on a touch screen for controlling vehicles, so the idea here is to interface a small analog joystick (the parallax unit) and a potentiometer to do the actual control. The tablet will be used to pull up user interface screens for the locomotives and also have screens for controlling other things.

Basically, I’ve connected a generic bluetooth interface (about $10) to my Xbee Widget controller. The Widget can be configured to have up to 8 analog inputs, I’m using 3 of them here. I have the bluetooth interface on the spare serial port. On the other serial port is the Xbee which actually sends the commands to the locomotive.

I’m using PyGame to build Android apps with because I love Python!

Right now, the only thing on the screen that actually works is the speedometer. This is a screen shot of a Positive Train Control screen I dug up on the internet. I’m not sure what most of the other things on there are so this is just for playing around for now. But hey, it looks neat!

So anyhow, since I looked high and low and found ONE reference on how to scan the BT devices with Python, I decided to post up some python source to help out anyone looking to do this. As with most Python things, it’s really quite easy once you get the particulars ironed out.

To use this, just pass in the name of your bt device after you instantiate it. This is the same name you see when you pair your device with your tablet. In my case, it’s ‘HC-06’.

bluetooth = Bluetooth()

Here is the method. Note that the UUID in the device create is the same for all BT devices (as far as I know).

Jnius is a nice package that lets you call Java from Python so this could be used for other things besides Bluetooth I guess, but that’s another project. I really detest Java so anything I can do to write Android apps in python is great.

# Bluetooth interface class for PyGame- Python Android Games and Graphics development
# you will need the jnius python library to use this

import pygame
import sqlite3
import math

   import android
   from jnius import autoclass
   android = None

class Bluetooth:
    def __init__(self):
        self.BluetoothAdapter = autoclass('android.bluetooth.BluetoothAdapter') 
        self.BluetoothDevice = autoclass('android.bluetooth.BluetoothDevice')
        self.BluetoothSocket = autoclass('android.bluetooth.BluetoothSocket')
        self.UUID = autoclass('java.util.UUID')
        self.deviceValid = False

    def prepare(self, name):
        paired_devices = self.BluetoothAdapter.getDefaultAdapter().getBondedDevices().toArray()
        for device in paired_devices:
            if device.getName() == name:
               self.socket = device.createRfcommSocketToServiceRecord(self.UUID.fromString("00001101-0000-1000-8000-00805F9B34FB"))
               self.recv_stream = self.socket.getInputStream()
               self.send_stream = self.socket.getOutputStream()
               self.deviceValid = True

    def write(self, sendString):
        if self.deviceValid:
           self.send_stream.write([ord(b) if ord(b) <= 127 else ord(b)-256 for b in sendString])

    def read(self):
        datastring = ""
        if self.deviceValid:
           c = self.recv_stream.available() 
           if c > 0:
              for i in range(c):
                  datastring = datastring + chr(
        return datastring
    def close(self):
        if self.deviceValid:

This is a quick project I’ve been working on to test the feasibility of using wifi to directly control something.

It uses a slider on an android app to control the position of a servo in real time using my widget and the Sparkfun WiFly Module.


There are three parts, the hardware, which is the widget and the Wifly module, the microcode that goes into the widget and the app code on the tablet.

(This is a rather lengthy post so I’ve moved this to a page of it’s own)

You can find it here- Simple Wifi Servo control with Android

As far as conclusions from this, I don’t particularly care for 802.11 for control. In my case, the primary objection is well, it’s not really meant for that sort of thing and I don’t like all the complicated message transactions this entails. Your mileage may vary on that. The other thing is my cheap tablet doesn’t have a very good wifi range so at 30 ft or so I start to loose control. Granted, much of this could probably be resolved with an improved algorithm on the app side, or perhaps a better device (I’ve resisted getting a smart phone). But for me, I prefer the Xbee series mentioned elsewhere on this blog so I will be sticking with that project before I come back and put any more effort in this one.

Been a while since my last update. I’m in somewhat unfamilar territory so progress is slow. I’ve been messing around with my Android tablet, the Eclipse IDE for Android and this neat little chip, the FT312D.

In theory, this chip should provide a way to have the tablet control external hardware via ttl serial, and as a bonus, provide external battery power. It acts as a host module and that’s how the tablet sees it but the USB side is somewhat alien to me, both h/w and s/w. My first pass prototype came out a bit sloppy, it connects to the tablet but with less than acceptable results.

So back to the drawing board I guess. Here is a new, base circuit diagram, drawn from the reference circuit on the web site. I’ve cut out the Attiny, the Joystick and the Xbee for a minimalistic situation. I have all the parts, just have to build it.


I’ll be working with these softwares- Android demo application projects from the chip manufacturer –

And of course, to download the Eclipse IDE to load and build all this, you can go here: Android Development


Well, this turned out a lot easier than I thought it would. Align the chip and stick it down with masking tape. Just touch the soldering iron tip to the trace and the chip pin and presto, instant bond, no muss, no fuss. Did the whole chip in just a few minutes.

I’m using a 0.8 pitch Schmart Board to do this, they are a bit pricey but well worth it in terms of ease of use for concocting a breadboard-able SMT chip.

However, it does seem prudent to look into the next step up, surface mount reflow in a toaster oven. This was not bad but these components are getting too tiny to work with and I will need a more ‘small production friendly’ method if I want to sell these things (which I do at some point). Here are a few links I’ve been looking over and does it count I’ve been to Walmart to price new toaster ovens? Ha.

Suface Mount Soldering Tools

Anyhow, to recap, (see below post) this is the interface chip between my control widget- a tiny joystick and xbee radio module- and a cheap android tablet. The idea is to use the tablet as the user interface for the widget as opposed to the controller I have been working on with it’s limited LCD and 16 key interface. (see previous posts) It works ok and it’s cheap but its like really clunky. Time for a fresh morph into a new design.