Modify

Opened 2 years ago

Closed 2 years ago

#20343 closed defect (fixed)

luci signal strength reported incorrectly for 5 GHz radio

Reported by: anonymous Owned by: developers
Priority: normal Milestone:
Component: packages Version: Trunk
Keywords: Cc:

Description

for mt7612e device using latest trunk luci shows positive signal value which makes it hard to understand the real received signal strength

Attachments (3)

factory.bin (64.0 KB) - added by anonymous 2 years ago.
MiWiFi Mini EEPROM
hex2off (1.6 KB) - added by AndreiM 2 years ago.
hexdump -C -s 0x8000 mtd2.bin
hex2mtk (1.6 KB) - added by AndreiM 2 years ago.
hexdump -C MT7612E3_EEPROM_layout_20131022_2G5G_iPAiLNA_wTSSI_default_slope_offset.bin

Download all attachments as: .zip

Change History (22)

comment:1 Changed 2 years ago by nbd

which device and openwrt version are you using?

comment:2 Changed 2 years ago by anonymous

xiaomi miwifi trunk r46672

comment:3 Changed 2 years ago by paul.kozlovitch@…

It seems that stock EEPROM is broken, accroding to http://4pda.ru/forum/index.php?showtopic=686221&st=20#entry41511968 Workaround: get reference EEPROM: https://github.com/openwrt/mtk-wifi-gpl/blob/master/eeprom/MT7612E3_EEPROM_layout_20131022_2G5G_iPAiLNA_wTSSI_default_slope_offset.bin and copy some values from your stock EEPROM to that reference one: your MAC (0x8004 - 0x8009), RF Offset (0x803A) and something else at 0x809E, 0x809F

comment:4 Changed 2 years ago by nbd

Can somebody please send me a dump of their eeprom data from this device (without any modifications)?
Maybe I can make the driver detect and deal with this.

Changed 2 years ago by anonymous

MiWiFi Mini EEPROM

comment:5 Changed 2 years ago by AndreiM

They claim you can simply zero out 0x8045, 0x8049, and 0x804D in your factory dump. There's also an automated solution at http://mi.freize.org, and I verified that it does exactly that. Of course, I have yet to patch my mtd2 since it's read-only right now, but I'll report back once I modify MIWIFI-MINI.dts.

Edit: Well, I patched my EEPROM as described above, without bricking my Mini ;-) No Luci here, so hopefully it fixes some of my other issues…

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

comment:6 Changed 2 years ago by anonymous

that is true, but when you select first option that fixes offset then a lot more of eeprom is modified; can you check what's the difference? maybe tx power related or something?

Changed 2 years ago by AndreiM

hexdump -C -s 0x8000 mtd2.bin

Changed 2 years ago by AndreiM

hexdump -C MT7612E3_EEPROM_layout_20131022_2G5G_iPAiLNA_wTSSI_default_slope_offset.bin

comment:7 Changed 2 years ago by AndreiM

There are many differences, as you can see from the attached hexdumps, so I'm wary of bricking my router. Also, I don't speak Russian, and Google Translate is somewhat fuzzy about their Method 1. Are we supposed to replace everything after offset 0x8000 with the MTK stuff (save 0x8004-0x8009, 0x803A, 0x809E, and 0x809F)? Are we sure there's no ePA/eLNA for 5 GHz in the MiWiFi Mini?

