If anyone is interested, I’m making slow but steady progress on my train widgets board. I’ve managed to get it to work with the Ardunio IDE as well as Atmel Studio 6 development platforms. Ardunio was a bit of a pain as the Attiny series are not ‘official ardunios’ but it works quite well, albeit with a smaller feature set than some. Here are some pictures:

http://martinsant.net/wp-content/uploads/2014/05/pir-widget.png

http://martinsant.net/wp-content/uploads/2014/03/widget-pins.png

http://martinsant.net/wp-content/uploads/2014/05/hhd-A.png

(A widget is embedded in the hand-held throttle, the case is 3D printed.)

The idea is to create a low cost, wireless, networked control board that will control, well, everything. Servos, motor controllers, digital outputs and inputs, etc. All talking on the Xbee 802.15.4 network in real time. I’ve got all the low level stuff working, I’m in the process of ripping out the old radio control in my RS3 and installing one of these to do some real world testing soon.

I know it’s not your intent, but what is the relative cost difference to do all of this on 802.11?

I would think that 802.11 components are down low enough in cost to be competitive, and that solves many issues with compatibility and available off the shelf hardware.

Greg

That’s an interesting question. My thoughts are that I don’t want to share real-time data with standard 802.11 running tcp/ip traffic. So I’ve divided the layers. All real-time traffic goes through the Xbee. I’m getting 7ms packets with 25 byte payloads. Pretty fast. I get a nice smooth servo response at this speed.

To be compatible with the ‘outside world’, I have my Raspberry Pi setup as a web server. I can present an html5 based web page to a phone or tablet that in turn sends commands (via web sockets) to the Xbee network via an Xbee plugged into the USB on the Pi.

Eventually I will have a native app on the phone/tablet that will not require a browser interface, but I’m not quite there yet.

As to cost, an Xbee series 1 is $19 from Mouser and an Attiny 1634 is about a buck and a half in singles.

Here is a general system overview-

http://controlwidgets.com/wp-content/uploads/2014/03/overview1.png

So the wireless zigbee module is $19… ahh, the through hole component… so you basically want no intelligence at the servo, and just basically use zigbee as a wireless connection from the processor to the servo?

the data rate is not so great, but I see it works for a few devices… how about running multiple locos at the same time and accessories, etc.?

Greg

Hmm. I’ll edit this a bit since I was a bit bleary eyed last night and not very clear. (to say the least)

The xbee is just the com layer, it runs at 250kbs and can address up to 65K other xbees. The Attiny 1634 microcontroller handles all the messaging and all the work of maintaining the servo pulses, so no, it’s not a straight pass through like R/C.

From my measurements I could update 5 locomotives in 35ms so I don’t know what you are saying there. A consist of three (depending on how you did it) would be 21ms. The nodes don’t require a constant refresh of data- there are several options for delivery and acknowledgements for individual messages.

Anyhow, as the idea is an eventual open-source, low cost implementation, I’ve added Ardunio support but my code doesn’t use the Ardunio libraries (yet), it’s straight C code in Atmel Studio 6. I’m working on that.

I’m slowly fleshing out my page, it has some diagrams and schematics if you care to take a look-

http://controlwidgets.com

That helps… so the zigbee is a 250k data link with 65k addresses…

so no brains per se at the servos, you sending an address and servo “count” to each?

the key was nodes do not need constant refresh…

Got it…

how do you transmit the servo info, and what is between the servo and the zigbee receiver?

Greg

The Attiny 1634 microcontroller is between the xbee and the servos. I transmit a number between 0 and 1000 for the servo position. One word handles one servo, I have a payload of 16 bytes with a 25 byte packet size but that’s just an arbitrary size I picked.

The xbee operates in API mode. A message comes in to the xbee, it interrupts the microcontroller and he reads out the message and applies it to the servos and other outputs. One of the serial ports on the attiny is dedicated to the xbee, the other I use for RFID in and sound card out.

The Attiny times the pulse width to each servo based on this number (0 to 1000 microseconds) to get a 1ms to 2ms pulse (as per spec). This repeats every 20ms to keep the servos refreshed. Even if the data from the xbee stops, the servos hold their last position (or they could default or whatever you wanted)

The Attiny 1634 is a rather capable little chip, it has 16K of flash program memory and 1K of RAM. It also has 256 bytes of eeprom and runs at 8mhz with no external crystal. It is essentially an 8bit ardunio (atmega) in a 20 pin SOIC package. I love it.

So, in theory, you could transmit to the widget a ‘profile’ or a small code routine that would execute to drive a servo based on some local input. Or anything else. There are lots of possibilities. Right now I have the basics running. I can drive the servos from the hand-held thing or from the Raspberry Pi using python. I have it playing sounds, toggling relays and lighting up LEDs. Pretty much all you could want to do.

Thanks Martin, now that completely answers my questions of how you are holding servo position and how the “brains” are distributed.

With the Attiny at each servo, custom code could be in place to do some cool stuff, thinking of uncoupler control right now.

Regards, Greg

Martin: I like the design of your hand held controller that you had 3D printed. would this be something you would sell or make the 3d file available to others to have printed?.

Dan

Well, I was, but I’m not sure I have a file that you can just send to the printer, I went through quite a few test prints and resizes to make it work.

But I can post up the ‘base’ file if you want to play with it- its an OBJ file with all the parts (as groups) still intact. You can use this to boolean out the display and key holes to whatever size you need. All the main parts are mocked up, the xbee widget board, display, keyboard and battery pack (4 AAAs).

I stuck it here:
http://controlwidgets.com/?page_id=261
Handheld3DFile.zip

Some more Widget development, this is the Sparkfun 802.11 module, it’s pin compatible with the Xbee so it drops right in. Have it up and running and a bit of python to open sockets to it- quite a neat little package. My tablet (android) connects to it directly so I’m thinking an app might be fun, drive my battery loco from my tablet. Hmm.

http://martinsant.net/wp-content/uploads/2014/07/802.11Widget.png