Unable to change MCS for MorseMicro MM8108

Software
1

**Problem Summary
**
I have a mesh network configured using two MM8108 chips which are both configured at a channel width of 2 MHz and a center frequency of 915MHz. My chip is refusing to change its MCS from auto-negotiated to fixed-MCS.

Environment details

Hardware: Gateworks Venice GW7100

Radio: Morse Micro MM8108 (USB 2.0)

OS: OpenWrt 24.10 (Kernel 6.6.109)

Driver/Tools: morse_usb v1.16.4-gateworks (github link - branch=v1.16.4-gateworks)

Supplicant: wpa_supplicant_s1g v2.12-morse_micro-1.16.4

Problem Details
To start, I have had success changing, for example, the country code by altering /etc/modules.d/morse and then rebooting. So, I tried passing the desired MCS values via /etc/modules.d/morse like so:

root@fa3e:~# cat /etc/modules.d/morse

morse country=US enable_ext_xtal_init=1 fixed_mcs=2 enable_fixed_rate=Y

root@fa3e:~#

And when I reboot the board the morse driver does seem to pick up those changes. If I run dmesg | grep “morse” I see.

…

[ 15.102774] morse_usb 1-1:1.0: fixed_mcs : 2

[ 15.109997] morse_usb 1-1:1.0: enable_fixed_rate : Y

…

But if I then run cat /sys/kernel/debug/ieee80211/phy0/morse/mmrc_table

I see that MCS 8 is still active:

2MHz SGI 36 A L MCS8 1 35 1331 10.05 8.53 100 0 0 0 129045 131837 0 0

Furthermore I can confirm that the MCS is not changing to MCS 2 (my requested level) because if I run an iperf test I see that both MCS 8 and the fake “MCS 2” both result in an iperf result of ~5.4Mbps. If I were truly at 2MHz/MCS 2, my iperf3 would be physically capped at around 1.9 Mbps after overhead.

Does anyone know the correct way to modify the MCS for the MorseMicro MM8108?

2

Not sure exactly what’s happening here, but if you’re using OpenWrt, you would usually set the modparams in uci (in wifi-device). This would then be responsible for correct module insertion. If you manually edit /etc/modules.d/morse, this would be changed the next time you tried to use anything via uci.

Having said that, it seems like you’re not doing that if you’re not seeing a subsequent driver insertion with different parameters. Are you using uci to bring things up?

3

Thanks for your response. I am not using uci to bring things up because the documentation of my HaLow card ( expansion/gw16167 – Gateworks ) advises against it. In fact one of the first things my program does is to disable the radios in uci so that uci does not attempt to control them:

        uci set wireless.radio0.disabled='1' 
        uci set wireless.radio1.disabled='1'

Instead I use wpa_supplicant_s1g. Specifically I define a file called “wpa_supplicant_halow_mesh.conf” with these contents:

country=US 
ctrl_interface=/var/run/wpa_supplicant_s1g 
sae_pwe=1 

max_peer_links=10 
mesh_fwding=0 

network={
ssid="redacted" 
key_mgmt=SAE 
mode=5 
s1g_prim_chwidth=0 
s1g_prim_1mhz_chan_index=0 
channel=28 
op_class=71
country="US" 
mesh_rssi_threshold=-85 
sae_password="redacted"
pairwise=CCMP 
ieee80211w=2 
beacon_int=100
dtim_period=1 
}

I then call /usr/sbin/wpa_supplicant_s1g -i mesh0 -c /etc/wpa_supplicant_halow_mesh.conf

To bring up the radio. Could I potentially pass my MCS number in the .conf file?

4

To expand on what Mark is using: He’s using fairly stock OpenWrt 24.10, not MorseMicro’s OpenWrt (because its kernel is too dated to support his board) so it lacks the MorseMicro UCI setup scripts that are compatible with HaLow. Gateworks has a package feed that builds the MorseMicro 1.16.4 driver/supplicant/hostapd for the more modern OpenWrt 24.10 and OpenWrt 25.12 releases.

So the question is, how does one used fixed MCS using the MorseMicro wpa_supplicant for Mesh?

1 Like
5

Hi @toast_apd

I happen to have a Gateworks board on my desk (GW8200). I’ve plugged one of our MM8108 USB dongles into it to replicate your setup, and I was able to set a fixed MCS rate using exactly the commands and configuration you used - though obviously adjusting the ssid and password to suit my own setup.

I’m using the OpenWrt image Gateworks provides, available at https://dev.gateworks.com/openwrt/24.10/openwrt-24.10-venice.img.gz

My /etc/modules.d/morse file is as follows (though strictly speaking the enable_ext_xtal_init=1 mod param is not required for this chip - that’s an MM6108 Silex specific module parameter):

morse country=US enable_ext_xtal_init=1 fixed_mcs=2 enable_fixed_rate=1

And I’ve connected it to a mesh peer, and started an iperf session. Dumping the mmrc_table during the iperf session shows me locked at MCS2.

4MHz   LGI        0     AB P  MCS2   1    16    3840  4.05  4.04         100     0       0        0          27          27       0     0

I will verify a few channel configuration options, as I note you are using 2MHz where I have instead used 4. But your current steps are exactly how a fixed MCS should be configured.

6

I found the solution to this, in my environment you can set any MCS index you want using:

echo "18" > /sys/kernel/debug/ieee80211/phy0/morse/fixed_rate

18 in this case corresponds to 2MHz LGI. If you want a list of available indexes run:

cat /sys/kernel/debug/ieee80211/phy0/morse/mmrc_table

You can then test the data rate using iperf3.

On one node run:

root@nodeA:~# iperf3 -s

root@NodeB~# iperf3 -c <Node A’s IP> -t 30

Note that the max data rate will almost always be higher than what iperf3 actually shows. Especially in the case of a mesh network which requires traffic to maintain the mesh.

Thanks!

7

Oh I see the only difference is that you set

enable_fixed_rate=1

and I set

enable_fixed_rate=Y

Well now we have two solutions!

8

Hey all, so a few things to note here for anyone reading this down the line. Setting the MCS at runtime with a already established mesh network is easy and the above methods work great. But if you want to integrate manual MCS rate control via a user interface you need to keep a few things in mind. The nodes will actually attempt to switch back to auto MCS negotiation as soon as another node joins the mesh network. So, if you want your manual MCS to stick you need to have a process running that manually writes to that file AKA:

echo "18" > /sys/kernel/debug/ieee80211/phy0/morse/fixed_rate

This is the only way to guarantee that your MCS will remain static.

1 Like
9

Nice find. We’ll make sure to report this internally as well!