ath9k_htc AR9271 tx power increase weird problem + debug #82
Comments
|
hiya, so no - the maximum rate power you can program into the chip for each of It sounds like there's a bug somewhere - but it sounds like it does clamp On 24 January 2016 at 09:26, Bruno Duarte notifications@github.com wrote:
|
|
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 RX POWER LEVEL = -62 RX POWER LEVEL = -48 RX POWER LEVEL = -48 RX POWER LEVEL = -48 |
|
Hi, |
|
It's Alfa AWUS036NHA, it has a Skyworks SE2576L power amplifier onboard. |
|
Ok, i had some doubts that amp is correctly set, so may be it is the case. If i see it correctly some gpio should be pulled up to set max power on this amp. |
|
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 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. |
|
hm.. according doc i would expect 3.3V on SE2576L - PIN 2 (EN). I pointed to ar5416SetupTxDesc_20 as example where TX gain is set. |
|
@olerem , I installed latest AWUS036NHA drivers from alfa.com.tw in my Windows XP machine. 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). When you first mentioned this power amplifier, i thought that maybe the power level gap i see in my receiver, when setting
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. |
|
Seems that the power amplifier is working... I've set lowest transmission power
and RX power level on receiver was -70... 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
and RX power level is instantaneously -40 RX level stayed at the same -40...
the power amplifier is being turned on... btw, when i do the manual pull up, i get this debug message from the driver
|
|
HI, Check the RX rate. I wonder if hte rate is changing and you're seeing a -a |
|
How do i check RX rate @erikarn ? |
|
So, each rate has a different max transmit power. Lower rates have higher So on the receiver, log both the RSSI /and/ the RX rate (Mbit/sec) so we -a On 26 January 2016 at 21:34, Bruno Duarte notifications@github.com wrote:
|
|
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...
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: FYI: the tests i've related here before, were made with original EEPROM data. These EEPROM tests i've made were specific tests. |
|
@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 |
|
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. |
|
@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/ |
|
doing a check of driver code i found this: static void ar9271_hw_init_txgain_ini(struct ath_hw *ah, u32 txgain_type) 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 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? |
|
hi, So, the power offset needs to be -5 unless its overridden by something in Yeah, can someone please dump the contents out of eeprom? There's an ath9k Thanks! -adrian |
|
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 |
|
hi, Sure, but if you cat a specific file in debugfs, you get the dump in a If someone cats that, then I can go through it and figure out what's going Thanks, -adrian On 11 August 2016 at 13:11, psyborg55 notifications@github.com wrote:
|
|
Hi :) cat ath9k_htc/base_eeprom cat ath9k_htc/modal_eeprom |
|
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 think this applies to tl-wn722n only since awus036nha is already using high power setting |
|
@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. |
|
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. |
|
hi, can someone please at least give me a hex file binary dump of the eeprom (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:
|
|
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? |
|
Hi, the high TX rates typically have reduced power anyway, due to PA/FEM -adrian On 8 September 2016 at 11:25, psyborg55 notifications@github.com wrote:
|
|
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 ? |
|
Hi, I have a spectrum analyser, so I can test out whether it's actually true or -a |
|
i've checked debug output from alfa and it is the same olerem posted. tl-wn722n has some differences: |
but won't show mapping to hex addresses of the values. and there isn't any in the pdf doc too. looks like your method of dumping eeprom data did not reveal values for 3rd tplink regdomain - maybe this is debug domain allowing all channels that misidentifies as ?11A? ?
different pcb design is enough to require different eeprom for another card and looks like it can be tuned in many possible and impossible ways. maybe the amp is not set for any amplification, but is only passing data through? maybe it's bias level could be increased? |
|
Well, the pdf was interesting to me as the content of the eeprom is very similar and it describes the purpose. Offsets do not matter really, there are also structs in the pdf and they match with kernel sources more or less. |
|
3rd regdomain refers to ctlindex in tplink eeprom that has no valid data according to your previous comment. bias level should be easily changed, simply replace value at 0xCF. why it's set to 1 in card eeproms that have no xPA i do not know |
|
The |
|
well if there's no driver code to support xPA it might be possible it's configured some other way, GPIO for example. i've used tool for art partitions to dump values, only replaced reg limits with the ones from tplink eeprom this was the output: same values dump from alfa: |
|
Just a side note: bootrom code is in this git repo. So, it is open, |
|
maybe my mod is inaccurate due to differences in eeprom layouts? |
|
@psyborg55: the driver uses only ctl with nonzero index, it's in the for loop in eeprom_4k.c - it ends the loop when ctlIndex is zero in the eeprom: that's why I am not parsing the zeroes there, having the same loop. @olerem: did not know that, still, as it's a rom code, we can only hope, that the vendor used the same source. This may actually be different on each card (like tplink vs alfa vs ubqt). Is there any way we can read out the binary blob of the rom code? Possibly compare it with the build one? |
|
for reference - xpa isn't used any longer in anything seful.
most of the time the tx power offset stuff is all subtly weirdly wrong.
Has someone put together a table showing each TX power setting (in 0.5dBm
increments) versus measured output? the problem is when it crosses into
that secondary tx power curve, right?
…-a
|
Could you please elaborate? How can we set txpower with 0.5dBm increments? I can provide tables for the graphs posted here, there are signal strength measurements for 1dBm txpower increments. But I do not have a spectrum analyser, if you mean that kind of output measurement. I see following problems:
|
shouldn't that refer to xPA steps e.g from 1 to 2 ? |
|
It seems to me that output power is under the control of power detector closed loop - there are PDADC voltage levels set that correspond to output power in 0.5dBm steps, the programmed table has 128 pwr/voltage entries, the table is split in two, first half corresponds to power detector gain0 and the second half to PD gain1, the split is not in the middle, the split point is calculated by the driver and few other settings in the eeprom: pdGainOverlap_t2 and calculated gainBoundaries[]. Check this comment to see the behavior - the second gain was changed by factor 2 (as 0x0c was switched to 0x0a in xpdGain mask) making the voltage levels insufficient for target power and so the txpower jumps to the flat top when the PD gain is switched to the second one. Check the pdf pointed above, it is described on page 14 and 15. |
|
hi,
yes. it's this. There's multiple (up to two now I think?) PDADC voltage <->
dBm curves in 0.5dBm steps. The curves typically overlap. The table has an
offset compared to AR5416->AR9160 because at least starting with ar9280 the
target tx power starts at -5dBm and not 0 dBm. (You can't accurately
transmit /at/ 0dBm; they just gave the target TX power programming more
headroom.)
Then starting with AR9285 the power control changed a little bit more; the
AR9271 is effectively an AR9285 + AR7010 with some other little bits and
pieces.
Then there's a power table offset that takes into account what the output
PA is. Some XPAs have a couple of gain settings; others can be enabled for
TX but have no gain. So there's a couple of bits that run out of the chip
to control whether to use the first or second XPA gain config; then
external chips can determine which does what. (look for "switch table"..)
I'm kinda at the point where I'll take loaner AR9271 units to plug into a
spectrum analyser here and debug whats going on. I'm actually kitted up
here to do TX power calibration. :-) So, which NICs should I either acquire
and/or get donated?
Thanks!
…-adrian
On 28 October 2017 at 13:33, j4nn ***@***.***> wrote:
It seems to me that output power is under the control of power detector
closed loop - there are PDADC voltage levels set that correspond to output
power in 0.5dBm steps, the programmed table has 128 pwr/voltage entries,
the table is split in two, first half corresponds to power detector gain0
and the second half to PD gain1, the split is not in the middle, the split
point is calculated by the driver and few other settings in the eeprom:
pdGainOverlap_t2 and calculated gainBoundaries[].
It looks like the chip adjusts the output power to meet the requested
target power for used transfer rate, using the power detector and voltages
set in it.
Check this comment
<#82 (comment)>
to see the behavior - the second gain was changed by factor 2 (as 0x0c was
switched to 0x0a in xpdGain mask) making the voltage levels insufficient
for target power and so the txpower jumps to the flat top when the PD gain
is switched to the second one.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#82 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABGl7f7worCM0LRgCbZHjAhrw1cte-pbks5sw4-BgaJpZM4HLL6H>
.
|
|
I would be interested to see proper measurements for these units (that I have collected;-)
|
|
Ubiquiti WiFiStation EXT is interesting particularly because the external amp used there does not have the Power Detector Output signal like it is the case with the Alfa. |
|
Hi,
Check to see if it's using the open loop power control. It's a bit set
somewhere in the EEPROM.
…-adrian
|
|
Hi, I am afraid that this bit is not present in the 4k eeprom - it is not in the ar5416_eeprom_4k struct (which has different base header than ar5416_eeprom_def struct, in which the bit is there). I think I read somewhere that the open loop means the output power is not directly measured for the amplification adjustments, while the closed loop means, the output power is really sampled on the RF output. I have the case of open loop power control with the jjplus JWX6082 mini PCIe card (3T3R Atheros AR9390) - it has entirely different calibration setup in the eeprom. The open loop seems to use temperature sensor instead of sampling the output signal directly. |
|
Hi,
So the AR9380 and later 11n parts are all open loop power control. I think
the 11ac parts flipped back to close loop.
…-adrian
|
|
Hi, I've improved my measurements scripts, now transmitting and receiving is done by multiple cards at the same time, so we can compare under the very same interference conditions:
This allows easy parsing of tcpdump captured data, having just one file for each receiving card, containing all transmitting beacons from all tx cards for all txpower levels, having txp level recorded in the packets' SSID. As receivers are receiving at the same time we can compare how the very same data and corresponding signal levels were viewed by different receiver cards. I've used channel 8 for the tests as that channel looked the most free here with regard to possible interference (including nearby channels). A hostapd for each transmit card is started one after each other, using The results are interesting, but a bit confusing: we have a new winner - the alfa5g card (but only if the data is received by tplnk2) - comparing the alfa5g-test with alfa5g-orig shows the signal level increase is probably around the expected 12dBm: but it's not clear on the graphs from the other receiving cards - here ubqte2 receiver shows that winner is ubqte1-test. And visibly lower are tplink-test, alfa5g-test and ubqte1-orig having practically the same max level, followed by a bit lower alfa2g-test : The jjplus receiver shows that the most powerful were tplink-test with ubqte1-test both having the same max signal level, while alfa5g-test is visibly lower (on the same level with ntgear-test): And the confusion is even worse with askeyc as the receiver - that one shows nearly the same max signal level for alfa5g-test, ubqte1-test and tplink-test: Please also note in the above graphs, how ubqte2 nicely receives ubqte1, while tplnk2 receives tplink-test quite badly (losing there), while tplink-test is received greatly on askeyc (nearly at winning level) and jjplus (being one of the winners there). The graphs also show again the previously described alfa2g txpower anomally - it's level is also interesting, comparing it to the other cards (and to it's own signal level corresponding to max /not clamped/ txpower level, i.e. the 26dBm). As all these measurements are relative - it would be interesting to know, what txpower is really on the RF output of any of those cards - for example the very common tplink - the txpower from spectrum analyser with original and with patched eeprom (on 26dBm txpower limit level set) would be great. Not sure what can be concluded from the above tests - it looks like the high power expensive cards from alfa perform quite similar to tplink if the eeprom limitations are removed, at least in case of the most receivers (in 3 out of 4)? |
|
you will get regression with tplink if try you to patch it to more than 23dBm, both on windows and linux |
|
I am not sure what you mean exactly? |
|
i know that i even managed to patch the eeprom in a way that setting the power over 26dBm doesn't crash the signal. but highest output power would help only if used 1Mbps rate. at 23dBm rate power for 6-24 and 20dBm for 54, bandwidth test on both windows and linux was about 90Mbps, if increased for only 1dBm there is a drop to 70Mbps |
|
That is something I did not test yet. But I understand that higher rates need to have lower power. I am wondering what did you change to avoid the drop for txpower over 26dBm, while still getting the signal even stronger? |
|
it wasn't stronger. it was just capped at 26 (i put 26 as target power) even if your driver set 30 or 27 as default. i only tried with tplink. can you describe how you shift +12dB power in rt2x00 driver? |
|
This is maybe getting a bit off topic - this issue should be about the AR9271 chipset, particularly the alfa AWUS036NHA txpower anomaly. |
|
no |
|
can driver load eeprom from 24C32 eeprom instead of 24C08? |
|
No new developments on this? I confirmed that three ways:
At a setting of 16 dBm the card consumes about 3.3 watts which drops down to less than half when it's set above 16. Setting to 20 or 30 doesnt make any difference. I mean i can live with that since i know where the sweet spot is, but seeing how many people try to coax their cards up to 30 dBm with regulatory hacks and driver patches while it wont do anything at all.. Besides, i think this should be further analyzed and fixed because it could lead to people operating their cards illegally unintentionally. |
|
Possible than full power permitted become luck of power because also
reciever consume.
среда, 7 августа 2019 г. пользователь alismatales <notifications@github.com>
написал:
… No new developments on this?
I ran into this bug as well. I have 2 of the AWUS036NHA with the Atheros
AR9271 chipset and with some experimentation i figured out that it has the
highest transmit power at the setting of 16-17 dBm, it while it reduces
considerably when you set it higher.
I confirmed that three ways:
1. The signal level reported by an access point it is connected to (tp
link router running openwrt)
2. Power consumption measured by a USB amp meter
3. Using the second AWUS cards spectrum analysis capability with
https://github.com/bcopeland/speccy
<https://github.com/bcopeland/speccy>
At a setting of 16 dBm the card consumes about 3.3 watts which drops down
to less than half when it's set above 16.
Setting to 20 or 30 doesnt make any difference.
I mean i can live with that since i know where the sweet spot is, but
seeing how many people try to coax their cards up to 30 dBm with regulatory
hacks and driver patches while it wont do anything at all..
Besides, i think this should be further analyzed and fixed because it
could lead to people operating their cards illegally unintentionally.
I cant measure the exact power transmitted, but i kinda doubt that it is
only sending actual 40 mW at a setting of 16 dBm, when the card consumes
over 3 watts at that setting and it even makes my 2.4 Ghz mouse and
keyboard unusable in the same room.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#82?email_source=notifications&email_token=AIBWFOMSYHOPKV7GSRK5AVLQDKKD5A5CNFSM4BZMX2D2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3X2W6A#issuecomment-519023480>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AIBWFOKAELD7PYOGCHL5APLQDKKD5ANCNFSM4BZMX2DQ>
.
|
brunoaduarte commentedJan 24, 2016
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) dBmiwconfig wlan0 set txpower (from 18 to 23) dBmHere are the measurements with more detailed info
https://docs.google.com/spreadsheets/d/1Ad3AoFaqREGViFPtKFfQzRQvgilnv9e008ltYJlwHG8/edit?usp=sharing
Some considerations:
Questions:
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
The text was updated successfully, but these errors were encountered: