All of lore.kernel.org
 help / color / mirror / Atom feed
From: Holger Schurig <hs4233@mail.mn-solutions.de>
To: linux-wireless@vger.kernel.org
Cc: libertas-dev@lists.infradead.org
Subject: Re: [RFC PATCH] mac80211: use hardware flags for signal/noise units
Date: Tue, 18 Mar 2008 11:57:47 +0100	[thread overview]
Message-ID: <200803181157.47575.hs4233@mail.mn-solutions.de> (raw)
In-Reply-To: <200803082101.24424.bruno@thinktube.com>



>     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
>     rt2x00          dBm(?)  n/a     percent rssi+tx/rx frame
> success rt2400        dBm(?)  n/a
>       rt2500pci     dBm(?)  n/a
>       rt2500usb     dBm(?)  n/a
>       rt61pci       dBm(?)  n/a
>       rt73usb       dBm(?)  n/a
>     rtl8180		nounit	n/a    (?)
>     rtl8187		nounit	(?)    (?)
>     zd1211		dB(?)	/      percent

This list made me think about the libertas values. Here the 
firmware provides SNR and NF and RSSI is calculated from those 
values. However,

Is it ok to add a dBm value (noisefloor) to a dB value (SNR) ??




The libertas firmware can give me SNR and NF for beacons (via 
CMD_802_11_RSSI) and also for each received frame (in the rx 
packet descriptor structure).

In the firmware manual they say:

   SNR  UINT8  Signal to noise ratio for this packet
               This should be a positive value (dB)
   NF   UINT8  Noise floor for this packet (dBm)
               Noise floor is always negative. The absolute
               value is passed.

That was the description for the RX packet descriptor, the 
description for the CMD_802_11_RSSI is basically the same. 

Now I see two macros:

#define CAL_NF(NF)       ((s32)(-(s32)(NF)))
#define CAL_RSSI(SNR,NF) ((s32)((s32)(SNR) + CAL_NF(NF)))

While I understand the CAL_NF() macro, but I'm not sure if the 
second one does the right thing. Or maybe the manual is simply 
wrong. Here are some samples with my WLAN card sitting next to 
an AP:

rxpd:     SNR  41, NF  86
get_rssi: SNR  41, NF  86
rxpd:     SNR  41, NF  86
get_rssi: SNR  42, NF  86
rxpd:     SNR  41, NF  86
get_rssi: SNR  41, NF  86
rxpd:     SNR  41, NF  86
get_rssi: SNR  41, NF  86
get_rssi: SNR  40, NF  85
rxpd:     SNR  41, NF  86


      parent reply	other threads:[~2008-03-18 11:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-08 12:01 [RFC PATCH] mac80211: use hardware flags for signal/noise units bruno randolf
2008-03-08 14:09 ` Michael Buesch
2008-03-09 20:34 ` Johannes Berg
2008-03-18  0:08   ` Luis R. Rodriguez
2008-03-18  1:54     ` bruno randolf
2008-03-18 10:57 ` Holger Schurig [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200803181157.47575.hs4233@mail.mn-solutions.de \
    --to=hs4233@mail.mn-solutions.de \
    --cc=libertas-dev@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.