[ath9k-devel] Is setting txpower in master mode on ath9k supposed to work?

[ath9k-devel] Is setting txpower in master mode on ath9k supposed to work?

[Blaise Gassend]

Is setting txpower in master mode supposed to work on ath9k?

I have been adjusting the txpower on an ath9k radio set as master
mode, and monitoring RSSI on another radio. The results I am getting
seem very inconsistent. Sometimes RSSI decreases when txpower
incresase. Sometimes I can't get any change at all. Sometimes things
are sane over part of the power range, and constant elsewhere. I see
that there seem to be some table lookups involved in setting txpower.
Do some vendors fill those tables with garbage?

I still need to take the time to take some good data on this and
debug, but thought I'd inquire if anybody happens to know off hand.

Thanks,
Blaise

[ath9k-devel] Is setting txpower in master mode on ath9k supposed to work?

[Mohammed Shafi]

On Thu, Nov 25, 2010 at 10:03 AM, Blaise Gassend
<blaise@willowgarage.com> wrote:
> Is setting txpower in master mode supposed to work on ath9k?
>
Yes it should be.How are we setting the tx-power using the command ?
> I have been adjusting the txpower on an ath9k radio set as master
> mode, and monitoring RSSI on another radio. The results I am getting
> seem very inconsistent. Sometimes RSSI decreases when txpower
> incresase. Sometimes I can't get any change at all. Sometimes things
> are sane over part of the power range, and constant elsewhere. I see
> that there seem to be some table lookups involved in setting txpower.
> Do some vendors fill those tables with garbage?
>
Can you please point out where your refering to that table? There is
also a tx-power (20 I think).
> I still need to take the time to take some good data on this and
> debug, but thought I'd inquire if anybody happens to know off hand.
>
> Thanks,
> Blaise
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] Is setting txpower in master mode on ath9k supposed to work?

[Blaise Gassend]

I have made a bit of progress on my problems with setting txpower in
master mode on ath9k. It turns out that setting txpower does work, but
that the settings that get sent to the adapter for a given requested
txpower are wrong. If anybody knows the details of how
ath9k_hw_set_def_power_per_rate_table works it might be obvious what
is going wrong here.

I have tested with two different adapters. In both cases, low values
of txpower seem to max out the transmit power. As you increase
txpower, nothing happens initially. Then the observed power steps
down, and thereafter increases nicely as one would expect (though some
boards seem to better calibrated and more consistent than others). See
APPENDIX A for the raw data. This problem is troublesome, as it could
cause regulatory limits to be exceeded, since setting a low txpower
will actually cause a much higher txpower to be set on the adapter.

Digging through the code a bit, it appears that
ath9k_hw_def_set_txpower in eeprom_def.c is correctly receiving the
requested txpower (or rather twice the requested txpower). However,
the values it gets from ath9k_hw_set_def_power_per_rate_table appear
to have are non-monotonic, and match the txpower I have been
observing. APPENDIX B shows the ratesArray values as a function of
powerLimit.

Any tips would be appreciated,
Blaise

