Brainstorming AP ranging

[mysticvirgo67]

Well, I had a serious bout of insomnia last night and had plenty of time to do some mental "background processing" while watching "NOVA" on PBS. The program was about the Universe , as is vcommon with that show. They did alot of talking about the speed of light, satellites and such.

That and posting in these forums lead me to thinking, Knowing speed of light is a constant and that radio and microwaves also travel speed of light, it should be possible calculate the distance to an AP using ping or timestamp or such.

Using the Ping command is no good because it has only millisecond resolution. Is there time data in the AP polling process? I think that counting CPU cycles via the
Andrew, What is the process you use in Vistumbler to accomplish the ranging? In which data layer is this info found, int the physical layer, Transport layer, packets ect?

Does the results of Netsh command in Vista provide timing data?

I am fairly certain that accuracy will depend on processing speed of the target Ap/Router (I can assume that the majority of them run 300 MHz) , processor speed (assuming 1 GHz) and the time required to run the code?


This is more of a 'though experiment" than anything but having others to bounce ideas off of is nice.

[pferland]

i don't think using time would be a good ruler, seeing how light and radio waves travel further in a few milisecond then your average access point could reach. CPU cycles might be better but also not constant from one system to another.

just my 2 cents, may be dead wrong though

[mysticvirgo67]

So I wonder if the packet infromation would contain time information? If so, how precise would that be? I have a packet sniffer that I plat with here at the house, I'll check on that sometime next few days

[pferland]

I opened up Wireshark on my work computer (winXP) and the packets do have time information, but doing this on a wireless card in windows is going to be hard because some NICs don't have promiscuous mode or monitor mode. I dont have a wireless card here at work, I only have a Broadcom in my laptop at home. Andrew has an Intel wireless card, so we could try something like that on his. But then again as I look back at wireshark, the Time is only the arival time, I could not find a 'departure' time anywhere in the packet.

[mysticvirgo67]

Kewl I have Wireshark , too. And a broadcomm in my laptop..
Hmmm... well, I was thinking that mabey one could initiate a timin loop... but then there would be an added inaccuracy from system to system in the execution speed of the code from machine to machine. I am starting to think that any significant degree of precision and accuracy would not be possible without a consistant ,platform independant clock.

HOWEVER, if one can access the timing clock in in a GPSr.... They HAVE to have ultra precise and independent clocks. So if one polls the GPSr clock on the departure of a packet and then again with the arrival of the incoming packet. then do the math. Repeat a few times to determine the modality of the data ( ya know best 17 out of 20 or so) to filter out some of the noise in the data and BOOM, there is the range independent of any system clocks...

Granted there will be a little bit of a "reaction time" between detecting the arriving packet, reconizing it AS an incoming packet then grabbing the GPSr clock signal. Perhaps this can be compensated for with a calibration subroutine during the initialization of the application?

I'll try to take some time in the next week or so to work on some pseudocode. I was about to say I could dig through GPSr data to isolate the timestamps, but then remebered that I don't have a working GPSr DUH!

Hmmm.. now all I gotta do is mount my Vagi onto a rotating mount, we could have a true WIFI radar.. A WIDAR!! WIfi Detection and Ranging!! Now THAT would be a cool toy!

[mysticvirgo67]

Damn! the delay would still be dependant on the processing speed of the AP... hmm... I suppose a table of AP processor speeds per manufacturer would need to be consulted...

[ACalcutt]

GPS timestamps only go down to seconds.

[mysticvirgo67]

But wouldn't the stamp in the signals sent by the Sats be down to milliseconds? Is this not the basic principle behind GPS. Sat sends a signal with the time in it's onboard clock and that signal is compared with the time on the reciever's clock and the same math of finding eleapsed time from difference.

Now let us remeber, Gentlemen, this is more of a thought experiment to provide inspiration...

Lemme do a little more googling about this to see what I can find..

[mysticvirgo67]

well, I have learened more about GPS signalas than I care to... Craxy insane schemes for errorchecking algorithims involved.. and yes, Andrew, signals a re sent once a second...and I could not find the resolution of the timing signal.. best I could do us learn that the binary signal code is two to the negative 30th seconds,.
Aside.. GPS sats compensate for Ionospheric effects by sending the frames simutaniously on two different frequencies.. Clever clever.. the difference in recieved times generates a correction factor COOL!!

Npt all errors are eliminated resulting ina a wandering of position of 1 meter per second in the horizontal plane. This explains to me why if I am stationary, the KML shows the position track bouncing around.

