[ath9k-devel] txpower control issues

[ath9k-devel] txpower control issues

[Daniel Halperin]

Hi,

I have an ar9380-based chip and am playing with power control. iw
reports a maximum tx power of 27 dBm.

When I run iwconfig wlan1 txpower [0-4] iwconfig reports a radiated
power value between 0 and 4 dBm, but the rate is very high.
When I run iwconfig wlan1 txpower 5, the rate drops 100 Mbps.

Am I using iwconfig incorrectly? Is power control for ath9k buggy? Is
there another CLI to control power that I should be using?

I am using latest wireless-testing and AP is on channel 124.

Thanks,
Dan

[ath9k-devel] txpower control issues

[Falk-Moritz Schaefer]

Try the following command "iw wlanX set txpower fixed Y", where Y=300 for a
low transmission power and Y=2000 for a high transmission power.
Please be aware, that different calibration values are read from eeprom for
different mcs, e.g. the highest transmit power for 54 Mbit/s is already
reached when using Y=1400. Anything higher will not have any effect on the
used power for 54 Mbit/s. This makes sense, because the higher the
transmission power the lower the SINR on the subcarriers depending on the RF
properties. High MCS require high SINR, so that the transmission power must
be reduced. Another influence might have the PAPR reduction algorithm
introduced in AR93xx, but I don't know if it is actually used in the current
driver.

Maybe someone can provide more detailed information about transmission power
control for AR93xx? I am very interested, too.

Regards,
Falk


 
> -----Original Message-----
> From: ath9k-devel-bounces at venema.h4ckr.net [mailto:ath9k-devel-
> bounces at venema.h4ckr.net] On Behalf Of Daniel Halperin
> Sent: Thursday, May 26, 2011 3:28 AM
> To: ath9k-devel at lists.ath9k.org
> Subject: [ath9k-devel] txpower control issues
> 
> Hi,
> 
> I have an ar9380-based chip and am playing with power control. iw reports
a
> maximum tx power of 27 dBm.
> 
> When I run iwconfig wlan1 txpower [0-4] iwconfig reports a radiated power
> value between 0 and 4 dBm, but the rate is very high.
> When I run iwconfig wlan1 txpower 5, the rate drops 100 Mbps.
> 
> Am I using iwconfig incorrectly? Is power control for ath9k buggy? Is
there
> another CLI to control power that I should be using?
> 
> I am using latest wireless-testing and AP is on channel 124.
> 
> Thanks,
> Dan
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] txpower control issues

[Mohammed Shafi]

On Thu, May 26, 2011 at 1:03 PM, Falk-Moritz Schaefer
<falk.schaefer@tu-dortmund.de> wrote:
> Try the following command "iw wlanX set txpower fixed Y", where Y=300 for a
> low transmission power and Y=2000 for a high transmission power.
> Please be aware, that different calibration values are read from eeprom for
> different mcs, e.g. the highest transmit power for 54 Mbit/s is already
> reached when using Y=1400. Anything higher will not have any effect on the
> used power for 54 Mbit/s. This makes sense, because the higher the
> transmission power the lower the SINR on the subcarriers depending on the RF
> properties. High MCS require high SINR, so that the transmission power must
> be reduced. Another influence might have the PAPR reduction algorithm
> introduced in AR93xx, but I don't know if it is actually used in the current
> driver.

PAPRD is currently disabled

>
> Maybe someone can provide more detailed information about transmission power
> control for AR93xx? I am very interested, too.
>
> Regards,
> Falk
>
>
>
>> -----Original Message-----
>> From: ath9k-devel-bounces at venema.h4ckr.net [mailto:ath9k-devel-
>> bounces at venema.h4ckr.net] On Behalf Of Daniel Halperin
>> Sent: Thursday, May 26, 2011 3:28 AM
>> To: ath9k-devel at lists.ath9k.org
>> Subject: [ath9k-devel] txpower control issues
>>
>> Hi,
>>
>> I have an ar9380-based chip and am playing with power control. iw reports
> a
>> maximum tx power of 27 dBm.
>>
>> When I run iwconfig wlan1 txpower [0-4] iwconfig reports a radiated power
>> value between 0 and 4 dBm, but the rate is very high.
>> When I run iwconfig wlan1 txpower 5, the rate drops 100 Mbps.
>>
>> Am I using iwconfig incorrectly? Is power control for ath9k buggy? Is
> there
>> another CLI to control power that I should be using?
>>
>> I am using latest wireless-testing and AP is on channel 124.
>>
>> Thanks,
>> Dan
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] txpower control issues

