For most general-purpose wireless controls, a learning-code system is the practical starting point. Use fixed code only where simplicity and field matching matter more than access control. Move to rolling code or authenticated custom pairing when replaying a captured transmission could create a real safety, security, or financial problem.
That is the short answer. The longer answer is that “more secure” is not automatically “better” if installers cannot add a replacement remote, the receiver memory fills without warning, or the factory cannot manage keys across several product versions. I have seen projects choose a sophisticated protocol and then weaken it in production because the service process was never designed. The pairing method has to survive the full product life, not just the first bench test.
Start with the consequence of an unauthorized command
Before comparing encoder types, write down what happens if an unknown transmitter operates the receiver. A decorative light turning on is inconvenient. A gate opening, a hoist moving, or an alarm being disarmed is a different class of problem.
I normally divide applications into three groups:
Low consequence: lighting, demonstrations, toys, non-critical convenience functions, or equipment used only inside a controlled enclosure.
Controlled access: doors, shutters, parking barriers, pumps, shared equipment, and machines where only approved operators should have control.
High consequence: functions where unauthorized or replayed commands can cause injury, release assets, defeat an alarm, or interrupt a process.
This classification does not replace a formal risk assessment, but it stops a common mistake: selecting a code system from range, frequency, or price while ignoring what the command actually does.
Fixed code: simple, predictable, and easy to copy
A fixed-code transmitter sends the same identity and command pattern each time a button is pressed. Older systems may use DIP switches or solder links. Newer units may program an identifier at the factory, but the essential behavior is the same: the code does not change from one operation to the next.
Fixed code still has valid uses. It is easy to match in the field, easy to test, and convenient when a maintenance team must replace equipment without software tools. A technician can set the same switch pattern on a spare remote and return the machine to service in minutes.
The limitation is also obvious: anyone who knows or copies the code can reproduce it. A radio capture can often be replayed because the receiver has no way to distinguish yesterday’s valid frame from today’s. With a small DIP-switch address space, accidental code duplication between nearby systems is also possible.
Choose fixed code when
The function is low consequence and the operating area is controlled.
Fast field replacement is more valuable than protection against copying.
The code space is large enough to avoid accidental overlap in the intended installation.
The customer accepts that a lost or copied remote may require changing every unit to a new code.
Do not describe fixed code as secure because the exact pulse format is not published. Obscurity may slow down casual copying, but it is not an access-control strategy.
Learning code: easy enrollment, but not automatically rolling code
“Learning code” describes the receiver workflow: place the receiver in learn mode, press a transmitter button, and store that transmitter’s identifier. Many 315 MHz and 433 MHz EV1527-type remotes are used this way. The receiver can accept several transmitters without setting physical address switches.
This is the most practical arrangement for a large number of OEM controls. Production can pair a remote during final test, installers can add a spare on site, and the customer does not need a programming cable or mobile application.
However, the word learning often causes confusion. A receiver learning a fixed transmitter identifier does not make the radio message change every time. The transmitted frame can still be static and replayable. Learning code improves provisioning and reduces address-setting errors; it does not by itself provide replay protection.
Questions that matter more than the encoder name
How many transmitters can the receiver store?
Is memory allocated per transmitter or per button?
Can one lost remote be deleted, or is “clear all” the only option?
What prevents an unauthorized person from entering learn mode?
Is there a visible or audible confirmation when memory is full?
Does pairing survive a power loss and firmware update?
Can one transmitter control several receivers, and is that behavior intended?
I have dealt with receivers advertised as “20-remote capacity” where each four-button handset consumed four memory slots. The specification was not technically false, but it was not how the installer understood it. State the capacity in the same units the customer uses.
Rolling code: replay protection with a service burden
A rolling-code transmitter changes part of the message after each valid operation. The receiver verifies the new value using a shared algorithm or key and keeps track of an expected counter window. A recording of a previous transmission should not operate the receiver again.
This is a strong improvement when replay attacks are within the threat model. It is common in access control and vehicle-related products for good reason. But it adds engineering and service requirements that are easy to underestimate.
The transmitter and receiver can lose synchronization if buttons are pressed many times out of range, if memory is corrupted, or if a replacement receiver is fitted without a proper enrollment process. A sensible resynchronization window handles normal out-of-range presses, but a window that is too wide can weaken the protocol or create confusing recovery behavior.
Rolling code also needs disciplined key handling. If every production unit uses the same master secret and that secret leaks, the entire product family may be affected. If every device has unique keys, factory programming, database control, repair replacement, and long-term support all become part of the design.
Choose rolling code when
Capturing and replaying a valid command would create an unacceptable risk.
The product can support controlled enrollment and replacement procedures.
The engineering team can manage counters, resynchronization, nonvolatile memory wear, and power-loss recovery.
Cryptographic keys can be injected and protected through production and service.
Do not add rolling code only as a label on the datasheet. Test power interruption during counter updates, repeated out-of-range key presses, cloned receiver memory, lost-transmitter removal, and replacement-unit commissioning. Those are the cases that reach the service desk later.
Custom authenticated pairing: useful when the receiver is part of a larger system
Some products need more than a handheld remote and a relay output. They may need user permissions, event logs, remote revocation, product-specific commands, or integration with a controller over UART, RS-485, CAN, or another internal bus. In that case a custom authenticated protocol can be justified.
A modern design may use a unique device identity, a challenge-response exchange, message authentication, and a per-device or per-product key. The exact architecture should be reviewed by someone experienced in embedded security. Adding AES to a packet does not solve enrollment, key storage, replay handling, downgrade protection, or compromised-device recovery.
Custom pairing makes sense when it supports a real system requirement. It is usually excessive for a simple light switch with two remotes, especially if the customer expects any technician to add a replacement handset without special tools.
Compare the service workflow before you select the protocol
The fastest way to expose a poor choice is to walk through five ordinary events:
First production pairing: Who pairs the remote, how long does it take, and how is success verified?
Adding a spare: Can the installer do it without opening a hazardous enclosure or exposing a learn button?
Lost remote: Can that one credential be removed without visiting every surviving transmitter?
Receiver replacement: Can valid remotes be transferred, or must the site collect and re-enroll all of them?
End of support: Will replacement remotes and pairing information still exist five or ten years later?
These are not administrative details. They determine truck rolls, downtime, warranty cost, and whether the customer finds a workaround that defeats the security you designed.
Receiver memory and deletion behavior deserve their own specification
For a learning or rolling-code receiver, define memory behavior explicitly. “Supports multiple remotes” is not enough.
Maximum stored transmitters and whether every button uses a separate slot
Behavior when memory is full
Single-transmitter deletion versus full erase
Duplicate enrollment handling
Storage retention and write endurance
Protection against accidental erase during power-up
Indication of learn, success, failure, and erase states
On industrial equipment, I prefer an enrollment action that cannot be triggered by one exposed pushbutton. A timed sequence, keyed access, protected menu, or service jumper may be appropriate depending on the machine. The operator should not be able to erase the fleet while trying to reset a fault.
Do not ignore radio compatibility
Two products can both say “433 MHz” and still be incompatible. Pairing requires agreement on carrier tolerance, modulation, data rate, pulse timing, packet structure, bit order, identifier length, command mapping, and receiver decoding rules. The code family is only one part of that chain.
This matters when a buyer asks for a “universal” replacement remote. A cloning remote may reproduce certain fixed-code formats, but it cannot generally convert one modulation or protocol into another, and it cannot legitimately duplicate a rolling-code credential without the required enrollment process.
For replacement projects, send a known transmitter, receiver sample, waveform capture, or complete protocol specification. A frequency printed on the case is not enough to guarantee a match.
A practical selection rule
Use fixed code for low-risk equipment where field matching must be immediate and copying is an accepted limitation.
Use learning code with a fixed identifier for general OEM wireless control where easy pairing, reasonable code space, and low service cost are the main priorities.
Use rolling code where captured commands must not be reusable and the business can support key and synchronization management.
Use custom authenticated pairing when the remote is a credential inside a larger managed system, not merely a wireless pushbutton.
The final choice should be written into the product specification together with enrollment, deletion, memory capacity, replacement, and recovery behavior. If those items are missing, the protocol is not fully selected—only the encoder has been selected.
What to include in an RF control inquiry
When requesting a receiver or remote-control design, provide the application consequence, number of users, expected remotes per receiver, whether individual deletion is required, replacement workflow, compatibility targets, and the level of replay protection needed. Also state the operating frequency and region, range, power supply, output mode, and environmental requirements.
With that information, a supplier can recommend a pairing architecture that works in production and remains supportable in the field. Without it, the default will usually be whatever is easiest to demonstrate on the bench—and that may not be what the finished product needs.