diagram

A diagram of what I’m working on. Not shown is my prototype battery powered handheld, it would be (in addition to or to replace) the master in this diagram. 300ft range between the master and any client node, 250kbs.

I have about 80% of this working as indicated. I’m still coding up the Client DCC output state machine. It’s almost there but I think I’m off one bit at the end of the message. Hmm. Also, I have not yet tested the LMD18200 driver that will power the DCC out to drive the decoder, so that’s another step.

The weak link to me is the purple arrow between the prodigy and the base station. Right now, I have the cheap express unit, so it’s that thick telephone sort of wire. But from what I’ve read the wireless unit only has about a 40 ft range? Not so good. That is where the proto handheld I’ve built will come in. But that’s another project.

The whole idea of all of this is to be as transparent and fast as possible. DCC in at one end, it pops out at the client with only a small delay. How small? I’m hoping 10ms or so but that’s probably optimistic and will depend on the traffic. Lots of experimentation and testing to do but so far so good.

trace

So this is the trace. The upper signal is the generated DCC waveform out of the client microcontroller. The lower waveform is from the Prodigy Express. Same message, skewed a bit, the top trace is about 1.5ms to the left. Look carefully and count the pulses and consider the widths, see how they are almost dead on except for that last bit? Hmm. Oh that will drive me nuts until I fix it!

Here is the Prodigy DCC controlling a servo over my Xbee network. (the video is sped up 200%) This validates the network layer and the speed. However, this is just a raw implementation of the protocol. The DCC message is just sent as fast as possible, regardless if it has changed or not. I don’t want to keep it this fast, there are far far too many Xbee packets flying around. It is ‘thinned’ out a bit because only packets meant for address 8522 are sent to this Xbee but I will need to implement the proper algorithms so that only data that changes is on the network. The client can then maintain the DCC stream on it’s own. Also, with only 128 steps of speed control the precision is lacking controlling the servos smoothly. I’ll need to do some processing of the speed before it’s sent to the servos.

It has a ways to go before it’s a bonafide ‘wireless decoder’ but the basic wireless network works, and that’s the most important, everything else is just more firmware 🙂

So far, I’ve used less about a third of the flash and ram:
Program Memory Usage : 4908 bytes 30.0 % Full
Data Memory Usage : 215 bytes 21.0 % Full

atmel-Studio7

logicAnalyzer

dccw

Making good progress on this. What I’ve done here is connect my MRC Prodigy Express DCC system to my Control Widget Platform. The input from the DCC system is run through an optoisolator to get the voltage down to logic levels. I then wrote an IRQ routine to decode and assemble the DCC packets. These get queued, error checked and then passed to the Xbee transmit routine. I pull the DCC destination address (either 1 or 2 bytes) out of the packet and use that as the Xbee destination address.

In the Atmel Studio pic above, you can see the Xbee X-CTU utility displaying a stream of Xbee encoded DCC messages for address 8522. Anything addressed to 8522 flows out over the air and into this particular Xbee which will eventually be on the client controlwidget.

In the logic analyzer pic, you can see I’m blasting these out about every 7ms or so. Pretty fast! This is just for experimental purposes now, just to see how fast I can go over the air. This will eventually change so that the client is doing all the work maintaining the DCC output while the master only sends packets that have changed since the last scan. This will keep the network traffic down.

Next step is to get the client going, decode the packet and apply it to the various things. Servos, Motor Controllers, lights, etc. With a controlwidget as a ‘decoder’ there is not much off limits- drive servos for steam locomotives or large motor controllers for battery locomotives. Or, a little more esoteric, create a ‘router’ that divides the mobile and accessory traffic into different xbee streams? On different channels too. Hmm.

I particularly want to try a sound decoder to see how that works, I wonder if I can use an HO sound decoder. Intercept the motor control data to drive a servo and then pass the data stream to the sound decoder? Hmm. Don’t know. Sounds like a fun experiment however…

dcc-sm

I have just started to play with a wonderful new tool, a four channel logic analyzer from https://www.saleae.com/

This is a fantastic unit for the price, I can’t tell you how wonderful it is for doing small scale digital h/w design and firmware. I can literally time my interrupt routines, I’m sporting 5us on a dcc decoder INT routine. Sweet. I also found a really bad firmware bottleneck, I love this thing!

lab-500

Here it is all hooked up to my development system. Atmel Studio 7 drives everything. This is my favorite kind of software development. Right on the metal.

I wired up my yellow critter with a control widget, a Turnigy 20A ESC and a 4.8v 2300mah nimh battery pack. Works quite well. I did have to add a relay to reverse the motor but that’s already supported by the software, it’s what I use in my RS3.

A pic from the video, out on the track at Gilbert Virginia.

Just can see the Xbee in the cab. The battery is in the engine compartment along with the Turnigy ESC. The relay to toggle the motor direction is also in the cab but you can’t see it from here.

The development platform for my Dash 9 whenever I get around to it. A close shot of the control board with the Xbee. This is the same control board in the Critter. There is just enough room (I think) in the critter to put in micro servos for the couplers but I have not gotten there yet…

And here is the critter with the handheld controller.

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()



Finally got my control system tested out in the woods. Very happy with the range. The Xbee will do 300ft and I can’t even see the RS3 if I go that far away. This is my controlwidgets.com design. All the wireless communications are handled by the Xbee. I can send any sort of data to or from anything with this system in real time. Those are 16 byte data packets that are controlling the throttle and coupler servos.

The RS3 has the throttle, front and rear couplers and single channel sound all hooked up and working. All of it is powered by a 5000mah hour LiPoly battery driving a Pololu 18v7 motor controller. The control widget drives the servos directly. There is also an RFID reader under the fuel tank which works quite well too.

1ChannelSound

I realized I didn’t have this posted up- this is the single channel mp3 sound card from mdfly.com combined with a simple audio amp. The amp is quite loud and can be built with parts from Radio Shack. This is what I’m using on my RS3 in the pictures below. I’m using the Attiny 1634 s/w UART to drive this from the client widget. It works quite well, you just send a single byte to the card to set the volume or play one of the sounds. However, you get what you pay for, $10 only gets you one sound at a time.