[Adrian Chadd]

Hm, check the per-rate TX power control registers at each setting and
see what's being written into them?

Maybe there's rounding / underflow issues?


Adrian

On 26 May 2011 09:28, Daniel Halperin <dhalperi@cs.washington.edu> wrote:
> Hi,
>
> I have an ar9380-based chip and am playing with power control. iw
> reports a maximum tx power of 27 dBm.
>
> When I run iwconfig wlan1 txpower [0-4] iwconfig reports a radiated
> power value between 0 and 4 dBm, but the rate is very high.
> When I run iwconfig wlan1 txpower 5, the rate drops 100 Mbps.
>
> Am I using iwconfig incorrectly? Is power control for ath9k buggy? Is
> there another CLI to control power that I should be using?
>
> I am using latest wireless-testing and AP is on channel 124.
>
> Thanks,
> Dan
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] txpower control issues

[Adrian Chadd]

Since Daniel asked about how TX power is configured, I thought I'd
brain-dump the next few minutes of me going spelunking through the
AR9300 TX power code.

The ath9k driver arch has the TX power and calibration configured as
an "eeprom op". The reason behind it is because the specifics of TX
calibration relied on the EEPROM layout as well as the chip
version/revision.

The place to start is ar9300_eeprom.c . Take a look at the bottom of
the source file -

const struct eeprom_ops eep_ar9300_ops = {
...
        .set_txpower = ath9k_hw_ar9300_set_txpower,
...
}

The key is ath9k_hw_ar9300_set_txpower(). It calls a few things.

ar9003_hw_set_target_power_eeprom() fetches the target power for each TX rate.

ar9003_hw_set_power_per_rate_table(). That extracts out the maximum TX
power for each TX rate, given the channel/operating mode.

There's PAPRD stuff in there for TX power calibration; I haven't looked in that.

Then set_txpower() does this:

        for (i = 0; i < ar9300RateSize; i++) {
                ath_dbg(common, ATH_DBG_EEPROM,
                        "TPC[%02d] 0x%08x\n", i, targetPowerValT2[i]);
        }


So you could enable ATH_DBG_EEPROM to see what the per-rate TX power is:

../ath.h:	ATH_DBG_EEPROM		= 0x00000004,

Finally, it's written to the hardware via a call to
ar9003_hw_tx_power_regwrite().

So I'd begin by comparing what the per-rate TX power levels are as you
configure different target powers, and see if they're varying by more
than what you're configuring. There have been bugs before where low TX
power rates would "underflow" and cause an overly-large value to be
written.

Good luck, and I hope you find it's a relatively obvious bug to fix.
Don't be afraid to nag people with questions. I'm happy to go digging
through the AR9300 code but I warn you, I have no experience with the
9300-series NICs and I'm busy with university stuff until the end of
June so I may not be terribly helpful.


Adrian

[ath9k-devel] txpower control issues

[Mohammed Shafi]

