How RSSI, SNR, Bit Errors, and Packet Loss Relate to Each Other | IoT Worker

How RSSI, SNR, Bit Errors, and Packet Loss Relate to Each Other

Reading time: 4 minute Word count: 776
Wireless Communication RSSI SNR Packet Loss

A common field-debugging sentence is: “The signal is good, so why does it still drop?” In many cases, “good signal” only means RSSI (Received Signal Strength Indicator) is not low. Wireless link quality is not determined by receive power alone.

A better model is:

receive signal strength + noise and interference -> SNR / SINR -> demodulation success -> frame errors -> retries / packet loss -> application experience

RSSI only says how much energy the receiver sees. It does not say how much of that energy is useful signal.

RSSI Is Receive Power

RSSI usually represents received signal strength, often in dBm. A value closer to 0 means stronger received power. For example, -45 dBm is usually much stronger than -75 dBm.

But RSSI has limits:

  • Different chips, drivers, and systems may measure it differently
  • RSSI does not show the noise floor
  • RSSI does not show same-channel or adjacent-channel interference
  • RSSI does not show whether the current PHY rate is appropriate
  • RSSI does not show retry, backoff, or queueing pressure

RSSI is useful for rough coverage checks. It is not enough to judge link quality by itself.

SNR Is Closer to Demodulation Difficulty

SNR (Signal-to-Noise Ratio) compares signal against noise. A strong signal with strong noise may still have poor SNR. A weaker signal in a quiet environment may be more stable.

In real wireless environments, SINR (Signal-to-Interference-plus-Noise Ratio) is often more relevant because failures come from both noise and interference:

  • Same-channel Wi-Fi or other 2.4 GHz / 5 GHz devices
  • Bluetooth, Zigbee, microwave ovens, wireless cameras, and other shared-band devices
  • Adjacent-channel leakage
  • Multipath fading
  • RF, shielding, and antenna issues inside the device

Higher-order modulation usually requires better SNR. When link quality is insufficient, devices lower the rate or retry more often. The application sees lower throughput and worse latency, not always an immediate disconnect.

Bit Errors and Packet Loss Are Different Layers

Air-interface problems may first appear as bit errors. If the receiver cannot demodulate a frame or the checksum fails, that frame cannot be delivered upward.

But the application may not immediately see “packet loss” because several layers can react first:

  • PHY / MAC may discard the bad frame
  • The link layer may retransmit
  • IP may never know how many link-layer retries happened
  • TCP may recover with its own acknowledgements and retransmissions
  • The application may only see slowness, stalls, or timeout

This is a common debugging mismatch. Application logs show request timeout, IP captures may show TCP retransmission, while wireless captures show earlier frame errors, rate fallback, and link-layer retries.

Good RSSI does not guarantee a good link. Common causes:

  • A nearby interferer raises the noise or interference floor
  • Many same-channel devices create contention and backoff
  • Antenna direction, polarization, or obstruction creates multipath problems
  • The uplink is weak even when downlink RSSI looks good
  • The device selects a PHY rate that is too aggressive
  • Power-save policy causes missed windows or wakeup latency

Uplink and downlink asymmetry matters. What a phone or AP sees does not prove that a battery device with a small antenna and low transmit power can reliably send back.

Packet Loss Must Be Read With Timing

Low packet loss does not always mean good experience, and high packet loss is not equally bad for every workload.

Read it together with:

  • Whether losses happen in bursts
  • Whether retries push latency beyond the application budget
  • Whether loss happens during connection setup, handshake, data, or keepalive
  • Whether the lost traffic is unicast, broadcast, multicast, or control frames
  • Whether loss is concentrated on certain channels, positions, directions, or time windows

Real-time audio, control commands, OTA download, and periodic sensor reports tolerate loss very differently. Wireless metrics must be interpreted with application timing.

A Practical Debugging Order

A useful order is:

  1. Check RSSI to rule out simple coverage failure
  2. Check noise, interference, channel occupancy, or scan results
  3. Check whether PHY rate falls back frequently
  4. Check link-layer retries and failed frames
  5. Check whether IP/TCP/application symptoms are caused by lower-layer delay

If only device logs are available, separate “signal strength”, “connection rate”, “retry/failure counters”, and “application timeout”. A single signal good or connected log line is not enough for wireless debugging.

RSSI is an entry point, not a conclusion. Link quality depends on useful signal relative to noise and interference, how errors turn into retries, and whether the resulting latency and throughput cross the application’s tolerance boundary.

Continue Reading