Different Codes, Same Channel: Why RF Remotes Can Collide

Two cars reach an entrance almost together. Both drivers press a 433.92 MHz remote. Which command does the receiver hear?

A common assumption is that different remote codes prevent a conflict. Each transmitter has its own identity, so the receiver should be able to tell them apart. The missing step is recovering enough of the radio message to read that identity in the first place.

An address identifies a sender. A channel-access method governs when it transmits. Those are separate jobs. Understanding the difference explains why two legitimate remotes can work individually yet miss a command when pressed together.

Why Different Codes Still Share a Channel

A typical remote assembles data such as its identifier and button command; a rolling-code design also includes changing security-related data. The transmitter carries that message using a modulation scheme such as OOK, a form of ASK, or FSK. The exact frame format depends on the system.

At the receiver, signal detection, synchronization and data recovery make later address and security checks possible. Address filtering does not remove an interfering signal before the receiver has recovered the relevant bits.

When transmissions arrive within the same receive channel and overlap in time, their waveforms superimpose at the antenna. They do not physically crash into one another in the air. The combined input can disrupt synchronization, amplitude decisions or bit timing, leaving no valid frame to identify.

Rolling code does not schedule that access. Microchip's HCS301 documentation describes changing code data and receiver synchronization, not a mechanism that senses another transmitter before sending. Protection against replay depends on the implemented security and state handling; a changing code alone is not a complete security guarantee.

What a Receiver Can Recover from Overlap

Simultaneous button presses do not guarantee that both commands fail. The actual overlap depends on wake-up delay, frame duration, repeat timing and propagation. Button timing is only the start of the experiment.

With substantial overlap and similar received powers, neither frame may be recovered. Under other conditions, the receiver may recover one transmission despite the other. A power difference can favor the stronger signal, but there is no universal rule that the strongest remote always wins.

For OOK/ASK in particular, the result depends on receiver architecture, synchronization, automatic gain control, interference timing and the relative powers. Capture behavior must be checked on the intended receiver and protocol. Moving one remote closer is a useful test variation, but distance alone does not determine received power; antenna orientation, obstructions and reflections also matter.

Describe the observation precisely: neither frame accepted, one accepted, or a later repeat accepted. A gate opening shows that an actionable command reached the control system; it does not show that the first radio frames were free of overlap.

Repeated Frames Help When Timing Separates

Many one-way remote protocols send a short burst of repeated frames for one button press. If early frames overlap but a later frame arrives cleanly, the receiver may recover the command and the user sees normal operation.

That is another opportunity, not delivery confirmation. Two transmitters with similar fixed repeat intervals can keep overlapping through the burst. Any benefit from accidental timing separation depends on the actual protocol and timing; it should not be assumed from a repeat-count specification.

Adding repeats also adds channel use. Excessive repetition can make a busy channel harder for everyone to use. Define a bounded burst, permitted timing variation and receiver duplicate handling. One press should not unexpectedly become several toggle actions because several copies were received.

A transmitter-only handheld can repeat a command without knowing whether it arrived. It cannot perform radio-based listen-before-talk or receive an ACK unless receive-capable hardware is present.

Enrollment Capacity Is Not Concurrent Capacity

If a receiver specification says it can enroll 400 remotes, check what that number counts: transmitters, credentials or button assignments. It describes enrollment capacity, not evidence that the receiver can decode 400 simultaneous transmissions.

For collisions, the useful starting points are how often devices transmit, how long their frames and bursts occupy the channel, and whether those attempts cluster in time. Include retries and, on two-way links, acknowledgment traffic.

A large enrolled population can generate little traffic when most devices remain silent. A smaller group that sends long or frequent bursts can create much more contention. A shift change or a queue arriving at one entrance can produce a concentrated burst of activity even when daily average traffic is low.

Airtime is therefore useful, but it is not the only predictor. Relative power, frame timing, receive bandwidth, receiver recovery and unrelated interference affect the outcome. Traffic estimates should use the intended busy period and be checked against observed command success and delay.

Listen-Before-Talk Needs Hardware and a Protocol