On Thu, May 26, 2011 at 9:06 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> Since Daniel asked about how TX power is configured, I thought I'd
> brain-dump the next few minutes of me going spelunking through the
> AR9300 TX power code.
>
> The ath9k driver arch has the TX power and calibration configured as
> an "eeprom op". The reason behind it is because the specifics of TX
> calibration relied on the EEPROM layout as well as the chip
> version/revision.
>
> The place to start is ar9300_eeprom.c . Take a look at the bottom of
> the source file -
>
> const struct eeprom_ops eep_ar9300_ops = {
> ...
> ? ? ? ?.set_txpower = ath9k_hw_ar9300_set_txpower,
> ...
> }
>
> The key is ath9k_hw_ar9300_set_txpower(). It calls a few things.
>
> ar9003_hw_set_target_power_eeprom() fetches the target power for each TX rate.
>
> ar9003_hw_set_power_per_rate_table(). That extracts out the maximum TX
> power for each TX rate, given the channel/operating mode.
>
> There's PAPRD stuff in there for TX power calibration; I haven't looked in that.
>
> Then set_txpower() does this:
>
> ? ? ? ?for (i = 0; i < ar9300RateSize; i++) {
> ? ? ? ? ? ? ? ?ath_dbg(common, ATH_DBG_EEPROM,
> ? ? ? ? ? ? ? ? ? ? ? ?"TPC[%02d] 0x%08x\n", i, targetPowerValT2[i]);
> ? ? ? ?}
>

there is some issue for HT40 rates the tx power seems to be 0
irrespective of PAPRD enabled/disabled, may be I can try with Dan's
patch

>
> So you could enable ATH_DBG_EEPROM to see what the per-rate TX power is:
>
> ../ath.h: ? ? ? ATH_DBG_EEPROM ? ? ? ? ?= 0x00000004,

May 27 11:18:22 shafi-laptop kernel: [  573.523194] ath: paprd
disabled for mcs 23
May 27 11:18:22 shafi-laptop kernel: [  573.523197] ath: TPC[00] 0x00000022
May 27 11:18:22 shafi-laptop kernel: [  573.523199] ath: TPC[01] 0x00000022
May 27 11:18:22 shafi-laptop kernel: [  573.523201] ath: TPC[02] 0x00000020
May 27 11:18:22 shafi-laptop kernel: [  573.523203] ath: TPC[03] 0x00000020
May 27 11:18:22 shafi-laptop kernel: [  573.523206] ath: TPC[04] 0x00000022
May 27 11:18:22 shafi-laptop kernel: [  573.523208] ath: TPC[05] 0x00000022
May 27 11:18:22 shafi-laptop kernel: [  573.523210] ath: TPC[06] 0x00000022
May 27 11:18:22 shafi-laptop kernel: [  573.523212] ath: TPC[07] 0x00000022
May 27 11:18:22 shafi-laptop kernel: [  573.523215] ath: TPC[08] 0x00000020
May 27 11:18:22 shafi-laptop kernel: [  573.523217] ath: TPC[09] 0x00000020
May 27 11:18:22 shafi-laptop kernel: [  573.523219] ath: TPC[10] 0x00000020
May 27 11:18:22 shafi-laptop kernel: [  573.523221] ath: TPC[11] 0x00000020
May 27 11:18:22 shafi-laptop kernel: [  573.523224] ath: TPC[12] 0x00000020
May 27 11:18:22 shafi-laptop kernel: [  573.523226] ath: TPC[13] 0x0000001e
May 27 11:18:22 shafi-laptop kernel: [  573.523228] ath: TPC[14] 0x00000020
May 27 11:18:22 shafi-laptop kernel: [  573.523231] ath: TPC[15] 0x00000020
May 27 11:18:22 shafi-laptop kernel: [  573.523233] ath: TPC[16] 0x0000001e
May 27 11:18:22 shafi-laptop kernel: [  573.523235] ath: TPC[17] 0x0000001c
May 27 11:18:22 shafi-laptop kernel: [  573.523238] ath: TPC[18] 0x00000000
May 27 11:18:22 shafi-laptop kernel: [  573.523240] ath: TPC[19] 0x00000000
May 27 11:18:22 shafi-laptop kernel: [  573.523242] ath: TPC[20] 0x00000000
May 27 11:18:22 shafi-laptop kernel: [  573.523244] ath: TPC[21] 0x00000000
May 27 11:18:22 shafi-laptop kernel: [  573.523247] ath: TPC[22] 0x00000000
May 27 11:18:22 shafi-laptop kernel: [  573.523249] ath: TPC[23] 0x00000000
May 27 11:18:22 shafi-laptop kernel: [  573.523251] ath: TPC[24] 0x00000000
May 27 11:18:22 shafi-laptop kernel: [  573.523254] ath: TPC[25] 0x00000000
May 27 11:18:22 shafi-laptop kernel: [  573.523256] ath: TPC[26] 0x00000000
May 27 11:18:22 shafi-laptop kernel: [  573.523258] ath: TPC[27] 0x00000000
May 27 11:18:22 shafi-laptop kernel: [  573.523260] ath: TPC[28] 0x00000000
May 27 11:18:22 shafi-laptop kernel: [  573.523263] ath: TPC[29] 0x00000000
May 27 11:18:22 shafi-laptop kernel: [  573.523265] ath: TPC[30] 0x00000000
May 27 11:18:22 shafi-laptop kernel: [  573.523267] ath: TPC[31] 0x00000000
May 27 11:18:22 shafi-laptop kernel: [  573.523269] ath: TPC[32] 0x00000000
May 27 11:18:22 shafi-laptop kernel: [  573.523272] ath: TPC[33] 0x00000000
May 27 11:18:22 shafi-laptop kernel: [  573.523274] ath: TPC[34] 0x00000000
May 27 11:18:22 shafi-laptop kernel: [  573.523276] ath: TPC[35] 0x00000000





>
> Finally, it's written to the hardware via a call to
> ar9003_hw_tx_power_regwrite().
>
> So I'd begin by comparing what the per-rate TX power levels are as you
> configure different target powers, and see if they're varying by more
> than what you're configuring. There have been bugs before where low TX
> power rates would "underflow" and cause an overly-large value to be
> written.
>
> Good luck, and I hope you find it's a relatively obvious bug to fix.
> Don't be afraid to nag people with questions. I'm happy to go digging
> through the AR9300 code but I warn you, I have no experience with the
> 9300-series NICs and I'm busy with university stuff until the end of
> June so I may not be terribly helpful.
>
>
> Adrian
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] txpower control issues

[Mohammed Shafi]

On Fri, May 27, 2011 at 11:20 AM, Mohammed Shafi <shafi.ath9k@gmail.com> wrote:
> On Thu, May 26, 2011 at 9:06 PM, Adrian Chadd <adrian@freebsd.org> wrote:
>> Since Daniel asked about how TX power is configured, I thought I'd
>> brain-dump the next few minutes of me going spelunking through the
>> AR9300 TX power code.
>>
>> The ath9k driver arch has the TX power and calibration configured as
>> an "eeprom op". The reason behind it is because the specifics of TX
>> calibration relied on the EEPROM layout as well as the chip
>> version/revision.
>>
>> The place to start is ar9300_eeprom.c . Take a look at the bottom of
>> the source file -
>>
>> const struct eeprom_ops eep_ar9300_ops = {
>> ...
>> ? ? ? ?.set_txpower = ath9k_hw_ar9300_set_txpower,
>> ...
>> }
>>
>> The key is ath9k_hw_ar9300_set_txpower(). It calls a few things.
>>
>> ar9003_hw_set_target_power_eeprom() fetches the target power for each TX rate.
>>
>> ar9003_hw_set_power_per_rate_table(). That extracts out the maximum TX
>> power for each TX rate, given the channel/operating mode.
>>
>> There's PAPRD stuff in there for TX power calibration; I haven't looked in that.
>>
>> Then set_txpower() does this:
>>
>> ? ? ? ?for (i = 0; i < ar9300RateSize; i++) {
>> ? ? ? ? ? ? ? ?ath_dbg(common, ATH_DBG_EEPROM,
>> ? ? ? ? ? ? ? ? ? ? ? ?"TPC[%02d] 0x%08x\n", i, targetPowerValT2[i]);
>> ? ? ? ?}
>>
>
> there is some issue for HT40 rates the tx power seems to be 0
> irrespective of PAPRD enabled/disabled, may be I can try with Dan's
> patch
>
>>
>> So you could enable ATH_DBG_EEPROM to see what the per-rate TX power is:
>>
>> ../ath.h: ? ? ? ATH_DBG_EEPROM ? ? ? ? ?= 0x00000004,
>
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523194] ath: paprd
> disabled for mcs 23
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523197] ath: TPC[00] 0x00000022
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523199] ath: TPC[01] 0x00000022
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523201] ath: TPC[02] 0x00000020
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523203] ath: TPC[03] 0x00000020
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523206] ath: TPC[04] 0x00000022
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523208] ath: TPC[05] 0x00000022
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523210] ath: TPC[06] 0x00000022
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523212] ath: TPC[07] 0x00000022
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523215] ath: TPC[08] 0x00000020
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523217] ath: TPC[09] 0x00000020
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523219] ath: TPC[10] 0x00000020
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523221] ath: TPC[11] 0x00000020
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523224] ath: TPC[12] 0x00000020
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523226] ath: TPC[13] 0x0000001e
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523228] ath: TPC[14] 0x00000020
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523231] ath: TPC[15] 0x00000020
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523233] ath: TPC[16] 0x0000001e
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523235] ath: TPC[17] 0x0000001c
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523238] ath: TPC[18] 0x00000000
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523240] ath: TPC[19] 0x00000000
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523242] ath: TPC[20] 0x00000000
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523244] ath: TPC[21] 0x00000000
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523247] ath: TPC[22] 0x00000000
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523249] ath: TPC[23] 0x00000000
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523251] ath: TPC[24] 0x00000000
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523254] ath: TPC[25] 0x00000000
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523256] ath: TPC[26] 0x00000000
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523258] ath: TPC[27] 0x00000000
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523260] ath: TPC[28] 0x00000000
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523263] ath: TPC[29] 0x00000000
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523265] ath: TPC[30] 0x00000000
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523267] ath: TPC[31] 0x00000000
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523269] ath: TPC[32] 0x00000000
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523272] ath: TPC[33] 0x00000000
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523274] ath: TPC[34] 0x00000000
> May 27 11:18:22 shafi-laptop kernel: [ ?573.523276] ath: TPC[35] 0x00000000
>
>
>
true this function is the culprit
  ar9003_hw_set_power_per_rate_table(ah, chan,
                                           targetPowerValT2, cfgCtl,
                                           twiceAntennaReduction,
                                           twiceMaxRegulatoryPower,
                                           powerLimit);




