Ahh cool test application kurt, I will have to try it when I get my hands on another Teensy board.
Personally I know you love the Xbee's as much MUCH more data can be transmitted to the device on the end, however for the average person who wants to have an inexpensive RC solution Xbee's are kinda spendy.
I mean take a look at the Turnigy 9X receiver/transmitter.. the thing is fully hackable and has open source code for your TX its completely fantastic... OK back onto the idea.
When the 1.3 phoenix code came out originally, someone made a comment that the CPU was quite saturated and not much excess CPU was available for any other processing, such as myself adding in 7 pulsin() commands to use my T7C. Caused all sorts of wobbles and affected the gait when it walked... looked bad... however it worked.
the 2.0 code came out that used lookup tables which I have yet to use RC control on using the simple Pulsin() commands... you think it will just work?
I think what needs to be made is something like this https://store.diydrones.com/product_p/br-ppme.htm
however rather then outputting PPM signal outputting something like formatted serial strings
1500,1500,1500,1500,1500,1500,1500 .... which is what my first piece of code did for the arduino... not actually knowing C++ I was quite impressed on how easy it was to make... It does not use ... Ill just call them FANCY Interrupts! due to the fact that I do not know how to code them, even from looking at your example code....
I have had the idea in this topic for a couple years now as RC control really wasn't something that a lot of people did... and I really couldn't figure out why..maybe it was too difficult? or hard to use?
I want to expand on the idea for something possibly better... this is the basic theory...
Separate processor such as the diydrone,teensy something small and simple code like pulsin() however, I want to see about adding an eeprom into the mix. I want this device to read the channels as fast as it can possible run which is around 50hz or 60hz?... then when you connect this to your other CPU on your bot, that when it polls the control board it can instantly retrieve its value and continue one, rather then waiting until the cpu thats reading the RC channels is done with a complete pass.
I believe Kurt can fill me in on this, but if you just use pulsin() in an arduino, the command exits once the pulse has made a complete pass.. If you read the channels in order there shouldn't be a need to use inturupts right?
On a side note,
what about creating an environment that allows you to take sensors of all kinds and output data like an RC reciever outputs 1000-2000 value.. such as a ping sensor, or a gyro, or an accelerometer.
One Idea that I have had floating around a while was to attach a gyro to the top of the pheonix and as I walked it up a hill the body would self level.. I think thats tessellation mode..
By the way, that maple board is pretty slick.