Edit: OK, I did it, and something is happening… The patched iPAiLNA EEPROM caps at 14 dBm max, so I reverted 1413f553f866e9ae53871013294c25ff85588cf3, and things seem OK. I also tried the ePAeLNA version, which capped TX power at 8 dBm with the original driver (haven't tried after applying the revert, but maybe I should). Otherwise, the weird timeouts described here still happen no matter what I do.

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

comment:8 Changed 2 years ago by anonymous

thanks for info. i'll try it myself too.

regarding timeouts, i get them randomly on vivid without any driver patches using AR9462 card but the same card on lucid worked perfect without any timeout or connection drop.

comment:9 Changed 2 years ago by anonymous

with patched EEPROM signal strength is weaker and unstable.

comment:10 Changed 2 years ago by anonymous

patched vs. factory EEPROM wifi test!

Client connecting to 192.168.10.2, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[  3] local 192.168.10.1 port 35930 connected with 192.168.10.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec  5.38 MBytes  45.1 Mbits/sec
[  3]  1.0- 2.0 sec  4.75 MBytes  39.8 Mbits/sec
[  3]  2.0- 3.0 sec  5.12 MBytes  43.0 Mbits/sec
[  3]  3.0- 4.0 sec  4.88 MBytes  40.9 Mbits/sec
[  3]  4.0- 5.0 sec  4.38 MBytes  36.7 Mbits/sec
[  3]  5.0- 6.0 sec  4.75 MBytes  39.8 Mbits/sec
[  3]  6.0- 7.0 sec  4.88 MBytes  40.9 Mbits/sec
[  3]  7.0- 8.0 sec  5.12 MBytes  43.0 Mbits/sec
[  3]  8.0- 9.0 sec  5.12 MBytes  43.0 Mbits/sec
[  3]  9.0-10.0 sec  4.38 MBytes  36.7 Mbits/sec
[  3]  0.0-10.0 sec  48.9 MBytes  40.9 Mbits/sec
root@OpenWrt:~# mtd write /tmp/factory factory
Unlocking factory ...

Writing from /tmp/factory to factory ...     
root@OpenWrt:~# reboot
root@OpenWrt:~# Write failed: Broken pipe
ubuntu@ubuntu:~$ ssh root@192.168.5.1
root@192.168.5.1's password: 


BusyBox v1.24.1 (2015-11-22 03:39:10 CET) built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 DESIGNATED DRIVER (Bleeding Edge, r47551)
 -----------------------------------------------------
  * 2 oz. Orange Juice         Combine all juices in a
  * 2 oz. Pineapple Juice      tall glass filled with
  * 2 oz. Grapefruit Juice     ice, stir well.
  * 2 oz. Cranberry Juice
 -----------------------------------------------------
root@OpenWrt:~# iperf -c 192.168.10.2 -i 1
------------------------------------------------------------
Client connecting to 192.168.10.2, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[  3] local 192.168.10.1 port 46189 connected with 192.168.10.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec  6.75 MBytes  56.6 Mbits/sec
[  3]  1.0- 2.0 sec  7.25 MBytes  60.8 Mbits/sec
[  3]  2.0- 3.0 sec  7.38 MBytes  61.9 Mbits/sec
[  3]  3.0- 4.0 sec  7.25 MBytes  60.8 Mbits/sec
[  3]  4.0- 5.0 sec  7.00 MBytes  58.7 Mbits/sec
[  3]  5.0- 6.0 sec  7.12 MBytes  59.8 Mbits/sec
[  3]  6.0- 7.0 sec  7.12 MBytes  59.8 Mbits/sec
[  3]  7.0- 8.0 sec  7.00 MBytes  58.7 Mbits/sec
[  3]  8.0- 9.0 sec  7.12 MBytes  59.8 Mbits/sec
[  3]  9.0-10.0 sec  6.38 MBytes  53.5 Mbits/sec
[  3]  0.0-10.0 sec  70.5 MBytes  59.0 Mbits/sec
root@OpenWrt:~# 

we need to use factory EEPROM!

comment:11 Changed 2 years ago by AndreiM

What do you mean by factory EEPROM? Can you attach the raw image in question, or maybe a hex dump? Either way, those numbers hovering around 60 Mbps are pretty decent; not sure stock OS can do much better.

comment:12 Changed 2 years ago by anonymous

attachment after comment 4 https://dev.openwrt.org/attachment/ticket/20343/factory.bin

original as it came with device.

all those patched EEPROMs give lower throughput.

comment:13 Changed 2 years ago by karlp@…

I believe I'm seeing the same issues, with a xiaomi miwifi mini mt7620a running r47730.

iw station dumps from the 5gig

root@OpenWrt:~# iw dev wlan0 station dump
Station fc:64:ba:a4:3a:8d (on wlan0)
	inactive time:	1220 ms
	rx bytes:	31215
	rx packets:	377
	tx bytes:	48007
	tx packets:	194
	tx retries:	43
	tx failed:	15
	signal:  	51 [51, 49] dBm
	signal avg:	101 [101, -5] dBm
	tx bitrate:	175.5 MBit/s VHT-MCS 4 80MHz VHT-NSS 1
	rx bitrate:	6.0 MBit/s
	expected throughput:	5.53Mbps
	authorized:	yes
	authenticated:	yes
	preamble:	short
	WMM/WME:	yes
	MFP:		no
	TDLS peer:	no
root@OpenWrt:~#

and from the 2.4gig

root@OpenWrt:~# iw dev wlan1 station dump
Station a8:40:41:00:11:e2 (on wlan1)
	inactive time:	460 ms
	rx bytes:	190100
	rx packets:	778
	tx bytes:	194014
	tx packets:	1170
	tx retries:	59
	tx failed:	0
	signal:  	-89 dBm
	signal avg:	-87 dBm
	tx bitrate:	36.0 MBit/s
	rx bitrate:	54.0 MBit/s
	expected throughput:	2.664Mbps
	authorized:	yes
	authenticated:	yes
	preamble:	short
	WMM/WME:	yes
	MFP:		no
	TDLS peer:	no
Station 6c:fd:b9:91:31:92 (on wlan1)
	inactive time:	0 ms
	rx bytes:	797040629
	rx packets:	927716
	tx bytes:	1133050470
	tx packets:	1095138
	tx retries:	296696
	tx failed:	5007
	signal:  	-95 dBm
	signal avg:	-94 dBm
	tx bitrate:	121.5 MBit/s MCS 6 40MHz
	rx bitrate:	54.0 MBit/s MCS 3 40MHz
	expected throughput:	4.357Mbps
	authorized:	yes
	authenticated:	yes
	preamble:	short
	WMM/WME:	yes
	MFP:		no
	TDLS peer:	no
Station 40:b8:37:c5:77:3b (on wlan1)
	inactive time:	4100 ms
	rx bytes:	576161
	rx packets:	4642
	tx bytes:	4033573
	tx packets:	4216
	tx retries:	877
	tx failed:	90
	signal:  	-97 dBm
	signal avg:	-97 dBm
	tx bitrate:	72.2 MBit/s MCS 7 short GI
	rx bitrate:	24.0 MBit/s
	expected throughput:	3.405Mbps
	authorized:	yes
	authenticated:	yes
	preamble:	short
	WMM/WME:	yes
	MFP:		no
	TDLS peer:	no
root@OpenWrt:~#

as requested by jow on irc. Is there still "information required" for this ticket at all?

comment:14 Changed 2 years ago by anonymous

2.4gig is because of LNA missing

comment:15 Changed 2 years ago by anonymous

another comment by padavan:

Heh, I found the bug in 7612 when calculating a driver RSSI, when entered in the EEPROM non-zero "External LNA Gain".

Function ConvertToRssi (cmm_sync.c).

All chips to 7612, External LNA Gain consisted of 8 bits, and asking a positive number (at least more so in 7610). In 7612 he entered the bit 7, which sets the + or -. For example, 0x82 means the gain of + 2dB.

The ANDES firmvar bytes transmitted in full, but in function ConvertToRssi forgot to cut the bits 7 and calculating a RSSI is exhausted to -126 (0x82 signed for CPU) instead of two. Bug hidden, as in the actual External LNA there is check and reset the variable to 0 LNAGain.

The bottom line:
On eLNA layout option "External LNA Gain" always works correctly and RSSI is also calculated correctly.
On iLNA wiring parameter "External LNA Gain" should be 0, but it allows the driver code and iLNA (probably small correction -1..2 +), but in this case breaks RSSI calculation.

The omission of the sign bit of garbage - this is a bug in the driver, which is shown in the above conditions and have real meaning to fix it, discarding the sign bit, then the RSSI on the Mi-mini will go from bad values ​​even without correction EEPROM. I am ready to fix it. Nevertheless, EEPROM correction is better to conduct as no external LNA to sabzh no amplification should be zero.

comment:16 Changed 2 years ago by anonymous

comment:17 Changed 2 years ago by nbd

Thanks for the detailed information.
Please try this mt76 patch: http://nbd.name/mt76-lnagain.patch

comment:18 Changed 2 years ago by anonymous

after applying patch, signal values show correctly as a negative value. quick iperf test shows no loss in throughput so this was the real fix to this bug, rather than even more breaking already "broken" eeprom. thnx.

comment:19 Changed 2 years ago by nbd

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

fixed in r48234

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


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

 
Note: See TracTickets for help on using tickets.