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
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…
Since I’m putting together a new N scale layout, or at least I’m planning it out right now, I decided I should probably give DCC a go since it’s so popular. So I ordered an inexpensive DCC starter set, the MRC prodigy Express2. I am glad I did. Just on a test loop my little DCC switcher locomotive runs WAY better than it did on DC. And since I like the feel of the MRC Prodigy Express DCC controller (more or less), I figured, why not come up with a way to use that to control, via Xbee, for my G scale stuff too?
So after much scouring and searching via Google, I came up with an input and output circuit for my control widget board.
In the above picture you can see the DCC waveforms and the really simple input side of the circuit. I’ve also got my basic C framework built out and this looks like it will be a fun project if I can ever get the time to work on it!
Anyhow, the basic idea here is read the DCC out of the Prodigy output, transmit that via Xbee and decode it on the other end. Or pass it through, or both. That way you can use any DCC handheld you want to control battery powered locomotives or even live steam ones (via intercepts of DCC commands to servos and relays, etc)
So this should be neat if I can get it to work. Something new to learn anyhow, DCC as a message stream
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.
Here are some pictures of my computer/manual switch throw. I was looking for a device that I could use to throw a switch both with a manual lever and also have a servo drive it for computer control. This is what I came up with. After a bit of testing, it seems like it will do just what I want. It uses a cheap waterproof servo, three magnets and a styrene throw. There are two magnets on the servo wheel and one on the throw. There is no connection between the servo wheel and the actuator other than the magnetic ‘clutch’. The ‘spring’ wire is a paper clip bent to fit. With the servo off or centered, you can throw the switch manually and it ‘clicks’ to one of the two magnets on the wheel. Under computer control, the servo can rotate to ‘pick up’ the magnet on the arm to throw the switch. Works quite well on the bench so I’ll be installing it soon to test out in Gilbert.
Man, my o-flute-upcut carbide bit does some clean work on .125 inch styrene! This is the design from a few posts down, cut out with the CNC. A waterproof R/C servo provides the automation. The arm has one super magnet, the wheel on the servo has two. The idea here is that you can throw the lever manually to control a turnout but that it also remains at all times under control of the computer.
That’s the plan anyhow. The magnets are those little really powerful ones. They act like a ‘clutch’ in this situation. So far it works on the bench but the real world is another story, I’m not quite there yet. I need to install them on my three turnouts and stick them out in the cold rain for some testing.
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.
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.
Here are a couple of shots of my control system going into my Aristocraft RS3. The power is all in the back end, I have a 5000mah 14.8v lipo pack driving this beast with a Pololu 18v7 motor controller powering the trucks. A very potent drive train. Anyhow, these pics show the brains- the Atmel 1634 board, the Xbee Series 1 and the MDFly mp3 sound card. Not seen is the RFID reader on the fuel tank- I’ll post that up later. Phew, some work and lots of engineering spits and fails but it’s now pretty clean and works well. I did downsize the controls a bit, I’m only driving the motor, the two coupler servos and the sound card. I left the lights on a manual switch and there is a current sensor in there but I’m not looking at it right now. As mentioned, the RFID is also connected and works so I do have the basics of a computer controlled system. The main control boards are also reasonably accessable by taking off just the short hood of the locomotive so tweaking the firmware, sounds and the pololu motor controller won’t require the entire locomotive to be taken apart (which is a BITCH to say the least!)