I am designing a wireless scoring system. Basically you have two people, if an event is triggered on one person the device must send a status note about that event to the other person's device.
I though about using RF transmitters and receivers. Having a transmitter and a receiver on each device, but the issue is interference, if I have 4 or 5 sets of people using that device in a single room, then there is bound to be interference and I can't guarantee the data to be accurate all the time.
I stumbled upon a Bluetooth wireless transceiver RS232. Looks promising, but I am not familiar with how Bluetooth works and am not sure if I will face similar issues using such system instead.
I wanted to know if I will get interference issues if multiple RS232 modules are sending and receiving data at the same time.
I wanted to know if I will get interference issues if multiple RS232 modules are sending and receiving data at the same time.
Yes.
You need a system that packetises the data and receives a receipt when it is received correctly. If this is not received withing a certain time then it retries. This sounds like a job for an Xbee in mesh mode.
The avoidance of collision through several transmitters operating at once is acheived by network style protocols. The problem is there with whatever RF devices you use.
Bluetooth can choose beteen 100 separate RF channels in the 2.4GHz, band, but of course any transmitter or receiver can only be tuned to one channel at a time. This is why many people can use Bluetooth links in a crowded space such as an office without problems . Each pair chooses a free channel by listening for traffic in the band before 'pairing' . Neat idea.
Your description in your Original Post is not fully clear. You start by talking about a pair of people and then you say "4 or 5 sets of people".
Do you mean 4 or 5 pairs without any need for one pair to communicate with another?
OR
D0 you mean 8 or 10 people all communicating with each other?
For the first scenario (separate pairs) all you need to do is use a different channel (frequency) for each pair.
The other case is more complex because if two or more transmit on the same frequency at the same time all the output will be garbled and lost. A simple solution is to arrange for one device to act as master and poll each of the others in turn. It can both send and receive data when polling. The master program in my link can be extended to poll several slaves.
If polling is not fast enough for your project then I think you will need a very much more complex solution perhaps involving changing channels. From my reading of the TMRh20's documentation his network and mesh systems rely on transmissions being sufficiently infrequent that they rarely collide.
There is a rule of thumb when working with channels that will carry unsynchronized traffic, such as several radios transmitting at random. If your total traffic loading reaches 33% of channel capacity, you will be eaten alive by retries. Keep that in mind when picking bit rates, and traffic volume per radio, and don't forget to include ACK messages. Actually best to stay well below that 33% level.
jrdoner:
There is a rule of thumb when working with channels that will carry unsynchronized traffic, such as several radios transmitting at random. If your total traffic loading reaches 33% of channel capacity, you will be eaten alive by retries. Keep that in mind when picking bit rates, and traffic volume per radio, and don't forget to include ACK messages. Actually best to stay well below that 33% level.
Very interesting. I will keep it in mind.
Do you have any reference for it? I would like to read more.
