I think there has been a bit of confusion as to what my board is and what it can do. I’ve probably not been as clear as I should have been so I’ll try to clarify that here.

First, the ‘widget’ is a design I have been working on for several years now. It’s gone through a couple of iterations of hardware but for the most part this is a final design. It is meant to be a generic ‘Internet of Things’ device. That itself is a bit confusing as IoT means different things to different people. However, since my application is controlling large scale model trains, I’ll describe it in those terms.

This board will drive motor controllers (ESCs), external serial devices (sound cards, for example), servos, relays and provides a logic level Digital Command Control (DCC) output. It will also accept inputs such as digital and analog devices, sensors, etc.

That is the physical side of the board. On the network side it will accept Bluetooth modules, Xbee, Wifi and SNAP mesh. This means you can run it with your phone, your raspberry Pi or your PC. I also have a couple of proprietary handheld controller designs I’ve been playing with but for now I’m concentrating on Android Phones since they are cheap and available.

My main concentration now, since I am interested in all the cool things DCC decoders will do for you (including saving a lot of wiring inside the locomotive) is to support the three main Large Scale DCC decoders- QSI, SoundTraxx and TCS WOW. I am writing android apps for this with the first one being for Bluetooth. Others will follow as time permits.

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 that I will probably put in my Aristo U25B.

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.

Trip_Optimizer

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.

phonescreen

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.

protophoneB
protophoneA

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.

bt

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()
bluetooth.prepare("HC-06")
bluetooth.write("--testmessage--")


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

try:
   import android
   from jnius import autoclass
except:
   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.socket.connect()
               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(self.recv_stream.read())
        return datastring
        
    def close(self):
        if self.deviceValid:
           self.socket.close()



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.

pygame

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 ftdichip.com 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.

USB-Android-FT312D

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

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

tinyparts

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

http://www.freetronics.com/surface-mount-soldering-with-a-toaster-oven

http://hackaday.com/toaster-oven-reflow-soldering

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.