# Multiple transmitters using same frequency

in our wireless network we have a variable count of devices. Each device contains one transmitter and receiver. Both receiver and transmitter are working on the same frequency, 433 MHz.

To keep the price as low as possible, we are not able to buy more expensive modules which support frequency changes. Thus we have to create kind of time separating mechanism to prevent transmitters to “jam” each other.

The problem is you never know the device cound, and each device doesn't have the same ID each time it is connected to the network – it is set by the owner of the device. Therefore we can not assign the transmission time like $\text{ID} \times ( \text{time between each transmission} + \text{time of transmission} )$.

Is there a way to determine device count and assign them unique IDs and transmission time?

There are some things to consider before choosing a mechanism. They include:

• What is the duty cycle of each transmitter and what is the combined duty cycle? How does (average transmit duration for one radio per hour) * (number of radio) compare to one hour?
• Do all the radios have a similar transmit duration per hour?
• How often do radios join or leave the net?
• Is the number of radios in the net constant, or nearly constant? The question does state "we have variable count of devices".

Assigning fixed slots will be difficult in a net where the number of members keeps changing. It may need frequent reassigning or there may be many slots where no member transmits. Thus wasting bandwidth and possibly slowing down message transmission while a transmitter wait for their slot.

If the overall bandwidth required is low then it may be better to go for "Carrier Sense Multiple Access" CSMA or "CSMA with Collision Detection" CSMA/CD networks. These are designed for networks where the membership varies over time.

CSMA type networks work well when the total amount of messages (ie data) is low compared to the maximum capacity, ie when the number of collisions is relatively low. As the amount of data to be transmitted increases the number of collisions increases. At some point the network may become overloaded and the actual throughput decrease.

Designs for these kinds of network must also consider:

• How to handle the detection and possible retransmission of messages that are garbled (corrupted) due to a collision.
• What happens if a transmitter fails and is continuously transmitting.
• Devices will be allowed to leave or join only at defined circumstances. Otherwise, the device count should be constant. At this point, I would say, collisions will be the problem. Many messages will probably be sent in just a second. CSMA does not seems to be the answer. In additional, on another forum I asked this question, they suggested to use 2,4Ghz modules instead those 433Mhz. In that case, listening wouldn't probably help us due to transmission speed. – Lorin Feb 10 '15 at 15:10

You need a protocol. Theres no easy way around this without a protocol.

By protocol i mean, each radio needs to be at least half-duplex, and negotiate that information on the fly.

If you are going all this long to have a network, you might very well use WiFi modules and have everything solved for you automatically.

• What exactly do you mean by protocol? Design packets, what to do on successful transmission, unsuccessful one etc.? Those 433Mhz modules does not support more than one frequency, which half-duplex requires. This could be solved by using better 2,4Ghz modules. Wifi modules support just a small amount of connected devices (up to 32?), which is not enough for us. We would like to build expandable network with "almost" unlimited devices count. – Lorin Feb 10 '15 at 15:16
• @Lorin A protocol describes how the various radios communicate, including: message content, message sequencing, joining/leaving the net, retries after errors, etc. See en.wikipedia.org/wiki/… for a better list. A wifi mesh may be suitable for you, see en.wikipedia.org/wiki/Wireless_mesh_network . See also en.wikipedia.org/wiki/Category:Wireless_networking for many other options. – AdrianHHH Feb 11 '15 at 9:18
• You say that wifi modules support only 32 nodes (this is by no way correct) but, your current solution (433mhz modules) cannot solve that either (you dont have a protocol yet). So, whats better 32 or a single transmitter (even if the 32 limit was right) ? – Jorge Aldo Feb 11 '15 at 21:28

Is there a way to determine device count, assign them unique IDs and transmission time?

You could have them all communicate and negotiate this information. That's complex, though. It's more of a computer science problem than a radio one. The issue is that all the nodes have to agree on what their respective slots are, or agree on a leader which will arbitrate channel access. This is a classic distributed consensus problem, and while it seems simple it's not. What happens, for example, when a node can't hear the leader? Does it then become the leader or elect a new one? What if the former leader is still around, but propagation conditions have changed so just some of the nodes can't hear it? Then you end up with two leaders which each think they are the only one, leading to collisions.

Consequently, some protocols eliminate the consensus problem by making those decisions static. For example, each node is configured to acknowledge one leader, and if the leader isn't available, then the node just doesn't work. Maybe this is acceptable for you, but by the nature of your question I'm guessing not.

Alternately, you can just each transmitter listen before transmitting, and not transmit until the channel seems clear. This is called carrier sense multiple access, or CSMA. It is the method used by Wi-Fi and amateur radio packet. You can still try to reduce collisions through some leader arbitration, as long as you acknowledge that collisions may still occur, due largely to the consensus problem as before. For an example, see 802.11's RTS/CTS protocol.

• I was thinking about "listening" before transmitting too. But this could lead to multiple transmitters starting transmit at time. But it seems it's only choice. Later on, after counting, main device could assing transmitting time to avoid this problem. – Lorin Feb 8 '15 at 12:43