Zachary Noyes wrote: > > > In this way all that you need to encode a number in a radio signal is > two pulses, Actually one pulse according to your description. It looked like you were encoding information in the width of each carrier burst. > rather than log2(n) number of bits (encoded in a > modulation which requires a DSP to decompose), where "n" is the > maximum value of the information. The info can be directly read by > the PIC. > > Is this feasable, impossible, already done, missing a piece. Yes, no, of course, perhaps. I haven't looked at them in detail, but I think the RF signals for RC hobby servos use exactly this scheme. This was all designed before anyone could possibly put a computer at the receiving end. The pulse width was used by a analog servo circuit to control the position of the motor. In this case, the fact that this method has no guaranteed delivery, no error detection, and low accuracy is partly irrelevant and partly made up for with redundancy. A new value is sent about every 20mS, so if one gets glitched it won't have too much effect overall. This kind of scheme works OK for transmitting single analog values where close enough is close enough. It doesn't work well for transmitting discrete digital information, like a credit card number. There you have to get the right number. Being off by 1 isn't close enough. Another drawback is lack of error detection. RF is always a noisy channel. You should never assume any one packet makes it intact to the receiver. In the case of discrete digital information, it is often important to know that it was received correctly. For example, if you send a credit card number you have to assume sometimes it sometimes gets garbled. In those cases it's much better to know you didn't get anything usable and to ignore the whole packet than to use the wrong credit card number. This is usually handled by wrapping chunks of information in packets and adding a digital checksum to each packet. (Credit card numbers actually contain some error detection themselves, but that's not relevant to this discussion). Although you say this scheme is more efficient than sending the information digitally, it's actually not for most cases. There will always be some jitter on received demodulated edges due to channel noise. For sake of simplicity, let's say that every edge is randomly received somewhere within a 1 time unit window. The uncertainty of a received carrier pulse width is therefore 2 time units (one for each edge). Let's say you wanted to transmit a bunch of randomly chosen values with 8 bits resolution (1 part in 256). The maximum pulse width would need to be 512 time units for the receiver to be able to distinguish 256 levels. If these are randomly chosen values, then the carrier will be on for 256 time units per value on average. Now let's compare this to a digital scheme, like manchester encoding. One way of looking at manchester encoding is that data is sent in carrier bursts (and gaps) of 1/2 bit or 1 bit time in length. Since we have a +-2 time unit error on measuring the width of any pulse or gap, we need the pulses to be 4 and 8 time units long to be able to distinguish between a long and a short in the receiver. This make each manchester bit 8 time units long. Since we are transmitting a 8 bit value, that requires 64 time units. The carrier is on for 1/2 the time each bit, or 32 time units for a 8 bit value. Even if we use twice that by adding a preamble for synchronization, we're still at 1/4 the carrier time for sending just a 8 bit value compared to the analog approach. For transmitting N bits of information, the analog scheme requires transmitter power proportional to 2**N whereas for digital encoding it's proportional to N. As you can see, even for a low value like N=8 the digital scheme is already 4x more efficient. Of course both schemes aren't equal and have different properties. The analog scheme fails gracefully if you are transmitting a analog value. The digital scheme allows for means of knowing the data was received exactly correct within some confidence probability, such as by adding a checksum. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist