Large Scale Central

Wireless DCC via Xbee

Not sure if anyone is interested but I am making good progress on this and posted a few screen shots and notes on my site.

http://martinsant.net/?p=2803

I wanted to change my xbee controlwidget design to make it a bit more compatible with the real world (ie DCC and JMRI), so I have been working on sending DCC packets over Xbee to my critters and battery powered locomotives.

The hard part was decoding the DCC packets and getting them out via Xbee and that’s working now. I hope to optimize the master and have the client firmware finished up in the next few weekends.

These widgets wouldn’t be compatible with Airwire, Stanton and Tam Valley ‘wireless DCC’ by any chance?

No, I’m afraid not. 802.15.4 gives me network infrastructure out over the air, point to multipoint at 100 meters. So the Xbee is central to the design.

Pretty nifty, Martin.

http://martinsant.net/?p=2816

Made a bit more progress this morning. I have the base layer working- DCC out of the Prodigy, into the Xbee Master, out over the air to the Xbee Client driving a servo. At the indicated loco number of course (in this case 8522). Still too much flying around on the wireless but it keeps up with it- no problems. Next step is to fix that by only sending the data if it changes, the client can keep the DCC stream going if needed. Right now I’m just acting on the data, I’m not streaming it out of the client yet, that’s a future requirement (and requires a small amount of h/w I have yet to build)

Speaking of which, a DCC question if anyone knows- can I take a sound decoder, say an HO tsunami and just stream the DCC the client is getting (voltaged adjusted of course) into the decoder? Will this work and give me the ‘notched’ prime mover sounds? Of course, the motor will not be connected since I’m going to drive the ‘real’ motor with a 20A esc. Will I still get sound or does it need that load to act correctly? Anyone know before I drop $75 on a decoder for experiments?

Just to answer my own question, that would be no, you don’t need a motor on the decoder to get the prime mover to notch up or down or to get any of the other sounds either. At least on the Soundtraxx Econami ECO-100 Diesel. I do like the sounds, it’s driving a large component speaker I have quite nicely. Just need to code up the DCC output driver on the Xbee client, add the driver hardware and I’m in business. The microcontroller is extracting the throttle and sending that to my 30amp ESC and getting the direction bit to toggle the power relay.

Time to open up my good ole RS3 test machine and rewire. Do you think it has enough screws? Jeeze :slight_smile:

This is way more fun than my day job :slight_smile:

X

While your effort is of reasonable interest - and I’ve thought about doing the exact same thing for another project but got shot down time and again - why would you spend time wireless mapping to a 20+ year protocol e.g. DCC? The IOT world is moving way ahead and way faster and spawning a whole new generation of messaging. Can u send a UDP ‘slow down’ broadcast message to your entire railway’s moving assets - for example using DCC? It’s not possible.

Regardless, there is a lot of merit in the idea to support an ancient protocol - like the Morse code or nautical semaphores.

I’m just wondering…

Vic

Victor, while I respect your pursuit of the bleeding edge, I’ll let you go there. I’m getting too old to keep chasing that.

For me, Speed, Range and Compatibility- using off the shelf solutions, are more important.

Xbee, DCC and JMRI are established, well supported engineering solutions.

Mine is a simple incarnation that leverages the structure of the 802.15.4 point to multi-point- DCC is just the payload.

It works, I’m happy. There ya go :slight_smile:

Well, unless either or both of you have the resources (time, money, staff) to duplicate the effort in the features in modern decoders, all you will be able to achieve will be about 10% of the functionality of a modern decoder.

So, yes, doing something to work with DCC is smart.

Of course if your market is just very basic motor control, sure, you can invent a protocol, but honestly, it’s not impressive if you don’t have the functionality.

So what are you guys’ goals? Just out of curiosity. Oh, I have a zigbee based wireless DCC system that works just fine too, and it’s off the shelf.

(by the way you do need a central intelligence in your system, so just doing independent point to point DCC like AirWire, still leaves you in the junior leagues.)

Greg

It’s point to multipoint with a central intelligent master. I’m just finalizing the client DCC output waveforms today. I think I’m off by one bit at the end of the message so I need to stare at my state machine some more I guess. But I’ve been working on it all day so time to take a break and do something else. Phew.

Anyhow, if a system sort of diagram helps, here ya go:

http://martinsant.net/?p=2825

X

OK, so you want to have wireless DCC via zigbee (why do you call it xbee, are you only using the xbee brand name modules from Digi?)

It appears you want a servo out, but why would you not use the DCC decoder’s servo outputs?

Why do you have a servo going into an ESC?

Why are you running the motor from an ESC instead of the DCC decoder?

How are you going to reconcile speed commands from DCC into signals that can go to either your xbee module and/or the DCC decoder?

Why do you have a relay connected to the motor? If this is for reversing, it’s a bad idea, in fact having relays in trains is a bad idea period.

Not trying to give you a hard time, but most of this makes little sense to me.

You can give me a hard time if you want, I don’t mind. In fact, I appreciate it. The proof is in the pudding as they say and I have all this working and it suits my needs so I’m quite happy with it.

