Modify

Opened 2 years ago

Last modified 18 months ago

#20369 reopened defect

Xiaomi mini Wireless signal is very weak

Reported by: rexchou Owned by: developers
Priority: high Milestone: Chaos Calmer 15.05
Component: kernel Version: Trunk
Keywords: Cc:

Description

Openwrt work in Xiaomi mini wireless signal is very weak

Attachments (0)

Change History (65)

comment:1 Changed 2 years ago by anonymous

confirm. 2.4 very weak, 5G 15-20% less than with factory fw.

comment:2 Changed 2 years ago by AndreiM

I may have fixed it with a change to MIWIFI-MINI.dts (see https://github.com/airend/openwrt/commit/cb717694914a4fc62e2aaf5ff6bda65b5d164e16)

 				ralink,group = "i2c", "rgmii1";
 				ralink,function = "gpio";
 			};
+			pa {
+				ralink,group = "pa";
+				ralink,function = "pa";
+			};
 		};
 	};
 

comment:3 Changed 2 years ago by anonymous

great, from 60% the signal jumped to 90%. this fixes 2.4G wifi. maybe there is no enabled PA for 5G wifi too so we don't need to use driver hack?

comment:4 Changed 2 years ago by AndreiM

Sorry, what driver hack? P.S. I have submitted a patch to openwrt-devel and @blogic.

comment:5 Changed 2 years ago by anonymous

5GHz wifi has the same weak signal, it has been improved with driver hack in https://dev.openwrt.org/changeset/46519/ but does not work as expected. so i thought there should be a way to enable 5GHz PA too.

another thing, 2.4GHz shows very low received signal strength in router too, mostly between -90 and -105 dBm. maybe there is LNA disabled also?

comment:6 Changed 2 years ago by AndreiM

Got worried when you said hack ;-) In my use, the mt76 signal strength has been fine, surprisingly so, but the bad bug there is with A-MPDU. Either way, only now the 2.4 GHz levels are in the same ballpark, after +15 in SNR with this change.

comment:7 Changed 2 years ago by anonymous

before the 46519 change mt76 radio has about 50% signal strentgh, txpower can be changed.

after the change it gives about 68% signal strength, if you change txpower down to 0dBm it gives about 50% so this indicates the driver does not function properly.

also at 2.4GHz the throughput is very low, in HT40 mode i'm getting no more than 30Mbps measured with iperf, probably because LNA is not enabled.

i have looked through mt7620.c and mt7620.h files and LNA definitions are missing, there are some in rt305x. files but the values are different and i didn't try to change anything cause i don't know how the LNA bits in the .h file are related to the pin numbers in .c file

comment:8 follow-up: Changed 2 years ago by AndreiM

Right, the mt76 will suffer improvements, I'm sure; there are good people working on it, alas too few…

Digression aside, yes, the 2.4 GHz throughput is very low. Even now (50-80% faster), it behaves more like 11g :-( I think all the PA/LNA magic happens in the `pinctrl` driver, where rt305x has hooks for both PA and LNA, whereas mt7620 only has support for the former. We could attempt to mirror the LNA stuff (e.g., RT3352_GPIO_MODE_LNA -> MT7620_GPIO_MODE_LNA, rt3352_lna_func -> lna_grp, etc), but the major piece of information missing is the content of lna_grp[] = { FUNC("lna", 0, ?, ?) }… Looking at the MT7620 data sheet, I think some sort of LNA exists, although people claim no external PA or LNA.

At this point, I only know that I increased my received signal strength from very low to usable (about +15 in SNR); if we manage something similar for LNA, it'd be great. We just need to find the right pin_first & pin_count

Last edited 2 years ago by AndreiM (previous) (diff)

comment:9 Changed 2 years ago by anonymous

the specs say that the chip has integrated LNA/PA, in that case external LNA/PA are not used?

i am also looking at the datasheet where pins 18 and 19 are described as ANT_TRN/ANT_TRNB and i notice that 4 pins are reserved only for PA while in rt3352 there are 2 pins for PA and 2 for LNA.

and i still don't get it what the definitions in mt7620.h are for since it has only pin 20 defined, and according to mt7620.c all 4 pins are enabled (18-21)

once we find lna pins, does it have to be declared in .dts file as you did with pa?

comment:10 Changed 2 years ago by AndreiM

I don't know enough, so confused as well, but I think 18…18+4 are the actual pins as you found, MT7620_GPIO_MODE_PA being just a shift for the pa group. So, maybe that's the most we can do if LNA & PA are a combo. If I understand correctly, pins 18-19 are GPOs, so we're only activating 20-21? Either way, based on empirical evidence, something was off before, and it's on now ;-)

comment:11 Changed 2 years ago by anonymous

you are right, only 20 & 21 are activated. so the

+static struct rt2880_pmx_func pa_grp[] = { FUNC("pa", 0, 18, 4) };

should be changed to

+static struct rt2880_pmx_func pa_grp[] = { FUNC("pa", 0, 20, 2) };

maybe there's something else we're missing, looking at the programming guide (http://www.anz.ru/files/mediatek/MT7620_ProgrammingGuide.pdf) there are also polarity settings for these pins, maybe they're no set properly?

comment:12 Changed 2 years ago by anonymous

and to update iperf test results: first i thought 2nd channel is automatically switched to upper/lower based on primary selected channel since there is no option in luci anymore to choose upper or lower and didn't notice it was actually stuck at HT20.

now on channel 3 i'm getting over 80Mbps at 5 meter distance through one thick wall when sending data and only about 35Mbps when receiveing so this clears any doubts: LNA must be enabled for 2.4G wifi to function properly.

since the reception is fine for 5G wifi we should try to figure how to enable it's PA, i wonder would it work the same way as for 2.4G since it's connected via pci interface?

comment:13 Changed 2 years ago by anonymous

here is the datasheet for 5G mt7612e chip http://sourceforge.net/p/wive-ng/wive-ng-rtnl/ci/ead72aaa747ff859ebaed772bc8000e84fef82f7/tree/docs/DataSheets/MT7612E.pdf?format=raw

looks like GPIOs 13 and 14 need to be toggled in IO_MODE 7 to enable PA

unfortunately i don't see any LNA GPIOs in mt7620a datasheet, it could be that LNA is enabled by CPU itself rather than by GPIO pin

comment:14 Changed 2 years ago by nbd

  • Resolution set to fixed
  • Status changed from new to closed

fix committed in r46891

comment:15 Changed 2 years ago by João

How to install / change the MIWIFI-MINI.dts ??

Thanks.

comment:16 Changed 2 years ago by anonymous

With the last trunk edition r47104 (05-Oct-2015) the wireless signal is very weak.

comment:17 Changed 2 years ago by anonymous

r47149 2.4GHz wireless weak. 5GHz no change.

comment:18 Changed 2 years ago by anonymous

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:19 Changed 2 years ago by maxzerker@…

I've the same issue on r47168

comment:20 follow-ups: Changed 2 years ago by anonymous

Anyone tried latest 14-Oct-2015 16:25 build?

comment:21 follow-up: Changed 2 years ago by anonymous

People commenting after the ticket was closed, and without any useful information: you're not helping the developers at all… You can easily track any relevant changes at: https://dev.openwrt.org/log/trunk/target/linux/ramips. As you can see, nothing after r46891 touches upon this issue.

Now, in case it wasn't obvious, this ticket was mostly about the 2.4 GHz radio (mt7602), and the referenced fix definitely improved things there. If that's not your experience, provide statistically relevant signal strengths before and after. As of now, both 2.4 and 5 GHz radios have comparable strengths (in my case, roughly 62-65 dBms at 12 m).

Finally, you cannot reasonably expect a diminutive $27 AP to perform like one with discrete external amplifiers, especially using the 11n radio on the SoC. The 11ac radio has enough bandwidth, and the 'mt76' driver performs rather well nowadays.

comment:22 in reply to: ↑ 20 Changed 2 years ago by anonymous

Replying to anonymous:

Anyone tried latest 14-Oct-2015 16:25 build?

The wireless signal 2.4GHz is very weak.

comment:23 Changed 2 years ago by anonymous

the signal strength is weaker and unstable, LNA still not working and for 5GHz the signal strength never was at max with mt76 driver.

comment:24 Changed 2 years ago by anonymous

Can somebody pls post /etc/config/wireless you're testing with?

Any version i try ( latest trunk/imagebuilder/compile openwrt from source) gives me like 18% strength on n and 0% on ac.

Thanks a lot in advance!

comment:25 follow-up: Changed 2 years ago by augustus_meyer@…

Having many disconnects on 11g/n, I found out:

  • re-auths (because of disconnects ?) happen more often during time of idle client (power- save on router?)
  • using "Very dirty hacks" in /lib/netifd/hostapd.sh I edited

disable_pmksa_caching=0 !Default: 1
set_default disassoc_low_ack 0 !Default: 1
DELETED: okc=0 !Default: present

comment:26 in reply to: ↑ 20 Changed 2 years ago by anonymous

Replying to anonymous:

Anyone tried latest 14-Oct-2015 16:25 build?

many re-auths (because of disconnects ?)

https://forum.openwrt.org/viewtopic.php?pid=297229#p297229

comment:27 in reply to: ↑ 25 Changed 2 years ago by augustus_meyer@…

Replying to augustus_meyer@…:

Having many disconnects on 11g/n, I found out:

  • re-auths (because of disconnects ?) happen more often during time of idle client (power- save on router?)
  • using "Very dirty hacks" in /lib/netifd/hostapd.sh I edited

disable_pmksa_caching=0 !Default: 1
set_default disassoc_low_ack 0 !Default: 1
DELETED: okc=0 !Default: present

This improved my situation.

comment:28 in reply to: ↑ 21 Changed 2 years ago by anonymous

Replying to anonymous:

People commenting after the ticket was closed, and without any useful information: you're not helping the developers at all… You can easily track any relevant changes at: https://dev.openwrt.org/log/trunk/target/linux/ramips. As you can see, nothing after r46891 touches upon this issue.

the newer kernel might be the cause

Now, in case it wasn't obvious, this ticket was mostly about the 2.4 GHz radio (mt7602), and the referenced fix definitely improved things there. If that's not your experience, provide statistically relevant signal strengths before and after. As of now, both 2.4 and 5 GHz radios have comparable strengths (in my case, roughly 62-65 dBms at 12 m).

2.4 varies between 80% and 90% while 5GHz is 71% at most, usually about 65-67% and while transfering data it falls down to 62% sometimes even at 58%. so the strengths are not comparable.

Finally, you cannot reasonably expect a diminutive $27 AP to perform like one with discrete external amplifiers, especially using the 11n radio on the SoC. The 11ac radio has enough bandwidth, and the 'mt76' driver performs rather well nowadays.

the AP price has nothing to do with this. i can assure you that. because with proprietary drivers both wlans give between 80% and 90% signal strength. to be even more sure about this i observed displayed signal strength on my notebook for 5GHz and i noticed this interesting fact: in rare ocasions when connecting to 5GHz network i get 82% of signal strength at the moment the card connects and only a second later it drops to 70% or 68%, probably it gives full strength for a short time until the radio is wrongly recalibrated due to the bug somewhere in mt76 code or missing PA trigger.

comment:29 follow-up: Changed 2 years ago by augustus_meyer@…

2.4 very bad on my Xiaomi-mini.
cat /sys/kernel/debug/ieee80211/phy1/statistics/*
2601
0
0
0
wlan1 ESSID: "blablabla"

Access Point: F0:B4:29:18:5E:0D
Mode: Master Channel: 1 (2.412 GHz)
Tx-Power: 20 dBm Link Quality: 23/70
Signal: -87 dBm Noise: unknown
Bit Rate: 144.4 MBit/s
Encryption: WPA2 PSK (CCMP)
Type: nl80211 HW Mode(s): 802.11bgn
Hardware: unknown [Generic MAC80211]
TX power offset: unknown
Frequency offset: unknown
Supports VAPs: yes PHY name: phy1

root@OpenWrt:/etc# cat openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='Bleeding Edge'
DISTRIB_REVISION='r47249'
DISTRIB_CODENAME='designated_driver'
DISTRIB_TARGET='ramips/mt7620'
DISTRIB_DESCRIPTION='OpenWrt Designated Driver r47249'
DISTRIB_TAINTS=

config wifi-device radio1

option type mac80211
option channel 1
option hwmode 11g
option path '10180000.wmac'
option htmode HT20

option country 'DE'

config wifi-iface

option device radio1
option network lan
option mode ap
option ssid blablabla
option encryption 'psk2+ccmp'
option key ''

comment:30 in reply to: ↑ 29 Changed 2 years ago by augustus_meyer@…

Distance about 3m between notebook (Win7) and Xiaomi-mini, line of sight.

comment:32 Changed 2 years ago by anonymous

it is already off, need to turn it on somehow

comment:33 Changed 2 years ago by anonymous

can somebody please try this patch and check 5GHz radio?

--- /home/ubuntu/Desktop/mt76.h	2015-10-08 20:38:26.000000000 +0200
+++ mt76.h	2015-11-13 11:00:13.494813000 +0100
@@ -44,6 +44,8 @@
 
 #define MT_CALIBRATE_INTERVAL	HZ
 
+#define MT7612_GPIO_MODE_PA	13
+
 #include "regs.h"
 #include "util.h"
 #include "mac.h"
--- /home/ubuntu/Desktop/main.c	2015-10-08 20:38:26.000000000 +0200
+++ main.c	2015-11-13 11:00:12.198807000 +0100
@@ -12,6 +12,16 @@
  */
 
 #include "mt76.h"
+#include <asm/mach-ralink/pinmux.h>
+
+static struct rt2880_pmx_func pa_grp[] = { FUNC("pa", 0, 13, 2) };
+
+static struct rt2880_pmx_group mt7612e_pinmux_data[] = {
+	GRP("pa", pa_grp, 1, MT7612_GPIO_MODE_PA),
+	{ 0 }
+};
+
+rt2880_pinmux_data = mt7612e_pinmux_data;
 
 static int
 mt76_start(struct ieee80211_hw *hw)
@@ -104,7 +114,7 @@ mt76_config(struct ieee80211_hw *hw, u32
 	mutex_lock(&dev->mutex);
 
 	if (changed & IEEE80211_CONF_CHANGE_POWER) {
-		dev->txpower_conf = hw->conf.power_level * 2;
+		dev->txpower_conf = hw->conf.power_level;
 
 		if (test_bit(MT76_STATE_RUNNING, &dev->state))
 			mt76_phy_set_txpower(dev);
@@ -389,7 +399,7 @@ mt76_get_txpower(struct ieee80211_hw *hw
 {
 	struct mt76_dev *dev = hw->priv;
 
-	*dbm = dev->txpower_cur / 2;
+	*dbm = dev->txpower_cur;
 	return 0;
 }
 

comment:34 Changed 2 years ago by anonymous

where do you get the FIELD32 value for TX_PIN_CFG_RFRX_EN in rt2800.h from?

comment:35 Changed 2 years ago by anonymous

no response -> close ticket

comment:36 Changed 2 years ago by anonymous

As I have no 5GHz device, I can only comment to 2.4GHz: And here, I still consider the problem to exist.

comment:37 Changed 2 years ago by anonymous

Leave as reopened

comment:38 Changed 2 years ago by anonymous

https://patchwork.ozlabs.org/patch/436305/

root@OpenWrt:/# rmmod mt76pci && modprobe mt76pci && dmesg
[...]
[   73.620000] pci device driver detached
[   73.630000] mt76pci 0000:01:00.0: no of_node; not parsing pinctrl DT
[   73.630000] ASIC revision: 76120044
[   73.640000] mt76pci 0000:01:00.0: Invalid MAC address ff:ff:ff:ff:ff:ff
[   73.640000] mt76pci 0000:01:00.0: Using random address f6:27:92:58:3a:fd
[   73.680000] ROM patch already applied
[   73.680000] Firmware Version: 0.0.00
[   73.680000] Build: 1
[   73.680000] Build Time: 201406241830____
[   73.710000] Firmware running!
[   73.720000] ieee80211 phy2: Selected rate control algorithm 'minstrel_ht'
[   73.740000] pci device driver attached

Does "no of_node" have something to do with the issue?

comment:40 Changed 2 years ago by nbd

  • Resolution set to fixed
  • Status changed from reopened to closed

comment:41 Changed 2 years ago by anonymous

  • Resolution fixed deleted
  • Status changed from closed to reopened

still weak signal here.

comment:42 Changed 2 years ago by nbd

2.4 ghz or 5 ghz?
rx or tx?
how big is the difference compared to the reference firmware?

comment:43 Changed 2 years ago by anonymous

5Ghz tx gives -55dBm while stock firmware in the same situation give -46dBm on a pc.

2.4 rx weak but tx pretty strong.

comment:44 Changed 2 years ago by augustus_meyer@…

2.4 rx weak< confirmed.

comment:45 Changed 2 years ago by anonymous

Anyone can confirm considerable improvement?
What really puzzles me is that my n-only 5ghz devices can see 5ghz network alright, IIRC non such behaviour was present with truly-enabled AC mode on 5ghz radio.

comment:46 Changed 2 years ago by anonymous

you are right. vistumbler scan detects 5GHz network as n but it was detected as ac before. it is set to ac mode in luci.

comment:47 Changed 2 years ago by anonymous

Actually, it is set to AC in luci. But still, can connect from non-ac devices.

@OpenWrt Designated Driver r47548

comment:48 Changed 2 years ago by anonymous

i was always able to connect to AC with abgn card with 300Mbps speed and abg card with 54Mbps but connecting to N obviously failed with abg card and had some bug with abgn card where throughput drastically decreased. i'll check this again with wireshark.

comment:49 Changed 2 years ago by anonymous

HT Capabilities (802.11n D1.10)
HT Information (802.11n D1.10)

as soon as possible i'll flash an older image and check again. for now it looks like AC is not working with r47929. if someone has different experience let us know.

comment:50 Changed 2 years ago by anonymous

comment from padavan on site: http://4pda.ru/forum/index.php?showtopic=596689&st=4700

W) PA / LNA
Each chip has a WiFi radio transmitter and receiver. To send a signal it must be reinforced through PowerAmplifier (PA) to the level of 20dBm (100mW), the levels vary with the laws of each region. In some WiFi PA chip is embedded in the device may be diluted with a built-like (iPA), and external (ePA). External PA are always well received signal amplifier Low Noise Amplifier (LNA), so if there is ePA, the circuit ePA / eLNA. If you are using a built-iPA, it can be applied iLNA or external chip eLNA.
On a subject:

2.4 radio wired as iPA / eLNA + T / R switch
Radio 5 wired as iPA / iLNA (T / R switch and built-in)

When placed external chip LNA, the input from the WiFi chip should be muted (normal gain LNA 12dB, depending on the characteristics of the particular eLNA), otherwise the LNA will supply high level, which will be distorted. For this purpose the EEPROM registers parameter "External LNA Gain", which tells how much dB you need to reduce the sensitivity of the input to which a signal from the LNA.
When using the internal LNA, it is common practice "External LNA Gain" is not filled in, ie It is the nominal sensitivity. On sabzh factory in EEPROM 5GHz hammered 2dB, it decreases the value of "hearing" at radio, ie the worse the hearing, the worse the AP hearing the client at his disposal and greatly reduces the speed of the link.

the last described is exactly what is happening on 2.4G wifi

comment:51 Changed 2 years ago by anonymous

DESIGNATED DRIVER (Bleeding Edge, r48196)

2.4 Ghz good recive, but so stable
5 Ghz stable, not so good recieve.

Oh how i wish it was qualcomm atheros inside =)

comment:52 Changed 2 years ago by gazambuja

I install last trunk and all work fine (but unstabe). In logread show me all the time this message:

Tue Feb  9 14:10:40 2016 kern.err kernel: [15917.981234] ieee80211 phy1: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840
Tue Feb  9 14:10:40 2016 kern.err kernel: [15917.988959] ieee80211 phy1: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840
Tue Feb  9 14:10:40 2016 kern.err kernel: [15917.996640] ieee80211 phy1: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840
Tue Feb  9 14:10:41 2016 kern.err kernel: [15918.083924] ieee80211 phy1: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840
Tue Feb  9 14:10:41 2016 kern.err kernel: [15918.091624] ieee80211 phy1: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840
Tue Feb  9 14:10:41 2016 kern.err kernel: [15918.099328] ieee80211 phy1: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840

My config/wireless file:

config wifi-device 'radio0'
        option type 'mac80211'
        option channel '36'
        option hwmode '11ac'
        option path 'pci0000:00/0000:00:00.0/0000:01:00.0'
        option htmode 'VHT80'

config wifi-device 'radio1'
        option type 'mac80211'
        option channel '0'
        option hwmode '11g'
        option path 'platform/10180000.wmac'
        option htmode 'HT20'

config wifi-iface 'private2g'
        option device 'radio1'
        option mode 'ap'
        option disassoc_low_ack '0'
        option network 'lan'
        option beacon_int '60'
        option disabled '0'
        option macfilter 'disable'
        option ssid 'mySSID'
        option encryption 'psk2'
        option key 'mypassword'

config wifi-iface 'private5g'
        option device 'radio0'
        option mode 'ap'
        option disassoc_low_ack '0'
        option network 'lan'
        option beacon_int '60'
        option disabled '0'
        option macfilter 'disable'
        option ssid 'mySSID'
        option encryption 'psk2'
        option key 'mypassword'

Some tip here?

comment:53 follow-up: Changed 2 years ago by anonymous

The miwifi mini has no pa at all, and this patch is vaild.I try to detect the power of lna, it is default high with either stock or openwrt firmware.

comment:54 Changed 2 years ago by anonymous

from my understanding: stock fw does not need EEPROM (factory partition to work) but is using internal Efuse that's why the signal is strong.

openwrt doesn't work without EEPROM which might be broken/incorectly calibrated at some offsets.

since my xiaomi mini is already fucked up partialy someone else should make a detailed test of both 2.4G and 5G wifi with both firmwares and in both of the situations: with original EEPROM and with deleted EEPROM.

detailed results could help us understand what is happening in each of the situations.

comment:55 Changed 2 years ago by gazambuja@…

I have a lot of Xiaomi Mini with me, all brand new. If you can sendme by private all the test (Im not a expertice with this), I can help with all test you need:

azambuja AT protonmail DOT ch

comment:56 Changed 23 months ago by anonymous

there is a command failed error when enabling 2.4 wifi

Sun Mar 20 16:15:45 2016 daemon.notice netifd: radio1 (569): command failed: Not supported (-122)
Sun Mar 20 16:15:45 2016 daemon.notice netifd: radio1 (569): Configuration file: /var/run/hostapd-phy1.conf
Sun Mar 20 16:15:45 2016 daemon.notice netifd: radio1 (569): wlan1: interface state UNINITIALIZED->COUNTRY_UPDATE
Sun Mar 20 16:15:45 2016 daemon.notice netifd: radio1 (569): Using interface wlan1 with hwaddr 64:09:80:12:34:56 and ssid "Xiaomi_1"
Sun Mar 20 16:15:46 2016 daemon.notice netifd: radio1 (569): wlan1: interface state COUNTRY_UPDATE->ENABLED
Sun Mar 20 16:15:46 2016 daemon.notice netifd: radio1 (569): wlan1: AP-ENABLED 

comment:57 Changed 23 months ago by ccoder64@…

使用最新版本的https://downloads.openwrt.org/chaos_calmer/15.05.1/ramips/mt7620/openwrt-15.05.1-ramips-mt7620-xiaomi-miwifi-mini-squashfs-sysupgrade.bin
5G信号可以,110% 左右
2G仍然是50%左右,隔墙效果很差
求大神们解决呀~.

comment:58 Changed 23 months ago by anonymous

5G составляет 110% из которых, передавать или принимать или оба? потому что даже если хорошие передачи получить еще слабее и, таким образом, вероятно, производитель ошибка в дизайне.

comment:59 Changed 23 months ago by gazambuja@…

I start a bounty (USD 250) for related bug 22086 on this device, this way we can get full Openwrt working over Xiaomi Mini: https://www.bountysource.com/issues/32309542-no-connection-on-wlan-in-2-4g
If any can help (with more money or solving this issue) I would appreciate.

comment:60 Changed 22 months ago by gazambuja

Distance 1mt/3 feets enviroment with a lot of wifi signals.
Use Wifi Analyzer app over HTC M8 Android 6 to measure.

Format of test:
freq -> best signal / worst signal detected (in 60 seconds of monitoring)

Stock firmware from Xiaomi
2.4 --> -35 / -38
5 --> -39 / -42

Stable version - CC 15.05.01
2.4 --> -57 / -61
5 --> -55 / -58

Trunk - some commit with kernel 4.3 - http://git.openwrt.org/openwrt.git?p=op … ce6ea6df9c
2.4 --> -39 / -56
5 --> -47 / -54

Trunk r49161 (from few days ago... unstable on 2.4G)
2.4 --> -36 / -41
5 --> -48 / -51

Fork of @changeway - https://github.com/changeway/openwrt_CC_for_MiWifi_Mini
2.4 --> -34 / -36
5 --> -45 / -47

comment:61 in reply to: ↑ 53 Changed 22 months ago by anonymous

Replying to anonymous:

The miwifi mini has no pa at all, and this patch is vaild.I try to detect the power of lna, it is default high with either stock or openwrt firmware.

who can tell, if it's really high on both firmware, if the problem is with calibration data that use openwrt or something else. i found some other dts code for lna in other device.

lna-supply = <&vsim>;	/* LNA regulator */

comment:62 Changed 20 months ago by gazambuja

how I can test this for you?
I have Xiamoi Mini with factory firmware, and others with OO trunk.

comment:63 Changed 18 months ago by anonymous

any updates on this so far?!

comment:64 Changed 18 months ago by anonymous

yes. do not buy mediatek products anymore. they are limiting device power intentionally.

comment:65 in reply to: ↑ 8 Changed 18 months ago by anonymous

Replying to AndreiM:

Right, the mt76 will suffer improvements, I'm sure; there are good people working on it, alas too few…

Digression aside, yes, the 2.4 GHz throughput is very low. Even now (50-80% faster), it behaves more like 11g :-( I think all the PA/LNA magic happens in the `pinctrl` driver, where rt305x has hooks for both PA and LNA, whereas mt7620 only has support for the former. We could attempt to mirror the LNA stuff (e.g., RT3352_GPIO_MODE_LNA -> MT7620_GPIO_MODE_LNA, rt3352_lna_func -> lna_grp, etc), but the major piece of information missing is the content of lna_grp[] = { FUNC("lna", 0, ?, ?) }… Looking at the MT7620 data sheet, I think some sort of LNA exists, although people claim no external PA or LNA.

At this point, I only know that I increased my received signal strength from very low to usable (about +15 in SNR); if we manage something similar for LNA, it'd be great. We just need to find the right pin_first & pin_count

Any clue from some leaked MTK driver sources?

Add Comment

Modify Ticket

Action
as reopened .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.