On 05/02/2010 08:52 AM, Christian Lamparter wrote:
If necessary I can measure the times myself as delta's from one
event to another withing the SH2.
I have not digested the docs I have thoroughly yet but a cursory
review suggests a less than trivial project.
I have not yet found a good high resolution clock inside the ar9170
there are alot of clocks but they all seem to be 16bit. Probably that
will make things harder.
TSF timer could be used for this. (see 802.11-2007, Section 11 et seq.)
It's a 2^64 bit timer with a 1us resolution and a accuracy _better_
or equal to +/- 0.01%.
The register address are at:
- 0x1c3514 (low, AR9170_MAC_REG_TSF_L, read only)
- 0x1c3518 (high, AR9170_MAC_REG_TSF_H, read only)
But it comes at a small price: this timer is sometimes
update& synchronized (802.11 11.1.3.4 and 11.1.4) in
station or ad-hoc mode. The exact details are hidden
inside MAC chip, but it should be possible to disable
both by selecting the monitor mode.
I will have to look into that it might work.
I beleive this project is in ad-hoc mode,
but if the timer is not being altered between the transmission of a
packet and the receipt of its ACK I am fine,
the worst case would be that it is and delta T becomes artificially
smaller. One characteristic of my problem is that
almost all the error is positive delta T overly large.
I was expecting to have to make changes to the ar9170 firmware. I
was expecting to have to devise some means of passing that information
to the Linux driver and to the userspace application.
Well, then you have two more good reasons why to use carl9170:
* the ar9170usb driver and ar9170 firmware don't track tx frames.
carl9170 on the other hand does (every frame has a 8 bit "cookie").
This feature was necessary to generate an accurate tx transmission
feedback report for every individual frame for the driver.
That would be necescary in my application and I have started to work
with the carl9170 driver.
I built the toolchain compiler the firmware and I am building a
linux kernel right now.
* carl9170 has the ability to store additional per-frame data.
In fact, if you don't need to have a different retry rates
you could realloc the 3 * 32 bit "rr" (as in retry rate)
array in the carl9170_tx_superdesc and _carl9170_tx_superdesc
struct (see wlan.h) for your purposes (storage for your time values).
And if you fetched all the data, everything will be sent
with an ordinary tx status feedback report to the application
(add the timer fields into carl9170_tx_status and _carl9170_tx_status
struct - see fwcmd.h)
I need a delta T between some fixed point during the send and some
fixed point during the ACK.
And the MAC address of the device I was sending to. The latter
already is obviously already known, I just have to tie to it.
(* talked about this earlier, but you never know...
carlu _tool_ already provides a low-level HW driver for userspace.
This has the obvious advantage that you won't need to mess with
the kernel driver and network stacks.
The only work you'll have to do is: get the kernel code for
the MAC& PHY initialization and put it into carlu.
But the framework is already there so it's mostly copy + paste )
I beleive you are using DEBUGFS and that was already part of my spec.
Regardless, I am comfortable on the Linux driver side.
The closer I get to the Linux side the more comfortable I am.
Further though the actual timing of each send's delta T needs to be
as accurate and fine grained as possible,
everything else in this project is non-critical. Within reason it
is unimportant how long it takes to propigate data from the AR9170
through to userspace,
Clean and simple will take precedence over any other technical demands.
I would be happy to do that in some fashion that conformed to an existing
or future standard, but I was not anticipating a broad desire for what I am
doing. Variable latencies are highly undesirable in this application,
but the userspace application will be aggregating large amounts of
information, if latencies in what is measured are constrained and the
unit of time measurement is small enough everything will work.
If it comes to that we switch to different hardware, but my project
is bringing a concept that was demonstrated with an expensive SDR to an
ar9170.
It's always nice to have some "added value" for cheap and generic devices.
e.g.: Atheros AR92xx chips can be used as among other stuff as a
full range spectrum analyzer.
And my ability to get consulting work is strongly effected by the
extent I can contribute to Linux.
References, and lists of skills and qualifications on my web site
are dwarfed by
Dave Lynch, DLA Systems <dhlii@xxxxxxxxxx> appearing inside the
kernel tree.
I love this work. I love working for myself, I want to continue to
do so.
I would contribute as I can regardless, but self interest helps.
Regards,
Chr
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.587.7774 dhlii@xxxxxxxxxx http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
