Yes, an RF remote can run two functions at the same time—but only if the entire command path was designed for it. A handset with eight buttons is not automatically an eight-function-at-once controller. The transmitter must recognize more than one key, the radio message must describe that combination, the receiver must decode it correctly, and the machine must permit those outputs to be active together.
This question usually appears late in a project, after someone discovers that two perfectly good buttons will not work when held together. In most cases the radio range is fine and the relays are fine. The limitation was built into the command logic from the beginning.
First, define what “two functions at once” means
People use the phrase for three different requirements, and they need different designs:
Two held controls: the operator holds one button and then adds a second, such as travel plus horn, or boom up plus rotation.
One button, two outputs: a single command should energize two receiver outputs together, such as opening a valve and starting a pump.
A timed sequence: one command should start output A, wait, then start output B. That is automation, not simply simultaneous RF control.
Write the requirement in plain machine language before choosing hardware. “CH1 and CH3 may remain on together while both buttons are held” is testable. “We need multi-channel control” is not.
Why many inexpensive remotes only send one key
A simple transmitter often scans its keys and gives priority to the first valid input it finds. Press B while A is held and it may continue sending A, switch to B, or stop transmitting because the combination is undefined. All three behaviors exist in real products.
The RF packet may also have room for only one command number. If button A sends command 01 and button B sends command 02, there is no command for “01 and 02 together” unless the protocol was designed with a bit field or a separate combination code.
This is why a bench test matters. Do not infer simultaneous operation from the number of buttons, channels, or relays shown in a catalogue.
Check the whole command path, not just the receiver
For two outputs to operate together, five parts must agree:
Key scanning: the transmitter has to detect both pressed keys without electrical ghosting or firmware priority conflicts.
RF encoding: the packet has to represent multiple active commands or a defined combined command.
Receiver firmware: the decoder must accept the combination and maintain both output states.
Output hardware: relays, MOSFETs, connectors, tracks, and power supply must carry the combined load.
Machine logic: PLC logic, contactor interlocks, and safety circuits must allow that operating combination.
A four-relay receiver can still be single-command. Conversely, a receiver may support several outputs even though the supplied handset transmits only one key at a time. The system must be evaluated as a matched set.
“Can operate together” is not the same as “should operate together”
Some combinations are useful. A horn can sound while a winch moves. A work light can remain on while another function runs. On mobile equipment, travel and a proportional steering command may be intentionally concurrent.
Other combinations must be blocked. Forward and reverse contactors should never energize together. Two hydraulic valves may overload the power unit or create an unsafe movement. A pump may need proof that a valve is open before it starts.
After ten years around control panels, I prefer to put hard conflicts in the machine or receiver logic, not in the operator’s memory. The remote can request a movement; the machine decides whether that request is presently allowed.
Sometimes a dedicated combination command is the better design
Sending two independent key states is flexible, but it is not always the most predictable method. For a known operation—such as clamp plus cycle start—it can be safer to define one explicit command for that combination. The receiver then treats it as a single operating mode with a clear timeout and interlock.
This also avoids ambiguous transitions. If the operator releases one of two held buttons, should the remaining output continue, stop both outputs, or restart under a different command? A dedicated combination command lets the behavior be defined and tested instead of guessed.
Do not overlook the combined electrical load
When two channels energize together, the receiver supply sees both output coils, indicator loads, and control electronics at once. Relay contacts also see the real machine load, including inrush. Two 4 A running loads are not necessarily an 8 A event; motors and solenoids can draw several times their steady current during pickup.
Check the common terminal, PCB current path, connector rating, fuse, wiring size, and supply voltage dip. I have seen “RF problems” that were simply a receiver rebooting when the second contactor pulled in.
If the outputs drive large loads, use the receiver as a control signal for properly rated contactors or drivers. Do not make a small relay board carry motor current just because the relay case has a high resistive rating printed on it.
Release behavior matters more than the first button press
For hold-to-run control, each active command should be refreshed continuously and removed promptly when its button is released. If two functions are active, the receiver needs a clear rule for each one. A shared timeout that drops both outputs may be correct for some machines; independent timeouts may be better for others.
Test weak-signal release as well as strong-signal activation. Walk to the edge of the working area, hold two permitted functions, then release one button. The machine should not keep that function alive because the receiver missed the release transition. A short watchdog timeout is usually more dependable than trusting a single “button up” packet.
A practical bench test before approving the design
Connect lamps or low-risk test loads to the intended outputs.
Press each button alone and record the receiver behavior.
Hold the first button, add the second, then reverse the order.
Release one button while continuing to hold the other.
Repeat the test at the edge of normal working range.
Cycle receiver power while no buttons are pressed and confirm every output returns to a safe state.
Repeat with the real contactors or valves while monitoring receiver supply voltage.
Run the same test for forbidden pairs. The correct result is not merely “nothing happened”; confirm the receiver does not chatter, reboot, or leave one output latched unexpectedly.
What to tell a supplier or control engineer
Specify the operating combinations instead of asking only for a channel count:
Which buttons must work simultaneously?
Which pairs must be interlocked?
Are outputs momentary, latched, or timed?
What should happen when one of two buttons is released?
What is the maximum command-loss timeout?
What loads are connected, including coil inrush?
Does the machine PLC make the final permission decision?
A simple function matrix is often enough: list outputs across the top, operating states down the side, and mark every permitted combination. It prevents a surprising amount of rework.
The practical answer
If simultaneous control is important, treat it as a protocol and safety requirement—not as a feature implied by “multi-channel.” Ask for documented multi-key behavior, define allowed and forbidden combinations, and test button release under weak signal and full electrical load.
For a light, horn, or other non-conflicting auxiliary function, simultaneous operation is usually straightforward with the right transmitter and receiver firmware. For motors, valves, lifting equipment, or mobile machinery, let the RF link carry the request and let hardwired or validated control logic enforce the safe result.