I call it Xbee, I’m not sure why, it’s the series 1, with the default point to multipoint incarnation in it, no mesh or anything so I guess I just, uh, call it that. Don’t think it really matters much does it? I actually think it’s a silly name but whatever :slight_smile:

The servo outs are for servos or ESCs. They both operate the same. Perhaps I wasn’t clear on the diagram. I am using $5, 20amp turnigy ESC from Hobby King. One day I would like to get a live steam locomotive too. I’m not sure how that will work out, I’ve never owned one before, but I would like to use servos to control it if I can. So I keep that option.

Yes, the relay is for switching direction, I am using 8A DPDTs ($3 from mouser). The coil is 5v, I’m switching them with 510 mosfets. I don’t have any problems with them and I get a real satisfying ‘click’ out of them too :slight_smile: Not sure why you don’t like them, they are frequently used with other R/C type vehicles but whatever floats your boat.

As far as the decoder, I’m not really interested in anything in it except the sound. If I could get decent sound samples on my own (I’ve tried that route with not much success), I wouldn’t really be interested in it at all. But I can use a cheap Economi HO decoder for that, it will drive a pretty big speaker. Plus for my critters and some other incarnations of ‘vehicles’ I don’t need sound at all.

I’m not sure what you mean by reconcile? Perhaps you are missing the basic premise of what I am doing here. I am deconstructing the DCC stream, manipulating it at the byte level and then re-constructing it at the other end. So I can do anything I want with it. I pull the throttle data from the command, massage it just a bit and use it as a servo/esc output. I pull the direction bit out and use it to flip the relay. I intercept the function commands as well. I can also pass the DCC out verbatim (or altered) to the output stage to drive the decoder sound (and lights if I want) or whatever.

The xbee is in there just to get the data from one place to another without having to worry about the mechanics of getting it there. In fact, all I had to do from my other incarnation of Xbee control was to define another message type and insert the DCC data as the payload. The master did need some custom priority queue routines- I only send data that has changed over the network to keep the speed up. Plus only the Xbee with a particular address gets it’s own traffic, it doesn’t get the entire stream so it’s filtered that way too (although it doesn’t have to be)

I get flack about the Xbee, I don’t know why, I guess they are a bit expensive ($19) but they are industrial strength devices. You can put these little fellows in API mode, disable the network ACK and they scream. There is no ‘sync’ or anything, just power them up, they take a few seconds to find and construct the wireless network and then they just go. I’ve posted timing diagrams before, I’m getting 7ms packet times, that’s not too shabby. I also get a really really good range.

The diagram shows the Prodigy Express. I like the feel and the operation of it (I like knobs), but I don’t like the wire. I don’t like the advertised range of the ‘wireless’ systems either, so I will expand my handheld design for walk around control. The Prodigy is just a source for the DCC commands so I can reverse engineer the stream. I may get an NCE as well, just to see what they do. The prodigy sure spits out a ton of stuff that’s for sure :slight_smile:

Actually, in normal circumstances, I don’t really need DCC. As Victor said, it is a pretty old moldy protocol, it’s dense at the packet level but chews up tons of bandwidth the way it’s transmitted. It also looks cobbled together from many revisions. Or something. But everybody and their brother speaks it, and if I want to leverage anything like JMRI or similar into my operations, I think it’s good I speak it on my network too. I didn’t give up any of my other control design, I just leveraged this on top of it, so I can stay very flexible. You are welcome to take a look at my designs and code, they are published on my controlwidgets site.

And, this last part is most important- I love doing this stuff and I am bored. I’m also bored waiting on the turkey so I typed in a long post :slight_smile:

Happy Thanksgiving!

Greg Elmassian said:

Why do you have a relay connected to the motor? If this is for reversing, it’s a bad idea, in fact having relays in trains is a bad idea period.

I am curious about this statement. I have been experimenting with various types of remote control and some of them require relays to reverse direction. Keep in mind I am a poor man in a rich man’s hobby so I can’t just go spend lots of money on “proper” wireless technology. I have to improvise. But my knowledge of electronics is still elementary. So could you explain why relays are a bad idea?

My concern would be the kickback from the relay coil- a diode takes care of that, the other would be a sudden switch in direction under load, good software design prevents that. Or it should anyhow :slight_smile:

All the R/C control systems my dad designed in the 80s and early 90s used relays to control the direction of the locos. We were using AM-band R/C radios, which were absolutely brutal with regard to interference. We got around the rapid change in direction with two safeguards. First, if the motor voltage was greater than 0, the direction could not be changed. If the voltage was 0, the control needed to receive a 1-second uninterrupted signal before it would change the direction. That seemed to keep things in check very well.

Later,

K

For anyone interested I have moved my breadboard designs for my 8A DPDT relay and the DCC interfaces into production PCBs-

http://martinsant.net/?p=2888

The relay will operate either from a logic signal or from any channel of a standard R/C receiver (I have an attiny84 decoding the pulse width).