Years ago I’d written a wifi scanning app that logs RSSI data from nearby wireless access points. This app retrieved signal strengths from Windows using what was then called the Wlan API, since renamed Windows Native Wifi. The WlanGetNetworkBssList() function returns a list of WLAN_BSS_ENTRY structures, each containing information about a detected WiFi BSS (think access point). This structure has an lRSSI field documented as returning “the received signal strength indicator (RSSI) value, in units of decibels referenced to 1.0 milliwatts (dBm).” How convenient–dBm is exactly the reference everyone in the wireless industry uses for signal strength. I logged the lRSSI field for all detected access points and called it a day.
But a few days ago I received an email noting that the values logged by my app don’t match those from a popular wifi troubleshooting app called inSSIDer Office, and asking me to investigate. I downloaded a trial copy and found that indeed, my app was showing signal strengths that were generally about 10 dB lower than reported by inSSIDer Office. What gives? I’m using the official Windows API–what could be better? (Don’t laugh.) By the way, while wifi scanners are now a dime a dozen, inSSIDer Office seems like a pretty cool tool. I didn’t play with all its features, but it did seem to show exactly the information you need to understand your local wifi environment.
Now to the investigation..
I checked the google to see if Windows had changed their wifi API and now had a different/better way of getting RSSI. No luck–other than renaming it Native Wifi it looked the same, and the WlanGetNetworkBssList() function was still the way to go. (After all, Windows would never replace an API, would they?)
Next up was a closer look at the data. I wrote a quickie test app to display relevant data from the WLAN_BSS_ENTRY list and ran it along-side inSSIDer Office to get a feel for how the data was different. The first thing I noticed was that both apps reported the same signal strength for very strong signals (greater than about -50 dBm). Between -50 and -65 dBm readings were about 5 dB lower on my test app, and below that they were about 10 dB lower. Very interesting, and what affects weak signals more than strong signals? Noise.
The WLAN_BSS_ENTRY structure has another field called uLinkQuality that returns a value from 0 to 100 and indicates the link quality. I understand this to be a rough measurement of the signal-to-noise ratio (SNR), or the extent which the received signal exceeds the noise floor. In practice, wifi radios can’t easily distinguish noise from interference, so the link quality field actually reports the ratio of the signal to noise+interference. I seem to recall that the wifi specs use the term link quality indicator (LQI) for this same measurement.
A closer examination of the data suggested that inSSIDer might actually be reporting the signal-to-noise+interference radio calculated from the link quality metric instead of reporting the actual signal strength. Windows even suggests a formula for this: (uLinkQuality / 2) – 100. Note that this isn’t the same as the received signal strength, we’re talking two different things here. RSSI indicates the actual signal strength, while LQI is how much of the signal is visible above the noise.
I modified my test app to display the SNR as calculated from the link quality metric, and it matched inSSIDer Office exactly. So while they claim to show dBm (received power relative to 1 milliwatt) it seems like they’re actually reporting SNR, which is a ratio and should be expressed in dB, not dBm.
So now we know why the two apps are showing different values, but what do we do about it? Which value is best? If you’re measuring coverage ranges you generally want to use the actual received power (dBm) as your metric. If you care about reliability you probably want to use the link quality indication because it includes the effects of noise and interference.
Most wifi installations are in congested areas. All your neighbors have wifi and other devices interfering with your wireless network. So inSSIDer is probably showing the most useful value to their customers, even if it is incorrectly named.
P.S. If you’ve followed this closely you may have noted that SNR should be smaller than the RSSI reading in the presence of noise, but the signal quality metric shows a higher value than RSSI. More about this later.