trying to clean up the signal/noise mess. the previous code in mac80211 did
not have much definition of what units of signal and noise were provided and
used weird implicit mechanisms from the wireless extensions.
introduce hardware capability flags to let the hardware specify if it can
provide signal and noise level values and which units it can provide:
IEEE80211_HW_SIGNAL_UNSPEC - unspecified, unknown, hw specific
IEEE80211_HW_SIGNAL_DB - dB difference to unspecified reference point
IEEE80211_HW_SIGNAL_DBM - dBm, difference to 1mW
IEEE80211_HW_NOISE_DBM - dBm, difference to 1mW
also clean up the misleading and confusing names which were used for signal,
noise and qual before.
i tried my best to find out for each driver what it can provide and update it
but i'm not sure (?) for many of them and used the more conservative guess in
doubt. could driver authors please check and fix that up later or tell me the
correct units?
DRIVER SIGNAL NOISE QUAL
-----------------------------------------------------------------
adm8211 unspec? n/a missing
at76_usb unspec? unused missing
ath5k dBm dBm percent rssi
b43legacy dBm dBm percent jssi(?)
b43 dBm dBm percent jssi(?)
iwl-3945 dBm dBm percent snr+more
iwl-4965 dBm dBm percent snr+more
p54 unspec n/a missing
rt2x00 dB(?) n/a percent rssi+tx/rx frame success
rt2400 dB(?) n/a
rt2500pci dB(?) n/a
rt2500usb dB(?) n/a
rt61pci dB(?) n/a
rt73usb dB(?) n/a
rtl8180 unspec? n/a ?
rtl8187 unspec? ? noise?
zd1211 dB? n/a percent
---
drivers/net/wireless/adm8211.c | 6 ++--
drivers/net/wireless/at76_usb.c | 5 ++-
drivers/net/wireless/ath5k/base.c | 23 +++-----------
drivers/net/wireless/b43/main.c | 8 ++---
drivers/net/wireless/b43/xmit.c | 5 +--
drivers/net/wireless/b43legacy/main.c | 7 ++--
drivers/net/wireless/b43legacy/xmit.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-3945.c | 18 +++++------
drivers/net/wireless/iwlwifi/iwl-4965.c | 12 ++++---
drivers/net/wireless/iwlwifi/iwl-core.c | 16 ++-------
drivers/net/wireless/iwlwifi/iwl3945-base.c | 15 ++-------
drivers/net/wireless/p54common.c | 6 ++--
drivers/net/wireless/rt2x00/rt2400pci.c | 5 +--
drivers/net/wireless/rt2x00/rt2500pci.c | 6 ++--
drivers/net/wireless/rt2x00/rt2500usb.c | 6 ++--
drivers/net/wireless/rt2x00/rt2x00dev.c | 4 +-
drivers/net/wireless/rt2x00/rt61pci.c | 5 +--
drivers/net/wireless/rt2x00/rt73usb.c | 5 +--
drivers/net/wireless/rtl8180_dev.c | 8 ++---
drivers/net/wireless/rtl8187_dev.c | 9 ++---
drivers/net/wireless/zd1211rw/zd_mac.c | 11 +++---
include/net/mac80211.h | 46 ++++++++++++++++++---------
net/ieee80211/ieee80211_rx.c | 2 +
net/mac80211/debugfs_sta.c | 2 +
net/mac80211/ieee80211.c | 10 +++---
net/mac80211/ieee80211_i.h | 2 +
net/mac80211/ieee80211_ioctl.c | 20 ++++++++----
net/mac80211/ieee80211_sta.c | 12 ++++---
net/mac80211/rx.c | 4 +-
net/mac80211/sta_info.h | 2 +
30 files changed, 137 insertions(+), 147 deletions(-)
diff --git a/drivers/net/wireless/adm8211.c b/drivers/net/wireless/adm8211.c
index 2e257ee..f90953e 100644
--- a/drivers/net/wireless/adm8211.c
+++ b/drivers/net/wireless/adm8211.c
@@ -446,9 +446,9 @@ static void adm8211_interrupt_rci(struct ieee80211_hw *dev)
struct ieee80211_rx_status rx_status = {0};
if (priv->pdev->revision < ADM8211_REV_CA)
- rx_status.ssi = rssi;
+ rx_status.signal = rssi;
else
- rx_status.ssi = 100 - rssi;
+ rx_status.signal = 100 - rssi;
rx_status.rate_idx = rate;
@@ -1901,9 +1901,9 @@ static int __devinit adm8211_probe(struct pci_dev *pdev,
dev->extra_tx_headroom = sizeof(struct adm8211_tx_hdr);
/* dev->flags = IEEE80211_HW_RX_INCLUDES_FCS in promisc mode */
+ dev->flags = IEEE80211_HW_SIGNAL_UNSPEC;
dev->channel_change_time = 1000;
- dev->max_rssi = 100; /* FIXME: find better value */
dev->queues = 1; /* ADM8211C supports more, maybe ADM8211B too */
diff --git a/drivers/net/wireless/at76_usb.c b/drivers/net/wireless/at76_usb.c
index 33fa026..009f8a7 100644
--- a/drivers/net/wireless/at76_usb.c
+++ b/drivers/net/wireless/at76_usb.c
@@ -1599,7 +1599,7 @@ static void at76_rx_tasklet(unsigned long param)
at76_dbg_dump(DBG_RX_DATA, priv->rx_skb->data,
priv->rx_skb->len, "RX: len=%d", priv->rx_skb->len);
- rx_status.ssi = buf->rssi;
+ rx_status.signal = buf->rssi;
rx_status.flag |= RX_FLAG_DECRYPTED;
rx_status.flag |= RX_FLAG_IV_STRIPPED;
@@ -2273,7 +2273,8 @@ static int at76_init_new_device(struct at76_priv *priv,
/* mac80211 initialisation */
priv->hw->wiphy->bands[IEEE80211_BAND_2GHZ] = &at76_supported_band;
- priv->hw->flags = IEEE80211_HW_RX_INCLUDES_FCS;
+ priv->hw->flags = IEEE80211_HW_RX_INCLUDES_FCS |
+ IEEE80211_HW_SIGNAL_UNSPEC;
SET_IEEE80211_DEV(priv->hw, &interface->dev);
SET_IEEE80211_PERM_ADDR(priv->hw, priv->mac_addr);
diff --git a/drivers/net/wireless/ath5k/base.c b/drivers/net/wireless/ath5k/base.c
index b5c0a0d..538c815 100644
--- a/drivers/net/wireless/ath5k/base.c
+++ b/drivers/net/wireless/ath5k/base.c
@@ -461,13 +461,11 @@ ath5k_pci_probe(struct pci_dev *pdev,
/* Initialize driver private data */
SET_IEEE80211_DEV(hw, &pdev->dev);
- hw->flags = IEEE80211_HW_RX_INCLUDES_FCS;
+ hw->flags = IEEE80211_HW_RX_INCLUDES_FCS |
+ IEEE80211_HW_SIGNAL_DBM |
+ IEEE80211_HW_NOISE_DBM;
hw->extra_tx_headroom = 2;
hw->channel_change_time = 5000;
- /* these names are misleading */
- hw->max_rssi = -110; /* signal in dBm */
- hw->max_noise = -110; /* noise in dBm */
- hw->max_signal = 100; /* we will provide a percentage based on rssi */
sc = hw->priv;
sc->hw = hw;
sc->pdev = pdev;
@@ -1893,20 +1891,9 @@ accept:
rxs.freq = sc->curchan->center_freq;
rxs.band = sc->curband->band;
- /*
- * signal quality:
- * the names here are misleading and the usage of these
- * values by iwconfig makes it even worse
- */
- /* noise floor in dBm, from the last noise calibration */
rxs.noise = sc->ah->ah_noise_floor;
- /* signal level in dBm */
- rxs.ssi = rxs.noise + rs.rs_rssi;
- /*
- * "signal" is actually displayed as Link Quality by iwconfig
- * we provide a percentage based on rssi (assuming max rssi 64)
- */
- rxs.signal = rs.rs_rssi * 100 / 64;
+ rxs.signal = rxs.noise + rs.rs_rssi;
+ rxs.qual = rs.rs_rssi * 100 / 64;
rxs.antenna = rs.rs_antenna;
rxs.rate_idx = ath5k_hw_to_driver_rix(sc, rs.rs_rate);
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index a4e6a59..e86cd57 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -4301,10 +4301,10 @@ static int b43_wireless_init(struct ssb_device *dev)
/* fill hw info */
hw->flags = IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE |
- IEEE80211_HW_RX_INCLUDES_FCS;
- hw->max_signal = 100;
- hw->max_rssi = -110;
- hw->max_noise = -110;
+ IEEE80211_HW_RX_INCLUDES_FCS |
+ IEEE80211_HW_SIGNAL_DBM |
+ IEEE80211_HW_NOISE_DBM;
+
hw->queues = b43_modparam_qos ? 4 : 1;
SET_IEEE80211_DEV(hw, dev->dev);
if (is_valid_ether_addr(sprom->et1mac))
diff --git a/drivers/net/wireless/b43/xmit.c b/drivers/net/wireless/b43/xmit.c
index ec10a8e..1c8f8e1 100644
--- a/drivers/net/wireless/b43/xmit.c
+++ b/drivers/net/wireless/b43/xmit.c
@@ -574,13 +574,12 @@ void b43_rx(struct b43_wldev *dev, struct sk_buff *skb, const void *_rxhdr)
}
}
- status.ssi = b43_rssi_postprocess(dev, jssi,
+ status.signal = b43_rssi_postprocess(dev, jssi,
(phystat0 & B43_RX_PHYST0_OFDM),
(phystat0 & B43_RX_PHYST0_GAINCTL),
(phystat3 & B43_RX_PHYST3_TRSTATE));
status.noise = dev->stats.link_noise;
- /* the next line looks wrong, but is what mac80211 wants */
- status.signal = (jssi * 100) / B43_RX_MAX_SSI;
+ status.qual = (jssi * 100) / B43_RX_MAX_SSI;
if (phystat0 & B43_RX_PHYST0_OFDM)
status.rate_idx = b43_plcp_get_bitrate_idx_ofdm(plcp,
phytype == B43_PHYTYPE_A);
diff --git a/drivers/net/wireless/b43legacy/main.c b/drivers/net/wireless/b43legacy/main.c
index f518e79..5f95ef2 100644
--- a/drivers/net/wireless/b43legacy/main.c
+++ b/drivers/net/wireless/b43legacy/main.c
@@ -3689,10 +3689,9 @@ static int b43legacy_wireless_init(struct ssb_device *dev)
/* fill hw info */
hw->flags = IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE |
- IEEE80211_HW_RX_INCLUDES_FCS;
- hw->max_signal = 100;
- hw->max_rssi = -110;
- hw->max_noise = -110;
+ IEEE80211_HW_RX_INCLUDES_FCS |
+ IEEE80211_HW_SIGNAL_DBM |
+ IEEE80211_HW_NOISE_DBM;
hw->queues = 1; /* FIXME: hardware has more queues */
SET_IEEE80211_DEV(hw, dev->dev);
if (is_valid_ether_addr(sprom->et1mac))
diff --git a/drivers/net/wireless/b43legacy/xmit.c b/drivers/net/wireless/b43legacy/xmit.c
index dcad249..906a087 100644
--- a/drivers/net/wireless/b43legacy/xmit.c
+++ b/drivers/net/wireless/b43legacy/xmit.c
@@ -532,12 +532,12 @@ void b43legacy_rx(struct b43legacy_wldev *dev,
}
}
- status.ssi = b43legacy_rssi_postprocess(dev, jssi,
+ status.signal = b43legacy_rssi_postprocess(dev, jssi,
(phystat0 & B43legacy_RX_PHYST0_OFDM),
(phystat0 & B43legacy_RX_PHYST0_GAINCTL),
(phystat3 & B43legacy_RX_PHYST3_TRSTATE));
status.noise = dev->stats.link_noise;
- status.signal = (jssi * 100) / B43legacy_RX_MAX_SSI;
+ status.qual = (jssi * 100) / B43legacy_RX_MAX_SSI;
/* change to support A PHY */
if (phystat0 & B43legacy_RX_PHYST0_OFDM)
status.rate_idx = b43legacy_plcp_get_bitrate_idx_ofdm(plcp, false);
diff --git a/drivers/net/wireless/iwlwifi/iwl-3945.c b/drivers/net/wireless/iwlwifi/iwl-3945.c
index e116ed7..9b270fc 100644
--- a/drivers/net/wireless/iwlwifi/iwl-3945.c
+++ b/drivers/net/wireless/iwlwifi/iwl-3945.c
@@ -518,7 +518,7 @@ static void iwl3945_add_radiotap(struct iwl3945_priv *priv,
{
/* First cache any information we need before we overwrite
* the information provided in the skb from the hardware */
- s8 signal = stats->ssi;
+ s8 signal = stats->signal;
s8 noise = 0;
int rate = stats->rate_idx;
u64 tsf = stats->mactime;
@@ -691,7 +691,7 @@ static void iwl3945_rx_reply_rx(struct iwl3945_priv *priv,
}
/* Convert 3945's rssi indicator to dBm */
- rx_status.ssi = rx_stats->rssi - IWL_RSSI_OFFSET;
+ rx_status.signal = rx_stats->rssi - IWL_RSSI_OFFSET;
/* Set default noise value to -127 */
if (priv->last_rx_noise == 0)
@@ -710,21 +710,21 @@ static void iwl3945_rx_reply_rx(struct iwl3945_priv *priv,
* Calculate rx_status.signal (quality indicator in %) based on SNR. */
if (rx_stats_noise_diff) {
snr = rx_stats_sig_avg / rx_stats_noise_diff;
- rx_status.noise = rx_status.ssi -
+ rx_status.noise = rx_status.signal -
iwl3945_calc_db_from_ratio(snr);
- rx_status.signal = iwl3945_calc_sig_qual(rx_status.ssi,
+ rx_status.qual = iwl3945_calc_sig_qual(rx_status.signal,
rx_status.noise);
/* If noise info not available, calculate signal quality indicator (%)
* using just the dBm signal level. */
} else {
rx_status.noise = priv->last_rx_noise;
- rx_status.signal = iwl3945_calc_sig_qual(rx_status.ssi, 0);
+ rx_status.qual = iwl3945_calc_sig_qual(rx_status.signal, 0);
}
IWL_DEBUG_STATS("Rssi %d noise %d qual %d sig_avg %d noise_diff %d\n",
- rx_status.ssi, rx_status.noise, rx_status.signal,
+ rx_status.signal, rx_status.noise, rx_status.qual,
rx_stats_sig_avg, rx_stats_noise_diff);
header = (struct ieee80211_hdr *)IWL_RX_DATA(pkt);
@@ -734,8 +734,8 @@ static void iwl3945_rx_reply_rx(struct iwl3945_priv *priv,
IWL_DEBUG_STATS_LIMIT("[%c] %d RSSI:%d Signal:%u, Noise:%u, Rate:%u\n",
network_packet ? '*' : ' ',
le16_to_cpu(rx_hdr->channel),
- rx_status.ssi, rx_status.ssi,
- rx_status.ssi, rx_status.rate_idx);
+ rx_status.signal, rx_status.signal,
+ rx_status.noise, rx_status.rate_idx);
#ifdef CONFIG_IWL3945_DEBUG
if (iwl3945_debug_level & (IWL_DL_RX))
@@ -746,7 +746,7 @@ static void iwl3945_rx_reply_rx(struct iwl3945_priv *priv,
if (network_packet) {
priv->last_beacon_time = le32_to_cpu(rx_end->beacon_timestamp);
priv->last_tsf = le64_to_cpu(rx_end->timestamp);
- priv->last_rx_rssi = rx_status.ssi;
+ priv->last_rx_rssi = rx_status.signal;
priv->last_rx_noise = rx_status.noise;
}
diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c b/drivers/net/wireless/iwlwifi/iwl-4965.c
index 1db873b..91daad5 100644
--- a/drivers/net/wireless/iwlwifi/iwl-4965.c
+++ b/drivers/net/wireless/iwlwifi/iwl-4965.c
@@ -3294,7 +3294,7 @@ static void iwl4965_add_radiotap(struct iwl_priv *priv,
struct ieee80211_rx_status *stats,
u32 ampdu_status)
{
- s8 signal = stats->ssi;
+ s8 signal = stats->signal;
s8 noise = 0;
int rate = stats->rate_idx;
u64 tsf = stats->mactime;
@@ -3951,7 +3951,7 @@ static void iwl4965_rx_reply_rx(struct iwl_priv *priv,
priv->ucode_beacon_time = le32_to_cpu(rx_start->beacon_time_stamp);
/* Find max signal strength (dBm) among 3 antenna/receiver chains */
- rx_status.ssi = iwl4965_calc_rssi(rx_start);
+ rx_status.signal = iwl4965_calc_rssi(rx_start);
/* Meaningful noise values are available only from beacon statistics,
* which are gathered only when associated, and indicate noise
@@ -3960,11 +3960,11 @@ static void iwl4965_rx_reply_rx(struct iwl_priv *priv,
if (iwl4965_is_associated(priv) &&
!test_bit(STATUS_SCANNING, &priv->status)) {
rx_status.noise = priv->last_rx_noise;
- rx_status.signal = iwl4965_calc_sig_qual(rx_status.ssi,
+ rx_status.qual = iwl4965_calc_sig_qual(rx_status.signal,
rx_status.noise);
} else {
rx_status.noise = IWL_NOISE_MEAS_NOT_AVAILABLE;
- rx_status.signal = iwl4965_calc_sig_qual(rx_status.ssi, 0);
+ rx_status.qual = iwl4965_calc_sig_qual(rx_status.signal, 0);
}
/* Reset beacon noise level if not associated. */
@@ -3976,12 +3976,12 @@ static void iwl4965_rx_reply_rx(struct iwl_priv *priv,
iwl4965_dbg_report_frame(priv, pkt, header, 1);
IWL_DEBUG_STATS_LIMIT("Rssi %d, noise %d, qual %d, TSF %llu\n",
- rx_status.ssi, rx_status.noise, rx_status.signal,
+ rx_status.signal, rx_status.noise, rx_status.qual,
rx_status.mactime);
network_packet = iwl4965_is_network_packet(priv, header);
if (network_packet) {
- priv->last_rx_rssi = rx_status.ssi;
+ priv->last_rx_rssi = rx_status.signal;
priv->last_beacon_time = priv->ucode_beacon_time;
priv->last_tsf = le64_to_cpu(rx_start->timestamp);
}
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
index da51349..f050a22 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.c
+++ b/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -220,18 +220,10 @@ static void iwlcore_init_hw(struct iwl_priv *priv)
struct ieee80211_hw *hw = priv->hw;
hw->rate_control_algorithm = "iwl-4965-rs";
- /* Tell mac80211 and its clients (e.g. Wireless Extensions)
- * the range of signal quality values that we'll provide.
- * Negative values for level/noise indicate that we'll provide dBm.
- * For WE, at least, non-0 values here *enable* display of values
- * in app (iwconfig). */
- hw->max_rssi = -20; /* signal level, negative indicates dBm */
- hw->max_noise = -20; /* noise level, negative indicates dBm */
- hw->max_signal = 100; /* link quality indication (%) */
-
- /* Tell mac80211 our Tx characteristics */
- hw->flags = IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE;
-
+ /* Tell mac80211 our characteristics */
+ hw->flags = IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE |
+ IEEE80211_HW_SIGNAL_DBM |
+ IEEE80211_HW_NOISE_DBM;
/* Default value; 4 EDCA QOS priorities */
hw->queues = 4;
#ifdef CONFIG_IWL4965_HT
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 5bc5f6f..eb266c4 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -7973,17 +7973,10 @@ static int iwl3945_pci_probe(struct pci_dev *pdev, const struct pci_device_id *e
priv->ibss_beacon = NULL;
- /* Tell mac80211 and its clients (e.g. Wireless Extensions)
- * the range of signal quality values that we'll provide.
- * Negative values for level/noise indicate that we'll provide dBm.
- * For WE, at least, non-0 values here *enable* display of values
- * in app (iwconfig). */
- hw->max_rssi = -20; /* signal level, negative indicates dBm */
- hw->max_noise = -20; /* noise level, negative indicates dBm */
- hw->max_signal = 100; /* link quality indication (%) */
-
- /* Tell mac80211 our Tx characteristics */
- hw->flags = IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE;
+ /* Tell mac80211 our characteristics */
+ hw->flags = IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE |
+ IEEE80211_HW_SIGNAL_DBM |
+ IEEE80211_HW_NOISE_DBM;
/* 4 EDCA QOS priorities */
hw->queues = 4;
diff --git a/drivers/net/wireless/p54common.c b/drivers/net/wireless/p54common.c
index 63f9bad..d6322be 100644
--- a/drivers/net/wireless/p54common.c
+++ b/drivers/net/wireless/p54common.c
@@ -355,7 +355,7 @@ static void p54_rx_data(struct ieee80211_hw *dev, struct sk_buff *skb)
struct ieee80211_rx_status rx_status = {0};
u16 freq = le16_to_cpu(hdr->freq);
- rx_status.ssi = hdr->rssi;
+ rx_status.signal = hdr->rssi;
/* XX correct? */
rx_status.rate_idx = hdr->rate & 0xf;
rx_status.freq = freq;
@@ -1004,9 +1004,9 @@ struct ieee80211_hw *p54_init_common(size_t priv_data_len)
skb_queue_head_init(&priv->tx_queue);
dev->wiphy->bands[IEEE80211_BAND_2GHZ] = &band_2GHz;
dev->flags = IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING | /* not sure */
- IEEE80211_HW_RX_INCLUDES_FCS;
+ IEEE80211_HW_RX_INCLUDES_FCS |
+ IEEE80211_HW_SIGNAL_UNSPEC;
dev->channel_change_time = 1000; /* TODO: find actual value */
- dev->max_rssi = 127;
priv->tx_stats.data[0].limit = 5;
dev->queues = 1;
diff --git a/drivers/net/wireless/rt2x00/rt2400pci.c b/drivers/net/wireless/rt2x00/rt2400pci.c
index a6e9c89..c8a0fa7 100644
--- a/drivers/net/wireless/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/rt2x00/rt2400pci.c
@@ -1353,10 +1353,9 @@ static void rt2400pci_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
/*
* Initialize all hw fields.
*/
- rt2x00dev->hw->flags = IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING;
+ rt2x00dev->hw->flags = IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING |
+ IEEE80211_HW_SIGNAL_DB;
rt2x00dev->hw->extra_tx_headroom = 0;
- rt2x00dev->hw->max_signal = MAX_SIGNAL;
- rt2x00dev->hw->max_rssi = MAX_RX_SSI;
rt2x00dev->hw->queues = 2;
SET_IEEE80211_DEV(rt2x00dev->hw, &rt2x00dev_pci(rt2x00dev)->dev);
diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c b/drivers/net/wireless/rt2x00/rt2500pci.c
index 1bdb873..db2a6e2 100644
--- a/drivers/net/wireless/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/rt2x00/rt2500pci.c
@@ -1673,10 +1673,10 @@ static void rt2500pci_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
/*
* Initialize all hw fields.
*/
- rt2x00dev->hw->flags = IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING;
+ rt2x00dev->hw->flags = IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING |
+ IEEE80211_HW_SIGNAL_DB;
+
rt2x00dev->hw->extra_tx_headroom = 0;
- rt2x00dev->hw->max_signal = MAX_SIGNAL;
- rt2x00dev->hw->max_rssi = MAX_RX_SSI;
rt2x00dev->hw->queues = 2;
SET_IEEE80211_DEV(rt2x00dev->hw, &rt2x00dev_pci(rt2x00dev)->dev);
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
index f5c18f0..aa4c4fe 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -1590,10 +1590,10 @@ static void rt2500usb_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
rt2x00dev->hw->flags =
IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE |
IEEE80211_HW_RX_INCLUDES_FCS |
- IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING;
+ IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING |
+ IEEE80211_HW_SIGNAL_DB;
+
rt2x00dev->hw->extra_tx_headroom = TXD_DESC_SIZE;
- rt2x00dev->hw->max_signal = MAX_SIGNAL;
- rt2x00dev->hw->max_rssi = MAX_RX_SSI;
rt2x00dev->hw->queues = 2;
SET_IEEE80211_DEV(rt2x00dev->hw, &rt2x00dev_usb(rt2x00dev)->dev);
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
index d2c0967..2acb224 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -607,9 +607,9 @@ void rt2x00lib_rxdone(struct queue_entry *entry,
rt2x00dev->link.qual.rx_success++;
rx_status->rate_idx = idx;
- rx_status->signal =
+ rx_status->qual =
rt2x00lib_calculate_link_signal(rt2x00dev, rxdesc->rssi);
- rx_status->ssi = rxdesc->rssi;
+ rx_status->signal = rxdesc->rssi;
rx_status->flag = rxdesc->flags;
rx_status->antenna = rt2x00dev->link.ant.active.rx;
diff --git a/drivers/net/wireless/rt2x00/rt61pci.c b/drivers/net/wireless/rt2x00/rt61pci.c
index 0d2e6f7..af0196c 100644
--- a/drivers/net/wireless/rt2x00/rt61pci.c
+++ b/drivers/net/wireless/rt2x00/rt61pci.c
@@ -2229,10 +2229,9 @@ static void rt61pci_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
*/
rt2x00dev->hw->flags =
IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE |
- IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING;
+ IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING |
+ IEEE80211_HW_SIGNAL_DB;
rt2x00dev->hw->extra_tx_headroom = 0;
- rt2x00dev->hw->max_signal = MAX_SIGNAL;
- rt2x00dev->hw->max_rssi = MAX_RX_SSI;
rt2x00dev->hw->queues = 4;
SET_IEEE80211_DEV(rt2x00dev->hw, &rt2x00dev_pci(rt2x00dev)->dev);
diff --git a/drivers/net/wireless/rt2x00/rt73usb.c b/drivers/net/wireless/rt2x00/rt73usb.c
index b3c8462..44e071f 100644
--- a/drivers/net/wireless/rt2x00/rt73usb.c
+++ b/drivers/net/wireless/rt2x00/rt73usb.c
@@ -1817,10 +1817,9 @@ static void rt73usb_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
*/
rt2x00dev->hw->flags =
IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE |
- IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING;
+ IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING |
+ IEEE80211_HW_SIGNAL_DB;
rt2x00dev->hw->extra_tx_headroom = TXD_DESC_SIZE;
- rt2x00dev->hw->max_signal = MAX_SIGNAL;
- rt2x00dev->hw->max_rssi = MAX_RX_SSI;
rt2x00dev->hw->queues = 4;
SET_IEEE80211_DEV(rt2x00dev->hw, &rt2x00dev_usb(rt2x00dev)->dev);
diff --git a/drivers/net/wireless/rtl8180_dev.c b/drivers/net/wireless/rtl8180_dev.c
index b1b3a47..6839c4f 100644
--- a/drivers/net/wireless/rtl8180_dev.c
+++ b/drivers/net/wireless/rtl8180_dev.c
@@ -132,8 +132,8 @@ static void rtl8180_handle_rx(struct ieee80211_hw *dev)
rx_status.antenna = (flags2 >> 15) & 1;
/* TODO: improve signal/rssi reporting */
- rx_status.signal = flags2 & 0xFF;
- rx_status.ssi = (flags2 >> 8) & 0x7F;
+ rx_status.qual = flags2 & 0xFF;
+ rx_status.signal = (flags2 >> 8) & 0x7F;
/* XXX: is this correct? */
rx_status.rate_idx = (flags >> 20) & 0xF;
rx_status.freq = dev->conf.channel->center_freq;
@@ -894,9 +894,9 @@ static int __devinit rtl8180_probe(struct pci_dev *pdev,
dev->wiphy->bands[IEEE80211_BAND_2GHZ] = &priv->band;
dev->flags = IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING |
- IEEE80211_HW_RX_INCLUDES_FCS;
+ IEEE80211_HW_RX_INCLUDES_FCS |
+ IEEE80211_HW_SIGNAL_UNSPEC;
dev->queues = 1;
- dev->max_rssi = 65;
reg = rtl818x_ioread32(priv, &priv->map->TX_CONF);
reg &= RTL818X_TX_CONF_HWVER_MASK;
diff --git a/drivers/net/wireless/rtl8187_dev.c b/drivers/net/wireless/rtl8187_dev.c
index c03834d..1086e01 100644
--- a/drivers/net/wireless/rtl8187_dev.c
+++ b/drivers/net/wireless/rtl8187_dev.c
@@ -261,8 +261,8 @@ static void rtl8187_rx_cb(struct urb *urb)
}
rx_status.antenna = (hdr->signal >> 7) & 1;
- rx_status.signal = 64 - min(hdr->noise, (u8)64);
- rx_status.ssi = signal;
+ rx_status.qual = 64 - min(hdr->noise, (u8)64);
+ rx_status.signal = signal;
rx_status.rate_idx = rate;
rx_status.freq = dev->conf.channel->center_freq;
rx_status.band = dev->conf.channel->band;
@@ -737,11 +737,10 @@ static int __devinit rtl8187_probe(struct usb_interface *intf,
priv->mode = IEEE80211_IF_TYPE_MNTR;
dev->flags = IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING |
- IEEE80211_HW_RX_INCLUDES_FCS;
+ IEEE80211_HW_RX_INCLUDES_FCS |
+ IEEE80211_HW_SIGNAL_UNSPEC;
dev->extra_tx_headroom = sizeof(struct rtl8187_tx_hdr);
dev->queues = 1;
- dev->max_rssi = 65;
- dev->max_signal = 64;
eeprom.data = dev;
eeprom.register_read = rtl8187_eeprom_register_read;
diff --git a/drivers/net/wireless/zd1211rw/zd_mac.c b/drivers/net/wireless/zd1211rw/zd_mac.c
index 69c45ca..335f2d0 100644
--- a/drivers/net/wireless/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/zd1211rw/zd_mac.c
@@ -638,7 +638,7 @@ static int filter_ack(struct ieee80211_hw *hw, struct ieee80211_hdr *rx_hdr,
memset(&status, 0, sizeof(status));
status.flags = IEEE80211_TX_STATUS_ACK;
- status.ack_signal = stats->ssi;
+ status.ack_signal = stats->signal;
__skb_unlink(skb, q);
tx_status(hw, skb, &status, 1);
goto out;
@@ -691,8 +691,8 @@ int zd_mac_rx(struct ieee80211_hw *hw, const u8 *buffer, unsigned int length)
stats.freq = zd_channels[_zd_chip_get_channel(&mac->chip) - 1].center_freq;
stats.band = IEEE80211_BAND_2GHZ;
- stats.ssi = status->signal_strength;
- stats.signal = zd_rx_qual_percent(buffer,
+ stats.signal = status->signal_strength;
+ stats.qual = zd_rx_qual_percent(buffer,
length - sizeof(struct rx_status),
status);
@@ -982,9 +982,8 @@ struct ieee80211_hw *zd_mac_alloc_hw(struct usb_interface *intf)
hw->wiphy->bands[IEEE80211_BAND_2GHZ] = &mac->band;
hw->flags = IEEE80211_HW_RX_INCLUDES_FCS |
- IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE;
- hw->max_rssi = 100;
- hw->max_signal = 100;
+ IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE |
+ IEEE80211_HW_SIGNAL_DB;
hw->queues = 1;
hw->extra_tx_headroom = sizeof(struct zd_ctrlset);
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 48428a6..b7f1e0e 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -329,13 +329,16 @@ enum mac80211_rx_flags {
* The low-level driver should provide this information (the subset
* supported by hardware) to the 802.11 code with each received
* frame.
+ *
* @mactime: value in microseconds of the 64-bit Time Synchronization Function
* (TSF) timer when the first data symbol (MPDU) arrived at the hardware.
* @band: the active band when this frame was received
* @freq: frequency the radio was tuned to when receiving this frame, in MHz
- * @ssi: signal strength when receiving this frame
- * @signal: used as 'qual' in statistics reporting
- * @noise: PHY noise when receiving this frame
+ * @signal: signal strength when receiving this frame, either in dBm, in dB or
+ * unspecified depending on the hardware capabilities flags
+ * @IEEE80211_HW_SIGNAL_*
+ * @noise: noise when receiving this frame, in dBm.
+ * @qual: overall signal quality indication, in percent (0-100).
* @antenna: antenna used
* @rate_idx: index of data rate into band's supported rates
* @flag: %RX_FLAG_*
@@ -344,9 +347,9 @@ struct ieee80211_rx_status {
u64 mactime;
enum ieee80211_band band;
int freq;
- int ssi;
int signal;
int noise;
+ int qual;
int antenna;
int rate_idx;
int flag;
@@ -385,7 +388,8 @@ enum ieee80211_tx_status_flags {
* relevant only if IEEE80211_TX_STATUS_AMPDU was set.
* @ampdu_ack_map: block ack bit map for the aggregation.
* relevant only if IEEE80211_TX_STATUS_AMPDU was set.
- * @ack_signal: signal strength of the ACK frame
+ * @ack_signal: signal strength of the ACK frame either in dBm, dB or unspec
+ * depending on hardware capabilites flags @IEEE80211_HW_SIGNAL_*
* @queue_length: ?? REMOVE
* @queue_number: ?? REMOVE
*/
@@ -697,6 +701,24 @@ enum ieee80211_tkip_key_type {
* @IEEE80211_HW_2GHZ_SHORT_PREAMBLE_INCAPABLE:
* Hardware is not capable of receiving frames with short preamble on
* the 2.4 GHz band.
+ *
+ * @IEEE80211_HW_SIGNAL_UNSPEC:
+ * Hardware can provide signal values but we don't know its units. To be
+ * able to standardize between different devices we would like linear
+ * values from 0-100. If possible please provide dB or dBm instead.
+ *
+ * @IEEE80211_HW_SIGNAL_DB:
+ * Hardware gives signal values in dB, decibel difference from an
+ * arbitrary, fixed reference. If possible please provide dBm instead.
+ *
+ * @IEEE80211_HW_SIGNAL_DBM:
+ * Hardware gives signal values in dBm, decibel difference from
+ * one milliwatt. This is the preferred method since it is standardized
+ * between different devices.
+ *
+ * @IEEE80211_HW_NOISE_DBM:
+ * Hardware can provide noise floor values in units dBm, decibel difference
+ * from one milliwatt.
*/
enum ieee80211_hw_flags {
IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE = 1<<0,
@@ -704,6 +726,10 @@ enum ieee80211_hw_flags {
IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING = 1<<2,
IEEE80211_HW_2GHZ_SHORT_SLOT_INCAPABLE = 1<<3,
IEEE80211_HW_2GHZ_SHORT_PREAMBLE_INCAPABLE = 1<<4,
+ IEEE80211_HW_SIGNAL_UNSPEC = 1<<5,
+ IEEE80211_HW_SIGNAL_DB = 1<<6,
+ IEEE80211_HW_SIGNAL_DBM = 1<<7,
+ IEEE80211_HW_NOISE_DBM = 1<<8,
};
/**
@@ -734,13 +760,6 @@ enum ieee80211_hw_flags {
*
* @channel_change_time: time (in microseconds) it takes to change channels.
*
- * @max_rssi: Maximum value for ssi in RX information, use
- * negative numbers for dBm and 0 to indicate no support.
- *
- * @max_signal: like @max_rssi, but for the signal value.
- *
- * @max_noise: like @max_rssi, but for the noise value.
- *
* @queues: number of available hardware transmit queues for
* data packets. WMM/QoS requires at least four.
*
@@ -762,9 +781,6 @@ struct ieee80211_hw {
int channel_change_time;
int vif_data_size;
u8 queues;
- s8 max_rssi;
- s8 max_signal;
- s8 max_noise;
};
/**
diff --git a/net/ieee80211/ieee80211_rx.c b/net/ieee80211/ieee80211_rx.c
index 1e3f87c..c5d7e4c 100644
--- a/net/ieee80211/ieee80211_rx.c
+++ b/net/ieee80211/ieee80211_rx.c
@@ -385,7 +385,7 @@ int ieee80211_rx(struct ieee80211_device *ieee, struct sk_buff *skb,
wstats.updated = 0;
if (rx_stats->mask & IEEE80211_STATMASK_RSSI) {
- wstats.level = rx_stats->rssi;
+ wstats.level = rx_stats->signal;
wstats.updated |= IW_QUAL_LEVEL_UPDATED;
} else
wstats.updated |= IW_QUAL_LEVEL_INVALID;
diff --git a/net/mac80211/debugfs_sta.c b/net/mac80211/debugfs_sta.c
index fc2c1a1..04216c2 100644
--- a/net/mac80211/debugfs_sta.c
+++ b/net/mac80211/debugfs_sta.c
@@ -63,8 +63,8 @@ STA_FILE(tx_fragments, tx_fragments, LU);
STA_FILE(tx_filtered, tx_filtered_count, LU);
STA_FILE(tx_retry_failed, tx_retry_failed, LU);
STA_FILE(tx_retry_count, tx_retry_count, LU);
-STA_FILE(last_rssi, last_rssi, D);
STA_FILE(last_signal, last_signal, D);
+STA_FILE(last_qual, last_qual, D);
STA_FILE(last_noise, last_noise, D);
STA_FILE(channel_use, channel_use, D);
STA_FILE(wep_weak_iv_count, wep_weak_iv_count, LU);
diff --git a/net/mac80211/ieee80211.c b/net/mac80211/ieee80211.c
index 616ce10..a484443 100644
--- a/net/mac80211/ieee80211.c
+++ b/net/mac80211/ieee80211.c
@@ -1643,13 +1643,13 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
local->hw.conf.beacon_int = 1000;
- local->wstats_flags |= local->hw.max_rssi ?
- IW_QUAL_LEVEL_UPDATED : IW_QUAL_LEVEL_INVALID;
- local->wstats_flags |= local->hw.max_signal ?
+ local->wstats_flags |= local->hw.flags & (IEEE80211_HW_SIGNAL_UNSPEC |
+ IEEE80211_HW_SIGNAL_DB |
+ IEEE80211_HW_SIGNAL_DBM) ?
IW_QUAL_QUAL_UPDATED : IW_QUAL_QUAL_INVALID;
- local->wstats_flags |= local->hw.max_noise ?
+ local->wstats_flags |= local->hw.flags & IEEE80211_HW_NOISE_DBM ?
IW_QUAL_NOISE_UPDATED : IW_QUAL_NOISE_INVALID;
- if (local->hw.max_rssi < 0 || local->hw.max_noise < 0)
+ if (local->hw.flags & IEEE80211_HW_SIGNAL_DBM)
local->wstats_flags |= IW_QUAL_DBM;
result = sta_info_start(local);
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index a6485f0..2b5aa3f 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -81,7 +81,7 @@ struct ieee80211_sta_bss {
u16 capability; /* host byte order */
enum ieee80211_band band;
int freq;
- int rssi, signal, noise;
+ int signal, noise, qual;
u8 *wpa_ie;
size_t wpa_ie_len;
u8 *rsn_ie;
diff --git a/net/mac80211/ieee80211_ioctl.c b/net/mac80211/ieee80211_ioctl.c
index 5af23d3..731ecd2 100644
--- a/net/mac80211/ieee80211_ioctl.c
+++ b/net/mac80211/ieee80211_ioctl.c
@@ -158,12 +158,20 @@ static int ieee80211_ioctl_giwrange(struct net_device *dev,
range->num_encoding_sizes = 2;
range->max_encoding_tokens = NUM_DEFAULT_KEYS;
- range->max_qual.qual = local->hw.max_signal;
- range->max_qual.level = local->hw.max_rssi;
- range->max_qual.noise = local->hw.max_noise;
+ range->max_qual.level = 0;
+ if (local->hw.flags & IEEE80211_HW_SIGNAL_UNSPEC)
+ range->max_qual.level = 100;
+ else if (local->hw.flags & IEEE80211_HW_SIGNAL_DB)
+ /* this is pretty arbitrary but the range of most drivers */
+ range->max_qual.level = 64;
+ else if (local->hw.flags & IEEE80211_HW_SIGNAL_DBM)
+ range->max_qual.level = -110;
+
+ range->max_qual.noise = -110;
+ range->max_qual.qual = 100;
range->max_qual.updated = local->wstats_flags;
- range->avg_qual.qual = local->hw.max_signal/2;
+ range->avg_qual.qual = 0;
range->avg_qual.level = 0;
range->avg_qual.noise = 0;
range->avg_qual.updated = local->wstats_flags;
@@ -974,8 +982,8 @@ static struct iw_statistics *ieee80211_get_wireless_stats(struct net_device *dev
wstats->qual.noise = 0;
wstats->qual.updated = IW_QUAL_ALL_INVALID;
} else {
- wstats->qual.level = sta->last_rssi;
- wstats->qual.qual = sta->last_signal;
+ wstats->qual.level = sta->last_signal;
+ wstats->qual.qual = sta->last_qual;
wstats->qual.noise = sta->last_noise;
wstats->qual.updated = local->wstats_flags;
}
diff --git a/net/mac80211/ieee80211_sta.c b/net/mac80211/ieee80211_sta.c
index cf51ca6..dccc9a5 100644
--- a/net/mac80211/ieee80211_sta.c
+++ b/net/mac80211/ieee80211_sta.c
@@ -1910,8 +1910,8 @@ static void ieee80211_rx_mgmt_assoc_resp(struct ieee80211_sub_if_data *sdata,
local->hw.conf.channel->center_freq,
ifsta->ssid, ifsta->ssid_len);
if (bss) {
- sta->last_rssi = bss->rssi;
sta->last_signal = bss->signal;
+ sta->last_qual = bss->qual;
sta->last_noise = bss->noise;
ieee80211_rx_bss_put(dev, bss);
}
@@ -2628,9 +2628,9 @@ static void ieee80211_rx_bss_info(struct net_device *dev,
bss->timestamp = beacon_timestamp;
bss->last_update = jiffies;
- bss->rssi = rx_status->ssi;
bss->signal = rx_status->signal;
bss->noise = rx_status->noise;
+ bss->qual = rx_status->qual;
if (!beacon)
bss->probe_resp++;
@@ -3335,9 +3335,9 @@ static int ieee80211_sta_config_auth(struct net_device *dev,
!ieee80211_sta_match_ssid(ifsta, bss->ssid, bss->ssid_len))
continue;
- if (!selected || top_rssi < bss->rssi) {
+ if (!selected || top_rssi < bss->signal) {
selected = bss;
- top_rssi = bss->rssi;
+ top_rssi = bss->signal;
}
}
if (selected)
@@ -3966,8 +3966,8 @@ ieee80211_sta_scan_result(struct net_device *dev,
memset(&iwe, 0, sizeof(iwe));
iwe.cmd = IWEVQUAL;
- iwe.u.qual.qual = bss->signal;
- iwe.u.qual.level = bss->rssi;
+ iwe.u.qual.qual = bss->qual;
+ iwe.u.qual.level = bss->signal;
iwe.u.qual.noise = bss->noise;
iwe.u.qual.updated = local->wstats_flags;
current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe,
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 644d277..c1efdcf 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -209,7 +209,7 @@ ieee80211_rx_monitor(struct ieee80211_local *local, struct sk_buff *origskb,
cpu_to_le16(IEEE80211_CHAN_DYN |
IEEE80211_CHAN_2GHZ);
- rtfixed->antsignal = status->ssi;
+ rtfixed->antsignal = status->signal;
rthdr->it_len = cpu_to_le16(rtap_len);
}
@@ -725,8 +725,8 @@ ieee80211_rx_h_sta_process(struct ieee80211_rx_data *rx)
sta->rx_fragments++;
sta->rx_bytes += rx->skb->len;
- sta->last_rssi = rx->status->ssi;
sta->last_signal = rx->status->signal;
+ sta->last_qual = rx->status->qual;
sta->last_noise = rx->status->noise;
if (!(rx->fc & IEEE80211_FCTL_MOREFRAGS)) {
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index f166c80..63b0f30 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -214,8 +214,8 @@ struct sta_info {
* from this STA */
unsigned long rx_fragments; /* number of received MPDUs */
unsigned long rx_dropped; /* number of dropped MPDUs from this STA */
- int last_rssi; /* RSSI of last received frame from this STA */
int last_signal; /* signal of last received frame from this STA */
+ int last_qual; /* qual of last received frame from this STA */
int last_noise; /* noise of last received frame from this STA */
/* last received seq/frag number from this STA (per RX queue) */
__le16 last_seq_ctrl[NUM_RX_DATA_QUEUES];
On Thursday 27 March 2008 21:47:43 Johannes Berg wrote:
> On Wed, 2008-03-26 at 21:30 +0900, Bruno Randolf wrote:
> > trying to clean up the signal/noise mess. the previous code in mac80211
> > did not have much definition of what units of signal and noise were
> > provided and used weird implicit mechanisms from the wireless extensions.
> >
> > introduce hardware capability flags to let the hardware specify if it can
> > provide signal and noise level values and which units it can provide:
> >
> > IEEE80211_HW_SIGNAL_UNSPEC - unspecified, unknown, hw specific
> > IEEE80211_HW_SIGNAL_DB - dB difference to unspecified reference
> > point IEEE80211_HW_SIGNAL_DBM - dBm, difference to 1mW
> >
> > IEEE80211_HW_NOISE_DBM - dBm, difference to 1mW
> >
> > also clean up the misleading and confusing names which were used for
> > signal, noise and qual before.
>
> I have to admit to not particularly caring about these things, so if
> you're willing to accept responsibility for all breakage I'm ok with the
> patch going in :)
well, i'm going to - for whatever that means :)
i have compile tested the current patch with all mac80211 based drivers, i
believe and function tested with ath5k and iwl4965 - but lets give the driver
authors some more time for feedback and review. also i'd like to integrate
jean's suggestion that unspec doesn't have to be linear.
bruno
hi jean!
i really appreciate your input based on your experiences with the wireless
extensions!
On Thursday 27 March 2008 09:19:09 Jean Tourrilhes wrote:
> Now, we would like all hardware to report RSSI in dBm, and get
> done with it.
i definetly agree with that. dBm is what we want!
> However, some hardware (Atheros) can not do it, because
> their RSSI hardware is uncalibrated. So, what do you do with those
> hardware ? Reporting a "relative" signal strength is probably better
> than nothing.
can you explain why you think atheros HW is "relative"?
in the past in madwifi RSSI was said to be measured against a fixed noise
value of -95dBm (which should be expressed by using _SIGNAL_DB in my patch)
but now we have a periodic noise floor calibration and we assume RSSI to be
relative to that, so we believe to be able to provide dBm for both values.
that's how it is currently reported in madwifi and ath5k and what we believe
to be correct (without having much documentation from atheros, however) - if
that's not correct we have to modify the drivers.
> Note also that many hardware are not truly calibrated, but
> "sort of" calibrated (Orinoco, HostAP). Good measurement is expensive,
> that's why most implementation do measurement on the cheap. It means
> the value will be correct within some few percents for a large part
> range. Up to now, we pretented that those devices report dBm
> properly. That's why RCPTI talk of expected accuracy of measurement.
hmm, accuracy is another question. i think at the moment as long as the device
tries to report dBm i would say it's dBm no matter what the accuracy is. in
the future, when we know more about the devices we can add some hw flags or
variables which can state that accuracy of the signal/noise measurements.
> Clearly, you have to think hard and define is the reference is
> fixed (as stated above) or variable (Atheros). The fixed reference
> could be more useful to apps, but I don't know how many HW would fit
> that definition. The variable reference would accomodate the Atheros
> nicely.
again, please tell us more about atheros. we believe RSSI to be relative to
the noise floor, which we can measure. therefore we have dBm for both.
> And of course, the main question to ask is, is this extra
> functionality worth the additional complexity of the API, and the
> potential confusion to users. I don't know, but for WE the answer was
> no.
sorry jean, no offense, but the usage of these values in WE was really
confusing and the lack of knowing what the values acutally mean made it
really hard for applications to work with them. i think it is worth the
effort to make that clearer and explicity state the HW capabilities instead
of using implicit mechanisms so applications can know more exactly what to
expect. applications which would have benefits from that would include
NetworkManager, roaming agents, link metric calculations for mesh
networks,...
> Note also that you may need an agregate measure of how good
> the link is, but that would be best generated by the stack itself. I
> guess for most devices, the bitrate in use will tell you that kind of
> information.
once we have the signal units properly specified by the HW we can and should
do things like this in mac80211 - i think we should move the "qual" link
quality calculation up into mac80211 so it will be the same for all devices.
> > > + *
> > > + * @IEEE80211_HW_SIGNAL_UNSPEC:
> > > + * Hardware can provide signal values but we don't know its
> > > units. To be + * able to standardize between different devices we
> > > would like linear + * values from 0-100. If possible please provide
> > > dB or dBm instead.
>
> Note that for some hardware, you can not get liner values (see
> above).
ok, good point! i think we should remove that from the definition then.
> Anyway, what does linear means, is it linear on a log/dBm
> scale or on a power/mW scale ?
linear would mean linar on whatever units the device uses (might be a power/mW
scale). log/dBM i would call "logarithmic". but anyhow, as you said not all
devices can do linear, so i would tend to remove that from the definition and
just say "totally unspecified".
if the need arises we could invent 2 different flags like
IEEE80211_HW_SIGNAL_UNSPEC_LOG and IEEE80211_HW_SIGNAL_UNSPEC_LINEAR but i
think that would be overkill right now.
> > > + * @IEEE80211_HW_NOISE_DBM:
> > > + * Hardware can provide noise floor values in units dBm, decibel
> > > difference + * from one milliwatt.
>
> Noise only defined in dBm ? Some older devices have noise in
> "unspec". I also don't know what Atheros does here.
so far as far as i can see drivers either know the noise in dBm or don't know
it at all. if there is HW which has "unspec" we can add that.
bruno
On Wed, Mar 26, 2008 at 06:59:11PM -0400, Luis R. Rodriguez wrote:
> Jean a question or two for you below.
>=20
> OK I know I seemed happy with the original patch but after some
> thought I have some concerns. They are below.
Hi there,
I'm, currently on business trip. I'll try to answer the best I
can. Ping me again next week.
Note that I did not define what went into mac80211.h, and I
disclaim any responsability from that.
My idea is that the API should be based on real physical
measurable values as much as possible. The tradeoff is that those
values should also be useful, often raw values are useless.
> On Wed, Mar 26, 2008 at 8:30 AM, Bruno Randolf <[email protected]> =
wrote:
>=20
> > diff --git a/include/net/mac80211.h b/include/net/mac80211.h
>=20
> > @@ -697,6 +701,24 @@ enum ieee80211_tkip_key_type {
> > * @IEEE80211_HW_2GHZ_SHORT_PREAMBLE_INCAPABLE:
> > * Hardware is not capable of receiving frames with short prea=
mble on
> > * the 2.4 GHz band.
> > + *
> > + * @IEEE80211_HW_SIGNAL_DB:
> > + * Hardware gives signal values in dB, decibel difference fro=
m an
> > + * arbitrary, fixed reference. If possible please provide dBm=
instead.
> > + *
>=20
> Signal should given in either be in dBm or an unspecified value. Sinc=
e
> we have "unspecified" not sure why we would have the "db" value. Can
> you clarify what the difference between "unspecified" and "db" would
> be? I don't think it makes sense to refer to signal with a "db" value=
,
> unless we want "singal" here to be able to mean SNR.
Having a absolute signal measurement is very interesting to
some applications. A signal in dBm tells you how "far" radio wise you
are from the AP, and you may use it for roaming. Also, if you want to
do localisation (triangulation) using RSSI, you need the signal in
dBm.
SNR is useful, but less, and can be calculated using both the
signal and the noise value. That's why I did not include it in the WE
API. SNR could be used to pick the most appropriate bit rate for
example.
The most common unit for the RSSI is dBm, but I see that IEEE
is using RCPTI. I personally don't like RCPTI because it's more
opaque, people are physically measuring dBm, and are having transmit,
gain and loss measured in dBs. That's why I think it's important that
the unit used for that value be dBm.
Now, we would like all hardware to report RSSI in dBm, and get
done with it. However, some hardware (Atheros) can not do it, because
their RSSI hardware is uncalibrated. So, what do you do with those
hardware ? Reporting a "relative" signal strength is probably better
than nothing.
Note that it could be uncalibrated in two way. One way is the
offset (like the Atheros), the other is the slope (older hardware). It
means that for some hardware, it does not even follow a dB
curve. Uncalibrated usually means that every instance of the hardware
is different and you can't have a global correction factor.
For example, check the Aironet driver. The driver has a RSSI
correction table, for every raw RSSI value, the driver check in a
table to get the RSSI in dBm. The table is stored in the EPROM of the
card, and I believe specific to each card. The correction curve is not
even linear !
For the Atheros, there is another issue, the offset changes
over time and is not constant for the card.
Note also that many hardware are not truly calibrated, but
"sort of" calibrated (Orinoco, HostAP). Good measurement is expensive,
that's why most implementation do measurement on the cheap. It means
the value will be correct within some few percents for a large part
range. Up to now, we pretented that those devices report dBm
properly. That's why RCPTI talk of expected accuracy of measurement.
So, in WE we have :
o signal is RSSI in dBm, which is the most useful to apps.
o if can't do dBm, do relative, which has no expectations.
Now, back to your question.
This additional value would be cases where only the offset is
uncalibrated and the slope is correct, like the Atheros. What it would
allow is to calculate SNR in dB, which a "unspec" would not allow. If
the offset is constant (as specified above, but not the case for
Atheros), you could compare different value over time and make a
difference in dB.
Clearly, you have to think hard and define is the reference is
fixed (as stated above) or variable (Atheros). The fixed reference
could be more useful to apps, but I don't know how many HW would fit
that definition. The variable reference would accomodate the Atheros
nicely.
Also, with respect to "sort of calibrated" device, you would
have to device if they are dBm or dB. What is the accuracy you expect.
And of course, the main question to ask is, is this extra
functionality worth the additional complexity of the API, and the
potential confusion to users. I don't know, but for WE the answer was
no.
Note also that you may need an agregate measure of how good
the link is, but that would be best generated by the stack itself. I
guess for most devices, the bitrate in use will tell you that kind of
information.
> > + *
> > + * @IEEE80211_HW_SIGNAL_UNSPEC:
> > + * Hardware can provide signal values but we don't know its u=
nits. To be
> > + * able to standardize between different devices we would lik=
e linear
> > + * values from 0-100. If possible please provide dB or dBm in=
stead.
Note that for some hardware, you can not get liner values (see
above). Anyway, what does linear means, is it linear on a log/dBm
scale or on a power/mW scale ?
This is exactly why I introduced avg_qual in WE.
> > + * @IEEE80211_HW_SIGNAL_DBM:
> > + * Hardware gives signal values in dBm, decibel difference fr=
om
> > + * one milliwatt. This is the preferred method since it is st=
andardized
> > + * between different devices.
> > + *
> > + * @IEEE80211_HW_NOISE_DBM:
> > + * Hardware can provide noise floor values in units dBm, deci=
bel difference
> > + * from one milliwatt.
Noise only defined in dBm ? Some older devices have noise in
"unspec". I also don't know what Atheros does here.
> > */
> > enum ieee80211_hw_flags {
> > IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE =3D 1<<0,
> > @@ -704,6 +726,10 @@ enum ieee80211_hw_flags {
> > IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING =3D 1<<2,
> > IEEE80211_HW_2GHZ_SHORT_SLOT_INCAPABLE =3D 1<<3,
> > IEEE80211_HW_2GHZ_SHORT_PREAMBLE_INCAPABLE =3D 1<<4,
> > + IEEE80211_HW_SIGNAL_UNSPEC =3D 1<<5,
> > + IEEE80211_HW_SIGNAL_DB =3D 1<<6,
> > + IEEE80211_HW_SIGNAL_DBM =3D 1<<7,
> > + IEEE80211_HW_NOISE_DBM =3D 1<<8,
> > };
> >
> > /**
>=20
> <-- snip -->
>=20
> > diff --git a/net/mac80211/ieee80211_ioctl.c b/net/mac80211/ieee802=
11_ioctl.c
> > index 5af23d3..731ecd2 100644
> > --- a/net/mac80211/ieee80211_ioctl.c
> > +++ b/net/mac80211/ieee80211_ioctl.c
> > @@ -158,12 +158,20 @@ static int ieee80211_ioctl_giwrange(struct n=
et_device *dev,
> > range->num_encoding_sizes =3D 2;
> > range->max_encoding_tokens =3D NUM_DEFAULT_KEYS;
> >
> > - range->max_qual.qual =3D local->hw.max_signal;
> > - range->max_qual.level =3D local->hw.max_rssi;
> > - range->max_qual.noise =3D local->hw.max_noise;
> > + range->max_qual.level =3D 0;
> > + if (local->hw.flags & IEEE80211_HW_SIGNAL_UNSPEC)
> > + range->max_qual.level =3D 100;
> > + else if (local->hw.flags & IEEE80211_HW_SIGNAL_DB)
> > + /* this is pretty arbitrary but the range of most=
drivers */
> > + range->max_qual.level =3D 64;
> > + else if (local->hw.flags & IEEE80211_HW_SIGNAL_DBM)
> > + range->max_qual.level =3D -110;
> > +
> > + range->max_qual.noise =3D -110;
> > + range->max_qual.qual =3D 100;
> > range->max_qual.updated =3D local->wstats_flags;
>=20
> I'm pretty perplexed by the original intention of Wireless Extensions
> max_qual. The documentation we have for this states:
>=20
> /* Quality of link & SNR stuff */
> /* Quality range (link, level, noise)
> * If the quality is absolute, it will be in the range [0 ; m=
ax_qual],
> * if the quality is dBm, it will be in the range [max_qual ;=
0].
> * Don't forget that we use 8 bit arithmetics... */
> struct iw_quality max_qual; /* Quality of the lin=
k */
>=20
> max_qual is a struct though, iw_quality which is:
>=20
> /*
> * Quality of the link
> */
> struct iw_quality
> {
> __u8 qual; /* link quality (%retries, SN=
R,
> %missed beacons or better.=
=2E.) */
> __u8 level; /* signal level (dBm) */
> __u8 noise; /* noise level (dBm) */
> __u8 updated; /* Flags to know if updated *=
/
> };
>=20
> Jean, if range->max_qual.level is set to -110 does this mean signal
> level can be set only from -110 up to 0 ? Is max_qual.level supposed
> to be the weakest signal possibly detected?
Yes. This is what make most sense.
Remember we also have "avg_qual".
The idea is that if we want to graphically represent the value
on a graph, we need to know the bounds. Think about a
thermometer. Most thermometers show a range of temperature from -20C
to +100C.
Usually, level and noise will have the same range [-110;0],
and qual will have its own range [0-100] or whatever.
> Also, technically the noise should change depending on the channel ba=
ndwidth.
>=20
> IEEE-802.11 Channel bandwidth
> 802.11a 20MHz
> 802.11b 22MHz
> 802.11g 20MHz (except when operating in 802.11b rates)
> 802.11n 20MHz, 40MHz (except when operating in 802.11b rates)
>=20
> Applying the noise power formula:
>=20
> Pn =3D kTB
>=20
> where:
>=20
> k is Boltzmann's constant, 1.38*10^-23 J/K
> T is the temperature in Kelvin (room temperature, 290 K)
> B is the system bandwidth, in Hz
>=20
> Note: Watt =3D J/s
>=20
> For a 1 Hz bandwidth and at 290 K:
>=20
> Pn =3D 1.38 * 10-23 J/K * 290 K * 1 Hz
> Pn =3D 4.00200 * 10^-21 JHz
> Pn =3D 4.00200 * 10^-21 J/s
> Pn =3D 4.00200 * 10^-21 W
> Pn =3D 4.00200 =D7 10-18 mW
>=20
> To convert to Bell, we do log (foo), to deciBell we do 10 * log (foo)
> so: (dBm =3D=3D dBmW)
>=20
> Pn =3D 10 * log (4.00200 * 10^-18) dBm
> Pn =3D ~-173.97722915699807401277 dBm
> Pn =3D ~-174 dBm
>=20
> Now applying the same noise power formula, Pn =3D kTB, and knowing
> already -174dBm applies for each 1 Hz we can compute the power noise
> for each differing bandwidth for 802.11:
>=20
> Pn =3D -174 dBm / Hz + 10 * log (Bandwidth)
>=20
> mcgrof@monster:~$ calc
> C-style arbitrary precision calculator (version 2.12.1.13)
> Calc is open software. For license details type: help copyright
> [Type "exit" to exit, or "help" for help.]
>=20
>=20
> ; -174 + (10 * log(20 * 10^6))
> ~-100.98970004336018804794
> ; -174 + (10 * log(22 * 10^6))
> ~-100.57577319177793764041
> ; -174 + (10 * log(40 * 10^6))
> ~-97.97940008672037609579
>=20
> So I don't see why noise power should be -110, instead how about
> having it set to -101 dBm for 20 MHz and 22 MHz channel bandwidth and
> -98 dBm for 40 MHz channel bandwidth when used? If we want to be even
> more exact we can take into consideration the noise from the amplifie=
r
> chain for the hardware when known; for example for Atheros it seems t=
o
> be known to be 5dBm [1] so the noise for Atheros hardware should
> change to -96 dBm.
Remember, what we care most here is to give a range so that
graphical applications know the bound of the value. We don't need to
be absolutely accurate here. Think about the thermometer example.
Now, what you are talking is the channel noise. Receiver noise
is different, as the receiver chain adds its own noise. Then, if you
use DS (1 MB/s) or other complex modulation, you can have a processing
gain which lower the noise floor. When I looked at the Orinoco at
1Mb/s, I believe the -110 dBm was correct, but I may have got it
wrong.
I think it would be wise to use a value that change as little
as possible, so that the various applications can cache it (well, they
will do it anyway).
But yeah, please use whatever value make sense and give good
result in userspace applications.
> [1] http://madwifi.org/wiki/UserDocs/RSSI
>=20
> Luis
Regards,
Jean
On Thu, Mar 27, 2008 at 11:47:56AM +0900, bruno randolf wrote:
> hi jean!
>
> i really appreciate your input based on your experiences with the wireless
> extensions!
My pleasure, always glad to help ;-)
> > However, some hardware (Atheros) can not do it, because
> > their RSSI hardware is uncalibrated. So, what do you do with those
> > hardware ? Reporting a "relative" signal strength is probably better
> > than nothing.
>
> can you explain why you think atheros HW is "relative"?
>
> in the past in madwifi RSSI was said to be measured against a fixed noise
> value of -95dBm (which should be expressed by using _SIGNAL_DB in my patch)
> but now we have a periodic noise floor calibration and we assume RSSI to be
> relative to that, so we believe to be able to provide dBm for both values.
> that's how it is currently reported in madwifi and ath5k and what we believe
> to be correct (without having much documentation from atheros, however) - if
> that's not correct we have to modify the drivers.
One of my coworkers was doing experiments on interference
measurements. For that, we need to measure the signal strength of
various packets. Those recalibrations throw havoc in our
measurements. In other words, the RSSI we measure is consistent
between recalibration points, but not across those recalibration.
This co-worker was using some NetBSD and not MadWifi, and I
don't know which version, so I can not say for sure if this affect the
current version of MadWifi.
You have to look at what the application wants. The
application wants consistent measurements. You can *NOT* define
properly APIs unless you understand how application will use it.
I don't understand enough about the Atheros hardware (I
haven't used it), but I don't see why you would need to recalibrate
the noise floor and how you could acheive that. Any "noise" you
measure on the channel would be subject to interference and
fading. The only way you could measure some noise with some certainty
would be to ground the antenna and measure.
If you calibrate your RSSI using the noise on the channel, I
believe you are measuring SNR, not signal strength. Of course, I may
be wrong.
> > Note also that many hardware are not truly calibrated, but
> > "sort of" calibrated (Orinoco, HostAP). Good measurement is expensive,
> > that's why most implementation do measurement on the cheap. It means
> > the value will be correct within some few percents for a large part
> > range. Up to now, we pretented that those devices report dBm
> > properly. That's why RCPTI talk of expected accuracy of measurement.
>
> hmm, accuracy is another question. i think at the moment as long as the device
> tries to report dBm i would say it's dBm no matter what the accuracy is. in
> the future, when we know more about the devices we can add some hw flags or
> variables which can state that accuracy of the signal/noise measurements.
Yes, that's the practical and sane way to do it.
> again, please tell us more about atheros. we believe RSSI to be relative to
> the noise floor, which we can measure. therefore we have dBm for both.
RSSI is absolute, like transmit power. Anything relative to
the noise floor is SNR, in dB.
http://en.wikipedia.org/wiki/DBm
> sorry jean, no offense, but the usage of these values in WE was really
> confusing and the lack of knowing what the values acutally mean made it
> really hard for applications to work with them.
Everybody is entitled to their opinion. Those values were
clearly documenteed but nobody bothered to read the documentation.
> > Note also that you may need an agregate measure of how good
> > the link is, but that would be best generated by the stack itself. I
> > guess for most devices, the bitrate in use will tell you that kind of
> > information.
>
> once we have the signal units properly specified by the HW we can and should
> do things like this in mac80211 - i think we should move the "qual" link
> quality calculation up into mac80211 so it will be the same for all devices.
Ideally, qual should aggregate as many measurements as
possible, such as RSSI, noise, packet loss, beacon loss, etc... I
think Bill Moss did some work in that direction in the ipw2*00
drivers.
As I said above, I agree that it should probably be deal in
the stack.
> > Anyway, what does linear means, is it linear on a log/dBm
> > scale or on a power/mW scale ?
>
> linear would mean linar on whatever units the device uses (might be a power/mW
> scale). log/dBM i would call "logarithmic". but anyhow, as you said not all
> devices can do linear, so i would tend to remove that from the definition and
> just say "totally unspecified".
For most of those systems, linear measurement is not very
useful, and I believe most measurements are "sort of dB", i.e. closer
to log scale than linear.
> > Noise only defined in dBm ? Some older devices have noise in
> > "unspec". I also don't know what Atheros does here.
>
> so far as far as i can see drivers either know the noise in dBm or don't know
> it at all. if there is HW which has "unspec" we can add that.
Anyway, those old harware that did not do dBm are going the
way of dinausors, so we probably should not care that much about them.
> bruno
Regards,
Jean
On Thursday 27 March 2008 07:59:11 Luis R. Rodriguez wrote:
> > + * @IEEE80211_HW_SIGNAL_UNSPEC:
> > + * Hardware can provide signal values but we don't know its units.
> > To be + * able to standardize between different devices we would like
> > linear + * values from 0-100. If possible please provide dB or dBm
> > instead. + *
> > + * @IEEE80211_HW_SIGNAL_DB:
> > + * Hardware gives signal values in dB, decibel difference from an
> > + * arbitrary, fixed reference. If possible please provide dBm
> > instead. + *
>
> Signal should given in either be in dBm or an unspecified value. Since
> we have "unspecified" not sure why we would have the "db" value. Can
> you clarify what the difference between "unspecified" and "db" would
> be? I don't think it makes sense to refer to signal with a "db" value,
> unless we want "singal" here to be able to mean SNR.
the best thing to specify is dBm and all drivers should try to do that. it's
the only absolute value which makes sense and can be compared between
different drivers and devices.
however as we know some drivers simply cannot provide that. instead they have
some form of RSSI - RSSI in general meaning nothing more than "received
signal strength indication", which could be *anything*: voltage, any numbers,
in dB or linear or whatever. RSSI does *not* in general mean SNR! for example
you might remember the values of prism54, they were somewhere around 200. or
prism2 cards which had something around 100 (it's been a while since i've
touched them, so that might have changed). as jean noted the values don't
even have to be linear - so i think we should remove that from the
definition.
so in the "unspecified" case we really don't know much about the units, in the
worst case we can't even assume that 1/2 the value will mean 1/2 of the
received signal strength. it's very hard to work with this values, but it's
better than nothing.
other cards might not have noise, so no absolute (dBm) measurement, but a form
of RSSI which is measured in dB (that is a logarithmic difference). in this
case we might not know which reference point the measurement is taken to, but
we know how it behaves: -3 dB means half of the signal strength. if you add a
6dB gain antenna you can expect to see the signal reading to increase by 6dB.
it's not strictly SNR (because we don't know the noise) but quite close to
it.
i think it's important to know the difference between this 3 cases i order to
make some sense of the values in userspace gui, roaming agents, mesh link
metrics, etc...
bruno
SmVhbiBhIHF1ZXN0aW9uIG9yIHR3byBmb3IgeW91IGJlbG93LgoKT0sgSSBrbm93IEkgc2VlbWVk
IGhhcHB5IHdpdGggdGhlIG9yaWdpbmFsIHBhdGNoIGJ1dCBhZnRlciBzb21lCnRob3VnaHQgSSBo
YXZlIHNvbWUgY29uY2VybnMuIFRoZXkgYXJlIGJlbG93LgoKT24gV2VkLCBNYXIgMjYsIDIwMDgg
YXQgODozMCBBTSwgQnJ1bm8gUmFuZG9sZiA8YnJ1bm9AdGhpbmt0dWJlLmNvbT4gd3JvdGU6Cgo+
ICBkaWZmIC0tZ2l0IGEvaW5jbHVkZS9uZXQvbWFjODAyMTEuaCBiL2luY2x1ZGUvbmV0L21hYzgw
MjExLmgKCj4gIEBAIC02OTcsNiArNzAxLDI0IEBAIGVudW0gaWVlZTgwMjExX3RraXBfa2V5X3R5
cGUgewo+ICAgKiBASUVFRTgwMjExX0hXXzJHSFpfU0hPUlRfUFJFQU1CTEVfSU5DQVBBQkxFOgo+
ICAgKiAgICAgSGFyZHdhcmUgaXMgbm90IGNhcGFibGUgb2YgcmVjZWl2aW5nIGZyYW1lcyB3aXRo
IHNob3J0IHByZWFtYmxlIG9uCj4gICAqICAgICB0aGUgMi40IEdIeiBiYW5kLgo+ICArICoKPiAg
KyAqIEBJRUVFODAyMTFfSFdfU0lHTkFMX1VOU1BFQzoKPiAgKyAqICAgICBIYXJkd2FyZSBjYW4g
cHJvdmlkZSBzaWduYWwgdmFsdWVzIGJ1dCB3ZSBkb24ndCBrbm93IGl0cyB1bml0cy4gVG8gYmUK
PiAgKyAqICAgICBhYmxlIHRvIHN0YW5kYXJkaXplIGJldHdlZW4gZGlmZmVyZW50IGRldmljZXMg
d2Ugd291bGQgbGlrZSBsaW5lYXIKPiAgKyAqICAgICB2YWx1ZXMgZnJvbSAwLTEwMC4gSWYgcG9z
c2libGUgcGxlYXNlIHByb3ZpZGUgZEIgb3IgZEJtIGluc3RlYWQuCj4gICsgKgo+ICArICogQElF
RUU4MDIxMV9IV19TSUdOQUxfREI6Cj4gICsgKiAgICAgSGFyZHdhcmUgZ2l2ZXMgc2lnbmFsIHZh
bHVlcyBpbiBkQiwgZGVjaWJlbCBkaWZmZXJlbmNlIGZyb20gYW4KPiAgKyAqICAgICBhcmJpdHJh
cnksIGZpeGVkIHJlZmVyZW5jZS4gSWYgcG9zc2libGUgcGxlYXNlIHByb3ZpZGUgZEJtIGluc3Rl
YWQuCj4gICsgKgoKU2lnbmFsIHNob3VsZCBnaXZlbiBpbiBlaXRoZXIgYmUgaW4gZEJtIG9yIGFu
IHVuc3BlY2lmaWVkIHZhbHVlLiBTaW5jZQp3ZSBoYXZlICJ1bnNwZWNpZmllZCIgbm90IHN1cmUg
d2h5IHdlIHdvdWxkIGhhdmUgdGhlICJkYiIgdmFsdWUuIENhbgp5b3UgY2xhcmlmeSB3aGF0IHRo
ZSBkaWZmZXJlbmNlIGJldHdlZW4gInVuc3BlY2lmaWVkIiBhbmQgImRiIiB3b3VsZApiZT8gSSBk
b24ndCB0aGluayBpdCBtYWtlcyBzZW5zZSB0byByZWZlciB0byBzaWduYWwgd2l0aCBhICJkYiIg
dmFsdWUsCnVubGVzcyB3ZSB3YW50ICJzaW5nYWwiIGhlcmUgdG8gYmUgYWJsZSB0byBtZWFuIFNO
Ui4KCj4gICsgKiBASUVFRTgwMjExX0hXX1NJR05BTF9EQk06Cj4gICsgKiAgICAgSGFyZHdhcmUg
Z2l2ZXMgc2lnbmFsIHZhbHVlcyBpbiBkQm0sIGRlY2liZWwgZGlmZmVyZW5jZSBmcm9tCj4gICsg
KiAgICAgb25lIG1pbGxpd2F0dC4gVGhpcyBpcyB0aGUgcHJlZmVycmVkIG1ldGhvZCBzaW5jZSBp
dCBpcyBzdGFuZGFyZGl6ZWQKPiAgKyAqICAgICBiZXR3ZWVuIGRpZmZlcmVudCBkZXZpY2VzLgo+
ICArICoKPiAgKyAqIEBJRUVFODAyMTFfSFdfTk9JU0VfREJNOgo+ICArICogICAgIEhhcmR3YXJl
IGNhbiBwcm92aWRlIG5vaXNlIGZsb29yIHZhbHVlcyBpbiB1bml0cyBkQm0sIGRlY2liZWwgZGlm
ZmVyZW5jZQo+ICArICogICAgIGZyb20gb25lIG1pbGxpd2F0dC4KPiAgICovCj4gICBlbnVtIGll
ZWU4MDIxMV9od19mbGFncyB7Cj4gICAgICAgICBJRUVFODAyMTFfSFdfSE9TVF9HRU5fQkVBQ09O
X1RFTVBMQVRFICAgICAgICAgICA9IDE8PDAsCj4gIEBAIC03MDQsNiArNzI2LDEwIEBAIGVudW0g
aWVlZTgwMjExX2h3X2ZsYWdzIHsKPiAgICAgICAgIElFRUU4MDIxMV9IV19IT1NUX0JST0FEQ0FT
VF9QU19CVUZGRVJJTkcgICAgICAgID0gMTw8MiwKPiAgICAgICAgIElFRUU4MDIxMV9IV18yR0ha
X1NIT1JUX1NMT1RfSU5DQVBBQkxFICAgICAgICAgID0gMTw8MywKPiAgICAgICAgIElFRUU4MDIx
MV9IV18yR0haX1NIT1JUX1BSRUFNQkxFX0lOQ0FQQUJMRSAgICAgID0gMTw8NCwKPiAgKyAgICAg
ICBJRUVFODAyMTFfSFdfU0lHTkFMX1VOU1BFQyAgICAgICAgICAgICAgICAgICAgICA9IDE8PDUs
Cj4gICsgICAgICAgSUVFRTgwMjExX0hXX1NJR05BTF9EQiAgICAgICAgICAgICAgICAgICAgICAg
ICAgPSAxPDw2LAo+ICArICAgICAgIElFRUU4MDIxMV9IV19TSUdOQUxfREJNICAgICAgICAgICAg
ICAgICAgICAgICAgID0gMTw8NywKPiAgKyAgICAgICBJRUVFODAyMTFfSFdfTk9JU0VfREJNICAg
ICAgICAgICAgICAgICAgICAgICAgICA9IDE8PDgsCj4gICB9Owo+Cj4gICAvKioKCjwtLSBzbmlw
IC0tPgoKPiAgZGlmZiAtLWdpdCBhL25ldC9tYWM4MDIxMS9pZWVlODAyMTFfaW9jdGwuYyBiL25l
dC9tYWM4MDIxMS9pZWVlODAyMTFfaW9jdGwuYwo+ICBpbmRleCA1YWYyM2QzLi43MzFlY2QyIDEw
MDY0NAo+ICAtLS0gYS9uZXQvbWFjODAyMTEvaWVlZTgwMjExX2lvY3RsLmMKPiAgKysrIGIvbmV0
L21hYzgwMjExL2llZWU4MDIxMV9pb2N0bC5jCj4gIEBAIC0xNTgsMTIgKzE1OCwyMCBAQCBzdGF0
aWMgaW50IGllZWU4MDIxMV9pb2N0bF9naXdyYW5nZShzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LAo+
ICAgICAgICAgcmFuZ2UtPm51bV9lbmNvZGluZ19zaXplcyA9IDI7Cj4gICAgICAgICByYW5nZS0+
bWF4X2VuY29kaW5nX3Rva2VucyA9IE5VTV9ERUZBVUxUX0tFWVM7Cj4KPiAgLSAgICAgICByYW5n
ZS0+bWF4X3F1YWwucXVhbCA9IGxvY2FsLT5ody5tYXhfc2lnbmFsOwo+ICAtICAgICAgIHJhbmdl
LT5tYXhfcXVhbC5sZXZlbCA9IGxvY2FsLT5ody5tYXhfcnNzaTsKPiAgLSAgICAgICByYW5nZS0+
bWF4X3F1YWwubm9pc2UgPSBsb2NhbC0+aHcubWF4X25vaXNlOwo+ICArICAgICAgIHJhbmdlLT5t
YXhfcXVhbC5sZXZlbCA9IDA7Cj4gICsgICAgICAgaWYgKGxvY2FsLT5ody5mbGFncyAmIElFRUU4
MDIxMV9IV19TSUdOQUxfVU5TUEVDKQo+ICArICAgICAgICAgICAgICAgcmFuZ2UtPm1heF9xdWFs
LmxldmVsID0gMTAwOwo+ICArICAgICAgIGVsc2UgaWYgIChsb2NhbC0+aHcuZmxhZ3MgJiBJRUVF
ODAyMTFfSFdfU0lHTkFMX0RCKQo+ICArICAgICAgICAgICAgICAgIC8qIHRoaXMgaXMgcHJldHR5
IGFyYml0cmFyeSBidXQgdGhlIHJhbmdlIG9mIG1vc3QgZHJpdmVycyAqLwo+ICArICAgICAgICAg
ICAgICAgIHJhbmdlLT5tYXhfcXVhbC5sZXZlbCA9IDY0Owo+ICArICAgICAgIGVsc2UgaWYgIChs
b2NhbC0+aHcuZmxhZ3MgJiBJRUVFODAyMTFfSFdfU0lHTkFMX0RCTSkKPiAgKyAgICAgICAgICAg
ICAgIHJhbmdlLT5tYXhfcXVhbC5sZXZlbCA9IC0xMTA7Cj4gICsKPiAgKyAgICAgICByYW5nZS0+
bWF4X3F1YWwubm9pc2UgPSAtMTEwOwo+ICArICAgICAgIHJhbmdlLT5tYXhfcXVhbC5xdWFsID0g
MTAwOwo+ICAgICAgICAgcmFuZ2UtPm1heF9xdWFsLnVwZGF0ZWQgPSBsb2NhbC0+d3N0YXRzX2Zs
YWdzOwoKSSdtIHByZXR0eSBwZXJwbGV4ZWQgYnkgdGhlIG9yaWdpbmFsIGludGVudGlvbiBvZiBX
aXJlbGVzcyBFeHRlbnNpb25zCm1heF9xdWFsLiBUaGUgZG9jdW1lbnRhdGlvbiB3ZSBoYXZlIGZv
ciB0aGlzIHN0YXRlczoKCiAgICAgICAgLyogUXVhbGl0eSBvZiBsaW5rICYgU05SIHN0dWZmICov
CiAgICAgICAgLyogUXVhbGl0eSByYW5nZSAobGluaywgbGV2ZWwsIG5vaXNlKQogICAgICAgICAq
IElmIHRoZSBxdWFsaXR5IGlzIGFic29sdXRlLCBpdCB3aWxsIGJlIGluIHRoZSByYW5nZSBbMCA7
IG1heF9xdWFsXSwKICAgICAgICAgKiBpZiB0aGUgcXVhbGl0eSBpcyBkQm0sIGl0IHdpbGwgYmUg
aW4gdGhlIHJhbmdlIFttYXhfcXVhbCA7IDBdLgogICAgICAgICAqIERvbid0IGZvcmdldCB0aGF0
IHdlIHVzZSA4IGJpdCBhcml0aG1ldGljcy4uLiAqLwogICAgICAgIHN0cnVjdCBpd19xdWFsaXR5
ICAgICAgIG1heF9xdWFsOyAgICAgICAvKiBRdWFsaXR5IG9mIHRoZSBsaW5rICovCgptYXhfcXVh
bCBpcyBhIHN0cnVjdCB0aG91Z2gsIGl3X3F1YWxpdHkgd2hpY2ggaXM6CgovKgogKiAgICAgIFF1
YWxpdHkgb2YgdGhlIGxpbmsKICovCnN0cnVjdCAgaXdfcXVhbGl0eQp7CiAgICAgICAgX191OCAg
ICAgICAgICAgIHF1YWw7ICAgICAgICAgICAvKiBsaW5rIHF1YWxpdHkgKCVyZXRyaWVzLCBTTlIs
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAlbWlzc2VkIGJlYWNv
bnMgb3IgYmV0dGVyLi4uKSAqLwogICAgICAgIF9fdTggICAgICAgICAgICBsZXZlbDsgICAgICAg
ICAgLyogc2lnbmFsIGxldmVsIChkQm0pICovCiAgICAgICAgX191OCAgICAgICAgICAgIG5vaXNl
OyAgICAgICAgICAvKiBub2lzZSBsZXZlbCAoZEJtKSAqLwogICAgICAgIF9fdTggICAgICAgICAg
ICB1cGRhdGVkOyAgICAgICAgLyogRmxhZ3MgdG8ga25vdyBpZiB1cGRhdGVkICovCn07CgpKZWFu
LCBpZiByYW5nZS0+bWF4X3F1YWwubGV2ZWwgaXMgc2V0IHRvIC0xMTAgZG9lcyB0aGlzIG1lYW4g
c2lnbmFsCmxldmVsIGNhbiBiZSBzZXQgb25seSBmcm9tIC0xMTAgdXAgdG8gMCA/IElzIG1heF9x
dWFsLmxldmVsIHN1cHBvc2VkCnRvIGJlIHRoZSB3ZWFrZXN0IHNpZ25hbCBwb3NzaWJseSBkZXRl
Y3RlZD8KCkFsc28sIHRlY2huaWNhbGx5IHRoZSBub2lzZSBzaG91bGQgY2hhbmdlIGRlcGVuZGlu
ZyBvbiB0aGUgY2hhbm5lbCBiYW5kd2lkdGguCgpJRUVFLTgwMi4xMSAgQ2hhbm5lbCBiYW5kd2lk
dGgKODAyLjExYSAgICAgICAgMjBNSHoKODAyLjExYiAgICAgICAgMjJNSHoKODAyLjExZyAgICAg
ICAgMjBNSHogKGV4Y2VwdCB3aGVuIG9wZXJhdGluZyBpbiA4MDIuMTFiIHJhdGVzKQo4MDIuMTFu
ICAgICAgICAyME1IeiwgNDBNSHogKGV4Y2VwdCB3aGVuIG9wZXJhdGluZyBpbiA4MDIuMTFiIHJh
dGVzKQoKQXBwbHlpbmcgdGhlIG5vaXNlIHBvd2VyIGZvcm11bGE6CgpQbiA9IGtUQgoKd2hlcmU6
CgprIGlzIEJvbHR6bWFubidzIGNvbnN0YW50LCAxLjM4KjEwXi0yMyBKL0sKVCBpcyB0aGUgdGVt
cGVyYXR1cmUgaW4gS2VsdmluIChyb29tIHRlbXBlcmF0dXJlLCAyOTAgSykKQiBpcyB0aGUgc3lz
dGVtIGJhbmR3aWR0aCwgaW4gSHoKCk5vdGU6IFdhdHQgPSBKL3MKCkZvciBhIDEgSHogYmFuZHdp
ZHRoIGFuZCBhdCAyOTAgSzoKClBuID0gMS4zOCAqIDEwLTIzIEovSyAqIDI5MCBLICogMSBIegpQ
biA9IDQuMDAyMDAgKiAxMF4tMjEgSkh6ClBuID0gNC4wMDIwMCAqIDEwXi0yMSBKL3MKUG4gPSA0
LjAwMjAwICogMTBeLTIxIFcKUG4gPSA0LjAwMjAwIMOXIDEwLTE4IG1XCgpUbyBjb252ZXJ0IHRv
IEJlbGwsIHdlIGRvIGxvZyAoZm9vKSwgdG8gZGVjaUJlbGwgd2UgZG8gMTAgKiBsb2cgKGZvbykK
c286IChkQm0gPT0gZEJtVykKClBuID0gMTAgKiBsb2cgKDQuMDAyMDAgKiAxMF4tMTgpIGRCbQpQ
biA9IH4tMTczLjk3NzIyOTE1Njk5ODA3NDAxMjc3IGRCbQpQbiA9IH4tMTc0IGRCbQoKTm93IGFw
cGx5aW5nIHRoZSBzYW1lIG5vaXNlIHBvd2VyIGZvcm11bGEsIFBuID0ga1RCLCBhbmQga25vd2lu
ZwphbHJlYWR5IC0xNzRkQm0gYXBwbGllcyBmb3IgZWFjaCAxIEh6IHdlIGNhbiBjb21wdXRlIHRo
ZSBwb3dlciBub2lzZQpmb3IgZWFjaCBkaWZmZXJpbmcgYmFuZHdpZHRoIGZvciA4MDIuMTE6CgpQ
biA9IC0xNzQgZEJtIC8gSHogKyAxMCAqIGxvZyAoQmFuZHdpZHRoKQoKbWNncm9mQG1vbnN0ZXI6
fiQgY2FsYwpDLXN0eWxlIGFyYml0cmFyeSBwcmVjaXNpb24gY2FsY3VsYXRvciAodmVyc2lvbiAy
LjEyLjEuMTMpCkNhbGMgaXMgb3BlbiBzb2Z0d2FyZS4gRm9yIGxpY2Vuc2UgZGV0YWlscyB0eXBl
OiAgaGVscCBjb3B5cmlnaHQKW1R5cGUgImV4aXQiIHRvIGV4aXQsIG9yICJoZWxwIiBmb3IgaGVs
cC5dCgoKOyAtMTc0ICsgKDEwICogbG9nKDIwICogMTBeNikpCiAgICAgICAgfi0xMDAuOTg5NzAw
MDQzMzYwMTg4MDQ3OTQKOyAtMTc0ICsgKDEwICogbG9nKDIyICogMTBeNikpCiAgICAgICAgfi0x
MDAuNTc1NzczMTkxNzc3OTM3NjQwNDEKOyAtMTc0ICsgKDEwICogbG9nKDQwICogMTBeNikpCiAg
ICAgICAgfi05Ny45Nzk0MDAwODY3MjAzNzYwOTU3OQoKU28gSSBkb24ndCBzZWUgd2h5IG5vaXNl
IHBvd2VyIHNob3VsZCBiZSAtMTEwLCBpbnN0ZWFkIGhvdyBhYm91dApoYXZpbmcgaXQgc2V0IHRv
IC0xMDEgZEJtIGZvciAyMCBNSHogYW5kIDIyIE1IeiBjaGFubmVsIGJhbmR3aWR0aCBhbmQKLTk4
IGRCbSBmb3IgNDAgTUh6IGNoYW5uZWwgYmFuZHdpZHRoIHdoZW4gdXNlZD8gSWYgd2Ugd2FudCB0
byBiZSBldmVuCm1vcmUgZXhhY3Qgd2UgY2FuIHRha2UgaW50byBjb25zaWRlcmF0aW9uIHRoZSBu
b2lzZSBmcm9tIHRoZSBhbXBsaWZpZXIKY2hhaW4gZm9yIHRoZSBoYXJkd2FyZSB3aGVuIGtub3du
OyBmb3IgZXhhbXBsZSBmb3IgQXRoZXJvcyBpdCBzZWVtcyB0bwpiZSBrbm93biB0byBiZSA1ZEJt
IFsxXSBzbyB0aGUgbm9pc2UgZm9yIEF0aGVyb3MgaGFyZHdhcmUgc2hvdWxkCmNoYW5nZSB0byAt
OTYgZEJtLgoKWzFdIGh0dHA6Ly9tYWR3aWZpLm9yZy93aWtpL1VzZXJEb2NzL1JTU0kKCiAgTHVp
cwo=
On Wed, 2008-03-26 at 21:30 +0900, Bruno Randolf wrote:
> trying to clean up the signal/noise mess. the previous code in mac80211 did
> not have much definition of what units of signal and noise were provided and
> used weird implicit mechanisms from the wireless extensions.
>
> introduce hardware capability flags to let the hardware specify if it can
> provide signal and noise level values and which units it can provide:
>
> IEEE80211_HW_SIGNAL_UNSPEC - unspecified, unknown, hw specific
> IEEE80211_HW_SIGNAL_DB - dB difference to unspecified reference point
> IEEE80211_HW_SIGNAL_DBM - dBm, difference to 1mW
>
> IEEE80211_HW_NOISE_DBM - dBm, difference to 1mW
>
> also clean up the misleading and confusing names which were used for signal,
> noise and qual before.
I have to admit to not particularly caring about these things, so if
you're willing to accept responsibility for all breakage I'm ok with the
patch going in :)
johannes
On Friday 28 March 2008 01:52:37 Jean Tourrilhes wrote:
> > can you explain why you think atheros HW is "relative"?
> >
> > in the past in madwifi RSSI was said to be measured against a fixed noise
> > value of -95dBm (which should be expressed by using _SIGNAL_DB in my
> > patch) but now we have a periodic noise floor calibration and we assume
> > RSSI to be relative to that, so we believe to be able to provide dBm for
> > both values. that's how it is currently reported in madwifi and ath5k and
> > what we believe to be correct (without having much documentation from
> > atheros, however) - if that's not correct we have to modify the drivers.
>
> One of my coworkers was doing experiments on interference
> measurements. For that, we need to measure the signal strength of
> various packets. Those recalibrations throw havoc in our
> measurements. In other words, the RSSI we measure is consistent
> between recalibration points, but not across those recalibration.
> This co-worker was using some NetBSD and not MadWifi, and I
> don't know which version, so I can not say for sure if this affect the
> current version of MadWifi.
>
> You have to look at what the application wants. The
> application wants consistent measurements. You can *NOT* define
> properly APIs unless you understand how application will use it.
> I don't understand enough about the Atheros hardware (I
> haven't used it), but I don't see why you would need to recalibrate
> the noise floor and how you could acheive that. Any "noise" you
> measure on the channel would be subject to interference and
> fading. The only way you could measure some noise with some certainty
> would be to ground the antenna and measure.
there are actually two types of noise calibration for atheros hardware: one is
for the internal circuit noise, which is done by detaching the antennas and
another one for the environment noise (interference) on the channel, which is
measured during silent times of the MAC protocol (SIFS for example). at least
that's my understanding of what is described in an atheros patent:
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PTXT&s1=%22Method+system+noise+floor+calibration+receive+signal+strength+detection%22.TI.&OS=TTL/
> If you calibrate your RSSI using the noise on the channel, I
> believe you are measuring SNR, not signal strength. Of course, I may
> be wrong.
i think that's what is happening. that seems to be consistent with both your
collegues experimental results, the patent and the way we interpret
the "RSSI" as SNR in madwifi and ath5k.
of course lacking any documentation from atheros this all mostly speculations.
> > sorry jean, no offense, but the usage of these values in WE was really
> > confusing and the lack of knowing what the values acutally mean made it
> > really hard for applications to work with them.
>
> Everybody is entitled to their opinion. Those values were
> clearly documenteed but nobody bothered to read the documentation.
true. it's unfair to blame WE for that. the problems came mostly from the fact
that devices used completely different methods of reporting these values and
not much was know about the devices sometimes.
now that have a mac80211 stack which unifies different drivers i would like to
improve that situation by also unifying the way we report signal and noise
across most devices. most modern cards support dBm so this is probably the
way to go for the future.
but the remaining question is how do we deal with devices where we don't know
how to map RSSI to dBm.
i take your suggestion that we should remove the "linear" requirement from the
definition. do you think it would be feasible to require the drivers to
normalize their RSSI to a range of 0-100, so we would have at least some
consistency between devices? (of course their steps within this percentage
would be different and it would still be impossible to compare these values
across different devices).
best regards,
bruno
On Mon, Mar 31, 2008 at 03:32:44PM +0900, bruno randolf wrote:
>
> there are actually two types of noise calibration for atheros hardware: one is
> for the internal circuit noise, which is done by detaching the antennas and
> another one for the environment noise (interference) on the channel, which is
> measured during silent times of the MAC protocol (SIFS for example). at least
> that's my understanding of what is described in an atheros patent:
>
> http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PTXT&s1=%22Method+system+noise+floor+calibration+receive+signal+strength+detection%22.TI.&OS=TTL/
>
Patents are hard to read. And you don't even know if the
patent apply to the current hardware.
Reading the patent, the intention is good. They want to
calculate dBm. Because their hardware does not have a fixed offset,
they do all kind of tricks to calibrate the offset.
Now, the problem of their method is that they need to
determine the channel noise floor. And this is where it falls apart,
as there is no guarantee that you can measure the noise floor, because
there is no guarantee that you can measure a time where there is no
transmission and no interference. With all the cordless phones,
BlueTooth, adjacent cell, channel overlap and so on, the 2.4 GHz band
tend to be quite busy.
What the patent seem to advocate is to measure the noise over
a long period of time and use the lowest measurement. The patent seems
to say that this channel noise vary little by temperature, so you
could actually measure it once and store it. They also seem to say
that it could be the same for all units.
> i think that's what is happening. that seems to be consistent with both your
> collegues experimental results, the patent and the way we interpret
> the "RSSI" as SNR in madwifi and ath5k.
>
> of course lacking any documentation from atheros this all mostly
> speculations.
Yes, I don't want to claim anything, because I've not used
this hardware, we have only hearsay and I belive those kind of things
need to be verified in details.
From the patent, it looks like you could measure dBm this way
but you would need more care in managing the channel noise
measurement.
Note that's the trouble with doing things bottom up. Very
often, hardware does it some specific way because it was easier to
implement or because the designer made some choices. Unfortunately,
applications may have other needs.
I've also seen Atheros based AP where the Tx power is relative
(dB to max) instead of absolute (dBm). And in the case, the max did
depend on various things, such as the band (2.4 GHx vs. 5GHz) and the
type of antenna (internal/external). Very messy.
> The problems came mostly from the fact
> that devices used completely different methods of reporting these values and
> not much was know about the devices sometimes.
>
> now that have a mac80211 stack which unifies different drivers i would like to
> improve that situation by also unifying the way we report signal and noise
> across most devices. most modern cards support dBm so this is probably the
> way to go for the future.
I think you are in a way better position. We now have 10 year
of experience, there are way more people concerned about it and
application are finally starting to pay attention to those APIs.
> but the remaining question is how do we deal with devices where we
> don't know how to map RSSI to dBm.
>
> i take your suggestion that we should remove the "linear"
> requirement from the definition.
I believe most devices will have a "sort of dBm" measurement
(i.e. log scale), because that's what you need to perform CSMA-CA,
roaming and bit-rate adaptation.
> do you think it would be feasible
> to require the drivers to normalize their RSSI to a range of 0-100,
> so we would have at least some consistency between devices? (of
> course their steps within this percentage would be different and it
> would still be impossible to compare these values across different
> devices).
If the measurement is not linear or log, it does not make
sense mandating the 0-100, because 50 won't be the mid-point. And we
assume that devices are not consistent to start with...
Anyway, to avoid quantisation errors, I prefer to defer
normalisation to the end software. For example, if the app use a 64
pixel window to show the RSSI, it wants a value 0-63, not 0-100.
> best regards,
> bruno
Have fun...
Jean
T24gV2VkLCBNYXIgMjYsIDIwMDggYXQgODoxOSBQTSwgSmVhbiBUb3VycmlsaGVzIDxqdEBocGwu
aHAuY29tPiB3cm90ZToKPiBPbiBXZWQsIE1hciAyNiwgMjAwOCBhdCAwNjo1OToxMVBNIC0wNDAw
LCBMdWlzIFIuIFJvZHJpZ3VleiB3cm90ZToKPiAgPiBKZWFuIGEgcXVlc3Rpb24gb3IgdHdvIGZv
ciB5b3UgYmVsb3cuCj4gID4KPiAgPiBPSyBJIGtub3cgSSBzZWVtZWQgaGFwcHkgd2l0aCB0aGUg
b3JpZ2luYWwgcGF0Y2ggYnV0IGFmdGVyIHNvbWUKPiAgPiB0aG91Z2h0IEkgaGF2ZSBzb21lIGNv
bmNlcm5zLiBUaGV5IGFyZSBiZWxvdy4KPgo+ICAgICAgICAgSGkgdGhlcmUsCj4KPiAgICAgICAg
IEknbSwgY3VycmVudGx5IG9uIGJ1c2luZXNzIHRyaXAuIEknbGwgdHJ5IHRvIGFuc3dlciB0aGUg
YmVzdCBJCj4gIGNhbi4gUGluZyBtZSBhZ2FpbiBuZXh0IHdlZWsuCj4gICAgICAgICBOb3RlIHRo
YXQgSSBkaWQgbm90IGRlZmluZSB3aGF0IHdlbnQgaW50byBtYWM4MDIxMS5oLCBhbmQgSQo+ICBk
aXNjbGFpbSBhbnkgcmVzcG9uc2FiaWxpdHkgZnJvbSB0aGF0LgoKSSdtIHZlcnkgd2VsbCBhd2Fy
ZSB5b3UgZGlkIG5vdCBkZWZpbmUgd2hhdCB3ZW50IGludG8gbWFjODAyMTEuaC4gQWxzbwpJJ20g
bm90IGJsYW1pbmcgYW55b25lIGZvciBhbnl0aGluZywgSSBqdXN0IHdhbnRlZCB0byBhc2sgeW91
IHNvbWUKZGV0YWlscyBvZiBpbnRlbnRpb25zIGJlaGluZCBhIHZhbHVlIHVzZWQgaW4gV0Ugc28g
d2UgY2FuIGJldHRlcgppbXBsZW1lbnQgdGhpbmdzIG1vdmluZyBmb3J3YXJkLgoKPiAgICAgICAg
IE15IGlkZWEgaXMgdGhhdCB0aGUgQVBJIHNob3VsZCBiZSBiYXNlZCBvbiByZWFsIHBoeXNpY2Fs
Cj4gIG1lYXN1cmFibGUgdmFsdWVzIGFzIG11Y2ggYXMgcG9zc2libGUuIFRoZSB0cmFkZW9mZiBp
cyB0aGF0IHRob3NlCj4gIHZhbHVlcyBzaG91bGQgYWxzbyBiZSB1c2VmdWwsIG9mdGVuIHJhdyB2
YWx1ZXMgYXJlIHVzZWxlc3MuCgpBQ0sKCj4gICAgICAgICBUaGUgbW9zdCBjb21tb24gdW5pdCBm
b3IgdGhlIFJTU0kgaXMgZEJtLCBidXQgSSBzZWUgdGhhdCBJRUVFCj4gIGlzIHVzaW5nIFJDUFRJ
LiBJIHBlcnNvbmFsbHkgZG9uJ3QgbGlrZSBSQ1BUSSBiZWNhdXNlIGl0J3MgbW9yZQo+ICBvcGFx
dWUsIHBlb3BsZSBhcmUgcGh5c2ljYWxseSBtZWFzdXJpbmcgZEJtLCBhbmQgYXJlIGhhdmluZyB0
cmFuc21pdCwKPiAgZ2FpbiBhbmQgbG9zcyBtZWFzdXJlZCBpbiBkQnMuIFRoYXQncyB3aHkgSSB0
aGluayBpdCdzIGltcG9ydGFudCB0aGF0Cj4gIHRoZSB1bml0IHVzZWQgZm9yIHRoYXQgdmFsdWUg
YmUgZEJtLgoKSSB0aGluayB5b3UgbWVhbnQgUkNQSSwgYW5kIGl0IHNlZW1zIHRvIGJlIHdlbGwg
ZGVmaW5lZCBhY3R1YWxseS4gVGhlCnZhbHVlIGlzIG9wYXF1ZSBidXQgaXQgaXMgYSByZXByZXNl
bnRhdGlvbiBvZiBhIGRibSB2YWx1ZS4gQWdhaW4sCnF1b3RpbmcgZnJvbSBTaW1vbidzIGNvbW1l
bnQgb24gUkNQSToKCiJUaGUgYWxsb3dlZCB2YWx1ZXMgZm9yIHRoZSBSZWNlaXZlZCBDaGFubmVs
IFBvd2VyIEluZGljYXRvciAoUkNQSSkgcGFyYW1ldGVyCnNoYWxsIGJlIGFuIDggYml0IHZhbHVl
IGluIHRoZSByYW5nZSBmcm9tIDAgdGhyb3VnaCAyMjAsIHdpdGggaW5kaWNhdGVkCnZhbHVlcyBy
b3VuZGVkIHRvIHRoZSBuZWFyZXN0IDAuNSBkQiBhcyBmb2xsb3dzOgoKMDogUG93ZXIgPCAtMTEw
IGRCbQoxOiBQb3dlciA9IC0xMDkuNSBkQm0KMjogUG93ZXIgPSAtMTA5LjAgZEJtCgphbmQgc28g
b24gd2hlcmUKClJDUEkgPSBpbnR7KFBvd2VyIGluIGRCbSArMTEwKSoyfSBmb3IgMGRibSA+IFBv
d2VyID4gLTExMGRCbQoKMjIwOiBQb3dlciA+IC0wIGRCbQoyMjEtMjU0OiByZXNlcnZlZAoyNTU6
IE1lYXN1cmVtZW50IG5vdCBhdmFpbGFibGUKClJDUEkgc2hhbGwgZXF1YWwgdGhlIHJlY2VpdmVk
IFJGIHBvd2VyIHdpdGhpbiBhbiBhY2N1cmFjeSBvZiArLy01IGRCCig5NSUgY29uZmlkZW5jZSBp
bnRlcnZhbCkgd2l0aGluIHRoZSBzcGVjaWZpZWQgZHluYW1pYyByYW5nZSBvZiB0aGUKcmVjZWl2
ZXIuIFRoZSByZWNlaXZlZCBSRiBwb3dlciBzaGFsbCBiZSBkZXRlcm1pbmVkIGFzc3VtaW5nIGEg
cmVjZWl2ZXIKbm9pc2UgZXF1aXZhbGVudCBiYW5kd2lkdGggZXF1YWwgdG8gdGhlIGNoYW5uZWwg
YmFuZHdpZHRoIG11bHRpcGxpZWQgYnkKMS4xLiIKCkJ1dCBhcyBkaXNjdXNzZWQgYWxyZWFkeSBv
biB0aGUgbGlzdHMgdGhlIHByb2JsZW0gd2l0aCBSQ1BJIHdpbGwgYmUKZ2V0dGluZyBoYXJkd2Fy
ZSB0byBzdXBwb3J0IGl0IGFuZCBpdHMgYWNjdXJhY3kuIEluIHRlcm1zIGFjY3VyYWN5IGZvcgpS
Q1BJIHlvdSBuZWVkIHRvIHN1cHBvcnQgInJlY2VpdmVkIFJGIHBvd2VyIGluIHRoZSBzZWxlY3Rl
ZCBjaGFubmVsCmZvciBhIHJlY2VpdmVkIGZyYW1lLiBUaGlzIHBhcmFtZXRlciBzaGFsbCBiZSBh
IG1lYXN1cmUgYnkgdGhlIFBIWQpzdWJsYXllciBvZiB0aGUgcmVjZWl2ZWQgUkYgcG93ZXIgaW4g
dGhlIGNoYW5uZWwgbWVhc3VyZWQgb3ZlciB0aGUKZW50aXJlIHJlY2VpdmVkIGZyYW1lIG9yIGJ5
IG90aGVyIGVxdWl2YWxlbnQgbWVhbnMgd2hpY2ggbWVldCB0aGUKc3BlY2lmaWVkIGFjY3VyYWN5
Ii4gSSBkb24ndCBiZWxpZXZlIHdlIGhhdmUgaGFyZHdhcmUgdGhhdCBjYW4gZml0CnRoaXMgZGVm
aW5pdGlvbiB5ZXQuIEF0aGVyb3MnIHJzc2kgdmFsdWUgaXMgbWVhc3VyZWQgZHVyaW5nIHRoZSB0
aGUKaW5pdGlhbCA0dXMgb2YgZGV0ZWN0aW9uLCBkdXJpbmcgdGhlIHByZWFtYmxlIGFuZCBQTENQ
LCBub3Qgc3VyZSBpZgp0aGlzIGZpdHMgdGhlIGRlZmluaXRpb24gb24gdGhlICJvciIgY2xhdXNl
ICgib3IgYnkgb3RoZXIgZXF1aXZhbGVudAptZWFucyB3aGljaCBtZWV0IHRoZSBzcGVjaWZpZWQg
YWNjdXJhY3kiKS4gSSBhbHNvIHdpc2ggYW5kIHdvbmRlciBpZgp3ZSBjb3VsZCBtb2RpZnkgdGhp
cyBkdXJhdGlvbiBvZiA0dXMgZHVyaW5nIHdoaWNoIHRoZSBTTlIgaXMgbWVhc3VyZWQuCgo+ICAg
ICAgICAgTm93LCB3ZSB3b3VsZCBsaWtlIGFsbCBoYXJkd2FyZSB0byByZXBvcnQgUlNTSSBpbiBk
Qm0sIGFuZCBnZXQKPiAgZG9uZSB3aXRoIGl0LiBIb3dldmVyLCBzb21lIGhhcmR3YXJlIChBdGhl
cm9zKSBjYW4gbm90IGRvIGl0LCBiZWNhdXNlCj4gIHRoZWlyIFJTU0kgaGFyZHdhcmUgaXMgdW5j
YWxpYnJhdGVkLiBTbywgd2hhdCBkbyB5b3UgZG8gd2l0aCB0aG9zZQo+ICBoYXJkd2FyZSA/IFJl
cG9ydGluZyBhICJyZWxhdGl2ZSIgc2lnbmFsIHN0cmVuZ3RoIGlzIHByb2JhYmx5IGJldHRlcgo+
ICB0aGFuIG5vdGhpbmcuCgpXaGF0IDgwMi4xMSBoYXJkd2FyZSBkb2VzIHJlcG9ydCBleGFjdCBk
Ym0gc2lnbmFsIHN0cmVuZ3RoCm1lYXN1cmVtZW50cz8gQXQgbGVhc3QgZm9yIEF0aGVyb3MgQVI1
MjEyIGhhcmR3YXJlIHRoZXJlIHNlZW1zIHRvIGJlCmFuIG9mZnNldCB2YWx1ZSBiZXR3ZWVuIHRo
ZSBhY3R1YWwgc2lnbmFsIHN0cmVuZ3RoIGFuZCB0aGUgbWVhc3VyZWQKc2lnbmFsIHN0cmVndGgu
IEF0IE9yYml0IHdlIHVzZSBhIGxvdCBvZiBBdGhlcm9zIGhhcmR3YXJlICg4MDAKd2lyZWxlc3Mg
Y2FyZHMgb24gdGhlIGdyaWQpIGFuZCBhdCBvbmUgcG9pbnQgaXQgc2VlbXMgdGhlcmUgd2FzIGEg
YmlnCmNvbmNlcm4gb3ZlciB0aGUgdmFsdWUgb2Ygc2lnbmFsIHN0cmVuZ3RoIHJlcG9ydGVkIGFu
ZCBob3cgaXQgZGlmZmVyZWQKYW1vbmdzdCBjYXJkcyBjb21wYXJlZCB0byBhIHJlYWwgY29udHJv
bGxlZCB2YWx1ZS4gSSBqdXN0IHRyaWVkIHRvCmdhdGhlciB0b2dldGhlciBhIGJpdCBvZiB0aGUg
ZXhwZXJpZW5jZSBzbyBmYXIgYW5kIGl0IHNlZW1zIHRoYXQgaW4KZ2VuZXJhbCB0aGUgb2Zmc2V0
IHdhcyBzbWFsbCBhbmQgZGlkbid0IHZhcnkgdG9vIG11Y2guIFNvIGFjdHVhbGx5LAp1bmxlc3Mg
SSBhbSBtaXNyZXByZXNlbnRpbmcgdGhlIGV4cGVyaWVuY2UgZXhwbGFpbmVkIHNvIGZhciBBdGhl
cm9zCmhhcmR3YXJlIHNlZW1zIHByb3ZpZGUgcmVsaWFibGUgcmVzdWx0cywgYWNyb3NzIGRpZmZl
cmVudCBleHBlcmltZW50cywKYWNyb3NzIGRpZmZlcmVudCBjYXJkcy4gQW4gb2Zmc2V0IGV4aXN0
cyBidXQgaXQgc2VlbXMgdG8gYmUKbmVnbGlnaWJsZS4gSWYgeW91IHdhbnQgdG8gYmUgc3VyZ2lj
YWxseSBwcmVjaXNlIHlvdSBkbyBoYXZlIHRvCmFjY291bnQgZm9yIGl0IGJ1dCBpdCBzZWVtcyBp
dCBjbG9zZSBlbm91Z2ggZm9yIG91ciBwdXJwb3Nlcy4KCj4gICAgICAgICBOb3RlIHRoYXQgaXQg
Y291bGQgYmUgdW5jYWxpYnJhdGVkIGluIHR3byB3YXkuIE9uZSB3YXkgaXMgdGhlCj4gIG9mZnNl
dCAobGlrZSB0aGUgQXRoZXJvcyksIHRoZSBvdGhlciBpcyB0aGUgc2xvcGUgKG9sZGVyIGhhcmR3
YXJlKS4gSXQKPiAgbWVhbnMgdGhhdCBmb3Igc29tZSBoYXJkd2FyZSwgaXQgZG9lcyBub3QgZXZl
biBmb2xsb3cgYSBkQgo+ICBjdXJ2ZS4gVW5jYWxpYnJhdGVkIHVzdWFsbHkgbWVhbnMgdGhhdCBl
dmVyeSBpbnN0YW5jZSBvZiB0aGUgaGFyZHdhcmUKPiAgaXMgZGlmZmVyZW50IGFuZCB5b3UgY2Fu
J3QgaGF2ZSBhIGdsb2JhbCBjb3JyZWN0aW9uIGZhY3Rvci4KCklzIHRoZXJlIHN0YW5kYXJkIDgw
Mi4xMSBoYXJkd2FyZSBvdXQgdGhlcmUgdGhhdCBpcyBub3QgY2FsaWJyYXRlZAp1bmRlciB0aGlz
IGRlZmluaXRpb24/Cgo+ICAgICAgICAgRm9yIGV4YW1wbGUsIGNoZWNrIHRoZSBBaXJvbmV0IGRy
aXZlci4gVGhlIGRyaXZlciBoYXMgYSBSU1NJCj4gIGNvcnJlY3Rpb24gdGFibGUsIGZvciBldmVy
eSByYXcgUlNTSSB2YWx1ZSwgdGhlIGRyaXZlciBjaGVjayBpbiBhCj4gIHRhYmxlIHRvIGdldCB0
aGUgUlNTSSBpbiBkQm0uIFRoZSB0YWJsZSBpcyBzdG9yZWQgaW4gdGhlIEVQUk9NIG9mIHRoZQo+
ICBjYXJkLCBhbmQgSSBiZWxpZXZlIHNwZWNpZmljIHRvIGVhY2ggY2FyZC4gVGhlIGNvcnJlY3Rp
b24gY3VydmUgaXMgbm90Cj4gIGV2ZW4gbGluZWFyICEKPiAgICAgICAgIEZvciB0aGUgQXRoZXJv
cywgdGhlcmUgaXMgYW5vdGhlciBpc3N1ZSwgdGhlIG9mZnNldCBjaGFuZ2VzCj4gIG92ZXIgdGlt
ZSBhbmQgaXMgbm90IGNvbnN0YW50IGZvciB0aGUgY2FyZC4KCkkgd291bGRuJ3QgYmUgc3VycHJp
c2VkIGlmIHRoZSBvZmZzZXQgY2hhbmdlcyBvdmVyIHRpbWUgYnV0IEkgZG91YnQKaXRzIGJ5IGEg
bG90LiBIb3cgbXVjaCBoYXZlIHlvdSBzZWVuIHRoZSBvZmZzZXQgY2hhbmdlIG92ZXIgdGltZT8g
SSBkbwpub3QgdGhpbmsgd2UgaGF2ZSB0ZXN0ZWQgdGhpcy4gSSB3aWxsIGNoZWNrLgoKPiAgICAg
ICAgIE5vdGUgYWxzbyB0aGF0IG1hbnkgaGFyZHdhcmUgYXJlIG5vdCB0cnVseSBjYWxpYnJhdGVk
LCBidXQKPiAgInNvcnQgb2YiIGNhbGlicmF0ZWQgKE9yaW5vY28sIEhvc3RBUCkuIEdvb2QgbWVh
c3VyZW1lbnQgaXMgZXhwZW5zaXZlLAo+ICB0aGF0J3Mgd2h5IG1vc3QgaW1wbGVtZW50YXRpb24g
ZG8gbWVhc3VyZW1lbnQgb24gdGhlIGNoZWFwLiBJdCBtZWFucwo+ICB0aGUgdmFsdWUgd2lsbCBi
ZSBjb3JyZWN0IHdpdGhpbiBzb21lIGZldyBwZXJjZW50cyBmb3IgYSBsYXJnZSBwYXJ0Cj4gIHJh
bmdlLiBVcCB0byBub3csIHdlIHByZXRlbnRlZCB0aGF0IHRob3NlIGRldmljZXMgcmVwb3J0IGRC
bQo+ICBwcm9wZXJseS4gVGhhdCdzIHdoeSBSQ1BUSSB0YWxrIG9mIGV4cGVjdGVkIGFjY3VyYWN5
IG9mIG1lYXN1cmVtZW50Lgo+Cj4gICAgICAgICBTbywgaW4gV0Ugd2UgaGF2ZSA6Cj4gICAgICAg
ICAgICAgICAgIG8gc2lnbmFsIGlzIFJTU0kgaW4gZEJtLCB3aGljaCBpcyB0aGUgbW9zdCB1c2Vm
dWwgdG8gYXBwcy4KPiAgICAgICAgICAgICAgICAgbyBpZiBjYW4ndCBkbyBkQm0sIGRvIHJlbGF0
aXZlLCB3aGljaCBoYXMgbm8gZXhwZWN0YXRpb25zLgo+Cj4gICAgICAgICBOb3csIGJhY2sgdG8g
eW91ciBxdWVzdGlvbi4KPiAgICAgICAgIFRoaXMgYWRkaXRpb25hbCB2YWx1ZSB3b3VsZCBiZSBj
YXNlcyB3aGVyZSBvbmx5IHRoZSBvZmZzZXQgaXMKPiAgdW5jYWxpYnJhdGVkIGFuZCB0aGUgc2xv
cGUgaXMgY29ycmVjdCwgbGlrZSB0aGUgQXRoZXJvcy4gV2hhdCBpdCB3b3VsZAo+ICBhbGxvdyBp
cyB0byBjYWxjdWxhdGUgU05SIGluIGRCLCB3aGljaCBhICJ1bnNwZWMiIHdvdWxkIG5vdCBhbGxv
dy4gSWYKPiAgdGhlIG9mZnNldCBpcyBjb25zdGFudCAoYXMgc3BlY2lmaWVkIGFib3ZlLCBidXQg
bm90IHRoZSBjYXNlIGZvcgo+ICBBdGhlcm9zKSwgeW91IGNvdWxkIGNvbXBhcmUgZGlmZmVyZW50
IHZhbHVlIG92ZXIgdGltZSBhbmQgbWFrZSBhCj4gIGRpZmZlcmVuY2UgaW4gZEIuCgpJbiBBdGhl
cm9zJyBjYXNlIHdlIHdhbnQgdG8gdXNlIGRibSBhcyB3ZSBhbHNvIGtub3cgdGhlIG5vaXNlLCBz
byB3ZQpjYW4ganVzdCB3b3JrIHdpdGggc2lnbmFsLiBJcyB0aGVyZSBoYXJkd2FyZSB3aGVyZSB3
ZSBtaWdodCBoYXZlIFNOUgpidXQgbm90IG5vaXNlPwoKPiAgICAgICAgIENsZWFybHksIHlvdSBo
YXZlIHRvIHRoaW5rIGhhcmQgYW5kIGRlZmluZSBpcyB0aGUgcmVmZXJlbmNlIGlzCj4gIGZpeGVk
IChhcyBzdGF0ZWQgYWJvdmUpIG9yIHZhcmlhYmxlIChBdGhlcm9zKS4gVGhlIGZpeGVkIHJlZmVy
ZW5jZQo+ICBjb3VsZCBiZSBtb3JlIHVzZWZ1bCB0byBhcHBzLCBidXQgSSBkb24ndCBrbm93IGhv
dyBtYW55IEhXIHdvdWxkIGZpdAo+ICB0aGF0IGRlZmluaXRpb24uIFRoZSB2YXJpYWJsZSByZWZl
cmVuY2Ugd291bGQgYWNjb21vZGF0ZSB0aGUgQXRoZXJvcwo+ICBuaWNlbHkuCj4gICAgICAgICBB
bHNvLCB3aXRoIHJlc3BlY3QgdG8gInNvcnQgb2YgY2FsaWJyYXRlZCIgZGV2aWNlLCB5b3Ugd291
bGQKPiAgaGF2ZSB0byBkZXZpY2UgaWYgdGhleSBhcmUgZEJtIG9yIGRCLiBXaGF0IGlzIHRoZSBh
Y2N1cmFjeSB5b3UgZXhwZWN0Lgo+Cj4gICAgICAgICBBbmQgb2YgY291cnNlLCB0aGUgbWFpbiBx
dWVzdGlvbiB0byBhc2sgaXMsIGlzIHRoaXMgZXh0cmEKPiAgZnVuY3Rpb25hbGl0eSB3b3J0aCB0
aGUgYWRkaXRpb25hbCBjb21wbGV4aXR5IG9mIHRoZSBBUEksIGFuZCB0aGUKPiAgcG90ZW50aWFs
IGNvbmZ1c2lvbiB0byB1c2Vycy4gSSBkb24ndCBrbm93LCBidXQgZm9yIFdFIHRoZSBhbnN3ZXIg
d2FzCj4gIG5vLgoKSXRzIGEgZ29vZCBwb2ludCBidXQgZm9yIHRob3NlIHdobyB3YW50IHByZWNp
c2UgcmVzdWx0cyBhbmQgaWYgd2UKKmNhbiogcHJvdmlkZSBiZXR0ZXIgYW5kIG1vcmUgYWNjdXJh
dGUgcmVzdWx0cyBJIGRvbid0IHNlZSB3aHkgbm90LgpVbHRpbWF0ZWx5IEknZCBsaWtlIHRvIHNl
ZSBSQ1BJIGVtYnJhY2VkIGJ1dCB3ZSBoYXZlIHRvIHlldCBzZWUKaGFyZHdhcmUgd2hvIGNhbiBm
aXQgaXRzIGRlZmluaXRpb24gb24gYWNjdXJhY3kuCgo8LS0gc25pcCAtLT4KCj4gID4gPiAgKyAq
IEBJRUVFODAyMTFfSFdfU0lHTkFMX0RCTToKPiAgPiA+ICArICogICAgIEhhcmR3YXJlIGdpdmVz
IHNpZ25hbCB2YWx1ZXMgaW4gZEJtLCBkZWNpYmVsIGRpZmZlcmVuY2UgZnJvbQo+ICA+ID4gICsg
KiAgICAgb25lIG1pbGxpd2F0dC4gVGhpcyBpcyB0aGUgcHJlZmVycmVkIG1ldGhvZCBzaW5jZSBp
dCBpcyBzdGFuZGFyZGl6ZWQKPiAgPiA+ICArICogICAgIGJldHdlZW4gZGlmZmVyZW50IGRldmlj
ZXMuCj4gID4gPiAgKyAqCj4gID4gPiAgKyAqIEBJRUVFODAyMTFfSFdfTk9JU0VfREJNOgo+ICA+
ID4gICsgKiAgICAgSGFyZHdhcmUgY2FuIHByb3ZpZGUgbm9pc2UgZmxvb3IgdmFsdWVzIGluIHVu
aXRzIGRCbSwgZGVjaWJlbCBkaWZmZXJlbmNlCj4gID4gPiAgKyAqICAgICBmcm9tIG9uZSBtaWxs
aXdhdHQuCj4KPiAgICAgICAgIE5vaXNlIG9ubHkgZGVmaW5lZCBpbiBkQm0gPyBTb21lIG9sZGVy
IGRldmljZXMgaGF2ZSBub2lzZSBpbgo+ICAidW5zcGVjIi4gSSBhbHNvIGRvbid0IGtub3cgd2hh
dCBBdGhlcm9zIGRvZXMgaGVyZS4KCldlIGRvbid0IGhhdmUgZG9jdW1lbnRhdGlvbiBmb3IgdGhp
cyBidXQgd2UgY2FuIHNlZSB3aGF0IHdhcyAqZG9uZSogb24KTWFkV2lmaS4gT24gTWFkV2lmaSB0
aGUgbm9pc2UgaXMgb2J0YWluZWQgZHVyaW5nIGludGVycnVwdHMgb24KaW5jb21pbmcgc2V0IG9m
IGZyYW1lcyBhbmQgdGhpcyBpcyBzYXZlZCBvbiBhIHZhcmlhYmxlLiBUaGlzIG5vaXNlIGlzCmlz
IHN1YnRyYWN0ZWQgZnJvbSB0aGUgU05SIChyc3NpKSB0byBnZXQgdGhlIHNpZ25hbC4gSSBndWVz
cyB0aGlzCmFzc3VtZXMgdGhhdCBpZiB0aGVyZSBpcyBhIHN0YXRpYyBub2lzZSBkdXJpbmcgU0lG
cyB0aGVuIHlvdSBzaG91bGQKc3VidHJhY3QgdGhhdCBub2lzZSBhcyB3ZWxsLiBJIGNhbm5vdCBz
YXkgd2UgaGF2ZSBtZWFzdXJlZCB0aGlzCm1ldGhvZCdzIGFjY3VyYWN5IGJ1dCBob3BlIGl0cyBi
ZXR0ZXIgdGhhbiBhc3N1bWluZyBhIHN0YXRpYyBub2lzZSBhcwppdHMgd2hhdCB3ZSB1c2UgaW4g
YXRoNWsgYXMgd2VsbC4KCjwtLSBzbmlwIC0tPgoKPiAgPiBJJ20gcHJldHR5IHBlcnBsZXhlZCBi
eSB0aGUgb3JpZ2luYWwgaW50ZW50aW9uIG9mIFdpcmVsZXNzIEV4dGVuc2lvbnMKPiAgPiBtYXhf
cXVhbC4gVGhlIGRvY3VtZW50YXRpb24gd2UgaGF2ZSBmb3IgdGhpcyBzdGF0ZXM6Cj4gID4KPiAg
PiAgICAgICAgIC8qIFF1YWxpdHkgb2YgbGluayAmIFNOUiBzdHVmZiAqLwo+ICA+ICAgICAgICAg
LyogUXVhbGl0eSByYW5nZSAobGluaywgbGV2ZWwsIG5vaXNlKQo+ICA+ICAgICAgICAgICogSWYg
dGhlIHF1YWxpdHkgaXMgYWJzb2x1dGUsIGl0IHdpbGwgYmUgaW4gdGhlIHJhbmdlIFswIDsgbWF4
X3F1YWxdLAo+ICA+ICAgICAgICAgICogaWYgdGhlIHF1YWxpdHkgaXMgZEJtLCBpdCB3aWxsIGJl
IGluIHRoZSByYW5nZSBbbWF4X3F1YWwgOyAwXS4KPiAgPiAgICAgICAgICAqIERvbid0IGZvcmdl
dCB0aGF0IHdlIHVzZSA4IGJpdCBhcml0aG1ldGljcy4uLiAqLwo+ICA+ICAgICAgICAgc3RydWN0
IGl3X3F1YWxpdHkgICAgICAgbWF4X3F1YWw7ICAgICAgIC8qIFF1YWxpdHkgb2YgdGhlIGxpbmsg
Ki8KPiAgPgo+ICA+IG1heF9xdWFsIGlzIGEgc3RydWN0IHRob3VnaCwgaXdfcXVhbGl0eSB3aGlj
aCBpczoKPiAgPgo+ICA+IC8qCj4gID4gICogICAgICBRdWFsaXR5IG9mIHRoZSBsaW5rCj4gID4g
ICovCj4gID4gc3RydWN0ICBpd19xdWFsaXR5Cj4gID4gewo+ICA+ICAgICAgICAgX191OCAgICAg
ICAgICAgIHF1YWw7ICAgICAgICAgICAvKiBsaW5rIHF1YWxpdHkgKCVyZXRyaWVzLCBTTlIsCj4g
ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICVtaXNzZWQgYmVh
Y29ucyBvciBiZXR0ZXIuLi4pICovCj4gID4gICAgICAgICBfX3U4ICAgICAgICAgICAgbGV2ZWw7
ICAgICAgICAgIC8qIHNpZ25hbCBsZXZlbCAoZEJtKSAqLwo+ICA+ICAgICAgICAgX191OCAgICAg
ICAgICAgIG5vaXNlOyAgICAgICAgICAvKiBub2lzZSBsZXZlbCAoZEJtKSAqLwo+ICA+ICAgICAg
ICAgX191OCAgICAgICAgICAgIHVwZGF0ZWQ7ICAgICAgICAvKiBGbGFncyB0byBrbm93IGlmIHVw
ZGF0ZWQgKi8KPiAgPiB9Owo+ICA+Cj4gID4gSmVhbiwgaWYgcmFuZ2UtPm1heF9xdWFsLmxldmVs
IGlzIHNldCB0byAtMTEwIGRvZXMgdGhpcyBtZWFuIHNpZ25hbAo+ICA+IGxldmVsIGNhbiBiZSBz
ZXQgb25seSBmcm9tIC0xMTAgdXAgdG8gMCA/IElzIG1heF9xdWFsLmxldmVsIHN1cHBvc2VkCj4g
ID4gdG8gYmUgdGhlIHdlYWtlc3Qgc2lnbmFsIHBvc3NpYmx5IGRldGVjdGVkPwo+Cj4gICAgICAg
ICBZZXMuIFRoaXMgaXMgd2hhdCBtYWtlIG1vc3Qgc2Vuc2UuCgpIb3cgc28/IEkgdGhpbmsgSSBt
dXN0IHN0aWxsIGJlIHNlcmlvdXNseSBtaXN1bmRlcnN0YW5kaW5nIHNvbWV0aGluZwp0aGVuLiBJ
ZiB0aGUgd2Vha2VzdCBzaWduYWwgcG9zc2libHkgZGV0ZWN0ZWQgaXMgLTExMCBkYm0gaXQgZG9l
cyBub3QKaW1wbHkgdGhlIHN0cm9uZ2VzdCBzaWduYWwgd2lsbCBiZSAwIGRibS4gT24gdGhlIGNv
bnRyYXJ5LCBJIGV4cGVjdCB0bwpiZSBhYmxlIHRvIHJlY2VpdmUgZnJhbWVzIHdpdGggcG9zaXRp
dmUgZGJtIHZhbHVlcy4gRm9yIGV4YW1wbGUsIGlmIEkKaG9vayB1cCBhIGNhcmQncyBhbnRlbm5h
IHdoaWNoIGlzIHRyYW5zbWl0dGluZyBhdCAyMGRibSB0byBhbm90aGVyCmNhcmQncyBhbnRlbm5h
IGRpcmVjdGx5IHdpdGggY2FibGVzIHdpdGggMTAgZGJtIGF0dGVudWF0b3IgaW4gdGhlCm1pZGRs
ZSBJIGV4cGVjdCB0byBzZWUgMTAgZGJtIG9uIHRoZSByZWNlcHRpb24gc2lkZS4gVGhlcmVmb3Jl
CnNob3VsZG4ndCB0aGUgbWF4IGJlIGNsb3NlIHRoZSBtYXggYWxsb3dlZCwgb3IgYXQgbGVhc3Qg
ZXhwZWN0ZWQsCkVJUlA/Cgo+ICAgICAgICAgUmVtZW1iZXIgd2UgYWxzbyBoYXZlICJhdmdfcXVh
bCIuCj4gICAgICAgICBUaGUgaWRlYSBpcyB0aGF0IGlmIHdlIHdhbnQgdG8gZ3JhcGhpY2FsbHkg
cmVwcmVzZW50IHRoZSB2YWx1ZQo+ICBvbiBhIGdyYXBoLCB3ZSBuZWVkIHRvIGtub3cgdGhlIGJv
dW5kcy4gVGhpbmsgYWJvdXQgYQo+ICB0aGVybW9tZXRlci4gTW9zdCB0aGVybW9tZXRlcnMgc2hv
dyBhIHJhbmdlIG9mIHRlbXBlcmF0dXJlIGZyb20gLTIwQwo+ICB0byArMTAwQy4KPiAgICAgICAg
IFVzdWFsbHksIGxldmVsIGFuZCBub2lzZSB3aWxsIGhhdmUgdGhlIHNhbWUgcmFuZ2UgWy0xMTA7
MF0sCgpJIGV4cGVjdCBub2lzZSB0byBoYXZlIHRoZSByYW5nZSBbbWluaW1hbCBwb3NzaWJseSBk
ZXRlY3RlZCBzaWduYWwKLS0tLSBtYXggZXhwZWN0ZWQgRUlSUCBdClRoZSBzYW1lIGFwcGxpZXMg
dG8gc2lnbmFsLCB3aGljaCB5b3Ugc2VlbSB0byBoYXZlIGxhYmVsZWQgYXMgImxldmVsIi4KCkFn
YWluLCBJIHRoaW5rIEknbSBwcm9iYWJseSBqdXN0IHJlYWxseSBub3QgdW5kZXJzdGFuZGluZyB0
aGlzIHNvCnBsZWFzZSBjbGFyaWZ5IGEgYml0IG1vcmUuCgo+ICBhbmQgcXVhbCB3aWxsIGhhdmUg
aXRzIG93biByYW5nZSBbMC0xMDBdIG9yIHdoYXRldmVyLgoKU3VyZSwgd2UgdXNlIHF1YWwgYXMg
YSBwZXJjZW50YWdlIG9mIHRoZSBiZXN0IHNpZ25hbCByaWdodCBub3cuIFRoaXMKaXMgZHJpdmVy
IGRlcGVuZGVudDsgZm9yIEF0aGVyb3MgaGFyZHdhcmUsIGZvciBleGFtcGxlLCB3ZSBhc3N1bWUg
YQptYXggcnNzaSB2YWx1ZSBvZiA2NC4KCj4gID4gQWxzbywgdGVjaG5pY2FsbHkgdGhlIG5vaXNl
IHNob3VsZCBjaGFuZ2UgZGVwZW5kaW5nIG9uIHRoZSBjaGFubmVsIGJhbmR3aWR0aC4KPiAgPgo+
ICA+IElFRUUtODAyLjExICBDaGFubmVsIGJhbmR3aWR0aAo+ICA+IDgwMi4xMWEgICAgICAgIDIw
TUh6Cj4gID4gODAyLjExYiAgICAgICAgMjJNSHoKPiAgPiA4MDIuMTFnICAgICAgICAyME1IeiAo
ZXhjZXB0IHdoZW4gb3BlcmF0aW5nIGluIDgwMi4xMWIgcmF0ZXMpCj4gID4gODAyLjExbiAgICAg
ICAgMjBNSHosIDQwTUh6IChleGNlcHQgd2hlbiBvcGVyYXRpbmcgaW4gODAyLjExYiByYXRlcykK
PiAgPgo+ICA+IEFwcGx5aW5nIHRoZSBub2lzZSBwb3dlciBmb3JtdWxhOgo+ICA+Cj4gID4gUG4g
PSBrVEIKPiAgPgo+ICA+IHdoZXJlOgo+ICA+Cj4gID4gayBpcyBCb2x0em1hbm4ncyBjb25zdGFu
dCwgMS4zOCoxMF4tMjMgSi9LCj4gID4gVCBpcyB0aGUgdGVtcGVyYXR1cmUgaW4gS2VsdmluIChy
b29tIHRlbXBlcmF0dXJlLCAyOTAgSykKPiAgPiBCIGlzIHRoZSBzeXN0ZW0gYmFuZHdpZHRoLCBp
biBIego+ICA+Cj4gID4gTm90ZTogV2F0dCA9IEovcwo+ICA+Cj4gID4gRm9yIGEgMSBIeiBiYW5k
d2lkdGggYW5kIGF0IDI5MCBLOgo+ICA+Cj4gID4gUG4gPSAxLjM4ICogMTAtMjMgSi9LICogMjkw
IEsgKiAxIEh6Cj4gID4gUG4gPSA0LjAwMjAwICogMTBeLTIxIEpIego+ICA+IFBuID0gNC4wMDIw
MCAqIDEwXi0yMSBKL3MKPiAgPiBQbiA9IDQuMDAyMDAgKiAxMF4tMjEgVwo+ICA+IFBuID0gNC4w
MDIwMCDDlyAxMC0xOCBtVwo+ICA+Cj4gID4gVG8gY29udmVydCB0byBCZWxsLCB3ZSBkbyBsb2cg
KGZvbyksIHRvIGRlY2lCZWxsIHdlIGRvIDEwICogbG9nIChmb28pCj4gID4gc286IChkQm0gPT0g
ZEJtVykKPiAgPgo+ICA+IFBuID0gMTAgKiBsb2cgKDQuMDAyMDAgKiAxMF4tMTgpIGRCbQo+ICA+
IFBuID0gfi0xNzMuOTc3MjI5MTU2OTk4MDc0MDEyNzcgZEJtCj4gID4gUG4gPSB+LTE3NCBkQm0K
PiAgPgo+ICA+IE5vdyBhcHBseWluZyB0aGUgc2FtZSBub2lzZSBwb3dlciBmb3JtdWxhLCBQbiA9
IGtUQiwgYW5kIGtub3dpbmcKPiAgPiBhbHJlYWR5IC0xNzRkQm0gYXBwbGllcyBmb3IgZWFjaCAx
IEh6IHdlIGNhbiBjb21wdXRlIHRoZSBwb3dlciBub2lzZQo+ICA+IGZvciBlYWNoIGRpZmZlcmlu
ZyBiYW5kd2lkdGggZm9yIDgwMi4xMToKPiAgPgo+ICA+IFBuID0gLTE3NCBkQm0gLyBIeiArIDEw
ICogbG9nIChCYW5kd2lkdGgpCj4gID4KPiAgPiBtY2dyb2ZAbW9uc3Rlcjp+JCBjYWxjCj4gID4g
Qy1zdHlsZSBhcmJpdHJhcnkgcHJlY2lzaW9uIGNhbGN1bGF0b3IgKHZlcnNpb24gMi4xMi4xLjEz
KQo+ICA+IENhbGMgaXMgb3BlbiBzb2Z0d2FyZS4gRm9yIGxpY2Vuc2UgZGV0YWlscyB0eXBlOiAg
aGVscCBjb3B5cmlnaHQKPiAgPiBbVHlwZSAiZXhpdCIgdG8gZXhpdCwgb3IgImhlbHAiIGZvciBo
ZWxwLl0KPiAgPgo+ICA+Cj4gID4gOyAtMTc0ICsgKDEwICogbG9nKDIwICogMTBeNikpCj4gID4g
ICAgICAgICB+LTEwMC45ODk3MDAwNDMzNjAxODgwNDc5NAo+ICA+IDsgLTE3NCArICgxMCAqIGxv
ZygyMiAqIDEwXjYpKQo+ICA+ICAgICAgICAgfi0xMDAuNTc1NzczMTkxNzc3OTM3NjQwNDEKPiAg
PiA7IC0xNzQgKyAoMTAgKiBsb2coNDAgKiAxMF42KSkKPiAgPiAgICAgICAgIH4tOTcuOTc5NDAw
MDg2NzIwMzc2MDk1NzkKPiAgPgo+ICA+IFNvIEkgZG9uJ3Qgc2VlIHdoeSBub2lzZSBwb3dlciBz
aG91bGQgYmUgLTExMCwgaW5zdGVhZCBob3cgYWJvdXQKPiAgPiBoYXZpbmcgaXQgc2V0IHRvIC0x
MDEgZEJtIGZvciAyMCBNSHogYW5kIDIyIE1IeiBjaGFubmVsIGJhbmR3aWR0aCBhbmQKPiAgPiAt
OTggZEJtIGZvciA0MCBNSHogY2hhbm5lbCBiYW5kd2lkdGggd2hlbiB1c2VkPyBJZiB3ZSB3YW50
IHRvIGJlIGV2ZW4KPiAgPiBtb3JlIGV4YWN0IHdlIGNhbiB0YWtlIGludG8gY29uc2lkZXJhdGlv
biB0aGUgbm9pc2UgZnJvbSB0aGUgYW1wbGlmaWVyCj4gID4gY2hhaW4gZm9yIHRoZSBoYXJkd2Fy
ZSB3aGVuIGtub3duOyBmb3IgZXhhbXBsZSBmb3IgQXRoZXJvcyBpdCBzZWVtcyB0bwo+ICA+IGJl
IGtub3duIHRvIGJlIDVkQm0gWzFdIHNvIHRoZSBub2lzZSBmb3IgQXRoZXJvcyBoYXJkd2FyZSBz
aG91bGQKPiAgPiBjaGFuZ2UgdG8gLTk2IGRCbS4KPgo+ICAgICAgICAgUmVtZW1iZXIsIHdoYXQg
d2UgY2FyZSBtb3N0IGhlcmUgaXMgdG8gZ2l2ZSBhIHJhbmdlIHNvIHRoYXQKPiAgZ3JhcGhpY2Fs
IGFwcGxpY2F0aW9ucyBrbm93IHRoZSBib3VuZCBvZiB0aGUgdmFsdWUuIFdlIGRvbid0IG5lZWQg
dG8KPiAgYmUgYWJzb2x1dGVseSBhY2N1cmF0ZSBoZXJlLiBUaGluayBhYm91dCB0aGUgdGhlcm1v
bWV0ZXIgZXhhbXBsZS4KClBvaW50IHRha2VuLiBJbiB0aGF0IGNhc2UgcmVwcmVzZW50YXRpb24t
d2lzZSB3ZSBzaG91bGQgdGFrZSB0aGUKbG93ZXN0IG51bWJlciBmb3IgdGhlIGxvd2VzdCBwb3Nz
aWJsZSB2YWx1ZS4gRm9yIDgwMi4xMSB0aG91Z2ggaXQKc2VlbXMgdGhlIGxvd2VzdCB2YWx1ZSBz
aG91bGQgYmUgLTEwMSAoMjAgTUh6IGJhbmR3aWR0aCkgYXMgSQppbGx1c3RyYXRlZCBidXQgc29t
ZSBmdW5reSBoYXJkd2FyZSAoQXRoZXJvcykgYWxsb3dzIGV2ZW4gZm9yIDUgTUh6CmNoYW5uZWwg
d2lkdGhzIHNvIGJlY2F1c2Ugb2YgdGhhdCB0aGlzIGNvbWVzIGRvd24gdG8gMTA3OgoKOyAtMTc0
ICsgKDEwICogbG9nKDUgKiAxMF42KSkKICAgICAgICB+LTEwNy4wMTAyOTk5NTY2Mzk4MTE5NTIx
OQoKRm9yIDFNSHogd2UgZ2V0IGEgY2xlYW4gLTExNDoKCjsgLTE3NCArICgxMCAqIGxvZygxICog
MTBeNikpCiAgICAgICAgLTExNAoKV2hhdGV2ZXIsIEkgZ3Vlc3MgLTExMCBvciAtMTE0IGlzIE9L
IHRoZW4gOikgSSBzZWUgeW91ciBwb2ludCB0aG91Z2guCgo+ICAgICAgICAgTm93LCB3aGF0IHlv
dSBhcmUgdGFsa2luZyBpcyB0aGUgY2hhbm5lbCBub2lzZS4gUmVjZWl2ZXIgbm9pc2UKPiAgaXMg
ZGlmZmVyZW50LCBhcyB0aGUgcmVjZWl2ZXIgY2hhaW4gYWRkcyBpdHMgb3duIG5vaXNlLiBUaGVu
LCBpZiB5b3UKPiAgdXNlIERTICgxIE1CL3MpIG9yIG90aGVyIGNvbXBsZXggbW9kdWxhdGlvbiwg
eW91IGNhbiBoYXZlIGEgcHJvY2Vzc2luZwo+ICBnYWluIHdoaWNoIGxvd2VyIHRoZSBub2lzZSBm
bG9vci4gV2hlbiBJIGxvb2tlZCBhdCB0aGUgT3Jpbm9jbyBhdAo+ICAxTWIvcywgSSBiZWxpZXZl
IHRoZSAtMTEwIGRCbSB3YXMgY29ycmVjdCwgYnV0IEkgbWF5IGhhdmUgZ290IGl0Cj4gIHdyb25n
Lgo+ICAgICAgICAgSSB0aGluayBpdCB3b3VsZCBiZSB3aXNlIHRvIHVzZSBhIHZhbHVlIHRoYXQg
Y2hhbmdlIGFzIGxpdHRsZQo+ICBhcyBwb3NzaWJsZSwgc28gdGhhdCB0aGUgdmFyaW91cyBhcHBs
aWNhdGlvbnMgY2FuIGNhY2hlIGl0ICh3ZWxsLCB0aGV5Cj4gIHdpbGwgZG8gaXQgYW55d2F5KS4K
PiAgICAgICAgIEJ1dCB5ZWFoLCBwbGVhc2UgdXNlIHdoYXRldmVyIHZhbHVlIG1ha2Ugc2Vuc2Ug
YW5kIGdpdmUgZ29vZAo+ICByZXN1bHQgaW4gdXNlcnNwYWNlIGFwcGxpY2F0aW9ucy4KClN1cmUu
CgogIEx1aXMK
On Thursday 03 April 2008 08:19:07 Luis R. Rodriguez wrote:
> > > Jean, if range->max_qual.level is set to -110 does this mean sig=
nal
> > > level can be set only from -110 up to 0 ? Is max_qual.level supp=
osed
> > > to be the weakest signal possibly detected?
> >
> > Yes. This is what make most sense.
>
> How so? I think I must still be seriously misunderstanding something
> then. If the weakest signal possibly detected is -110 dbm it does not
> imply the strongest signal will be 0 dbm. On the contrary, I expect t=
o
> be able to receive frames with positive dbm values. For example, if I
> hook up a card's antenna which is transmitting at 20dbm to another
> card's antenna directly with cables with 10 dbm attenuator in the
> middle I expect to see 10 dbm on the reception side. Therefore
> shouldn't the max be close the max allowed, or at least expected,
> EIRP?
from a paper, from Joshua Bardwell, also available at:
http://madwifi.org/attachment/wiki/UserDocs/RSSI/you_believe_D100201.pd=
f
"Bear in mind that, realistically, stations will nearly always receive =
signals=20
below 1 mW, unless they are very close (within a few feet) of the acces=
s=20
point. Therefore, the power levels below 1 mW are critical to the opera=
tion=20
of an 802.11 chipset."
=2E..
"Realistically, 1 mW is about the maximum power that a station is likel=
y to=20
receive, and the station would have to be within inches of a powerful A=
P to=20
receive even that much! (That might surprise you, but remember that 802=
=2E11=20
NICs can receive signals down to about 10-7 to 10-9 mW, so a =E2=80=9Cw=
eak=E2=80=9D 1 mW=20
signal is actually millions of times stronger than the weakest signal t=
he=20
card could discern.)"
=2E..
"Consequently, the RSSI ranges used by the 802.11 chipset manufacturers=
don=E2=80=99t=20
measure at all above 1 mW. The maximum RSSI value for all 802.11 chipse=
ts and=20
NICs represents a power level that is less than 1 mW. Everything betwee=
n 1 mW=20
and 100 mW is simply considered =E2=80=9C100 %=E2=80=9D RSSI."
bruno
On Wed, Mar 26, 2008 at 10:07 PM, bruno randolf <[email protected]> wrote:
> On Thursday 27 March 2008 07:59:11 Luis R. Rodriguez wrote:
> > > + * @IEEE80211_HW_SIGNAL_UNSPEC:
> > > + * Hardware can provide signal values but we don't know its units.
> > > To be + * able to standardize between different devices we would like
> > > linear + * values from 0-100. If possible please provide dB or dBm
> > > instead. + *
> > > + * @IEEE80211_HW_SIGNAL_DB:
> > > + * Hardware gives signal values in dB, decibel difference from an
> > > + * arbitrary, fixed reference. If possible please provide dBm
> > > instead. + *
> >
> > Signal should given in either be in dBm or an unspecified value. Since
> > we have "unspecified" not sure why we would have the "db" value. Can
> > you clarify what the difference between "unspecified" and "db" would
> > be? I don't think it makes sense to refer to signal with a "db" value,
> > unless we want "singal" here to be able to mean SNR.
>
> the best thing to specify is dBm and all drivers should try to do that. it's
> the only absolute value which makes sense and can be compared between
> different drivers and devices.
>
> however as we know some drivers simply cannot provide that. instead they have
> some form of RSSI - RSSI in general meaning nothing more than "received
> signal strength indication", which could be *anything*: voltage, any numbers,
> in dB or linear or whatever. RSSI does *not* in general mean SNR! for example
> you might remember the values of prism54, they were somewhere around 200. or
> prism2 cards which had something around 100 (it's been a while since i've
> touched them, so that might have changed). as jean noted the values don't
> even have to be linear - so i think we should remove that from the
> definition.
>
> so in the "unspecified" case we really don't know much about the units, in the
> worst case we can't even assume that 1/2 the value will mean 1/2 of the
> received signal strength. it's very hard to work with this values, but it's
> better than nothing.
>
> other cards might not have noise, so no absolute (dBm) measurement, but a form
> of RSSI which is measured in dB (that is a logarithmic difference). in this
> case we might not know which reference point the measurement is taken to, but
> we know how it behaves: -3 dB means half of the signal strength. if you add a
> 6dB gain antenna you can expect to see the signal reading to increase by 6dB.
> it's not strictly SNR (because we don't know the noise) but quite close to
> it.
>
> i think it's important to know the difference between this 3 cases i order to
> make some sense of the values in userspace gui, roaming agents, mesh link
> metrics, etc...
Agreed, but can you give me an example of a card which does provide
RSSI in db for values we don't know and that UNSPEC cannot handle? Is
this what is assumed of the rt2x00 cards?
Luis
On Thursday 03 April 2008 04:27:31 Luis R. Rodriguez wrote:
> > so in the "unspecified" case we really don't know much about the units,
> > in the worst case we can't even assume that 1/2 the value will mean 1/2
> > of the received signal strength. it's very hard to work with this values,
> > but it's better than nothing.
> >
> > other cards might not have noise, so no absolute (dBm) measurement, but
> > a form of RSSI which is measured in dB (that is a logarithmic
> > difference). in this case we might not know which reference point the
> > measurement is taken to, but we know how it behaves: -3 dB means half of
> > the signal strength. if you add a 6dB gain antenna you can expect to see
> > the signal reading to increase by 6dB. it's not strictly SNR (because we
> > don't know the noise) but quite close to it.
> >
> > i think it's important to know the difference between this 3 cases i
> > order to make some sense of the values in userspace gui, roaming agents,
> > mesh link metrics, etc...
>
> Agreed, but can you give me an example of a card which does provide
> RSSI in db for values we don't know and that UNSPEC cannot handle? Is
> this what is assumed of the rt2x00 cards?
i currently assume that for rt2x00 and zd1211 cards - but i'm really just
guessing here. feedback from driver authors or people who have more knowledge
about the hardware would be greatly appreciated!
here's the current table:
DRIVER SIGNAL MAX NOISE QUAL
-----------------------------------------------------------------
adm8211 unspec(?) 100 n/a missing
at76_usb unspec(?) (?) unused missing
ath5k dBm dBm percent rssi
b43legacy dBm dBm percent jssi(?)
b43 dBm dBm percent jssi(?)
iwl-3945 dBm dBm percent snr+more
iwl-4965 dBm dBm percent snr+more
p54 unspec 127 n/a missing
rt2x00 percent rssi+tx/rx frame success
rt2400 dB(?) 100 n/a
rt2500pci dB(?) 100 n/a
rt2500usb dB(?) 100 n/a
rt61pci dB(?) 100 n/a
rt73usb dB(?) 100 n/a
rtl8180 unspec(?) 65 n/a (?)
rtl8187 unspec(?) 65 (?) noise(?)
zd1211 dB(?) 100 n/a percent
bruno
On Wed, Apr 02, 2008 at 07:19:07PM -0400, Luis R. Rodriguez wrote:
>
> I'm very well aware you did not define what went into mac80211.h. Also
> I'm not blaming anyone for anything, I just wanted to ask you some
> details of intentions behind a value used in WE so we can better
> implement things moving forward.
Understood, this is why I took my time answering you.
> > The most common unit for the RSSI is dBm, but I see that IEEE
> > is using RCPTI.
>
> I think you meant RCPI, and it seems to be well defined actually.
Yes, I "misspoke". Note that RCPI is implemented in WT-29. If
iwconfig sees a RCPI value over WE, it converts it to dBm.
> > Now, we would like all hardware to report RSSI in dBm, and get
> > done with it. However, some hardware (Atheros) can not do it, because
> > their RSSI hardware is uncalibrated. So, what do you do with those
> > hardware ? Reporting a "relative" signal strength is probably better
> > than nothing.
>
> What 802.11 hardware does report exact dbm signal strength
> measurements?
Cisco Aironet 350 (later firmware using calibration
table). That's probably the best I can think off.
> At least for Atheros AR5212 hardware there seems to be
> an offset value between the actual signal strength and the measured
> signal stregth. At Orbit we use a lot of Atheros hardware (800
> wireless cards on the grid) and at one point it seems there was a big
> concern over the value of signal strength reported and how it differed
> amongst cards compared to a real controlled value. I just tried to
> gather together a bit of the experience so far and it seems that in
> general the offset was small and didn't vary too much. So actually,
> unless I am misrepresenting the experience explained so far Atheros
> hardware seems provide reliable results, across different experiments,
> across different cards. An offset exists but it seems to be
> negligible. If you want to be surgically precise you do have to
> account for it but it seems it close enough for our purposes.
As I explained in other parts of this thread, I have no
experience of Atheros. Some coworker has been using NetBSD and has
seen inconsistency over time due to noise recalibration. Note that we
operate in an environment with noise.
> > Note that it could be uncalibrated in two way. One way is the
> > offset (like the Atheros), the other is the slope (older hardware). It
> > means that for some hardware, it does not even follow a dB
> > curve. Uncalibrated usually means that every instance of the hardware
> > is different and you can't have a global correction factor.
>
> Is there standard 802.11 hardware out there that is not calibrated
> under this definition?
On top of my head, I don't remember. It affected mostly
pre-802.11 devices. There is a Raylink which is a 802.11 FH device,
but that probably does not count. Then, a lot of devices are "sort of
calibrated", and I don't know where you want to draw the line.
> > For the Atheros, there is another issue, the offset changes
> > over time and is not constant for the card.
>
> I wouldn't be surprised if the offset changes over time but I doubt
> its by a lot. How much have you seen the offset change over time? I do
> not think we have tested this. I will check.
My coworker was complaining a significant change. Enough to
impact is interference measurements. It was related to noise
recalibration that occur at periodic intervals. Note that it was with
NetBSD, the driver may be different.
> > This additional value would be cases where only the offset is
> > uncalibrated and the slope is correct, like the Atheros. What it would
> > allow is to calculate SNR in dB, which a "unspec" would not allow. If
> > the offset is constant (as specified above, but not the case for
> > Atheros), you could compare different value over time and make a
> > difference in dB.
>
> In Atheros' case we want to use dbm as we also know the noise, so we
> can just work with signal. Is there hardware where we might have SNR
> but not noise?
Don't think so, but I did not look at all design. And nowadays
I can't be bothered to check it.
> Its a good point but for those who want precise results and if we
> *can* provide better and more accurate results I don't see why not.
> Ultimately I'd like to see RCPI embraced but we have to yet see
> hardware who can fit its definition on accuracy.
I like RCPI for the accuracy expectation. But I would rather
present a dBm value to the user (in floating point, obviously).
> > Noise only defined in dBm ? Some older devices have noise in
> > "unspec". I also don't know what Atheros does here.
>
> We don't have documentation for this but we can see what was *done* on
> MadWifi. On MadWifi the noise is obtained during interrupts on
> incoming set of frames and this is saved on a variable. This noise is
> is subtracted from the SNR (rssi) to get the signal. I guess this
> assumes that if there is a static noise during SIFs then you should
> subtract that noise as well. I cannot say we have measured this
> method's accuracy but hope its better than assuming a static noise as
> its what we use in ath5k as well.
Well, check my other e-mail in this thread. Measuring channel
noise is, I believe, much more tricky than it looks.
> > > Jean, if range->max_qual.level is set to -110 does this mean signal
> > > level can be set only from -110 up to 0 ? Is max_qual.level supposed
> > > to be the weakest signal possibly detected?
> >
> > Yes. This is what make most sense.
>
> How so? I think I must still be seriously misunderstanding something
> then. If the weakest signal possibly detected is -110 dbm it does not
> imply the strongest signal will be 0 dbm. On the contrary, I expect to
> be able to receive frames with positive dbm values. For example, if I
> hook up a card's antenna which is transmitting at 20dbm to another
> card's antenna directly with cables with 10 dbm attenuator in the
> middle I expect to see 10 dbm on the reception side. Therefore
> shouldn't the max be close the max allowed, or at least expected,
> EIRP?
Initially, dBm did not had a "max", and the max_qual value was
zero (there are probably drivers still like that). With dBm, you know
the min and max if you know the frequency and the band. So, I did not
bother with it.
When we went with multi band and multi rate, I failed to
properly extend the API, and retrofited the noise floor in the
max. That was the most expedient at the time.
Ideally, we should have a true "min and max". The most
important value to know if the min, as you want to know in marginal
condition how close you are from the limit. For the max, there is no
way of knowing, as it mostly depend on the transmitter (power, gain,
etc...). I believe 0 is close enough to a good value.
Note also that most receiver will saturate if the received
signal is too strong and won't measure accurately dBm in those range.
> > Remember we also have "avg_qual".
> > The idea is that if we want to graphically represent the value
> > on a graph, we need to know the bounds. Think about a
> > thermometer. Most thermometers show a range of temperature from -20C
> > to +100C.
> > Usually, level and noise will have the same range [-110;0],
>
> I expect noise to have the range [minimal possibly detected signal
> ---- max expected EIRP ]
> The same applies to signal, which you seem to have labeled as "level".
Yes.
In my API, I have : signal quality, signal level and
noise. Therefore, in my API, "signal" is ambiguous.
> Again, I think I'm probably just really not understanding this so
> please clarify a bit more.
No, I think you get it.
> > Remember, what we care most here is to give a range so that
> > graphical applications know the bound of the value. We don't need to
> > be absolutely accurate here. Think about the thermometer example.
>
> Point taken. In that case representation-wise we should take the
> lowest number for the lowest possible value. For 802.11 though it
> seems the lowest value should be -101 (20 MHz bandwidth) as I
> illustrated but some funky hardware (Atheros) allows even for 5 MHz
> channel widths so because of that this comes down to 107:
>
> ; -174 + (10 * log(5 * 10^6))
> ~-107.01029995663981195219
>
> For 1MHz we get a clean -114:
>
> ; -174 + (10 * log(1 * 10^6))
> -114
>
> Whatever, I guess -110 or -114 is OK then :) I see your point though.
At 1 and 2 Mb/s using Direct Sequence, you have a processing
gain. In other words, you should consider the DS signal to be 1 or 2
MHz, not 20 MHz.
I think I also did some measurements with the Orinoco to see
what values were reported. People hate when it shows values out of
bounds ;-)
> > But yeah, please use whatever value make sense and give good
> > result in userspace applications.
>
> Sure.
>
> Luis
Have fun...
Jean
On Tuesday 01 April 2008 02:47:56 Jean Tourrilhes wrote:
> > do you think it would be feasible
> > to require the drivers to normalize their RSSI to a range of 0-100,
> > so we would have at least some consistency between devices? (of
> > course their steps within this percentage would be different and it
> > would still be impossible to compare these values across different
> > devices).
>
> If the measurement is not linear or log, it does not make
> sense mandating the 0-100, because 50 won't be the mid-point. And we
> assume that devices are not consistent to start with...
> Anyway, to avoid quantisation errors, I prefer to defer
> normalisation to the end software. For example, if the app use a 64
> pixel window to show the RSSI, it wants a value 0-63, not 0-100.
ok, got it :) i will keep max_signal for this, then. it should be used for
IEEE80211_HW_SIGNAL_UNSPEC and IEEE80211_HW_SIGNAL_DB. in the case of dBm i
think we can always assume the same range.
cheers,
bruno