>
>>
>> Finally, it's written to the hardware via a call to
>> ar9003_hw_tx_power_regwrite().
>>
>> So I'd begin by comparing what the per-rate TX power levels are as you
>> configure different target powers, and see if they're varying by more
>> than what you're configuring. There have been bugs before where low TX
>> power rates would "underflow" and cause an overly-large value to be
>> written.
>>
>> Good luck, and I hope you find it's a relatively obvious bug to fix.
>> Don't be afraid to nag people with questions. I'm happy to go digging
>> through the AR9300 code but I warn you, I have no experience with the
>> 9300-series NICs and I'm busy with university stuff until the end of
>> June so I may not be terribly helpful.
>>
>>
>> Adrian
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>

[ath9k-devel] txpower control issues

[Mohammed Shafi]

On Thu, May 26, 2011 at 9:06 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> Since Daniel asked about how TX power is configured, I thought I'd
> brain-dump the next few minutes of me going spelunking through the
> AR9300 TX power code.
>
> The ath9k driver arch has the TX power and calibration configured as
> an "eeprom op". The reason behind it is because the specifics of TX
> calibration relied on the EEPROM layout as well as the chip
> version/revision.
>
> The place to start is ar9300_eeprom.c . Take a look at the bottom of
> the source file -
>
> const struct eeprom_ops eep_ar9300_ops = {
> ...
> ? ? ? ?.set_txpower = ath9k_hw_ar9300_set_txpower,
> ...
> }
>
> The key is ath9k_hw_ar9300_set_txpower(). It calls a few things.
>
> ar9003_hw_set_target_power_eeprom() fetches the target power for each TX rate.
>
> ar9003_hw_set_power_per_rate_table(). That extracts out the maximum TX
> power for each TX rate, given the channel/operating mode.
>
> There's PAPRD stuff in there for TX power calibration; I haven't looked in that.

