While I was working on the next part of the “Unobvious and overlooked Wi-Fi” (which is about channels), I got an interesting knowledge nugget from our engineering. We all know that there is a lower limit to receiver sensitivity, we all know that there must be some upper limit, after which the Rx signal is so powerful, it simply oversaturates the radio. But that is it? Now I know it, even though I did not ask for it explicitly – I merely happened to run into a situation where it matters.. Read on…
I was looking into channel overlap, and have configured two APs (AP-7131N) blasting at full power on the same channel. I positioned them so close they were literally touching the antennas. When I looked at RSSI measurements on the AP, I could see RSSI of -1 to -5dBm (per-packet RSSI as reported by APs radio):
[AP CLI, can be done in GUI, but I’m lazy when it comes to clicking. Output redacted for clarity.]
amyapname>service pktcap on radio 1 filter ether src 5C-0E-8B-5B-10-80 and dot11 beacon [...] BEACON [Src/Dst/BSS/SSID/etc...], CH 11, RSSI -1, RATE 1 [...] BEACON [Src/Dst/BSS/SSID/etc...], CH 11, RSSI -3, RATE 1 [...] BEACON [Src/Dst/BSS/SSID/etc...], CH 11, RSSI -2, RATE 1 [...] BEACON [Src/Dst/BSS/SSID/etc...], CH 11, RSSI -5, RATE 1 [...] BEACON [Src/Dst/BSS/SSID/etc...], CH 11, RSSI -3, RATE 1 ...etc...
Knowing that APs are 0 (zero) cm apart, Tx power is 20dBm, antenna gain is 3dB+ on both Tx and Rx, plus MRC gain from 3 receive antennas on AP-7131N (at least another 3dB), I expected bigger RSSI values. Let’s run a simple link budget:
- Gains: 20dBm (Tx power) + 2*3dB (Tx/Rx antenna gain) + 3dB (MRC gain) = 29dBm.
- Losses: only FSPL. So, in order to see -1dBm RSSI, we need to lose 30dB due to FSPL.
FSPL calculator gives me 31.5cm of spacing for such a loss, and my APs are 0 cm apart! I know that FSPL is non-linear when it comes to small distances, but I still expected to see positive numbers! Even at 10cm apart (FSPL ~20dB) I should have up to 9dB of positive margin… I checked my set up several times and spent quite some time trying to get positive values – nothing. What is wrong?
Well, the only thing that was obviously wrong, was my understanding of how Wi-Fi radios work.
After asking our engineering, I’ve been told that most chipset vendors cap their receivers (by design) at -20 to -30dBm (based on product designation). This is still conformant to the 802.11 spec.
[Update] Thanks to Chi-Thahn Hoang I got a lead on the standard specifications on the upper Rx limits. There is no single table, instead the data is spread across multiple sections, depending on the PHY type. The key phrase to look for is “maximum input level” which typically resides in the “PMD Receiver Specifications” section. Here’s an example for HR-DSSS (802.11b): “The receiver shall provide a maximum PER of 10% at a PSDU length of 1000 octets, for a maximum input level of –30 dBm measured at the antenna for any baseband modulation.”
Summarizing the data across all chapters were’re getting this:
- 802.11b: -30dBm
- 802.11a: -30dBm
- 802.11g: -20dBm (including when operating at 802.11b rates)
- 802.11n (2.4): -20dBm
- 802.11n (5): -30dBm
So, -30dBm for 5GHz and -20dBm for 2.4GHz. [/Update]
Any stronger signal then simply saturates the radio, causing signal distortions (up to a level on not being able to decode the frames, think of being blinded by a light that is too bright), and any RSSI numbers above those thresholds are inaccurate.
If you think about it, it makes total sense: in real-world scenarios one would never see such values. Both clients and adjacent APs are typically spaced much further. It makes so much sense that our software, as I’ve been told, cannot even display RSSIs above 0, which perfectly explains why I could not see any positive numbers! 🙂
Well, as you can see, when it comes to Wi-Fi signal, “The more the merrier” principle does not work. Too much signal is no good. Also, do not trust RSSIs >= -20dBm when reported by Wi-Fi devices (specialized tools might be an exception). Never know what one may learn another day… It’s not the only strange thing I ran into while experimenting recently, so expect more articles in my new category “Learning by doing …wrong“.