# TX MCS not recovering after RSSI improvement under low unicast traffic (MM6108) **URL:** \ **Category:** Software\ **Created:** [March 18, 2026, 6:36am UTC](https://community.morsemicro.com/t/tx-mcs-not-recovering-after-rssi-improvement-under-low-unicast-traffic-mm6108/1485 "2026-03-18T06:36:23Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![murugesan.kumar](https://avatars.discourse-cdn.com/v4/letter/m/b4bc9f/32.png) [@murugesan.kumar](https://community.morsemicro.com/u/murugesan.kumar)\ **Post date:** [March 18, 2026, 6:36am UTC](https://community.morsemicro.com/t/tx-mcs-not-recovering-after-rssi-improvement-under-low-unicast-traffic-mm6108/1485/1 "2026-03-18T06:36:23Z")
Dear Morse Micro Team, We are currently using the **MM6108 chipset** with **Morse driver/firmware version v1.16** in an **802.11ah mesh deployment**. During mobility testing, we observed that **TX MCS does not recover appropriately after RSSI improvement when unicast traffic load is low**. ### Experiment Description A controlled mobility experiment was conducted where one mesh node was physically moved away from its peer to progressively degrade RSSI and then moved back towards the peer to restore link quality. This resulted in a clear **signal degradation–recovery cycle** , allowing us to observe the rate adaptation behavior during both phases. ### Observed Behavior **During link degradation:** - TX MCS decreases as expected when RSSI drops - Rate adaptation appears responsive to worsening channel conditions **During link recovery (node moving closer):** - RSSI improves significantly (e.g., from ~-90 dBm to ~-25 dBm). However, TX MCS does **not recover proportionally** when unicast traffic load is low. TX MCS remains at low values (often near MCS 0–1) for extended duration. Please refer to the following graph. This behavior suggests that **rate adaptation may be strongly dependent on unicast traffic volume**. ### Expected Behavior We expect the rate control mechanism to: - Probe higher MCS levels when channel conditions improve - Adapt primarily based on link quality rather than traffic density - Maintain reasonable PHY efficiency even under sparse traffic conditions Could you please: - Confirm whether this behavior is expected in the current rate control implementation, Advise if any configuration or tuning parameters are available, Indicate whether this issue has been addressed in newer firmware releases Thank you for your support. Regards, **Kumar M.** ![mcs_unicast_test_with_100kbps_iperf](https://us1.discourse-cdn.com/flex001/uploads/morsemicro/original/1X/28e72b2ebf035026edb041aecb977269a75cf777.png) ![mcs_unicast_test_with_10kbps_iperf](https://us1.discourse-cdn.com/flex001/uploads/morsemicro/original/1X/9e50bcbbedaf6774710ba6f2197009738c2f51e2.png) ![mcs_unicast_test_with_ping](https://us1.discourse-cdn.com/flex001/uploads/morsemicro/original/1X/84c241bba9585283aa61f3821bf37f992c7f78ee.png) ---
**Author:** ![michael.mccandless](https://avatars.discourse-cdn.com/v4/letter/m/c5a1d2/32.png) [@michael.mccandless](https://community.morsemicro.com/u/michael.mccandless)\ **Post date:** [March 27, 2026, 12:42am UTC](https://community.morsemicro.com/t/tx-mcs-not-recovering-after-rssi-improvement-under-low-unicast-traffic-mm6108/1485/2 "2026-03-27T00:42:50Z")
Hi Kumar, Rate control for low/moderate throughput scenarios is an area that we have been actively working on since 1.16. 1.16 is missing some notable improvements. 1.17 is our most recent release and may have a few of the fixes, but there’s a few recently implemented for the next release. Unfortunately I don’t believe there are any tweakable parameters for the rate control algorithm that’ll improve this, the fixes we’ve implemented are algorithmic improvements rather than configuration adjustments. Regardless the MCS should recover given enough time. The 1.16 rate control sampling operating with ~1-2 packets per second (assuming a 1kB packet size with iperf) is less than ideal for the 1.16 iteration. ---
**Author:** ![murugesan.kumar](https://avatars.discourse-cdn.com/v4/letter/m/b4bc9f/32.png) [@murugesan.kumar](https://community.morsemicro.com/u/murugesan.kumar)\ **Post date:** [April 2, 2026, 5:38am UTC](https://community.morsemicro.com/t/tx-mcs-not-recovering-after-rssi-improvement-under-low-unicast-traffic-mm6108/1485/3 "2026-04-02T05:38:21Z")
Thank you for the clarification. We understand that the rate control behaviour in low/moderate throughput scenarios is being actively improved beyond v1.16, and that the current limitation is related to insufficient sampling at low packet rates. We will proceed to test the same mobility scenario on **v1.17** and share our observations, particularly focusing on MCS recovery behavior under low unicast traffic conditions. Could you also please let us know the expected timeline for the 1.17 release (for MM6108) that includes the additional rate control improvements you mentioned? Looking forward to validating the improvements. Thanks again for your support. Regards, Kumar M. ---
**Author:** ![michael.mccandless](https://avatars.discourse-cdn.com/v4/letter/m/c5a1d2/32.png) [@michael.mccandless](https://community.morsemicro.com/u/michael.mccandless)\ **Post date:** [April 10, 2026, 1:42am UTC](https://community.morsemicro.com/t/tx-mcs-not-recovering-after-rssi-improvement-under-low-unicast-traffic-mm6108/1485/4 "2026-04-10T01:42:38Z")
1.17, for the MM6108 specifically, is currently in the final stages of testing for release, if all goes well it should be out in the next couple of weeks. Hopefully it improves your MCS recovery issues. I’ll reiterate though, 1.17 has a few of the low/moderate throughput MCS related fixes in it, however the release following 1.17 will have the additional fixes that didn’t make the tag. That will take some time to be released compared to 1.17 so ideally you’ll see some improvement with 1.17. Best of luck, Michael