APPENDIX A: Received power as a function of txpower.
(First column is txpower requested using iwconfig, second column is
RSSI as seen by tcpdump on a monitor interface on another computer.

Adapter 1
0 -57.5
1 -57.6
2 -57.0
3 -70.95
4 -71.45
5 -69.55
6 -71.4
7 -68.25
8 -67.5
9 -66.1
10 -67.4
11 -65.45
12 -63.15
13 -61.7
14 -60.35
15 -58.6
16 -59.6
17 -56.55
18 -57.55
19 -56.35
20 -58.5217391304

Adapter 2
0 -54.6
1 -55.2
2 -55.0
3 -55.2
4 -55.2
5 -68.2
6 -68.2
7 -66.2
8 -66.4
9 -65.0
10 -64.4
11 -63.6
12 -62.6
13 -61.6
14 -60.2
15 -58.4
16 -58.4
17 -57.2

APPENDIX B: ratesArray as a function of powerLimit

(First number before colon is powerLimit, remaining numbers are
entries in ratesArray.)

Adapter 1
0: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32
32 30 10 10 10 10 10 10 10 10 10 10 10 10
2: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32
32 30 10 10 10 10 10 10 10 10 10 10 10 10
4: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32
32 30 10 10 10 10 10 10 10 10 10 10 10 10
6: 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
10 10 10 10 10 10 10 10 10 10 10 10 10 10
8: 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12
12 12 10 10 10 10 10 10 10 10 10 10 10 10
10: 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14
14 14 10 10 10 10 10 10 10 10 10 10 10 10
12: 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16
16 16 10 10 10 10 10 10 10 10 10 10 10 10
14: 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18
18 18 10 10 10 10 10 10 10 10 10 10 10 10
16: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 10 10 10 10 10 10 10 10 10 10 10 10
18: 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22
22 22 10 10 10 10 10 10 10 10 10 10 10 10
20: 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24
24 24 10 10 10 10 10 10 10 10 10 10 10 10
22: 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26
26 26 10 10 10 10 10 10 10 10 10 10 10 10
24: 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28
28 28 10 10 10 10 10 10 10 10 10 10 10 10
26: 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
30 30 10 10 10 10 10 10 10 10 10 10 10 10
28: 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32
32 30 10 10 10 10 10 10 10 10 10 10 10 10
30: 32 32 32 32 32 32 32 32 34 34 34 34 34 34 34 32 32 32 32 32 32 32
32 30 10 10 10 10 10 10 10 10 10 10 10 10
32: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32
32 30 10 10 10 10 10 10 10 10 10 10 10 10
34: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32
32 30 10 10 10 10 10 10 10 10 10 10 10 10
36: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32
32 30 10 10 10 10 10 10 10 10 10 10 10 10
38: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32
32 30 10 10 10 10 10 10 10 10 10 10 10 10
40: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32
32 30 10 10 10 10 10 10 10 10 10 10 10 10

Adapter 2
0: 30 30 30 30 30 30 30 26 0 0 0 0 0 0 0 30 30 30 30 30 30 30 30 26 0
0 0 0 0 0 0 0 0 0 0 0
2: 30 30 30 30 30 30 30 26 0 0 0 0 0 0 0 30 30 30 30 30 30 30 30 26 0
0 0 0 0 0 0 0 0 0 0 0
4: 30 30 30 30 30 30 30 26 0 0 0 0 0 0 0 30 30 30 30 30 30 30 30 26 0
0 0 0 0 0 0 0 0 0 0 0
6: 30 30 30 30 30 30 30 26 0 0 0 0 0 0 0 30 30 30 30 30 30 30 30 26 0
0 0 0 0 0 0 0 0 0 0 0
8: 30 30 30 30 30 30 30 26 0 0 0 0 0 0 0 30 30 30 30 30 30 30 30 26 0
0 0 0 0 0 0 0 0 0 0 0
10: 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0
12: 3 3 3 3 3 3 3 3 0 0 0 0 0 0 0 3 3 3 3 3 3 3 3 3 0 0 0 0 0 0 0 0 0 0 0 0
14: 5 5 5 5 5 5 5 5 0 0 0 0 0 0 0 5 5 5 5 5 5 5 5 5 0 0 0 0 0 0 0 0 0 0 0 0
16: 7 7 7 7 7 7 7 7 0 0 0 0 0 0 0 7 7 7 7 7 7 7 7 7 0 0 0 0 0 0 0 0 0 0 0 0
18: 9 9 9 9 9 9 9 9 0 0 0 0 0 0 0 9 9 9 9 9 9 9 9 9 0 0 0 0 0 0 0 0 0 0 0 0
20: 11 11 11 11 11 11 11 11 0 0 0 0 0 0 0 11 11 11 11 11 11 11 11 11 0
0 0 0 0 0 0 0 0 0 0 0
22: 13 13 13 13 13 13 13 13 0 0 0 0 0 0 0 13 13 13 13 13 13 13 13 13 0
0 0 0 0 0 0 0 0 0 0 0
24: 15 15 15 15 15 15 15 15 0 0 0 0 0 0 0 15 15 15 15 15 15 15 15 15 0
0 0 0 0 0 0 0 0 0 0 0
26: 17 17 17 17 17 17 17 17 0 0 0 0 0 0 0 17 17 17 17 17 17 17 17 17 0
0 0 0 0 0 0 0 0 0 0 0
28: 19 19 19 19 19 19 19 19 0 0 0 0 0 0 0 19 19 19 19 19 19 19 19 19 0
0 0 0 0 0 0 0 0 0 0 0
30: 21 21 21 21 21 21 21 21 0 0 0 0 0 0 0 21 21 21 21 21 21 21 21 21 0
0 0 0 0 0 0 0 0 0 0 0
32: 23 23 23 23 23 23 23 23 0 0 0 0 0 0 0 23 23 23 23 23 23 23 23 23 0
0 0 0 0 0 0 0 0 0 0 0
34: 25 25 25 25 25 25 25 25 0 0 0 0 0 0 0 25 25 25 25 25 25 25 25 25 0
0 0 0 0 0 0 0 0 0 0 0

On Wed, Nov 24, 2010 at 8:33 PM, Blaise Gassend <blaise@willowgarage.com> wrote:
> Is setting txpower in master mode supposed to work on ath9k?
>
> I have been adjusting the txpower on an ath9k radio set as master
> mode, and monitoring RSSI on another radio. The results I am getting
> seem very inconsistent. Sometimes RSSI decreases when txpower
> incresase. Sometimes I can't get any change at all. Sometimes things
> are sane over part of the power range, and constant elsewhere. I see
> that there seem to be some table lookups involved in setting txpower.
> Do some vendors fill those tables with garbage?
>
> I still need to take the time to take some good data on this and
> debug, but thought I'd inquire if anybody happens to know off hand.
>
> Thanks,
> Blaise
>

[ath9k-devel] Is setting txpower in master mode on ath9k supposed to work?

[Brian Prodoehl]

On Mon, Dec 6, 2010 at 8:05 PM, Blaise Gassend <blaise@willowgarage.com> wrote:
> I have made a bit of progress on my problems with setting txpower in
> master mode on ath9k. It turns out that setting txpower does work, but
> that the settings that get sent to the adapter for a given requested
> txpower are wrong. If anybody knows the details of how
> ath9k_hw_set_def_power_per_rate_table works it might be obvious what
> is going wrong here.
>
> I have tested with two different adapters. In both cases, low values
> of txpower seem to max out the transmit power. As you increase
> txpower, nothing happens initially. Then the observed power steps
> down, and thereafter increases nicely as one would expect (though some
> boards seem to better calibrated and more consistent than others). See
> APPENDIX A for the raw data. This problem is troublesome, as it could
> cause regulatory limits to be exceeded, since setting a low txpower
> will actually cause a much higher txpower to be set on the adapter.
>
> Digging through the code a bit, it appears that
> ath9k_hw_def_set_txpower in eeprom_def.c is correctly receiving the
> requested txpower (or rather twice the requested txpower). However,
> the values it gets from ath9k_hw_set_def_power_per_rate_table appear
> to have are non-monotonic, and match the txpower I have been
> observing. APPENDIX B shows the ratesArray values as a function of
> powerLimit.
>
> Any tips would be appreciated,
> Blaise
>
> APPENDIX A: Received power as a function of txpower.
> (First column is txpower requested using iwconfig, second column is
> RSSI as seen by tcpdump on a monitor interface on another computer.
>
> Adapter 1
> 0 -57.5
> 1 -57.6
> 2 -57.0
> 3 -70.95
> 4 -71.45
> 5 -69.55
> 6 -71.4
> 7 -68.25
> 8 -67.5
> 9 -66.1
> 10 -67.4
> 11 -65.45
> 12 -63.15
> 13 -61.7
> 14 -60.35
> 15 -58.6
> 16 -59.6
> 17 -56.55
> 18 -57.55
> 19 -56.35
> 20 -58.5217391304
>
> Adapter 2
> 0 -54.6
> 1 -55.2
> 2 -55.0
> 3 -55.2
> 4 -55.2
> 5 -68.2
> 6 -68.2
> 7 -66.2
> 8 -66.4
> 9 -65.0
> 10 -64.4
> 11 -63.6
> 12 -62.6
> 13 -61.6
> 14 -60.2
> 15 -58.4
> 16 -58.4
> 17 -57.2
>
> APPENDIX B: ratesArray as a function of powerLimit
>
> (First number before colon is powerLimit, remaining numbers are
> entries in ratesArray.)
>
> Adapter 1
> 0: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32
> 32 30 10 10 10 10 10 10 10 10 10 10 10 10
> 2: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32
> 32 30 10 10 10 10 10 10 10 10 10 10 10 10
> 4: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32
> 32 30 10 10 10 10 10 10 10 10 10 10 10 10
> 6: 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
> 10 10 10 10 10 10 10 10 10 10 10 10 10 10
> 8: 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12
> 12 12 10 10 10 10 10 10 10 10 10 10 10 10
> 10: 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14
> 14 14 10 10 10 10 10 10 10 10 10 10 10 10
> 12: 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16
> 16 16 10 10 10 10 10 10 10 10 10 10 10 10
> 14: 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18
> 18 18 10 10 10 10 10 10 10 10 10 10 10 10
> 16: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
> 20 20 10 10 10 10 10 10 10 10 10 10 10 10
> 18: 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22
> 22 22 10 10 10 10 10 10 10 10 10 10 10 10
> 20: 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24
> 24 24 10 10 10 10 10 10 10 10 10 10 10 10
> 22: 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26
> 26 26 10 10 10 10 10 10 10 10 10 10 10 10
> 24: 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28
> 28 28 10 10 10 10 10 10 10 10 10 10 10 10
> 26: 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
> 30 30 10 10 10 10 10 10 10 10 10 10 10 10
> 28: 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32
> 32 30 10 10 10 10 10 10 10 10 10 10 10 10
> 30: 32 32 32 32 32 32 32 32 34 34 34 34 34 34 34 32 32 32 32 32 32 32
> 32 30 10 10 10 10 10 10 10 10 10 10 10 10
> 32: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32
> 32 30 10 10 10 10 10 10 10 10 10 10 10 10
> 34: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32
> 32 30 10 10 10 10 10 10 10 10 10 10 10 10
> 36: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32
> 32 30 10 10 10 10 10 10 10 10 10 10 10 10
> 38: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32
> 32 30 10 10 10 10 10 10 10 10 10 10 10 10
> 40: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32
> 32 30 10 10 10 10 10 10 10 10 10 10 10 10
>
> Adapter 2
> 0: 30 30 30 30 30 30 30 26 0 0 0 0 0 0 0 30 30 30 30 30 30 30 30 26 0
> 0 0 0 0 0 0 0 0 0 0 0
> 2: 30 30 30 30 30 30 30 26 0 0 0 0 0 0 0 30 30 30 30 30 30 30 30 26 0
> 0 0 0 0 0 0 0 0 0 0 0
> 4: 30 30 30 30 30 30 30 26 0 0 0 0 0 0 0 30 30 30 30 30 30 30 30 26 0
> 0 0 0 0 0 0 0 0 0 0 0
> 6: 30 30 30 30 30 30 30 26 0 0 0 0 0 0 0 30 30 30 30 30 30 30 30 26 0
> 0 0 0 0 0 0 0 0 0 0 0
> 8: 30 30 30 30 30 30 30 26 0 0 0 0 0 0 0 30 30 30 30 30 30 30 30 26 0
> 0 0 0 0 0 0 0 0 0 0 0
> 10: 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0
> 12: 3 3 3 3 3 3 3 3 0 0 0 0 0 0 0 3 3 3 3 3 3 3 3 3 0 0 0 0 0 0 0 0 0 0 0 0
> 14: 5 5 5 5 5 5 5 5 0 0 0 0 0 0 0 5 5 5 5 5 5 5 5 5 0 0 0 0 0 0 0 0 0 0 0 0
> 16: 7 7 7 7 7 7 7 7 0 0 0 0 0 0 0 7 7 7 7 7 7 7 7 7 0 0 0 0 0 0 0 0 0 0 0 0
> 18: 9 9 9 9 9 9 9 9 0 0 0 0 0 0 0 9 9 9 9 9 9 9 9 9 0 0 0 0 0 0 0 0 0 0 0 0
> 20: 11 11 11 11 11 11 11 11 0 0 0 0 0 0 0 11 11 11 11 11 11 11 11 11 0
> 0 0 0 0 0 0 0 0 0 0 0
> 22: 13 13 13 13 13 13 13 13 0 0 0 0 0 0 0 13 13 13 13 13 13 13 13 13 0
> 0 0 0 0 0 0 0 0 0 0 0
> 24: 15 15 15 15 15 15 15 15 0 0 0 0 0 0 0 15 15 15 15 15 15 15 15 15 0
> 0 0 0 0 0 0 0 0 0 0 0
> 26: 17 17 17 17 17 17 17 17 0 0 0 0 0 0 0 17 17 17 17 17 17 17 17 17 0
> 0 0 0 0 0 0 0 0 0 0 0
> 28: 19 19 19 19 19 19 19 19 0 0 0 0 0 0 0 19 19 19 19 19 19 19 19 19 0
> 0 0 0 0 0 0 0 0 0 0 0
> 30: 21 21 21 21 21 21 21 21 0 0 0 0 0 0 0 21 21 21 21 21 21 21 21 21 0
> 0 0 0 0 0 0 0 0 0 0 0
> 32: 23 23 23 23 23 23 23 23 0 0 0 0 0 0 0 23 23 23 23 23 23 23 23 23 0
> 0 0 0 0 0 0 0 0 0 0 0
> 34: 25 25 25 25 25 25 25 25 0 0 0 0 0 0 0 25 25 25 25 25 25 25 25 25 0
> 0 0 0 0 0 0 0 0 0 0 0
>
> On Wed, Nov 24, 2010 at 8:33 PM, Blaise Gassend <blaise@willowgarage.com> wrote:
>> Is setting txpower in master mode supposed to work on ath9k?
>>
>> I have been adjusting the txpower on an ath9k radio set as master
>> mode, and monitoring RSSI on another radio. The results I am getting
>> seem very inconsistent. Sometimes RSSI decreases when txpower
>> incresase. Sometimes I can't get any change at all. Sometimes things
>> are sane over part of the power range, and constant elsewhere. I see
>> that there seem to be some table lookups involved in setting txpower.
>> Do some vendors fill those tables with garbage?
>>
>> I still need to take the time to take some good data on this and
>> debug, but thought I'd inquire if anybody happens to know off hand.
>>
>> Thanks,
>> Blaise

Which chipset are you using?  On which cards?  With the AR9280/AR9220,
I see the output power is pretty close to what is being set through iw
(measured with a spectrum analyzer).  I've been selecting output
levels between 5 and 17dBm.

[ath9k-devel] Is setting txpower in master mode on ath9k supposed to work?

[Blaise Gassend]

> Which chipset are you using? ?On which cards? ?With the AR9280/AR9220,
> I see the output power is pretty close to what is being set through iw
> (measured with a spectrum analyzer). ?I've been selecting output
> levels between 5 and 17dBm.

I agree that with my adapter 2, things behave well from 5 to 17dBm.
(Adapter 1 works well from 3 to 20, but with worse calibration.)
However, there the fact that it goes to a high power level from 0 to 5
dBm is disturbing to me. At best it is very misleading, and at worst
it could cause regulatory violations.

Adapter 1 is a PCI-E adapter from Sparklan
http://sparklan.com/product.php?func=view&prod_id=157
http://sparklan.com/product.php?func=view&prod_id=63
(I have one of each, and they behave identically.)
03:00.0 Network controller: Atheros Communications Inc. AR928X
Wireless Network Adapter (PCI-Express) (rev 01)
        Subsystem: Lite-On Communications Inc Device 6512
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at fbaf0000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: <access denied>
        Kernel driver in use: ath9k
        Kernel modules: ath9k

Adapter 2 is an Ubiquiti SR71-A (http://ubnt.com/sr71a)
02:02.0 Network controller: Atheros Communications Inc. AR9160
802.11abgn Wireless PCI Adapter (rev 01)
        Subsystem: Device 0777:4082
        Flags: bus master, 66MHz, medium devsel, latency 168, IRQ 16
        Memory at fb9e0000 (32-bit, non-prefetchable) [size=64K]
        Capabilities: <access denied>
        Kernel driver in use: ath9k
        Kernel modules: ath9k

[ath9k-devel] Is setting txpower in master mode on ath9k supposed to work?

[Brian Prodoehl]

On Tue, Dec 7, 2010 at 2:47 AM, Blaise Gassend <blaise@willowgarage.com> wrote:
>> Which chipset are you using? ?On which cards? ?With the AR9280/AR9220,
>> I see the output power is pretty close to what is being set through iw
>> (measured with a spectrum analyzer). ?I've been selecting output
>> levels between 5 and 17dBm.
>
> I agree that with my adapter 2, things behave well from 5 to 17dBm.
> (Adapter 1 works well from 3 to 20, but with worse calibration.)
> However, there the fact that it goes to a high power level from 0 to 5
> dBm is disturbing to me. At best it is very misleading, and at worst
> it could cause regulatory violations.
>
> Adapter 1 is a PCI-E adapter from Sparklan
> http://sparklan.com/product.php?func=view&prod_id=157
> http://sparklan.com/product.php?func=view&prod_id=63
> (I have one of each, and they behave identically.)
> 03:00.0 Network controller: Atheros Communications Inc. AR928X
> Wireless Network Adapter (PCI-Express) (rev 01)
> ? ? ? ?Subsystem: Lite-On Communications Inc Device 6512
> ? ? ? ?Flags: bus master, fast devsel, latency 0, IRQ 16
> ? ? ? ?Memory at fbaf0000 (64-bit, non-prefetchable) [size=64K]
> ? ? ? ?Capabilities: <access denied>
> ? ? ? ?Kernel driver in use: ath9k
> ? ? ? ?Kernel modules: ath9k
>
> Adapter 2 is an Ubiquiti SR71-A (http://ubnt.com/sr71a)
> 02:02.0 Network controller: Atheros Communications Inc. AR9160
> 802.11abgn Wireless PCI Adapter (rev 01)
> ? ? ? ?Subsystem: Device 0777:4082
> ? ? ? ?Flags: bus master, 66MHz, medium devsel, latency 168, IRQ 16
> ? ? ? ?Memory at fb9e0000 (32-bit, non-prefetchable) [size=64K]
> ? ? ? ?Capabilities: <access denied>
> ? ? ? ?Kernel driver in use: ath9k
> ? ? ? ?Kernel modules: ath9k
>

Ah, ok.  I have noticed going all the way back to madwifi and
AR500x-series chips that 0 is an especially low power setting.  Not
quite off, but often well below 0dBm.  Anything positive tends to be
within a couple dB of what is desired, until you get close to the max
output of the card.  Usually they don't really let you exceed what the
card was designed for, so there's often a wide range near the top of
what you may be dialing in that is all the same output power.  The
card's EEPROM specifies the maxes here, for each bitrate.  Are you
forcing a bitrate when you're trying to take measurements?  Going from
BPSK to 64-QAM, the output power can easily drop by 6dB.  If I get
time this week, I can plot the actual output power with R52n and R52Hn
cards, across desired power settings of 0-25dBm.  I have a WPEA-111N,
but hooking it up to the spectrum analyzer is a bit too troublesome.

[ath9k-devel] Is setting txpower in master mode on ath9k supposed to work?

[Daniel Halperin]

On Tue, Dec 7, 2010 at 6:07 AM, Brian Prodoehl <bprodoehl@gmail.com> wrote:
> Ah, ok. ?I have noticed going all the way back to madwifi and
> AR500x-series chips that 0 is an especially low power setting. ?Not
> quite off, but often well below 0dBm. ?Anything positive tends to be
> within a couple dB of what is desired, until you get close to the max
> output of the card.

At least the last time I checked, "txpower 0" in iwconfig was the same
as asking the card's transmit power to turn "off".  Not 0 dBm.  So it
might be significantly lower.

> ?Usually they don't really let you exceed what the
> card was designed for, so there's often a wide range near the top of
> what you may be dialing in that is all the same output power. ?The
> card's EEPROM specifies the maxes here, for each bitrate. ?Are you
> forcing a bitrate when you're trying to take measurements? ?Going from
> BPSK to 64-QAM, the output power can easily drop by 6dB. ?If I get
> time this week, I can plot the actual output power with R52n and R52Hn
> cards, across desired power settings of 0-25dBm. ?I have a WPEA-111N,
> but hooking it up to the spectrum analyzer is a bit too troublesome.

The above is correct, to add a little detail:

It's not uncommon among device manufacturers to reduce txpower for the
QAM modulations to keep the maximum power output close to the same.
BPSK/QPSK modulations use roughly equal power per symbol, but 16/64QAM
have higher peak-to-average-power ratios (PAPRs). What this means is
that symbols in the constellation are much stronger than others, which
pushes the limits of the TX amplifier, so they reduce the power of all
symbols to put that peak in a place the amplifier can handle.  If you
look at Ubiquiti NIC specs (I think there were some of their chips
involved in the earlier discussion) you can often see that the maximum
power transmitted is different for different modulations+coding
schemes.  See, e.g., http://ubnt.com/downloads/sr71a_datasheet.pdf
under '2.4 GHz TX POWER SPECIFICATIONS".

Dan

[ath9k-devel] Is setting txpower in master mode on ath9k supposed to work?

[Blaise Gassend]

Turns out that this bug was fixed a couple of days ago by this patch
(but it still exists in eeprom_9287.c and ar9003_eeprom.c):
http://www.mail-archive.com/ath9k-devel at lists.ath9k.org/msg04380.html

It is unfortunate that REDUCE_SCALED_POWER_BY_TWO_CHAIN is in
ath9k_hw_set_*_power_per_rate_table rather than
ath9k_hw_*_set_txpower, as some adapters would be able to reach lower
txpower levels if the reduction was done after txPowerIndexOffset is
added. I may write a patch for this.

[ath9k-devel] Is setting txpower in master mode on ath9k supposed to work?

[Adrian Chadd]

On 8 December 2010 03:10, Blaise Gassend <blaise@willowgarage.com> wrote:
> Turns out that this bug was fixed a couple of days ago by this patch
> (but it still exists in eeprom_9287.c and ar9003_eeprom.c):
> http://www.mail-archive.com/ath9k-devel at lists.ath9k.org/msg04380.html
>
> It is unfortunate that REDUCE_SCALED_POWER_BY_TWO_CHAIN is in
> ath9k_hw_set_*_power_per_rate_table rather than
> ath9k_hw_*_set_txpower, as some adapters would be able to reach lower
> txpower levels if the reduction was done after txPowerIndexOffset is
> added. I may write a patch for this.

All REDUCE_SCALED_POWER_BY_TWO_CHAIN is doing is scaling the target TX
power values.

How would changing txPowerIndexOffset going to help here? It's also
simply added to the rate table.

Just FYI - the SR-71A EEPROM values specify 0 for pwrDecreaseFor2Chain
and pwrDecreaseFor3Chain:

| pwrDecreaseFor2Chain: 0x00 | pwrDecreaseFor3Chain: 0x00 |
txFrameToDataStart: 0x0e | txFrameToPaOn: 0x0e |

So you could work around this in your own codebase by just ignoring
the power decrease. :-)

In fact, I may just go do that and submit a patch upstream.

One other thing to keep in mind is that there is AR_PHY_POWER_TX_SUB
which is programmed with 2-chain and 3-chain TX power reduction
values. I've not done any in-depth investigation here (as the SR-71A's
I'm using have the above "0" values :-) but I wonder if they do as
advertise - subtract from the actual TX power in hardware. If that's
the case, there may be no need for scaledPower as it's currently used.

Would someone with access to a spectrum analyzer (or be in Perth with
one? :-) pipe up so we can do some tests? :-)


Adrian

[ath9k-devel] Is setting txpower in master mode on ath9k supposed to work?

[Brian Prodoehl]

On Wed, Dec 8, 2010 at 3:26 AM, Adrian Chadd <adrian@freebsd.org> wrote:
> On 8 December 2010 03:10, Blaise Gassend <blaise@willowgarage.com> wrote:
>> Turns out that this bug was fixed a couple of days ago by this patch
>> (but it still exists in eeprom_9287.c and ar9003_eeprom.c):
>> http://www.mail-archive.com/ath9k-devel at lists.ath9k.org/msg04380.html
>>
>> It is unfortunate that REDUCE_SCALED_POWER_BY_TWO_CHAIN is in
>> ath9k_hw_set_*_power_per_rate_table rather than
>> ath9k_hw_*_set_txpower, as some adapters would be able to reach lower
>> txpower levels if the reduction was done after txPowerIndexOffset is
>> added. I may write a patch for this.
>
> All REDUCE_SCALED_POWER_BY_TWO_CHAIN is doing is scaling the target TX
> power values.
>
> How would changing txPowerIndexOffset going to help here? It's also
> simply added to the rate table.
>
> Just FYI - the SR-71A EEPROM values specify 0 for pwrDecreaseFor2Chain
> and pwrDecreaseFor3Chain:
>
> | pwrDecreaseFor2Chain: 0x00 | pwrDecreaseFor3Chain: 0x00 |
> txFrameToDataStart: 0x0e | txFrameToPaOn: 0x0e |
>
> So you could work around this in your own codebase by just ignoring
> the power decrease. :-)
>
> In fact, I may just go do that and submit a patch upstream.
>
> One other thing to keep in mind is that there is AR_PHY_POWER_TX_SUB
> which is programmed with 2-chain and 3-chain TX power reduction
> values. I've not done any in-depth investigation here (as the SR-71A's
> I'm using have the above "0" values :-) but I wonder if they do as
> advertise - subtract from the actual TX power in hardware. If that's
> the case, there may be no need for scaledPower as it's currently used.
>
> Would someone with access to a spectrum analyzer (or be in Perth with
> one? :-) pipe up so we can do some tests? :-)

I can.  Let me know what you want to see.  I did a quick run with an
R52n last night (AR9220 chipset).  Selecting 0 produced -14dBm,
selecting 5 produced -1dBm, 7 was actually -4dBm, 8 was actually 8dBm,
9 was 10dBm, 12 was 14dBm, and 14 was 17dBm.  That's per port in 2x2
mode at MCS0, running compat 11-30 in OpenWrt, which has some
txpower-related changes in this patch:
https://dev.openwrt.org/browser/trunk/package/mac80211/patches/320-pending_work.patch

I'd like to re-run with vanilla 12-07.  Like I said, let me know what
you want to see.  Tonight I should have time to test every value
between 0 and 20, recording that register value and the actual output
per port in 2x2.

[ath9k-devel] Is setting txpower in master mode on ath9k supposed to work?

[Adrian Chadd]

Hi,

Would you mind retrying it with 1mbit legacy rate (11bg) rather than MCS0?

If you configure 11a or 11bg (ie, non-n) then only 1 tx/rx chain is
enabled. This should bypass filling out the power decrease and the
AR_PHY_TX_POWER_SUB register.

Then yes, try that with TX power 0->max, reading the rate registers
and AR_PHY_TX_POWER_SUB.

Then retry in 11bgn mode, but at 1mbit legacy rate if you can.


Adrian


On 8 December 2010 22:10, Brian Prodoehl <bprodoehl@gmail.com> wrote:
> On Wed, Dec 8, 2010 at 3:26 AM, Adrian Chadd <adrian@freebsd.org> wrote:
>> On 8 December 2010 03:10, Blaise Gassend <blaise@willowgarage.com> wrote:
>>> Turns out that this bug was fixed a couple of days ago by this patch
>>> (but it still exists in eeprom_9287.c and ar9003_eeprom.c):
>>> http://www.mail-archive.com/ath9k-devel at lists.ath9k.org/msg04380.html
>>>
>>> It is unfortunate that REDUCE_SCALED_POWER_BY_TWO_CHAIN is in
>>> ath9k_hw_set_*_power_per_rate_table rather than
>>> ath9k_hw_*_set_txpower, as some adapters would be able to reach lower
>>> txpower levels if the reduction was done after txPowerIndexOffset is
>>> added. I may write a patch for this.
>>
>> All REDUCE_SCALED_POWER_BY_TWO_CHAIN is doing is scaling the target TX
>> power values.
>>
>> How would changing txPowerIndexOffset going to help here? It's also
>> simply added to the rate table.
>>
>> Just FYI - the SR-71A EEPROM values specify 0 for pwrDecreaseFor2Chain
>> and pwrDecreaseFor3Chain:
>>
>> | pwrDecreaseFor2Chain: 0x00 | pwrDecreaseFor3Chain: 0x00 |
>> txFrameToDataStart: 0x0e | txFrameToPaOn: 0x0e |
>>
>> So you could work around this in your own codebase by just ignoring
>> the power decrease. :-)
>>
>> In fact, I may just go do that and submit a patch upstream.
>>
>> One other thing to keep in mind is that there is AR_PHY_POWER_TX_SUB
>> which is programmed with 2-chain and 3-chain TX power reduction
>> values. I've not done any in-depth investigation here (as the SR-71A's
>> I'm using have the above "0" values :-) but I wonder if they do as
>> advertise - subtract from the actual TX power in hardware. If that's
>> the case, there may be no need for scaledPower as it's currently used.
>>
>> Would someone with access to a spectrum analyzer (or be in Perth with
>> one? :-) pipe up so we can do some tests? :-)
>
> I can. ?Let me know what you want to see. ?I did a quick run with an
> R52n last night (AR9220 chipset). ?Selecting 0 produced -14dBm,
> selecting 5 produced -1dBm, 7 was actually -4dBm, 8 was actually 8dBm,
> 9 was 10dBm, 12 was 14dBm, and 14 was 17dBm. ?That's per port in 2x2
> mode at MCS0, running compat 11-30 in OpenWrt, which has some
> txpower-related changes in this patch:
> https://dev.openwrt.org/browser/trunk/package/mac80211/patches/320-pending_work.patch
>
> I'd like to re-run with vanilla 12-07. ?Like I said, let me know what
> you want to see. ?Tonight I should have time to test every value
> between 0 and 20, recording that register value and the actual output
> per port in 2x2.
>

[ath9k-devel] Is setting txpower in master mode on ath9k supposed to work?

[BC]

Is setting txpower in master mode on ath9k
	supposed	to work?
To: ath9k-devel at lists.ath9k.org
Message-ID:
	<AANLkTikV+xqZsULtDz1JesDOj5Aed_uzJmPmfnsaiNJt@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

>Is setting txpower in master mode supposed to work on ath9k?

>I have been adjusting the txpower on an ath9k radio set as master
mode, and monitoring RSSI on another radio. The results I am getting
seem very inconsistent. Sometimes RSSI decreases when txpower
incresase. Sometimes I can't get any change at all. Sometimes things
are sane over part of the power range, and constant elsewhere. I see
that there seem to be some table lookups involved in setting txpower.
Do some vendors fill those tables with garbage?

>I still need to take the time to take some good data on this and
debug, but thought I'd inquire if anybody happens to know off hand.



I had similar problems. I switched from Ad Hoc mode to Infrastructure mode and that fixed the TxPower problem I was having. Hope that helps.
Also try to switch to the latest ath9k driver and latest kernel.




Brandon M. Combs
Brmcombs at iusb.edu
mypage.iusb.edu/~brmcombs
(574)202-0972
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20101125/93266a4a/attachment.htm