Thanks a lot for your reply.  It has cleared up many things for me.  I'm going to tinker around with a Prism2 based card to see what I can get.  I think modifying with the interrupt vector code is a little bit beyond my abilities at this point, but it's good thing to keep in the back of my mind.

Cheers,
-Mike

On 8/25/06, Stevie <stiabhan@bigpond.net.au> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Hello again

> The research paper I'm using as
a basis for my program assumes that
>  the smallest time resolution possible is 1us.  One thing I missed
>  before is that the timestamps have to be created by the wireless
> card so that interrupt latencies are avoided;  it doesn't matter
> when the application receives the data.  The most important part is
>  that I have a timestamp on each sent or received 802.11 frame.


The cards used by GŁnther and Hoene in their papers are Prism II
(802.11b) cards. The card itself timestamps the frame but in MadWifi
the timestamp is fabricated in the interrupt handler - incurring a
significant latency.

There is a way to more precisely measure the arrival time of the the
interrupts. The CPU timestamp counter is incremented at the CPU clock
frequency (at least for pentiums). If you modify the interrupt vector
code you can capture the TSC value and store it for later use by the
driver itself. Although the logic can be a little tricky (to account
for arrivals of the interrupt from other sources) its possible to get
more precise measurement over repeated readings.

The bad news is the PCI bus speed becomes the key timing constraint
and that is usually 33MHz. At the very best this would place a station
within 10m but maybe the statistical approach of GŁnther and Hoene
could be leveraged to improve that further. I'd be interested in
making he kernel/driver mods as the basis of a paper but it'll be a
while before I get around to it. I don't know if there's any scope for
collaboration on that.

You may also want to look at this report -
http://cisr.nps.navy.mil/downloads/theses/02thesis_morrison.pdf. This
uses a hardware-based approach. This is interesting and hence my
playing with the GNURadio/USRP (I'm not an electronics engineer so
software is easier) as we can measure with a pretty good resolution.
Finally, the 802.11 committee has discussed modifying the standard to
allow precise flight time measurement with just one frame (by
eliminating the major area of guesswork - the MAC processing
overhead). Take a look at the WG papers.

Steve


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE74wvW7aAm65EWy4RA9lbAKCwjsD5GATOpjtKpaE4KNWg6BxgQgCcCdD6
QUHZzhmhIRk83PS4pXzrKfI=
=Le5N
-----END PGP SIGNATURE-----




--
-Mike