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

j4nn commented 7 years ago

From jjpATP tcpdump of 2437 MHz 11b -62dBm signal -67dBm signal antenna 0 -77dBm signal antenna 1 -64dBm signal antenna 2 I've used the first strength indication, while it follows with level for each antenna separately. Not sure how "compound" signal level is recorded by tcpdump. It might be interesting to use the other levels in graph as well? Or not as that may increase confusion? ;-)

j4nn commented 7 years ago

Here is the binary content of the eeprom_4k struct for the alfa card case (mac addr and checksum was doctored in both, so they work) - captured from ath9k_htc driver on x86_64 architecture:

It may be interesting to see content of eeprom_4k struct for other alfa cards that you have available.

psyborg55 commented 7 years ago

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

but with original eeprom it is present at 17-18dBm. why would it show up at 14-15dBm in such a case?

not sure if that should change anything?

your graph looks wrong! original alfa test from first image shows -74dBm strength for txpower 18dBm and -68dBm for txpower 19dBm. while it is -74dBm for 17dBm and -68dBm for 18dBm since we already made a conclusion it happens at setting txpower of 18dBm

j4nn commented 7 years ago

oh, you mean the small jump between 18 and 19 dBm of txpower? I did not consider that as an anomaly, comparing to the big anomaly between 15 and 18 dBm of txpower. The small "anomaly" is about 5dBm jump (stepping from 18 to 19 txpower), but the big anomaly is about 16dBm jump of signal strength (stepping from 14 to 15 of txpower).

Do you mean that in your case, there is a jump when stepping from 17 to 18, while in my case, there is the small jump when stepping from 18 to 19 and from that your conclusion is that there is a mistake in my measurements and possibly the results should have been shifted by 1dBm txpower?

I adjusted the scripts to measure in 0-30 interval instead of previous 1-30, the results show similar value for 0 txpower as for 1dBm txpower in case of the alfa (so the graph is flat in the beginning from 0 to 3 dBm of txpower). While in case of tplink, the value for 0 txpower is about 2.6 of signal strength lower than for the 1dBm of txpower (so the graph is linear already from 0 txpower in case of the tplink).

I believe the measurements are correct. They show that alfa can have a big anomaly both in orig and test variant of eeprom content (orig4 and test2). And they show that it is nearly linear (except that the small anomaly) also for both eeprom variants (orig1 and test1 measurements). This is to prove the eeprom changes did not cause the anomaly.

The measurement results are different comparing them to the google docs table from @brunoaduarte, where there is a big signal strength jump (of 14dBm diff of signal strength) when stepping from 17 to 18 of txpower. I guess that each alfa piece may behave a bit different?

