On 15 Apr 2004 at 11:40, Edson Brusque wrote: > I'm testing some transmiters and receivers modules (315MHz e > 434MHz) from Keymark (www.keymark.com.tw). Transmiters are TXC1-0315 > and TXC1-0434. Receivers are RXD1-0315 and RXD1-0434. > > What I'm founding strange is that the receivers output random > noise > when the transmiter is OFF (or ON with data pin low). > > This is ok? Am I doin something wrong? Yes this is normal. No, you are not doing anything wrong. And yes, there is lots of info on the PIClist already. This type of encoded is called OOK (On Off Keying). Carrier on for one logic state, carrier off for the other. When no carrier is present the receiver AGC (Automatic Gain Control) ramps up the "volume" trying to "listen" for a signal. The discriminator circuit that outputs the digital 1's and 0's is usually a simple comparator, the threshold of which follows the average level of the received level. When a constant string of data is being sent AND the received signal to the noise ratio is high AND the data is fairly well "DC balanced" (even number of 1's and 0's) it all works very nicely. From the above description of the discriminator and AGC you can probably see what can happen to make things go wrong. If the data is not DC balanced the discriminator threshold shifts to the point where noise starts getting discriminated and the data is corrupted. If the received signal is weak (or there is no signal) the AGC ramps up and so noise starts getting discriminated again. There are obviously response times for the above mentioned circuits. These should be on the spec sheet for the receiver module you are using, and likewise it should specify a nominal data rate for best performance. The problem you are faced with is how to determine the start of a valid data transmission. The first thing you can do, following a period of no data transmission, is to send a "preamble". This is a burst of transmission that gets the receiver AGC and discriminator settled down, locked on, tuned in, etc. The preamble therefore needs to be DC balanced (eg, 0x55 or 0xAA characters..check them out in binary) and long enough to suit the receiver response time. The output of the receiver will be noisy at the start of the preamble, but should be good by the end of it. Your micro needs to ignore the preamble. Next problem...syncing the UART (assuming that is what you are using a UART for receiving data, and that you are sending data in bytes). There are lots of other methods, but I'll just mention one. If your first data byte immediately followed the preamble there is no guarantee the UART was waiting at the expected time for the start bit. By the end of the preamble the UART is only seeing a continuous stream of alternating 1's and 0's, and will most likely be getting a lot of framing errors. The preamble gets the receiver settled, a Sync character or sequence is needed to get the UART settled. A suggested Sync sequence to send is 2 bytes of 0x0F (0b00001111). See how it works? A start bit is a 0, then there are 8 bits of data, and the end bit is a stop. So the UART sees 0000011111. Do that a couple of times and there is no way the UART can miss the next Start bit. In some cases four or 5 consecutive 1's or 0's is too long and can upset the discriminator, but for the case of describing the process I think this is the best value to use. Then you send the data. Make sure there is an even number of 1's and 0's as already mentioned, and likewise no long series of consecutive 1's or 0's that will cause un acceptable DC shift in the discriminator threshold. I'll leave you to do your own research on how to do it...this email is getting too long. Then you will need a checksum or CRC, because you need to be able to detect if the data has been received OK or has been corrupted. Sorry for such a long winded response...hope it helps a bit (or should that be byte). -- Brent Brown, Electronic Design Solutions 16 English Street, Hamilton, New Zealand Ph/fax: +64 7 849 0069 Mobile/txt: 025 334 069 eMail: brent.brown@clear.net.nz -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu