[ath9k-devel] Fixing the rate and rate relationship to OFDM

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[John Clark]

Many people seem to desire the bit rate to be the 'highest possible', and have that automagically set.

For some applications, I like to be able to set a specific bit rate, and have that bit rate used no matter the resulting errors.

I have looked a the code briefly, and it seems that there is the possibility for setting up several retries, with changes in bit rate.

So, the questions are:

1) how to 'fix' a rate, disable adjustments on retries, etc?
2) What is the relationship between the bit rate selected at this OS level, and the subcarrier modulation of the RF signal?

Thanks,
John Clark.

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[shinnazar]

You should look at minstrel_ht code. there you can set specific rate at all
retry stages. But I think you should care about the error level, because
high error rates decreases Aggregate frame length consequently shows very
little throughput that may be not tolerable for your application.

Shinnazar

-----Original Message-----
From: John Clark [mailto:jeclark2006 at aim.com] 
Sent: Thursday, March 28, 2013 3:49 AM
To: ath9k-devel at lists.ath9k.org
Subject: [ath9k-devel] Fixing the rate and rate relationship to OFDM

Many people seem to desire the bit rate to be the 'highest possible', and
have that automagically set.

For some applications, I like to be able to set a specific bit rate, and
have that bit rate used no matter the resulting errors.

I have looked a the code briefly, and it seems that there is the possibility
for setting up several retries, with changes in bit rate.

So, the questions are:

1) how to 'fix' a rate, disable adjustments on retries, etc?
2) What is the relationship between the bit rate selected at this OS level,
and the subcarrier modulation of the RF signal?

Thanks,
John Clark.

_______________________________________________
ath9k-devel mailing list
ath9k-devel at lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[John Clark]

On Mar 28, 2013, at 4:32 AM, shinnazar wrote:

> You should look at minstrel_ht code. there you can set specific rate at all
> retry stages. But I think you should care about the error level, because
> high error rates decreases Aggregate frame length consequently shows very
> little throughput that may be not tolerable for your application.

Thanks for the pointer.

This 'need' is for testing the characteristics of the RF signal, and so the actual throughput is not necessarily 'important'.

Since using 'test modes' of the Atheros chip set seems to be part of the 'black box' that is not divulged to the public, one
has to find ways to perform tests, with what is available on the open source driver.

John Clark.

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[Adrian Chadd]

Which test modes are you after?




adrian

On 28 March 2013 10:45, John Clark <jeclark2006@aim.com> wrote:
>
> On Mar 28, 2013, at 4:32 AM, shinnazar wrote:
>
>> You should look at minstrel_ht code. there you can set specific rate at all
>> retry stages. But I think you should care about the error level, because
>> high error rates decreases Aggregate frame length consequently shows very
>> little throughput that may be not tolerable for your application.
>
> Thanks for the pointer.
>
> This 'need' is for testing the characteristics of the RF signal, and so the actual throughput is not necessarily 'important'.
>
> Since using 'test modes' of the Atheros chip set seems to be part of the 'black box' that is not divulged to the public, one
> has to find ways to perform tests, with what is available on the open source driver.
>
> John Clark.
>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[John Clark]

On Mar 28, 2013, at 11:19 AM, Adrian Chadd wrote:

> Which test modes are you after?

I'd like to be able to 'turn on' transmitter continuously, with all subcarriers at max power, to then determine channel power.

This is a test mode, and not an operational mode.

Fixing the bit rate, loading up a bunch of packets, etc. sort of gives a 'asymptotic' approximation of this... but at the moment that's all I have to work with.

I believe such 'test modes' to exist, since this is what would be used calibrate, or verify the device. But since I don't have access to this level of documentation,
I can only 'guess' as to how this would be done.

John Clark.


