search

qca / open-ath9k-htc-firmware

The firmware for QCA AR7010/AR9271 802.11n USB NICs
Other
432 stars 183 forks source link

ath9k_htc AR9271 tx power increase weird problem + debug #82

Open brunoaduarte opened 8 years ago

brunoaduarte commented 8 years ago

Hi, i'm trying to increase tx power of my AR9271 card using ath9k_htc backports 4.0.1 driver + open-ath9k-htc-firmware, but i got this strange behavior:

iwconfig wlan0 set txpower (from 1 to 17) dBm

iwconfig wlan0 set txpower (from 18 to 23) dBm

Here are the measurements with more detailed info https://docs.google.com/spreadsheets/d/1Ad3AoFaqREGViFPtKFfQzRQvgilnv9e008ltYJlwHG8/edit?usp=sharing

Some considerations:
#define    AR5416_PWR_TABLE_OFFSET_DB -5
    for (i = 0; i < Ar5416RateSize; i++) {
        ratesArray[i] -= AR5416_PWR_TABLE_OFFSET_DB * 2
        // times 2 cause ratesArray needed half/dBm values;
    }
#define MAX_RATE_POWER    63 (0x3F) // half dbm correct ?

Does this define set the max firmware power as 63/2 = 31.5 dBm ? Why this value ? Can it be changed to go as high as 66 (0x42) (33 dBm) ?

Thanks

erikarn commented 8 years ago

hiya,

so no - the maximum rate power you can program into the chip for each of the possible transmit rates is 0x3f. now, on ar9280 and later chips the target transmit power starts at -5dBm, purely as a function of how the transmit power control hardware works.

It sounds like there's a bug somewhere - but it sounds like it does clamp the values /somewhere/. Just read back the TX power register values as you up the transmit power via iwconfig and see whta they say. (AR_PHYTXPOWER* ...)

On 24 January 2016 at 09:26, Bruno Duarte notifications@github.com wrote:

Hi, i'm trying to increase tx power of my AR9271 card using ath9k_htc backports 4.0.1 driver + open-ath9k-htc-firmware, but i got this strange behavior:

iwconfig wlan0 set txpower (from 1 to 17) dBm

  • increases rx power detected by the receiver (airodump-ng PWR column) step by step as expected (-79 to -62)

iwconfig wlan0 set txpower (from 18 to 23) dBm

  • when set to 18, RX PWR makes a strange jump from -62 to -48 (why !?), and values over 18 (19 to 23), does not have any effect on RX PWR, it will stay at -48

Here are the measurements with more detailed info

https://docs.google.com/spreadsheets/d/1Ad3AoFaqREGViFPtKFfQzRQvgilnv9e008ltYJlwHG8/edit?usp=sharing Some considerations:

  • ath9k_htc backports driver makes a internal increase of (5 dBm) before setting the power with REG_WRITE

define AR5416_PWR_TABLE_OFFSET_DB -5

for (i = 0; i < Ar5416RateSize; i++) {
    ratesArray[i] -= AR5416_PWR_TABLE_OFFSET_DB \* 2 // times 2 cause ratesArray needed half/dBm values;
}
  • So we have, 17 dBm (iwconfig) + 5 dBm (offset from ath9k_htc driver) = 23 dBm * 2 (cause the card works with half dBm values) = 46 as the maximum value that causes any effects on the firmware

Questions:

  • Where in the firmware can i look to understand this -62 to -48 rx gap ?
  • Is there anyway to do a live or even a log debug in this firmware ?
  • In if_athvar.c

define MAX_RATE_POWER 63 // half dbm correct ?

Does this define set the max firmware power as 63/2 = 31.5 dBm ? Why this value ? Can it be changed to go as high as 66 (33 dBm) ?

Thanks

— Reply to this email directly or view it on GitHub https://github.com/qca/open-ath9k-htc-firmware/issues/82.

brunoaduarte commented 8 years ago

Thanks for the reply @erikarn

Seems that the registers are correctly set, this is my driver debug output (dmesg):

eeprom_4k.c -> ath9k_hw_4k_set_txpower

iwconfig wlan1 txpower 17
ath: ratesArray[0](d) -> 34 (17 dBm)
ath: ratesArray[0](d) -> 44 (22 dBm) (considering -5 dBm AR5416_PWR_TABLE_OFFSET_DB)
ath: REG_WRITE(AR_PHY_POWER_TX_RATE1) = 741092396 (0x2c2c2c2c)
ath: REG_WRITE(AR_PHY_POWER_TX_RATE2) = 741092396 (0x2c2c2c2c)
ath: REG_READ(AR_PHY_POWER_TX_RATE1) = 741092396 (0x2c2c2c2c)
ath: REG_READ(AR_PHY_POWER_TX_RATE2) = 741092396 (0x2c2c2c2c)

RX POWER LEVEL = -62

iwconfig wlan1 txpower 18
ath: ratesArray[0](d) -> 36 (18 dBm)
ath: ratesArray[0](d) -> 46 (23 dBm) (considering -5 dBm AR5416_PWR_TABLE_OFFSET_DB)
ath: REG_WRITE(AR_PHY_POWER_TX_RATE1) = 774778414 (0x2e2e2e2e)
ath: REG_WRITE(AR_PHY_POWER_TX_RATE2) = 774778414 (0x2e2e2e2e)
ath: REG_READ(AR_PHY_POWER_TX_RATE1) = 774778414 (0x2e2e2e2e)
ath: REG_READ(AR_PHY_POWER_TX_RATE2) = 774778414 (0x2e2e2e2e)

RX POWER LEVEL = -48

iwconfig wlan1 txpower 19
ath: ratesArray[0](d) -> 38 (19 dBm)
ath: ratesArray[0](d) -> 48 (24 dBm) (considering -5 dBm AR5416_PWR_TABLE_OFFSET_DB)
ath: REG_WRITE(AR_PHY_POWER_TX_RATE1) = 808464432 (0x30303030)
ath: REG_WRITE(AR_PHY_POWER_TX_RATE2) = 808464432 (0x30303030)
ath: REG_READ(AR_PHY_POWER_TX_RATE1) = 808464432 (0x30303030)
ath: REG_READ(AR_PHY_POWER_TX_RATE2) = 808464432 (0x30303030)

RX POWER LEVEL = -48

iwconfig wlan1 txpower 20
ath: ratesArray[0](d) -> 40 (20 dBm)
ath: ratesArray[0](d) -> 50 (25 dBm) (considering -5 dBm AR5416_PWR_TABLE_OFFSET_DB)
ath: REG_WRITE(AR_PHY_POWER_TX_RATE1) = 842150450 (0x32323232)
ath: REG_WRITE(AR_PHY_POWER_TX_RATE2) = 842150450 (0x32323232)
ath: REG_READ(AR_PHY_POWER_TX_RATE1) = 842150450 (0x32323232)
ath: REG_READ(AR_PHY_POWER_TX_RATE2) = 842150450 (0x32323232)

RX POWER LEVEL = -48

olerem commented 8 years ago

Hi, which adapter are you using? Is it one with external amplifier?

brunoaduarte commented 8 years ago

It's Alfa AWUS036NHA, it has a Skyworks SE2576L power amplifier onboard.

olerem commented 8 years ago

Ok, i had some doubts that amp is correctly set, so may be it is the case. Take look at ar5416SetupTxDesc_20.

If i see it correctly some gpio should be pulled up to set max power on this amp.

brunoaduarte commented 8 years ago

Well @olerem , i'm not sure how this works, but the only connection between SE2576L and AR9271L is this:

SE2576L - PIN 2 (EN) - Power Amplifier Enable AR9271L - PIN 67 (XPABIAS) - Bias for optional external power amplifier they're connected thru a 10 ohm resistor

I can't measure this pin precisely cause i don't have a oscilloscope (it's an analog output), but with the multimeter i've measured 10 mV with some 25 mV peak.

I've looked at "ar5416SetupTxDesc_20" but can't see anything related to this BIAS control there.

olerem commented 8 years ago

hm.. according doc i would expect 3.3V on SE2576L - PIN 2 (EN). If i remember correctly, windows driver was providing option to enable high gain TX. Do you have M$ can you compare both drivers?

I pointed to ar5416SetupTxDesc_20 as example where TX gain is set.

brunoaduarte commented 8 years ago

@olerem , I installed latest AWUS036NHA drivers from alfa.com.tw in my Windows XP machine. There's no option to enable high gain TX in the Atheros utilities or the driver management tab.

Maximum setable tx power that appeared here is 100 mW.

I've measured the pin again and there's nothing there, as always (0 V). I'm not sure if there are any cases where this power amplifier is used. Also, i've manually pull up this pin to 3V, using a resistor, and nothing happened, i could not see any difference in output power (i'm going to try this again with a lower value resistor).

When you first mentioned this power amplifier, i thought that maybe the power level gap i see in my receiver, when setting

TX: iwconfig wlan1 txpower 17 -> RX = -62 TX: iwconfig wlan1 txpower 18 -> RX = -48

was caused because of the power amplifier being turned off and on respectively, but that makes no sense if the EN pin of SE2576L doesn't change.

brunoaduarte commented 8 years ago

Seems that the power amplifier is working... I've set lowest transmission power

iwconfig wlan1 txpower 1

and RX power level on receiver was -70... So i manually pull up the SE2576L EN pin to 3.3V using a 100 ohm resistor and RX power level became -55 without any iwconfig changes

ps: even if i remove the pull up resistor, power stays at the same -55, power amplifier doesn't get deactivated

then i do iwconfig wlan1 txpower 18 and rx level became -40

then i reset everything and set

iwconfig wlan1 txpower 18

and RX power level is instantaneously -40 now i repeated the process and manually pulled up EN pin... nothing happened

RX level stayed at the same -40... So it means that, somehow, after

iwconfig wlan1 txpower 18

the power amplifier is being turned on... Maybe it doesn't need constant dc current on it. Maybe it's just a pulse (like a manually did with the resistor)...

btw, when i do the manual pull up, i get this debug message from the driver

ath: phy7: NF did not complete in calibration window ath: phy7: Reset TX queue: 0 ath: phy7: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0 ath: phy7: Reset TX queue: 1 ath: phy7: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0 ath: phy7: Reset TX queue: 2 ath: phy7: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0 ath: phy7: Reset TX queue: 3 ath: phy7: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0 ath: phy7: Reset TXQ, inactive queue: 4 ath: phy7: Reset TXQ, inactive queue: 5 ath: phy7: Reset TXQ, inactive queue: 6 ath: phy7: Reset TXQ, inactive queue: 7 ath: phy7: Reset TX queue: 8 ath: phy7: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0 ath: phy7: Reset TX queue: 9 ath: phy7: tx ok 0x0 err 0x0 desc 0x10f eol 0x10f urn 0x0 ath: phy7: ah->misc_mode 0xc ath: phy7: enabling ADC Gain Calibration ath: phy7: enabling ADC DC Calibration ath: phy7: enabling IQ Calibration ath: phy7: starting ADC Gain Calibration

erikarn commented 8 years ago

HI,

Check the RX rate. I wonder if hte rate is changing and you're seeing a lower rate at a higher tx power..

-a

brunoaduarte commented 8 years ago

How do i check RX rate @erikarn ? I'm doing my tests using a fake access point (hostapd) on tx side (awus036nha), and airodump-ng running on receiver side to check RX power level.

erikarn commented 8 years ago

So, each rate has a different max transmit power. Lower rates have higher maximum transmit powers. So unless you fix a rate somehow (can that work with ath9k_htc right now?) then the rate control may be stepping the rate down and transmitting at a higher max poewr.

So on the receiver, log both the RSSI /and/ the RX rate (Mbit/sec) so we can see.

-a

On 26 January 2016 at 21:34, Bruno Duarte notifications@github.com wrote:

What do you mean by RX rate @erikarn https://github.com/erikarn ? How do i check it ? I'm doing my tests using a fake access point (hostapd) on tx side (awus036nha), and airodump-ng running on receiver side.

— Reply to this email directly or view it on GitHub https://github.com/qca/open-ath9k-htc-firmware/issues/82#issuecomment-175410490 .

brunoaduarte commented 8 years ago

Ahh ok. I don't think that's the case @erikarn ... as hostpad seems to set a fixed default rate of 11 mbps and i'm not forcing it to any other...

Operation mode (a = IEEE 802.11a, b = IEEE 802.11b, g = IEEE 802.11g, Default: IEEE 802.11b

CH  6 ][ Elapsed: 14 mins ][ 2016-01-27 14:50  ][  1/  1/   1 ][ paused output                                                     

 BSSID              PWR RXQ  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID                                                       

 00:C0:CA:AA:AA:AA  -58  93     8521        0    0   6  11   OPN              Alfa

I've tried some EEPROM hacking on the adapter. I've replaced the rates power table with higher values, but no success increasing TX POWER.

I've related my tests in this topic:

https://forums.kali.org/showthread.php?28874-ALFA-AWUS036NHA-hacking-EEPROM-via-UART-JTAG&p=55742&viewfull=1#post55742

FYI: the tests i've related here before, were made with original EEPROM data. These EEPROM tests i've made were specific tests.

yipperr commented 8 years ago

@brunoaduarte any further news on the tx power also have you noticed the weird hum this card makes at high data rates one other dude confirmed this in another thread

psyborg55 commented 8 years ago

Hi

Thanks for the detailed test results. Can you tell me how to calculate checksum on modified EEPROM data? The reader used was not able to do ICP R/W so I'll have to unsolder the chip and I won't even try that before I'm sure I can get working modified EEPROM.

As per comment located in this post https://forums.kali.org/showthread.php?28874-ALFA-AWUS036NHA-hacking-EEPROM-via-UART-JTAG&p=59550&viewfull=1#post59550

I've seen the change in driver behaviour, but only in such a way that the power gap between 17 and 18 dBm is reduced and spread across 17-27 dBm. Still no power increase in my case.

Also, any ideas where in the code they've broke rate control so I can set fixed rate?

Wish I could find an old revision of the NHA card because I get feeling this thing with power amplifier is crippled.

jholster commented 8 years ago

@brunoaduarte I'm also trying to figure out how to boost the output from AWUS036NHA. It seems that simple software hacks like hardcoding the desired power level into driver source does not work. I suspect that there is a hardware closed loop controlling the output power.

Did you notice that there is another connection between the chips, the DET output from SE2576L is connected to PDET input of AR9271. It signals the AR9271 the actual power output, so that AR9271 can adjust the input signal accordingly, if I understand correctly. Check the http://www.skyworksinc.com/uploads/documents/202428A.pdf datasheet page 5 for voltage curve. Maybe we could fake this signal to enable the full power output e.g. by pulling down or putting a resistor between (not easy soldering job!), so AR9271 thinks the output is lower than it actually is.

Your findings about pulling up the EN pin are interesting. I wonder if pull up causes overheating by 100% duty cycle and some protection mode kicks on? Did you check temperature? The fact that SE2576L datasheet mentions EN rise time hints that you are supposed to drive it by dynamically, i.e. only when you are actually transmitting?

(I'm not an EE, all the above are only amateur guessing.)

PS. The wifibroadcast project contains a patch for fixed rate: https://befinitiv.wordpress.com/2015/02/22/finding-the-right-wifi-dongle-and-patching-its-kernel-driver-and-firmware/

psyborg55 commented 8 years ago

doing a check of driver code i found this:

/* PA CAL is not needed for high power solution */
if (ah->eep_ops->get_eeprom(ah, EEP_TXGAIN_TYPE) ==
    AR5416_EEP_TXGAIN_HIGH_POWER)
    return;

static void ar9271_hw_init_txgain_ini(struct ath_hw *ah, u32 txgain_type) { if (txgain_type == AR5416_EEP_TXGAIN_HIGH_POWER) INIT_INI_ARRAY(&ah->iniModesTxGain, ar9271Modes_high_power_tx_gain_9271); else INIT_INI_ARRAY(&ah->iniModesTxGain, ar9271Modes_normal_power_tx_gain_9271);

static const u32 ar9271Modes_high_power_tx_gain_9271[][5] = {

looks like we need a way of forcing the card into high power mode.

also, grep through backports directory for power offset regarding infamous 5dB returned:

ath/ath9k/eeprom.h:#define AR5416_PWR_TABLE_OFFSET_DB -5 ath/ath9k/eeprom.h:#define AR9287_PWR_TABLE_OFFSET_DB -5 ath/ath9k/ar9003_eeprom.h:#define AR9300_PWR_TABLE_OFFSET 0

maybe setting it back to 0 as it's already set for ar9300 could help too.

could you guys create a complete map of EEPROM so we can know what exactly is and should be set in there?

erikarn commented 8 years ago

hi,

So, the power offset needs to be -5 unless its overridden by something in the EEPROM.

Yeah, can someone please dump the contents out of eeprom? There's an ath9k eeprom entry in debugfs that prints out everything in text format. Could you please attach that?

Thanks!

-adrian

psyborg55 commented 8 years ago

do you know offset of that "something" ?

there are dumps for AWUS036NHA TL-WN721NC and TL-WN722N on kali forums: https://forums.kali.org/showthread.php?28874-ALFA-AWUS036NHA-hacking-EEPROM-via-UART-JTAG

erikarn commented 8 years ago

hi,

Sure, but if you cat a specific file in debugfs, you get the dump in a pretty format.

If someone cats that, then I can go through it and figure out what's going on.

Thanks,

-adrian

On 11 August 2016 at 13:11, psyborg55 notifications@github.com wrote:

do you know offset of that "something" ?

there are dumps for AWUS036NHA TL-WN721NC and TL-WN722N on kali forums: https://forums.kali.org/showthread.php?28874-ALFA- AWUS036NHA-hacking-EEPROM-via-UART-JTAG

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/qca/open-ath9k-htc-firmware/issues/82#issuecomment-239277167, or mute the thread https://github.com/notifications/unsubscribe-auth/ABGl7d_ph2hpYXhdOA38DkqaUC__f-bIks5qe4HxgaJpZM4HLL6H .

olerem commented 8 years ago

Hi :)

cat ath9k_htc/base_eeprom Major Version : 14 Minor Version : 15 Checksum : 51114 Length : 376 RegDomain1 : 33594 RegDomain2 : 0 TX Mask : 1 RX Mask : 1 Allow 5GHz : 0 Allow 2GHz : 1 Disable 2GHz HT20 : 0 Disable 2GHz HT40 : 0 Disable 5Ghz HT20 : 0 Disable 5Ghz HT40 : 0 Big Endian : 0 Cal Bin Major Ver : 0 Cal Bin Minor Ver : 8 Cal Bin Build : 131 TX Gain type : 1 MacAddress : 00:c0:ca:72:6b:17

cat ath9k_htc/modal_eeprom 2GHz modal Header : Chain0 Ant. Control : 0 Ant. Common Control : 286331969 Chain0 Ant. Gain : 0 Switch Settle : 44 Chain0 TxRxAtten : 32 Chain0 RxTxMargin : 0 ADC Desired size : 226 PGA Desired size : 0 Chain0 xlna Gain : 13 txEndToXpaOff : 0 txEndToRxOn : 2 txFrameToXpaOn : 14 CCA Threshold) : 28 Chain0 NF Threshold : 186 xpdGain : 12 External PD : 1 Chain0 I Coefficient : 0 Chain0 Q Coefficient : 0 pdGainOverlap : 4 O/D Bias Version : 4 CCK OutputBias : 3 BPSK OutputBias : 2 QPSK OutputBias : 2 16QAM OutputBias : 0 64QAM OutputBias : 0 CCK Driver1_Bias : 2 BPSK Driver1_Bias : 0 QPSK Driver1_Bias : 0 16QAM Driver1_Bias : 0 64QAM Driver1_Bias : 0 CCK Driver2_Bias : 2 BPSK Driver2_Bias : 0 QPSK Driver2_Bias : 0 16QAM Driver2_Bias : 0 64QAM Driver2_Bias : 0 xPA Bias Level : 2 txFrameToDataStart : 14 txFrameToPaOn : 14 HT40 Power Inc. : 0 Chain0 bswAtten : 0 Chain0 bswMargin : 0 HT40 Switch Settle : 44 Chain0 xatten2Db : 0 Chain0 xatten2Margin : 0 Ant. Diversity ctl1 : 2 Ant. Diversity ctl2 : 6 TX Diversity : 0

psyborg55 commented 8 years ago

so, did somebody tried to figure out what is going on according to the eeprom dump in previous message?

replacing ar9271Modes_normal_power_tx_gain_9271 with ar9271Modes_high_power_tx_gain_9271 i was able to get increased txpower output about 5dB at 150Mbps rate with tl-wn722n

i think this applies to tl-wn722n only since awus036nha is already using high power setting

olerem commented 8 years ago

@psyborg55 can you please describe your setup. What you change, how do you measure. What is the distance between sender and receiver. As match as possible. 5dB difference i get without change any setup, just by moving my self in the room. So actually every object make the difference.

psyborg55 commented 8 years ago

ar9331 router with external antenna was about 1.5m away from the usb port on my notebook to which tl-wn722n was attached. rx rate in openwrt interface 150Mbps, signal level -45dBm. doing a change mentioned in my previous message, recompiling a driver and restarting makes the signal go to -40dBm while still at 150Mbps rate. i was sitting still in front of the notebook so no moving objects around. reverting the change and restarting gave back -45dBm. usb adapter region was changed to US and power limit increased to 30dBm in EEPROM.

erikarn commented 8 years ago

hi,

can someone please at least give me a hex file binary dump of the eeprom contents? :) All the firmware posts have varying forms of dumps and it's all super-inconvienent.

(I have /all/ the kit I need to debug this; just need some eeprom dumps :)

-a

On 28 August 2016 at 04:46, psyborg55 notifications@github.com wrote:

ar9331 router with external antenna was about 1.5m away from the usb port on my notebook to which tl-wn722n was attached. rx rate in openwrt interface 150Mbps, signal level -45dBm. doing a change mentioned in my previous message, recompiling a driver and restarting makes the signal go to -40dBm while still at 150Mbps rate. i was sitting still in front of the notebook so no moving objects around. reverting the change and restarting gave back -45dBm. usb adapter region was changed to US and power limit increased to 30dBm in EEPROM.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/qca/open-ath9k-htc-firmware/issues/82#issuecomment-242970447, or mute the thread https://github.com/notifications/unsubscribe-auth/ABGl7bKydElUM7MsCLPtaG8X0KP7dwFtks5qkXT_gaJpZM4HLL6H .

psyborg55 commented 8 years ago

just did some tests with patched htc driver:

remote AP running NS2 firmware

CH13 RSSI -72dBm at 54Mbps, with increased power would show -67dBm

but

CH239 (2322MHz) RSSI -67dBm with increased power show -51dBm

this is quite a huge difference, is it possible it only happens because of interference clear channel?

also, i could not get the card transmit at full power at 48 or 54Mbps, maybe because of open/closed loop control or some other protection mechanism?

erikarn commented 8 years ago

Hi,

the high TX rates typically have reduced power anyway, due to PA/FEM linearality.

-adrian

On 8 September 2016 at 11:25, psyborg55 notifications@github.com wrote:

just did some tests with patched htc driver:

remote AP running NS2 firmware

CH13 RSSI -72dBm at 54Mbps, with increased power would show -67dBm

but

CH239 (2322MHz) RSSI -67dBm with increased power show -51dBm

this is quite a huge difference, is it possible it only happens because of interference clear channel?

also, i could not get the card transmit at full power at 48 or 54Mbps, maybe because of open/closed loop control or some other protection mechanism?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/qca/open-ath9k-htc-firmware/issues/82#issuecomment-245692333, or mute the thread https://github.com/notifications/unsubscribe-auth/ABGl7fjG9I89FL-QHF8d4-7iXocG3xMuks5qoFMXgaJpZM4HLL6H .

psyborg55 commented 8 years ago

that's true but i've seen some hardware specs where various cards rated 1W have 27dBm output at 54 Mbps. maybe i'll have to mod eeprom on alfa too.. do you know if AR9271/htc driver support ANI ?

erikarn commented 8 years ago

Hi,

I have a spectrum analyser, so I can test out whether it's actually true or not. you have to be careful going and fiddling with that stuff!

-a

psyborg55 commented 8 years ago

i've checked debug output from alfa and it is the same olerem posted. tl-wn722n has some differences:

root@OpenWrt:~# cat /sys/kernel/debug/ieee80211/phy1/ath9k_htc/base_eeprom
       Major Version :         14
       Minor Version :         13
            Checksum :      38964
              Length :        376
          RegDomain1 :      33608
          RegDomain2 :          0
             TX Mask :          1
             RX Mask :          1
          Allow 5GHz :          0
          Allow 2GHz :          1
   Disable 2GHz HT20 :          0
   Disable 2GHz HT40 :          0
   Disable 5Ghz HT20 :          0
   Disable 5Ghz HT40 :          0
          Big Endian :          0
   Cal Bin Major Ver :          0
   Cal Bin Minor Ver :          8
       Cal Bin Build :        109
        TX Gain type :          0
          MacAddress : 00:00:00:00:00:00
root@OpenWrt:~# cat /sys/kernel/debug/ieee80211/phy1/ath9k_htc/modal_eeprom
   2GHz modal Header :
 Chain0 Ant. Control :          0
 Ant. Common Control :  289674257
    Chain0 Ant. Gain :          0
       Switch Settle :         44
    Chain0 TxRxAtten :         32
   Chain0 RxTxMargin :          0
    ADC Desired size :        226
    PGA Desired size :          0
    Chain0 xlna Gain :         13
       txEndToXpaOff :          0
         txEndToRxOn :          2
      txFrameToXpaOn :         14
      CCA Threshold) :         28
 Chain0 NF Threshold :        186
             xpdGain :         12
         External PD :          1
Chain0 I Coefficient :          0
Chain0 Q Coefficient :          0
       pdGainOverlap :          6
    O/D Bias Version :          4
      CCK OutputBias :          5
     BPSK OutputBias :          4
     QPSK OutputBias :          4
    16QAM OutputBias :          0
    64QAM OutputBias :          0
    CCK Driver1_Bias :          4
   BPSK Driver1_Bias :          0
   QPSK Driver1_Bias :          0
  16QAM Driver1_Bias :          0
  64QAM Driver1_Bias :          0
    CCK Driver2_Bias :          4
   BPSK Driver2_Bias :          0
   QPSK Driver2_Bias :          0
  16QAM Driver2_Bias :          0
  64QAM Driver2_Bias :          0
      xPA Bias Level :          1
  txFrameToDataStart :         14
       txFrameToPaOn :         14
     HT40 Power Inc. :          0
     Chain0 bswAtten :          0
    Chain0 bswMargin :         31
  HT40 Switch Settle :         44
    Chain0 xatten2Db :          0
Chain0 xatten2Margin :          0
 Ant. Diversity ctl1 :         13
 Ant. Diversity ctl2 :          9
        TX Diversity :          0
rodizio1 commented 8 years ago

Just saw this discussion.

Not sure if this helps somebody, but I have increased TX power on the TPLINK 722N from ~15mW to ~70mw and on the Alfa AWUSH036NHA from 60mw to around 280mw by changing this part in eeprom_4k,c (Kernel version 4.4.11):

(Probably not good when using different datarates, but I don't need that).

        for (i = 0; i < Ar5416RateSize; i++) {
//              ratesArray[i] -= AR5416_PWR_TABLE_OFFSET_DB * 2;
                ratesArray[i] = 60;
        }

I don't remember if it was 60 or 63 exactly, I later changed it to 58 because the signal shoulders of the OFDM signal looked a little too wide and high. Measurements were done by somebody with an ImmersionRC Power Meter.

Somebody else tried this with a Ubiqity Wifistation-EXT, there this was way too much, power meter showed 800mw and the card was putting out 90% garbage packets probably because the amp was clipping.

BTW, I can also hear the ticking sound when transmitting. It seems to me, like every "tick" is an individual packet, the speed of the ticks change when injection packet per second rate changes.

can someone please at least give me a hex file binary dump of the eeprom contents? :) All the firmware posts have varying forms of dumps and it's all super-inconvienent.

I have Alfa AWUS036NHA, TPLINK 722N and TPLINK 822N V2 dongles here, if you can give me a quick hint or a link on how to do the dump I'll gladly do that (Didn't find any hexdump under /sys/kernel/debug/, debugFS and debugging is enabled for ath9k and ath9k_htc though in Kernel config).

psyborg55 commented 8 years ago

Hi

Thanks for test results, but to be more precise, can you write your configuration?

What OS, kernel and compat-wireless version was used and which wifi mode/channels were these power values measured at? How the packets were transmitted during the tests?

rodizio1 commented 8 years ago

I'm not sure about the compat wireless version, I use the drivers included in Kernel 4.4.11 for the Raspberry Pi downloaded via rpi-source. OS is Raspbian, arm platform.

Wifi mode used was 802.11g with 24Mbit bitrate (forced by patching ath9k_htc firmware, miserably failed at finding out how to make rate selection via radiotap work) packets with 1024bytes payload being injected via pcap.

Exact frequency I don't know, but it was something between 2412 and 2472 Mhz.

Edit: found the pic from the guy that looked at the signal with a spectrum analyzer: This was on 2484MHz with the AWUSH036NHA. My feeling is that it's pretty much maxxed-out when looking at the signal shoulders: http://static.rcgroups.net/forums/attachments/1/8/4/7/9/a9054285-63-rod_awus036nha.PNG

psyborg55 commented 8 years ago

Can you ask the guy to repeat test with eeprom.h variable AR5416_PWR_TABLE_OFFSET_DB set to -11 ? I'm interested will the readings be higher than 280mW.

olerem commented 7 years ago

Finally i got time to play with it. So, it looks like:

I need to find some software which was able to set higher amplification.

erikarn commented 7 years ago

hiya,

ok so the xpabias pin IS being switched on per-packet? Ok, so at least we know the PA is being engaged. Which PA is it? (ie, let's find the datasheet and see what operating modes it has.) Some devices expect some GPIO line to be set in software to turn on/off "higher" power TX modes for some reason.

The relevant fields to double check in the eeprom header for AR9280 are:

for AR9285/AR9271, it's:

That's why I asked for the ath9k debugfs calibration info; that tells us which of the gain tables in the initvals it should be using.

-adrian

erikarn commented 7 years ago

oh, and the modal (2g and 5g) sections:

Those control the RX, TX, idle, BT, etc antenna switch settings, which control the PA/LNA.

-adrian

olerem commented 7 years ago

As far as i know, there is only ar9271 + external PA most used configuration. This ticket targeting only this configuration as well. @erikarn , i would prefer if we limit this issue only for ar9271. Ok? The PA is Skyworks (SiGe) SE2576L / 2576L. http://www.skyworksinc.com/uploads/documents/202428A.pdf

erikarn commented 7 years ago

ok, so this looks straightforward.

Let's look at the antenna switch common, chain0 and txgain values in the ar9271 calibration eeprom.

-adrian

On 6 January 2017 at 09:42, Oleksij Rempel notifications@github.com wrote:

As far as i know, there is only ar9271 + external PA most used configuration. This ticket targeting only this configuration as well. @erikarn https://github.com/erikarn , i would prefer if we limit this issue only for ar9271. Ok? The PA is Skyworks (SiGe) SE2576L / 2576L. http://www.skyworksinc.com/uploads/documents/202428A.pdf

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/qca/open-ath9k-htc-firmware/issues/82#issuecomment-270959208, or mute the thread https://github.com/notifications/unsubscribe-auth/ABGl7Xtg8JlVNy6aMkQBY6FzXlh5rL4Eks5rPnzqgaJpZM4HLL6H .

olerem commented 7 years ago

I retested my measurements with good scope, the XPABIAS is set to 3 volt at the time of packet duration. I would assume PA is working properly and amplification is set to maximum.

j4nn commented 7 years ago

It seems that the Alfa card contains some kind of tx power amplification anomaly - at least in my case there is a jump in signal strength on txpower from 15 to 18, while it continues the original slope at txpower 19.

I have done lots of measurements but only with wifi cards, I do not have a spectrum analyser unfortunately. You can see a measurement graph sample here: alfaawus036nha-txpower-anomaly-ch06-ubqte2

The graph compares Alfa AWUS036NHA with Tplink TL-WN722N, the receiver was Ubiquiti WifiStationEXT, signal going from a living room across kitchen to a bedroom, possibly crossing two concrete walls in a flat. The measurements were scripted, tcpdump was used as a capture tool, patched to support capture timeout for specific time. This allows to monitor a channel and count number of received beacons, so packet loss may also be evaluated. From tcpdump capture files, signal strength average is computed including standard deviation. The results are put to a gnuplot script/graph as you see it.

I believe I've adjusted all thinkable regulatory limits:

The graph shows comparison of original eeprom content (marked as origX) and hacked eeprom content (marked as testX). As you can see this allows further signal strength increase on 18dBm and higher txpower levels in case of the tplink card, while it's orig graph is limited since txpower of 18dBm. Nothing was received in case of tplink since 27dBm. It is similar in case of the alfa card, but the difference is smaller, starts to be visible since 23dBm txpower. The signal drops also since 27dBm in case of the alfa card with modified eeprom, but was still received.

There are two graphs for each case (origX and testX) of each card. It shows that the txpower anomaly of the alfa card is ramdom - it can be and may not be present in both - in the original eeprom and also in the 'test' eeprom cases. I am not sure why alfa2g-ch06-ubqte2-orig4 graph is shifted to higher signal levels, it might be due to it being recorded a bit later, as testing continued to reproduce the txpower anomaly with the original eeprom content.

It is also quite strange that the signal top at the anomaly hill is a bit higher than what can be achieved by removing limits in the eeprom. Could this be caused by a not stable closed loop of the power amp to atheros chip tx power detector because calibration data for frequency piers may not be chosen properly?

olerem commented 7 years ago

Hi, did test was made with same modulation? signal strange and form is different for all modulations.

j4nn commented 7 years ago

I believe so - there was started a hostapd for each test run, with txpower set to 1dBm before start of hostapd and incremented by 1dBm for each measurement point, having hostapd running in background with following config:

driver=nl80211
interface=$IFACE
hw_mode=g
channel=6
beacon_int=100
auth_algs=1
wpa=2
wpa_pairwise=CCMP
ssid=<omitted>
wpa_passphrase=<omitted>

There was tcpdump at the receiver side with filter set to capture only beacons with the expected BSSID, nothing else. The receiver was running the (patched) tcpdump for 2098ms in order to record up to 20 beacons with 102.4ms beacon interval. So assuming beacons from hostapd should have the same modulation, at least for those two cards as they share the same chipset. I have all the capture files available if you need something specific to be checked in them (there is radiotap information present there as -y IEEE802_11_RADIO option was used with tcpdump).

psyborg55 commented 7 years ago

your graph should start from 0, not 1dB since alfaorig1 anomaly should happen when 18dBm is set.

a description of graph parameters and definition of differences between them would also help to better understand some things.

alfaorig4 does not look like an original eeprom, but modified one test

j4nn commented 7 years ago

In my case, I can see the signal boost already at 15dBm txpower and it is there till 18dBm including. Than it drops a bit as visible in the graph. The alfaorig4 test run is actually an original eeprom, even though it is shifted in the graph towards stronger signal levels. It still contains the visible limit imposed by the original eeprom - you can see it goes more or less flat since 21dBm, similar as alfaorig1. Not sure what do you mean that the graph should start from 0dBm - it does actually. Do you mean the measurement should have started at 0dBm? And then in 1dBm steps increses or do you mean to switch immediately to 18dBm?

psyborg55 commented 7 years ago

The alfaorig4 test run is actually an original eeprom, even though it is shifted in the graph towards stronger signal levels. It still contains the visible limit imposed by the original eeprom - you can see it goes more or less flat since 21dBm, similar as alfaorig1.

but it also contain anomaly as alfatest2 at 14dBm

Not sure what do you mean that the graph should start from 0dBm - it does actually. Do you mean the measurement should have started at 0dBm?

yes the measurement. or you can just shift current measurement for -1dB

j4nn commented 7 years ago

Just a side note, I did the measurements with 3 different cards on the receiver side. So I have another two graphs, that were measured in the same run as the graph above. The measurement was done like that each txpower set was measured in sequence for all the three cards on receiver, each capturing for 2098ms time duration. So the graphs do not share exactly the same time for each measured point, but each measuring point is only a bit more than 2 seconds later for the next receiver card. The graphs still share the same setting of the txpower from the same hostapd instance (i.e. each txpower setting was measured by 3 different receiver cards in sequence before advancing to next txpower level).

The signal strength shift up of alfaorig4 test is not present with the two other receiver cards, as you can see here: alfaawus036nha-txpower-anomaly-ch06-askeyc alfaawus036nha-txpower-anomaly-ch06-jjpatp

The other two receiver cards:

It seems the shift-up of the alfaorig4 was specific only for the wifistationEXT receiver case! On the other hand it is quite interesting that these other two receiver cards receive stronger signal from tplink than from the alfa.

j4nn commented 7 years ago

but it also contain anomaly as alfatest2 at 14dBm

yes, this shows that the anomaly is present with both, original and patched eeprom content

yes the measurement. or you can just shift current measurement for -1dB

not sure if that should change anything?

olerem commented 7 years ago

stronger signals should have more echo/reflections. The RX part may choice to take reflected/weak signal instead of the original one.

j4nn commented 7 years ago

Right, that is probably it, since the wifistationEXT is only 1R (no possibility for choice) while askeyc is 2R and jjpATP is 3R?