[collectd] Wireless plugin patch for collectd 3.11.5

[Silvio Klaic]

Hi

> I don't understand your functions `ConvertSignalQualityToRssi' and
> `ConvertRssiToSignalQuality' though. They each use two linear functions
> to convert from signal strength to a quality value and back again. Which
> one is used depends on the signal strength - but they don't even have
> different gradients..
>
> Why don't you simply use (100 * (current - min) / (max - min))?

There are two models for conversing dBm to percentage, quadratic and linear.
Which is better don't know, some vendors use linear and some quadratic, take a look at these url if it helps:
http://www.ces.clemson.edu/linux/dbm-rssi.shtml

Function ConvertRssiToSignalQuality is copied from Ralink RT2500 driver utility (see http://rt2x00.serialmonkey.com) and its good balance between two models.
Most cards which we tested were returning values (with original software), closely to these returned with this function.

I wrote ConvertSignalQualityToRssi function to do inverse job than ConvertRssiToSignalQuality, because I found problem with some cards like ASUS WL-130b which returns values in percent:
Inter-| sta-|   Quality        |   Discarded packets               | Missed | WE
 face | tus | link level noise |  nwid  crypt   frag  retry   misc | beacon | 19
   ra0: 0000   85.  199.   59        0      0      0      0      0        0
   ra1: 0000   65.  190.   64        0      0      0      0      0        0
   ra2: 0000   80.  195.   54        0      0      0      0      0        0
   ra3: 0000   69.   42     0        0      0      0      8      0        0
In this /proc/net/wireless listing from one of ours linux routers you can see that other cards uses for level and noise dBm, but ra3 is asus card which returns percentage and values here goes only from 0 to 100.

> Besides, why even convert to some quality indicator? _The_ unit for
> signal strength is dBm (or Dezibel or Bel, chose your poison), so I
> think we should record values in exactly that format.
>
> I can see that converting the ``quality'' returned by a card to dBm may
> be messy and inaccurate, so recording a percentage for these cards would
> be fine for me. I'd prefer to convert them to dBm though.

I agree it is better solution to store values in dBm.

> Please keep in mind that this is only the storage format. If someone is
> uncomfortable with a logarithmic scale you can always use RRDTools `RPN'
> feature (or OO.o what whatever with the CSV files) to convert the values
> for a presentation. (Basically the same applies to temperatures, though
> we're using Celsius there - not Kelvin ;)

I know. I chose percentage because almost all utility software uses by default percentage to display values, and it was easier and faster for me to copy function for conversion in plugin than writing perl code for conversion in cgi script or to use some other method :)

> That being said, you further use the following to decide if the card
> returns a ``quality'' or dBm values:
> -- 8< --
> if (power <= 100) { /* cards returning percent values, test with power
> because noise in dBm can be lower than 100 */
> -- >8 --
> I always thought (and your code indicates) that the power of wireless
> LAN equipment is well below 0dBm, i. e. in the general range of -100 to
> -50 dBm..? I would have thought that this decision should be done as
> follows:
> -- 8< --
> if (power < 0) /* card returns dBm */
>   ...
> else if (power <= 100) /* card returns percentage */
>   ...
> else /* whatever that means */
> {
>   ERROR ("Your WLAN-card is too strong for me!");
>   return (-1);
> }
> -- >8 --
>
> And one last question: In your code there's
> -- 8< --
>  power -= 256.0;
>  ...
>  noise -= 256.0;
> -- >8 --
> Where do these shifts come from? If that's some Linux specific stuff,
> could you please provide a pointer to some documentation or code
> segments? Thanks ;)

I'm more interested where are values returned from /proc/net/wireless in negative form.
As far I know, all new linux distribution (to be more precisely kernel versions 2.4.x and above) display values from /proc/net/wireless in range 0-255.
Original code uses negative values directly and it didn't work for me (didn't store values for signal and noise). That's the reason why I modified that code and wrote this one.

Regards,
Silvio

.---------------------------------- --  -
| E-mail : info at sklaic.info
|.------------------------------------- --  -
|| URL : http://www.sklaic.info