Short answer: when two ordinary RF remotes transmit on the same frequency at the same time, the receiver may decode one packet, reject both, or briefly follow the stronger signal. What it should never do is rely on radio collision itself to decide which operator is in charge. Priority, conflicting commands, and stop behavior have to be designed into the control system.
This question usually comes up after a system has already worked well with one transmitter. A second operator is added, both remotes are paired to the same receiver, and somebody asks: “What happens if we press at the same time?” It sounds like a radio question. In practice, the harder part is control ownership.
I have seen more trouble from two perfectly valid commands arriving one after another than from a true over-the-air collision. One operator presses OPEN while another presses CLOSE. Both packets decode correctly. The receiver has done its job, but the machine still needs a sensible answer.
What an RF collision actually looks like
Most low-cost 315 MHz and 433 MHz keyfob systems are one-way. The transmitter sends a short coded burst, often several times for reliability, and the receiver checks whether a valid learned address and command are present.
If two transmitters overlap, their modulated signals combine at the receiver input. With simple ASK or OOK systems, the resulting waveform may no longer match either code. A well-designed decoder rejects the damaged frame and waits for a clean repeat. If one signal is much stronger at the antenna, the receiver may capture and decode that transmitter while ignoring the weaker one.
That means there is no single universal result:
Both frames may be rejected.
The nearer or stronger transmitter may be decoded.
One packet may finish cleanly after the other transmitter stops.
Repeated bursts may alternate, so valid commands from both users reach the controller.
Distance alone does not determine the winner. Antenna orientation, a metal enclosure, body shielding, reflections, battery voltage, and exact packet timing all matter. If a system appears to “always choose Remote A” on the bench, do not treat that as a priority feature. Move the operators and the result can change.
Three problems that are often called interference
When troubleshooting, I separate the following cases before touching the antenna.
1. A real simultaneous transmission
Both remotes are actively sending and the packets overlap. The symptom is usually a missed or delayed response, not a stable wrong action. Once one transmitter stops, the next clean packet should be decoded.
2. Two valid commands in quick succession
This is common with gates, motors, hoists, and multi-zone equipment. OPEN is received correctly, then CLOSE is received correctly 80 milliseconds later. There may be no RF error at all. The application logic must reject, stop, queue, or arbitrate the conflict.
3. A continuously transmitting or damaged remote
A stuck button, wet keypad, damaged switch, or poor battery connection can keep a transmitter on the air. It may occupy enough airtime to reduce the success rate of every other remote. When all receivers in one area become unreliable at once, I check for a stuck local transmitter before replacing receivers.
Decide who owns the machine
Before choosing a receiver with memory for ten, fifty, or five hundred remotes, decide whether those users are allowed to control the load concurrently. “The receiver can learn 50 transmitters” only describes storage capacity. It says nothing about safe multi-operator behavior.
There are several workable ownership models.
First operator holds control
The first valid press-and-hold command takes ownership. Other motion commands are ignored until the first operator releases the button and a short neutral time has passed. This works well where one person should complete a movement without another person taking over halfway through.
Last valid command wins
This is easy to implement and often acceptable for lighting or non-hazardous loads. I avoid it for reversing motion unless the controller stops first, applies a defined dead time, and verifies that the opposing output is off before changing direction.
Any conflict causes a stop
For machinery, this is frequently the most defensible rule. If UP and DOWN, OPEN and CLOSE, or FORWARD and REVERSE are requested at the same time or within a defined conflict window, remove both run commands. The operators must release and issue a fresh command.
One master and several limited remotes
A supervisor transmitter or local selector enables the system, while operator remotes control only assigned functions or zones. This reduces accidental cross-control, especially in workshops with several similar machines.
Give STOP special treatment
For ordinary process control, a valid stop command should normally override a run command. The controller should not make STOP wait for the current operator’s ownership timer to expire.
However, a radio STOP button is not automatically an emergency stop. A low-cost one-way transmitter cannot guarantee that the stop packet arrives during interference, a dead battery, or receiver failure. If the risk assessment requires an emergency stop, use the appropriate hardwired or safety-rated system and design it to remove hazardous energy independently of the standard RF link.
A practical control order is:
Hardwired safety chain open: remove all motion commands.
Valid stop request: remove all motion commands.
Conflicting direction requests: stop and require neutral.
Single valid motion request: run only if limits and interlocks permit it.
Missing command or timeout: return to the defined safe state.
Writing this order down during design prevents a surprising number of arguments during commissioning.
Do not solve a control problem only with different frequencies
Putting one remote on 315 MHz and another on 433 MHz can separate two radio links, but it does not by itself prevent both receivers from energizing opposing machine inputs. If those outputs meet at the same motor controller, the conflict still exists.
Different frequencies or channels are useful when independent systems operate close together and airtime is busy. Addressing and pairing are useful for ensuring that the correct receiver accepts a code. Neither replaces output interlocking, operator priority, or a stop strategy.
For several machines in one area, I normally combine three layers:
Unique addressing: each transmitter is learned only by the intended receiver or zone.
Clear human identification: remote labels, colors, machine numbers, or guarded function keys make mistakes less likely.
Local machine interlocks: even a valid but inappropriate RF command cannot bypass limits, guards, or opposing-direction lockout.
Repeated packets need careful application logic
Keyfob transmitters usually repeat while a button is held. Repetition improves the chance that at least one clean packet arrives after a collision, but the receiving application must understand that twenty decoded frames can represent one physical press.
For momentary movement, repeated valid frames can maintain the run request until a short timeout occurs. For toggle functions, the application should change state once per deliberate press, not once per decoded frame. A release requirement, sequence counter, or properly chosen debounce window prevents a held button from switching the output on and off repeatedly.
Do not make the debounce window so long that it hides a genuine stop or direction change. I prefer separate rules for motion, toggle, and stop commands instead of one timing value applied to every button.
When the job needs a supervised link
If multiple operators must control important equipment in a noisy environment, a basic learning-code keyfob system may be the wrong class of product. Consider a system with device identity, acknowledgements, link supervision, command sequence handling, and defined behavior when communication is lost.
For industrial motion, useful features include:
A press-and-hold enable or dead-man function.
Positive transmitter identity available to the controller.
Receiver feedback or acknowledgement.
A missing-message timeout with documented timing.
Hardware-interlocked outputs.
A local/remote or maintenance/operation selector.
Event logging when operator accountability matters.
More protocol features do not automatically make a system safe, but they give the machine controller better information than “some valid code was heard.”
How I test a two-remote installation
A single-operator function test will not reveal multi-user problems. I use two people and the final installed equipment, not two remotes placed neatly beside each other on a bench.
Press the same command on both remotes at nearly the same time.
Hold one motion command and press the opposite direction from the second remote.
Press STOP from the second remote while the first holds RUN.
Move one operator close to the receiver and the other to the edge of coverage, then swap positions.
Hold a button on one transmitter continuously and confirm how other commands behave.
Remove the battery from the active transmitter while motion is in progress.
Restore receiver power while one or both remote buttons are held.
Repeat the test near motors, contactors, VFD cables, and metal structures in their normal operating state.
The expected result should be written beside each test. “Nothing dangerous happened” is not a test specification. State whether the output must stop, ignore the second user, accept STOP, require button release, or report a fault.
The practical rule I use
If two people can issue commands to the same moving load, the receiver’s pairing capacity is the least interesting part of the design. The important questions are who owns control, which commands override others, how conflicting directions are blocked, and what happens when neither operator has a reliable link.
For non-hazardous switching, occasional missed packets may be acceptable. For motors, gates, hoists, and actuators, I prefer a boring result: conflicting commands produce no motion, STOP has clear priority, direction changes pass through neutral, and every restart requires a fresh intentional command. Boring behavior is exactly what you want when two people press buttons at once.
Where incorrect operation could injure someone or damage machinery, the complete control system—not only the RF receiver—should be reviewed against the applicable local safety requirements by a qualified engineer.