mac80211: use hardware flags for signal/noise units
Subsystems (3)
PATCH 1/1 mac80211: use hardware flags for signal/noise units
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(-)
drivers/net/wireless/adm8211.c +3 -3
@@ -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 */
drivers/net/wireless/at76_usb.c +3 -2
@@ -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);
drivers/net/wireless/ath5k/base.c +5 -18
@@ -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);
drivers/net/wireless/b43/main.c +4 -4
@@ -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))
drivers/net/wireless/b43/xmit.c +2 -3
@@ -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 );
drivers/net/wireless/b43legacy/main.c +3 -4
@@ -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))
drivers/net/wireless/b43legacy/xmit.c +2 -2
@@ -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);
drivers/net/wireless/iwlwifi/iwl-3945.c +9 -9
@@ -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; }
drivers/net/wireless/iwlwifi/iwl-4965.c +6 -6
@@ -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); }
drivers/net/wireless/iwlwifi/iwl-core.c +4 -12
@@ -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
drivers/net/wireless/iwlwifi/iwl3945-base.c +4 -11
@@ -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 ;
drivers/net/wireless/p54common.c +3 -3
@@ -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 ;
drivers/net/wireless/rt2x00/rt2400pci.c +2 -3
@@ -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);
drivers/net/wireless/rt2x00/rt2500pci.c +3 -3
@@ -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);
drivers/net/wireless/rt2x00/rt2500usb.c +3 -3
@@ -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);
drivers/net/wireless/rt2x00/rt2x00dev.c +2 -2
@@ -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;
drivers/net/wireless/rt2x00/rt61pci.c +2 -3
@@ -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);
drivers/net/wireless/rt2x00/rt73usb.c +2 -3
@@ -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);
drivers/net/wireless/rtl8180_dev.c +4 -4
@@ -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 ;
drivers/net/wireless/rtl8187_dev.c +4 -5
@@ -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;
drivers/net/wireless/zd1211rw/zd_mac.c +5 -6
@@ -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 );
include/net/mac80211.h +31 -15
94 lines not on this page · raw message
net/ieee80211/ieee80211_rx.c +1 -1
@@ -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 ;
net/mac80211/debugfs_sta.c +1 -1
@@ -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 );
net/mac80211/ieee80211.c +5 -5
@@ -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);
net/mac80211/ieee80211_i.h +1 -1
@@ -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;
net/mac80211/ieee80211_ioctl.c +14 -6
@@ -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; }
net/mac80211/ieee80211_sta.c +6 -6
@@ -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,
net/mac80211/rx.c +2 -2
@@ -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 )) {
net/mac80211/sta_info.h +1 -1
@@ -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 ];
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=
Quoted 4 lines · Luis R. Rodriguez
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.
Quoted 1 line
On Wed, Mar 26, 2008 at 8:30 AM, Bruno Randolf <[email protected]> =
Quoted 6 lines · wrote:
=20
Quoted 1 line
diff --git
a/include/net/mac80211.hb/include/net/mac80211.h=20
Quoted 3 lines
@@ -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
Quoted 4 lines
Quoted 4 lines
* the 2.4 GHz band.
+ *
+ * @IEEE80211_HW_SIGNAL_DB:
+ * Hardware gives signal values in dB, decibel difference fro=
m an
Quoted 1 line
Quoted 1 line
+ * arbitrary, fixed reference. If possible please provide dBm=
instead.
Quoted 3 lines
Quoted 1 line
+ *
=20
Signal should given in either be in dBm or an unspecified value. Sinc=
e
Quoted 3 lines
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=
,
Quoted 1 line
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.
Quoted 3 lines
Quoted 3 lines
+ *
+ * @IEEE80211_HW_SIGNAL_UNSPEC:
+ * Hardware can provide signal values but we don't know its u=
nits. To be
Quoted 1 line
Quoted 1 line
+ * able to standardize between different devices we would lik=
e linear
Quoted 1 line
Quoted 1 line
+ * 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.
Quoted 2 lines
Quoted 2 lines
+ * @IEEE80211_HW_SIGNAL_DBM:
+ * Hardware gives signal values in dBm, decibel difference fr=
om
Quoted 1 line
Quoted 1 line
+ * one milliwatt. This is the preferred method since it is st=
andardized
Quoted 4 lines
Quoted 4 lines
+ * between different devices.
+ *
+ * @IEEE80211_HW_NOISE_DBM:
+ * Hardware can provide noise floor values in units dBm, deci=
bel difference
Quoted 1 line
Quoted 1 line
+ * from one milliwatt.
Noise only defined in dBm ? Some older devices have noise in
"unspec". I also don't know what Atheros does here.
Quoted 13 lines
Quoted 13 lines
*/
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,};
Quoted 5 lines
Quoted 1 line
/**
=20
<-- snip -->
=20Quoted 1 line
diff --git
a/net/mac80211/ieee80211_ioctl.cb/net/mac80211/ieee802=
11_ioctl.c
Quoted 4 lines
Quoted 4 lines
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,
Quoted 11 lines
Quoted 11 lines
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 */
Quoted 7 lines
Quoted 7 lines
+
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;
Quoted 7 lines
=20
I'm pretty perplexed by the original intention of Wireless Extensionsmax_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],
Quoted 1 line
* if the quality is dBm, it will be in the range [
max_qual;=
0].
Quoted 2 lines
* Don't forget that we use 8 bit arithmetics... */
structiw_qualitymax_qual; /* Quality of the lin=
k */
Quoted 9 lines
=20
max_qualis a struct though,iw_qualitywhich is:
=20
/*
* Quality of the link
*/
structiw_quality
{
__u8qual; /* link quality (%retries, SN=
R,
Quoted 1 line
%missed beacons or better.=
=2E.) */
Quoted 3 lines
__u8 level; /* signal level (dBm) */
__u8 noise; /* noise level (dBm) */
__u8 updated; /* Flags to know if updated *=/
Quoted 5 lines
};
=20
Jean, ifrange->max_qual.levelis 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.
Quoted 1 line
Also, technically the noise should change depending on the channel ba=
ndwidth.
Quoted 49 lines
=20
IEEE-802.11 Channel bandwidth802.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)
=20mcgrof@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))
Quoted 8 lines
~-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
Quoted 1 line
chain for the hardware when known; for example for Atheros it seems t=
o
Quoted 2 lines
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.
Quoted 3 lines
[1] http://madwifi.org/wiki/UserDocs/RSSI
=20
Luis
Regards,
Jean
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 10 lines · On Thursday 27 March 2008 07:59:11 Luis R. Rodriguez wrote:
Quoted 9 lines
+ * @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. + *
Quoted 5 lines
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
hi jean!
i really appreciate your input based on your experiences with the wireless extensions!
Quoted 2 lines · 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!
Quoted 4 lines
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.
Quoted 6 lines
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.
Quoted 5 lines
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.
Quoted 4 lines
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,...
Quoted 4 lines
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.
Quoted 9 lines
Quoted 6 lines
Quoted 6 lines
+ *
+ * @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.
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
Quoted 3 lines
+ * @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
Johannes Berg
maintainerQuoted 7 lines · Bruno Randolf
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:
Quoted 8 lines
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 1mWalso 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
Quoted 4 lines · bruno randolf
hi jean!
i really appreciate your input based on your experiences with the wireless extensions!
My pleasure, always glad to help ;-)
Quoted 7 lines
Quoted 4 lines
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"?
Quoted 7 lines
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_DBin 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.
Quoted 11 lines
Quoted 6 lines
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.
Quoted 2 lines
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
Quoted 3 lines
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.
Quoted 8 lines
Quoted 4 lines
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.
Quoted 7 lines
Quoted 2 lines
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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 1 line
bruno
Regards,
Jean
Quoted 12 lines · On Thursday 27 March 2008 21:47:43 Johannes Berg wrote:
Quoted 11 lines · Bruno Randolf
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
pointIEEE80211_HW_SIGNAL_DBM- dBm, difference to 1mW
Quoted 8 lines
Quoted 4 lines
IEEE80211_HW_NOISE_DBM- dBm, difference to 1mWalso 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
Quoted 19 lines · On Friday 28 March 2008 01:52:37 Jean Tourrilhes wrote:
Quoted 9 lines
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_DBin 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.
Quoted 9 lines
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:
Quoted 3 lines
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.
Quoted 6 lines
Quoted 3 lines
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
Quoted 9 lines · bruno randolf
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:
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.
Quoted 6 lines
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.
Quoted 8 lines
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.
Quoted 5 lines
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.
Quoted 6 lines
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.
Quoted 2 lines
best regards,
bruno
Have fun... Jean
Quoted 7 lines · On Tuesday 01 April 2008 02:47:56 Jean Tourrilhes wrote:
Quoted 6 lines
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).
Quoted 6 lines
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
Quoted 44 lines · bruno randolf
Quoted 10 lines · On Thursday 27 March 2008 07:59:11 Luis R. Rodriguez wrote:
Quoted 9 lines
+ * @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. + *Quoted 5 lines
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.
Quoted 3 lines
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
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
Quoted 5 lines · Luis R. Rodriguez
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.
Quoted 4 lines
Quoted 2 lines
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.
Quoted 8 lines
Quoted 5 lines
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.
Quoted 5 lines
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
Quoted 8 lines
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.
Quoted 8 lines
Quoted 5 lines
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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 10 lines
Quoted 6 lines
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.
Quoted 4 lines
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).
Quoted 11 lines
Quoted 2 lines
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.
Quoted 6 lines
Quoted 5 lines
Quoted 3 lines
Jean, if
range->max_qual.levelis 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.
Quoted 9 lines
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.
Quoted 10 lines
Quoted 6 lines
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.
Quoted 2 lines
Again, I think I'm probably just really not understanding this so please clarify a bit more.
No, I think you get it.
Quoted 11 lines
Quoted 3 lines
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))
Quoted 8 lines
~-107.01029995663981195219For 1MHz we get a clean -114:
; -174 + (10 *
log(1 * 10^6))-114Whatever, 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 ;-)
Quoted 6 lines
Quoted 2 lines
But yeah, please use whatever value make sense and give good
result in userspace applications.Sure.
Luis
Have fun... Jean
Quoted 1 line · On Thursday 03 April 2008 08:19:07 Luis R. Rodriguez wrote:
Quoted 1 line
Quoted 1 line
Jean, if
range->max_qual.levelis set to -110 does this mean sig=
nal
Quoted 1 line
Quoted 1 line
Quoted 1 line
level can be set only from -110 up to 0 ? Is max_qual.level supp=
osed
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
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
Quoted 6 lines
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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 13 lines · On Thursday 03 April 2008 04:27:31 Luis R. Rodriguez wrote:
Quoted 13 lines
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.
Quoted 7 lines
Quoted 3 lines
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