> 
> 
> 
> 
> adrian
> 
> On 28 March 2013 10:45, John Clark <jeclark2006@aim.com> wrote:
>> 
>> On Mar 28, 2013, at 4:32 AM, shinnazar wrote:
>> 
>>> You should look at minstrel_ht code. there you can set specific rate at all
>>> retry stages. But I think you should care about the error level, because
>>> high error rates decreases Aggregate frame length consequently shows very
>>> little throughput that may be not tolerable for your application.
>> 
>> Thanks for the pointer.
>> 
>> This 'need' is for testing the characteristics of the RF signal, and so the actual throughput is not necessarily 'important'.
>> 
>> Since using 'test modes' of the Atheros chip set seems to be part of the 'black box' that is not divulged to the public, one
>> has to find ways to perform tests, with what is available on the open source driver.
>> 
>> John Clark.
>> 
>> 
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[Adrian Chadd]

On 28 March 2013 12:29, John Clark <jeclark2006@aim.com> wrote:
>
> On Mar 28, 2013, at 11:19 AM, Adrian Chadd wrote:
>
>> Which test modes are you after?
>
> I'd like to be able to 'turn on' transmitter continuously, with all subcarriers at max power, to then determine channel power.
>
> This is a test mode, and not an operational mode.

Felix and I are looking into opening this up for the 11n chips.

There are some interesting FCC implications by doing this, just so you know.



Adrian

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[Holger Schurig]

> Felix and I are looking into opening this up for the 11n chips.
> There are some interesting FCC implications by doing this, just so you
know.

Adrian, open it just for ham radio amateurs. We are allowed (here in
Germany, at least) to use up to 75 W PEP tx power on 2.3 GHz and 5.7 GHz,
unfortunately "only" with 10 MHz band width.

Holger, DH3HS :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130402/d90f69c3/attachment.htm 

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[Adrian Chadd]

On 2 April 2013 06:04, Holger Schurig <holgerschurig@gmail.com> wrote:
>> Felix and I are looking into opening this up for the 11n chips.
>> There are some interesting FCC implications by doing this, just so you
>> know.
>
> Adrian, open it just for ham radio amateurs. We are allowed (here in
> Germany, at least) to use up to 75 W PEP tx power on 2.3 GHz and 5.7 GHz,
> unfortunately "only" with 10 MHz band width.

It's not as easy as "open it up to amateurs", as the ham rules are
different per country.

And then if someone leaks this stuff out to non-ham users, what then?

Hence why it's taking time to figure out the "right" solution.



Adrian

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[John Clark]

On Apr 2, 2013, at 6:04 AM, Holger Schurig wrote:

> > Felix and I are looking into opening this up for the 11n chips.
> > There are some interesting FCC implications by doing this, just so you know.
> 
> Adrian, open it just for ham radio amateurs. We are allowed (here in Germany, at least) to use up to 75 W PEP tx power on 2.3 GHz and 5.7 GHz, unfortunately "only" with 10 MHz band width.
> 
> Holger, DH3HS :-)

In the US there is a similar amateur band at 2.39 GHz. (It was 2.3-2.4, but commercial interests 'bought' the 2.31 to 2.39 chunk...). I don't believe there a 10 MHz BW limit, but the QSL.NET site gives 20, 10, and 5 MHz band frequency centers... which the Atheros chips can do.

I've thought about getting my Ham license to allow me to configure for the amateur bands at trade shows, and side step the 'white noise' that the ordinary WIFI spectrum seems to have at such venues.

John Clark.

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[Adrian Chadd]

On 2 April 2013 11:15, John Clark <jeclark2006@aim.com> wrote:

> In the US there is a similar amateur band at 2.39 GHz. (It was 2.3-2.4, but commercial interests 'bought' the 2.31 to 2.39 chunk...). I don't believe there a 10 MHz BW limit, but the QSL.NET site gives 20, 10, and 5 MHz band frequency centers... which the Atheros chips can do.
>
> I've thought about getting my Ham license to allow me to configure for the amateur bands at trade shows, and side step the 'white noise' that the ordinary WIFI spectrum seems to have at such venues.

This has come up in the past.

The problem is that NICs aren't tested for those frequency bands.

You'd have to do your own local certification just to ensure that the
NIC is working correctly and not spewing crap everywhere.

