I’ve retrofitted one widget and am building another from scratch, both have 18.432Mhz crystals driving the clock instead of the internal resonator for some experimentation and prototyping. Adding a crystal takes two pins but what can you do eh?
I have one running and so far and everything seems a bit tighter, but not dead nuts on like I was looking for. Note the couple of nanoseconds off on the first pulse. Main servo cycle is also 15ms instead of 20ms. Not sure I like that.
I think I’m missing something in the algorithm aspect of the servo drivers so I may refactor it for the third time. The above is a hack, I’m not fond of it but it works.
The big revelation here is that the timers must have some intrinsic slop which you have to compensate for. I found this while fixing the s/w uart so perhaps some servo driver adjustments are prudent.
Speaking of, the s/w serial out is now dead on, I get zero errors out at 4800 baud. So now I have one dedicated h/w serial link to the Xbee, a dedicated h/w serial RX from the RFID reader and a s/w tx to the sound boards. Sweet.
Well, after much poking about, taking scope traces and trying various prototype code, I’ve come to the conclusion that a s/w driven uart to control the sound boards is just not going to work reliably. I’m not sure why, but the timers on the Attiny 1634 seem to be off a bit sometimes. Quite often actually. I noticed some of this on the servo control code, but the servos are more forgiving so they don’t mind much and work fine. At even 4800 baud though, the bits are off by enough to cause the wrong data to be clocked into the sound card- Yuck.
I can use one of the onboard h/w uarts and it’s rock steady but I really didn’t want to do that. One of the h/w uarts is dedicated to the Xbee and the other I use for the RFID reader. It’s a shame the RFID reader wants to run at 9600 and the sound boards wants 4800, otherwise I would be set. However I don’t think there is a way to change either of them so I’m kinda stuck.
Anyhow, I’m guessing it’s because I’m running the chip on the internal clock, so perhaps an external crystal is the ticket. I have a couple of 20mhz xtals around but it looks like the best ‘baud’ friendly crystal is 18.432 which gives 0% error on all the rates. They are a buck from mouser but will consume two pins on the chip. Oh well.
Looks like the best bet is to do a 3.0 design with the crystal and then move all the I/O off to the SPI interface, that way I can control 32 bits of I/O for about $3. This lets me control the sound plus the 915mhz radio for the automatic uncouplers too. Hmm.
I refactored the software for both the master and client nodes over the last few days. I cleaned up some of the prototype code, added some basic structures to lay over the xbee transmit packets and moved things around just a bit. As far as functionality, I can now control three servos and send the RFID tag reading back to the master. If you look closely at the display you can see the raw hex code from a read in the lower left of the display. The ID20 from Sparkfun is a really nice reader, it catches the card passing by very quickly at about 40-50mm.
This also shows some experiments with the Kadee coupler controlled by a servo. Seems to work well, but this is on a bench test setup, not a real locomotive- but I’m optimistic. All I did was drill a very small hole in the ‘tab’ on the coupler. This is a standard Kadee 787 coupler meant for the Aristocraft RS-3. The actuator wire will be replaced by a chain or something more cosmetically pleasing.
The sound cards are the next step. Right now I’m feeding the power from the same bus as the servos so I get a bit of noise mixed into the amp output. I’ll clean that up later, for now all I hear is the servo when it moves, other than that it sounds fine, good enough to get the s/w working.
I’m thinking of how to make the Kadee couplers automatic per car. It’s easy to add them to a locomotive, I’ve allocated two servo controls to my XBee wireless widget controller for that. The tougher part is how to make something that will do individual cars.
Here is what I’ve come up with. It clocks in at about $15 in electronics. Two sub-micro servos for $3, an attiny 1634 at $2 and a WRL-12031 wireless transceiver for $7. That’s $15 per car. Hmm. Still a bit on the high side but if you could have the locomotive be the master and then control each coupler on each car in the consist, you could do some nifty automated switching moves, eh?
I’m getting ready to refactor the software for both the client and master so I decided it would probably be good to shoot a bit of video showing everything working and driving servos before I break it for a while. This shows servos on channel 1 of both clients moving via the knob on the master. There is a bit of dead space on both ends of the knob rotation but other than that it tracks really well. Note that I click the somewhat silly keyboard to select between the two clients. Anyhow, you can see other posts I’ve made of the timings and message passing but I wanted some real world video to show just how well it’s working. So here ya go. Next up is getting the RFID via Xbee and the slave sound card up and running. Almost there. That’s up next.
The two current widgets. The Xbee client is in the upper right hand corner- it sports wireless bidirectional communications following the 802.15.4 protocol. FCC approved, 300 ft range. It controls servos, motor controls, discrete outputs- lights, solenoids. Also has a serial input for an RFID reader. Additional inputs are available for current sensors or distance/speed sensors. This is my locomotive Frankenstein. I am really happy how this has turned out. I’m working on a set of simple PCBs so all of this can be just soldered in. (soldered and wired breadboards are a pain sometimes)
In the center is the sound widget. Up to 200 stereo mp3 files can be triggered from R/C inputs or discrete buttons presses or switches. You can put ridiculously large SD cards into it. Like 32G of sounds. You can trigger music, sound efx, whatever you want. A 1 watt amplifier is onboard- more than enough to drive a large speaker.
Finished up another client, I can now control two from the handheld, just push one of the keyboard buttons to change to the next locomotive (Xbee Address). Point to multipoint. I like it. I also got the RFID reader working, quite nice. Super simple interface. This is the ID20LA from Sparkfun. I’m using the big thin credit card sized tags and they work really well, even at speed. Put a reader on the locomotive and embed the tags under the track and I think this will work great.
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.