I continue to refine my control widgets. Here is the latest incarnation. I’ve shrunk the footprint down and boosted the clock speed to 12Mhz. This module ties into the 802.15.4 network via Xbee. I’m using the Series 1 not the Pro and Zigbee. I’m not real hip on the Pro Zigbee Mesh, it seems overly complex compared to say the Synapse SNAP mesh network.

Anyhow, according to what I’ve been following on the IoT blogs and sites, 802.15.4 has about 65% of the IOT market so I’ve decided to concentrate in that direction.

Basically, this module allows you to control things like servos and digital outputs, plus it gives you a DCC logic level signal output as well. Feed that into a motor driver like the ones from Pololu and you have a nice robust DCC implementation that is network based, rather than the point to point of Bluetooth or R/C.

I’m also looking into another implementation, via the Synapse RF266 SNAP module. I had initially though I could somehow make the RF266 work with the Xbee Series 1. While I think it’s technically possible to do this, the effort involved is quite extensive. Instead, I think a minor hardware platform will make things easier and actually, more flexible, so I’ve started down that road. Essentially, I’ll use the two serial ports on the Attiny to link the two modules together. With the right firmware I should be able to hang a Xbee Series 1 network off of the SNAP network for all sorts of diabolical mesh network fun. 🙂

P1050050

P1050053P1050049

One thing that I have not been real happy with as I build out my control network, is the hand held controller implementation. I hope this design will change that. It features a uLCD-32 smart touch screen display unit, a large aluminum knob and four tactile hardware buttons. The display unit is a very full featured device including a Lipo battery charging circuit! Very cool. The custom graphics chip and language are very powerful and more importantly FAST. This will take all the UI load off the Xbee/Widget device. More info is here – Serial TFT Color LCD

The reason for this particular design is that I am finding I don’t want to look at the controller as I’m running my trains. I like to hold the unit in my left hand and use my thumb to control the speed. When I get the momentum and braking feature in, I’ll want to use the button under my thumb (I think) to apply the brake function. Or not. Not sure yet but I’ve brought out the USB programming jack so I can download anything I want into it. Lots of power and options here. I’ll probably use this as a test bed for the new Xbee Replacement board, detailed a bit more in the post below this one.

synapse

Well, I can’t believe I have not seen this module before. I may have but discounted it because it is about $11 more than an Xbee Series 1. However, the features in this module are very compelling, you really get a LOT of extra power and features for that $11.

This Synapse RF module-in-an-XBee-Pro-form-factor features OTA (Over-The-Air) speeds up to 2Mbps, maximum 1.2km (4000) range and a chip antenna for compact installation.

This particular RF module includes a user programmable (via python-based scripts), embedded ATmega128RFA1 microcontroller that can be programmed for all kinds of applications including remote sensor monitoring, remote control, or peripheral activation.

Features:

  • XBee Pro pin and footprint compatibility
  • Very high communication speeds (250kbps to 2Mbps)
  • Up to 1.2km (4000′) foot range (line-of-sight)
  • Built-in Python interpreter (Who needs additional microcontroller? This one has one built-in!)
  • Wide low voltage TTL operating range (2.7 – 3.6V)
  • Ultra low power consumption mode (1.18µA. Not mA, but µA!)
  • 15 GPIO, featuring
    • 4 10-bit A/D inputs
    • 4 PWM Outputs
    • 7 Interrupt capable pins
  • 128k flash, with 58k free for over-the-air loaded user programs
  • Communication options include I2C (TWI) master mode, SPI (3 & 4 wire, master mode), 1 UART
  • Low power capabilities (2.3uA sleep current)

More:

  • Embedded ATmega128RFA1 on-board
  • 1 UART port (pin 2, 3) for LVTTL (3.3V) serial control or transparent data
  • Able to be configured to wirelessly program Arduino Uno & Mega 2560
  • Socket-able (2mm spacing) or solder-able
  • SNAP, instant-on, self-healing, mesh network operating system
  • 802.15.4 Protocol at 2.4GHz
  • I2C communication (Pins 9, 13)
  • SPI communication (Pins 18, 19, 20)
  • 128k flash memory (56k available for user applications)
  • Can be used stand-alone (no additional microcontroller required)
  • Low power mode of 2.3uA with internal timer running
  • Supply voltage: 2.7V~3.6V
  • Transmit current: 130mA (Typ)
  • Receive current: 25mA
  • Sleep current: 2.3uA
  • Operating temperature:-40°C ~ 85°C
  • Power output: 20dBm for best-in-class range
  • FCC certified on all 16 channels (2.4GHz)
  • Spread spectrum (DSSS) technology resists noisy environments

I’ve been working on this Xbee DCC thing for quite some time now and have finally finished it off. Or more like, I’ve finally gotten to the point where I think I could ‘release’ the code and the hardware. I have created a version 2.0 release branch for the code and have most of the hardware in a PCB state so it’s getting pretty mature. And more importantly, it works pretty darn good now!