Just because the RF synth may go down to 2.3GHz, doesn't mean that it
will do so without spurs, distortion; doesn't mean that the chosen
LNAs/FEMs aren't going go distort at that point; that they don't draw
higher current when operating out of the normal bands, leading to
distortion; etc, etc.

I'd like to write/release a bunch of testing tools to let the open
community do this themselves, but the worry is that the FCC will get
angry.



Adrian

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[Jerald A DeLong]

> I'd like to write/release a bunch of testing tools to let the open
> community do this themselves, but the worry is that the FCC will get
> angry.
> 

Let them get angry, the HAMs will police there own.


Jerry, KD4YAL

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[Adrian Chadd]

On 2 April 2013 16:05, Jerald A DeLong <kd4yal@tampabay.rr.com> wrote:
>
>> I'd like to write/release a bunch of testing tools to let the open
>> community do this themselves, but the worry is that the FCC will get
>> angry.
>>
>
> Let them get angry, the HAMs will police there own.

As I've said many times before, it's not the ham enthusiasts I'm worried about.

The driver as it stands has more than enough rope for people to hang
themselves with, legally speaking. Personally, speaking as me and not
as my employer or any related companies, _I_ think the onus should be
on the device owner and not on the manufacturer. I'd rather that the
devices be as flexible as possible so that people who wish to tinker
can. But unfortunately enough people have shown they're quite happy to
flaunt the radiation restrictions that regulatory domains get cranky.

If you'd like to see this change for the better, then users and
companies alike need to find a way to get inserted into the FCC
feedback process and be proactive about this. No voices being heard?
Don't be surprised when rulings swing away from this whole open radio
thing we've all come to love and enjoy from Atheros chips as they
stand.

So, stop complaining on the ath9k-devel list and start writing letters
to the FCC already. Constructive ones.

Sheesh. :-)



Adrian

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[Peter Stuge]

Adrian Chadd wrote:
> FCC implications

I don't see how Qualcomm can be held liable for what users do.

If that is likely to actually happen, that suggests to me that users
are not actually legal entities responsible for their actions. I'd be
surprised if that's the case.


//Peter

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[Adrian Chadd]

On 2 April 2013 06:51, Peter Stuge <peter@stuge.se> wrote:
> Adrian Chadd wrote:
>> FCC implications
>
> I don't see how Qualcomm can be held liable for what users do.
>
> If that is likely to actually happen, that suggests to me that users
> are not actually legal entities responsible for their actions. I'd be
> surprised if that's the case.

The FCC isn't that clear-cut. From what I've been told, they don't
give you explicit rules to meet, they give you guidelines, and tell
you when you're doing things that they find disconcerting.

Then your lawyers and their lawyers get into discussions, etc.

So it's not as nice an environment to live in as you'd think. :-)



Adrian

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[Peter Stuge]

Adrian Chadd wrote:
> >> FCC implications
> >
> > I don't see how Qualcomm can be held liable for what users do.
> 
> The FCC isn't that clear-cut. From what I've been told, they don't
> give you explicit rules to meet, they give you guidelines, and tell
> you when you're doing things that they find disconcerting.

Again, I don't see the risk. An object is either legal or illegal
to build and posess, to sell, and/or to operate.

The object is the radio.

As far as I know FCC has no problem with anyone merely building and
posessing radios. (Which makes sense, because how would they know?)

Selling objects is trade. Trading some objects is illegal - does the
FCC have a problem with radios being traded? I wouldn't expect that
they are too involved in trade.

Operating objects can be illegal. Users operate radios. More
specifically, many users outside FCC jurisdiction operate Qualcomm
radios.

That's why I don't see how Qualcomm could be liable for what users do.

Of course it's easier for the FCC to go after Qualcomm instead of
going after users doing something illegal.

That doesn't stop anyone who wants to operate radios illegaly from
doing so.


> Then your lawyers and their lawyers get into discussions, etc.

It's important to understand what the other side intends, but I
really don't understand how Qualcomm could be held liable and thus
would need to care about the FCC with regard to publishing code.


