Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #194 (closed defect: duplicate)

Opened 8 years ago

Last modified 8 years ago

Tx power setting patch

Reported by: Assigned to: mrenzmann
Priority: major Milestone:
Component: madwifi: driver Version: trunk
Keywords: Tx Power Cc:
Patch is attached: 1 Pending:


I have been trying to set the Tx power through iwconfig and have found that the power value doesn't get set appropriately (as have others folks). It seems that the ic_txpowlimit value never gets set and so the power setting code in ath_update_txpow doesn't get called. Then each of the VAP power settings is simply reset to the original default value.

I'm not quite sure of the relationship between the maximum power setting for the device (set with ath_hal_settxpowlimit) versus the Tx power requested for each packet using ath_hal_setuptxdesc. I've done some measurements with a spectrum analyzer and found that the only way I can get the Tx power settings to change is by calling ath_hal_settxpowlimit.

I've attached a patch that sets the device's maximum power limit to the highest value requested by any of the VAP's on that device. I'm not sure if this patch is the correct solution, but at least it allows me to modifiy power levels settings and to verify that those power levels are actually changing the output power.

Signed-off-by: Dustin McIntire? <>


txpower.patch (1.0 kB) - added by on 11/30/05 20:10:35.
Patch to change device power levels based on maximum VAP power setting

Change History

11/30/05 20:10:35 changed by

  • attachment txpower.patch added.

Patch to change device power levels based on maximum VAP power setting

12/15/05 08:33:41 changed by mrenzmann

  • status changed from new to assigned.
  • owner set to mrenzmann.

12/29/05 17:51:38 changed by mrenzmann

The following is a answer from Sam to a mail from Bruno, regarding how to implement the TX power control right:

we are trying to make the txpower setting work on madwifi, but it looks like ath_hal_getmaxtxpow(sc->sc_ah, &txpow) always clamps the value to something about 30. in the old madwifi we did'nt have this check, and it seemed to work (there was a change in RSSI) but it seems reasonable to have the check. can you explain the difference between:

ath_hal_gettxpowlimit(ah, &txpow);
ath_hal_getmaxtxpow(sc->sc_ah, &txpow);

what needs to be done for proper txpower handling from your point of view?

getmaxtxpow returns the txpow limit (in .5 dBm units) calculated from the card capabilities and the regulatory constraint

gettxpowlimit returns the current, potentially constrained, txpow limit (in .5 dBm units) as set for example when implementing 11h; it is clamped (internally) to the value returned by getmaxtxpow

There are 3 ways to control tx power:

  1. settxpowlimit to clamp the max txpower to a setting lower than the max allowed by the card++regdomain
  2. the per tx descriptor tpc which is an index into a table of size 64 which yields uneven tx power steps that you must calibrate per card but typically has finer grain control at the "low end"; you must explicitly enable this before use with HAL_CAP_TPC
  3. tx power scaling (HAL_CAP_TXPOW, 3) which is included solely for compatbility with Atheros' vxworks code and may go away at any time; this is a setting in the range [0..4] which causes the txpow tables to be down-scaled when they are calculated by 0, 3, 6, 9, and max dBm

The intended/preferred way to control txpower is with the per-packet TPC setting in the tx descriptor. However because it's been hard to get that right and because not all parts support it I added the tpScale knob.

I recently did some txpower tests on 5212 cards and believe things are working. There is one issue that we discovered; that the txpower for self-generated frames was not set correctly when using per-packet tpc (it is low)--this will be fixed in the next hal rev.

This should be considered for the implementation of a patch as the one above.

@reporter: Can you please verify if your patch complies with what Sam suggests?

12/29/05 18:50:49 changed by Mister_X

  getmaxtxpow returns the txpow limit (in .5 dBm units) calculated from the card
  capabilities and the regulatory constraint

Will this work on high power cards like Ubiquiti SR2, SR5 and SRC (respectivly 400, 400 and 300mw)?

01/03/06 11:47:23 changed by mrenzmann

re Mister_X: Hard to tell, this is a question to be forwarded to either Atheros or Sam. Will do so later this week.

01/03/06 16:56:44 changed by

I've been using the Ubiquiti SR2 to test the power settings with the attached patch. What I have found with this particular card is that the output power actually corresponds to the output setting issued by iwconfig + 10db. So the 16dbm setting is actually the 26dbm (400mW) Tx output power, and setting 6dbm would actually set the 16dbm output power, etc.


01/03/06 19:00:59 changed by Thorsten

The Ubiquiti SR2 power "offset" is presumably done on purpose by Ubiquiti in order to cope with drivers that clamp the output power below 23dBm preventing users from getting full power on these cards. See UserDocs/Ubiquiti where I've also added your note.

01/03/06 21:35:50 changed by

That was my assumption as well. The impact is that is that one cannot effectively set the ouput power for these cards below 10dbm (if one really wants to anyway).

01/04/06 07:26:11 changed by mrenzmann

Dustin, can you please verify if your patch with what has been suggested by Sam (see the quote above)?

01/15/06 14:27:01 changed by jirif

getmaxtxpow returns the txpow limit (in .5 dBm units) calculated from the card capabilities and the regulatory constraint

This is not right. When is the settxpowlimit < maxtxpowlimit allowed by regdomain, it return value set by settxpowlimit. So this function return current txpower limit

BTW: Dustin's patch working, its only hack to not working TPC of the current implementation (Sam's way 1). I working at more clean implementation.


01/16/06 20:42:13 changed by anonymous

  • cc set to

01/23/06 08:23:59 changed by mrenzmann

Jiri has posted the announced reworked version of this patch in #315.

02/01/06 06:31:52 changed by mrenzmann

  • patch_attached set to 1.

02/03/06 06:34:26 changed by mrenzmann

  • status changed from assigned to closed.
  • resolution set to duplicate.

Closing this ticket as "duplicate" (which isn't entirely correct, though). Please follow up to #315.