[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 other cases.

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 code.

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!

Cheers,
Robin
--

-------------------------------------------------------------------------
 Robin L. Darroch - PO Box 2715, South Hedland WA 6722 - +61 421 503 966
      robin@xxxxxxxxxxxxx - robin@xxxxxxxxxxx - robin@xxxxxxxxxxxxx


Other related posts: