Q:

How to avoid interference in wireless communication?

I am working on wireless communication system. We are using around 10 pairs of transmitter and receivers. We are using atmega16 microcontroller for encoding and decoding by USART ports.
Now we are able to transmit the data and receive the same in the receiver end, but there is a major problem, when we are finding the 2 transmitter data coming at the same time. The receiver is unable to get it due to interference.
Suppose one transmitter sends "SENDA" at the meanwhile another transmitter sends "GETTS", at that time the receiver can not receive proper data. As all the transmitters and receivers are working in same frequency, so this interference is occurring. How can I resolve this issue?

A:

Developing a workable RF communications protocol is apt to be a tricky but educational exercise.  A few additional points to consider beyond what's been said:

On some radio hardware, it takes a lot of power to listen for a signal.  With many if not most small radios, listening for a second is going to take more energy than transmitting for a millisecond; on some radios, listening for a millisecond may take more energy than transmitting for a millisecond.  If current consumption is not an issue, listening continuously is a lot simpler than listening intermittently; if current consumption is an issue, however, it may be necessary to listen intermittently.  Probably not a good idea until you've managed to get something going with a continuous-listen protocol.
Listen-before-transmit may be "polite", but it's nowhere near as useful with RF as with e.g. an Ethernet cable.  Ethernet signalling is designed so that not only is it likely that a device which listens before transmitting will usually avoid a collision, but it's also designed so that a device whose transmission collides with that of another device is virtually guaranteed to notice.  RF transmission offers no such promise.  It's entirely possible that when P wants to transmit to Q, some other device X which is closer to Q than to P will be transmitting loud enough to prevent Q from hearing P's transmission, but not loud enough for P to notice.  The only way P will know that Q might not have received his transmission is by the fact that P won't hear a response from Q. 
It's important to beware the consensus problem--much moreso with RF than with wire signalling.  If a P sends to Q, it's possible that Q will hear P's transmission and send an acknowledgment, but P will for various reasons not hear that acknowledgment.  It's thus necessary to be very careful to distinguish retransmissions from "new" transmissions.
The consensus problem can be especially vexing if one is trying to save energy by powering down receivers when they're not needed.  Suppose two P and Q are supposed to communicate once every 10 seconds, so they power up and P sends Q a packet.  Q receives the packet, sends his acknowledgment, and--knowing that P won't be sending anything for almost ten seconds, powers down.  If P doesn't get Q's acknowledgment, he'll retransmit; since Q is asleep, however, he won't hear P's retransmission.  From Q's perspective, that wouldn't matter (he's already received his data), but it means no matter how many times P retries, he'll have no way of knowing Q got his packet (at least not until the next rendezvous in about ten seconds).
It's entirely possible to have a situation in which node Q will be able to receive transmissions from P, but P will not be able to receive transmissions from Q.  It may not be possible to usefully communicate in such scenarios, but one should at least endeavor to avoid doing anything obnoxious (like having P endlessly retry a transmission hundreds of retries per second)

As said, a workable RF communications protocol is apt to be a tricky exercise.  Still, I'd expect you'll probably learn a lot from the experience.

A:

If you're not using a standard protocol for this then you're going to have to design and implement one, e.g. a simple example:

before transmitting, a node should listen to check that the channel is free
if after transmitting a message no acknowledgement is received, the node should wait a random period of time and then try again, up a some maximum number of retries

So what happens is that you first try to avoid "jamming" by listening first, then if a jam still does occur you detect this via a lack of acknowledgment from the receiving node and then try again after a random delay - the two jamming transmitters will use different random delays, minimising the chance of a second collision.

A:

Here are two common options
1) Implement a Listen Before Talk (LBT) algorithm, which checks if there is transmission in progress before starting your own, and if so, backs off for a period of time. The period should contain a fixed length and a random length so that they don't all back off for the same period. Many standard radio protocols include this procedure, see ETSI EN 300-220-1.
2) Implement a beacon system where the transmissions are timed from the beacon. Each transmitter gets its own timing slot. You would normally use serial numbers in the devices to determine their slot, and have a system for determining who sends the beacon. Since this relies on all the transmitters having a different slot, it is not a good idea to leave it to the user to uniquely identify all the transmitters, unless you have a solid procedure for this.

