If a machine moves only while the operator holds a wireless button, the receiver is not seeing a continuous electrical contact. It is seeing a stream of short radio packets. The output stays active only while valid packets keep arriving inside a defined time window. When the repeat rate, receiver timeout, and downstream control delay are not designed together, the result is familiar: the machine hesitates, stops while the button is still down, or continues longer than expected after release.
I have debugged this on doors, lifting tables, winches, linear actuators, pumps, and small industrial machines. The radio is often blamed first. In practice, the fault is usually a timing mismatch between parts that were tested separately and never checked as one control loop.
Hold-to-run is a timed conversation, not a maintained wire
A wired pushbutton can maintain a circuit for as long as the contact is closed. A radio transmitter cannot simply hold the air interface “on” for the entire press. It sends a coded frame, pauses, and sends again. The receiver validates each frame and refreshes a timer. If that timer expires, the output must release.
This gives the receiver a practical way to stop when the transmitter goes out of range, its battery fails, or interference blocks the link. It also means that a single missed packet should not normally stop the machine. The design needs enough margin to tolerate an occasional loss without making the release sluggish.
The three clocks that decide what the operator feels
Transmitter repeat interval. This is the time from one valid command frame to the next while the key remains pressed. In simple remote controls it may be a few tens of milliseconds, but it must be measured on the real transmitter and firmware.
Receiver release timeout. Every accepted frame reloads this timer. If no further valid frame arrives before it expires, the receiver turns the output off.
Downstream delay. Relay operate and release time, PLC input filtering, contactor delay, and the machine controller scan all add time after the RF decision has already been made.
The operator experiences the sum of these clocks, not the receiver setting printed in a firmware note. A 180 ms RF timeout followed by a 50 ms PLC filter and a slow contactor can produce a noticeably longer stop than the RF engineer expected.
Choose the timeout from a loss budget
Do not select a release timeout by increasing a number until the bench test looks smooth. Start with the measured repeat interval and decide how many consecutive packet opportunities the application should survive.
For example, suppose the transmitter sends a valid frame every 50 ms while the key is held. A 60 ms timeout leaves almost no margin: one delayed or corrupted frame can release the output. A timeout around 160–200 ms allows roughly three missed intervals, depending on packet timing and processing jitter.
That does not make 200 ms a universal value. It is only an example of the calculation. The correct setting depends on command rate, interference, required stopping response, receiver processing, and the consequences of an unwanted pause or delayed release.
Write the timing requirement in both directions:
Continuity requirement: how many consecutive frames may be lost before motion is interrupted?
Release requirement: after the last valid frame, how quickly must the RF output and the complete machine response return to the intended state?
If a project specifies only “continuous while pressed,” it is not specified well enough to test.
Why the unit passes on the bench and stutters on the machine
On a bench, the transmitter is close, the battery is fresh, and there is little conducted noise. Installed equipment adds motor drives, contactors, metal panels, long cables, switching supplies, and operators who stand in different places.
A marginal link may still deliver most packets, so a toggle command appears reliable. Hold-to-run exposes the same link because it depends on a continuous sequence. Losing one frame out of twenty may be invisible with a toggle button and obvious during a ten-second motor jog.
When the complaint is “it stops only sometimes,” compare the packet gap with the release timeout. Do not judge by the receiver LED alone. Many LEDs stretch a short decode event so the eye can see it; they do not show the actual spacing between valid frames.
The receiver needs states, not a single delay
A robust implementation normally separates three conditions:
Key down: the first authorized frame activates the permitted output.
Key held: matching frames refresh the hold timer without retriggering the action as a new command.
Key released or link lost: a release message, when the protocol supports one, or expiry of the hold timer returns the output to its defined state.
This distinction matters because packet repetition has two opposite jobs. It must keep a hold-to-run output alive, but it must not make a toggle command switch repeatedly. Treating every valid frame as a new button press is the usual cause of duplicate actions. Treating every repeated frame as irrelevant is the usual cause of a held command timing out.
Use separate command handling for jog, toggle, set-ON/set-OFF, and interlocked direction control. One global debounce value rarely serves all four correctly.
Release packets help, but timeout is still required
Some two-way or MCU-based transmitters can send a specific key-release frame. This can make the output release quickly when the operator lets go. It must not be the only way to stop the output, because the final packet is the one most likely to be missed when the transmitter is moving, the battery contact opens, or the operator leaves the coverage area.
Use the release frame for fast normal response and keep the receiver timeout as the backstop. Then test both paths separately: a clean button release and an abrupt loss of RF while the output is active.
Watch the PLC and relay after the RF output
A receiver can release correctly while the machine appears late. If the receiver drives a PLC input through a dry contact, check the PLC input filter and program logic. Some filters intended to reject contact bounce add tens of milliseconds at both activation and release. A timer inside the ladder logic can add more.
For direct motor or solenoid control, measure the relay coil drive and the load current, not only the RF decoder. A sticky contactor, a flyback path that slows coil release, or a mechanical brake can extend movement after the receiver output has gone inactive.
Do not use ordinary remote-control timing as a substitute for a safety-rated emergency-stop function. Hold-to-run behavior is one part of the machine control design; the required protective functions must be assessed and implemented separately for the application.
A test setup that gives useful answers
Capture at least four signals on the same time axis:
the transmitter key input;
the RF transmit envelope or a packet-valid indication;
the receiver’s accepted-command or timer-refresh signal;
the receiver output, PLC input, or load current.
Run a short tap, a five-second hold, and an abrupt loss test. Repeat with a low but still serviceable transmitter battery, at the intended operating distance, with the real motor or drive switching. If possible, rotate the handheld remote and test with the operator’s body between transmitter and receiver. That is where a weak installation shows itself.
Record the longest gap between accepted frames, not just the average interval. The timeout must survive expected worst-case gaps with margin while still meeting the required release response.
Common fixes that create a second problem
Making the timeout very long. The stutter disappears, but the output remains active too long after RF loss.
Transmitting continuously with no pause. Battery life, oscillator behavior, coexistence, and regional radio limits may become problems.
Adding a large PLC off-delay. This hides packet gaps downstream and makes the machine response harder to predict.
Using toggle mode for a jog function. A missed or duplicate event can leave the final state different from the operator’s intention.
Testing only at one metre with a fresh battery. The timing looks correct because the link has no realistic loss.
What to specify when selecting a system
For a hold-to-run application, ask for more than frequency and range. Specify which buttons are jog controls, the transmitter repeat interval, receiver release timeout, output state after power-up, behavior after RF loss, direction interlock rules, and whether a release frame is used. Also state the PLC input filter or load interface connected after the receiver.
If the supplier cannot describe what happens after the last valid packet, the hold-to-run behavior is still undefined.
The practical conclusion
A wireless button that must stay active while held is a small real-time control system. Smooth operation depends on a repeat interval fast enough for the job, a receiver timeout long enough to ride through expected packet loss, and a complete release path fast enough for the application.
Measure the frame gaps, set a deliberate loss budget, and include the PLC, relay, contactor, and mechanics in the timing check. Once those numbers are visible on one trace, the argument about whether “the RF is weak” usually becomes a straightforward engineering decision.