The basic problem I’m trying to solve is how to control my trains, both electric and live steam, with one network. This network would also control pretty much everything else- turnouts, lights in buildings, signals, whatever. Everything on the network- trains, towns, turnouts, signals, would be capable of talking to everyone else, in real time. This would then allow you to tap into the network with a standard interface to leverage whatever application you want on top of it.

This is the reason I went with the Xbee. Unlike simple R/C or even Bluetooth, the Xbee (and I am speaking specifically about the Series 1 Xbee, NOT the Pro Zigbee) is a low level point to multi-point network. It runs at 250Kbps and has a range outside of about 100 meters or 300 feet. Every node on the network has a 16 bit address and can talk or respond to any other node.

One thing that took quite a bit of time to develop and test was the DCC output. The widget generates 128 step DCC throttle messages and DCC Function Messages F0-F12. It’s a bit basic, you have to program your DCC decoder with an external DCC unit and (for now anyhow) you only get those specific DCC transaction but as you can see from the video, that gives you lights, sounds and throttle.

I also completely redesigned the Master side code as well. It’s now far more generic in terms of messages. So I designed a new hand-held controller for it to reside in:

handheld

Hand Held Controller 2.0

 

Here is a basic diagram of what is going on in the U25B in the video. These are the components and control and power flows. Red is power, orange is logic, blue is DCC. Also, it’s not on the diagram, but the economi is controlling the lights and the Widget is driving 2 servos to automate each coupler. The ‘other I/O’ is also hooked up, a current sensor monitors the amps flowing to the trucks and there is also a photo detector that gives a pulse on every wheel revolution (for speed and distance). (The software is not currently looking at these however)

xbeedcc

Basic Control Diagram

 

All of the components in the client are now on PCBs, no more proto or perf boards:

nano

Nano Widget

 

micro

Micro Widget

 

dccOut

DCC Output

 

relay8A

8Amp DPDT Relay

 

 

u25b

hh1

hh2

A couple of pictures of my latest iteration of wireless DCC and train control. This one has been refactored a couple of times and I now have a nice compact executable that takes throttle and function commands from any controller (in this case, my new hand held design) and converts them to both servo pulses (for the motor controller) and DCC output commands to control the lights and sounds. The speaker is a 2 inch full range with a passive radiator, sounds nice and full. The lights are all surface mount LEDs driven by CL2Ns. I also have servos on the couplers, they are tied to the F6 and F7 functions on the handheld.

Here are the basic components that go into the locomotive:

xmaspcbSMAnnotate

Everything is now driven by a simple command structure- throttle commands and function commands. The throttle controls the servo 0 spot, I’m using a 20A ESC to drive the motors in the U25B. The throttle commands are also used to drive the DCC decoder for the engine sounds. Since this is an HO Economi decoder, it doesn’t have the current output directly. But it does have great sound and I also drive the lights with it.

Why Xbee everyone asks? Because this is true networking. Everyone is on the same network and can speak or be spoken too. True point to multipoint. This opens up all sorts of possibilities for automation, signals, detection blocks and computer control. Something Bluetooth cant’ do. It’s also ‘industrial strength’ in that Digi has been making Xbee modules for many years now. They are FCC approved out of the box and

P1040901

This is the base design for my new hand-held controller. Along with a new case and display, I’m going to refactor the software to provide a cleaner interface into the clients (locomotives). Right now my ‘phase A’ handheld knows a little too much about the clients, I want a more disconnected sort of protocol. Anyhow, I’ve gotten everything to fit but the graphic interface required some new hardware so that has not been tested (other than a basic smoke test). I’ll need to write the code for that and then port parts of the old handheld code into it. The keyboard, knob and Xbee interface should not have to change much, I just need a calibration step on the kbd and store that into eeprom. I’m going to have a usb interface into this so I can write a tool on the PC to setup the function keys and display.

HK-T6XV2-M1(2)

transmitter

In addition to my own control system using Xbees, I also play around with standard radio control. I have one of the Hobby King systems shown above, I think it was like $25 for the TX and RX pair. In the second picture I’ve taken the TX out of the shell and replaced the joy sticks with pots. I’ve mounted it on a board so I can get to it’s innards.

Anyhow, what I’ve done is leverage my R/C signal software and my DCC generation software into one widget. I continuously sample the servo pulse coming out of the R/C RX and then translate that into DCC messages. In this case, throttle messages, although they could be anything.

pulses

It all fits into an 8 pin Attiny85, then feeds into my other new widget, the DCC output board.

dccoutA

With this board, one side goes to the battery connection, the other is the output. You can see the small R/C type connector which carries the signal from the Attiny to the board. The DCC output of this board then directly feeds the sound decoder.

brain

main

Finally, here is a video showing it in action. You can hear the notches of the sound decoder increase as the output pot is twisted and the servo pulse width increases-

diagram

Above is the basic install I do on all my locomotives. The green RX box can be a regular R/C RX or it can be my Xbee Control Board. Same basic wiring.

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.