Hi guys,

Since I've been knee-deep in the AR9160 power calibration code (And
I've been eyeballing the AR92xx TX power calibration code, in prep for
porting it all to FreeBSD) I can help you guys start diagnosing it.

Firstly, I know that the SR-71A under FreeBSD "does the right thing"
TX power wise, from a target power rate of 0 all the way to "max" (19
dBm, which is 16dBm on the SR-71A.)

Ubiquiti have written in "strange" power calibration parameters into
the SR-71A EEPROM so the configured power is lower (as I said, 19dBm
target TX power gets you 16dBm real power @ 1mbit 11b), but then
that's multiplied by 3 to get you their "spec" sheet power (which is
supposed to be 22dBm, but is closer to 21dBm.)

Firstly, how are you measuring the output power of the SR-71A? What
are you doing to generate traffic?

Secondly, just to make sure things are "doing the right thing", I
suggest checking the contents of the target power registers as you
configure successively higher TX power rates - just to make sure the
"right" values are being programmed in. They should increase linearly
from 0 to 38 (19*2, the target TX power rate registers are in 0.5 dBm
increments) for the 11bg rates < 24mbit, then the > 24mbit rates will
drop off a bit earlier (14-16dBm target TX power, IIRC.)

If those register values are incrementing correctly, then the next
step would be to dump the EEPROM contents to see what the configured
values are, then see what values are being written into the PDADC
curve/PDADC gain boundary/gain level registers.

The following is at least correct for the AR9160. I haven't yet gone
deep digging into the AR9280+ chips:

The TX power rate registers in question:

2/5ghz ofdm:
AR_PHY_POWER_TX_RATE1   0x9934 - | rate 18mbit | rate 12mbit | rate
9mbit | rate 6mbit |
AR_PHY_POWER_TX_RATE2   0x9938 - | rate 54mbit | rate 48mbit | rate
36mbit | rate 24mbit |

2ghz:
AR_PHY_POWER_TX_RATE3   0xA234 - | rate 2s | rate 2l | rate Xr | rate 1l |
AR_PHY_POWER_TX_RATE4   0xA238  - | rate 11s | rate 11l | rate 5_5s | rate 5_5l 
|

AR_PHY_POWER_TX_RATE5   0xA38C - | rate HT20 3 | rate HT20 2 | rate
HT20 1 | rate HT20 0 |
AR_PHY_POWER_TX_RATE6   0xA390 - | rate HT20 7 | rate HT20 6 | rate
HT20 5 | rate HT20 4 |
AR_PHY_POWER_TX_RATE7   0xA3CC - | rate HT40 3 | rate HT40 2 | rate
HT40 1 | rate HT40 0 |
AR_PHY_POWER_TX_RATE8   0xA3D0 - | rate HT40 7 | rate HT40 6 | rate
HT40 5 | rate HT40 4 |
AR_PHY_POWER_TX_RATE9   0xA3D4 - | rate Ext OFDM | rate ext CCK | rate
dup OFDM | rate dup CCK |

So if you're testing 11bg power at 19dBm on channel 6,
POWER_TX_RATE2/3 should be 0x26262626 (0x26 = 38 = 2 * 19dBm.) Then
RATE1/RATE2 will show lower values for the higher tx powers.

Now, inspecting registers on ath9k (thanks Felix! :-)

(This is not from an AR9160, this is from an AR9100. It demonstrates
the idea though.)

r...@openwrt:/sys/kernel/debug/ath9k/phy0# echo "0xa234" > regidx ; cat regval
0x24242124
r...@openwrt:/sys/kernel/debug/ath9k/phy0# echo "0xa238" > regidx ; cat regval
0x24242424
r...@openwrt:/sys/kernel/debug/ath9k/phy0# echo "0x9934" > regidx ; cat regval
0x21212121
r...@openwrt:/sys/kernel/debug/ath9k/phy0# echo "0x9938" > regidx ; cat regval
0x1a202121

If you have the time, I suggest writing a script to set the TX power
level, then inspect the relevant rate registers. If they're being
programmed "right" from TX power target 0 -> 19, then the next step is
to look at the power calibration stuff. But I can verify that although
TX power can be -unstable- at times, (and I have no idea why this
is!), FreeBSD's HAL "gets it right" on the SR-71A from txpower=0dBm ->
txpower=19dBm.

HTH,


Adrian

On 8 December 2010 06:13, BC <[email protected]> wrote:
> I also have "adapter 1" the WPEA-111N AR9280 Half-mini card and I can ACK
> that my TxPower output is buggy.
>
> The TxPower does not seem to adjust in Ad Hoc mode and sometimes not in
> Infrastructure either. Here is my system info:
>
> ~/Desktop$ uname -a
>
>
> Linux B-netbook 2.6.32-24-generic #41-Ubuntu SMP Thu Aug 19 01:12:52 UTC
> 2010 i686 GNU/Linux
>
>
>
>
>
> ~/Desktop$  sudo lspci -vvv
>
> 05:00.0 Network controller: Atheros Communications Inc. AR928X Wireless
> Network Adapter (PCI-Express) (rev 01)
>
>  Subsystem: Lite-On Communications Inc Device 6512
>
>  Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR+ FastB2B- DisINTx-
>
>  Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
> <MAbort- >SERR- <PERR- INTx-
>
>  Latency: 0, Cache Line Size: 32 bytes
>
>  Interrupt: pin A routed to IRQ 16
>
>  Region 0: Memory at f0100000 (64-bit, non-prefetchable) [size=64K]
>
>  Capabilities: [40] Power Management version 2
>
>  Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA
> PME(D0+,D1+,D2-,D3hot+,D3cold-)
>
>  Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
>  Capabilities: [50] Message Signalled Interrupts: Mask- 64bit- Queue=0/0
> Enable-
>
>  Address: 00000000  Data: 0000
>
>  Capabilities: [60] Express (v1) Legacy Endpoint, MSI 00
>
>  DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
>
>  ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
>
>  DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>
>  RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
>
>  MaxPayload 128 bytes, MaxReadReq 512 bytes
>
>  DevSta: CorrErr+ UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend-
>
>  LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM unknown, Latency L0 <512ns,
> L1 <64us
>
>  ClockPM- Suprise- LLActRep- BwNot-
>
>  LnkCtl: ASPM L1 Enabled; RCB 128 bytes Disabled- Retrain- CommClk+
>
>  ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>
>  LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt-
> ABWMgmt-
>
>  Capabilities: [90] MSI-X: Enable- Mask- TabSize=1
>
>  Vector table: BAR=0 offset=00000000
>
>  PBA: BAR=0 offset=00000000
>
>  Capabilities: [100] Advanced Error Reporting <?>
>
>  Capabilities: [140] Virtual Channel <?>
>
>  Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
>
>  Kernel driver in use: ath9k
>
>  Kernel modules: ath9k
>
>
>
>
>
> ~/Desktop$ sudo lshw
>
>  *-network
>
>                 description: Wireless interface
>
>                 product: AR928X Wireless Network Adapter (PCI-Express)
>
>                 vendor: Atheros Communications Inc.
>
>                 physical id: 0
>
>                 bus info: p...@0000:05:00.0
>
>                 logical name: wlan2
>
>                 version: 01
>
>                 serial: 00:0e:8e:28:01:ec
>
>                 width: 64 bits
>
>                 clock: 33MHz
>
>                 capabilities: pm msi pciexpress msix bus_master cap_list
> ethernet physical wireless logical
>
>                 configuration: broadcast=yes driver=ath9k
> driverversion=2.6.32-24-generic firmware=N/A ip=192.168.1.1 latency=0
> link=yes multicast=yes wireless=IEEE 802.11abgn
>
>                 resources: irq:16 memory:f0100000-f010ffff
>
>>
>>Date: Mon, 6 Dec 2010 23:47:48 -0800
> From: Blaise Gassend <[email protected]>
> Subject: Re: [ath9k-devel] Is setting txpower in master mode on ath9k
>       supposed to work?
> To: Brian Prodoehl <[email protected]>
> Cc: [email protected]
> Message-ID:
>       <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1
>
>> 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
>
>
> ------------------------------
>
> Brandon M. Combs
> [email protected]
> mypage.iusb.edu/~brmcombs
> (574)202-0972
> _______________________________________________
> ath9k-devel mailing list
> [email protected]
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>
_______________________________________________
ath9k-devel mailing list
[email protected]
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Reply via email to