//Peter

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[Adrian Chadd]

Yes, the FCC will chase after people who make/sell devices that are in
violation of licencing requirements. Eg, continuous abuse by people
who are disabling DFS on DFS requiring channels, then deciding to
operate near airports.

It's not as clear-cut as you're making it out, Peter. Please accept
that. No amount of logical reasoning here is going to change the
reality of the situation.



Adrian

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[Peter Stuge]

Adrian Chadd wrote:
> Yes, the FCC will chase after people who make/sell devices that are
> in violation of licencing requirements.

That's a problem of course. :(


> Eg, continuous abuse by people who are disabling DFS on DFS
> requiring channels, then deciding to operate near airports.

Abuse sucks really badly! But making abuse the problem of someone
other than the abusive also sucks really badly.


> No amount of logical reasoning here is going to change the reality
> of the situation.

Yep, I know that the products will remain artificially limited.


//Peter

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[John Clark]

On Apr 2, 2013, at 9:43 AM, Peter Stuge wrote:

> Adrian Chadd wrote:
>>>> FCC implications
>>> 
>>> I don't see how Qualcomm can be held liable for what users do.
>> 
>> The FCC isn't that clear-cut. From what I've been told, they don't
>> give you explicit rules to meet, they give you guidelines, and tell
>> you when you're doing things that they find disconcerting.
> 
> Again, I don't see the risk. An object is either legal or illegal
> to build and posess, to sell, and/or to operate.
> 
> The object is the radio.
> 
> As far as I know FCC has no problem with anyone merely building and
> posessing radios. (Which makes sense, because how would they know?)


The FCC does 'care' if someone makes a device which interferes with licensed bands. If one 'builds' radios, one needs to be under some form of license, such as Ham license for 'amateur/hobbiest', or temporary license for other bands. In the case of the ISM bands such as 900 MHz, 2.4/5 GHz, since there is no 'license' for individual radio use, the signal characteristics are regulated, and before 'using the device', however built, one has to convince the FCC that it does not exceed the regulation limits, either in band, or creating 'noise' outside of the band.

This whole issue is why there was a 'binary only HAL' in the first place, and why it has been so difficult to get information at the 'radio level'. (There's also the matter of the 'licensing' but that could be seen as  primary barrier against 'mis use'... namely someone is not going to pay big bux just to jam their neighbor's WIFI, when a simple procedure involving alligator clips, and overriding the microwave door safety interlocks would produce enough 2.4 band noise to take out the neighbors... and fry the neighbor's kids at the same time...).

Atheros in that respect has been a 'leader', there are other companies that are essentially 'Fort Knox' when it comes to programming their devices, and that's the reason why there was the 'windows driver' support to allow a binary driver to run in Linux...

There's also the 'avoiding hassle factor' that many large companies, which was true for the early 'video chips'. Trying to get register definitions and 'data sheets' for these chips was like pulling teeth, and lead to a lot of reverse engineering. (While video does create RF noise... I don't think the companies making the video chips were really worried about someone programming the video chip 'wyrdly', to cause interference with neighbors down the block...).

Anyway, how these things are 'caught' usually involves a licensed broadcaster receiving indications that their broadcast is being interfered with, and reporting that. If you are in your steel reenforced concrete Faraday caged bunker, most likely no one will ever know...

Personally I'd rather the FCC worry about this sort of thing, and place staff on the certification programs, rather than chasing down 'foul language, or naughty images' on radio or TV... or extending that censorship to the Internet...

While we are discussion the US FCC... most countries have some entity that is similar, and depending more or less stringent.

John Clark.

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[Alex Hacker]

Hi,
If you able to add small piece of code to the driver, you can do the following:
Construct a single aggregate with desired parameters, NoAck bit set and 1 retry
count in the first retry series. Link last descriptor of the aggregate to the
first and drop this bomb into any TX queue. The aggregate should be in
accordance with the 802.11n, i.e. contain <64K of data+delimeters+FCS and be
4ms or shorter.
In case when no other signals in the medium this gives you 100% transmit time
except the small silence periods required by the standard.

But IMO, measuring TX power with a SA is not the best way. Using a much cheaper
power meter set up to measure on first 16us of each packet (preamble) is better.
It allows you to get a valid result with single packet shot.

About modulations used in 11n:
MCS			Modulation
0,8,16			BPSK
1,2,9,10,17,18		QPSK
3,4,11,12,19,20		QAM16
5,6,7,13,14,15,21,22,23	QAM64

52 subcarriers in 20MHz bandwidth and 108 in 40MHz.

Regards,
Alex.

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[John Clark]

On Mar 28, 2013, at 10:23 PM, Alex Hacker wrote:

> Hi,
> If you able to add small piece of code to the driver, you can do the following:
> Construct a single aggregate with desired parameters, NoAck bit set and 1 retry
> count in the first retry series. Link last descriptor of the aggregate to the
> first and drop this bomb into any TX queue. The aggregate should be in
> accordance with the 802.11n, i.e. contain <64K of data+delimeters+FCS and be
> 4ms or shorter.
> In case when no other signals in the medium this gives you 100% transmit time
> except the small silence periods required by the standard.
> 
> But IMO, measuring TX power with a SA is not the best way. Using a much cheaper
> power meter set up to measure on first 16us of each packet (preamble) is better.
> It allows you to get a valid result with single packet shot.
> 
> About modulations used in 11n:
> MCS			Modulation
> 0,8,16			BPSK
> 1,2,9,10,17,18		QPSK
> 3,4,11,12,19,20		QAM16
> 5,6,7,13,14,15,21,22,23	QAM64
> 
> 52 subcarriers in 20MHz bandwidth and 108 in 40MHz.


The Spectrum Analyzer setup is for people who need 8x10 glossy photos with circles and arrows and writin' on the back.

The continuous package setup sounds good for a field alignment setup, along with the cheaper power meter.

Thanks,
John Clark.

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[Adrian Chadd]

.. wait until I get back into the office next week and I'll see if I can
dig up the specific tone generation code for FCC certification.

Yeah, the irony here is:

* the FCC don't want users to be able to generate arbitrary tones; but
* boy do they want you to prove your radio is stable when you go for
certification.

It makes for some very interesting "what can be open sourced" issues.




Adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130329/3593fb66/attachment.htm 

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[Alex Hacker]

Hi Adrian,
You talking about real continuos signal like sine wave? I do not understand
why it needed. The method I'd offered is in full accordance with the 802.11
standard (and FCC I think) until CCA mechanism is not shut down. But I agree what
this kind of flood generator is terrible in the air.

Hi John,
I'd asked our RF engeneers who do FCC sertification tests. They agree - SA power
measurements are complex, slow and imprecise. But this methods is defined by FCC
specifications.

Best regards,
Alex.

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[Adrian Chadd]

On 30 March 2013 05:32, Alex Hacker <hacker@epn.ru> wrote:

> Hi Adrian,
> You talking about real continuos signal like sine wave? I do not understand
> why it needed. The method I'd offered is in full accordance with the 802.11
> standard (and FCC I think) until CCA mechanism is not shut down. But I
> agree what
> this kind of flood generator is terrible in the air.
>
>
Yup. Either is kinda frightening though! Even a back-to-back frame
transmission with CCA disabled is bordering on unhappiness.


> Hi John,
> I'd asked our RF engeneers who do FCC sertification tests. They agree - SA
> power
> measurements are complex, slow and imprecise. But this methods is defined
> by FCC
> specifications.
>

IIRC, there's ETSI requirements that tones are generated to test centre
frequency accuracies. I thought that the FCC had those too?


Adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130330/7a7d0710/attachment.htm 

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[Alex Hacker]

Hi Adrian,

On Sat, Mar 30, 2013 at 06:27:53AM -0700, Adrian Chadd wrote:
>    Yup. Either is kinda frightening though! Even a back-to-back frame
>    transmission with CCA disabled is bordering on unhappiness.

