MarkF
Senior Heliman
Location: Palo Alto, CA
| Hi, Gang!
Everyone: Thank you very much for the great encouragement - that's very cool of you! This probably is kind of a nutty project, but it's nice to know that I'm not alone! 
Angelos: Congratulations on pulling this off - great job! I hadn't heard about your efforts previously, so I just dove in! Hmmm, since you've already made such great progress, maybe I ought to shift the emphasis of my project to the next-generation QPSK [Quadrature Phase Shift Keying] setup. The biggest problem is that this requires that the RF [Radio Frequency] strips change from a simple "hard" digital encoding to a linear encoding (consequently, the receiver doesn't use a data slicer). With good linear response, all we need is a D/A [Digital/Analog] converter on the transmitter, and an A/D [Analog/Digital] converter on the receiver. Modulating and demodulating QPSK is quite straightforward.
As it turns out, the Philips chip I'm using is actually a good choice for both the transmitter and the receiver, with up to 128KB FLASH ROM [FLASH ROM is rewriteable "Read Only Memory"] and 64K RAM on the LPC2106 chip, plus a solid 60 MHz core (plus a 256-bit FLASH prefetcher that delivers 0-wait state code access). The only thing that would be a slight pain for the transmitter application is that this chip doesn't have lots of on-chip A/Ds for reading the pots, so it'd be necessary to add on an external multichannel A/D converter.
So, while I won't promise anything yet, if we're going to consider tackling the RF section, we might as well get a significant benefit out of it, and QPSK would be a BIG benefit!
Sharam: Thanks for the idea! As it turns out, I've already got two features that will help the receiver from being fooled by interference, including a special preamble, and a two-byte CRC [Cyclic Redundancy Check] that will prevent a frame from being acted upon if any bits are received in error.
Your suggestion to include a unique ID would definitely work, but I'm not sure that it would accomplish what you would like it to. Since RF signals mix together, the only real benefit this would offer would be to prevent someone else from taking off with your model, if your receiver was turned on, but your transmitter was turned off! If both transmitters are on, the preamble and CRC checks will force a hold condition, and if the errors continue, eventually failsafe will kick in. Note that if transmission weren't continuous, your idea could offer a significant benefit, but to reduce latency, each transmitter will essentially transmit continuously. Good idea, though!
RC-Cam: Thanks for the excellent pointers! As I mentioned earlier, the key difference with QPSK is that it needs nice linear phase response on both the transmitter and the receiver's RF strips, but maybe I'll experiment with tapping into commercial RF modules to see if any of them can hack it!
Starting Up
Wow - that was fast! As it turns out, Nohau's located not far from me, and I received the target board, the in-circuit debugger, and the C-compilers the day after I ordered them!
Everything looks OK, with the exception of the Hitech C Compiler and IDE [Integrated Development Environment] - for some reason, they're locking up hard on my system. Fortunately, Nohau provided TWO different 16KB-limited C compilers, and the second is by a company called IAR, which is running fine. At least we are able to load, execute, and debug code!
Proposed PCM Format
Particularly since Angelos has already reverse engineered the Futaba PCM format, I'm thinking more about the 16-channel format I'd mentioned above. The encoding I'll probably start with would be a very basic differentially encoded format that's conceptually similar to the Futaba format described earlier. It would include a (length to be determined) preamble, followed by nine 10-bit words, as follows:- The Control Word would be bit mapped, with Bit 9 indicating a Failsafe frame if high/Normal frame if low, Bit 8 would indicate an Odd Frame if high/Even frame if low, and bits 0..7 would be the switch channels.
- During an even frame, the next four words would contain absolute values for analog channels 1-4. During an odd frame, these words would contain the absolute values for analog channels 5-8.
- During an even frame, the next two words would contain four 5-bit differentially encoded values for channels 5-8, and during an odd frame, it would contain differential values for channels 1-4. With linear encoding, this would only offer the ability for alternate frames to encode a position value of +/-15, so I'll probably encode the differential values with the equivalent of an ~exponential function, allowing faster response to large control changes.As one possible example, the values could be encoded as something like 0, +/- 1, 2, 3, 4, 5, 6, 8, 16, 32, 48, 80, 128, 208, 336, 544.
- The last two words would be the Cyclic Redundancy Code that detects bit errors.
During Failsafe frames, the Failsafe values would be encoded in the absolute value words, and the hold/set state for each value would be encoded in the switch bits. I'm still thinking about what we might put in the differential fields during Failsafe frames, but it might well be a set of four possible endpoints for each On/Off switch state, allowing "analog" control values to be sent from the "digital" switches.
Well, that's where we are today! Thanks again, everyone, for the encouragement! 
Have Fun!
MarkF |