Clear channel assessment, CCA, estimates whether the channel is busy. A listen-before-talk procedure uses that assessment to decide when to attempt a transmission. A typical contention rule is to transmit after an acceptable clear assessment, defer when busy, then reassess after a defined wait.

TI's CC1101 datasheet documents RSSI, programmable carrier sense and CCA support. These are radio capabilities that firmware can use. They do not by themselves specify a complete access protocol or prove that a finished remote implements one.

The implementation must define the sensing threshold, observation time, valid radio state, receive-to-transmit transition and busy-channel response. The chosen method must notice the traffic of concern, including its modulation and gaps. A register setting copied from another product is not a coexistence test.

Two nodes can both sense an idle channel and start transmitting together. Hidden nodes create another limit: two remotes may not hear each other even though both reach the same receiver. A clear assessment at the transmitter is not proof that the receiver has an interference-free channel.

Random backoff reduces the chance that competing devices repeatedly retry in step. The protocol still needs a backoff rule, a fresh assessment, limits on attempts and a maximum command age. Randomization reduces contention; it does not guarantee a delivery time under arbitrary interference.

Define What an ACK Actually Confirms

A two-way link can send an acknowledgment after reception and retry when the expected ACK is absent. Both ends must support the return exchange, including turnaround timing, an ACK receive window and retry handling.

An absent ACK does not prove that the original command was lost. The receiver may have received it while the return ACK was lost. Retries therefore need transaction identification and duplicate suppression, especially for commands that toggle an output.

Nordic's Enhanced ShockBurst guide documents acknowledgment, retransmission and duplicate handling in a particular two-way radio protocol. It is an example of those mechanisms working together, not a feature that can be assumed on an ordinary one-way gate remote.

Specify the acknowledgment stage: packet received, command authenticated, command accepted, or action completed. A radio-level ACK alone does not confirm relay operation or gate position. Physical completion requires the relevant equipment feedback.

Listening, waiting and unsuccessful retries use energy and add delay. A better design for the application balances command success, latency, battery use and cost. Adding ACKs does not by itself make a control system suitable for safety-related machinery.

Europe: Frequency Is Only Part of the Specification

For a European-market product, asking whether a radio can operate at 868 MHz leaves important requirements unanswered. Select the exact permitted band and device category, then assess radiated power, occupied bandwidth and the applicable channel-access and occupation rules.

ETSI EN 300 220-2 V3.3.1 sets out technical requirements for non-specific short-range radio equipment, including band-dependent duty-cycle or polite-access provisions. A chip with CCA capability is not proof that the complete product meets the applicable sensing and timing requirements.

The EU short-range-device spectrum decision is another relevant starting point. Check current national implementation and the assessment requirements for the destination and equipment. Do not apply one duty-cycle or power figure to every product described as 868 MHz.

Test Command Delivery in the Intended Installation

Return to the two drivers at the entrance. Their different codes can help the receiver distinguish valid messages once recovered. Whether both commands arrive in time depends on the radio conditions and protocol.

• Establish a baseline with each registered remote operating alone at the intended positions.
• Vary the delay between presses, including near-simultaneous starts, overlapping bursts and repeated attempts.
• Vary orientation and relative received power; include close/far and similar-power cases.
• Record accepted commands, missed commands, duplicates and time to response during a representative busy period.
• For two-way links, separate lost commands from lost ACKs and check retry limits, stale-command rejection and duplicate suppression.
• Observe the controller output and equipment state separately when physical completion matters.

For a broader comparison of repetition, frequency separation, time slots, hopping and carrier sensing, see our RF collision hardware and protocol guide. Receiver sensitivity and security claims should also be checked independently of a concurrency claim.

At Dongguan Fengxian Electronics Technology Co., Ltd., the useful question is how the complete link delivers commands in its intended environment. For development or sourcing discussions, include the receiver model, market, traffic pattern, response deadline and supported link direction. These details are more useful than a rolling-code label or enrollment count alone.

Different identities can share the same channel. Reliable command delivery needs a radio and protocol designed for the traffic that actually uses it.