Theoretically I think about a possible collusion problem when using multiple transmitter modules. If we use several transmitter and receivers in a site, when transmitters sending messages, receivers which is in range of multiple transmitters easily get confused.
At the illustration below, one receiver is in range of two transmitter:
That is a major issue with any RF communication. How do you prevent two transmitters from transmitting at the same time?
In most data communications the use of checksums and ACKs are used to ensure the data was properly received. Also most systems listen before transmitting and then add a random time delay before transmitting. This requires each node to have both transmit and receive capability.
In your system this is not possible since the transmitter nodes have no way of knowing if the data was received. Also your RF modules are very basic ‘dumb’ units. So all verifying of data is done in software. An ‘address’ or network ID can be included with a data packet some a receiver can reject data from the ‘wrong’ transmitter.
If both transmitters come on during data transmission then the data gets trashed and there isn’t a way for the transmitter to know to resend the data. The data could be sent multiple times with a ‘packet ID’. This would be a redundant transmission protocol and can work if the bandwidth utilization is normally low but it is still not a 100% guarantee that the data was correctly received.
Another way is to have to two systems on different frequencies, 433 MHz and 413MHz may work if the receivers are selective enough to reject the other transmitter. If they are not then the frequencies need to be farther apart.
The best solution is using RF modules with all of the physical and MAC layers built in that take care of collusion detection, acknowledgments and retransmissions. And that can be set-up as separate networks. For low data rate ZigBee and 802.15.4 come to mind.
Another is to ensure that a receiver can only ‘hear’ the correct transmitter. Directional antennas can help accomplish this goal.
Theoretically I think about a possible collusion problem when using multiple transmitter modules. If we use several transmitter and receivers in a site, when transmitters sending messages, receivers which is in range of multiple transmitters easily get confused.
At the illustration below, one receiver is in range of two transmitter:
Although messages can be addressed by software, The hardware will have interference with each other. Is it correct? How to avoid such an interference?
Collision avoidance in wireless (or wired) packet data systems is a basic requirement. It’s one of the key functions of the MAC layer protocol. The interference can come from your own nodes competing for air-time (intra-system) and from other transmitters using other modulation methods, since you are in the unlicensed spectrum.
Read up on 802.15.4 “Clear Channel Assessment (CCA)” and the back-off algorithm. This is an implmentation of Carrier Sense, Multiple Access with Collision Avoidance (CSMA/CA). You’ll see CSMA/CA in 802.11 WiFi and other wireless.
Since you aren’t using a chip/module with IEEE 802.15.4, where the MAC protocol with CCA is included free, you have to roll your own. Ouch.
this was among top results for ‘rf communication multiple transmitters one receiver’
i have been putting off a (in my opinion ‘highly desirable’) project for far too long and was mainly lamenting the complexity of creating a zigbee mesh with a master unit and multiple slaves and contemplating/fearing that it would involve custom software development (on a laptop connected to the ‘master’ unit via usb) to evaluate values being sent by multiple sensors… and then i came across these RF units.
i DO enjoy inventing protocols and the suggestion to send along a ‘node id’ in the each transmitter’s data packet is exactly in line with what i was just brainstorming at this very moment.
basically your central receiver unit would go round-robin checking for data coming in on its data line, check the byte’s ‘node id’ and if it matches a counter (initially ‘0’ for ‘node 0’), read the byte, else wait until some timeout and try again, if the timeout expires, increment the counter and when checking the data line, see if it’s from ‘node 1’, and if so, read the byte, etc.
it’s entirely lossy but for sensor networks that’s ok, there’s always more environmental data on its way.
you could also just keep reading the data line without waiting for a particular node to ‘chime in’ but in so doing a race condition might happen where one node has a tendency to keep the receiver’s data latch busy more often than the other transmitters…
as for protocol of the data packet being set by the transmitters the simplest that comes to mind is an 8 bit payload, where some number of most significant bits is the node id and the rest is the data – so if you reserve the upper 2 bits for the id, then you can have sensors transmitting 6 bit information (not bad resolution actually)…
with that ^ you could have 4 transmitters sending a 6 bit value to a 2400bps receiver, and potentially be getting 75 sensor-value reports per second (again, not too shabby).
rekall:
i have been putting off a (in my opinion ‘highly desirable’) project for far too long and was mainly lamenting the complexity of creating a zigbee mesh
Apologies if you know this already… You need ZigBee as the network layer only if you need meshing (hopping/relays). Peer to peer is the simplest, easiest- no coordinator, just set destination address and transmit. Or send to broadcast address.