Back to ranging.. an acceptible circle of error fpr me would be 3 meters or 10 feet. So millisecond precision would be fine. Normal ping requests are timed in milliseconds. Can pings be directed at a mac address instead of an IP??

[pferland]

no, this is one of the things that we wanted to try and figure out, you would have to be connected to each AP to do a ping. then you are limited to the ones that are open, or you already have a key for. then you wouldn't have enough time to connect and ping the AP as you are driving by, or do multiple APs at once, when you are walking around somewhere.

right now, every Signal ranging app that i have seen, more or less guesses at the range of an AP by the signal strength.

[ACalcutt]

The problem i see with a ping is that nothing we are doing is contant

ping is going to be affected by connection stregnth. so it will be affected by walls, distance, type of antenna, wireless card

I was origionally thinking maybe we could do something based on signal strength in relation to spec wifi distances.
for example.. with 802.11b/g we have a maximum (outdoor) distance of 300 ft (http://en.wikipedia.org/wiki/IEEE_802.11)
maybe we could figure out at
99% signal we are 1ft away
50% signal we are 150ft away
1% signal we are 300ft away
But this would be affected by antenna, wifi cards, and access points

[Freebe]

@Andrew
The Problem here is the word ( 300ft ) this only applies to a Standard 802.11b/g and some are going further, ie. mine.
So you would have to use some sort of dividing method. ( bad news )
But you might be able to work out the difference between the strong and the weak Signal ie. -91% and -50% this giving you a Value.

But i am NO specialist on this.

[ACalcutt]

Thats what I was saying, antenna and network card differences would make that way not work. I would think the solution to that would be to make maximum distance setable, so if the user had a high gain adapter and has an estimated range of 600 ft, they could set that somewhere and the distance mesurements would change accordingly

if we could do something simple like
Distance * Signal% = Estimated_Distance

so with a standard adapter at 50% signal you would have
300ft x .50 = 150ft

But if you had a better adapter/antenna it would be
600ft x .50 = 300ft

Maybe we could figure out a way to take Db gain to adjust the antenna distance, like
(300ft x Db_Gain) x .50 = estimated distance
so with my 14db gain antenna we would get something like this
(300ft x 14) x .50 = 2100ft

keep in mind, all the numbers above are made up and not based on any real testing

[ACalcutt]

And actually, we wouldn't want to use Signal%, we would want to use its inverse, otherwise as the signal goes down so would the distance, where we would want distance to go up as the signal goes down.

so the above formulas should be more like
Distance * ((100-Signal) / 100) = Estimated_Distance
I'm going to change our signal to 25% because its easier to show, so we would end up with this
300ft * ((100-25) / 100)
300ft * (75 / 100)
300ft * .75 = 225ft

or with the other formula
(300ft x Db_Gain) * ((100-Signal) / 100) = Estimated_Distance
So with a 14db antenna at 25% signal
(300ft x 14) * ((100-25) / 100)
(300ft x 14) * (75 / 100)
(300ft x 14) * .75 = 3150ft

[mysticvirgo67]

I supposes that would work..and if code could include a setting for entering the antenna dB,. Not perfect.. Thee is the point of different ap's at a similar distance showing at varying distances simply because of differences in radiated power, right?

By ranging off timing signal, the range would be accurate regardless of signal strength. So long as a signal is relyably ( cant spell for crud) detectable, of course

[mysticvirgo67]

ACK! does this mean another coumn in the 'Stumbler GUI!!! ACK!!!

[pferland]

The more options the better in my opinion, you wouldn't want Vistumbler to turn into Apple( ) like software now would you?

[mysticvirgo67]

as long as the options include the option to exclude options, then I agree that the more the merrier.
Aooohhh!! Phil said the "A" word!

[mysticvirgo67]

Oh OT and BTW Andrew, I just recently noticed that the Vistumbler settings menu is duplicated in the tabbed settings window. Why have the option of a pulldown menu AND a tabbed interface for the settings. Would seem more elegant just to have the tabbed window open when options/settings is selected on the toolbar and not bother with the code for the pulldown menu.

[ACalcutt]

Because I like to be able to go to specific windows in one step, like if i want to go right to AutoKML settings.

[mysticvirgo67]

Ahhh.. more options ..LOL okay then..
I had long ago discovered a windows trueism a while back... there are at LEAST three ways to accomplish a task. Example; Cut n paste in an application.. you can go through the menu bar, or right click and select or use the keyboard shortcut...