After all the work to get things really fast, now I’m going really fast but not very often. I’m taking a snapshot of the ADC knob (throttle) and if it’s close to the last time I read it, I don’t send out any RF update. This results in a LOT of silence on the network, more than enough time for other packets to bounce around as the complexity of the network develops. This is really working VERY well so far, simple circuits, stick to standards and minimalistic coding practices. As Jessie Pinkman would say, it’s SCIENCE BITCH!
Ok, more tweaking gets us to 10ms per xbee data packet. Well, per cycle, each packet is about 7ms long, a total of 25 bytes with 16 bytes as the actual data payload. This leaves about 3ms of ‘I completely ain’t got nothing to do’ idle time. Sweet.
This sort of update gives a really smooth servo movement from the knob on the master to the client. I’m thinking I’m approaching the limit of what I can do at 8mhz. Or close. I’ve tried to go faster but get nothing. According to the data sheet, if I go above 38.4k and don’t set the ‘double’ bit, the error is over 2% which won’t fly. If I do set the double speed bit I think I can crank it one more notch to 76.8k and get a 0.2 % error which is quite good. Any of the other, higher baud rates are going to require a crystal at a ‘baud friendly’ frequency or a tweak to the fuzes to get the internal clock lower, neither option I want to do right now.
Anyhow, this rate gives two complete data updates per servo cycle, that means I can get a smooth throttle control for a two locomotive consist depending on how I do it. You could either send both locomotives individual packets from the hand held, or have the ‘master’ locomotive send a ‘slave’ packet to the other on the consist. That will be some interesting R&D there.
I’d would like to get this faster, to take it to the limit of the over the air rate (250kbs), but I’m pretty sure it will take a hardware change for even half that. Also, I’m not sure the Xbee will handle above 115.2K on it’s UART so I’ll leave that for phase 2.
This is the base circuit I’m using for all my designs these days. Ridiculously simple. The TX ports at the top of the chip can be used to export debug information to a TTL serial port or control/read other peripherials (wireless, sound etc).
You have the choice of C or C++ as far as a programming language goes. Personally, I favor vanilla C, it’s easier and I think, faster.
Anyhow, the Attiny 1634 is a SOIC surface mount chip, you can use a ‘schmart board’ available at your local Radio Shack, or you can order a 20pin version from Sparkfun Electronics to make breadboarding easier. I’ve uploaded the data sheet for this microcontroller to my site, you can find it HERE
Ok, as you can see, I’m into minimalistic designs. This is a super simple circuit, you can have this up and running including the Pololu USB programmer and full development software for, uh, $30 or so. Yes, you will have to do some soldering but it’s well worth it.
Programmed correctly this chip will drive servos, motor controllers, ESCs, lights and other loads. And (again) with the right software, it can also read servo pulses from a standard R/C rx and let you do things with that. Move the stick or knob on your RC transmitter to set lights, trigger sounds, etc.
I also have hooked it up to an XBee 802.15.4 real time radio module. (Super tiny and it’s $20) to do wireless up to 300 ft. So you can do that too. You can also connect an RFID reader, or perhaps a current sensor and a speed indicator. There is a tremendous potential with this chip. 16K of programming space, 1K of RAM, 256 bytes of EEPROM and two full speed serial ports. Freaks me out personally, your mileage may vary 🙂
After two designs, I finally have the servos working. I can drive pretty much any number of them, I’ve got four going here. Currently the plan for the ‘client’ node is four servos, four mosfet switches, a serial port for intercepting RFID and a transmit only serial port (in s/w) to drive two channels of mp3 sound. There will also be two input pins left over for a current sensor and a speed/distance counter.
I have the transmitter/hand held prototype sending values read from the knob to the client and out to the servos now. Nothing fancy, read, transmit, repeat every 10ms and all the servos are sent the same value, but it does work well.
Still a bit of R&D, I’m not sure on the speed of the transmit to the Xbee module, currently it’s 9600 baud, I may have to increase that, but that’s not a real problem. I think other than that, most of my h/w design is working and has the appropriate low level support.
Have everything in terms of h/w working now. Just getting started on the UART drivers and then the formatting methods to build xbee frames. I’m going for the super simple series one point to point protocol. Technically this is not a ‘mesh’ network but for my purposes, it should do fine. The idea is to have any node talk to any other node directly. I don’t really need any sort of node hopping or self healing right now so I’ll opt for the simple first.
The handheld will function just like a standard R/C transmitter, moving servos and the motor controller in the locomotive. It will also be able to set various switches and relays and trigger sounds.
The big difference here between regular R/C and this- with this method I can do bi-directional data flows. So I can pick up position, speed and current consumption from the locomotive as well as send it commands. Also, since each device is a just another node on the network, an Xbee connected to my Raspberry Pi server will allow me to both control the locomotive and monitor it, the same as from the handheld.
In theory of course. However it is looking good so far. My h/w designs have proved both minimalistic and functional, so far anyhow, so I have a good feeling about getting all this working. The last stage will be the html5 tablet interface I did for the wixel, but that’s way down the road.