# MM8108 STA: sleeping right after a TX, and controlling MCS / bandwidth / TX pow **URL:** \ **Category:** General\ **Created:** [September 23, 2026, 7:17am UTC](https://community.morsemicro.com/t/mm8108-sta-sleeping-right-after-a-tx-and-controlling-mcs-bandwidth-tx-pow/2050 "2026-09-23T07:17:43Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Ziyao](https://avatars.discourse-cdn.com/v4/letter/z/7feea3/32.png) [@Ziyao](https://community.morsemicro.com/u/Ziyao)\ **Post date:** [September 23, 2026, 7:17am UTC](https://community.morsemicro.com/t/mm8108-sta-sleeping-right-after-a-tx-and-controlling-mcs-bandwidth-tx-pow/2050/1 "2026-09-23T07:17:43Z")
We have an EKH05 (STM32U585 + MM8108, firmware `rel_1_17_8`) sending one 16–24 kB image every 0.5–2 s to a Morse AP, with no other traffic. We measure power on the HaLow rail using a PPK2. **1. Power-saving behavior after uplink transmission** After the last uplink frame, the chip stays awake at ~30 mA for another 124–167 ms and only goes to sleep just after the next beacon. Halving the AP beacon interval halves this waiting time. `dynamic_ps_timeout` is already set to 20 ms, the lowest value the chip accepts. Why does the STA wait for the next beacon before sleeping? Can an uplink-only STA go to sleep as soon as its last frame is acknowledged? **2. Fixing MCS, bandwidth, and TX power** Can we fix the MCS, bandwidth, and TX power in a normal build? `mmwlan_ate_override_rate_control()` works, but is it intended for production use? `mmwlan_override_max_tx_power()` only seems to take effect when the channel changes. Also, after applying a rate override, the AP sees PPDUs about 15 dB above the TX power limit we configured. How can we set a hard TX power limit at runtime, and how can we read back the actual TX power being used? **3. Automatic link adaptation vs. fixed settings** If we apply no overrides, does the firmware jointly adapt MCS, bandwidth, and TX power to find the best link, or does it adapt only the MCS? Is the adaptation algorithm optimized primarily for throughput, or for energy per bit? For our traffic pattern—one 16–24 kB image every 0.5–2 s—which approach would generally result in lower power consumption: allowing the firmware to adapt automatically, or using fixed MCS/bandwidth/TX-power settings? ---
**Author:** ![ldennis](https://avatars.discourse-cdn.com/v4/letter/l/3ab097/32.png) [@ldennis](https://community.morsemicro.com/u/ldennis)\ **Post date:** [September 29, 2026, 2:41am UTC](https://community.morsemicro.com/t/mm8108-sta-sleeping-right-after-a-tx-and-controlling-mcs-bandwidth-tx-pow/2050/2 "2026-09-29T02:41:33Z")
Hi Ziyao, We’ve had some significant improvements in the MM8108 FW 2.0 which was released in the mm-iot-sdk 2.13.1 release. I would recommend trying that version and seeing if you still observe the same behaviour. > [@Ziyao](#): > > Why does the STA wait for the next beacon before sleeping? Can an uplink-only STA go to sleep as soon as its last frame is acknowledged? The expected behaviour is that it would go to sleep after a window of `dynamic_ps_timeout` ms after the ack. If you can reproduce this behaviour on 2.13.1 we can look at next steps for debugging. > [@Ziyao](#): > > Can we fix the MCS, bandwidth, and TX power in a normal build? > [@Ziyao](#): > > which approach would generally result in lower power consumption: allowing the firmware to adapt automatically, or using fixed MCS/bandwidth/TX-power settings? Fixing the MCS, BW, and TX power is not recommended, and not a good mechanism for achieving power savings. We find that it’s generally best to let the rate control algorithm send the packet at the best rate, as reducing the TX duration has a bigger impact on power consumption than limiting power/bandwidth etc. If your STA is generally only sending traffic upstream, and does not need to receive downstream traffic often, you can also look at increasing the AP DTIM period. Increasing this variable increases the duration between DTIM beacons, which the STA must wake for. The default on our HL2 APs is DTIM Period 2 (~200ms), you could increase this to 5 or 10. The impact of this change to be aware of is that the downstream latency will on average increase, and this will apply to all STA in the network. Hope that helps!