true PAPRD stuff is still handled for power control
  if (ah->eep_ops->get_eeprom(ah, EEP_PAPRD)) {
return true in ar9003_eeprom.c


>
> Then set_txpower() does this:
>
> ? ? ? ?for (i = 0; i < ar9300RateSize; i++) {
> ? ? ? ? ? ? ? ?ath_dbg(common, ATH_DBG_EEPROM,
> ? ? ? ? ? ? ? ? ? ? ? ?"TPC[%02d] 0x%08x\n", i, targetPowerValT2[i]);
> ? ? ? ?}
>
>
> So you could enable ATH_DBG_EEPROM to see what the per-rate TX power is:
>
> ../ath.h: ? ? ? ATH_DBG_EEPROM ? ? ? ? ?= 0x00000004,
>
> Finally, it's written to the hardware via a call to
> ar9003_hw_tx_power_regwrite().
>
> So I'd begin by comparing what the per-rate TX power levels are as you
> configure different target powers, and see if they're varying by more
> than what you're configuring. There have been bugs before where low TX
> power rates would "underflow" and cause an overly-large value to be
> written.
>
> Good luck, and I hope you find it's a relatively obvious bug to fix.
> Don't be afraid to nag people with questions. I'm happy to go digging
> through the AR9300 code but I warn you, I have no experience with the
> 9300-series NICs and I'm busy with university stuff until the end of
> June so I may not be terribly helpful.
>
>
> Adrian
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] Features for FCC test and etc

[Jun Xiao]

Hi,

With all your great efforts developing the driver, our products with
AR9271 is on the way of FCC certification tests. Some features are
required:

1. Be able to turn on WiFi transmission constantly
2. Be able to transmit at its maximum power
3. Be able to modify its MAC address

Do we have these features in ath9k-htc driver and what is the handler
from user space? If not, are they under development?

Thanks in advance.

Jun Xiao

Sixnet | www.sixnet.com

O +1 514 422 9110 Ext. 482                   

F +1 514 422 3338

junx at sixnet.com

[ath9k-devel] Features for FCC test and etc

[Mohammed Shafi]

On Mon, Sep 12, 2011 at 7:08 PM, Jun Xiao <Jun.Xiao@sixnet.com> wrote:
> Hi,
>
> With all your great efforts developing the driver, our products with
> AR9271 is on the way of FCC certification tests. Some features are
> required:
>
> 1. Be able to turn on WiFi transmission constantly

rfkill?

> 2. Be able to transmit at its maximum power

dev <devname> set txpower <auto|fixed|limit> [<tx power in mBm>]
the power set to the hardware will be controlled by regulatory power.

> 3. Be able to modify its MAC address

you can use macchanger application. supported by mac80211

>
> Do we have these features in ath9k-htc driver and what is the handler
> from user space? If not, are they under development?
>
> Thanks in advance.
>
> Jun Xiao
>
> Sixnet | www.sixnet.com
>
> O +1 514 422 9110 Ext. 482
>
> F +1 514 422 3338
>
> junx at sixnet.com
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>



-- 
shafi

[ath9k-devel] Features for FCC test and etc

[Mohammed Shafi]

On Mon, Sep 12, 2011 at 9:01 PM, Mohammed Shafi
<shafi.wireless@gmail.com> wrote:
> On Mon, Sep 12, 2011 at 7:08 PM, Jun Xiao <Jun.Xiao@sixnet.com> wrote:
>> Hi,
>>
>> With all your great efforts developing the driver, our products with
>> AR9271 is on the way of FCC certification tests. Some features are
>> required:
>>
>> 1. Be able to turn on WiFi transmission constantly
>
> rfkill?
>
>> 2. Be able to transmit at its maximum power
>
> dev <devname> set txpower <auto|fixed|limit> [<tx power in mBm>]
> the power set to the hardware will be controlled by regulatory power.

