APPNOTE-34 Measuring Low Power Wi-Fi HaLow
v1
1 Scope
This application note provides practical guidance and technical background for understanding, configuring, and optimizing power consumption in MM6108 and MM8108 based HaLow devices operating with the Morse Micro IoT Software Development Kit (SDK). Linux-based devices are excluded from the scope of this document.
The note covers key theoretical concepts such as beacons, Delivery Traffic Indication Message (DTIM) intervals, and Wireless Network Management (WNM) sleep mechanisms, and contrasts their trade-offs to help developers select the most suitable power-saving strategy for their use case. It also includes a step-by-step methodology for setting up measurement environments, configuring access points and stations, and using packet sniffers to analyze power-related behaviors. Note that only HaLow power consumption is looked at in detail. Power consumption from the host controller is not considered throughout this document. In addition, common behaviours specific to the MM6108 and MM8108 are discussed to help developers troubleshoot and fine-tune their designs.
By the end of this document, readers should be able to:
Understand how Wi-Fi HaLow power-saving mechanisms work
Make informed choices about network configurations to optimize power usage
Set up accurate power measurement systems and interpret results
Identify and resolve typical issues affecting power consumption
This application note is intended for embedded developers, system integrators, and test engineers working on Wi-Fi HaLow-enabled products, especially those targeting long-range, low-power wireless communication scenarios.
2 Theory/Background Information
Wi-Fi Beacons
A Wi-Fi beacon is a type of management frame that is broadcast periodically by a Wi-Fi Access Point (AP) to announce the presence of a wireless network. Beacons are a fundamental part of how Wi-Fi networks operate, allowing devices to discover available networks and connect to them.
Beacons are transmitted at the configured Beacon Interval. Typically, this is 102.4ms[a]. They are broadcast to all nearby devices on the same channel, and contain information such as SSID (network name), BSSID (MAC address of the AP), Traffic Indication Map (TIM), supported data rates and capabilities, and most importantly for the context of this document, the DTIM.
The DTIM field is only included in every Nth beacon, where N is the DTIM Period. [b][c]The DTIM field informs the Wi-Fi Station (STA) about pending broadcast or multicast data. Essentially telling the STA when to wake up and receive traffic. Both the Beacon Interval and DTIM Period are set by the AP and cannot be modified by the STA.
Power Save Methodologies
DTIM
DTIM sleep is a power-saving mechanism in which the STA enters a low-power mode and wakes only to receive DTIM beacons. These beacons notify the STA when the AP has data queued for transmission. The interval between these wake-ups is determined by the product of the Beacon Interval and the DTIM Period. A longer DTIM interval reduces the frequency of wake-ups, leading to greater power savings. However, this also increases the latency in receiving data. Therefore, selecting an appropriate DTIM value requires careful consideration of the specific application's power and latency requirements.
For example, when the AP sets the default Beacon Interval of 102.4ms, and a DTIM Period of 10, the device will sleep for 1024ms. This is referred to as DTIM10.
While in DTIM sleep, the STA will not wake up to receive the regular beacons. This can be seen by extending the previous diagram.
This can also be seen by looking at a real current measurement trace. The image below illustrates the power consumption profile of a HaLow device during DTIM sleep. The green highlighted region represents a typical DTIM measurement interval—in this case, a DTIM10 cycle lasting 1024 ms, which includes one scheduled DTIM wakeup event. In contrast, the blue highlighted region depicts the measurement of the device’s snooze current—the ultra-low-power state the HaLow chip enters between DTIM wakeups. This period excludes any wakeup events and reflects the baseline current draw during deep sleep.
The image below shows the zoomed in current profile of a single DTIM wakeup, with annotations to show the different stages.
WNM Sleep
WNM Sleep is another power-saving mechanism which allows STA’s to explicitly negotiate sleep schedules with the AP, reducing power consumption during idle periods while maintaining connectivity. Essentially, the STA does not wake up for DTIM beacons, and only wakes up at the period it previously scheduled with the AP.
Entering and exiting WNM sleep incurs a higher cost to power consumption than waking for a DTIM, due to the request-response exchange between the AP and STA, resulting in increased time in Receive (RX) and Transmit (TX) modes. This method is generally advised for applications with longer sleep periods. For guidance on when to use each mode, see When To Select DTIM Vs WNM Sleep section below.
The image below shows the power consumption profile of a device that was in DTIM mode, but then enters and exits WNM sleep. Note how the supply current when entering and exiting WMN sleep is significantly larger than waking for a DTIM beacon.
3 When To Select DTIM vs WNM Sleep
The optimal choice between DTIM and WNM sleep depends on several factors, including the application's sleep requirements, data transmission intervals, and how frequently the STA must receive data. General guidelines for selecting between the two modes are outlined below.
WNM sleep incurs a higher initial power cost due to the request-response exchange required to enter and exit the sleep state. Therefore, for shorter sleep durations, DTIM is the preferred method. However, for longer sleep intervals where the STA does not need to receive data frequently, WNM sleep becomes more efficient as it avoids periodic wake-ups. The crossover point at which WNM sleep becomes more power-efficient than DTIM can be calculated, but it is application-dependent.
For an 8 MHz channel, using a standard beacon interval of 102.4 ms, and using DTIM10, WNM sleep becomes more power efficient after roughly 80 seconds. This is assuming in each case there is no data buffered that the STA receives when it wakes up, and the STA is purely sleeping and waking.
With a higher DTIM interval such as DTIM40, WNM sleep becomes more efficient after approximately 325 seconds. Whether this delay is acceptable depends on the application’s tolerance for the station being unable to receive data during that period.
For applications like remote sensors that transmit data infrequently and do not require receiving data from the AP, WNM sleep mode could provide lower power consumption. However, for stations that do need to receive data from the AP, using DTIM-based power saving is the recommended approach.
There are also other practical limitations of WNM sleep that users should be aware of. If a STA remains asleep for an extended period, incoming data queued at the AP can exceed the available buffer capacity. Once this buffer is full, data loss may occur, leading to application-level issues. This limitation will be application specific, and may never pose a problem at all, but this is highlighting that WNM sleep intervals cannot be extended indefinitely.
4 Guidelines for Selecting Bandwidth
In most cases, achieving the lowest possible power consumption requires using higher bandwidths. This is because higher bandwidths enable faster transmission and reception of data, thereby minimizing the time the STA spends awake, and ultimately reducing power usage.
However, using higher bandwidths comes with important trade-offs that developers must consider. The most significant is range: as bandwidth increases, so does the total thermal noise power, which leads to a lower signal-to-noise ratio (SNR) and a reduction in the devices receive sensitivity. In simple terms, higher bandwidth offers better power efficiency but at the cost of reduced range, while lower bandwidth provides greater range at the expense of higher power consumption.
Another key trade-off involves channel capacity. Higher bandwidths support greater data throughput and can accommodate more devices sharing the same channel. In contrast, networks with fewer concurrently connected devices may benefit from lower bandwidths, which offer improved range and potentially more robust connections in noisy environments.
Ultimately, the choice of bandwidth should be guided by the specific requirements of the application, balancing power consumption, range, and network capacity. It is also important to note that Morse Micro AP’s employ rate control algorithms which can vary the selected bandwidth and Modular Coding Scheme (MCS) rate to improve network performance. For more information, please see MM APPNOTE 28[d][e] - Morse Micro Rate Control.
5 How To Measure Power Consumption
Hardware Setup
The most basic setup involves connecting the AP and STA to a host PC, and to each other via antennas. An energy analyser is also connected to the STA to measure power, in this case a Joulescope JS220. Where possible, the cables from the energy analyser to the STA should be short, low resistance leads to minimize the voltage drop, and to reduce lead inductance. Inductive leads can cause ringing or overshoot in current and voltage waveforms, and give misleading measurements.
For this application note, a Morse Micro HaLowLink 1 will be used for the AP, and an MM6108-EKH05 will be used as the STA. For more information on where to place the energy analyser to measure specific power rails, please consult the MM6108-EKH05 user guide. This application note will focus on measuring all HaLow supplies, as shown below by placing the probes across the HALOW header.
Access Point Configuration
Upgrade To Latest OpenWRT Version
On the AP, navigate to the Upgrade tab. Click the Check for automatic upgrade button and follow the prompts if an upgrade is available. An existing connection to the internet either through the ethernet connection or the 2.4 GHz Wi-Fi radio is needed for this step. Please see the HaLowLink 1 User Guide for more details.
Set Channel, Bandwidth, and DTIM Period
After initial configuration, the channel, bandwidth, and DTIM period can be changed by navigating to the Advanced Config → Network → Wireless page, and then clicking Edit on the HaLow radio.
The Bandwidth and Channel can then be changed from the Device Configuration menu. The DTIM Interval can then be changed by selecting Advanced Settings from the Interface Configuration menu.
Station Configuration
The primary objective when performing power measurements is to bring the device into a connected, idle state. The Morse Micro IoT SDK offers several example applications to facilitate this process. One of the recommended options is to use the Command Line Interface (CLI) application, which communicates with the Wi-Fi HaLow chip via a UART interface from the host system. Using the CLI, configuring the SSID and password is straightforward, and associating the STA with an AP can be done easily—automatically transitioning the device into DTIM sleep mode. Additionally, the CLI provides simple commands to place the STA into WNM sleep mode, offering further power-saving control.
There are several development options available for loading the CLI application onto the MM6108-EKH05 evaluation kit. The MM6108-EKH05 User Guide provides detailed instructions on using the CMSIS-Pack to program the device via supported IDEs such as STM32CubeIDE. For hardware platforms not supported by the CMSIS-Pack, PlatformIO is a suitable alternative, offering support for multiple Morse Micro boards. Refer to the PlatformIO User Guide for more information. Note that when building the example application, selecting FreeRTOS+TCP as the network stack will be more power efficient than the default lwIP stack.
Follow the instructions provided in the user guide corresponding to the chosen development environment. Regardless of the method used, the result should be the same: the STA successfully running the CLI example.
Place STA In Power Save
UART Settings
With the CLI application loaded onto the STA, a UART connection can be established to interact with the command line interface. On the MM6108-EKH05, this can be done through the micro-USB cable, and the onboard STLINK-V3. The UART connection should be configured as follows:
Baud Rate
115200
Hardware Flow Control
None
Data Bits
8
Stop Bits
1
Parity
None
Windows
The STLINK-V3MODS will show up as a Virtual COM port on windows machines.
This COM port can then be opened with tools such as PuTTY.
putty -serial COM19 -sercfg 115200
Linux
On Linux machines, the device can be detected with the following command:
ls /dev/serial/by-id/usb-STMicroelectronics_STLINK-V3_*
A serial terminal can be opened with tools such as minicom:
minicom -D /dev/serial/by-id/usb-STMicroelectronics_STLINK-V3_* -b 115200
Mac OS
On Mac machines, the device can be detected with the following command:
ls /dev/tty.*
A serial terminal can be opened with tools such as minicom:
minicom -D /dev/tty<YOUR-DEVICE-HERE> -b 115200
CLI Commands
When first opening the serial connection, the user will be presented with a cursor, waiting for input. To see a list of all commands, type “help”.
At this stage, the correct Country Code, SSID, and Password can be configured using the following commands. These are the minimum required parameters to initiate a connection and must match the settings configured on the AP. Once these values are set, they must be committed to ensure they persist after a power cycle or device reset. The user can then verify that the settings have taken effect by retrieving and reviewing the stored parameters.
set wlan.country_code AU set wlan.ssid MorseMicro set wlan.password 12345678 commit wlan get wlan
Now the station can connect to the AP with the following command.
wlan-connect
A confirmation of association between the devices can be seen on the terminal window. Power save is enabled by default and the power consumption can be monitored to see DTIM sleep.
To enter and exit WNM sleep, the following commands can be used.
wlan-wnm_sleep enter wlan-wnm_sleep exit
This again can be seen when monitoring the power consumption.
Figure 20. Joulescope capture after entering and exiting WNM sleep through the CLI application.
By default in the CLI application, the host is constantly awake and awaiting UART input. It is highly recommended to place this in a low power state, even when performing HaLow measurements. This can be achieved with the following command.
sys-deep_sleep one_shot
This can be seen by measuring the host power consumption.
6 How To Use A Sniffer To Debug Power Consumption
Benefits of Using a Wi-Fi HaLow Packet Sniffer
A sniffer allows the traffic across a network to be monitored. This allows us to see when the STA is transmitting and/or receiving packets. This can be useful for identifying unintended transmissions from the STA, such as wake-ups and data transfers that occur unexpectedly, as well as broadcast traffic from the AP that is being received by the STA.
Debug Example Using Sniffer
As an example, a STA in DTIM40 sleep was experiencing higher power consumption than expected. The DTIM wakeups were observed every 40 x 102.4ms = 4096ms, as expected, however two additional unaccounted wake-up events spaced 30 seconds apart were also observed. This is shown in the green highlighted area.
The consistent 30-second interval between wake-up events suggested a periodic trigger—either originating from the MM6108 or from recurring network activity. To pinpoint the source, a network sniffer was used to detect traffic occurring at these same intervals. In this case, the sniffer revealed Address Resolution Protocol (ARP) announcements every 30 seconds, illustrating how higher-layer network protocols can unintentionally contribute to increased power consumption.
This finding led to the review of the FreeRTOS+TCP network stack configuration, and the gratuitous ARP period was then changed to a longer interval. After applying these changes, the unexpected current spikes were eliminated, and the STA was able to remain in sleep mode without unintended wakeups. This fix was included in the Morse Micro IoT SDK 2.7.2 release, and future releases.
Configure Sniffer
Any linux based MM6108 or MM8108 device can be used to listen to and capture packets on a Wi-Fi HaLow network. Ordinary Wi-Fi sniffers will not work as their radios will not be able to operate in the sub 1 GHz spectrum. For this example, another HaLowLink 1 will be added to the existing setup.
For details on how to configure the HaLowLink1 to be a sniffer, please refer to MM APPNOTE 36 - How to do a sniffer capture. The intended outcome is for the user to have Wireshark running and successfully capturing HaLow traffic. However, not all HaLow traffic on the network may be visible at this stage. The following section outlines how to modify the network’s security settings to enable full packet visibility.
Set HaLow Network To Open Security
To allow the sniffer to capture all packets on the network, security must be temporarily set to "No Encryption (open network)." This configuration must be applied to both the AP and STA for the devices to associate. Note that open security is intended only for debugging and is not a supported mode for Wi-Fi HaLow certified devices. After debugging, security must be restored to the default WPA3-SAE (strong security) setting.
AP
The security can be set to Open by navigating to the Network → Wireless page, and clicking Edit on the HaLow network.
Next, navigate to the Wireless Security tab, and set the Encryption type to No Encryption (open network). Click Save, and then Save and Apply.
STA (Through CLI Application)
set wlan.security open commit wlan get wlan.security
With the CLI application still loaded, the security can be set, and retrieved with the following commands.
The STA can connect back to the AP using the same commands as shown in previous sections.
wlan-connect
Sniff Packets With Wireshark
Filters
Now that the security is set to open on both the AP and STA, the traffic across that network can be freely monitored. However, if multiple networks are operating on the same channel, it can become challenging to determine which traffic belongs to which network, potentially leading to confusion during analysis. To simplify this, a filter can be set to only show traffic to and from the STA. For example, the following filter will show all traffic from a STA with a particular MAC address.
wlan.addr == 94🇧🇧43:dc:f5:87
Some useful filters including the one shown above are as follows:
wlan.addr == <STA MAC Address>
Will show all traffic from a device with a particular MAC address. This is useful, but can also miss broadcast packets being sent to the STA which can still cause it to wake up.
wlan.addr == <STA MAC Address> or wlan.addr == <AP MAC Address>
This improves on the last filter by capturing all traffic to and from the AP, including broadcast packets that get received by the STA.
radiotap.dbm_antsignal >= -60
Filters packets that have greater than a certain receive strength. Useful if the signal strength is within an expected range, especially if evaluating all devices close together on a desk.
The MAC addresses of the AP and STA can be found by opening to the AP’s OpenWRT GUI, and navigating to the Network → Wireless page. The BSSID will show the AP’s MAC address. The STA’s MAC address can be found in the Associated Stations section.
Colour Schemes
Colour schemes within Wireshark can also be a useful tool to identify different types of traffic which can affect power consumption. There are many resources online to aid with setting up colour profiles. See here as an example - https://www.geeksforgeeks.org/what-is-packet-colourization-in-wireshark/.
This is useful as the colouring profile allows the user to quickly identify between different types of traffic. See Figure 29 highlighting beacons, and MDNS and SSDP traffic differently. Beacons aren’t very important when considering STA power consumption, but the other types of traffic can wake the STA and contribute to increased power usage.
7 Power Consumption Troubleshooting
Power consumption can be challenging to optimize. The following section outlines common issues and their corresponding troubleshooting methods, divided into two categories: application-specific configurations and the impact of Over-The-Air (OTA) transmissions.
Application Specific Software Configurations
Traffic From Bridged Interfaces
One of the most common causes of elevated power consumption is broadcast traffic. When the AP is configured to bridge its interfaces, other devices on the network may send broadcast messages to all devices within the subnet—including the HaLow STA. As a result, the STA receives these packets and spends an increased amount of time in RX mode, increasing power usage. This behavior can be easily identified using the sniffer techniques described in Section 6, particularly by applying appropriate coloring rules.
This is not a HaLow-specific issue but a broader network management concern. Various strategies can help mitigate the impact, though it ultimately falls on the network to manage this traffic.
For simple HaLow platform evaluations, one effective approach is to configure the AP to isolate the HaLow network. To do this, first go to Advanced -> Network -> Interfaces and click Add new interface.
Set name to “ahwlan”, and Protocol to “Static address”. Leave Device as “unspecified”, and click Create interface.
Click Dismiss on the page that comes next.
Navigate to the Quick Config page, and next to ahwlan, click Create Zone. Also input an IP address of 192.168.1.1.
Then, scroll down to the Wireless section, and set the Network of the 802.11ah radio to ahwlan. Then click Save & Apply. Now, the HaLow network is isolated, and no other traffic from devices on the bridged network will wake up the STA.
Application Specific Configurations
Below are some common reasons a STA may wake up as a result of application specific configuration settings.
The STA needs to send network traffic back to the AP. E.g. the STA sends a keep alive frame to let the AP know it is still connected. This can be easily identified with a sniffer. The time between sending these frames can also be increased through the Advanced Settings menu of the Interface Configuration page on the AP. Look for the Station inactivity limit parameter.
DHCP is enabled by default on all example applications. This can result in the STA waking up to send DHCP packets unnecessarily. This can be disabled in the CLI application with the following commands. The device may need to be reset after entering the commands to take effect.
set ip.dhcp_enabled false commit ip
The host is performing a health check to determine whether the Wi-Fi HaLow chip is still operational. On default example applications included within the Morse Micro IoT SDK, these are set to occur every 90 seconds. These can be disabled altogether by setting the health check interval using the following API in the source code of the Morse Micro IoT SDK example application. The example application will have to be rebuilt and uploaded to the device for the changes to take effect.
mmwlan_set_health_check_interval(0, 0);
The Wi-Fi HaLow chip has woken, missed the DTIM beacon and instead targets the next (potentially) non-DTIM beacon. This will be discussed in greater detail in the following section.
OTA vs Cabled
In a cabled, shielded environment, there is minimal risk of interference from external Radio Frequency (RF) sources between the AP and STA. However, in real-world OTA conditions, such interference is common. For devices operating in DTIM power save mode, interference from other RF sources can lead to collisions with the DTIM beacon, preventing successful reception by the STA. This negatively impacts power consumption as the STA will wake to receive the DTIM beacon, remain in active RX mode longer than necessary, fail to receive the beacon, and return to sleep. It will then attempt to capture the next non-DTIM beacon at the following beacon interval, further increasing time spent in RX mode. This prolonged RX activity can significantly raise power consumption and is clearly observable when monitoring current draw.
This behavior is not unique to Wi-Fi HaLow; it is a common characteristic of all RF-based communication systems. Any wireless technology that relies on beaconing or periodic transmissions—such as classic Wi-Fi, Bluetooth, Zigbee, or LoRa—can suffer similar issues when exposed to interference in OTA conditions. As a result, the impact on power consumption and communication reliability under OTA conditions must always be considered during the design and validation of low-power wireless systems.
8 MM6108 Known Behaviors
Current Spikes When Waking Up
Users may observe a momentary current spike when MM6108 based devices wake up from sleep modes, sometimes reaching or exceeding 1 A. This spike is expected, and results from the operation of the internal buck converter. The buck converter generates ~1.4 V during active operation to supply the internal chip power rails. In power save mode, the chip enters a sleep mode where the Vbuck voltage is dropped to ~0.7 V. This voltage is used to keep the internal memory in a retention state; while the rest of the chip's power supplies are disabled to save power.
When the chip wakes up, the buck capacitor is charged from ~0.7 V to ~1.4 V. This rapid charging, occurring over tens of microseconds, generates the observed current spike. This behavior is illustrated in the image below.
Although the peak of the current is large, the duration is short, so the energy is small (in this instance less than 10 µC) and the instantaneous current spike is sourced primarily from decoupling capacitors on the VBAT power rail. Batteries connected to the power supply are decoupled further by regulators and additional bulk capacitors upstream of the MM6108. All power consumption figures published in Morse Micro datasheets already include these transient spikes, ensuring there are no additional power costs beyond the specified values.
Memory Retention Current Spikes
On MM6108 based devices, users may observe regular spikes of current roughly every 85ms (this period will change with device capacitance, and with temperature). These are memory retention current spikes. When the MM6108 goes into its default low power mode, the internal memory in the chip is still being powered. The buck regulator on the MM6108 will operate to keep the CAPD and DVDD pin of the chip at a voltage where memory is retained. The buck regulator will then pulse when this voltage goes below a certain threshold. This is the spike in current that is being measured, and the period will depend on temperature and the capacitance of the board.
9 MM8108 Known Behaviors
Current Spikes When Waking Up
The MM8108 also exhibits a current spike when waking from sleep; however, the magnitude is significantly lower than that observed on the MM6108. This improvement is due to the soft-start feature of the MM8108’s internal buck regulators, which helps moderate inrush current during power-up. Users can typically expect this wake-up current spike to remain below 200 mA. The images below illustrate this behavior.
As with the MM6108, the current spike on the MM8108 is high in magnitude but short in duration, resulting in relatively low overall energy. Additionally, any batteries supplying power are further decoupled from this transient by upstream regulators and bulk capacitors, which help mitigate its impact on the power source.
10 Glossary
AP
Access Point
A device that broadcasts Wi-Fi beacons and manages wireless connections.
STA
Station
A Wi-Fi client device that connects to an AP.
DTIM
Delivery Traffic Indication Message
A field in beacon frames that indicates when broadcast/multicast data is available for sleeping stations.
WNM
Wireless Network Management
A power-saving protocol allowing scheduled wake/sleep cycles negotiated between STA and AP.
RX
Receive
Mode in which a device listens for and processes incoming wireless signals.
TX
Transmit
Mode in which a device sends wireless data.
SSID
Service Set Identifier
Network name broadcast in Wi-Fi beacons.
BSSID
Basic Service Set Identifier
MAC address of the AP.
TIM
Traffic Indication Map
A field in beacons that indicates which STAs have data waiting in the AP.
MCS
Modulation and Coding Scheme
Index that determines the data rate and efficiency of a wireless connection.
SNR
Signal-to-Noise Ratio
A measure of signal strength relative to background noise.
SDK
Software Development Kit
A collection of tools and code used to develop software applications.
CLI
Command Line Interface
A text-based interface to interact with the Wi-Fi HaLow chip through commands.
UART
Universal Asynchronous Receiver/Transmitter
A hardware interface used for serial communication.
CMSIS
Cortex Microcontroller Software Interface Standard
A standardized hardware abstraction layer for ARM Cortex-M processors.
IDE
Integrated Development Environment
Software used for writing, compiling, and debugging code.
lwIP
Lightweight IP
A small TCP/IP stack used in embedded systems.
FreeRTOS
Free Real-Time Operating System
A popular open-source real-time OS for microcontrollers.
OpenWRT
Open Wireless Router Toolkit
An open-source Linux operating system targeting embedded devices.
MDNS
Multicast DNS
A protocol for resolving hostnames to IP addresses within small networks without a central DNS server.
SSDP
Simple Service Discovery Protocol
A protocol to allow devices to discover each other on a network.
ARP
Address Resolution Protocol
Used to resolve IP addresses to MAC addresses on a local network.
OTA
Over The Air
Refers to wireless (non-cabled) communication or updates.
11 Revision History
01
11/06/2025
Initial release.
Last updated
Was this helpful?