For me the big jump is randomly present and stays there only between 15 to 18 dBm of txpower. Hmm, it looks like I am not that lucky with my card:-(

psyborg55 commented 7 years ago

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.

wifistationEXT use same driver htc, as alfa and tplink do. did you change wifistationEXT eeprom?

each chip has it's specific gain tables and thus small differences in reception numbers are possible

j4nn commented 7 years ago

I am aware of that. This is the reason I own so many cards - open driver and open firmware. I am using either no changes or changes specific to each card, decision is based on the mac addr from the real eeprom.

psyborg55 commented 7 years ago

They are different comparing to the google docs table from @brunoaduarte, where there is a big signal strength jump (of 14dBm diff of signal strength) when stepping from 17 to 18 of txpower.

there can be a lot of factors, OS/kernel version/driver version should be considered as well as channel/frequency used (look https://github.com/qca/open-ath9k-htc-firmware/issues/82#issuecomment-245692333), receiver specifications and testing conditions.

i've also noticed with original power settings on alfa that there is sometimes 6-7dB difference when going from 17 to 18dBm and some other times 12-16dBm..

j4nn commented 7 years ago

Concerning other channels/frequencies - tested that too. I have graphs for 2312 frequency channel. Not sure if it is worth to post it - they are very similar with the randomness and the shape of the small and big anomaly. The signal strength of the whole graph is shifted though, differently for tplink and for alfa - tplink is stronger on 2312 freq if received by askeyc and ubqte2, weaker when received by jjpATP. The shifting clearly depends on the receiver card.

j4nn commented 7 years ago

Concerning driver version, I am using compat-wireless patched from openwrt (mac80211 2017-01-31-r2) with some other custom patches.

j4nn commented 7 years ago

Well, here it is, the graphs for 2312 frequency channel:

alfaawus036nha-txpower-anomaly-ch2312-ubqte2

alfaawus036nha-txpower-anomaly-ch2312-askeyc

alfaawus036nha-txpower-anomaly-ch2312-jjpatp

psyborg55 commented 7 years ago

graphs for 2312 might be interesting. number of chains on receiver could also have an impact on reception characteristics, if interested in some tests take a look at https://bugs.lede-project.org/index.php?do=details&task_id=1075 but these might not be accurate due to possible hw issues.

j4nn commented 7 years ago

Concerning the small "anomaly", i.e. the small jump when stepping from 18 to 19 dBm of txpower (when the big anomaly is not present) - just wondering, may be it is not an anomaly, but it could be the transition point between two different power detector gains?

Maybe the big anomaly is caused by pdadc calibration setup using the overlapping points related to switch to the other power detector gain, possibly having incorrect values for one of the pd_gain in the overlapping range? If more correct gain pdadc setup is used, small anomaly would be visible, if the less correct gain pdadc setup would be used (in the overlapping range), the big anomaly would be present? Also explaining the randomness of big anomaly presence?

j4nn commented 7 years ago

Please, could you all who own the alfa awus036nha card share what value do you have in eeprom for xpdGain attribute?

cat /sys/kernel/debug/ieee80211/${ALFAPHY}/ath9k_htc/modal_eeprom | grep xpdGain

Particularly @brunoaduarte value would be interesting considering his measurement results. I have 12 there.

j4nn commented 7 years ago

I just tried to change xpdGain from 12 to 10 and it looks like my theory described in this comment is now confirmed: alfa-tplink-xpdgainmask0x0a-ch06-ubqte2 This graph shows xpdgain mask eeprom value when changed to 0x0a instead of 0x0c in case of the alpha card. There are two graphs for alpha and two for tplink (which is just for a reference) in the picture. This shows that sometime the overlapping region activates the second xpd gain already on txpower of 15dBm (as was the less frequent case with the big anomaly) or it is activated on txpower of 19dBm (which was the case of the small anomaly). So with xpdgain mask of 0x0a I get the behavior as @brunoaduarte described, except sometime the jump happens already on 15 txpower. Either he has xpdgain mask set to 0x0a already in the eeprom from vendor or he has different pdadc calibration data in the eeprom resulting with similar behavior.

Now the question is: can we somehow change pdadc calibration data in the eeprom in a way to make the signal strength dependent linearly on the txpower setting, while keeping the preset frequency compensations of the original calibration data?

brunoaduarte commented 7 years ago

Here i have

/sys/kernel/debug/ieee80211/PHY0/ /sys/kernel/debug/ieee80211/PHY1/

but they are both empty...

any ideas, @j4nn ?

j4nn commented 7 years ago

You need to have CONFIG_ATH9K_HTC_DEBUGFS=y in kernel config (or when building wireless drivers). I also have CONFIG_ATH_DEBUG=y.

j4nn commented 7 years ago

It seems the problem comes from calibration setup for PDADC (the setup controls the power detection closed loop behaviour). I've used the alfa's eeprom dump from @brunoaduarte posted here on kali forums to compare with dump of my alfa card. The xpdgain mask eeprom value is the same in both cases, the 0x0c value. But there are differences in the pdadc calibration in the eeprom.

I've tried to visualize the calibration values - I am not sure about the ranges / units, I've divided the pwr from eeprom by 4 and cannot really justify that (I would expect div by 2 instead): pdadc-cal-alfa-vs-tplink

In the visualization you can find middle freq calibration data for tplink, the mentioned above two alfa eeproms and ubqt wifi station ext. While tplink and ubqt have nice graph where part1 and part2 connects, corresponding to the two gains of power detector that are switched between, the alfa cards have that quite strange - the parts do not connect nicely and moreover each gain calibration setup ends with strange value making the final part flat. I guess that the not smooth connection of the two parts in case of alfa cards causes the random anomalities in txpower described above. And also explains a bit different behavior in my case and in @brunoaduarte 's case. I am wondering also about the end value of each pdadc calibration part in case of alfa cards - could that be an artificial power limitation set in PDADC calibration data?

j4nn commented 7 years ago

The PDADC table essentially conveys the calibration information on the power detector feedback voltage as measured by the built-in ADC. The ADC can be used with any combination of up to four gain values (1/2x, 1x, 2x, 4x) to cover a wide dynamic range. PDADC values for all pd_gain values used are spliced at appropriate transition levels to create the 128-entry PDADC table. PDADC values are stored for every 0.5-dB step in output power. At the transition levels, some amount of overlap is maintained for pd_gains both above and below. Transition levels and overlap is programmed into the chip by the driver with the configuration file.

A piecewise linear approximation of the power versus PDADC dependence is stored in the board data. To accurately cover the entire range of output power, calibration information for up to two pd_gain values is stored in the board data.

psyborg55 commented 7 years ago

besides target power that everyone's trying to increase there is also regulatory power ranging from 0x1c7 to 0x1f6. after trying to understand the mess tplink entered into eeprom (there were several different channels in this table without any order that would make sense including channels in 2300-2400MHz range) i've replaced the reg limits with my own values according to art partition dump from ar9331 router. there was noticeable power increase, even with default 20dBm output which still maintained high throughput (90-100Mbps both directions). setting up to 26dBm output was raising power and setting 27dBm or more on some channels would just cut off the signal by 30dB or more. maybe a good heatsink would help.

meanwhile i also made some eeprom mapping, 0x18b to 0x196 should be explored as it is different on alfa (fcc, mkk, etsi) than on tplink(fcc,etsi,??11A)

0x80 Length         u16
0x82 Checksum           u16
0x84 Minor Version      u8
0x85 Major Version      u8
0x88 RegDomain1         u16
0x8A RegDomain2         u16
0x8C MacAddress         hex
0x92 TX Mask            u8
0x93 RX Mask            u8
0x9A Cal Bin Major Ver      u8
0x9B Cal Bin Build      u8
0x9C Cal Bin Minor Ver      u8
0x9D
0x9E
0x9F TX Gain type       u8
0xB8 Ant. Common Control    u32
0xBC Chain0 Ant. Gain       u8
0xBD Switch Settle      u8
0xBE Chain0 TxRxAtten       u8
0xBF Chain0 RxTxMargin      u8
0xC0 ADC Desired size       u8
0xC1 PGA Desired size       u8
0xC2 Chain0 xlna Gain       u8
0xC3 txEndToXpaOff      u8
0xC4 txEndToRxOn        u8
0xC5 txFrameToXpaOn     u8
0xC6 CCA Threshold      u8
0xC7 Chain0 NF Threshold    u8
0xC8 xpdGain            u8
0xC9 External PD        u8
0xCA Chain0 I Coefficient   u8
0xCB Chain0 Q Coefficient   u8
0xCC pdGainOverlap      u8
0xCF xPA Bias Level     u8
0xD0 txFrameToDataStart     u8
0xD1 txFrameToPaOn      u8
0xD2 HT40 Power Inc     u8
0xD3 Chain0 bswAtten        u8
0xD4 Chain0 bswMargin       u8
0xD5 HT40 Switch Settle     u8

0x138 11b 1L-5L 2412 power
0x139 11b 5S 2412 power
0x13a 11b 11L 2412 power
0x13b 11b 11S 2412 power
0x13d 11b 1L-5L 2472 power
0x13e 11b 5S 2472 power
0x13f 11b 11L 2472 power
0x140 11b 11S 2472 power
0x147 11g 6-24 2412 power
0x148 11g 36 2412 power
0x149 11g 48 2412 power
0x14a 11g 54 2412 power
0x14c 11g 6-24 2437 power
0x14d 11g 36 2437 power
0x14e 11g 48 2437 power
0x14f 11g 54 2437 power
0x151 11g 6-24 2472 power
0x152 11g 36 2472 power
0x153 11g 48 2472 power
0x154 11g 54 2472 power
0x156 11n HT20 2412 power
0x157 11n HT20 2412 power
0x158 11n HT20 2412 power
0x159 11n HT20 2412 power
0x15a 11n HT20 2412 power
0x15b 11n HT20 2412 power
0x15c 11n HT20 2412 power
0x15d 11n HT20 2412 power
0x15f 11n HT20 2437 power
0x160 11n HT20 2437 power
0x161 11n HT20 2437 power
0x162 11n HT20 2437 power
0x163 11n HT20 2437 power
0x164 11n HT20 2437 power
0x165 11n HT20 2437 power
0x166 11n HT20 2437 power
0x168 11n HT20 2472 power
0x169 11n HT20 2472 power
0x16a 11n HT20 2472 power
0x16b 11n HT20 2472 power
0x16c 11n HT20 2472 power
0x16d 11n HT20 2472 power
0x16e 11n HT20 2472 power
0x16f 11n HT20 2472 power
0x171 11n HT40 2412 power
0x172 11n HT40 2412 power
0x173 11n HT40 2412 power
0x174 11n HT40 2412 power
0x175 11n HT40 2412 power
0x176 11n HT40 2412 power
0x177 11n HT40 2412 power
0x178 11n HT40 2412 power
0x17a 11n HT40 2437 power
0x17b 11n HT40 2437 power
0x17c 11n HT40 2437 power
0x17d 11n HT40 2437 power
0x17e 11n HT40 2437 power
0x17f 11n HT40 2437 power
0x180 11n HT40 2437 power
0x181 11n HT40 2437 power
0x183 11n HT40 2472 power
0x184 11n HT40 2472 power
0x185 11n HT40 2472 power
0x186 11n HT40 2472 power
0x187 11n HT40 2472 power
0x188 11n HT40 2472 power
0x189 11n HT40 2472 power
0x18a 11n HT40 2472 power
0x18b RegDomain0 mask
0x18c RegDomain0 mask
0x18d RegDomain0 mask
0x18e RegDomain0 mask
0x18f RegDomain1 mask
0x190 RegDomain1 mask
0x191 RegDomain1 mask
0x192 RegDomain1 mask
0x193 RegDomain2 mask
0x194 RegDomain2 mask
0x195 RegDomain2 mask
0x196 RegDomain2 mask (FCC=RegDomain0 MKK=RegDomain1 ETSI=RegDomain2)
0x197 FCC__11B Frequency0
0x198 FCC__11B Frequency1
0x199 FCC__11B Frequency2
0x19a FCC__11B Frequency3
0x19b FCC__11G Frequency0
0x19c FCC__11G Frequency1
0x19d FCC__11G Frequency2
0x19e FCC__11G Frequency3
0x19f FCC__HT20 Frequency0
0x1a0 FCC__HT20 Frequency1
0x1a1 FCC__HT20 Frequency2
0x1a2 FCC__HT20 Frequency3
0x1a3 FCC__HT40 Frequency0
0x1a4 FCC__HT40 Frequency1
0x1a5 FCC__HT40 Frequency2
0x1a6 FCC__HT40 Frequency3
0x1a7 MKK_11B Frequency0
0x1a8 MKK_11B Frequency1
0x1a9 MKK_11B Frequency2
0x1aa MKK_11B Frequency3
0x1ab MKK_11G Frequency0
0x1ac MKK_11G Frequency1
0x1ad MKK_11G Frequency2
0x1ae MKK_11G Frequency3
0x1af MKK_HT20 Frequency0
0x1b0 MKK_HT20 Frequency1
0x1b1 MKK_HT20 Frequency2
0x1b2 MKK_HT20 Frequency3
0x1b3 MKK_HT40 Frequency0
0x1b4 MKK_HT40 Frequency1
0x1b5 MKK_HT40 Frequency2
0x1b6 MKK_HT40 Frequency3
0x1b7 ETSI_11B Frequency0
0x1b8 ETSI_11B Frequency1
0x1b9 ETSI_11B Frequency2
0x1ba ETSI_11B Frequency3
0x1bb ETSI_11G Frequency0
0x1bc ETSI_11G Frequency1
0x1bd ETSI_11G Frequency2
0x1be ETSI_11G Frequency3
0x1bf ETSI_HT20 Frequency0
0x1c0 ETSI_HT20 Frequency1
0x1c1 ETSI_HT20 Frequency2
0x1c2 ETSI_HT20 Frequency3
0x1c3 ETSI_HT40 Frequency0
0x1c4 ETSI_HT40 Frequency1
0x1c5 ETSI_HT40 Frequency2
0x1c6 ETSI_HT40 Frequency3
0x1c7 FCC__11B Power0
0x1c8 FCC__11B Power1
0x1c9 FCC__11B Power2
0x1ca FCC__11B Power3
0x1cb FCC__11G Power0
0x1cc FCC__11G Power1
0x1cd FCC__11G Power2
0x1ce FCC__11G Power3
0x1cf FCC__HT20 Power0
0x1d0 FCC__HT20 Power1
0x1d1 FCC__HT20 Power2
0x1d2 FCC__HT20 Power3
0x1d3 FCC__HT40 Power0
0x1d4 FCC__HT40 Power1
0x1d5 FCC__HT40 Power2
0x1d6 FCC__HT40 Power3
0x1d7 MKK_11B Power0
0x1d8 MKK_11B Power1
0x1d9 MKK_11B Power2
0x1da MKK_11B Power3
0x1db MKK_11G Power0
0x1dc MKK_11G Power1
0x1dd MKK_11G Power2
0x1de MKK_11G Power3
0x1df MKK_HT20 Power0
0x1e0 MKK_HT20 Power1
0x1e1 MKK_HT20 Power2
0x1e2 MKK_HT20 Power3
0x1e3 MKK_HT40 Power0
0x1e4 MKK_HT40 Power1
0x1e5 MKK_HT40 Power2
0x1e6 MKK_HT40 Power3
0x1e7 ETSI_11B Power0
0x1e8 ETSI_11B Power1
0x1e9 ETSI_11B Power2
0x1ea ETSI_11B Power3
0x1eb ETSI_11G Power0
0x1ec ETSI_11G Power1
0x1ed ETSI_11G Power2
0x1ee ETSI_11G Power3
0x1ef ETSI_HT20 Power0
0x1f0 ETSI_HT20 Power1
0x1f1 ETSI_HT20 Power2
0x1f2 ETSI_HT20 Power3
0x1f3 ETSI_HT40 Power0
0x1f4 ETSI_HT40 Power1
0x1f5 ETSI_HT40 Power2
0x1f6 ETSI_HT40 Power3
j4nn commented 7 years ago

The eeprom can be nicely analysed using struct ar5416_eeprom_4k in kernel sources. This is what can be parsed out of tplink eeprom (orig content), concerning the target power and region limits:

ath: Reading from EEPROM, not flash
ath: orig eep txGainType=0
ath: calPierData2G[chain=0][fidx=0] freq=2412(70):
ath:   gidx=0 (13->30) (13->32) (18->40) (43->61) (89->79)
ath:   gidx=1 (38->73) (53->83) (78->94) (119->106) (176->117)
ath: calPierData2G[chain=0][fidx=1] freq=2437(89):
ath:   gidx=0 (0->6) (12->32) (17->40) (46->61) (93->79)
ath:   gidx=1 (38->73) (55->83) (81->94) (122->105) (177->117)
ath: calPierData2G[chain=0][fidx=2] freq=2472(ac):
ath:   gidx=0 (3->7) (10->33) (21->40) (44->62) (93->80)
ath:   gidx=1 (39->73) (54->83) (80->94) (123->106) (177->116)
   CCK[0] 2412 (70): 24 24 24 24
   CCK[1] 2484 (b8): 24 24 24 24
 2GCCK[0] 2412 (70): 24 24 24 20
 2GCCK[1] 2437 (89): 24 24 24 20
 2GCCK[2] 2472 (ac): 24 24 24 20
2GHT20[0] 2412 (70): 24 24 24 24 24 24 20 1e
2GHT20[1] 2437 (89): 24 24 24 24 24 24 20 1e
2GHT20[2] 2472 (ac): 24 24 24 24 24 24 20 1e
2GHT40[0] 2412 (70): 20 20 20 20 20 20 1e 1c
2GHT40[1] 2437 (89): 20 20 20 20 20 20 1e 1c
2GHT40[2] 2472 (ac): 20 20 20 20 20 20 1e 1c
11 FCC     11b[0]: 2412(70)=0:24(24) 2417(75)=1:24(64) 2462(a2)=0:24(24)
12 FCC     11g[0]: 2412(70)=0:21(21) 2417(75)=1:24(64) 2462(a2)=0:22(22)
15 FCC  2GHT20[0]: 2412(70)=0:20(20) 2417(75)=1:24(64) 2462(a2)=0:21(21)
17 FCC  2GHT40[0]: 2422(7a)=0:12(12) 2427(7f)=1:1a(5a) 2447(93)=1:1a(5a) 2452(98)=0:13(13)
31 ETSI    11b[0]: 2412(70)=0:20(20) 2417(75)=1:20(60) 2472(ac)=0:20(20)
32 ETSI    11g[0]: 2412(70)=0:20(20) 2417(75)=1:20(60) 2472(ac)=0:20(20)
35 ETSI 2GHT20[0]: 2412(70)=0:20(20) 2417(75)=1:20(60) 2472(ac)=0:20(20)
37 ETSI 2GHT40[0]: 2422(7a)=0:20(20) 2427(7f)=1:20(60) 2447(93)=1:20(60) 2462(a2)=0:20(20)
ath: ar9271_hw_init_txgain_ini txgain_type=0
ath: eeprom regdomain was 0x809c, using 0x833a instead!
ieee80211 Atheros AR9271 Rev:1

And this is for the Alfa card (orig content):

ath: Reading from EEPROM, not flash
ath: orig eep txGainType=1
ath: calPierData2G[chain=0][fidx=0] freq=2412(70):
ath:   gidx=0 (139->38) (148->58) (166->77) (188->98) (188->118)
ath:   gidx=1 (81->67) (97->89) (125->109) (170->127) (171->137)
ath: calPierData2G[chain=0][fidx=1] freq=2442(8e):
ath:   gidx=0 (138->39) (147->59) (166->79) (189->100) (188->120)
ath:   gidx=1 (80->67) (94->87) (122->109) (171->127) (171->138)
ath: calPierData2G[chain=0][fidx=2] freq=2472(ac):
ath:   gidx=0 (138->40) (148->59) (166->79) (188->100) (187->120)
ath:   gidx=1 (80->67) (92->87) (121->110) (171->127) (171->138)
   CCK[0] 2412 (70): 2c 2c 2c 2c
   CCK[1] 2484 (b8): 2c 2c 2c 2c
 2GCCK[0] 2412 (70): 2e 2c 2a 28
 2GCCK[1] 2437 (89): 2e 2c 2a 28
 2GCCK[2] 2472 (ac): 2e 2c 2a 28
2GHT20[0] 2412 (70): 2e 2e 2c 2c 2a 2a 28 28
2GHT20[1] 2437 (89): 2e 2e 2c 2c 2a 2a 28 28
2GHT20[2] 2472 (ac): 2e 2e 2c 2c 2a 2a 28 28
2GHT40[0] 2412 (70): 2e 2e 2c 2c 2a 2a 28 28
2GHT40[1] 2437 (89): 2e 2e 2c 2c 2a 2a 28 28
2GHT40[2] 2472 (ac): 2e 2e 2c 2c 2a 2a 28 28
11 FCC     11b[0]: 2412(70)=0:3c(3c) 2417(75)=1:3c(7c) 2462(a2)=0:3c(3c)
12 FCC     11g[0]: 2412(70)=0:3c(3c) 2417(75)=1:3c(7c) 2462(a2)=0:3c(3c)
15 FCC  2GHT20[0]: 2412(70)=0:3c(3c) 2417(75)=1:3c(7c) 2462(a2)=0:3c(3c)
17 FCC  2GHT40[0]: 2422(7a)=0:3c(3c) 2427(7f)=1:3c(7c) 2447(93)=1:3c(7c) 2452(98)=0:3c(3c)
41 MKK     11b[0]: 2412(70)=0:3c(3c) 2417(75)=1:3c(7c) 2472(ac)=0:3c(3c) 2484(b8)=0:3c(3c)
42 MKK     11g[0]: 2412(70)=0:3c(3c) 2417(75)=1:3c(7c) 2472(ac)=0:3c(3c)
45 MKK  2GHT20[0]: 2412(70)=0:3c(3c) 2417(75)=1:3c(7c) 2472(ac)=0:3c(3c)
47 MKK  2GHT40[0]: 2422(7a)=0:3c(3c) 2427(7f)=1:3c(7c) 2447(93)=1:3c(7c) 2462(a2)=0:3c(3c)
31 ETSI    11b[0]: 2412(70)=0:3c(3c) 2417(75)=1:3c(7c) 2472(ac)=0:3c(3c)
32 ETSI    11g[0]: 2412(70)=0:3c(3c) 2417(75)=1:3c(7c) 2472(ac)=0:3c(3c)
35 ETSI 2GHT20[0]: 2412(70)=0:3c(3c) 2417(75)=1:3c(7c) 2472(ac)=0:3c(3c)
37 ETSI 2GHT40[0]: 2422(7a)=0:3c(3c) 2427(7f)=1:3c(7c) 2447(93)=1:3c(7c) 2462(a2)=0:3c(3c)
ath: ar9271_hw_init_txgain_ini txgain_type=1
ath: eeprom regdomain was 0x833a, using 0x833a instead!
ieee80211 Atheros AR9271 Rev:1

The graphs I posted before - that was with target power and reg limits maxed out in the eeprom for all the cards (alfa did not put reg limits in eeprom while tplink did), comparing to the orig content. The visualisation in this comment is the data from calPierData2G values. What I am wondering, why the Alfa has similar txpower as tplink if the limits are removed for both - the alfa has an amplifier while tplink does not, right? So why is there so small difference? Maybe the amplifier is not set for max amplification? Concerning the drop after 26dBm - that feels to me like that would be a limit of the atheros chip. The behaviour is the same on all the cards, regardless external amplifier present or not.

j4nn commented 7 years ago

An interesting description of eeprom content can be read in MKG-0375-AR92xxEEPROM.pdf (just google it out).

psyborg55 commented 7 years ago

The eeprom can be nicely analysed using struct ar5416_eeprom_4k in kernel sources.

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

What I am wondering, why the Alfa has similar txpower as tplink if the limits are removed for both - the alfa has an amplifier while tplink does not, right?

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?

j4nn commented 7 years ago

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 tplink regdomain - not sure what you mean? tplink-ctl I am also wondering about the bias level of the external amp in case of the alfa card. But how to increase it?

psyborg55 commented 7 years ago

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

j4nn commented 7 years ago

The 0xCF xPA Bias Level, i.e. modal_hdr->xpaBiasLvl attribute in driver source (eeprom_4k.c) is not used anywhere else than the eeprom dump function. So I am afraid that changing that (in ath9k_htc driver memory copy of the eeprom) would not make any difference. Do you think that the card could use the eeprom content directly in the firmware, using the value? Possibly even in the ROM part of the firmware (which is not open)? I think I already tried to find the use in the firmware source without luck (that does not mean it's not there). To change that would require flashing of the eeprom, that is something I did not try yet (also because I am sceptical about that the firmware is using it before kernel driver).

psyborg55 commented 7 years ago

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:

   Regulatory 2.4GHz : FCC__11B FCC__11G FCC_HT20 FCC_HT40 ETSI_11B ETSI_11G ETSIHT20 ETSIHT40 ???__11A ???__11A ???__11A ???__11A

         Frequency 0 :  2412[1] 2462[11]  2412[1] 2462[11]  2412[1] 2462[11]  2422[3]  2447[8]  2412[1] 2472[13]  2412[1] 2472[13]
        Power|Edge 0 :   48|1     44|2     58|1     19|2     00|0     00|0     00|0     00|0     00|0     00|0     00|0     00|0  

         Frequency 1 :  2336[0]  2336[0]  2333[0]  2334[0]  2332[0]  2333[0]  2318[0]  2390[0]  2332[0]  2332[0]  2332[0]  2332[0]
        Power|Edge 1 :   32|0     32|0     32|0     32|1     00|0     00|0     00|0     00|0     00|0     00|0     00|0     00|0  

         Frequency 2 :  2417[2]     0x00  2417[2]     0x00  2417[2]     0x00  2427[4]  2452[9]  2417[2]     0x00  2417[2]     0x00
        Power|Edge 2 :   53|1     00|0     63|1     34|2     00|0     00|0     00|0     00|0     00|0     00|0     00|0     00|0  

         Frequency 3 :  2400[0]     0x00  2400[0]     0x00  2400[0]     0x00  2390[0]  2319[0]  2396[0]     0x00  2396[0]     0x00
        Power|Edge 3 :   32|1     00|0     32|1     32|0     00|0     00|0     00|0     00|0     00|0     00|0     00|0     00|0

same values dump from alfa:

   Regulatory 2.4GHz : FCC__11B FCC__11G FCC_HT20 FCC_HT40 MKK__11B MKK__11G MKK_HT20 MKK_HT40 ETSI_11B ETSI_11G ETSIHT20 ETSIHT40

         Frequency 0 :  2412[1] 2462[11]  2412[1] 2462[11]  2412[1] 2462[11]  2422[3]  2447[8]  2412[1] 2472[13]  2412[1] 2472[13]
        Power|Edge 0 :   48|1     44|2     58|1     19|2     48|1     44|2     48|1     44|2     48|1     44|2     58|1     19|2  

         Frequency 1 :  2360[0]  2360[0]  2360[0]  2360[0]  2360[0]  2360[0]  2360[0] 2424[3+]  2360[0]  2360[0]  2360[0]  2360[0]
        Power|Edge 1 :   60|0     60|0     60|0     60|1     60|0     60|0     60|0     60|0     60|0     60|0     60|0     60|1  

         Frequency 2 :  2417[2]     0x00  2417[2]     0x00  2417[2]     0x00  2427[4]  2452[9]  2417[2] 2484[14]  2417[2]     0x00
        Power|Edge 2 :   53|1     00|0     63|1     34|2     53|1     00|0     53|1     00|0     53|1     00|0     63|1     34|2  

         Frequency 3 : 2424[3+]     0x00 2424[3+]     0x00 2424[3+]     0x00 2424[3+]  2360[0] 2424[3+]  2360[0] 2424[3+]     0x00
        Power|Edge 3 :   60|1     00|0     60|1     60|0     60|1     00|0     60|1     00|0     60|1     00|0     60|1     60|0
olerem commented 7 years ago

Just a side note: bootrom code is in this git repo. So, it is open,

psyborg55 commented 7 years ago

maybe my mod is inaccurate due to differences in eeprom layouts?

   Regulatory 2.4GHz : MKK__11B MKK__11G MKK_HT20 MKK_HT40 FCC__11B FCC__11G FCC_HT20 FCC_HT40 ETSI_11B ETSI_11G ETSIHT20 ETSIHT40

         Frequency 0 :  2312[0]  2312[0]  2312[0]  2312[0]  2312[0]  2312[0]  2312[0]  2312[0]  2312[0]  2312[0]  2312[0]  2312[0]
        Power|Edge 0 :   60|0     60|0     60|0     60|0     60|0     60|0     60|0     60|0     60|0     60|0     60|0     60|0  

         Frequency 1 :  2412[1]  2412[1]  2412[1]  2412[1]  2412[1]  2412[1]  2412[1]  2412[1]  2412[1]  2412[1]  2412[1]  2412[1]
        Power|Edge 1 :   60|0     60|0     60|0     60|0     60|0     60|0     60|0     60|0     60|0     60|0     60|0     60|0  

         Frequency 2 : 2462[11] 2462[11] 2462[11] 2462[11] 2462[11] 2462[11] 2462[11] 2462[11] 2462[11] 2462[11] 2462[11] 2462[11]
        Power|Edge 2 :   60|0     60|0     60|0     60|0     60|0     60|0     60|0     60|0     60|0     60|0     60|0     60|0  

         Frequency 3 : 2484[14] 2484[14] 2484[14] 2484[14] 2484[14] 2484[14] 2484[14] 2484[14] 2484[14] 2484[14] 2484[14] 2484[14]
        Power|Edge 3 :   60|0     60|0     60|0     60|0     60|0     60|0     60|0     60|0     60|0     60|0     60|0     60|0
j4nn commented 7 years ago

@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:

for (i = 0; (i < AR5416_EEP4K_NUM_CTLS) &&
    pEepData->ctlIndex[i]; i++) {

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?

erikarn commented 7 years ago

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

j4nn commented 7 years ago

for reference - xpa isn't used any longer in anything seful.

Could you please elaborate? From hw point of view, xpa is in the alfa and it is also in the ubqt wifi station ext. But it looks like the xpa is not used/enabled (at least with oss linux driver & fw) in any of those cards, as the signal strength received is close to each other even when the txpower limitations are removed.

How can we set txpower with 0.5dBm increments? I am using following command: iw dev wlan3 set txpower limit 1900 to set 19dBm txpower, but if 1950 is used, it returns command failed: Operation not supported (-95)

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:

psyborg55 commented 7 years ago

between the two power detector gains

shouldn't that refer to xPA steps e.g from 1 to 2 ?

j4nn commented 7 years ago

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

erikarn commented 7 years ago

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 notifications@github.com 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 https://github.com/qca/open-ath9k-htc-firmware/issues/82#issuecomment-337965855 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 https://github.com/qca/open-ath9k-htc-firmware/issues/82#issuecomment-340217989, or mute the thread https://github.com/notifications/unsubscribe-auth/ABGl7f7worCM0LRgCbZHjAhrw1cte-pbks5sw4-BgaJpZM4HLL6H .

j4nn commented 7 years ago

I would be interested to see proper measurements for these units (that I have collected;-)

j4nn commented 7 years ago

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. Not 100% sure about that, but it seems to me, that the ubqt still uses the PDADC closed loop, but the adc voltage is probably measured directly by the atheros chip on it's own output (before going to ext amp).

erikarn commented 7 years ago

Hi,

Check to see if it's using the open loop power control. It's a bit set somewhere in the EEPROM.

-adrian

j4nn commented 7 years ago

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). The ar5416_eeprom_def is used with Netgear WNDA3200 and Panasonic N5HBZ0000055. These two units have it in the base_eeprom like this: OpenLoop Power Ctrl : 0 so closed loop even with these two.

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.

erikarn commented 7 years ago

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

j4nn commented 7 years ago

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 also added a new tplink on the receiver side, so we have easier to get reference on both tx and rx ends.

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 sleep .01 in bash script in between, using txpower of 20dBm. Then tcpdump is started on all remote receiving cards, using filter for beacons only with all the bssid addresses known from transmit cards. Then it waits for 5 seconds to hopefully resolve interference among the transmitters if there is any. Then measuring sequence starts with txpower limit changing from 0 to 30 dBm, sleeping in each txpower step for 0.1234 seconds (i.e. 21 times beacon interval, expecting capture of 20 tagged beacons in each step). This process is run twice, first with 'orig' eeprom setup and then with 'test' eeprom setup (i.e. with increased txpower limits). You can find the tcpdump capture files and resulting gnuplot graphs rendering sources attached here: txpower-comp-xtag.tar.gz To repeat again: the graphs shows transmitting and receiving from the same time, the same packets - only the "orig" and "test" variants were executed in sequence as reload of eeprom modifications are needed (this is to show the limitations from eeprom).

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: txp-tagged-try4-ch08-tplnk2

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 : txp-tagged-try4-ch08-ubqte2

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): txp-tagged-try4-ch08-jjplus

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: txp-tagged-try4-ch08-askeyc

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)? Or is there still any limitation to be found or some setting to activate higher external amplifier gain? It would be also interesting to measure the power of the Alfa AWUS036H card, of which there is a common belief (or myth?) that it has 1W txpower output. I do not have that card for comparison and do not consider one to collect as it become obsolete.

psyborg55 commented 7 years ago

you will get regression with tplink if try you to patch it to more than 23dBm, both on windows and linux

j4nn commented 7 years ago

I am not sure what you mean exactly? If eeprom of tplink is patched (in ram copy) in linux, signal level continues to rise with txpower up to 26dBm - as visible in every graph in my last comment, the black triangle vs red dot (which is limited in eeprom since 16dBm of txpower). I do not know about the behaviour on windows - did not test that. I do not even know how it is with drivers on windows - are they also open source? If not, such testing would need true write in the eeprom to have the changes persistent across different OSes.

psyborg55 commented 7 years ago

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

j4nn commented 7 years ago

That is something I did not test yet. But I understand that higher rates need to have lower power. So my 'test' change of the eeprom is basically finding max value in target power table, calculate difference of that max to reach 60 and add this diff to all target power table values. So decreasing of txpower for higher rates was still kept in the "modified" eeprom, but shifted higher. I plan to use the above graphs to find a top txpower and set the eeprom in a way that it would go flat for higher txpower values (so avoiding the drop for txpower > 26). After that it would be good to test performance of higher rates.

I am wondering what did you change to avoid the drop for txpower over 26dBm, while still getting the signal even stronger? Did you manage that only with tplink or with alfa as well?

psyborg55 commented 7 years ago

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?

j4nn commented 7 years ago

This is maybe getting a bit off topic - this issue should be about the AR9271 chipset, particularly the alfa AWUS036NHA txpower anomaly. The txpower increase in rt2800usb driver is hinted already in the comment, but I am sending you an email with more details. Do you have the AWUS052NH card too?

psyborg55 commented 7 years ago

no

psyborg55 commented 6 years ago

can driver load eeprom from 24C32 eeprom instead of 24C08?

alismatales commented 5 years ago

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

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 wireless mouse and keyboard unusable in the same room.

sergiy213 commented 5 years ago

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 https://github.com/qca/open-ath9k-htc-firmware/issues/82?email_source=notifications&email_token=AIBWFOMSYHOPKV7GSRK5AVLQDKKD5A5CNFSM4BZMX2D2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3X2W6A#issuecomment-519023480, or mute the thread https://github.com/notifications/unsubscribe-auth/AIBWFOKAELD7PYOGCHL5APLQDKKD5ANCNFSM4BZMX2DQ .