Xiaomi MiWifi mini wireless signal question

the image posted at https://forum.openwrt.org/viewtopic.php?pid=349582#p349582 has fixed 2.4GHz wifi. tx path is a bit unstable probably due to trunk issues, but rx now works fine

@psyborg Thanks for sharing dude. I got rid of PandoraBox since was unusable due to the fact that for a mysterious reason the /overlay partition was getting wiped out at each reboot, therefore I didn't even used it at all since bought it.

However I have installed the OpenWrt image you mentioned and I will report back. If somebody smarter than me (me lame!) managed to make some wireless speed transfer both 2.4Ghz and 5Ghz tests as well range performances tests please let me have those and I will compare against with this OpenWrt build this weekend.

Thanks

hwnat in pandorabox is buggy that causes the issue afaik, just disable it. try test build r1597 or (16.10) 2017-01-03 build from downloads.pandorabox.com.cn site.
gonna switch to lede as soon as wireless is fixed.

distance: approx. 5m below the router, through a 50cm wall

2.4G TX max 65Mbps
2.4G RX max 82Mbps
5G TX max 90Mbps
5G RX max 85Mbps

this is without USB device, if using USB device the throughput drops. i've tried using 1.5A power supply instead of original xioami's 1A but the issue persists. so it must be some kind of driver/registers conflict or the CPU simply cannot handle that much traffic while operating an USB device. it is running at 620MHz and so far there seems to be no way of setting higher clocks from breed loader (i've tried contacting hackpascal about this but did not get any reply). probably will just revert ralink bootloader after some more testing

update: with latest ubuntu 16.10 speeds are crap: about 50Mbps TX and 30 RX on both interfaces

suggestions for a lightweight and functional OS like lucid are welcome

wifi range, tested at approx. 8m distance without obstacles

2.4GHz

TX: -42dBm RX: -51dBm

5GHz

TX: -50dBm RX: -65dBm

2.4GHz compared to pandorabox or stock fw has same signal strength with both TX and RX. pandorabox (any of the 3 builds tested) and trunk have quite unstable 2.4GHz TX. stock fw has stable 2.4GHz TX.

5GHz seem to have problem with both iPA/iLNA. disabling TSSI compensation and enabling temperature control gains ~4dB at TX level without throughput regression.

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

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option encryption 'psk2+ccmp'
	option key 'password_here'
	option macfilter 'allow'
	list maclist '00:00:00:00:00:00'
	option ssid 'WIFI 5G NAME HERE'

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

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option encryption 'psk2+ccmp'
	option key 'password_here'
	option macfilter 'allow'
	list maclist '00:00:00:00:00:00'
	option ssid 'WIFI 2G NAME HERE'

LEDE Reboot SNAPSHOT r3472

Not fully stable but usable with the settings above. If I add country code or transmit power value it becomes unstable.

And getting this error from time to time.

Mon Feb 20 04:07:27 2017 kern.err kernel: [53303.575047] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 Mon Feb 20 04:07:27 2017 kern.err kernel: [53303.584492] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 Mon Feb 20 04:07:27 2017 kern.err kernel: [53303.593953] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 Mon Feb 20 04:07:27 2017 kern.err kernel: [53303.603401] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 Mon Feb 20 04:07:27 2017 kern.err kernel: [53303.612847] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 Mon Feb 20 04:07:27 2017 kern.err kernel: [53303.622297] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 Mon Feb 20 04:07:27 2017 kern.err kernel: [53303.631748] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 Mon Feb 20 04:07:27 2017 kern.err kernel: [53303.641192] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2

Speedtest wifi 2g: 6/7m with 2 walls distance 20-25 mbits DL 10-15 mbits UL.
5g seems to be getting capped to 50-60 mbits even if I'm standing next to the router.

Edit1:

All speedtest done with usb drive mounted.

Wired - http://beta.speedtest.net/result/6081768120
2G about 25 ft w/ 2/3 walls - http://www.speedtest.net/my-result/a/2654001492
2G about 30 ft w/ 3/4 walls - http://www.speedtest.net/my-result/a/2654014944
5G about 2 ft next to the router - http://www.speedtest.net/my-result/a/2654037149

Model: Xiaomi MiWiFi Mini
Firmware Version: LEDE Reboot SNAPSHOT r3472

Thanks with your help wireless seems more stable on dir-860l with lede 17.01.0

USB devices seem to cause throughput regression as I've already described: https://github.com/openwrt/mt76/issues/70

it seems to have an impact particularly on TX path since I've managed to get RX 155 Mbps at 5m distance through a concrete wall

patching eeprom at offset 8036 to value 02 will turn on temperature control. according to eeprom guide it is needed to patch 8053 to 57, 8054 to 47, 8055 to BA, 80F2 to 0F, 80F3 to 09, 80F4 to 0D and 80F5 to 10 for full TC operation. in some cases the TX gain could be 1-2dB higher, but it depends on placement of router antennas and signal dispersion - it can get up to 4dB. at this point both TX & RX rates were still 300Mbps, if needed max power patch offsets 8064 8069 806E 8073 8078 807D 8082 8087 808C 8091 8096 809B 80F8 to 2E. that will allow to set txpower of 23dBm which gains extra ~2dB but affects TX rate

This is what I was able to get from the next room (3m~)

but the max real world performance with usb drive is around

and about 80-90mbits ul/dl w/o the usb drive.

exact same dl/ul speeds i get when running iperf single-thread with default setting(openwrt r50082)

increasing buffer length and using 4 parallel streams almost doubles RX throughput, TX not tested yet

@psyborg I'm on the breed bootloader as well and would like to revert to the stock bootloader. Any chance you could share yours?
Another issue I have with this device is when using pandorabox I can't even connect to 2.4GHz wireless and LEDE is stuck in a bootloop... (both 17.01 and nightly)
The stock firmware however has no problems at all...

http://www76.zippyshare.com/v/xmsp8FhI/file.html

1 Like

Any updates on this issue?
Lede 17.01.4
10mbit/sec on 2.4GHz
70mbit/sec on 5GHz
95mbit/sec on through cable.
On stock/pandora firmware I can have about 50mbits over 2.4GHz, and there is no USB device connected. Tried a lot of different combinations of options like rts/fragmentation. Android phone shows link speed 150mbits

Up, wifi not work correctly:

[25263.585308] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[25263.594832] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[25263.604313] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[25263.613746] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[25263.623207] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[26543.858190] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[26543.867717] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[26543.877187] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[26543.886659] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[26543.896117] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2

Does it mean that as you mentioned:
Please reopen this pull request
this patch:

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

this will not fix the issue ?

no, issue not fixing

some problem in NEXX WT3020H ( MediaTek MT7620n )

ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2

Up any news?

please consider money support to my webmoney WMZ purse: Z290111431046 (PP,Bitcoin and others are not an option)

write and post MT7620 devices you use, their exact revision and wikidevi links to these devices

if there is enough interest (and support) i will try to get 4-5 most popular devices and continue to work on stabilizing wifi drivers. (another progress with mini has already been made)

The problem is not solved

Linux mi-mini 4.14.63 #0 Wed Aug 15 20:42:39 2018 mips GNU/Linux
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='18.06.1'
DISTRIB_REVISION='r7258-5eb055306f'
DISTRIB_TARGET='ramips/mt7620'
DISTRIB_ARCH='mipsel_24kc'
DISTRIB_DESCRIPTION='OpenWrt 18.06.1 r7258-5eb055306f'
DISTRIB_TAINTS=''
[ 1393.923791] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[ 1393.933241] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[ 1393.942686] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[ 1393.952130] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[ 1393.961574] ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2