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!

10

Hi @ajudge @toast_apd ,

Did we find any solution for this?
I am using the latest driver “0-rel_mm8108_2_0_0_2026_Apr_21”

Updating the “/etc/modules.d/morse” file to get fixed MCS is not reflecting.
The MCS is still auto.

[ 22.686575] morse_usb 1-1:1.0: fixed_mcs : 4
[ 22.693793] morse_usb 1-1:1.0: enable_fixed_rate : N

The /sys/ and morsectrl command changes works.

11

enable_fixed_rate : N

Have you tried setting enable_fixed_rate=1 in the module parameter configuration?

12

yes I have. but tha change is not reflected

13

If you’re using Morse Micro’s OpenWrt, set option enable_fixed_rate '1' in your wifi-device section in /etc/config/wireless. This is where all modparams are set, and will be passed through to /etc/modules.d/morse (this is auto-generated).

14

Hi @james.haggerty ,

I am using gateswork module which is ubuntu/linux.
Can I get information on how I can fix MCS on ubuntu platform?

Thanks,
Arti

15

Best to contact Gateworks about this, I think. But “I can’t set the modparam” seems like a generic problem that you can probably ask your AI to figure out :slight_smile: I assume that however you’re reloading the module you’re not picking up your setting. If you’re really stuck with the autoprobe, try using insmod directly and see if that does what you want.

You can also check what the current modparams are via sysfs as well as looking at the output from when the driver loads.

16

Hi @james.haggerty ,
We did contact gateworks and they mentioned it to be a driver issue.

This issue is observed on the EKH19 also.
updating the “/etc/modules.d/morse” is not reflecting the change of fixing the MCS.

17

Sorry, can you clarify at what point the fixed mcs is not applying? From your original comment, it seemed like you were saying you just couldn’t get the modparam to stick. I can’t see any issues with this. Have you tried using insmod or looking at the modparams via sysfs as I suggested, if you can’t figure out how to get Ubuntu’s modprobe to work as you expect?

Can you give more information about Gateworks’ ‘it’s a driver issue’ response?

Note that if your EKH19 is running OpenWrt, you should not be editing /etc/modules.d/morse, but /etc/config/wireless.

18

OpenWrt steps works fine. The issue comes when using ubuntu.

When we do:
cat /etc/modprobe.d/morse.conf
options morse country=US fixed_mcs=2 enable_fixed_rate=1

This change doesn’t stick. Even after changing the modprobe.d still the mcs remains auto and change disappers

19

If OpenWrt works fine, why would Gateworks say it’s a driver issue? It seems like you’re just not setting the parameters correctly in Ubuntu. Is it possible you have some other scripts which inserts the driver in a different way?

Did you try just using insmod and manually setting the parameters as I suggested earlier?