Ah! I remember reading up on that. I'm not even sure what the correct behaviour should be there at the low TX power levels. The FreeBSD HAL uses the values in the v14 EEPROM, rather than hard-coded 2/3 chain TX power subtractions.
I'll go read the other email and reply to that. Adrian On 8 December 2010 14:50, Blaise Gassend <[email protected]> wrote: > Hi Adrian, > > Like I said in an earlier post today, it looks like a patch went out a > few days ago that solves the problem. The problem was being caused by > an underflow when reducing the power to take into account multiple TX > antennas. If the requested power was too low, subtracting out those > corrections was causing the power level to wrap to a high value. > > The patch I am referring to is here: > http://www.mail-archive.com/[email protected]/msg04380.html > > With the patch, we still have the problem that with multiple antennas, > the lowest part of the txpower range will be clamped to a constant > value (now if you go too low, you get clamped at zero), which is > unfortunate because in many cases it would be possible to to set a > lower txpower on the hardware. Fixing this is more intrusive, as it > either involves making many variables signed, or it involves moving > the correction to a different place in the code base, which will > change a few of the checks that get done (perhaps for the better). > > I can be more precise if you are interested, and in fact I was in my > earlier email today. > > Blaise > > On Tue, Dec 7, 2010 at 9:56 PM, Adrian Chadd <[email protected]> wrote: >> 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