sorry the command is
iw dev <devname> set txpower <auto|fixed|limit> [<tx power in mBm>]
http://linuxwireless.org/en/users/Documentation/iw

>
>> 3. Be able to modify its MAC address
>
> you can use macchanger application. supported by mac80211
>
>>
>> Do we have these features in ath9k-htc driver and what is the handler
>> from user space? If not, are they under development?
>>
>> Thanks in advance.
>>
>> Jun Xiao
>>
>> Sixnet | www.sixnet.com
>>
>> O +1 514 422 9110 Ext. 482
>>
>> F +1 514 422 3338
>>
>> junx at sixnet.com
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>
>
>
> --
> shafi
>



-- 
shafi

[ath9k-devel] Features for FCC test and etc

[Jun Xiao]

Hi Mohammed,

Thanks for your quick reply. 
I think rfkill is for regularly enabling/disabling wireless devices.
However FCC asks to let the device transmit RF signal constantly during
tests(instead of pulsing its SSID periodically as an AP). This is only
for test purpose, nothing even related to wifi protocol.
I am not sure if the driver supports this operation :(

Jun Xiao

Firmware Engineer

Sixnet | www.sixnet.com

O +1 514 422 9110 Ext. 482                   

F +1 514 422 3338

junx at sixnet.com

-----Original Message-----
From: Mohammed Shafi [mailto:shafi.wireless at gmail.com] 
Sent: Monday, September 12, 2011 11:39 AM
To: Jun Xiao
Cc: ath9k-devel at lists.ath9k.org
Subject: Re: [ath9k-devel] Features for FCC test and etc

On Mon, Sep 12, 2011 at 9:01 PM, Mohammed Shafi
<shafi.wireless@gmail.com> wrote:
> On Mon, Sep 12, 2011 at 7:08 PM, Jun Xiao <Jun.Xiao@sixnet.com> wrote:
>> Hi,
>>
>> With all your great efforts developing the driver, our products with
>> AR9271 is on the way of FCC certification tests. Some features are
>> required:
>>
>> 1. Be able to turn on WiFi transmission constantly
>
> rfkill?
>
>> 2. Be able to transmit at its maximum power
>
> dev <devname> set txpower <auto|fixed|limit> [<tx power in mBm>]
> the power set to the hardware will be controlled by regulatory power.

sorry the command is
iw dev <devname> set txpower <auto|fixed|limit> [<tx power in mBm>]
http://linuxwireless.org/en/users/Documentation/iw

>
>> 3. Be able to modify its MAC address
>
> you can use macchanger application. supported by mac80211
>
>>
>> Do we have these features in ath9k-htc driver and what is the handler
>> from user space? If not, are they under development?
>>
>> Thanks in advance.
>>
>> Jun Xiao
>>
>> Sixnet | www.sixnet.com
>>
>> O +1 514 422 9110 Ext. 482
>>
>> F +1 514 422 3338
>>
>> junx at sixnet.com
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>
>
>
> --
> shafi
>



-- 
shafi

[ath9k-devel] Features for FCC test and etc

[Pavel Roskin]

On Mon, 12 Sep 2011 13:59:17 -0400
"Jun Xiao" <Jun.Xiao@sixnet.com> wrote:

> Hi Mohammed,
> 
> Thanks for your quick reply. 
> I think rfkill is for regularly enabling/disabling wireless devices.
> However FCC asks to let the device transmit RF signal constantly
> during tests(instead of pulsing its SSID periodically as an AP). This
> is only for test purpose, nothing even related to wifi protocol.
> I am not sure if the driver supports this operation :(

It was asked before:
http://www.mail-archive.com/ath9k-devel at lists.ath9k.org/msg05313.html

-- 
Regards,
Pavel Roskin