If one press produces two movements, two relay clicks, or an ON-then-OFF sequence, do not start by blaming “RF interference.” In most cases the radio link is doing exactly what it was designed to do: sending the same command more than once so that one weak packet does not lose the operation. The fault appears when the receiver, application firmware, or power stage treats every repeated packet as a new command.
I have seen this problem on gate controllers, lifting equipment, pumps, lighting controls, and battery-powered actuators. The symptom sounds simple, but there are five different places where a second action can be created. The fastest repair is to find the layer first, then change only that layer.
First, define what “twice” really means
Ask the operator to reproduce the fault while you watch the receiver LED, listen to the relay, and observe the load separately. These three things are not always synchronized.
Two receiver LED flashes: the decoder or MCU probably accepted two commands.
One LED event but two relay clicks: look at the receiver power rail, relay drive, or output-mode logic.
One clean relay operation but the machine moves twice: the problem is downstream—contactor bounce, PLC input filtering, limit-switch logic, or the machine controller.
The fault happens only when the button is held: repeated frames or a hold-to-run function are the leading suspects.
The fault happens on a quick tap: check button bounce, packet grouping, and power reset behavior.
This distinction saves hours. I once received a “remote sends twice” complaint where the RF receiver output was clean. The actual second pulse came from a PLC input routine that counted both the rising and falling edges.
Cause 1: the transmitter intentionally repeats the RF frame
Simple 315 MHz and 433 MHz remotes commonly transmit the same coded frame continuously while a key is pressed. EV1527-type transmitters and many learning-code products do this for reliability. A short human tap may still produce several valid frames because the transmitter runs much faster than a finger.
A receiver should normally group those frames into one key event. Problems start when custom firmware calls the application function every time a valid frame is decoded. A three-frame burst then becomes three toggle commands.
Check this with a logic analyzer at the decoder data output or with a debug pin toggled after a valid decode. Do not begin at the relay contact; by then several other variables have been added. If multiple identical decode events arrive within tens or hundreds of milliseconds, the radio path is working and the command-handling policy needs attention.
What usually fixes it
Accept the first valid frame, then ignore identical frames for a defined lockout period.
Release the lockout only after no valid frame has been received for a suitable gap.
For hold-to-run control, separate key down, key held, and key released by timeout states.
Do not apply the same timing to every function. A light toggle and a motor jog have different safety requirements.
A fixed 300 ms delay is a common quick fix, but it is not always a good design. It can make rapid legitimate commands feel slow, and it does not define what should happen when a key is held for two seconds. Use a state-based rule, not just a delay inserted until the complaint disappears.
Cause 2: the handheld pushbutton is bouncing
Mechanical switch contacts do not always change state once. They can open and close several times during the first few milliseconds of a press or release. Many encoder ICs naturally mask this because they need time to start transmitting, but a low-power MCU design that wakes directly from the key input may create two separate transmission sessions.
This is more likely when the remote is old, has been exposed to dust or moisture, or uses a low-cost tact switch operated near the edge of its travel. It also explains why one key fails while the other keys remain normal.
Test the key node at the MCU or encoder, not across the rubber keypad where the probe can change the contact pressure. If the electrical waveform shows several transitions, add proper hardware or firmware debounce and replace a worn switch. Cleaning may help temporarily, but it is not a production repair for a sealed industrial remote.
Cause 3: toggle mode converts a repeated command into ON then OFF
Toggle outputs are especially sensitive. The first accepted frame turns the relay on; the second accepted frame turns it off. To the operator, the relay may appear to pulse briefly or the load may “kick” without staying on.
If the application needs a definite state, use separate ON and OFF commands or a latched/interlocked mode rather than blind toggle logic. Toggle is convenient for lighting and other visible, non-critical loads. It is a poor fit where the receiver must know the intended final state after packet repetition, power loss, or a missed command.
For motor direction control, repeated commands must never defeat the forward/reverse interlock. A receiver should force a safe transition, including any required dead time, before changing direction.
Cause 4: the relay or power rail is chattering
Sometimes the RF decoder produces one clean event, but the relay drops out and pulls in again because the receiver supply collapses when the load switches. This is common when a small DC adapter powers the receiver, relay coil, and inductive load from the same rail.
Measure the receiver voltage at the PCB terminals with an oscilloscope during switching. A multimeter often misses a 5 ms dip. Also monitor the MCU reset pin if it is accessible. If the supply falls below the brownout threshold, the controller may reboot and restore the output in a way that looks like a second RF command.
Typical corrections include:
Use a supply with enough transient current margin, not only enough steady-state current.
Separate or decouple the logic rail from the load rail.
Fit the correct flyback diode across a DC coil, observing polarity.
Use an RC snubber, MOV, or suitable suppression network for AC inductive loads.
Keep high-current return paths away from the receiver ground and antenna area.
Verify the receiver’s power-up output state after every reset.
Do not place a diode across an AC coil. That mistake creates a short circuit. Suppression components must match the load type and operating voltage.
Cause 5: the downstream controller counts edges differently
A dry-contact receiver connected to a PLC, access controller, or alarm panel may be perfectly healthy while the receiving equipment interprets the contact transition incorrectly. Some inputs count rising edges, some falling edges, and some treat any change as an event. Long cable runs can also introduce noise at a high-impedance input.
Check the signal at the final controller terminal. Confirm whether the input is active-high or active-low, whether it has an internal pull-up, and whether the application expects a maintained level or a pulse. If the cable leaves the enclosure, verify shielding, routing, and surge protection rather than increasing software debounce indefinitely.
A diagnostic sequence that works on the bench
Reproduce with no load connected. If the duplicate action remains, focus on the transmitter, decoder, and receiver logic.
Change only the transmitter. Pair a known-good remote of the same code type. If one handset fails consistently, inspect its switch and transmit burst.
Observe the decoded command. Use a logic analyzer or firmware debug pin to count accepted frames.
Observe the relay-drive signal. If the MCU output pulses once but the relay clicks twice, move to the power stage.
Measure the supply during switching. Capture minimum voltage and reset behavior with the real load connected.
Check the final controller input. Confirm that one relay operation is not being converted into two software events.
Repeat at temperature and low battery. Marginal switches, oscillators, and supplies often behave normally on a warm bench with a fresh battery.
What to record before changing the design
Keep one short capture showing the key signal, decoded command, MCU output, and supply voltage if possible. Also record transmitter battery voltage, receiver supply, load type, output mode, and the approximate press duration that triggers the fault. Without this information, teams tend to change debounce time, RF decoding, and relay hardware at the same time. The symptom may disappear, but nobody knows why—and it often returns in the next application.
The practical conclusion
One press causing two actions is not a single RF fault. It is an event-definition problem that can be created at the key, in the repeated radio burst, inside the receiver state machine, at the relay power stage, or in the downstream controller.
Start by locating where the second event first appears. If the decoder reports repeated frames, fix command grouping. If the MCU output is clean but the relay chatters, fix the supply and suppression. If the receiver contact is clean, inspect the PLC or machine input logic. That order gives a reliable answer without replacing good radio hardware.