Yeah! Although it is all nothing compared to 1kW microwave oven or 500kW weather radar. :)

>    IIRC, there's ETSI requirements that tones are generated to test centre
>    frequency accuracies. I thought that the FCC had those too?

I think yes in some way. I ask the authoritative people at the morinig they did both
procedures.

>    Adrian

Best regards,
Alex.

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[Alex Hacker]

On Sat, Mar 30, 2013 at 09:03:24PM +0600, Alex Hacker wrote:
> I think yes in some way. I ask the authoritative people at the morinig they did both
> procedures.

Sorry, I wanted to say:
I ask the authoritative people at the monday. They breeze through both procedures.

Best regards,
Alex.

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[Alex Hacker]

On Sat, Mar 30, 2013 at 06:27:53AM -0700, Adrian Chadd wrote:
>    IIRC, there's ETSI requirements that tones are generated to test centre
>    frequency accuracies. I thought that the FCC had those too?
>    Adrian

I'd asked the RF boys. Nobody can recall exactly, they do it more than two
years ago, but they did it with MXA Signal Analyzer which measures frequency
error. They do not spent too much time on it beacuse if you have 5ppm quartz
generator then the precision of carrier frequencies is guaranteed by design.
Most problems in ETSI is out-of-band radiation pattern which it defines in
absolute values in contradistinction to FCC.

Regards,
Alex.

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[Adrian Chadd]

On 1 April 2013 01:14, Alex Hacker <hacker@epn.ru> wrote:

> I'd asked the RF boys. Nobody can recall exactly, they do it more than two
> years ago, but they did it with MXA Signal Analyzer which measures frequency
> error. They do not spent too much time on it beacuse if you have 5ppm quartz
> generator then the precision of carrier frequencies is guaranteed by design.
> Most problems in ETSI is out-of-band radiation pattern which it defines in
> absolute values in contradistinction to FCC.

Right.

I _think_ the tx continuous tone operation does transmit carriers of
various widths, up to 20/40mhz, with the TX spectral mask being met
(ie, it doesn't just blurt crap everywhere.)

I believe that's what is used when doing compliance testing.

Anyway, I'm back in the office in a couple days; I'll dig into this
further and try to come up with a plan moving forward.


Adrian

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[Felix Fietkau]

On 2013-03-27 7:49 PM, John Clark wrote:
> Many people seem to desire the bit rate to be the 'highest possible',
> and have that automagically set.
What's wrong with the current behavior of picking the rate that causes
the least wasted airtime?

> For some applications, I like to be able to set a specific bit rate,
> and have that bit rate used no matter the resulting errors.
That can be quite problematic with 802.11n aggregation. Any frame
transmission that has failed after too many retries causes a BlockAck
Request to be sent, which can cause other (potentially unrelated) frames
to be dropped on the receiver side.
Why do you want to do this at all?

> I have looked a the code briefly, and it seems that there is the
> possibility for setting up several retries, with changes in bit
> rate.
> 
> So, the questions are:
> 
> 1) how to 'fix' a rate, disable adjustments on retries, etc?
To do this per application, you'd have to put some ugly hacks into
various layers.

> 2) What is the relationship between the bit rate selected at this OS level,
> and the subcarrier modulation of the RF signal?
The standard describes what modulations are used for specific bitrates.

- Felix

[ath9k-devel] Fixing the rate and rate relationship to OFDM

[John Clark]

On Mar 28, 2013, at 12:00 PM, Felix Fietkau wrote:

> On 2013-03-27 7:49 PM, John Clark wrote:
>> Many people seem to desire the bit rate to be the 'highest possible',
>> and have that automagically set.
> What's wrong with the current behavior of picking the rate that causes
> the least wasted airtime?

What I'm looking for is a 'test mode' to determine channel power of the transmitter, based on observation of the signal via a spectrum analyzer.

But there is no public documentation on the Phy level controls, I'm trying to get an 'asymptotic' approximation for the time being.

John Clark.