[kismac] Re: Signal strength
- From: Robin L Darroch <robin@xxxxxxxxxxxxx>
- To: kismac@xxxxxxxxxxxxx
- Date: Thu, 2 Mar 2006 08:15:50 +0800
At 6:39 AM +0800 2006-03-02, Robin L Darroch wrote:
In this case, the POLA is actually to provide auto-scaling, not the raw
values KisMAC currently shows.
You've generated one case where auto-scaling appears to work.
Take any scheme in the world, and it's trivially easy for anyone to
come up with a single case where the scheme appears to work.
I agree... but my point is that there's no reason to expect
auto-scaled values to be any worse than what we currently get. If
it's not making things worse - and may in some cases actually make
things better - why not at least make it an option?
What's hard is generalizing the scheme to the point where you
can prove beyond a reasonable doubt that it covers at least the vast
majority of cases, and at least has reasonable failure modes for the
I only have the behaviour of my DWL-122, Airport Extreme passive &
active to base my personal observations on. Based on those
observations, I have not seen any behaviour which implies that an
auto-scaled strength reading would be less informative or contrary to
apparent reality as opposed to raw data.
In many cases, you'll get wildly different numbers with
exactly the same computer, exactly the same card, exactly the same
position, and exactly the same transmitter. Wireless networking is
just funny that way -- sometimes someone next door turns on the
microwave, or a digital cordless phone might be in use, or a
cordless video sender might be turned on, and those are just the
most obvious RFI sources I can think of off the top of my head.
All true... but as far as I can see, none of that would be worse
auto-scaled than raw.
I don't think we should be causing the situation to be even
more confusing to people by adding yet another factor that could
throw everything totally off.
I agree that it needs to be done (if at all) in such a way that
additional confusion is avoided. However, I'm not sure about how it
would "throw everything totally off"... is there a situation where
you think it might do so, and if so, how? If you can think of a way
that such scaling might throw everything totally off, it would be
good if you could suggest an example so that the problem can be
avoided (either by refining the algorithm, or by throwing the feature
out altogether). I don't like the idea of adding features which can
make things seriously worse ("show recently used menu items first"
from Microsoft is a prime example), but so far I think this could
still work well as long as the preferences are handled cleanly.
Hmm... this is getting a bit big... but the more I think about it, the
more convinced I am that it would be a considerable improvement to the
current numbers we show - we just need to be sure to get it right.
At the very least, if you're going to do it, please make sure
that it's not turned on by default, and that it's difficult to
accidentally turn on, and that you provide suitable warnings to
people if they do decide to turn it on.
Agreed on the "not on by default" - the default should be raw,
whether we later add dBm and/or auto-scaling... and no non-default
preference should be easy to select accidentally (that's just poor
interface design). As for the warning, if we're going to go down
that path then we should put the warning on the whole package, since
the same impossibility of comparing readings applies to raw signal
data. I don't think the whole package needs it, so nor should the
auto-scaling. It won't be on by default, but the sky won't fall if
someone decides to turn it on.
The world has too many warning labels already. :)
This doesn't exclude the possibility of using dBm if/when we can gather
data on translating raw signals to dBm for all supported adapters: just
let the user choose - raw, dBm, or auto-scaled.
I'd be much more interested in seeing work done on dBm first,
and I'm sure there are lots of other good things that could be
worked on before auto-scaling, but then I'm not the one writing the
I'd love to see dBm stuff done - I just haven't the first idea how to
do any of it. In terms of the algorithms, auto-scaled is
(relatively) easy... dBm will take a lot more doing, as it will
almost certainly need to be adapter or driver specific. I gather we
have a start on dBm translation for the Airport active mode, but even
Airport Extreme active and passive modes give completely different
numbers, so there's a lot of information left to gather before we'll
be able to start considering dBm implementation.
On the bright (?) side, I won't have any time to look at trying to
implement this myself for the next couple of months (the algorithmic
stuff I could do in 15 minutes, but the interface and data storage
stuff will take me ages to figure out as I've done very little of it
before, and don't even really know how KisMAC save files are
formatted or handled)... so there's plenty of time to see whether dBm
work can happen before I'll be able to do auto-scaling work. Of
course, if any other developers want to have a go at the preferences
interface and save-file handling for auto-scaling, I'm happy to look
after the algorithmic side of it. Or, if no-one but me likes the
idea of auto-scaling, then it may just be delayed indefinitely. In
the mean time, I'm going on holiday!
Robin L. Darroch - PO Box 2715, South Hedland WA 6722 - +61 421 503 966
robin@xxxxxxxxxxxxx - robin@xxxxxxxxxxx - robin@xxxxxxxxxxxxx
Other related posts: