Tx power setting patch

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

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?

  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)?

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

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.

Dustin

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.

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).

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

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.

Jiri

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

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