# Morse Micro documentation Documentation for Morse Micro products, software, and hardware integration. Build, evaluate, and ship with Morse Micro Wi-Fi HaLow solutions. Use this portal to find product data, implementation guides, and reference material. ### **Software releases** Software releases provide firmware, drivers, tools, and supporting packages. Release notes cover changes, compatibility, known issues, and release-specific details. #### [MM8108 Linux Software Release Notes](/software-releases/mm8108-linux-software-release-notes) Linux firmware and driver releases for MM8108-based products. #### [MM6108 Linux Software Release Notes](/software-releases/mm6108-linux-software-release-notes) Linux firmware and driver releases for MM6108-based products. #### [HaLowLink2 Software Release Notes](/software-releases/halowlink2-software-release-notes) Software releases for HaLowLink 2 devices. #### [HaLowLink1 Software Release Notes](/software-releases/halowlink1-software-release-notes) Software releases for HaLowLink 1 devices. #### [MM8108 Windows USB Driver Software Release Notes](/software-releases/mm8108-windows-usb-driver-software-release-notes) Software release notes for the Wi-Fi HaLow USB Network Adapter Windows driver. #### [MM-IoT-SDK Software Release Notes](/software-releases/mm-iot-sdk-software-release-notes) SDK releases for building applications with Morse Micro products. #### [CMSIS-Pack Software Release Notes](/software-releases/cmsis-pack-software-release-notes) CMSIS-Pack releases for Morse Micro development. #### [OpenWrt Software Release Notes](/software-releases/openwrt-software-release-notes) OpenWrt releases for supported Morse Micro hardware. ### **Datasheets** Datasheets define product specifications, electrical characteristics, pin descriptions, and design requirements. #### [MM6108-MF08651-US Data Sheet](/datasheets/mm6108-mf08651-us-datasheet) Datasheet for the MM6108-MF08651-US Wi-Fi HaLow module. #### [MM6108 Data Sheet](/datasheets/mm6108-datasheet) Datasheet for the MM6108 Wi-Fi HaLow system-on-chip. #### [MM8108 Data Sheet](/datasheets/mm8108-datasheet) Datasheet for the MM8108 Wi-Fi HaLow system-on-chip. #### [MM8108-MF15457 Data Sheet](/datasheets/mm8108-mf15457-datasheet) Datasheet for the MM8108-MF15457 Wi-Fi HaLow module. #### [MM8108-M20 Preliminary Data Sheet](/datasheets/mm8108-m20-preliminary-datasheet) Preliminary datasheet for the MM8108-M20 Wi-Fi HaLow module. ### **Design guides** Design guides provide hardware recommendations, reference layouts, and integration guidance. #### [MM8108-MF15457 Hardware Design Guide](/design-guides/mm8108-mf15457-hardware-design-guide) Hardware integration guidance for the MM8108-MF15457 Wi-Fi HaLow module. ### Application notes Application notes provide configuration guidance, implementation examples, and technical recommendations for Morse Micro products. #### [APPNOTE-3 Target Wake Time](/application-notes/appnote-3-target-wake-time) Guidance for configuring Target Wake Time. #### [APPNOTE-13 Morsectrl Guide](/application-notes/appnote-13-morsectrl-guide) Guidance for using the `morsectrl` utility. #### [APPNOTE-15 MM6108 SDIO SPI Design Guide](/application-notes/appnote-15-mm6108-sdio-spi-design-guide) Hardware design guidance for MM6108 SDIO and SPI interfaces. #### [APPNOTE-17 Dynamic Channel Selection](/application-notes/appnote-17-dynamic-channel-selection) Guidance for using dynamic channel selection. #### [APPNOTE-18 Bringing Up prplMesh on Linux](/application-notes/appnote-18-bringing-up-prplmesh-on-linux) Instructions for bringing up prplMesh on Linux. #### [APPNOTE-20 Thin LMAC](/application-notes/appnote-20-thin-lmac) Overview and guidance for Thin LMAC. #### [APPNOTE-21 TCP Keep Alive Offload](/application-notes/appnote-21-tcp-keep-alive-offload) Guidance for TCP keep-alive offload. #### [APPNOTE-24 Linux Porting Guide](/application-notes/appnote-24-linux-porting-guide) Guidance for porting Morse Micro software to Linux. #### [APPNOTE-25 Centralized Authentication Control](/application-notes/appnote-25-centralized-authentication-control) Guidance for centralized authentication control. #### [APPNOTE-26 BCF Overview and Impact on System Performance](/application-notes/appnote-26-bcf-overview-and-impact-on-system-performance) Overview of BCF and its system-performance impact. #### [APPNOTE-28 Morse Micro Rate Control](/application-notes/appnote-28-morse-micro-rate-control) Guidance for Morse Micro rate control. #### [MM APPNOTE-29 Bypass Boobytrap](/application-notes/appnote-29-bypass-boobytrap) Guidance for bypassing boobytrap protection. #### [APPNOTE-31 How to Configure EasyMesh](/application-notes/appnote-31-how-to-configure-easymesh) Instructions for configuring EasyMesh. #### [APPNOTE-32 How to Configure 802.11s Mesh](/application-notes/appnote-32-how-to-configure-802.11s-mesh) Instructions for configuring an 802.11s mesh. #### [APPNOTE-33 2.4GHz Range Extension Using HaLow](/application-notes/appnote-33-2.4ghz-range-extension-using-halow) Guidance for extending 2.4 GHz range with Wi-Fi HaLow. #### [APPNOTE 34 Measuring Low Power Wi-Fi HaLow](/application-notes/appnote-34-measuring-low-power-wi-fi-halow) Guidance for measuring low-power Wi-Fi HaLow operation. #### [APPNOTE-35 How to Configure a Starlink LTE Dongle Internet Uplink Connection](/application-notes/appnote-35-how-to-configure-a-starlink-lte-dongle-internet-uplink-connection) Guidance for configuring Starlink and LTE dongle internet uplinks. #### [APPNOTE-36 How to Do a Sniffer Capture](/application-notes/appnote-36-how-to-do-a-sniffer-capture) Guidance for capturing Wi-Fi HaLow packets with Wireshark. #### [APPNOTE-37 How to Configure Virtual Wire](/application-notes/appnote-37-how-to-configure-virtual-wire) Instructions for configuring Virtual Wire. #### [APPNOTE-38 Wi-Fi Easy Connect using DPP URIs or QR Codes](/application-notes/appnote-38-wi-fi-easy-connect-using-dpp-uris-or-qr-codes) Guidance for Wi-Fi Easy Connect using DPP URIs or QR Codes. #### [APPNOTE-39 MM6108 OTP for BCF and MAC Read and Write Guide](/application-notes/appnote-39-mm6108-otp-for-bcf-and-mac-read-and-write-guide) Guidance for reading and writing MM6108 OTP BCF and MAC data. #### [APPNOTE-41 OTP and BCF Selection](/application-notes/appnote-41-otp-and-bcf-selection) Guidance for selecting OTP and BCF configurations. #### [APPNOTE-43 Wi-Fi HaLow RF Test Guide](/application-notes/appnote-43-wi-fi-halow-rf-test-guide) Guidance for cabled RF testing of MM6108 and MM8108 devices. #### [APPNOTE-45 MM IoT SDK Porting Guide](/application-notes/appnote-45-mm-iot-sdk-porting-guide) Guidance for porting the MM IoT SDK to a new microcontroller platform. #### [APPNOTE-50 AP Power Management](/application-notes/appnote-50-ap-power-management) Guidance for access point power management. #### [APPNOTE-51 Linux SPI Driver Porting Guide](/application-notes/appnote-51-linux-spi-driver-porting-guide) Guidance for porting the Linux SPI driver. #### [APPNOTE-56 MM8108 Thermal Protection Mechanism](/application-notes/appnote-56-mm8108-thermal-protection-mechanism) Guidance for using the MM8108 thermal protection mechanism. ### **User guides** User guides provide setup, configuration, and integration instructions for Morse Micro products. #### [Wi-Fi HaLow Network Adapter User Guide](https://www.morsemicro.com/resources/user_guides/USB_Network_Adapter_User_Guide.pdf) The Wi-Fi HaLow Network Adapter User Guide provides instructions for setting up and configuring the Morse Micro Wi-Fi HaLow USB network adapter. #### [MM6108-EKH01 Evaluation Kit User Guide](https://www.morsemicro.com/resources/user_guides/MM6108-Eval-Kit-User-Guide-2.5.pdf) Instructions for deploying and configuring the MM6108 evaluation kit with OpenWrt. #### [MM-IoT CMSIS-Pack User Guide](https://www.morsemicro.com/resources/user_guides/MM-IoT-CMSIS-Pack-User-Guide.pdf) Instructions for integrating the MM-IoT-SDK into ARM development environments. #### [MM6108 Evaluation Kit User Guide](https://www.morsemicro.com/resources/user_guides/MM6108-Eval-Kit-User-Guide-2.6.pdf) Instructions for deploying and configuring the MM6108 evaluation kit with OpenWrt. #### [PlatformIO + MM-IoT-SDK User Guide](https://www.morsemicro.com/resources/user_guides/Platform-IO-MM-IoT-SDK-User-Guide.pdf) Instructions for integrating the MM-IoT-SDK with PlatformIO. #### [MM6108-EKH05 User Guide](https://www.morsemicro.com/resources/user_guides/MM6108-EKH05-User-Guide.pdf) Instructions for deploying and programming the MM6108-EKH05 evaluation board. #### [HaLowLink User Guide](https://www.morsemicro.com/resources/user_guides/HaLowLink-User-Guide.pdf) Instructions for installing, configuring, and using HaLowLink devices. #### [MM6108 Eval Kit User Guide](https://www.morsemicro.com/resources/user_guides/MM6108-Eval-Kit-User-Guide-2.7.pdf) Instructions for deploying and configuring the MM6108 evaluation kit with OpenWrt. #### [MM8108-EKH05 User Guide](https://www.morsemicro.com/resources/user_guides/MM6108_MM8108-Eval-Kit-User-Guide-2.9.pdf) Instructions for deploying and programming the MM8108-EKH05 evaluation board. #### [MMx108 Eval Kit User Guide](https://www.morsemicro.com/resources/user_guides/MM6108_MM8108-Eval-Kit-User-Guide-2.9.pdf) Instructions for using MM6108 and MM8108 evaluation hardware. ### **Downloads** Download firmware images and hardware reference design packages. #### [Images](/downloads/images) Firmware images for HaLowLink devices and evaluation kits. #### [Design packages](/downloads/design-packages) Reference schematics, PCB layouts, and BOMs for Morse Micro hardware. #### [Drivers](/downloads/drivers) Download drivers for supported Morse Micro hardware. # Software releases Software releases provide firmware, drivers, tools, and supporting packages for Morse Micro products. Each release notes page lists changes, compatibility, known issues, and release-specific details. ### Software release notes #### [MM8108 Linux Software Release Notes](/software-releases/mm8108-linux-software-release-notes) Linux firmware and driver releases for MM8108-based products. #### [MM6108 Linux Software Release Notes](/software-releases/mm6108-linux-software-release-notes) Linux firmware and driver releases for MM6108-based products. #### [HaLowLink2 Software Release Notes](/software-releases/halowlink2-software-release-notes) Software releases for HaLowLink 2 devices. #### [HaLowLink1 Software Release Notes](/software-releases/halowlink1-software-release-notes) Software releases for HaLowLink 1 devices. #### [MM8108 Windows USB Driver Software Release Notes](/software-releases/mm8108-windows-usb-driver-software-release-notes) Software release notes for the Wi-Fi HaLow USB Network Adapter Windows driver. #### [MM-IoT-SDK Software Release Notes](/software-releases/mm-iot-sdk-software-release-notes) SDK releases for building applications with Morse Micro #### [CMSIS-Pack Software Release Notes](/software-releases/cmsis-pack-software-release-notes) CMSIS-Pack releases for MM6108 and MM8108 evaluation kits. #### [OpenWrt Software Release Notes](/software-releases/openwrt-software-release-notes) OpenWrt releases for supported Morse Micro hardware. # MM8108 Linux Software Release Notes v5 2.1.0 [Download as PDF](https://www.morsemicro.com/resources/software_releases/linux/driver_source_code/MM8108-Linux-Software-Release-Notes.pdf) ## 1 Overview The purpose of this document is to provide a summary of new software features and improvements implemented in the latest Linux firmware and driver. ## 2 Software Change Summary ### 2.1 Release 2.1.0 This section summarizes software changes made since release 2.0.0. | Long-Term Support (LTS) Linux Kernels supported in this release | | --------------------------------------------------------------------------- | | 6.12.21, 6.6.31, 6.1.21, 5.15.61, 5.10.11, 5.4.83, 4.19.66, 4.14.98, 4.9.80 | #### 2.1.1 New Features * Support for Standby mode * Standby is a power management state in which the host application processor is powered down while the Wi-Fi HaLow firmware continues to run autonomously, maintaining network connectivity. * Support for Argentina, Chile, Colombia, and Mexico regulatory domains. * Support for EN 304 220 * Support for bus-test mode * The Morse driver test mode brings the driver up only to a selected stage, rather than performing a full interface bring-up. This is useful during driver porting. The new bus-test mode skips the firmware boot and verifies only that the host bus is functional and that data can be read from and written to the device correctly. * Support for FullMAC (Beta) * MM8108 firmware and driver can be configured to operate in FullMAC architecture. A FullMAC driver is a Linux Wi-Fi HaLow driver architecture in which most of the 802.11 MAC-layer processing occurs on the device rather than in the host kernel. * MM8108 FullMAC can only operate in STA mode. * FullMAC is currently in beta support. For configuration and limitations, refer to the "FullMAC Linux Driver User Guide". * FullMAC supports UDP keep-alive. The firmware maintains periodic UDP keep-alive packets to a cloud server on the host's behalf, allowing the host to enter deep power-down states, including full power-off. * Opportunistic Wireless Encryption (OWE) is supported on kernels older than 6.7. OWE is a Wi-Fi Alliance Enhanced Open mechanism that encrypts traffic on open networks without a passphrase. * Human Machine Interface (HMI) (Beta). A new framework for triggering user-defined actions in response to driver or firmware events. * Support for the MM8108-M20-US module * MM8108-M20 combines Morse Micro's Wi-Fi HaLow silicon with an external high-power amplifier, alongside a surface acoustic wave (SAW) filter tuned for the 902-928 MHz band in North America. For more details, see [MM8108 M20 High Power Wi-Fi HaLow Module](https://www.morsemicro.com/2026/06/01/morse-micro-announces-mm8108-m20-high-power-wi-fi-halow-module-to-accelerate-long-range-iot-adoption/). * BCF-based Thermal Protection Thresholds (beta): Thermal Mitigation ensures the device operates within safe limits. The firmware continuously monitors chip temperature and suspends transmission once it reaches the mitigation threshold, resuming once the chip cools down. BCF parameterization, introduced as alpha in 2.0.0, is now available as beta for customer evaluation. See APPNOTE-56, MM8108 Thermal Protection Mechanism, for more information. #### 2.1.2 Resolved Issues and Improvements * Throughput degradation for multi-STA if WDS is enabled. * An intermittent crash can be observed if running on the SPI bus with A-MSDU enabled and traffic flowing bidirectionally. * Intermittent firmware assert/crash during calibration. The issue is intermittent and uncommon. * Intermittent chip hangs during packet offloading transmission: Caused by incorrect packet size calculations. * Health-check can fail/timeout while the chip is busy handling scan requests. * The TX power setting is not obeyed for the sub-band. The feature doesn't affect data packets but only management packets (e.g., beacons, Probe request/response) #### 2.1.3 Known Issues **SoftMAC** * A lower association success rate was observed when interoperating with older (i.e., versions < 2.0.0) MM8108 software releases in high-noise environments. * This behavior can be attributed to the increased collision rate when a 1.17-based DUT occupies the medium while a 2.x-based DUT backs off more. * Workaround: Upgrade all devices to release 2.x whenever possible, or allow for a longer association time in noisy environments. * 5dB range degradation can be seen in the presence of strong Adjacent Channel Interference (ACI) in 8 MHz channels. * Workaround: When possible, devices should be put further away from strong interferer signals * The issue will be resolved in later releases. * MM8108-M20 based modules may exhibit degraded subband reception at specific attenuation levels, which may occasionally cause association failures * Workaround: consider adding a 10 dB attenuation if devices are less than 10 m apart * The issue will be resolved in later releases. * Multi-STA unrecoverable drop to zero throughput. The issue is caused by the station going to 0 throughput for a few seconds due to medium contention, then iPerf gives up and drops the stream/connection. * The issue is only observable in large setups (7 or 8 stations), with unthrottled traffic. * Workaround: Limit the bitrate through -b if using iPerf * Adaptive RAW low throughput in a multi-STA network * Workaround: None **FullMAC** * FullMAC STA doesn't yet support interoperability with Newracom APs * Firmware crashes if burst exhaust duty cycle restrictions are exceeded * Workaround: Avoid overloading burst mode duty cycle packets * Firmware crashes in bi-directional high TCP throughput. The issue is intermittent and uncommon to occur * Recoverable through watchdog timer * Workaround: None * In a noisy environment, wpa\_supplicant can time out before the FullMAC association is complete. * Workaround: Use the iw connect command instead of wpa\_supplicant #### 2.1.4 Unsupported, Limited, and Deprecated Features * SoftMAC: * AP power save mode is not supported * Support for PV1 frames has been deprecated * Pre-association power save is disabled by default, but can be enabled via a module parameter. * FullMAC: * STA only, single interface (IBSS, MBSS, mesh Soft AP are not supported) * Some advanced Wi-Fi HaLow features are not yet supported (WPA3 Enterprise, U-APSD, DPP, NDP probes) ### 2.2 Release 2.0.0 This section summarizes software changes made since release 1.17.9. #### 2.2.1 New Features * Airtime fairness support * Airtime fairness (ATF) in the Linux wireless stack ensures that each station on an AP receives a fair share of channel *time*, not a fair share of *throughput*. It solves the "performance anomaly" in 802.11: without it, slow clients (distant, low-data-rate, or 802.11b/g legacy devices) monopolize the medium because transmitting the same amount of data takes them longer. Airtime primarily governs the download (i.e., AP to STAs). This is enabled by default for any Linux kernel > 6.2, and can be enabled through a module parameter for older kernels (unsupported for kernels < 5.10) * A-MSDU Support * A-MSDU (Aggregate MAC Service Data Unit) is an 802.11 frame aggregation technique introduced in 802.11n to improve efficiency by packing multiple payloads into a single transmission. This feature is dependent on ATF being enabled. Default for Linux kernel > 6.2, and can be enabled once ATF is enabled for earlier kernels (unsupported for kernels < 5.10) * FullMAC Support (Beta) * MM8108 firmware and driver can be configured to operate in FullMAC architecture. A FullMAC driver is a Linux WiFi driver architecture in which most of the 802.11 MAC-layer processing occurs on the device rather than in the host kernel. MM8108 FullMAC can only operate in STA mode. FullMAC is currently in beta support. For configuration and limitations, refer to "FullMAC Linux Driver User Guide". * FullMAC supports configurable channelization for AU. * MM8108-M20-US Module Support (engineering sampling) * MM8108-M20 combines Morse Micro's Wi-Fi HaLow silicon with an external high-power amplifier delivering high transmit output power, alongside a surface acoustic wave (SAW) filter tuned for the 902-928 MHz band in North America. For more details, see [MM8108 M20 High Power Wi-Fi HaLow Module](https://www.morsemicro.com/2026/06/01/morse-micro-announces-mm8108-m20-high-power-wi-fi-halow-module-to-accelerate-long-range-iot-adoption/). * Firmware failsafe boot error mode * Allows the firmware to enter a failsafe mode and report boot errors to quickly identify the failure reason #### 2.2.2 Resolved Issues and Improvements * Thin LMAC support: Multiple improvements have been added to improve Thin LMAC, including bug fixes and throughput improvements * PHY interference performance improvements, including: * Improved Out-Of-Band (OOB) detection and desensing * Improved DC calibration in the presence of interference * Optimized packet detection desensing under interference, improving the overall range * Improved initial PHY calibration timing, which reduces boot-up time by up to 30% * WiFi feature improvements, including improved DPP performance and DCS (Dynamic Channel Selection) bug fixes #### 2.2.3 Known Issues **SoftMAC** * A lower association success rate is observed when interoperating with older MM8108 software releases in high-noise environments. * The behavior can be attributed to the increased collision rate when a 1.17-based DUT is occupying the medium, while a 2.-based DUT is backing off more. * Workaround: Upgrade all devices to release 2.0 whenever possible, or allow for a longer association time in noisy environments. * Throughput degradation for multi-STA if WDS is enabled. This is due to disabling the max\_txq\_len modparam (i.e., set to 0) * Workaround: Update the driver to remove the disabling of max\_txq\_len and enable airtime fairness. * For more information, customers can review OpenWRT 3.1.0 driver patches. * An intermittent crash can occur when running on the SPI bus with A-MSDU enabled and traffic flowing bidirectionally. * Recoverable through watchdog timer * Workaround: Disable A-MSDU when using the SPI bus * Intermittent firmware assert/crash during calibration. The issue is intermittent and uncommon. * Recoverable through watchdog timer * No workaround. * Intermittent chip hangs during packet offloading transmission: Caused by incorrect packet size calculations. The issue is intermittent and uncommon. * Recoverable through watchdog timer * Workaround: Disable packet offloading * Health-check can fail/timeout while the chip is busy handling scan requests. The issue is intermittent, and occurs only when both commands trigger at the same time. * The issue is not watchdog-recoverable and will require a full chip reset * The TX power setting is not obeyed for the sub-band. The feature doesn't affect data packets but only management packets (e.g., beacons, Probe request/response) * Workaround: None * Multi-STA unrecoverable drop to zero throughput. The issue is caused by the station going to 0 throughput for a few seconds due to medium contention, then iPerf gives up and drops the stream/connection. * The issue is only observable in large setups (7 or 8 stations), with unthrottled traffic. * Workaround: Limit the bitrate through -b if using iPerf * Adaptive RAW low throughput in a multi-STA network * Workaround: None **FullMAC** * FullMAC STA doesn't support interoperability with Newracom APs * Firmware crashes if burst exhaust duty cycle restrictions are exceeded * Workaround: Avoid overloading burst mode duty cycle packets * Firmware crashes in bi-directional high TCP throughput. The issue is intermittent and uncommon to occur * Recoverable through watchdog timer * Workaround: None * In a noisy environment, wpa\_supplicant can time out before the FullMAC association is complete. * Workaround: Use the iw connect command #### 2.2.4 Unsupported, Limited, and Deprecated Features * SoftMAC: * AP power save mode is not supported * Support for PV1 frames has been deprecated * Standby power save mode is not supported in SoftMAC. * Pre-association power save is disabled by default, but can be enabled via a module parameter. * FullMAC: * STA only, single interface (IBSS, MBSS, mesh Soft AP are not supported) * Some advanced Wi-Fi features are not supported (WPA3 Enterprise, U-APSD, DPP, NDP probes) ### 2.3 Release 1.17.9 This section summarizes software changes made since release 1.17.8. | Long-Term Support (LTS) Linux Kernels supported in this release | | ------------------------------------------------------------------ | | 6.12.21, 6.6.31, 6.1.21, 5.15.61, 5.10.11, 5.4.83, 4.9.80, 4.19.66 | #### 2.3.1 New Features No new features since release 1.17.8 #### 2.3.2 Resolved Issues and Improvements Various security vulnerabilities have been addressed: * Out-of-bounds memory access when processing compatibility IE in beacons and probe responses * Out-of-bounds memory access when processing TIM IE in beacons * Out-of-bounds memory access when processing vendor IE in beacons. #### 2.3.3 Known Issues No new known issues since release 1.17.8 ### 2.4 Release 1.17.8 This section summarizes software changes made since release 1.16.4. | Long-Term Support (LTS) Linux Kernels supported in this release | | ------------------------------------------------------------------ | | 6.12.21, 6.6.31, 6.1.21, 5.15.61, 5.10.11, 5.4.83, 4.9.80, 4.19.66 | #### 2.4.1 New Features * 802.11s Mesh (Beta) * 802.11s Mesh is a Wi-Fi feature that allows multiple wireless devices to interconnect to create a wireless LAN mesh network. This can extend network coverage by creating wireless links that manage multiple paths between nodes. It can automatically recover connectivity and dynamically adjust routes in response to environmental changes. For more details on 802.11s, please refer to Morse Micro's Application Note 32: How to Configure 802.11s Mesh. * WNM Sleep * WNM Sleep is a power-saving mechanism that allows Stations to explicitly negotiate sleep schedules with the Access Point, reducing power consumption during idle periods. For more information about WNM sleep, please refer to Morse Micro's Application Note 34: Measuring Low Power Wi-Fi HaLow. * Centralized Authentication Control (CAC) * Centralized Authentication Control (CAC) can reduce the time required for a large number of Stations to associate by throttling the number of Stations that attempt to associate simultaneously, thereby minimizing contention for time-sensitive association. * Periodic Restricted Access Window (PRAW) * PRAW is a specific type of RAW where an Access Point reserves time slots at regular, recurring intervals for scheduled transmissions. This is crucial for sensors or devices that generate data on a regular schedule, as it mitigates contention on the medium and enables better power savings. * IEEE802.11-2024 AU channelization * The channelization for Australia was updated in IEEE802.11-2024 * Dynamic Target Wake Time (TWT): * Dynamic TWT allows Stations to renegotiate TWT service periods after connecting to the Access Point (rather than before). For more details on TWT configuration, please refer to Morse Micro's Application Note 3: Target Wake Time. * 802.11r Fast BSS Transition * This mode allows a Station to transition between Access Points without redoing key exchange, minimizing switching time for time-sensitive applications. #### 2.4.2 Resolved Issues and Improvements * Multi-STA performance has been improved for up to 8 Stations * Improved interference performance * During power save, the SDIO\_CLK pin is no longer driven low but is put into high impedance. System developers should ensure they do not drive a clock on the pin during these periods to avoid increased power consumption. #### 2.4.3 Known Issues * In Multi-STA setups, an unbalanced downlink can be seen if WDS is enabled. The issue can be mitigated by setting the `max_txq_len` module param to 0 (i.e., unlimited queue length) * Some receive degradation is seen at 2 MHz, at approximately -73dBm RSSI * Workaround: Increase or decrease the RSSI by 2 dB to resolve this issue * Some receive degradation is seen at 1 MHz at strong signals * Workaround: Move devices further apart to lower signal strength. * The maximum TCP throughput between MM6108 and MM8108 is approximately 10% lower than expected. This issue is expected to be resolved in a future release. * In environments with very strong interference signals (greater than -40 dBm), wireless performance may be reduced. Improvements are planned for a future release. * In rare cases, an assert may occur if STAs remain idle for several hours. When this happens, the watchdog timer automatically restores the chip to its original associated state. Recovery is seamless at the link level; however, upper-layer connections (e.g., TCP/UDP) may need to be reestablished. * When using the 1 MHz MCS 9 rate in the 868 MHz channel band, you may observe a lower EVM. In practice, the rate control algorithm automatically steps down to MCS8 to maintain reliable performance. An improvement is planned for a future release. * In multi-STA setups on devices running Linux kernel > 6.2, airtime fairness is not enabled by default, which may result in suboptimal wireless performance. * Workaround: Set the enable\_airtime\_fairness module parameter to true. Additional patches for improved airtime fairness are available in the Morse Micro OpenWrt feed packages. * When pairing two devices at very close range, the STA may intermittently fail to join the AP due to excessively strong received signal levels (greater than -10 dBm). * Workaround: Ensure at least 2 meters of separation between the AP and STA before initiating the pairing sequence to maintain reliable association. An improvement is planned for the next firmware release. * The MM810x driver's vendor Information Element (IE) handling contains an out-of-bounds memory access vulnerability. This issue will be resolved in future releases. * Workaround: Customers with security concerns regarding this vulnerability may apply a patch to mitigate the issue. For details, refer to the Morse Micro OpenWrt patch sets available on GitHub. #### 2.4.4 Unsupported, Limited, and Deprecated Features * This release supports SoftMAC only. FullMAC and Thin LMAC modes are available for beta evaluation only. * Standby power-save mode is not supported in SoftMAC. * Support for PV1 frames has been deprecated in 1.17.8. * Support for software scan in the Linux Driver has been deprecated in 1.17.8. ### 2.5 Release 1.16.4 This section summarizes software changes made since release 1.15.3. | Long-Term Support (LTS) Linux Kernels supported in this release | | --------------------------------------------------------------- | | 6.6.31, 5.15.61, 5.4.83, 4.19.66 | #### 2.5.1 New Features * Dynamic Channel Selection (DCS) support and Extended Channel Switch Announcement (ECSA) support * The system can now automatically switch to a better Wi-Fi HaLow channel to reduce interference (Dynamic Channel Selection) and seamlessly notify connected devices to follow (Extended Channel Switch Announcement), improving reliability and performance. * Support for 100% duty cycle in Europe with DCS enabled * Device Provisioning Protocol (DPP) support * Wi-Fi HaLow devices can be added securely without needing to share or type passwords, making setup faster and safer. * EasyMesh support * Multiple access points can work together in a single, self-organizing wide-area mesh network to provide extended coverage and reliability. * FullMAC support (beta - not for production) * Early support for FullMAC operation, simplifying Wi-Fi HaLow integration and development by handling more functions in the firmware * Please note that this feature is currently in beta testing for integration and development purposes. It is not considered suitable for mass production #### 2.5.2 Known Issues * When the Access Point (AP) bandwidth is fully saturated with more than four stations (STAs), aggregated throughput through the AP degrades. * Workaround: For use cases requiring multiple stations running continuous, high-bandwidth data streams, limit the number of stations to 4 to ensure optimal overall performance * Dynamic Target Wake Time (TWT) is not supported in this release * When using the SDIO host interface, if the SDIO clock pin continues to be driven by the host while the device is in power-save mode, it may result in additional VDDIO leakage * Workaround: Ensure the SDIO clock is idle when the device is in power-save mode * The maximum TCP throughput between MM6108 and MM8108 is approximately 10% lower than expected. This issue is expected to be resolved in a future release. * In environments with very strong interference signals (greater than -40 dBm), wireless performance may be reduced. This is a known limitation, and improvements are planned for a future release. * In rare cases, an assert may occur if STAs remain idle for several hours. When this happens, the watchdog timer automatically restores the chip to its original associated state. Recovery is seamless at the link level; however, upper-layer connections (e.g., TCP/UDP) may need to be reestablished. * In uncommon scenarios with intermittent traffic (e.g., a single packet every few seconds), a race condition may cause occasional packet loss if power-save mode is enabled exactly when a packet is queued for transmission. The overall impact is minimal, with expected loss rates of less than 5%. A fix is planned for the next release. * Some receive degradation is seen at 2 MHz, at approximately -73dBm RSSI * Workaround: Increase or decrease the RSSI by 2 dB to resolve this issue * When using the 1 MHz MCS 9 rate in the 868 MHz channel band, a lower EVM may be observed. In practice, the rate control algorithm automatically steps down to MCS8 to maintain reliable performance. An improvement is planned for the next firmware release. ## 3 Revision History | Version Number | Release Date | Release Notes | | -------------- | ------------ | ----------------- | | 1 | 22 Sep 2025 | Release FW 1.16.4 | | 2 | 20 Apr 2026 | Release FW 1.17.8 | | 3 | 01 May 2026 | Release FW 1.17.9 | | 4 | 29 Jun 2026 | Release FW 2.0.0 | | 5 | 03 Sep 2026 | Release FW 2.1.0 | # MM6108 Linux Software Release Notes v5 2.1.1 [Download as PDF](https://www.morsemicro.com/resources/software_releases/linux/driver_source_code/MM6108-Linux-Software-Release-Notes.pdf) ## 1 Overview The purpose of this document is to provide a summary of new software features and improvements implemented in the latest Linux firmware and driver. ## 2 Software Change Summary ### 2.1 Release 2.1.1 This section summarizes software changes made since release 2.0.1 | Long-Term Support (LTS) Linux Kernels supported in this release | | --------------------------------------------------------------------------- | | 6.12.21, 6.6.31, 6.1.21, 5.15.61, 5.10.11, 5.4.83, 4.19.66, 4.14.98, 4.9.80 | #### 2.1.1 New Features * Support for Argentina, Chile, Colombia, and Mexico regulatory domains * Hardware support is not guaranteed * Support for EN 304 220 #### 2.1.2 Improvements * Driver-based watchdog is now enabled by default * Improved RSSI reporting in high power modules * Pre-association power save is now supported on kernel 6.9 and later * Setting TX power is now supported on kernel 6.12 and later * Mixed SKB priority on management traffic no longer causes CCMP PN replay checks to drop legitimate frames #### 2.1.3 Known Issues * Enterprise (EAP-TLS) roaming may stall for up to 70 seconds on the first roam back to a previously associated AP - to be resolved in release 2.2 * On kernel 4.19, SAE-secured connections may fail to establish in some 4-address mode configurations. * DPP push-button enrollment with a second AP may fail in Japan due to an incorrect off-channel frequency mapping during chirp exchange * After burst-mode duty cycle airtime reallocation, ping/ARP may fail for a period of time * Uplink QoS NULL frames may occasionally collide and require retransmission following high-traffic beacons * ARP resolution can take up to one second after a roaming event * In rare cases, DPP may fail and must be retried * ThinLMAC mode does not support fragmentation in this release * When using SPI with an 8 MHz channel bandwidth, throughput stabilization may require more than 10 seconds * When ThinLMAC is used on a host without cryptographic acceleration support (e.g., ARMv8 Cryptography Extensions for AES and SHA), the maximum throughput in an 8 MHz channel will be lower than on a host with cryptographic acceleration support * When removing the Morse Micro driver, the Linux kernel may report the following benign warning: * WARNING: CPU: 1 PID: 11976 at net/mac80211/main.c:1397 ieee80211\_free\_ack\_frame+0x60/0x64 * An AP may intermittently fail a TWT operation certification test, but will pass upon retry * An AP may occasionally omit sending a broadcast ARP request prior to a ping, resulting in a delayed response * In rare instances, an iPerf session may require restarting after a channel switch announcement * When an AP and multiple STAs are transmitting significant traffic, CAC STA association time may be longer than usual * Using CTS-to-self (instead of RTS/CTS) can cause high ping loss * Workaround: Enable RTS/CTS * UDP throughput over IPv6 is lower than IPv4 when using 4 MHz and 8 MHz channels * Mixed configurations of U-APSD and non-UAPSD access categories are not supported * Workaround: All access categories must use the same configuration * iPerf will not start if the beacon interval is set to 5,000 or higher * Workaround: Configure the beacon interval to less than 5,000 * In rare cases, the STA may associate more slowly than expected and report an "MFP required" error * In regulatory domains with duty-cycle restrictions (e.g., in the EU and Japan): * Burst Mode is recommended, since without it, MCS10 does not provide usable bandwidth * MBSSID is not supported #### 2.1.4 Deprecated Features * Support for Morse Micro Proprietary beacon mode has been deprecated in 2.0.1 * Support for PV1 frames has been deprecated in 1.17.8 * Support for software scan in the Linux Driver has been deprecated in 1.17.8 ### 2.2 Release 2.0.1 This section summarizes software changes made since release 1.17.9 | Long-Term Support (LTS) Linux Kernels supported in this release | | --------------------------------------------------------------------------- | | 6.12.21, 6.6.31, 6.1.21, 5.15.61, 5.10.11, 5.4.83, 4.19.66, 4.14.98, 4.9.80 | #### 2.2.1 New Features * Brazil's regulatory domain * Failsafe boot error mode * Allows the firmware to enter a failsafe mode and report boot errors (e.g., invalid BCF) * Added a new option allowing suppression of all status frames during standby, useful for deployments that do not require standby state reporting * The driver now exposes the list of supported regulatory domains via sysfs * The Linux mac80211 pull interface is now enabled by default for kernels 6.2 and above #### 2.2.2 Improvements * Resolved 8MHz AP to STA aggregate throughput issue when airtime fairness and WDS are enabled * hostapd\_s1g and wpa\_supplicant\_s1g no longer require morse\_cli * A station in standby will no longer immediately enter snooze after initiating an SA exchange * Resolved an issue where a change in TX power may not always be applied * An AP will no longer release broadcast traffic until it has successfully transmitted the beacon. * Resolved an early-stage hardware lockup, causing crash notifications to not be received * Early wake timing after a beacon miss is now correctly adjusted for long beacon intervals * Improved the reliability of beacon loss detection and reduced false disconnections * Stations now return to sleep promptly after a single-frame transmission to a power-saving AP * The maximum BCF size has been increased from 1024 to 2048 bytes * The STA will now exit standby for re-association when a TSF reset (BSS restart) is detected, avoiding stale association state after an AP restart * The STA can now be configured to send a protected 802.11 disassociation frame to the AP upon standby wake, enabling cleaner re-association flows. * NDP probe requests and responses now support 2 MHz operation, rather than always defaulting to 1 MHz * A watchdog-based recovery mechanism has been added for SDIO or SPI bus failures, allowing the driver to reset and reinitialize the bus without a full system restart * The driver now tracks beacon offload DTIM state correctly across suspend/resume cycles, preventing DTIM count drift after wake * The firmware path is now accessible via sysfs rather than debugfs, making it available in production configurations where debugfs is not mounted * The driver now tells MMRC when a packet was not acknowledged, improving rate selection under lossy conditions. * Management frames are now always enqueued at the highest TID on the hardware TX path, preventing CCMP PN replay drops caused by mixed SKB priorities * The driver now correctly handles the case where an association response is not acknowledged, retrying the association rather than leaving the STA stuck #### 2.2.3 Known Issues * With AP Power Save enabled, the DTIM beacon TIM bit may be sent twice when buffered broadcast traffic is present, and beacon generation failures (ret: -11) have been observed * The -11 error is benign and does not impact operation * AP command page exhaustion error seen intermittently in 1 MHz with low MCS * ACS occasionally selects an unexpected 8 MHz channel due to noise spikes * With enable\_short\_bcn\_as\_dtim\_override enabled, STAs wake on excess normal beacons and listen interval behavior is incorrect * Ping failures may be observed in 802.11s mesh with fragmentation * TCP performance in an 802.11s mesh with MM8108 devices may be lower than with MM6108 only * hostapd will not start if using India regulatory domain and a local operating class 6 * Global operating class 66 will work * ARP resolution can take up to one second after a roaming event * In rare cases, DPP may fail and must be retried * ThinLMAC mode does not support fragmentation in this release * When using SPI with an 8 MHz channel bandwidth, throughput stabilization may require more than 10 seconds * When ThinLMAC is used on a host without cryptographic acceleration support (e.g., ARMv8 Cryptography Extensions for AES and SHA), the maximum throughput in an 8 MHz channel will be lower than on a host with cryptographic acceleration support * When removing the Morse Micro driver, the Linux kernel may report the following benign warning: * WARNING: CPU: 1 PID: 11976 at net/mac80211/main.c:1397 ieee80211\_free\_ack\_frame+0x60/0x64 * An AP may intermittently fail a TWT operation certification test, but will pass upon retry * An AP may occasionally omit sending a broadcast ARP request prior to a ping, resulting in a delayed response * In rare instances, an iPerf session may require restarting after a channel switch announcement * When an AP and multiple STAs are transmitting significant traffic, the CAC STA association time may be longer than usual * Using CTS-to-self (instead of RTS/CTS) can cause high ping loss * Workaround: Enable RTS/CTS * UDP throughput over IPv6 is lower than IPv4 when using 4 MHz and 8 MHz channels * Mixed configurations of U-APSD and non-UAPSD access categories are not supported * Workaround: All access categories must use the same configuration * iPerf will not start if the beacon interval is set to 5,000 or higher * Workaround: Configure the beacon interval to less than 5,000 * In rare cases, the STA may associate more slowly than expected and report an "MFP required" error * In regulatory domains with duty-cycle restrictions (e.g., in the EU and Japan): * Burst Mode is recommended, since without it, MCS10 does not provide usable bandwidth * MBSSID is not supported #### 2.2.4 Deprecated Features * Support for PV1 frames has been deprecated in 1.17.8 * Support for software scan in the Linux Driver has been deprecated in 1.17.8 ### 2.3 Release 1.17.9 This section summarizes software changes made since release 1.17.8. | Long-Term Support (LTS) Linux Kernels supported in this release | | --------------------------------------------------------------------------- | | 6.12.21, 6.6.31, 6.1.21, 5.15.61, 5.10.11, 5.4.83, 4.19.66, 4.14.98, 4.9.80 | #### 2.3.1 New Features No new features from 1.17.8 #### 2.3.2 Improvements * Resolved an issue where, in busy or congested HaLow environments, the firmware may crash when waking from snooze mode, requiring a reset via the reset pin #### 2.3.3 Known Issues * When using WDS, throughput sharing may be affected. Setting `max_txq_len` to `0` will severely degrade performance for stations in power-saving mode. * No known workaround * ARP resolution can take up to one second after a roaming event * In rare cases, DPP may fail and must be retried * ThinLMAC mode does not support fragmentation in this release * When using SPI with an 8 MHz channel bandwidth, throughput stabilization may require more than 10 seconds * When ThinLMAC is used on a host without cryptographic acceleration support (e.g., ARMv8 Cryptography Extensions for AES and SHA), the maximum throughput in an 8 MHz channel will be lower than on a host with cryptographic acceleration support * When removing the Morse Micro driver, the Linux kernel may report the following benign warning: * WARNING: CPU: 1 PID: 11976 at net/mac80211/main.c:1397 ieee80211\_free\_ack\_frame+0x60/0x64 * An AP may intermittently fail a TWT operation certification test, but will pass upon retry * An AP may occasionally omit sending a broadcast ARP request prior to a ping, resulting in a delayed response * In rare instances, an iPerf session may require restarting after a channel switch announcement * When an AP and multiple STAs are transmitting significant traffic, CAC STA association time may be longer than usual * Using CTS-to-self (instead of RTS/CTS) can cause high ping loss * Workaround: Enable RTS/CTS * UDP throughput over IPv6 is lower than IPv4 when using 4 MHz and 8 MHz channels * Mixed configurations of U-APSD and non-UAPSD access categories are not supported * Workaround: All access categories must use the same configuration * iPerf will not start if the beacon interval is set to 5,000 or higher * Workaround: Configure the beacon interval to less than 5,000 * In rare cases, the STA may associate more slowly than expected and report an "MFP required" error * In regulatory domains with duty-cycle restrictions (e.g., in the EU and Japan): * Burst Mode is recommended, since without it, MCS10 does not provide usable bandwidth * MBSSID is not supported ### 2.4 Release 1.17.8 This section summarizes software changes made since release 1.16.4. | Long-Term Support (LTS) Linux Kernels supported in this release | | --------------------------------------------------------------------------- | | 6.12.21, 6.6.31, 6.1.21, 5.15.61, 5.10.11, 5.4.83, 4.19.66, 4.14.98, 4.9.80 | #### 2.4.1 New Features * DHCP Rapid Commit * The offloaded DHCP client now supports DHCP Rapid Commit, allowing for IP address negotiation in just two frames. Needs a DHCP server on the network to support this feature. * IEEE802.11-2024 AU channelization * The channelization for Australia was updated in IEEE802.11-2024 * Connection Quality Management for 802.11r * AP Power Management (beta, feature preview, not for production) * Allow an Access Point to sleep between beacons. Stations must support the Maximum Away Duration Information Element (MAD IE) during association to connect to Access Points in this mode. #### 2.4.2 Improvements * Improved PHY behavior to ensure smooth operation when accessing the medium * Enhanced ACS channel selection to avoid disabled channels and improve reliability * Improved robustness of DPP PKEX handling on slower host processors * Enhanced driver stability by addressing memory handling during hardware restart #### 2.4.3 Known Issues * In busy or congested HaLow environments, the firmware may crash when waking from snooze mode, requiring a reset via the reset pin * Workaround: Disable power save. * When using WDS, throughput sharing may be affected. Setting `max_txq_len` to `0` will severely degrade performance for stations in power-saving mode. * No known workaround * ARP resolution can take up to one second after a roaming event * In rare cases, DPP may fail and must be retried * ThinLMAC mode does not support fragmentation in this release * When using SPI with an 8 MHz channel bandwidth, throughput stabilization may require more than 10 seconds * When ThinLMAC is used on a host without cryptographic acceleration support (e.g., ARMv8 Cryptography Extensions for AES and SHA), the maximum throughput in an 8 MHz channel will be lower than on a host with cryptographic acceleration support * When removing the Morse Micro driver, the Linux kernel may report the following benign warning: * WARNING: CPU: 1 PID: 11976 at net/mac80211/main.c:1397 ieee80211\_free\_ack\_frame+0x60/0x64 * An AP may intermittently fail a TWT operation certification test, but will pass upon retry * An AP may occasionally omit sending a broadcast ARP request prior to a ping, resulting in a delayed response * In rare instances, an iPerf session may require restarting after a channel switch announcement * When an AP and multiple STAs are transmitting significant traffic, CAC STA association time may be longer than usual * Using CTS-to-self (instead of RTS/CTS) can cause high ping loss * Workaround: Enable RTS/CTS * UDP throughput over IPv6 is lower than IPv4 when using 4 MHz and 8 MHz channels * Mixed configurations of U-APSD and non-UAPSD access categories are not supported * Workaround: All access categories must use the same configuration * iPerf will not start if the beacon interval is set to 5,000 or higher * Workaround: Configure the beacon interval to less than 5,000 * In rare cases, the STA may associate more slowly than expected and report an "MFP required" error * In regulatory domains with duty-cycle restrictions (e.g., in the EU and Japan): * Burst Mode is recommended, since without it, MCS10 does not provide usable bandwidth * MBSSID is not supported #### 2.4.4 Deprecated Features * Support for PV1 frames has been deprecated in 1.17.8 * Support for software scan in the Linux Driver has been deprecated in 1.17.8 ### 2.5 Release 1.16.4 This section summarizes software changes made since release 1.15.3. | Long-Term Support (LTS) Linux Kernels supported in this release | | --------------------------------------------------------------------------- | | 6.12.21, 6.6.31, 6.1.21, 5.15.61, 5.10.11, 5.4.83, 4.19.66, 4.14.98, 4.9.80 | #### 2.5.1 New Features * Android Packet Filters and Android Wake-on-WLAN * Allows Android to configure the Wi-Fi firmware to filter out unnecessary packets and only wake the main processor for relevant network activity, reducing wakeups while ensuring the device responds to important events such as keep-alives and incoming messages * Kernel 6.12 support * Compilation support for the 6.12 series of the Linux kernel * Automatic RAW configuration * Support for automatically grouping stations into RAW groups, negating the need to manually configure RAW * Reattach to firmware * Ability to configure the driver to skip firmware download on boot if firmware is already running on the chip. This will still reset the configuration #### 2.5.2 Improvements * DPP improvements * Improved frequency selection for handshaking * Improved reliability when announcements stop * The sae\_password field is no longer required for the DPP push button * Improvements to the subband selection when an AP responds to 1 MHz probe requests * Improved resilience to a mismatch in priority with QoS Control field * Improvements to directed frame buffering logic when connected to power-saving 4 address mode stations * Improvements to the channel selection when an AP responds to 2 MHz probe requests #### 2.5.3 Known Issues * ARP resolution can take up to one second after a roaming event * Connection quality monitoring is not currently supported, requiring roaming to be initiated manually * In rare cases, DPP may fail and must be retried * ThinLMAC mode does not support fragmentation in this release * When using SPI with an 8 MHz channel bandwidth, throughput stabilization may require more than 10 seconds * When ThinLMAC is used on a host without cryptographic acceleration support (e.g., ARMv8 Cryptography Extensions for AES and SHA), the maximum throughput in an 8 MHz channel will be lower than on a host with cryptographic acceleration support * When removing the Morse Micro driver, the Linux kernel may report the following benign warning: * WARNING: CPU: 1 PID: 11976 at net/mac80211/main.c:1397 ieee80211\_free\_ack\_frame+0x60/0x64 * An AP may intermittently fail a TWT operation certification test, but will pass upon retry * An AP may occasionally omit sending a broadcast ARP request prior to a ping, resulting in a delayed response * In rare instances, an iPerf session may require restating after a channel switch announcement * When an AP and multiple STAs are transmitting significant traffic, CAC STA association time may be longer than usual * Using CTS-to-self (instead of RTS/CTS) can cause high ping loss * Workaround: Enable RTS/CTS * UDP throughput over IPv6 is lower than IPv4 when using 4 MHz and 8 MHz channels * Mixed configurations of U-APSD and non-UAPSD access categories are not supported * Workaround: All access categories must use the same configuration * iPerf will not start if the beacon interval is set to 5,000 or higher * Workaround: Configure the beacon interval to less than 5,000 * In rare cases, the STA may associate more slowly than expected and report an "MFP required" error * In regulatory domains with duty-cycle restrictions (e.g., in the EU and Japan): * Burst Mode is recommended, since without it, MCS10 does not provide usable bandwidth * MBSSID is not supported ## 3 Revision History | Version Number | Release Date | Release Notes | | -------------- | ------------ | ----------------- | | 1 | 01 Oct 2025 | Release FW 1.16.4 | | 2 | 19 Apr 2026 | Release FW 1.17.8 | | 3 | 04 May 2026 | Release FW 1.17.9 | | 4 | 26 Jun 2026 | Release FW 2.0.1 | | 5 | 03 Sep 2026 | Release FW 2.1.1 | # HaLowLink2 Software Release Notes v2 2.11.13 Download as PDF ## 1 Overview This document describes the software changes included in release 2.11.13 of the HaLowLink 2 OpenWrt software package. HaLowLink 2 is Morse Micro's Wi-Fi HaLow (802.11ah) access point and extender platform, designed for long-range, low-power IoT connectivity. The software runs on OpenWrt and is managed through the device's web-based user interface. Release 2.11.13 addresses security compliance improvements by updating the MM8108 driver and firmware. Customers running v2.11.12 or v2.11.8 are encouraged to upgrade. To upgrade your device, navigate to the Upgrade page in the web UI. An active internet connection is required. ## 2 Software Change Summary ### 2.1 Release 2.11.13 Release 2.11.13 is a maintenance release for HaLowLink 2 following release v2.11.12. It updates the MM8108 driver and firmware package to version 1.17.9, which fixes the reported security vulnerabilities. There are no new end-user features in this release. #### 2.1.1 New Features * There are no new features in this release. The MM8108 driver and firmware have been updated to version 1.17.9; this update delivers the security improvements described below and introduces no new end-user functionality. * For a full list of MM8108 driver features, refer to the MM8108 Linux Software Release Notes (1.17.9). #### 2.1.2 Resolved Issues and Improvements **2.1.2.1 Security compliance improvements** * Hardened parsing of 802.11 management-frame information elements (IEs) against malformed input: * Added bounds validation for vendor-specific IE lengths, preventing out-of-bounds reads. * Protected against a buffer overflow when parsing the Traffic Indication Map (TIM) information element. * Protected against a buffer overflow when parsing the S1G Capabilities information element. #### 2.1.3 Known Issues All known issues reported in release 2.11.12 are carried forward unchanged into 2.11.13; this release does not resolve any of them. They are listed again below for completeness. **2.1.3.1 Unbalanced downlink distribution in multi-STA scenarios** * In multi-STA setups, an unbalanced downlink distribution may be observed when traffic is sent simultaneously to more than four stations, with the first two associated stations potentially monopolizing the medium. * Workaround: Enable airtime fairness on the HaLowLink 2 (enable\_airtime\_fairness=1). **2.1.3.2 Receive degradation at 2 MHz near -73 dBm RSSI** * Some degradation is observed at 2 MHz, with an RSSI of approximately -73 dBm. * Workaround: Increase or decrease the RSSI by 2 dB to resolve this issue. **2.1.3.3 Receive degradation at 1 MHz at strong signals** * Some degradation is seen at 1 MHz at strong signal levels. * Workaround: Move the devices farther apart to lower the signal strength. **2.1.3.4 Intermittent STA association failure at very close range** * When pairing two devices at very close range, the STA may intermittently fail to join the HaLowLink 2 due to excessively strong received signal levels (greater than -10 dBm). * Workaround: Ensure a minimum separation of 2 meters between the HaLowLink 2 and STA before initiating the pairing sequence to maintain reliable association. An improvement is planned for a future firmware release. ### 2.2 Release 2.11.12 Release 2.11.12 is the first maintenance release for HaLowLink 2 following the production release v2.11.8. It includes security compliance improvements, stability fixes for high-density deployments, and an updated MM8108 driver and firmware package. There are no new end-user features in this release. #### 2.2.1 New Features * There are no new features in this release. The MM8108 driver and firmware have been updated to version 1.17.8; however, all features introduced in that driver version were already available in the HaLowLink 2 production release v2.11.8. * For a full list of MM8108 driver features, refer to the MM8108 Linux Software Release Notes v2 (1.17.8). #### 2.2.2 Resolved Issues and Improvements **2.2.2.1 Security compliance improvements** * Updated OpenSSL configuration to meet current security standards, ensuring compatibility with stricter TLS requirements and audit criteria. * Addressed a CWE-125 security weakness. **2.2.2.2 Multi-STA performance** * Multi-STA performance has been improved for up to 8 stations. * Improved interference performance in AP mode: beacon transmission is now maintained under high levels of adjacent-channel interference. * Enhanced stability in high-density deployments: resolved a firmware crash that could occur when operating with 32 or more connected STAs. **2.2.2.3 Documentation** * The user guide now lists all open network ports, with justification and usage context for each. #### 2.2.3 Known Issues **2.2.3.1 Unbalanced downlink distribution in multi-STA scenarios** * In multi-STA setups, an unbalanced downlink distribution may be observed when traffic is sent simultaneously to more than four stations, with the first two associated stations potentially monopolizing the medium. * Workaround: Enable airtime fairness on the HaLowLink 2 (enable\_airtime\_fairness=1). **2.2.3.2 Receive degradation at 2 MHz near -73 dBm RSSI** * Some degradation is observed at 2 MHz, with an RSSI of approximately -73 dBm. * Workaround: Increase or decrease the RSSI by 2 dB to resolve this issue. **2.2.3.3 Receive degradation at 1 MHz at strong signals** * Some degradation is seen at 1 MHz at strong signal levels. * Workaround: Move the devices farther apart to lower the signal strength. **2.2.3.4 Intermittent STA association failure at very close range** * When pairing two devices at very close range, the STA may intermittently fail to join the HaLowLink 2 due to excessively strong received signal levels (greater than -10 dBm). * Workaround: Ensure a minimum separation of 2 meters between the HaLowLink 2 and STA before initiating the pairing sequence to maintain reliable association. An improvement is planned for the next firmware release. ## 3 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | ----------------------- | | Version 2 | 4 Jun 2026 | Release OpenWrt 2.11.13 | | Version 1 | 24 Apr 2026 | Release OpenWrt 2.11.12 | Morse Micro provides this information "as is" without warranties of any kind, express or implied. No guarantee is made as to the accuracy, completeness, or suitability of this information or Morse Micro’s products for any specific purpose. Use of this information and products is at the user’s sole risk. Morse Micro products are not designed or tested for use in mission-critical systems, and should not be used in such applications. Performance specifications are based on internal testing and are believed to be reliable; however, they are not guaranteed. It is the Buyer’s responsibility to test and validate all product performance, compatibility, and compliance, both in isolation and within end applications. Morse Micro assumes no liability for the use or application of any product, circuit, or information described herein. No license or other rights—express or implied—are granted under Morse Micro’s intellectual property. This document contains proprietary information of Morse Micro and is subject to change without notice. Wi-Fi®, Wi-Fi HaLow™, and the Wi-Fi logo are trademarks of Wi-Fi Alliance. ZigBee™ and Z-Wave™ are trademarks of their respective owners. All other trademarks are the property of their respective owners. # HaLowLink1 Software Release Notes v2 (2.11.13) Download as PDF ## 1 Overview This document describes the software changes included in release 2.11.13 of the HaLowLink 1 OpenWrt software package. HaLowLink 1 is Morse Micro's Wi-Fi HaLow (802.11ah) access point and extender platform, designed for long-range, low-power IoT connectivity. The software runs on OpenWrt and is managed through the device's web-based user interface. Release 2.11.13 addresses security compliance improvements by updating the MM6108 driver and firmware (1.17.8 → 1.17.9). Customers running v2.11.12 are encouraged to upgrade. To upgrade your device, navigate to the Upgrade page in the web UI. An active internet connection is required. ## 2 Software Change Summary ### 2.1 Release 2.11.13 Release 2.11.13 is a maintenance release for HaLowLink 1 following release v2.11.12. It updates the MM6108 driver and firmware package to version 1.17.9, which fixes the reported security vulnerabilities. There are no new end-user features in this release. #### 2.1.1 New Features * There are no new features in this release. The MM6108 driver and firmware have been updated to version 1.17.9; this update delivers the security improvements described below and introduces no new end-user functionality. * For a full list of MM6108 driver features, refer to the MM6108 Linux Software Release Notes (1.17.9). #### 2.1.2 Resolved Issues and Improvements **2.1.2.1 Security compliance improvements** * Hardened parsing of 802.11 management-frame information elements (IEs) against malformed input: * Added bounds validation for vendor-specific IE lengths, preventing out-of-bounds reads. * Protected against a buffer overflow when parsing the Traffic Indication Map (TIM) information element. * Protected against a buffer overflow when parsing the S1G Capabilities information element. #### 2.1.3 Known Issues All known issues reported in release 2.11.12 are carried forward unchanged into 2.11.13; this release does not resolve any of them. They are listed again below for completeness. **2.1.3.1 Unbalanced downlink distribution in multi-STA scenarios** * In multi-STA setups, an unbalanced downlink distribution may be observed when traffic is sent simultaneously to more than four stations, with the first two associated stations potentially monopolizing the medium. * Workaround: Enable airtime fairness on the HaLowLink 1 (enable\_airtime\_fairness=1). **2.1.3.2 Performance constraints** * UDP throughput over IPv6 is lower than IPv4 when using 4 MHz and 8 MHz channels * In regulatory domains with duty-cycle restrictions (e.g., EU, Japan), MCS10 may not provide usable bandwidth without Burst Mode * Workaround: Enable Burst Mode **2.1.3.3 Networking and protocol behavior** * In rare cases, the STA may associate more slowly than expected and report an “MFP required” error * In rare cases, DPP provisioning may fail and require retry ### 2.2 Release 2.11.12 Release 2.11.12 is the third maintenance release for HaLowLink 1 following release v2.7.6. It includes security compliance updates, stability improvements for high-density deployments, and an upgrade to the MM6108 driver and firmware package (1.14.1 → 1.17.8), bringing cumulative enhancements in performance, reliability, and standards compliance. #### 2.2.1 New Features * Driver and firmware upgrade (1.14.1 → 1.17.8)\ Updated MM6108 driver and firmware package, incorporating multiple enhancements in performance, stability, and standards compliance across intermediate releases. * Scheduled Scan support\ Enables periodic background scanning to improve network discovery and roaming behavior. * Additional driver capabilities (internal enhancements)\ Includes support for features such as improved provisioning workflows, enhanced power management capabilities, and extended platform compatibility introduced across driver releases. For full details, refer to the MM6108 Linux Software Release Notes (v1.17.8). #### 2.2.2 Resolved Issues and Improvements **2.2.2.1 Security compliance improvements** * Updated OpenSSL configuration to meet current security standards, ensuring compatibility with stricter TLS requirements and audit criteria. * Addressed a CWE-125 security weakness. **2.2.2.2 Multi-STA performance** * Multi-STA performance has been improved for up to 8 stations. * Improved buffering and delivery for power-saving and 4-address mode stations * Enhanced stability in high-density deployments: resolved a firmware crash that could occur when operating with 32 or more connected STAs. **2.2.2.3 System stability and performance** * Improved PHY behavior for more stable medium access and link performance * Enhanced Automatic Channel Selection (ACS) * Fixed issues where noise was not measured correctly * Avoids use of disabled or invalid channels * Improved handling of wider channel configurations * Prevents unnecessary disabling of channels due to sub-channel restrictions * Improved QoS behavior: * Fixed excessive transmission of inactivity QoS NULL frames * Improved resilience to QoS priority mismatches * Improved scan and association behavior: * Fixed issues with scan timeouts and standby recovery * Fixed incorrect probe response bandwidth handling * Improved driver stability: * Resolved memory handling issues during hardware restart * Fixed firmware crash scenarios in mesh configurations **2.2.2.4 DPP push-button reliability** * Improved robustness of DPP provisioning workflows, including push-button pairing reliability **2.2.2.5 802.11s Mesh** * Resolved issues affecting multi-hop traffic delivery, including DHCP propagation across mesh nodes * Optimizations to 802.11s mesh routing (HWMP) for improved multi-hop performance * Improved mesh self-healing behavior through default configuration changes * Avoided unnecessary HWMP frame generation when alternative mesh protocols are in use * Fixed issues affecting mesh stability, including crash conditions and traffic forwarding inconsistencies **2.2.2.4 Documentation** * The user guide now lists all open network ports, with justification and usage context for each. #### 2.2.3 Known Issues **2.2.3.1 Unbalanced downlink distribution in multi-STA scenarios** * In multi-STA setups, an unbalanced downlink distribution may be observed when traffic is sent simultaneously to more than four stations, with the first two associated stations potentially monopolizing the medium. * Workaround: Enable airtime fairness on the HaLowLink 1 (enable\_airtime\_fairness=1). **2.2.3.2 Performance constraints** * UDP throughput over IPv6 is lower than IPv4 when using 4 MHz and 8 MHz channels * In regulatory domains with duty-cycle restrictions (e.g., EU, Japan), MCS10 may not provide usable bandwidth without Burst Mode * Workaround: Enable Burst Mode **2.2.3.3 Networking and protocol behavior** * In rare cases, the STA may associate more slowly than expected and report an “MFP required” error * In rare cases, DPP provisioning may fail and require retry ## 3 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | ------------------------------------------ | | Version 2 | 04 Jun 2026 | Third maintenance release OpenWrt 2.11.13 | | Version 1 | 01 May 2026 | Second maintenance release OpenWrt 2.11.12 | Morse Micro provides this information "as is" without warranties of any kind, express or implied. No guarantee is made as to the accuracy, completeness, or suitability of this information or Morse Micro’s products for any specific purpose. Use of this information and products is at the user’s sole risk. Morse Micro products are not designed or tested for use in mission-critical systems, and should not be used in such applications. Performance specifications are based on internal testing and are believed to be reliable; however, they are not guaranteed. It is the Buyer’s responsibility to test and validate all product performance, compatibility, and compliance, both in isolation and within end applications. Morse Micro assumes no liability for the use or application of any product, circuit, or information described herein. No license or other rights—express or implied—are granted under Morse Micro’s intellectual property. This document contains proprietary information of Morse Micro and is subject to change without notice. Wi-Fi®, Wi-Fi HaLow™, and the Wi-Fi logo are trademarks of Wi-Fi Alliance. ZigBee™ and Z-Wave™ are trademarks of their respective owners. All other trademarks are the property of their respective owners. # MM8108 Windows USB Driver Software Release Notes v1 1.0.2 [Download as PDF](https://www.morsemicro.com/resources/software_releases/windows/MM8108-USB-Driver-for-Windows-Release-Notes.pdf) ## 1 Overview This document summarizes the software features implemented in the first release of the MM8108 USB Driver for Windows. ## 2 Software Change Summary ### 2.1 Release 1.0.2 This is the first release of the Windows driver, enabling the USB network adapter to operate in station mode and allowing a Windows PC to connect to a Wi-Fi HaLow network as a client. #### 2.1.1 New Features * Based on MM8108 firmware version 2.1.0. * Windows 11 Support, starting from 24H2. * Station mode only; no AP mode available. * WPA3-SAE encryption. * Regions supported: * Argentina (AR) * Australia (AU) * Brazil (BR) * Chile (CL) * Colombia (CO) * Europe (EU) * Japan (JP) * Mexico (MX) * United State (US) * *Note: The exact region(s) supported will depend on the hardware being used. Please check the label on the packaging of the USB Network adapter to confirm it is the correct model for your region.* #### 2.1.2 Resolved Issues and Improvements * None ## 3 Revision History | Version Number | Release Date | Release Notes | | -------------- | ------------ | --------------- | | 1 | 16 Sep 2026 | Initial Release | # MM-IoT-SDK Software Release Notes v5 2.13.1 [Download as PDF](https://www.morsemicro.com/resources/software_releases/iot/MM-IoT-SDK-Software-Release-Notes.pdf) ## 1 Overview The Morse Micro IoT SDK includes the host-side components needed to use an MCU with an MM6108 or MM8108 transceiver. This includes drivers, the Upper MAC (UMAC) layer, the network stack, and the RTOS. The MM IoT SDK release package includes the following: * **morselib:** a library containing the Morse Micro driver, UMAC, and WPA supplicant. * **Source code:** RTOS (FreeRTOS), network stack (LwIP, mbedTLS, coreMQTT, etc.), platform BSPs, and shim layers. * **Example applications:** Various example applications to aid in understanding how to use the SDK and accelerate development efforts. * **Additional libraries developed by Morse Micro:** mmconfig for key-value persistent storage and mmagic for CLI interface generation. * **API documentation:** for Makefile-based development. * **Getting Started Guide:** for Makefile-based development. * **Setup scripts:** development machine setup scripts and tools. The SDK supports Makefile-based development on Linux with experimental support on macOS. Ubuntu 22.04 x86\_64 is the officially supported Linux distribution. ## 2 Software Change History ### 2.1 Release 2.13.1 This section outlines significant changes from release 2.12.3. #### 2.1.1 New Features * Updated Morse firmware and BCFs to version 2.0. * NOTE: MM8108 2.0 has a breaking BCF API change. New BCF files **must** be used. See section “Migration from 2.12.3 - BCF Files” below. * Added topology depth awareness to the relay subsystem. * Added support for uniform SSID in relay mode. * Added support for fast recovery of relay tree on link failure. #### 2.1.2 Other Improvements * Added additional validation to mmhal\_read\_mac\_addr to ensure station MAC address is valid. * Added support for constraining the channel list used when scanning, enabling targeted scans over a specified set of channels. * Added additional threading tests to Porting Assistant. * Increased timer pool for LWIP on-demand timers. * Added mmwlan API to configure the beacon loss count threshold. * Added a helper function to dump Morse chip stats to MCU console log in hex format. * Added ability to insert Vendor IEs into beacons and probe responses. * Added additional AP mode parameters to mmconfig. * Implemented buffering of management frames for power-saving STAs. * Improved validation of AP enable arguments. * Added transmit of 4-address Quality of Service (QoS) Null frame when relay is enabled. * Added relay API to query relay system state. * Added relay API to query the current relay depth. * Added test API to set relay depth override. * Added a requirement to enable relay mode before enabling the STA or AP interface. * Added relay API to register a callback on depth change. * Updated relay disable to return success when not active. * Restricted STA scan to the AP's primary channel when in relay mode. * Prevent STA mode from being enabled when the system is a relay root node. * Added LED status indicators to relay mode example application. * Updated relay example application for recent API changes. #### 2.1.3 Bug Fixes * Fixed unreleased TCP/IP lock in LWIP netif status callback. * Fixed inaccurate documentation for mmconfig wlan.duty\_cycle\_mode. * Fixed missing newline in LWIP error log. * Fixed the AP interface incorrectly registering as the active network interface during relay mode. * Fixed AP responding to probe requests on non-primary channels. * Fixed AP beacon incorrectly signaling buffered traffic. * Fixed relay node dropping broadcast traffic it generated. * Fixed relay node dropping traffic from downstream STA. #### 2.1.4 Known Issues **2.1.4.1 Makefile Infrastructure** * Building fails when the MM-IoT-SDK package directory has a space in the path * The MM-IoT-SDK package must be unpacked into a directory without spaces in its name. **2.1.4.2 RTOS** * Timeouts with FreeRTOS time slicing disabled * FreeRTOS time slicing is enabled by default in the MM-IOT-SDK FreeRTOS configuration. If this is disabled, timeouts may be observed when sending commands to the MM chip. * System time drifts on STM32-based reference platforms because of the low-accuracy clock. Higher accuracy can be achieved by switching to the High-Speed External (HSE) clock source at the cost of higher power consumption when active. **2.1.4.3 Example Applications** * Failures when lwIP is built with LWIP\_IPV4=0 * If IPv4 is disabled when LWIP is built (i.e., IPv6-only), the IP stack may not work as expected. The workaround is to always enable IPv4. **2.1.4.4 AP Mode (Alpha Release)** *Note that AP Mode is in alpha and is not intended for production use.* * Traffic is not forwarded between STAs * AP mode does not forward frames between connected STAs. Therefore, connected STAs cannot communicate with each other unless bridging is implemented at the application layer. * This functionality can be achieved by enabling relay mode and setting the AP as the root node. No changes are required on the STA devices to facilitate this. * Recovery from health failures is not supported in AP mode * If a health check failure occurs while operating in AP mode, it will trigger a system restart. * Mitigation is to disable the health check by invoking: mmwlan\_set\_health\_check\_interval(0, 0); * OWE security is not supported * Mitigation is to use Open or SAE security. * EU, GB, and IN regulatory domains are not supported in AP mode. **2.1.4.5 DPP (Beta Release)** *Note that DPP is in beta and is not intended for production use.* * DPP must be stopped explicitly before shutdown * If DPP has been started (via mmwlan\_dpp\_start()), it must be stopped explicitly via mmwlan\_dpp\_stop() prior to invocation of mmwlan\_shutdown(). **2.1.4.6 Stability** * Some link instability may occur at specific signal levels, resulting in an elevated packet error rate. * Minor changes to the distance from the AP, antenna orientation, or environment will correct it. #### 2.1.5 Migration from 2.12.3 **2.1.5.1 BCF Files** MM8108 2.0.0 Firmware has a breaking API change in the BCF API. This requires updating the BCF file. The MM8108 chip will not perform any RF operations if an old BCF file is loaded. NOTE: Even when there are no breaking changes, we recommend updating to the latest BCF file. #### 2.1.6 Components | Component | Version | | --------------------- | ---------------------- | | MM6108 Morse Firmware | mm6108-2.0.1 | | MM6108 BCF API | 12.1.0\* | | MM8108 Morse Firmware | mm8108-2.0.0 | | MM8108 BCF API | 13.1.0^ | | Regulatory Database | 2.8.0 | | FreeRTOS kernel | 11.2.0 | | LWIP | 2.2.0 (+modifications) | | mbedTLS | 3.6.5 | | STM32U5 BSP | 1.8.0 | | STM32WB55 BSP | 1.14.1 | \* Backward compatible with 8.0.0, but features may be limited. ^ API not backward-compatible; BCF must be updated. ### 2.2 Release 2.12.3 This section outlines significant changes from release 2.11.2. #### 2.2.1 New Features * Device Provisioning Protocol (DPP), QR code mode functionality as STA (Beta) #### 2.2.2 Other Improvements * Updated Morse firmware and BCFs to 1.17.9. * Added validation to enforce that simultaneous AP and STA interfaces operate on the same channel. * Added a benchmark test to Porting Assistant that verifies that the system executes instructions fast enough to meet the expected throughput. * Removed 2MHz EU channels from the regulatory database. * Added regulatory database documentation to the user guide. * Added Makefile targets to simplify programming and reconfiguring devices. * Added a check to example Makefiles that detects non-object files in \`OBJS\`. * Added support for defragmentation of management frames. In practice, this affects only large management frames, such as DPP GAS frames. * Decoupled DPP credentials from the PB\_RESULT event. There is now a new MMWLAN\_DPP\_EVT\_CONF\_RECEIVED event that is raised when the configuration is available; this makes it portable for different DPP methods (e.g., DPP QR). #### 2.2.3 Bug Fixes * Fixed a crash that occurred when mmwlan\_sta\_disable() was invoked while an association request retry timer was pending. * Fixed a crash caused by calling an ISR-context FreeRTOS function from a non-ISR background task. * Fixed system time drifting when exiting deep sleep. #### 2.2.4 Known Issues **2.2.4.1 Makefile Infrastructure** * Building fails when the MM-IoT-SDK package directory has a space in the path * The MM-IoT-SDK package must be unpacked into a directory without spaces in its name. **2.2.4.2 RTOS** * Timeouts with FreeRTOS time slicing disabled * FreeRTOS time slicing is enabled by default in the MM-IOT-SDK FreeRTOS configuration. If this is disabled, timeouts may be observed when sending commands to the MM chip. * System time drifts on STM32-based reference platforms because of the low-accuracy clock. Higher accuracy can be achieved by switching to the High-Speed External (HSE) clock source at the cost of higher power consumption when active. **2.2.4.3 Example Applications** * Failures when lwIP is built with LWIP\_IPV4=0 * If IPv4 is disabled when LWIP is built (i.e., IPv6-only), the IP stack may not work as expected. The workaround is to always enable IPv4. **2.2.4.4 AP Mode** *Note that AP Mode is alpha and not for production use.* * Traffic is not forwarded between STAs * AP mode does not forward frames between connected STAs. Therefore, connected STAs cannot communicate with each other unless bridging is implemented at the application layer. * This functionality can be achieved by enabling relay mode and setting the AP as the root node. No changes are required on the STA devices to facilitate this. * Recovery from health failures is not supported in AP mode * If a health check failure occurs while operating in AP mode, it will trigger a system restart. * Mitigation is to disable the health check by invoking: mmwlan\_set\_health\_check\_interval(0, 0); * OWE security is not supported * Mitigation is to use Open or SAE security. * STAs may not be able to associate to the AP in EU and GB regulatory domains. **2.2.4.5 DPP** *Note that DPP is beta and not for production use.* * DPP must be stopped explicitly before shutdown * If DPP has been started (via mmwlan\_dpp\_start()), it must be stopped explicitly via mmwlan\_dpp\_stop() prior to invocation of mmwlan\_shutdown(). * DPP is not currently supported in regulatory domains that contain multiple channels sharing the same center frequency but at different bandwidths, in particular JP and AU REVmf. **2.2.4.6 Stability** * Some link instability may be seen at some specific signal levels, resulting in an elevated packet error rate. * Minor changes to the distance from the AP, antenna orientation, or environment will correct it. #### 2.2.5 Migration from 2.11.2 **2.2.5.1 MMWLAN API** Added QR Code Enrollee mode, selectable via the new mode field in mmwlan\_dpp\_args. The event enum was expanded to include granular auth/config phase events, and SSID/passphrase was moved from args.pb\_result to args.conf\_received (fired as MMWLAN\_DPP\_EVT\_CONF\_RECEIVED for both modes). Update callbacks accordingly and use MMWLAN\_DPP\_ARGS\_INIT to initialize the expanded struct. **2.2.5.2 Flash HAL API** The Flash HAL API now uses mmhal\_flash\_addr\_t for address in place of uint32\_t. This type is defined as uint32\_t by default unless overridden by MMHAL\_FLASH\_ADDR\_T. Add optional mmhal\_get\_factory\_mmconfig\_partition() to allow a factory default partition to be specified for mmconfig. **2.2.5.3 UART HAL API** Added new functions, mmhal\_uart\_validate\_config() and mmhal\_uart\_configure(), for validating and setting UART configuration (baud rate and flow control). **2.2.5.4 MMAGIC API** DPP API has been updated. #### 2.2.6 Components | Component | Version | | ------------------- | ------------------------------------------------------------------ | | Morse firmware | 1.17.9 | | Regulatory Database | 2.8.0 | | FreeRTOS kernel | 11.2.0 | | LWIP | 2.2.0 (+modifications) | | mbedTLS | 3.6.5 | | STM32U5 BSP | 1.8.0 | | STM32WB55 BSP | 1.14.1 | | BCF API | 12.1.0 (backward compatible to 8.0.0, but features may be limited) | ### 2.3 Release 2.11.2 This section outlines significant changes from release 2.10.4. #### 2.3.1 New Features * Simultaneous AP/STA support * Subset of S1G Relay support, including Reachable Address Update \[alpha] #### 2.3.2 Other Improvements * Added MMWLAN API to register a callback to be invoked in case of unrecoverable errors. * Added a workaround to prevent indefinite pause of transmission when traffic control resume events are missed during spread mode duty cycle operation. * Added MMWLAN API to retrieve channel information for a VIF. * Updated the FreeRTOS kernel to v11.2. * Updated board support packages for STM32U5 and STM32H7 to the latest release version. * Updated the mbedtls submodule version from 3.6.2 to 3.6.5. The main benefit is a large number of security fixes (11 issues with Security Advisories) and a few bug fixes. See the full changesets at . * Added missing \`const\` qualifiers in mmconfig. * Error message with file hash: line number is now logged when a chip assert occurs. * Added a mechanism to hold the transceiver in reset when the MCU is halted on assertion in debug builds. * Added a function to assert/deassert the reset pin on the Wi-Fi HaLow transceiver in mmhal\_wlan. * mmutils.h now uses MMLOG\_XX macros instead of calling printf() directly. * Added additional information in the sta\_status updates in the ap\_mode example application. * Fixed typos in \`mmagic\_controller.h\` function docstrings. * Increased the response timeout for \`mmagic\_mqtt\_stop\_agent\` to improve reliability. * Added connect\_on\_boot configuration option to MMAGIC. * Added detection and disconnection of inactive STAs in AP mode. * Implemented \`mmwlan\_ap\_disable()\` to fully disable AP mode operation, replacing the previous stub implementation. * Implemented deauthentication of unrecognized stations in AP mode to ensure STAs with stale associations are properly notified when the AP has no record of their association. * Added an optional mmpkt pool for management-class frames (used in AP mode). * Extended API readiness labels and added documentation explaining usage. * Added ap\_ prefix to mmconfig WLAN parameters in ap\_mode example application. * Added mmwlan statistics for TX frames that timed out in the send path. * Added MMWLAN\_NOT\_SUPPORTED status code. * Reduced recovery time when a chip assertion is detected. * Removed freertos-plus-tcp network stack support. * Removed the bootloader that was previously provided with MM-IoT-SDK, as it was never productionized. In addition, the AWS OTA example that relied on it has been removed. * Increased size of command pool in reference pktmem implementations to account for larger commands. * Clarified behavior and parameters for mmwlan\_ate\_execute\_command(). * The standby mode and offload features that had previously been deprecated have now been removed from the MM-IoT-SDK. * Updated firmware binaries to v1.17.8. * Refactored the mmiperf client and server implementations into separate source files to improve code maintainability. * Added an API to stop iperf servers and in-progress iperf sessions. * Removed load\_mmwlan\_settings() prototype from mmconfig.h. It is provided by mm\_app\_loadconfig.h. * Updated the default NTP server to "time.aws.com" in the aws\_iot example to increase robustness and stability. * Updated scan example application to use the common version function from mm\_app\_common. * Improved clarity of mmhal\_flash documentation. * Replaced ARM-specific inline Assembly code in FreeRTOSConfig.h with MMPORT\_BREAKPOINT(). * Fixed a missing include in \`mqtt\_agent\_task\_powersave.c\`. * Relaxed handling of \`CHANNEL\_LIST\_NOT\_SET\` errors during network interface initialization to allow startup to proceed without a fully configured channel list. * Updated LWIP configuration to only set LWIP\_PROVIDE\_ERRNO if LWIP\_ERRNO\_STDINCLUDE is not defined. * Renamed MMAGIC “tcp” module to “socket”. * Added UDP client and server support to MMAGIC through the socket API, matching the existing TCP interface. * Enum types in the MMAGIC API are now packed to enforce consistent serialization. * Added MMAGIC DPP push button command support. * Increased mmagic\_controller\_wlan\_commit\_all timeout. * Added basic example application for relay mode. * Added experimental support for MacOS (Apple silicon). * Updated the default toolchain version to GCC14. * LWIP assertion messages are now printed in LWIP\_PLATFORM\_ASSERT(). * Added morselib and HW version to the Porting Assistant example application output. * Added mmpkt\_list API function to dequeue multiple packets from a list at once. * Added version information output to m2m reference applications. * Made the receive timeout for the mbedTLS transport interface configurable. * Added example application to demonstrate raw UDP and TCP client sockets. * The ekh08-wb55 and ekh18-wb55 platforms now use the hardware crypto libraries by default, reducing association time. * On-demand timers are added to the LWIP network stack to enable event-based timing, reducing power consumption. This option is toggled using ON\_DEMAND\_TIMERS\_ENABLED and is enabled by default. * Removed support for PlatformIO. * Updated the README to link to the GitHub Pages HTML documentation. * Added a new configuration variable to MMAGIC MQTT for the configuration of the keep alive interval. #### 2.3.3 Bug Fixes * Fixed a bug where the CLI application would fail an assertion if a country code was not programmed to the config store. * Fixed an incorrect return code in the porting assistant \`test\_wlan\_io.c\`, \`process\_sdio\_spi\_multi\_byte\_return()\`. * Fixed a bug that could cause system instability when the M2M agent datalink state was updated from an interrupt service routine context. * Fixed a bug where MMAGIC M2M ping would fail and report incorrect results. * Fixed AP enable API returning before the AP interface was started. * Improved scan result filtering to increase robustness of AP selection. * Fixed incorrect message in UART HAL. * Fixed an issue where the LwIP network interface bypassed the standard \`netif->input\` dispatch path by calling \`tcpip\_input\` directly. * Improved stability of hardware reset functionality for SDIO platforms. * Fixed incorrect range in implementation of \`mmhal\_random\_u32(min, max)\` for WB55 platforms. #### 2.3.4 Known Issues **2.3.4.1 Makefile Infrastructure** * Building fails when the MM-IoT-SDK package directory has a space in the path * The MM-IoT-SDK package must be unpacked into a directory without spaces in its name. **2.3.4.2 RTOS** * Timeouts with FreeRTOS time slicing disabled * FreeRTOS time slicing is enabled by default in the MM-IOT-SDK FreeRTOS configuration. If this is disabled, timeouts may be observed when sending commands to the MM chip. * System time drifts when the host is in deep sleep * System time may drift from wall clock time when deep sleep is enabled. This may result in iperf taking longer than expected to complete. A 1-2% drift has been observed on STM32U575 and 3-4% on STM32WB55, but this may vary with activity levels. **2.3.4.3 Example Applications** * Failures when lwIP is built with LWIP\_IPV4=0 * If IPv4 is disabled when LWIP is built (i.e., IPv6-only), the IP stack may not work as expected. The workaround is to always enable IPv4. **2.3.4.4 AP Mode** *Note that AP Mode is alpha and not for production use.* * Traffic is not forwarded between STAs * AP mode does not forward frames between connected STAs. Therefore, connected STAs cannot communicate with each other unless bridging is implemented at the application layer. * This functionality can be achieved by enabling relay mode and setting the AP as the root node. No changes are required on the STA devices to facilitate this. * Recovery from health failures is not supported in AP mode * If a health check failure occurs while operating in AP mode, it will trigger a system restart. * Mitigation is to disable the health check by invoking: mmwlan\_set\_health\_check\_interval(0, 0); * OWE security is not supported * Mitigation is to use Open or SAE security. **2.3.4.5 DPP** *Note that DPP is beta and not for production use.* * DPP must be stopped explicitly before shutdown * If DPP has been started (via mmwlan\_dpp\_start()), it must be stopped explicitly via mmwlan\_dpp\_stop() prior to invocation of mmwlan\_shutdown(). * DPP is not currently supported in regulatory domains that contain multiple channels sharing the same center frequency but at different bandwidths, in particular JP and AU REVmf. **2.3.4.6 Stability** * Some link instability may be seen at some specific signal levels, resulting in an elevated packet error rate. * Minor changes to the distance from the AP, antenna orientation, or environment will correct it. #### 2.3.5 Migration from 2.10.4 **2.3.5.1 Toolchain updates** The GCC toolchain has been updated. Please rerun the setup script to ensure the correct version is installed at the expected location. **2.3.5.2 MMWLAN API** A new state, MMWLAN\_AP\_STA\_AUTHENTICATED, has been added to the mmwlan\_ap\_sta\_state enumeration. The function mmwlan\_ap\_enable() now blocks by default until the AP interface is up. This can be overridden to the previous behavior by setting the async\_start option in the AP arguments. Deprecated Offload API has been removed and is no longer available for application use. **2.3.5.3 MMWLAN HAL API** New function mmhal\_wlan\_assert\_reset() needs to be implemented by the WLAN HAL. Reference HALs have been updated to reflect this. **2.3.5.4 MMAGIC API** The tcp module of MMAGIC has been renamed to socket. Deprecated Offload API has been removed. #### 2.3.6 Components | Component | Version | | ------------------- | ------------------------------------------------------------------ | | Morse firmware | 1.17.8 | | Regulatory Database | 2.7.0 | | FreeRTOS kernel | 11.2.0 | | LWIP | 2.2.0 (+modifications) | | mbedTLS | 3.6.5 | | STM32U5 BSP | 1.8.0 | | STM32WB55 BSP | 1.14.1 | | BCF API | 12.1.0 (backward compatible to 8.0.0, but features may be limited) | ### 2.4 Release 2.10.4 This section outlines significant changes from release 2.9.7. #### 2.4.1 New Features * Combined MM6108 and MM8108 into a single release package * Added support for the new AU 802.11-2024 and 802.11-REVmf channel maps. * Added support for handling Extended Channel Switch Announcements (ECSAs) in STA mode. * Added morselib source code. * Added MM8108 support for ESP32. * Added support for ESP32-P4. * Added ap\_mode example application for ESP32 platforms. #### 2.4.2 Other Improvements * Added morselib version header (mmversion.h) * Improved consistency of code style in the example application source code. * Updated the list of BCFs that are now included in the MM-IoT-SDK release package. * Updated ESP32 binary blob search behavior to be a recursive search. * Moved BCFs into a morsefirmware/\/bcfs/ directory structure to clarify which BCF is for which chip type. * Added duty cycle limits to EU and GB regulatory domains (2.8% for STA, 10% for AP). * Updated ap\_mode example to use Operating Class 71 (US, 8 MHz channel spacing) by default. * Moved application-specific regulatory database implementations into a dedicated Morse Micro regulatory database component. * Set the default AU channel list to IEEE 802.11-REVmf. This will be used if the country code "AU" is specified. * Added an assert on health check failure in AP mode, as health check recovery is not supported. * Added the ability to configure the maximum allowed connections when enabling AP mode. * Added MAC address helper functions to mmutils.h. * Added a warning to the documentation and an error message to mmwlan\_ap\_enable to make it explicitly clear that OWE is not currently supported by AP mode. * Disabled FreeRTOS-plus-TCP network stack for mm-ekh18-wb55 out of the box. * Added support for MM8108 to the mm-iot-sdk release package and deprecated the mm-iot-sdk-mm8108 release package. * Reduced RAM usage by 32 kB for MM8108 platforms. * Added support for TLS 1.3 to MMAGIC. * Added a new event to the MMAGIC TCP module that allows a Controller to receive notifications when data is ready to be read for a given TCP socket. This may be enabled on a per-socket basis. Only supported for the LWIP network stack. * Added configurable logging API to mmlog.h. * Added support for datapath\_driver\_rx\_alloc\_failures and datapath\_driver\_rx\_read\_failures UMAC stats on MM8108. * Reordered contents of mmwlan.h to improve structure and clarity. * Added support for libmorse\_nosupplicant.a on an ESP32 by mangling libmorse and hostap symbols post-compilation and linking of the two components. This adds a new Kconfig option, BUILD\_SUPPLICANT\_FROM\_SOURCE, that lets the user select the libmorse variant. * Added hostap source files to the esp32 package and hostap as a valid ESP-IDF component. For brevity, the build configuration is statically defined to the set required to support AP mode when this component is used. * Added a library mangler script to enable users to compile Morse Micro's hostap from source, useful for systems that already include hostap for another radio, e.g., ESP32. * Added packet memory reservation for commands when using mmpktmem\_heap. This improves command reliability on MM8108. * Renamed AP mode API from softap to ap, and example application from softap to ap\_mode. * Improved handling of packet memory exhaustion on MM8108. * HW Version string is now printed at boot for most example applications. * Added noise measurements to scan results to provide more in-depth information on scanned channels. Provided WPA Supplicant with a measured noise value to improve the accuracy of SNR estimation. * Enabled hardware acceleration of ECP cryptography operations for EKH05 platforms by default. * Enabled building of Supplicant cryptographic code from source by default in example applications. The BUILD\_SUPPLICANT\_CRYPTO\_FROM\_SOURCE make variable is now set to “y” by default in the example Makefile, but can be set to an empty string to return to the previous behavior. This change may result in longer connection times on platforms where hardware acceleration for ECC cryptographic operations is not supported (particularly those with slower processors). * Made IPAL implementations more permissive to config get/set operations when a given IP version is not enabled at compile time by the network stack configuration. * The MMWLAN API specifies that it must only be invoked when MMWLAN is inactive (i.e., STA mode is not enabled) and will now return \`MMWLAN\_UNAVAILABLE\` if you call it when the STA is enabled. * Increased the maximum number of stations that can connect in AP mode from 4 to 20, and added make variables to simplify enabling AP mode and allocating sufficient memory for the expected station count. * Python version 3.10 has been specified in the Pipfile as a requirement. * Split up mmhal.h API into multiple files (mmhal\_xxx.h) to better represent where each function is used. * Revised Getting Started guide. * Extended MMWLAN API to allow specification of the interface for transmitted and received packets, link status callback, and when retrieving the MAC address. * Added MMWLAN\_NOT\_INITIALIZED error code to signal when the MMWLAN API is invoked before the subsystem is initialized. * Removed Emmet dependency on MMHAL API. Applications that use set\_button or set\_led Emmet commands must now implement the corresponding emmet\_hal functions. * Added BCF for MM6108-MF16858 module. * Added API to set the time after network activity before the STA will notify the AP that it will go to sleep using a QoS Null frame, and when the host will allow the Morse chip to sleep. * Increased the default TCP client socket timeout to 10 seconds for both IP stacks. * Added MMWLAN API to enable/disable non-TIM mode. * Improved detection of connection loss. Stations will now disconnect on a beacon loss event after sending 2 QoS null packets to check whether the AP is reachable. Previously, 20 unacknowledged packets would also cause disconnects, and the station frequently sent QoS nulls to verify the AP's presence. * Added support for power-saving stations in AP mode. * Add releasing group-addressed traffic on the DTIM beacon in AP mode. * Added support for handling Extended Channel Switch Announcements (ECSAs) in STA mode. * Added MMWLAN API for notification and retrieval of STA status in AP mode. * Added support for DTIM periods greater than 1 in AP mode. * Moved offload\_arp\_response and offload\_arp\_refresh\_s from mmconfig WLAN namespace to IP namespace. * Replaced malloc/free usage in crypto\_mbedtls\_mm.c with mmosal\_malloc/mmosal\_free. * Added support for dynamic wake. This means that instead of waiting a fixed duration (10 ms) after the WAKE pin is raised, the Morse chip will now indicate readiness. This may result in lower power consumption and potentially less delay during transmission. * Reformatted source files in morselib/include files to ensure consistency. This will result in whitespace differences when comparing the old and new header files. * Added API to configure the Control Response preamble bandwidth. * FW\_MBIN is now specified in the platform-specific Makefile. * Improved robustness of the 4-way handshake in STA mode when connecting to an AP. * Improved roaming behavior when background scan is enabled in STA mode. * Added on-demand timer support to lwIP. This uses the RTOS timer to schedule events, allowing the host to sleep longer while the network stack is idle, reducing power consumption. Disabled by default. Set ON\_DEMAND\_TIMERS\_ENABLED=1 to enable. #### 2.4.3 Bug Fixes * Added missing stdint.h include to mmagic\_controller.h. * Fixed a bug where supplicant could get stuck in scanning state forever, unable to start a new scan with the error \`Reject scan trigger since one is already pending\`. * Fixed an assertion that could occur on reception of a fragmented 4 address frame. * Fixed a bug that prevented 2 and 4 MHz channels in the JP regulatory domain from being supported in AP mode. * Fixed CFLAGS for ESP32C6 platform. * Increased size of FLASH segment and decreased size of FILESYSTEM segment (currently unused) in m2m\_agent application for mm-ekh08-u575 platform. * Fixed a bug where stations would continuously send QOS\_NULL frames every 100ms. * Added missing implementation of mmwlan\_register\_tx\_flow\_control\_cb(). * mm-ekh18-wb55 platform option is now present for the \`program\_configstore.py\` script. * Fixed a discrepancy between LWIP and MMOSAL timeout expectations in the LWIP port implementation. * Fixed intermittent connection failure when using public key acceleration on STM32U585 platforms. * Updated documentation of mmwlan\_get\_bssid() to match behavior. * Updated the 4 address mode filter to avoid incorrectly dropping certain non-data frames. * Fixed rate control drops from duty cycle exhaustion. * Fixed a bug where the timeout argument to the wlan-connect CLI command was ignored, and corrected the argument parsing order for the same command. * Fixed Random Number Generation (RNG) failure on concurrent access for several STM32-based platforms. * Fixed a bug that caused received Action frames to be dropped when security mode was Open (i.e., no security). This would result in lower-than-expected throughput, since a Block Ack session could not be negotiated. This does not affect OWE or SAE operation. * Fixed a bug where group-addressed traffic would not be encrypted when transmitted in AP mode. * Removed semicolon from configBREAK macro in FreeRTOSConfig.h. * Fixed a bug that could result in to-chip yaps delimiter CRC fail error messages on MM8108. * Fixed a crash on mmwlan shutdown with DHCP offload enabled. * Fixed Command error on boot when DHCP offload is enabled. * Fixed a bug in the MQTT agent task that could result in a deadlock when resubscribing to MQTT subscriptions after a disconnect. * Fixed MQTTAgent task stack overflow on TLS 1.3. * Fixed the enum values in MMAGIC CLI documentation. * Fixed a bug where MMAGIC Agent would assert if an out-of-range stream\_id was given when closing a socket. #### 2.4.4 Known Issues **2.4.4.1 Makefile Infrastructure** * Building fails when the MM IoT SDK package directory has a space in the path * The MM IoT SDK package must be unpacked into a directory without spaces in its name. **2.4.4.2 RTOS** * Timeouts with FreeRTOS time slicing disabled * FreeRTOS time slicing is enabled by default in the MM-IOT-SDK FreeRTOS configuration. If this is disabled, timeouts may be observed when sending commands to the MM chip. * System time drifts when the host is in deep sleep * System time may drift from wall clock time when deep sleep is enabled. This may result, for example, in iperf taking longer than expected to complete. A 1-2% drift has been observed on STM32U575 and 3-4% on STM32WB55, but this may vary with activity levels. **2.4.4.3 Example Applications** * Failures when lwIP is built with LWIP\_IPV4=0 * If IPv4 is disabled when LWIP is built (i.e., IPv6-only), the IP stack may not work as expected. The workaround is to always enable IPv4. * The CLI application requires the country code to be programmed into the config store * The CLI application will assert during initialization if a valid country code has not been programmed to the config store. Instructions for programming the config store are in the Getting Started Guide. * Bootloader/OTAU support * The example bootloader and over-the-air-update (OTAU) support in the aws\_iot example have not been tested to a level that makes them recommended for production use. The example bootloader may be deprecated in a future release. **2.4.4.4 Standby/Offload Features** * The Standby and Offload features of the MMWLAN API are deprecated and will be removed in a future release. **2.4.4.5 AP** *Note that AP mode is beta and not for production use.* * Traffic is not forwarded between STAs * AP mode does not forward frames between connected STAs. Therefore, connected STAs cannot communicate with each other unless bridging is implemented at the application layer. * Recovery from health failures is not supported in AP mode * If a health check failure occurs while operating in AP mode, it will trigger a system restart. * Mitigation is to disable the health check by invoking: mmwlan\_set\_health\_check\_interval(0, 0); * OWE security is not supported * Mitigation is to use Open or SAE security. **2.4.4.6 DPP** *Note that DPP is beta and not for production use.* * DPP must be stopped explicitly before shutdown * If DPP has been started (via mmwlan\_dpp\_start()), it must be stopped explicitly via mmwlan\_dpp\_stop() prior to invocation of mmwlan\_shutdown(). * DPP is not currently supported in regulatory domains that contain multiple channels sharing the same center frequency but at different bandwidths, in particular JP and AU REVmf. **2.4.4.7 Stability** * Some link instability may be seen at some specific signal levels, resulting in an elevated packet error rate. * Minor changes to the distance from the AP, antenna orientation, or environment will correct it. #### 2.4.5 Migration from 2.9.7 The following is a list of significant changes from the previous MM-IoT-SDK release. This is not an exhaustive list and does not include new feature additions or changes to example applications. **2.4.5.1 Combined MM6108 and MM8108 libraries** MM6108 and MM8108 devices are now both supported by a single library. The MMWLAN HAL implementation is required to provide the following function to differentiate chip type: ``` const struct mmhal_chip *mmhal_get_chip(void) { /* This is a define that is set by the build system in the platform-xxx.mk file to select the * Morse chip type. See the API documentation for mmhal_get_chip() for more information. */ return &MMHAL_CHIP_TYPE; } ``` Where MMHAL\_CHIP\_TYPE is defined to either mmhal\_mm6108 or mmhal\_mm6108. This function has been added to the platform HALs provided in the SDK. **2.4.5.2 MMWLAN API** AP mode API has been renamed. Formerly, this was referred to as *Soft AP mode*, with an mmwlan\_softap\_ prefix in MMWLAN API. This is now referred to as *AP* *mode*, and the prefix has changed to mmwlan\_ap\_. Similarly, the *softap* example application has been renamed to *ap\_mode*. Similarly, the name of the Makefile variable to enable AP mode has changed from BUILD\_SUPPLICANT\_WITH\_SOFTAP to BUILD\_SUPPLICANT\_WITH\_AP. **2.4.5.3 MMHAL API** The MMHAL header has been split up into multiple headers to better clarify usage. | Header File | Description | | ---------------- | ------------------------------------------------------------------------------ | | mmhal\\\_core.h | Required for core morselib functionality. | | mmhal\\\_wlan.h | Required for morselib MMWLAN functionality. | | mmhal\\\_os.h | Required for the MMOSAL provided with this SDK (mmosal\\\_shim\\\_freertos.c). | | mmhal\\\_app.h | Required for the example applications provided with this SDK. | | mmhal\\\_uart.h | Required for certain example applications that need UART I/O. | | mmhal\\\_flash.h | Required for MMCONFIG, littlefs HALs, and certain example applications. | The header mmhal.h is still included in the package, but now simply includes the above headers. Note: mmhal.h is no longer included by mmosal.h. Files that previously relied on this implicit inclusion may need to be updated to explicitly include mmhal.h. The mmhal.c source file provided in the example applications has been split into multiple files corresponding to mmhal\_xx.h headers, and wlan\_hal.c has been renamed to mmhal\_wlan.c for consistency. **2.4.5.4 Cryptography** Example application Makefiles now enable BUILD\_SUPPLICANT\_CRYPTO\_FROM\_SOURCE by default. This can be overridden by setting BUILD\_SUPPLICANT\_CRYPTO\_FROM\_SOURCE to an empty string. The impact of this change is that morselib will use mbedTLS for cryptographic operations (including Elliptic Curve and hash operations). Platforms without hardware acceleration for these operations may observe an increase in connection time. Hardware acceleration of some mbedTLS Elliptic Curve operations has been enabled for EKH05 reference platforms provided in this SDK. **2.4.5.5 Makefile and infrastructure** The firmware and BCF files have moved from the framework/morsefirmware directory into subdirectories appropriate to the chip (framework/morsefirmware/mm6108, framework/morsefirmware/mm8108). **2.4.5.6 Emmet** An additional hardware abstraction API has been added to emmet.h. These functions must be implemented by any application that uses Emmet. **2.4.5.7 Regulatory Database** The regulatory database has been moved from mm\_app\_regdb.\* into a separate component called mmregdb. To receive regulatory database updates, existing applications should be updated to use this new component. See the provided example applications for reference. **2.4.5.8 Notable new API** A configurable logging API has been added to framework/morselib/include/mmlog.h. A new version header, framework/morselib/include/mmversion.h, has been added. #### 2.4.6 Deprecation Notice The following components of the MM-IoT-SDK have been marked as deprecated and will be removed in subsequent releases. **2.4.6.1 FreeRTOS-plus-TCP network stack** FreeRTOS-plus-TCP will be removed from future MM-IoT-SDK release packages. LWIP will continue to be the primary supported network stack. **2.4.6.2 Platform IO** Platform IO support will be removed from the core MM-IoT-SDK release package in the future. GNU Make will continue to be the primary supported build system supported by the core MM-IoT-SDK. Alternative build systems include: * ARM CMSIS IDEs such as STM Cube IDE: * ESP32 IDF: * Zephyr: **2.4.6.3 Bootloader example application** The Bootloader example application provided with the MM-IoT-SDK will be removed in a future release. Alternatives include bootloaders and MCUBoot supplied by the MCU vendors. **2.4.6.4 Offload functionality** The existing support for the MM chips' offload functionality (including “Standby mode”) will be removed in a future release. Please see the API documentation for more specific deprecation notices. #### 2.4.7 Components | Component | Version | | ------------------- | ------------------------------------------------------------------ | | Morse firmware | 1.17.6 | | Regulatory Database | 2.7.0 | | FreeRTOS kernel | 10.5.1 | | LWIP | 2.2.0 (+modifications) | | FreeRTOS + TCP | 4.3.1 | | mbedTLS | 3.6.2 | | STM32U5 BSP | 1.4.0 | | STM32WB55 BSP | 1.14.1 | | BCF API | 12.1.0 (backward compatible to 8.0.0, but features may be limited) | ### 2.5 Release 2.9.7 This section outlines significant changes from release 2.8.2. #### 2.5.1 New Features * Soft AP functionality (beta - not for production) * Support for operation in AP mode with a limited feature set: * Maximum 4 connected STAs\ Automatic and Dynamic channel selection is not supported\ Soft AP example application only supports IPv4 and static IP addresses\ See also the Soft AP subsection under Known Issues below * Device Provisioning Protocol (DPP), push button mode functionality as STA (Beta) * DPP push button allows a device to be provisioned onto a network by pressing a button on both the STA and on the AP * Only supported on EKH05 platforms, as Public Key Accelerator (PKA) HW is required to meet timing requirements * Support for 4-address frames in STA mode * Allows a STA to act as a layer 2 bridge * Support for duty cycle burst mode * In regulatory domains subject to duty cycle limitations, burst mode allows a device to consume its allowance in a burst rather than spread evenly over the duty cycle period #### 2.5.2 Other Improvements * Improved documentation of mmconfig parameters * Added support for home channel dwelling during background scan * Added MMWLAN API to configure listen interval * Added support for registering a callback on station events * Added support for appending user provided IEs to association IEs * Updated mbedTLS to latest release v3.6.2 * Added API to query preserved failure logs * Improved reliability of the WLAN chip health check system * Added support for MCS8/9 rate control override for MM8108. * Remove unsupported software scan * Reduced power consumption of unused sensors on EKH05 * Added logging of return address to Hard Fault handlers, which can aid in identifying the instruction that triggered the fault. * Improved EAPOL frame transmission reliability * Enforced TWT configuration to occur pre-association * Removed package files for unsupported MCU STM32-F429 * Extracted mmhal\_flash API from mmhal.c * Updated EKH05 CubeMX code generation to v6.14.1 * Added additional morselib.a builds to mm-iot-sdk-mm8108 so that it supports the same architectures as mm-iot-sdk. * Added support for debug-only assertions using the macro MMOSAL\_DEV\_ASSERT() * Removed support for MMAGIC CLI on EKH08-WB55 due to insufficient FLASH space * Disabled LWIP address collision detection by default to improve DHCP link bring-up time * Enabled DHCP by default on example applications and assumed target IP address is gateway address, where applicable (e.g., ping, iperf examples). * Extended mmconfig configuration options for the AWS IoT example application * Removed LED validation from porting assistant * Updated ESP32 porting assistant to match main version * Added support for debug builds in SDK Makefiles * Added support for configuring the scan interval when running ACE script wlan-sta-connect.py * Provided MM Chip MAC address to MMHAL read MAC address API * Added scan dwell time configuration to mmconfig * Added support for transceiver snooze in between scan attempts * Added support for snooze before association to reduce power consumption * Added support for disabling debugging in low power modes when using OpenOCD to improve power consumption profiling * Removed unneeded SWO initialisation from main.c. OpenOCD initialises the SWO when required. * Added PKA hardware acceleration support for EKH05 in mbedTLS * Deprecated MMOSAL notification API * Added a MMAGIC LLC synchronization mechanism to enable a controller to reattach to a running M2M agent * Added MMAGIC CLI command to query WLAN link status * Added TLS support in MMAGIC TCP core * Added support for NTP in MMAGIC m2m * Added support for a configurable timeout on MMAGIC m2m command responses * Restructured autogenerated MMAGIC source code files to remove .def files and replace with .c files. In doing this several existing .c files were also renamed for clarity. This change should be transparent to users of the autogenerated makefile fragments. * Added support for statically allocating MMPKT memory for m2m\_agent demo application * Reduced maximum mmagic streams to a sensible limit and allocated additional RAM to m2m\_agent application to allow allocating the maximum streams. * Added support for connecting to AP with higher operating bandwidth * Reduced default scan dwell duration * Added GB country code to regulatory domain database * Added support for EU 2MHz channels and 100% Duty cycle * Enabled subband transmission by default * Added support for customer provided BCFs * Added initial support for ESP32C6 platform * Added a Kconfig for specifying the Morse chip firmware binary when building for ESP32 * Improved SDK documentation viewability for ESP-IDF version on Github * Improved display of scan results in MMAGIC CLI * Added support for clearing MMAGIC CLI variables * Disabled OTA update support in aws\_iot example application by default * Reduced static RAM usage by 32KB when using MM8108 devices * Added ESP32C3 support to mm-iot-sdk-esp32 #### 2.5.3 Bug Fixes * Fixed \`mmhal\_get\_time()\` API missing explicit void argument * Fixed reporting TWT Requester S1G capabilities as "Not Supported" * Ensure MAC address persists over the app lifetime * Fixed RAW priority 0 being treated as disabled * Reduced power consumption on MM8108-EKH05 when HaLow chip is off * Improved robustness of porting assistant BUSY pin testing * Fixed MMAGIC CLI unable to set full IPV6 address * Fixed memory leak on failed TX in MMAGIC Agent LLC. * Fixed potential memory leak in m2m\_agent application for SPI datalink buffer TX. * Fixed MMAGIC CLI becoming unresponsive after executing one-shot system deep sleep command \`sys-deep\_sleep one\_shot\` * Fixed m2m\_agent SPI data link recovery from receive error. * Fixed ignored MMAGIC wlan core configuration parameters * Fixed MMAGIC CLI maximum wlan password length not matching MMWLAN maximum * Improved MM8108 TCP throughput stability in environments experiencing packet loss #### 2.5.4 Known Issues **2.5.4.1 Makefile Infrastructure** * Building fails when MM IoT SDK package directory has a space in the path * The MM IoT SDK package must be unpacked into a directory that does not include a space in its name. **2.5.4.2 Stability** * Timeouts with FreeRTOS time slicing disabled * FreeRTOS time slicing is enabled by default in the MM-IOT-SDK FreeRTOS configuration. If this is disabled, timeouts may be observed when sending commands to the MM chip. * System time drifts when host deep sleep is enabled * System time may drift from wall clock time when deep sleep is enabled. This may result, for example, in iperf taking longer than expected to complete. Drift of 1-2% has been observed on STM32U575 and 3-4% on STM32WB55, but this may vary with level of activity. * DPP must be stopped explicitly before shutdown * If DPP has been started (via mmwlan\_dpp\_start()) it must be stopped explicitly via mmwlan\_dpp\_stop() prior to invocation of mmwlan\_shutdown(). * Assert after consecutive RNG failures * On STM32 platforms, in cases where multiple threads access the hardware random number generator (RNG), a priority inversion may occur resulting in an assertion in mmhal\_random\_u32(). This can be mitigated by protecting access to the STM32 RNG API with a mutex. **2.5.4.3 Throughput** * Low throughput with open security due to action frames being dropped * When connected with open security (no encryption), action frames are dropped on receive. The primary impact of this is that block ack negotiation fails, meaning A-MPDU aggregation is not enabled, and thus resulting in lower throughput. This does not affect SAE or OWE security modes. **2.5.4.4 Example Applications** * Failures when lwIP built with LWIP\_IPV4=0 * If IPv4 is disabled when LWIP is built (i.e., IPv6 only) then there may be issues with the IP stack not working as expected. The workaround is to always enable IPv4. * CLI application requires country code to be programmed to config store * The CLI application will assert during initialization if a valid country code has not been programmed to the config store. Instructions for programming config store can be found in the Getting Started Guide. * Bootloader/OTAU support * The example bootloader and over-the-air-update (OTAU) support in the aws\_iot example has not been tested to a level where it is recommended for production use. The example bootloader may be deprecated in a future release. **2.5.4.5 Standby/Offload Features** * The Standby and Offload features of the MMWLAN API are in development and may not be fully functional. * Further improvements are planned in future releases that may result in minor API changes. **2.5.4.6 Soft AP** * Power save is not supported on connected STAs * Soft AP does not support buffering of traffic for power saving STAs. Therefore, 802.11 power save must be disabled on STAs connecting to the AP. * Traffic is not forwarded between STAs * Soft AP does not forward frames between connected STAs. Therefore it is not possible for connected STAs to communicate with each other. * Soft AP does not correctly transmit group addressed frames * Group addressed frames are transmitted unencrypted, even when encryption is enabled, meaning that they are not able to be decoded by receiving STAs. * Recovery from health failures is not supported in Soft AP mode * If a health check failure occurs while operating in Soft AP mode, it will not return to an operable state (for example, beacon transmission will not resume). #### 2.5.5 Migration from 2.8.2 The following is a list of significant changes from the previous release of the MM-IoT-SDK. This is not an exhaustive list and does not include new feature additions or changes to example applications. **2.5.5.1 mbedTLS configuration** For mbedTLS configuration files that use mmhal\_get\_time() for MBEDTLS\_PLATFORM\_TIME\_MACRO, the definition must be updated to the following to avoid compilation errors: \#define MBEDTLS\_PLATFORM\_TIME\_MACRO(x) mmhal\_get\_time() **2.5.5.2 MMOSAL API** Newly added functions: * mmosal\_printf(): OS abstracted version of printf used by morselib * mmosal\_extract\_failure\_info(): Extract the oldest un-viewed failure log entry The task notification API (mmosal\_task\_wait\_for\_notification(), mmosal\_task\_notify(), mmosal\_task\_notify\_from\_isr()) has been deprecated. This API is no longer used by morselib, and it may be removed from the MMOSAL API in the future. The macro MMOSAL\_DEPRECATED\_API\_ENABLED has been added to mmosal.h. If set to 0, then the deprecated MMOSAL API will be excluded by the preprocessor. The default value is 1 to allow for backward compatibility, but it can be overridden to 0 for increased strictness. **2.5.5.3 MMWLAN API** Newly added API: * morse\_chip\_id\_string field added to mmwlan\_version struct. * home\_channel\_dwell\_time\_ms field added to mmwlan\_scan\_config struct. * Duty cycle API (mmwlan\_set\_duty\_cycle\_mode() and mmwlan\_get\_duty\_cycle\_stats()) added. * STA event callback API added (sta\_evt\_cb and sta\_evt\_cb\_arg fields added to mmwlan\_sta\_args struct). *(Beta)* * extra\_assoc\_ies and extra\_assoc\_ies\_len fields added to mmwlan\_sta\_args struct. * use\_4addr field added mmwlan\_sta\_args struct. * DPP API added (mmwlan\_dpp\_start() and mmwlan\_dpp\_stop()). *(Beta)* * dwell\_on\_home\_ms field added to mmwlan\_scan\_args struct. * Soft AP API added (mmwlan\_softap\_enable() and mmwlan\_softap\_disable()). *(Beta)* API changes: * MMWLAN\_SCAN\_DEFAULT\_DWELL\_TIME\_MS was reduced from 105 to 30 due to improvements in scan implementation. **2.5.5.4 MMHAL API** The behavior regarding the invocation of the function mmhal\_read\_mac\_addr() has changed. This function will now only be invoked once after boot of the transceiver (e.g., via mmwlan\_boot()) and the value will be cached, where previously it may have been invoked multiple times. **2.5.5.5 MMAGIC** Restructured auto-generated MMAGIC source code files to remove .def files and replace them with .c files. In doing this, several existing .c files were also renamed for clarity. This change should be transparent to users of the auto-generated makefile fragments. Low-level MMAGIC Controller API added: mmagic\_controller\_agent\_sync() and mmagic\_controller\_request\_agent\_reset(). New API: *TLS*, *MQTT*, and *NTP*. Currently supported in M2M mode only. Due to FLASH constraints, support for the MMAGIC CLI has been removed on the mm-ekh08-wb55 platform. **2.5.5.6 MQTT agent** MQTT agent has been moved out of the aws-common component and into its own freertos-libs component. This enables using the MQTT agent without introducing a dependency on AWS, such as in the MMAGIC MQTT module. Existing Makefile-based applications using MQTT via AWS will need to include an additional Makefile fragment in their root Makefile:: include $(MMIOT\_ROOT)/mk/mqtt-agent-task.mk This change should be transparent to users of the auto-generated makefile fragments. **2.5.5.7 Makefile infrastructure** Setting of Makefile CFLAGS for optimization has been moved from misc.mk to Makefile for each example. Projects relying on this flag being set in misc.mk will need to be updated to set the flag in their Makefile. **2.5.5.8 Morse Firmware/BCFs** The firmware version has been updated from 1.15.3 to 1.16.4. Devices may need to have their BCF files updated to the latest version if they want the latest features on MM6108/MM8108. #### 2.5.6 Components | Component | Version | | ------------------- | ------------------------------------------------------------------- | | Morse firmware | 1.16.4 | | Regulatory Database | 2.4.1 | | FreeRTOS kernel | 10.5.1 | | LWIP | 2.2.0 | | FreeRTOS + TCP | 4.3.1 | | mbedTLS | 3.6.2 | | STM32U5 BSP | 1.4.0 | | STM32WB55 BSP | 1.14.1 | | BCF API | 12.1.0 (backwards compatible to 8.0.0, but features may be limited) | ## 3 System Details ### 3.1 System Memory Requirements Supported architectures\*: * ARM Cortex-M4F * ARM Cortex-M7F * ARM Cortex-M33F \*Users can compile morselib from source to integrate with other architectures. | Memory | Recommended | | ------ | ----------- | | RAM | 256 KB+ | | Flash | 2 MB+ | Space required will depend on the specific application. This may not be sufficient to support, for example, cloud connectivity, where application-layer protocols such as TLS and MQTT are required. ### 3.2 HaLow Throughput Performance Throughput is measured at 8 MHz, with RTS disabled (unless otherwise stated), SGI enabled, power-save enabled, using Lightweight IP (LWIP), and with iperf run for 60 seconds, taking the median of 5 iterations. * MM-IoT-SDK 2.13 STA * Linux AP with 2.0 drivers/firmware. | Test Type | Platform | UDP STA→AP (Mbps) | UDP AP→STA (Mbps) | TCP STA→AP (Mbps) | TCP AP→STA (Mbps) | | ---------------------------- | --------------------- | ----------------- | ----------------- | ----------------- | ----------------- | | Single STA | MM6108 EKH08-WB55 | 5.6 | 10 | 4.6 | 5.8 | | Single STA | MM6108 EKH05 SDIO | 22 | 22 | 7.0 | 9.4 | | Single STA | MM6108 EKH05 SPI | 17 | 18 | 6.4 | 8.2 | | Single STA | MM8108 EKH05 SDIO | 24 | 30 | 8.5 | 10 | | Single STA | MM8108 EKH05 SPI | 19 | 19 | 7.7 | 9.7 | | Multi STA (4 STA cumulative) | MM6108 EKH08-U575 SPI | 20 | 26 | 10 | 14 | | Multi STA (4 STA cumulative) | MM8108 EKH05 SPI | 25 | 35 | 11 | 17 | ## 4 Revision History | Version Number | Release Date | Release Notes | | -------------- | ------------ | --------------- | | 1 | 01 Oct 2025 | Initial Release | | 2 | 03 Mar 2026 | Added 2.10.4 | | 3 | 01 May 2026 | Added 2.11.2 | | 4 | 01 Jul 2026 | Added 2.12.3 | | 5 | 02 Sep 2026 | Added 2.13.1 | # CMSIS Pack Software Release Notes v4 1.10.2 [Download as PDF](https://www.morsemicro.com/resources/software_releases/iot/CMSIS-Pack-Software-Release-Notes.pdf) ## CMSIS-Pack Software Release Notes ## 1 Overview This document provides the software release notes for the Morse Micro CMSIS-Pack, an STM32Cube IDE Expansion Pack that integrates the MM-IoT-SDK with Morse Micro's MM6108 and MM8108 Wi-Fi HaLow (IEEE 802.11ah) chips. It is intended for developers working with the MM6108-EKH05 and MM8108-EKH05 evaluation kits. Each release section documents new features, improvements, known issues, and deprecation notices introduced since the previous release. ## 2 Software Change History ### 2.1 Release 1.10.2 #### 2.1.1 New Features * CMSIS-Pack has been updated to use MM-IoT-SDK release 2.12.3. * Please refer to the Release Notes for MM-IoT-SDK 2.12.3 for more information on the changes introduced in this release. #### 2.1.2 Other Improvements * CMSIS-Pack includes build-defines as a plain text file as part of the pack (see build\_defines.txt). This makes it easier to communicate build-defines without users having to inspect the example projects. * CMSIS-Pack defines explicit, non-conflicting paths for all header files in all components, including hostap. This ensures projects can rely on the dynamically generated include paths from CubeMX, rather than copy-pasting settings from the example projects. #### 2.1.3 Known Issues * Using IPv6 with the iPerf example fails because traffic is not received.\ Workaround: Manually set the iPerf bind address to ::0 when using IPv6. * The release build variant of the demo applications has instability. This option has been removed until the next CMSIS-Pack release.\ Workaround: Do not upgrade to 1.10.2, or wait until the next release. #### 2.1.4 Deprecation Notices * Nil ### 2.2 Release 1.9.0 #### 2.2.1 New Features * CMSIS-Pack has been updated to use MM-IoT-SDK release 2.11.2. Please refer to the Release Notes for MM-IoT-SDK 2.11.2 for more information on the changes introduced in this release. * The CMSIS-Pack also includes new components to allow building morselib and hostap from source. #### 2.2.2 Other Improvements * Nil #### 2.2.3 Known Issues * Using IPv6 with the iPerf example fails with traffic not being received.\ Workaround: Manually set the iPerf bind address to ::0 when using IPv6. #### 2.2.4 Deprecation Notices * The FreeRTOS+TCP networking stack has been removed. ### 2.3 Release 1.8.4 #### 2.3.1 New Features * CMSIS-Pack has been updated to use MM-IoT-SDK release 2.10.4. Please refer to the Release Notes for MM-IoT-SDK 2.10.4 for more information on the changes introduced in this release. * The EKH05-Demo example now has a Command Line Interface (CLI) over UART. This provides an interactive interface for controlling the application. #### 2.3.2 Other Improvements * CMSIS-Pack has been updated to make changing between Morse Micro chips (MM6108 and MM8108) and between demo example applications more straightforward. #### 2.3.3 Known Issues * Using IPv6 with the iPerf example fails with traffic not being received.\ Workaround: Manually set the iPerf bind address to ::0 when using IPv6. #### 2.3.4 Deprecation Notices * The FreeRTOS+TCP networking stack is deprecated by MM-IoT-SDK. It will be removed in the next release. ### 2.4 Release 1.7.4 #### 2.4.1 New Features * CMSIS-Pack has been updated to use MM-IoT-SDK release 2.9.7. Please refer to the 2.9.7 release notes for more information on the changes introduced in this release. * Support added for the new MM8108-EKH05 evaluation kit. The out-of-the-box example will flash the LEDs based on the EKH05's accelerometer. * A new CLI example has been added. This allows the user to send commands to the device over the UART, providing an interactive method for status and control of the EKH05. #### 2.4.2 Other Improvements * It is now possible to select the region via BLE when using the out-of-box demo (MM6108-EKH05 only). #### 2.4.3 Known Issues * Using IPv6 with the iPerf example fails with traffic not being received.\ Workaround: Manually set the iPerf bind address to ::0 when using IPv6. ### 2.5 Release 1.6.1 #### 2.5.1 New Features * CMSIS-Pack has been updated to use MM-IoT-SDK release 2.8.2, which includes the 1.15.3 drivers/firmware. Please refer to the release notes for 2.8.2 for more information on the changes introduced in this release. * Support added for the new MM8108 chip. * Support for the persistent config store used in MHS for storing configuration. * A shim template to assist users in getting started with new hardware. See the CMSIS-Pack user guide, chapter 10, for more information. #### 2.5.2 Bug Fixes * WNM sleep failed with a duration of 10 minutes or greater. * In the ping example, the post ping idle time was set to 60ms instead of 60s. #### 2.5.3 Known Issues * Using IPv6 with the iPerf example fails with traffic not being received.\ Workaround: Manually set the iPerf bind address to ::0 when using IPv6. ### 2.6 Release 1.5.0 #### 2.6.1 New Features * CMSIS-Pack has been updated to use MM-IoT-SDK release 2.6.4. Please refer to the release notes for 2.6.4 for more information on the changes introduced in this release. * A new version of HaLow\_example has been added that uses the SDIO interface, allowing users to easily switch between SPI and SDIO. #### 2.6.2 Known Issues * iPerf sessions running over IPv6 do not connect. * WNM sleep fails when the duration is 10 minutes or greater. * The post ping idle time is set to 60 ms instead of 60 s. This will impact power measurements. * Workaround: edit the config file in Core/Src/configs.c and change the following line: {“ping.post\_ping\_delay\_ms”, “60”}, to: {“ping.post\_ping\_delay\_ms”, “60000”}, ## 3 Revision History | Version Number | Release Date | Release Notes | | -------------- | ------------ | ------------------------ | | 1 | 25 Oct 2025 | Initial release | | 2 | 02 Apr 2026 | Update for 1.8.4 release | | 3 | 26 May 2026 | Update for 1.9.0 release | | 4 | 15 Sep 2026 | Update for 1.10.2 | # OpenWrt Software Release Notes v4 (3.0.2) [Download as PDF](https://www.morsemicro.com/resources/software_releases/linux/openwrt_source_code/OpenWrt-Software-Release-Notes.pdf) ## 1 Overview This OpenWrt software release introduces a range of new features for the MM6108 and MM8108 evaluation kits, which are now available for evaluation and development. ## 2 Software Change History ### 2.1 Release 3.0.2 (MM6108) Release 3.0.2 is the latest release for the OpenWrt-based evaluation kits, following the previous 2.12.6 release. Starting with the 3.x series, MM6108 and MM8108 drivers/firmware are maintained as separate components within OpenWrt, and each may be updated independently. OpenWrt releases may update one driver while leaving the other unchanged. In this release, version 3.0.2 covers MM6108 only with no updates to MM8108. The most significant change relative to 2.12.6 is the update of the driver/firmware for MM6108 from 1.17.9 to 2.0.1; MM8108 driver/firmware remains at version 1.17.9. #### 2.1.1 New Features * Updated the MM6108 driver/firmware to 2.0.1 (from 1.17.9) * Added Brazil (BR) country code handling in OpenWrt for Wi-Fi HaLow * Airtime Fairness is enabled by default #### 2.1.2 Feature Improvements * 802.11s Mesh improvements: * Mesh peer count raised to 20 * Added mesh keep-alive * Default Mesh Point beacon interval set to 1000 ms (configurable 1000–2000 ms) * Default mesh RSSI threshold changed from −85 dBm to −80 dBm #### 2.1.3 Known Issues **2.1.3.1 System stability and performance** * Multi-STA throughput instability and medium monopolization: in larger setups (more than 4 stations), a few stations can monopolize the medium and starve others * At 8 MHz, TCP uplink throughput is lower than expected with 7 stations * At 4 MHz, UDP downlink is unstable with more than 5 stations, and TCP fails with 7 stations * At 2 MHz and 1 MHz, downlink and TCP uplink are spotty or collapsing, and reliable only with 1–3 stations * DPP association reliability: DPP may occasionally fail and need a retry * Association and roaming: CAC association can take longer under load * 802.11s Mesh: stability and throughput gaps remain after the 3.0 mesh improvements * Fragmentation: Thin LMAC does not support fragmentation * UDP traffic can have up to 1.6% packet loss under heavy load, though maximum throughput can still be achieved **2.1.3.2 GUI and EasyMesh** * The GUI permits transmission power settings that exceed BCF regulatory constraints; however, these values are not applied even though no error message is shown * ARP-scan diagnostics dropdown does not show wireless interface names * Range-Test field needs a validation limit, and there is a header mismatch in the exported CSV * EasyMesh agent advertises an incorrect model name/serial in the 1905 AP-Autoconfiguration WSC packet, and may fail to re-associate after a Controller SSID change with WPS retry Please refer to the Linux Software Release Notes for comprehensive details regarding the new features and known issues introduced in the 2.0.1 (MM6108) driver/firmware update. ### 2.2 Release 2.12.6 Release 2.12.6 is the latest release for the Openwrt-based evaluation kits, building on the 2.11.12 release. The 2.12.6 release updates the base to OpenWrt 24.10.5, integrates a beta S1G driver, and steps the Morse driver/firmware to 1.17.9, together with a range of GUI, channelization, roaming, multi-STA, and stability improvements. #### 2.2.1 New Features * Updated OpenWrt version from 23.05.5 to 24.10.5 * Updates the Linux kernel from v5.15.167, with v6.1.110-1 mac80211 backport, to v6.6.119, with a v6.12.61 mac80221 backport. * Introduces a beta S1G (NS1G) driver integrated alongside the existing Morse driver, with in-GUI driver switching. * Enables an evaluation platform for NS1G support * Integrates release 1.17.9 of the Linux Firmware and Driver Package for MM6108 and MM8108. * Please refer to the Linux Firmware and Driver Package Release Notes for details regarding release 1.17.9 * SSH and HTTP are disabled by default (only the HTTPS web UI is accessible) * Digicert-based OpenSSL image signature verification applies (unsigned images require forcing / enforce\_fw\_sign='0') * Default Morse interface name changed from `wlanX` to `wlhX` #### 2.2.2 Feature Improvements **2.2.2.1 System stability and performance** * Fixed unsanitized network password fields when generating sysdumps * Improved disassociation behavior * Fixed AP’s incorrectly disassociating stations * Improved DPP push button behavior * Increased scan dwell time * Fixed STA disconnect after long-running periods * Fixed Wi-Fi HaLow interface failing to come up on hard power cycle * Renamed the default Morse interface name from `wlanX` to `wlhX` * Fixed Wi-Fi HaLow interface failing to come up when switching between USB ports on USB devices **2.2.2.3 Mesh and networking improvements** * Fixed the previously associated agent, which was sometimes unable to reconnect after a controller channel change * Fixed agent 2.4GHz SSID not automatically syncing with the controller * Fixed extender not inheriting mesh gate’s channelization parameters #### 2.2.3 Known Issues **2.2.3.1 Constraints with new native S1G feature** * As NS1G is marked as a Beta product, it is expected that not only will features be limited, but users will go through a more manual configuration process than the default Morse path. For example, the Morse Wizards are not compatible with the NS1G driver. The intended use for NS1G currently is a basic AP/STA setup, and configuration will be done primarily through the Quick Config/Network pages. * Userspace applications such as iwinfo and the frontend may report slightly erroneous information. **2.2.3.2 Unbalanced downlink distribution and crashes in multi-STA scenarios** * In multi-STA setups, an unbalanced downlink distribution may be observed when traffic is sent simultaneously to more than four stations, with the first two associated stations potentially monopolizing the medium. * Even with enable\_airtime\_fairness enabled, an AP crash may occur when more than 6 stations saturate the downlink. **2.2.3.3 Performance constraints on MM6108** * UDP throughput over IPv6 is lower than IPv4 when using 4 MHz and 8 MHz channels * In regulatory domains with duty-cycle restrictions (e.g., EU, Japan), MCS10 may not provide usable bandwidth without Burst Mode * Workaround: Enable Burst Mode **2.2.3.4 Networking and protocol behavior on MM6108 & MM8108** * Intermittent STA association latency may occur, occasionally resulting in an “MFP required” error report. * In rare circumstances, it is possible that despite DPP succeeding in both AP and STA and credentials being correctly provisioned, they will fail to reach a connected state. * Workaround: Wait for the DPP lockout period and retry. **2.2.3.5 Receive degradation at 2 MHz near -73 dBm RSSI on MM8108** * Some degradation is observed at 2 MHz, with an RSSI of approximately -73 dBm. * Workaround: Increase or decrease the RSSI by 2 dB to resolve this issue. **2.2.3.6 Receive degradation at 1 MHz at strong signals on MM8108** * Some degradation is seen at 1 MHz at strong signal levels. * Workaround: Move the devices farther apart to lower the signal strength. **2.2.3.7 Intermittent STA association failure at very close range on MM8108** * When pairing two devices at very close range, the STA may intermittently fail to join the device due to excessively strong received signal levels (greater than -10 dBm). * Workaround: Ensure a minimum separation of 2 meters between the AP and STA before initiating the pairing sequence to maintain reliable association. An improvement is planned for the next firmware release. ### 2.3 Release 2.11.12 This section summarizes software changes made since release 2.9.3. #### 2.3.1 New Features * Integrate release 1.17.8 of the Linux Firmware and Driver Package for MM6108 and MM8108. * Please refer to the Linux Firmware and Driver Package Release Notes for details regarding release 1.17.8 * Updated AU channelization support (IEEE 802.11-2024) * Aligns Australian channel definitions with the latest IEEE 802.11-2024 specification * Scheduled Scan support * Enables periodic background scanning for improved network discovery and roaming * 802.11s Mesh support (Beta) on MM8108 * Enables multi-node mesh networking with dynamic routing and self-healing capabilities #### 2.3.2 Feature Improvements **2.3.2.1 Security compliance improvements** * Updated OpenSSL configuration to meet current security standards **2.3.2.2 Multi-STA performance** * Improved multi-STA performance (validated up to 8 stations) * Improved interference performance on MM8108 under challenging RF conditions **2.3.2.3 System stability and performance** * Enhanced Automatic Channel Selection (ACS): * Avoids invalid/disabled channels * Improved ACS noise measurement behavior * Improved QoS handling: * Improved resilience to QoS Control field mismatches * Offloaded features now use QoS Data frames * Improved channel handling: * Wider channels no longer disabled due to sub-channel restrictions * Improved scan and association behavior: * Fixed scan timeout behavior and standby recovery issues * Fixed probe response bandwidth handling * Improved driver stability: * Fixed memory handling issues during hardware restart * Improved system behavior under interference conditions on MM8108 * Power save behavior update on MM8108 * SDIO clock pin now enters high-impedance state during power save * Reduces unintended power consumption **2.3.2.4 Mesh and networking improvements** * On MM8108: * Introduction of 802.11s mesh (Beta) * On MM6108: * Optimizations to 802.11s mesh (HWMP) * Improved multi-hop traffic handling (including DHCP propagation) * Avoided unnecessary HWMP frames when other mesh protocols are used **2.3.2.5 Power and efficiency improvements** * On MM6108: * Optimized TIM handling under duty cycle constraints * Reduced unnecessary host wakeups through firmware-based packet filtering * On MM8108: * Improved power-saving behavior through: * WNM Sleep * Dynamic TWT * SDIO power handling improvements **2.3.2.6 Platform updates** * Updated regulatory support: * IEEE 802.11-2024 AU channelization * EU and GB region support ### 2.3.2.7 Documentation * Updated user guide: * Lists open network ports with usage context * Includes additional configuration guidance #### 2.3.3 Known Issues **2.3.3.1 Unbalanced downlink distribution in multi-STA scenarios** * In multi-STA setups, an unbalanced downlink distribution may be observed when traffic is sent simultaneously to more than four stations, with the first two associated stations potentially monopolizing the medium. * Workaround: Enable airtime fairness on both MM8108 & MM6108 (enable\_airtime\_fairness=1). **2.3.3.2 Performance constraints on MM6108** * UDP throughput over IPv6 is lower than IPv4 when using 4 MHz and 8 MHz channels * In regulatory domains with duty-cycle restrictions (e.g., EU, Japan), MCS10 may not provide usable bandwidth without Burst Mode * Workaround: Enable Burst Mode **2.3.3.3 Networking and protocol behavior on MM6108** * Intermittent STA association latency may occur, occasionally resulting in an “MFP required” error report. * In rare cases, DPP provisioning may fail and require a retry. **2.3.3.4 Receive degradation at 2 MHz near -73 dBm RSSI on MM8108** * Some degradation is observed at 2 MHz, with an RSSI of approximately -73 dBm. * Workaround: Increase or decrease the RSSI by 2 dB to resolve this issue. **2.3.3.5 Receive degradation at 1 MHz at strong signals on MM8108** * Some degradation is seen at 1 MHz at strong signal levels. * Workaround: Move the devices farther apart to lower the signal strength. **2.3.3.6 Intermittent STA association failure at very close range on MM8108** * When pairing two devices at very close range, the STA may intermittently fail to join the device due to excessively strong received signal levels (greater than -10 dBm). * Workaround: Ensure a minimum separation of 2 meters between the AP and STA before initiating the pairing sequence to maintain reliable association. An improvement is planned for the next firmware release. ### 2.4 Release 2.9.3 This section summarizes software changes made since the previous release. #### 2.4.1 New Features * Support for MM8108, including BCFs for MM8108-based modules * The MM8108 is the next-generation Wi-Fi HaLow SoC developed by Morse Micro. It offers a highly integrated, low-power, single-chip Wi-Fi HaLow connectivity solution. It supports long-range data rates up to 43 Mbps using 256-QAM modulation over the air at 8 MHz bandwidth in the sub-1 GHz (license-exempt) bands worldwide. For more details, visit morsemicro.com/chips * Integrate release 1.16.4 of the Linux Firmware and Driver Package for MM6108 and MM8108. * Please refer to the Linux Firmware and Driver Package Release Notes for details regarding release 1.16.4. * Support for the new MM8108-EKH19 evaluation kit * The MM8108-EKH19 is a new evaluation kit that combines an off-the-shelf router running OpenWRT with a Morse Micro USB network adapter, providing a fully integrated Wi-Fi HaLow connectivity experience * USB hot-plugging support for MM8108-based devices * Hotplugging allows USB devices to be plugged in and removed while the host router is powered and without requiring a reboot. #### 2.4.2 Feature Improvements * The EasyMesh topology viewer now shows the bridge MAC address * EasyMesh will now manage all Wi-Fi radios, rather than just HaLow * This means that network credentials and configuration changes for all Wi-Fi radios will be synchronized across agents. To function, this requires that the radio be included in the br-prpl bridge network * Support added for EU and GB regions. ACS and DCS are always enabled for the EU to allow 100% duty cycle operation on 2MHz channels * Support has been added for MM8108 FullMAC mode (beta - not for production) * This allows the upper MAC layer of the network stack to run on the MM8108, which reduces the processing load on the host CPU * Note that this feature is released for beta testing, integration, and development. It is not considered suitable for mass production * The Web UI now shows which BCFs are installed on the device, along with some basic metadata about each BCF * If multiple BCFs are present, it is possible to select which one to use * The range testing UI now uses OpenStreetMaps for visualizing the range test * The range testing UI allows the location to be manually populated * Multiple SSIDs running on a single Wi-Fi HaLow radio are supported in OpenWrt * Various improvements have been made to DPP push-button pairing to enhance the speed and reliability of pairing #### 2.4.3 Other Improvements * Introduced a 4.3V FEM mode option, with platform-specific support handling for clarity and consistency * Enhanced reliability of upgrades over Wi-Fi HaLow, reducing the likelihood of timeout errors * Improved user guide display on mobile browsers for a smoother, more accessible experience * Optimized USB hotplug detection across platforms for consistent and accurate device recognition #### 2.4.4 Known Issues * In some cases, EasyMesh agents may not join the mesh as expected or may not appear correctly in the connection map. * While not officially supported in the 1.16 MM8108 driver, 802.11s mesh can still be configured and used in non-production environments. * MM6108 EKH devices may occasionally drop connections under heavy traffic conditions, but will automatically recover. The root cause is still under investigation. * Workaround: If this behavior is causing a significant impact in your environment, you can mitigate it by disabling the disassoc\_low\_ack setting in the wireless configuration with the following commands: uci wireless..disassoc\_low\_ack='0' uci commit reload\_config * The new MM8108 driver does not yet include all features available on the MM6108. For a detailed list of supported features, see the MM8108 1.16.4 release notes. * Power saving is currently unavailable for Wi-Fi HaLow radios connected via the USB interface ## 3 Upgrade Guide The device can be easily upgraded via the built-in Web UI by navigating to the Upgrade page. ![](https://content.gitbook.com/content/2yFeTlddp9G0rbIPqV9R/blobs/ebVN4sNW7y363mZlMQoE/Unknown%20image) If the device is connected to the Internet, select “Check for automatic upgrade” and follow the on-screen instructions. Alternatively, you may perform a manual upgrade by uploading the firmware through a web browser. To do this, select “Manually upload firmware file”, choose the appropriate file from your local system, and follow the prompts to complete the process. The device will automatically reboot once the upgrade is finalized. Configuration settings can be retained during version upgrades but not during downgrades. Unless configuration preservation is specifically required, we recommend starting with a fresh configuration to prevent legacy settings from previous versions from carrying over. ## 4 Revision History | | | | | -------------- | ------------ | ---------------------------------- | | Release Number | Release Date | Release Notes | | Version 4 | 1 Jul 2026 | Maintenance release 3.0.2 (MM6108) | | Version 3 | 26 Jun 2026 | Maintenance release 2.12.16 | | Version 2 | 1 May 2026 | Maintenance release 2.11.12 | | Version 1 | 23 Sep 2025 | Initial release 2.9.3 | Morse Micro provides this information "as is" without warranties of any kind, express or implied. No guarantee is made as to the accuracy, completeness, or suitability of this information or Morse Micro’s products for any specific purpose. Use of this information and products is at the user’s sole risk. Morse Micro products are not designed or tested for use in mission-critical systems, and should not be used in such applications. Performance specifications are based on internal testing and are believed to be reliable; however, they are not guaranteed. It is the Buyer’s responsibility to test and validate all product performance, compatibility, and compliance, both in isolation and within end applications. Morse Micro assumes no liability for the use or application of any product, circuit, or information described herein. No license or other rights—express or implied—are granted under Morse Micro’s intellectual property. This document contains proprietary information of Morse Micro and is subject to change without notice. Wi-Fi®, Wi-Fi HaLow™, and the Wi-Fi logo are trademarks of Wi-Fi Alliance. ZigBee™ and Z-Wave™ are trademarks of their respective owners. All other trademarks are the property of their respective owners. # Datasheets Datasheets provide product specifications, electrical characteristics, pin descriptions, and design requirements for Morse Micro hardware. ### Datasheets #### [MM8108 Datasheet](/datasheets/mm8108-datasheet) Datasheet for the MM8108 Wi-Fi HaLow system-on-chip. #### [MM6108 Datasheet](/datasheets/mm6108-datasheet) Datasheet for the MM6108 Wi-Fi HaLow system-on-chip. #### [MM8108-MF15457 Datasheet](/datasheets/mm8108-mf15457-datasheet) Datasheet for the MM8108-MF15457 Wi-Fi HaLow module. #### [MM8108-M20 Preliminary Datasheet](/datasheets/mm8108-m20-preliminary-datasheet) Preliminary datasheet for the MM8108-M20 Wi-Fi HaLow module. #### [MM6108-MF08651-US Datasheet](/datasheets/mm6108-mf08651-us-datasheet) Datasheet for the MM6108-MF08651-US Wi-Fi HaLow module. # MM8108 Datasheet v4 [Download as PDF](https://www.morsemicro.com/resources/datasheets/chips/MM8108_Data_Sheet.pdf) ## 1 Product Overview ### 1.1 Introduction Wi-Fi HaLow (pronounced "HEY-low") is the first global Wi-Fi standard (IEEE 802.11ah) specifically designed to meet the needs of the Internet of Things (IoT). It’s an open standard wireless network technology operating in the sub-1 GHz license-exempt RF bands (850 MHz to 950 MHz range), so it doesn’t incur ongoing monthly costs like cellular/mobile network connections. By operating in the sub-1 GHz range, this low-power wireless protocol can connect more IoT devices over much longer distances and with significantly lower power consumption than traditional Wi-Fi. Morse Micro, the world’s leading Wi-Fi HaLow solutions provider, offers several Wi-Fi HaLow connectivity solutions. The MM8108 SoC is a single-chip solution that incorporates radio, PHY, and MAC functions, all of which are compliant with the IEEE 802.11ah standard. It supports world-leading power efficiency and PHY rates up to 43.3 Mbps using world-first 256-QAM modulation at an 8 MHz bandwidth. It is ideal for power-sensitive and high-speed applications. Its integrated power amplifier (PA) offers world-leading transmit performance and energy efficiency with on-chip amplification of up to 26 dBm, which is ideal for low-cost devices. For ultra-long reach applications, the MM8108 can be paired with an external PCB mount power amplifier, typically included in front-end modules (FEMs). The high-performance integrated low-noise amplifier (LNA) offers exceptional receive sensitivity. These features, combined with digital transmit filtering and pre-distortion circuits, result in an advanced transceiver design that ensures out-of-the-box compatibility with all global Wi-Fi HaLow regulatory environments while reducing external component costs by eliminating the requirement for expensive external filters. MM8108 supports a USB 2.0 High-Speed host interface and an SDIO/SPI host interface, offering solution architects flexibility when integrating Wi-Fi HaLow connectivity into their existing solution. With a footprint of only 5 mm x 5 mm and a higher level of integration than previous generations of chipsets, the MM8108 can fit even smaller designs while substantially reducing the overall cost of materials. MM8108 supports WPA3 and all standard security features required for Wi-Fi HaLow product certifications. ### 1.2 Features * Single-stream maximum PHY rate of 43.3 Mbps at 8 MHz bandwidth * Radio supporting all global Sub-1 GHz frequency bands * Frequency Range: 850 MHz to 950 MHz * Channel width options of 1/2/4/8 MHz * High power and extremely high efficiency integrated PA with maximum 26 dBm (400 mW) output power at 45% PA efficiency and 37% SoC efficiency * Novel PA architecture maintains efficiency at power backoff * Low-power receiver with integrated LNA, NF < 4 dB * Compatible with external LNA, PA for higher power or sensitivity requirements * 802.11ah OFDM PHY with Wi-Fi Alliance Wi-Fi HaLow certification * BPSK, QPSK, 16-QAM, 64-QAM and 256-QAM * Automatic frequency and gain control * Packet detection and channel equalization * Forward Error Correction (FEC) coding and decoding * Modulation and Coding Scheme (MCS) levels 0-10 * 1 MHz duplicate mode * Optional traveling pilots * 802.11ah MAC with Wi-Fi Alliance Wi-Fi HaLow certification * Support for Station (STA) and Access Point (AP) roles * Listen-Before-Talk (LBT) access with energy detection * 802.11 power save * 802.11 fragmentation and defragmentation * Power-Saving Target Wake Time (TWT) support for extended battery life * Automatic and manual MCS rate selection * On-chip software stack assisting with host offload of Wi-Fi connection management * USB 2.0 High-Speed compliant device interface * Integrated USB 2.0 PHY and device interface supporting High-Speed mode at 480 Mbps * SDIO 2.0 compliant device interface * SDIO 2.0 High-Speed at 50 MHz max for 200 Mbps * Support for 1-bit and 4-bit data mode * Support for SPI mode operation at up to 80 MHz for 80 Mbps * Power Management Unit (PMU) supporting various modes of operation * Single supply 3.0-3.6 V for integrated DC-DCs and LDOs * Multiple low-power modes (hibernate, deep sleep, snooze, USB snooze) support extreme power environments * Support for an external real-time clock source providing the highest accuracy timing for sleep modes * Wide spectrum of security features * Wi-Fi layer security, including Wi-Fi Protected Access version 3 (WPA3), Protected Management Frames (PMF), and Opportunistic Wireless Encryption (OWE) * Hardware support for Advanced Encryption Standard (AES) and Secure Hash Algorithm version 2 (SHA-2) functions (SHA-256, SHA-384, SHA-512) ### 1.3 Applications For Internet of Things (IoT) and Machine-to-Machine (M2M) applications, such as: * Surveillance Cameras and Sensors * Cloud Connectivity * Low-power Sensor Networks * Building Automation Systems * Asset Tracking and Management * Machine Performance Monitors and Sensors * Building Access Control and Security * Drone Video and Navigation Communications * Connected Toys and Games * Rural Internet Access * Agricultural Networks * Utility Smart Meter and Intelligent Grid * Proximity Sensors * Industrial Automation Controls * Smart Home Automation * EV Car Chargers * Appliances * Construction Site Connectivity * Smart Signs and Kiosks * Retail Point-of-Sale Terminals * Vehicle-to-Vehicle Communications * IP Sensor Networks * Biometric IDs and Keypads * Warehouse Connectivity * Intelligent Lighting Controls * BT/ZigBee™/Z-Wave™ to Wi-Fi HaLow Gateways * Smart City Networks ## 2 Pin Overview ### 2.1 Pin Layout The MM8108 device package features 79 pins in a 5 mm x 5 mm package, as described in this section. ![Figure 1: Pin diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/HECTsBtrc9PWYl1wma6k/Unknown%20image) ### 2.2 Pin Descriptions The two buck converters on MM8108 are referred to as BUCK and BUCK\_TX, which have output voltages of 1.2 V and 1.8 V, respectively. **Table 1: Pin description** | Pin | Default Functionality Pin Name | Default Functionality Type | Default Functionality Description | Alternative 1 Pin Name | Alternative 2 Pin Name | | --- | ------------------------------ | -------------------------- | ---------------------------------------- | ---------------------- | ---------------------- | | A1 | GND | Ground | | | | | A2 | XON | Analog | 32 MHz crystal connection | | | | A3 | XOP | Analog | 32 MHz crystal connection | | | | A4 | GND | Ground | | | | | A5 | VBUCK | Supply | BUCK voltage | | | | A6 | WAKE\_UP | Analog | External wake from Deep Sleep and Snooze | | | | A7 | VBUCK\_FB | Supply | Voltage sense pin for BUCK output | | | | A8 | VBAT\_PWR | Supply | 3.3 V VBAT supply for BUCK | | | | A9 | GND | Ground | | | | | B1 | RTC\_XON | Analog | RTC XTAL connection, NC if unused | | | | B2 | NC | Not connected | | | | | B3 | NC | Not connected | | | | | B4 | VBUCK | Supply | BUCK output voltage | | | | B5 | VBAT\_AON | Supply | 3.3 V VBAT supply for the AON unit | | | | B6 | RESET\_N | Analog | Asynchronous chip reset (active low) | | | | B7 | GND | Ground | | | | | B8 | GND | Ground | | | | | B9 | VSW | Supply | BUCK switching node | | | | C1 | RTC\_XOP | Analog | RTC XTAL connection, NC if unused | | | | C2 | NC | Not connected | | | | | C3 | NC | Not connected | | | | | C4 | NC | Not connected | | | | | C5 | GND | Ground | | | | | C6 | GPAIO | Analog | Analog test signal (keep grounded) | | | | C7 | NC | Not connected | | | | | C8 | GND | Ground | | | | | C9 | GND | Ground | | | | | D1 | GND | Ground | | | | | D2 | GND | Ground | | | | | D3 | LO\_TEST | Analog | Analog test signal (keep grounded) | | | | D4 | GND | Ground | | | | | D5 | GPIO \_12 | Digital I/O | | FEM\_Control | FEM\_Control | | D6 | JTAG\_TMS | Digital I/O | JTAG mode select | | | | D7 | JTAG\_TDO | Digital I/O | JTAG data out | | | | D8 | SDIO\_D3 | Digital I/O | SDIO/SPI data line | SPI\_CS | QSPI\_D3 | | D9 | SDIO\_D0 | Digital I/O | SDIO/SPI data line | SPI\_MISO | QSPI\_D0 | | E1 | RFIN | RF | Receiver input | | | | E2 | GND | Ground | | | | | E3 | NC | Not connected | | QSPI\_CSB\_1 | QSPI\_CSB\_1 | | E4 | GPIO \_9 | Digital I/O | | | | | E5 | GPIO \_11 | Digital I/O | | FEM\_Control | FEM\_Control | | E6 | JTAG\_TCK | Digital I/O | JTAG clock | | | | E7 | JTAG\_TDI | Digital I/O | JTAG data in | | | | E8 | SDIO\_D2 | Digital I/O | SDIO/SPI data line | 47 kΩ pull-up needed | QSPI\_D2 | | E9 | SDIO\_D1 | Digital I/O | SDIO/SPI data line | SPI\_IRQ | QSPI\_D1 | | F1 | GND | Ground | | | | | F2 | Depopulated | | | | | | F3 | GND | Ground | | | | | F4 | GPIO \_8 | Digital I/O | | BUSY | BUSY | | F5 | GPIO \_10 | Digital I/O | | FEM\_Control | FEM\_Control | | F6 | GND | Ground | | | | | F7 | GND | Ground | | | | | F8 | SDIO\_CMD | Digital I/O | SDIO/SPI command/data line | SPI\_MOSI | QSPI\_CSB | | F9 | SDIO\_CLK | Digital I/O | SDIO/SPI clock input | SPI\_SCK | QSPI\_CLK | | G1 | RF\_OUT | RF | Transmitter output | | | | G2 | Depopulated | | | | | | G3 | VBUCK\_TX | Supply | BUCK\_TX voltage for the transmitter | | | | G4 | GPIO \_7 | Digital I/O | | DBG\_UART\_MM\_RX | DBG\_UART\_MM\_RX | | G5 | GPIO \_3 | Digital I/O | | QSPI\_D1 | UART\_RX | | G6 | GPIO \_4 | Digital I/O | | QSPI\_D2 | UART\_RTS | | G7 | GPIO \_5 | Digital I/O | | QSPI\_D3 | UART\_CTS | | G8 | VDDIO | Power | Host supply for digital I/O | | | | G9 | GND | Ground | | | | | H1 | GND | Ground | | | | | H2 | VBUCK\_TX | Supply | BUCK\_TX voltage for the transmitter | | | | H3 | GPIO \_6 | Digital I/O | | DBG\_UART\_MM\_TX | DBG\_UART\_MM\_TX | | H4 | GPIO \_0 | Digital I/O | | QSPI\_CLK | | | H5 | GPIO \_1 | Digital I/O | | QSPI\_CSB\_0 | | | H6 | BUSY | Digital I/O | BUSY signal output | QSPI\_D0 | UART\_TX | | H7 | GND | Ground | | | | | H8 | GND | Ground | | | | | H9 | VSW\_TX | Supply | BUCK\_TX switching node | | | | J1 | GND | Ground | | | | | J2 | VBUCK\_TX | Supply | BUCK\_TX voltage for the transmitter | | | | J3 | GND | Ground | | | | | J4 | USB\_DP | USB I/O | USB Data Plus (DP) line | | | | J5 | USB\_DM | USB I/O | USB Data Minus (DM) line | | | | J6 | USB\_VCC33A | Supply | USB 3.3 V supply | | | | J7 | VBUCK\_FB\_TX | Supply | Voltage sense pin for BUCK\_TX | | | | J8 | VBAT\_PWR\_TX | Supply | 3.3V VBAT supply to BUCK\_TX | | | | J9 | GND | Ground | | | | **Table 2: Alternative pin functionality description** | Alternative Pin Functionality Descriptions Pin Name | Alternative Pin Functionality Descriptions Description | | --------------------------------------------------- | ------------------------------------------------------ | | FEM\_Control | External front-end module control | | SPI\_SCK | SPI host interface serial clock | | SPI\_MOSI | SPI host interface master out, slave in | | SPI\_MISO | SPI host interface master in, slave out | | SPI\_IRQ | SPI host interface interrupt line | | SPI\_CS | SPI host interface chip select | | QSPI\_CLK | QSPI interface clock | | QSPI\_D0 | QSPI interface data line 0 | | QSPI\_D1 | QSPI interface data line 1 | | QSPI\_D2 | QSPI interface data line 2 | | QSPI\_D3 | QSPI interface data line 3 | | QSPI\_CSB\_0 | QSPI interface chip select device 0 | | QSPI\_CSB\_1 | QSPI interface chip select device 1 | | BUSY | Busy signal output | | DBG\_UART\_MM\_RX | Debug UART receive data | | DBG\_UART\_MM\_TX | Debug UART transmit data | | UART\_RX | UART host interface receive data | | UART\_TX | UART host interface transmit data | | UART\_RTS | UART host interface request to send | | UART\_CTS | UART host interface clear to send | ## 3 Functional Description The following sections describe the functions of the MM8108 device. ### 3.1 Functional Block Diagram ![Figure 2: Functional block diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/RDckk9oYQa3eLNDzhspG/Unknown%20image) ### 3.2 Clocks #### 3.2.1 XTAL Clock Deriving clocks in the RF and digital subsystems requires a 32 MHz crystal (XTAL) component. As shown in Figure 3, a Pierce oscillator circuit is used. ![Figure 3: Crystal circuit](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/viaaQh1YiNCXm0nZcauu/Unknown%20image) The crystal is connected between pins XOP & XON. The crystal load capacitance and driver is provided internally inside the chip (denoted in the gray box above). No external load capacitors are required on the PCB. The crystal component should meet the following specifications across the expected temperature range of operation to comply with 802.11ah standards for frequency offset and achieve the specified sensitivity. **Table 3: Crystal component specification** | XTAL Specifications | Min | Typ | Max | Units | | ------------------- | --- | --- | --- | ----- | | Frequency tolerance | - | - | 20 | ppm | | ESR | 10 | - | 100 | Ω | | Load capacitance | - | 8 | - | pF | Note: The crystal component frequency tolerance above is without trimming and is across temperature for the component's lifetime. The equipment designer is responsible for selecting a crystal component that complies with these specifications. #### 3.2.2 RTC XTAL Clock A 32.768 kHz crystal driver circuit is available for optional use as a real-time clock (RTC) source. This source provides the highest accuracy timing for system sleep modes compared with the on-chip RC oscillator, which is used if an RTC XTAL is absent. ![Figure 4: RTC crystal circuit](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/T7NyZ6xRwF7feo8L7y8N/Unknown%20image) As shown in Figure 4, the crystal should be connected between pins RTC\_XOP and RTC\_XON. Load capacitors CL must be placed at these pins and coupled to Ground. The capacitance values should follow the suggestions of the crystal datasheet. The crystal stability should be +/-30 ppm or better for accurate sleep time control. **Table 4: RTC crystal component specification** | RTC XTAL Specifications | Min | Typ | Max | Units | | ----------------------- | --- | ---- | --- | ----- | | Frequency tolerance | – | - | 30 | ppm | | ESR | - | 90 | - | kΩ | | Load capacitance | - | 12.5 | - | pF | ### 3.3 Power Management #### 3.3.1 Power Supply All power is derived from a 3.0 V to 3.6 V power source connected to VBAT\_PWR (A8), VBAT\_AON (B5), and VBAT\_PWR\_TX (J8). VDDIO (G8) can be connected to the same 3.0 V to 3.6 V power source or, if available, to the host's dedicated VDDIO rail. For optimal performance, 4.7 uF, 470 nF, 10 uF, and 470 nF decoupling capacitors are required at VBAT (A8), VBAT\_AON (B5), VBAT\_PWR\_TX (J8), and VDDIO (G8), respectively. VSW (B9) requires a 2.2 uH/10 uF LC filter and a 4.7 uF decoupling capacitor at VBUCK (A5, B4). The VBUCK\_FB (A7) feedback connection must be as close as possible to the load pin VBUCK (A5, B4). VSW\_TX (H9) requires a 1.5 uH/22 uF LC filter at VBUCK\_TX (G3, H2, J2). The VBUCK\_TX\_FB (J7) feedback connection must be as close as possible to the load pin VBUCK\_TX (G3, H2, J2). All ground pins should be connected to a solid ground plane on the second layer of the PCB. #### 3.3.2 Power Modes An internal Power Management Unit (PMU) provides multiple low-power modes that the chip may enter via firmware routines. **Table 5: Power modes overview** | Power Mode | Wake From RESET\_N (B6) | Wake From WAKE\_UP (A6) | Wake From Internal Timer | Wake From USB Signalling | 1 MB SRAM Retained | | ---------- | ----------------------- | ----------------------- | ------------------------ | ------------------------ | ------------------ | | Hibernate | Yes | No | No | No | No | | Deep Sleep | Yes | Yes | Yes | No | No | | Snooze | Yes | Yes | Yes | No | Yes | | USB snooze | Yes | Yes | Yes | Yes | Yes | Note: * Using RESET\_N (B6) to wake the chip will cause a complete chip reboot with no retention of any kind of memory **3.3.2.1 Hibernate** Hibernate mode draws the least current of the low-power modes. It may be exited only by toggling the RESET\_N (B6) pin, which causes the chip to reboot. While in hibernate mode, the chip will not respond to the WAKE\_UP (A6) pin or run an internal timer, and no internal memory will be retained. **3.3.2.2 Deep Sleep** Deep Sleep mode can be exited by toggling the RESET\_N (B6) pin, which causes a complete chip reboot, asserting the WAKE\_UP (A6) pin, or by using an internal timer (running on the real-time clock source). While in Deep Sleep mode, no internal memory will be retained. **3.3.2.3 Snooze** Snooze mode can be exited by toggling the RESET\_N (B6) pin, which causes a complete chip reboot, by asserting the WAKE\_UP (A6) pin, or by using an internal timer (running on the real-time clock source). If the chip resumes operation via the WAKE\_UP (A6) pin or an internal timer, 1 MB of SRAM memory will be retained. No internal memory will be retained if the chip is rebooted using the RESET\_N (B6) pin. **3.3.2.4 USB Snooze** USB snooze mode can be exited by toggling the RESET\_N (B6) pin, which causes a complete chip reboot by asserting the WAKE\_UP (A6) pin, using an internal timer (running on the real-time clock source), or by resuming signaling over the USB bus from the USB host. If the chip resumes operation via the WAKE\_UP (A6) pin, an internal timer, or USB resume signaling, 1 MB of SRAM memory will be retained. No internal memory will be retained if the chip is rebooted using the RESET\_N (B6) pin. ### 3.4 Boot/Reset Sequencing #### 3.4.1 Boot Timing ![Figure 5: Boot timing diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/fQmuIc4eVxduK0W3a3Yu/Unknown%20image) **Table 6: Boot timing overview** | Parameters | Description | Min | Max | Unit | | ---------- | ----------------------------------------------------------------- | --- | --- | ---- | | V IL\_nRST | Reset threshold | 450 | - | mV | | t 0 | Time between VBAT brought up (3.3 V) and RESET\_N being activated | 50 | - | μs | | t B | Boot time | - | 10 | ms | #### 3.4.2 Reset Timing ![Figure 6: Reset timing diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/joVWgDW5JnYoa6SJoT4c/Unknown%20image) **Table 7: Reset timing overview** | Parameters | Description | Min | Max | Unit | | ---------- | ---------------------------------------------------------------- | --- | --- | ---- | | V IL\_nRST | Reset threshold | 450 | - | mV | | t 1 | Duration of RESET\_N signal level < V IL\_nRST to reset the chip | 1 | - | ms | | t B | Boot time | - | 10 | ms | #### 3.4.3 Low-Power Modes Exiting any low-power mode takes at most 10 ms. ### 3.5 USB Host Interface A USB 2.0 High-Speed host interface is available, supporting device mode only at up to 480 Mbps. #### 3.5.1 Pin Description **Table 8: USB bus pins** | Pin | Pin Name | Description | | --- | ----------- | --------------------------------------- | | J4 | USB\_DP | High-speed differential pin, DP | | J5 | USB\_DM | High-speed differential pin, DM | | J6 | USB\_VCC33A | 3.3 V analog supply voltage for USB 2.0 | #### 3.5.2 Features * An integrated USB 2.0 PHY and MAC capable of up to High-Speed mode at 480 Mbps * Device endpoints implementing bulk data, isochronous transfers, and interrupts for the USB host driver to operate the chip as a network AP or STA * Suspend and resume power management functions * USB snooze mode with in-band wake * The USB link must be suspended to enter USB snooze mode. * The chip will initiate wake from USB snooze mode and return to normal operation mode when the USB host issues resume signaling over the USB bus (in-band). **Table 9: USB bus electrical specifications** | Parameter | Min | Typ | Max | Unit | | ------------------------------------------------------------ | --- | --- | --- | ---- | | USB\_VCC33A | 3.0 | 3.3 | 3.6 | V | | V noise\_33A (Allowable power noise on supply, 1 Hz-100 kHz) | - | - | 150 | mV | | I VCC33A | - | 8.1 | 8.4 | mA | ### 3.6 SDIO Host Interface A host interface is available via SDIO 2.0, capable of High-Speed mode and operating at 3.3 V. #### 3.6.1 Pins **Table 10: SDIO pins** | Pin | Pin Name | SDIO 4-bit Mode | SDIO 1-bit Mode | | --- | --------- | ----------------- | ----------------- | | F9 | SDIO\_CLK | Clock pin (input) | Clock pin (input) | | F8 | SDIO\_CMD | Command pin | Command pin | | D9 | SDIO\_D0 | Data pin 0 | Data pin 0 | | E9 | SDIO\_D1 | Data pin 1 | IRQ | | E8 | SDIO\_D2 | Data pin 2 | Unused | | D8 | SDIO\_D3 | Data pin 3 | Unused | #### 3.6.2 Bus Timing The SDIO clock rate supports up to 50 MHz. The SDIO bus always operates in High-Speed (25 Mbps) mode. ![Figure 7: SDIO device bus input timing diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/O92Od4TZsS4VRbGELoH2/Unknown%20image) ![Figure 8: SDIO device bus output timing diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/SBQUgM80hPf0gvOGNVMN/Unknown%20image) **Table 11: SDIO bus timing** | Parameter | Min | Max | Units | | -------------------------------------- | --- | --- | ----- | | Clock frequency | 0 | 50 | MHz | | Clock low time (t WL ) | 7 | - | ns | | Clock high time(t WH ) | 7 | - | ns | | Clock rise time (t LH ) | - | 3 | ns | | Clock fall time (t HL ) | - | 3 | ns | | Input setup time (t ISU ) | 6 | - | ns | | Input hold time (t IH ) | 2 | - | ns | | Output delay (t ODLY(max) ) | - | 14 | ns | | Output hold time (t ODLY(min) ) | 2.5 | - | ns | | Total system capacitance for each line | - | 40 | pF | ### 3.7 SPI Host Interface The SPI interface uses the pin layout as defined below, over which the modified SDIO protocol is used for communication. #### 3.7.1 Pins **Table 12: SPI bus pins** | Pin | Pin Name | SPI mode function | | --- | -------- | -------------------------------------------- | | D8 | CS | Chip select (active low) | | E9 | INT | Interrupt pin | | D9 | MISO | Master data in/slave data out | | F8 | MOSI | Master data out/slave data in | | F9 | CLK | Clock pin (input) | | E8 | Unused | Unused, needs to be pulled high for SPI mode | #### 3.7.2 Initialization in SPI Mode After power-on, the host interface can be brought up as either SDIO or SPI. Per the SDIO specification, the host must send a CMD0 while holding CS low (its asserted state) to switch the interface to SPI mode. For further details on the protocol, refer to the SD Specification Part E1 “SDIO Simplified Specification” version 2.00. #### 3.7.3 SPI Bus Timing The SPI clock rate supports up to 80 MHz. The SPI bus timing is identical to the SDIO bus timing, including considering MOSI and MISO as input and output timing, respectively. The SPI bus defaults to clock idling at logical 0 (CPOL=0), and data is launched and captured on the positive edges of the clock, as per SDIO High-Speed mode. After being initialized, the SPI bus may be configured to behave like CPHA=0 (drive output on negative edge, sample on positive edge). ### 3.8 GPIO #### 3.8.1 Features Up to 12 programmable General Purpose Input/Output (GPIO) pins are available. Each pin can be configured with a unique drive value and with driving enabled or disabled. The value of each pin can be read whether driving or not. Each pin can be configured to generate an interrupt based on level or edge (rising or falling). Inputs are synchronized to the main digital clock, so any pulses must be at least 31.25 us in length. There are internal pull-up and pull-down facilities in the pads and drive-strength selection. #### 3.8.2 Reset State GPIO pins will be undriven at boot and in a high impedance state. #### 3.8.3 Power-Save State The digital GPIOs can be programmed to retain their output state during power-saving modes. Digital GPIOs cannot be used to wake the chip. Only the dedicated WAKE\_UP (A6) pin can be used to wake the chip. If the RESET\_N (B6) pin is asserted while the chip is in any power-save mode, the chip will reboot, the retained digital GPIO state will be lost, and the pads will reset to high impedance. ## 4 Electrical Characteristics ### 4.1 Absolute Maximum Ratings Stress beyond absolute maximum ratings may cause permanent damage to the device. Operation is only guaranteed for recommended operating conditions. Operation of the device outside of recommended conditions may result in reduced lifetime and reliability problems, even if the absolute maximum ratings are not exceeded. **Table 13: Absolute maximum and minimum voltage ratings** | Parameter | Min | Max | Unit | | ----------------- | ---- | --- | ---- | | VBAT \_PWR | -0.3 | 3.6 | V | | VBAT\_PWR\_TX | -0.3 | 3.6 | V | | VBAT\_AON | -0.3 | 3.6 | V | | VDDIO | -0.3 | 3.6 | V | | RESET\_N/WAKE\_UP | -0.3 | 3.6 | V | | RF\_IN | -0.3 | 1.0 | V | ### 4.2 ESD Immunity **Table 14: ESD immunity specifications** | Parameter | Parameter | Parameter | Min | Max | Unit | | ----------------------------------------- | ----------------------------------------------------- | ------------------------ | ------ | ----- | ---- | | Electrostatic discharge (ESD) performance | Human body model (HBM), per ANSI / ESDA / JEDEC JS001 | RF Input | -1,000 | 1,000 | V | | Electrostatic discharge (ESD) performance | Human body model (HBM), per ANSI / ESDA / JEDEC JS001 | All pins except RF Input | -2,000 | 2,000 | V | | Electrostatic discharge (ESD) performance | Charged device model (CDM), per JESD22-C101 | All pins | -500 | 500 | V | ### 4.3 Recommended Operating Conditions **Table 15: Recommended operating conditions** | Parameter | Min | Typ | Max | Unit | | ------------------- | ---- | --- | --- | ---- | | Ambient temperature | -40 | - | 85 | °C | | Storage temperature | -40 | - | 125 | °C | | VBAT \_PWR | 3.0 | 3.3 | 3.6 | V | | VBAT\_PWR\_TX | 3.0 | 3.3 | 3.6 | V | | VBAT\_AON | 3.0 | 3.3 | 3.6 | V | | VDDIO | 2.25 | 3.3 | 3.6 | V | ### 4.4 Power Consumption #### 4.4.1 Active Transmit Current Consumption **Table 16: Transmit current consumption for VBAT, VBAT\_TX separated** | MCS Index | Current consumption (mA) per BW at V BAT 100% duty cycle, T A =25 o C, V BAT = V DDIO =3.3 V 1 MHz | Current consumption (mA) per BW at V BAT 100% duty cycle, T A =25 o C, V BAT = V DDIO =3.3 V 2 MHz | Current consumption (mA) per BW at V BAT 100% duty cycle, T A =25 o C, V BAT = V DDIO =3.3 V 4 MHz | Current consumption (mA) per BW at V BAT 100% duty cycle, T A =25 o C, V BAT = V DDIO =3.3 V 8 MHz | Current consumption (mA) per BW at V BAT\_TX 100% duty cycle, T A =25 o C, V BAT = V DDIO =3.3 V 1 MHz | Current consumption (mA) per BW at V BAT\_TX 100% duty cycle, T A =25 o C, V BAT = V DDIO =3.3 V 2 MHz | Current consumption (mA) per BW at V BAT\_TX 100% duty cycle, T A =25 o C, V BAT = V DDIO =3.3 V 4 MHz | Current consumption (mA) per BW at V BAT\_TX 100% duty cycle, T A =25 o C, V BAT = V DDIO =3.3 V 8 MHz | | --------- | -------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------ | | 10 | 51 | N/A | N/A | N/A | 281 | N/A | N/A | N/A | | 0 | 52 | 51 | 50 | 59 | 279 | 243 | 160 | 132 | | 1 | 52 | 51 | 50 | 59 | 278 | 243 | 159 | 131 | | 2 | 51 | 51 | 50 | 59 | 277 | 243 | 158 | 130 | | 3 | 51 | 51 | 50 | 59 | 266 | 242 | 158 | 130 | | 4 | 49 | 50 | 50 | 59 | 221 | 221 | 152 | 130 | | 5 | 44 | 47 | 48 | 58 | 144 | 174 | 128 | 125 | | 6 | 42 | 44 | 46 | 57 | 118 | 119 | 109 | 106 | | 7 | 36 | 39 | 44 | 54 | 88 | 96 | 98 | 95 | | 8 | 34 | 38 | 43 | 52 | 69 | 78 | 83 | 81 | | 9 | 32 | N/A | 40 | 49 | 54 | N/A | 63 | 58 | #### 4.4.2 Active Receive Current Consumption **Table 17: Active receive current consumption** | MCS Index | V BAT + V BAT\_TX + V DDIO Current consumption (mA) per BW 100% duty cycle, T A =25 o C, V BAT = V DDIO =3.3 V, R X signal at -70dBm 1 MHz | V BAT + V BAT\_TX + V DDIO Current consumption (mA) per BW 100% duty cycle, T A =25 o C, V BAT = V DDIO =3.3 V, R X signal at -70dBm 2 MHz | V BAT + V BAT\_TX + V DDIO Current consumption (mA) per BW 100% duty cycle, T A =25 o C, V BAT = V DDIO =3.3 V, R X signal at -70dBm 4 MHz | V BAT + V BAT\_TX + V DDIO Current consumption (mA) per BW 100% duty cycle, T A =25 o C, V BAT = V DDIO =3.3 V, R X signal at -70dBm 8 MHz | | --------- | ------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ | | 0 | 18 | 19 | 23 | 31 | | Max | 18 (MCS9) | 20 (MCS8) | 25 (MCS9) | 34 (MCS9) | #### 4.4.3 Listen Receive Current Consumption **Table 18: Listen receive current consumption** | V BAT + V BAT\_TX + V DDIO Current consumption (mA) per BW T A =25 o C, V BAT = V DDIO =3.3 V, Rx signal at -70dBm 1 MHz | V BAT + V BAT\_TX + V DDIO Current consumption (mA) per BW T A =25 o C, V BAT = V DDIO =3.3 V, Rx signal at -70dBm 2 MHz | V BAT + V BAT\_TX + V DDIO Current consumption (mA) per BW T A =25 o C, V BAT = V DDIO =3.3 V, Rx signal at -70dBm 4 MHz | V BAT + V BAT\_TX + V DDIO Current consumption (mA) per BW T A =25 o C, V BAT = V DDIO =3.3 V, Rx signal at -70dBm 8 MHz | | ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------ | | 17 | 18 | 21 | 29 | #### 4.4.4 Low Power Current Consumption **Table 19: Low power current consumption** | Power Mode | Current Consumption T A =25 o C, V BAT = V DDIO =3.3 V V BAT + V BAT\_TX | Current Consumption T A =25 o C, V BAT = V DDIO =3.3 V V DDIO | Current Consumption T A =25 o C, V BAT = V DDIO =3.3 V Unit | | ---------- | ------------------------------------------------------------------------ | ------------------------------------------------------------- | ----------------------------------------------------------- | | Hibernate | <1 | <1 | μA | | Deep Sleep | <2 | <1 | μA | | Snooze | <20 | <1 | μA | | USB snooze | <500 | <1 | μA | #### 4.4.5 Standby Current Consumption (using SDIO/SPI Host Interface) **Table 20: Standby current consumption** | Mode | Condition: T A =25 o C, V BAT = V DDIO =3.3 V | V BAT + V BAT\_TX | V DDIO | Unit | | ------ | --------------------------------------------- | ----------------- | ------ | ---- | | DTIM3 | 2 MHz channel, RTC=RTC\_XTAL, beacon=long | 176 | <1 | μA | | DTIM10 | 2 MHz channel, RTC=RTC\_XTAL, beacon=long | 68 | <1 | μA | | DTIM40 | 2 MHz channel, RTC=RTC\_XTAL, beacon=long | 33 | <1 | μA | | DTIM3 | 2 MHz channel, RTC=RTC\_XTAL, beacon=short | 126 | <1 | μA | | DTIM10 | 2 MHz channel, RTC=RTC\_XTAL, beacon=short | 52 | <1 | μA | | DTIM40 | 2 MHz channel, RTC=RTC\_XTAL, beacon=short | 29 | <1 | μA | The DTIM (Delivery Traffic Indication Message) number (DTIMx) indicates how often a Wi-Fi HaLow station in power-saving Snooze mode wakes to receive traffic from the access point. It is expressed as a multiple of beacon intervals (multiples of 102.4 ms). For example, DTIM1 indicates that the station will wake up every 102.4 ms, while DTIM40 configures the station to wake up every 4.1 seconds. Configuring DTIM is a complex compromise between power consumption and latency. Increasing the DTIM will reduce the average power consumption, as the station spends a greater proportion of time in Snooze mode, which consumes significantly less power than in Listen mode. However, since the station is unable to receive traffic in Snooze mode, increasing DTIM also increases latency. DTIM settings should be optimized appropriately according to the use case. ### 4.5 RF Specifications #### 4.5.1 Frequency Range The MM8108 radio operates in the frequency range from 850 MHz to 950 MHz. #### 4.5.2 Receiver **4.5.2.1 Sensitivity** Sensitivities for 10% packet error rate, 256-byte packets. Conditions are VBAT=3.3 V, 25oC **Table 21: Rate and receiver sensitivity** | MCS Index | Modulation Scheme | Coding Rate | PHY Rate (Mbps) per BW 1 MHz | PHY Rate (Mbps) per BW 2 MHz | PHY Rate (Mbps) per BW 4 MHz | PHY Rate (Mbps) per BW 8 MHz | Minimum Receive Sensitivity (dBm) per BW 1 MHz | Minimum Receive Sensitivity (dBm) per BW 2 MHz | Minimum Receive Sensitivity (dBm) per BW 4 MHz | Minimum Receive Sensitivity (dBm) per BW 8 MHz | | --------- | ----------------- | ----------- | ---------------------------- | ---------------------------- | ---------------------------- | ---------------------------- | ---------------------------------------------- | ---------------------------------------------- | ---------------------------------------------- | ---------------------------------------------- | | 10 | BPSK | 1/2 x 2 | 0.17 | N/A | N/A | N/A | -108 | N/A | N/A | N/A | | 0 | BPSK | 1/2 | 0.33 | 0.72 | 1.5 | 3.3 | -107 | -104 | -102 | -98 | | 1 | QPSK | 1/2 | 0.67 | 1.4 | 3.0 | 6.5 | -105 | -102 | -99 | -96 | | 2 | QPSK | 3/4 | 1.0 | 2.2 | 4.5 | 9.8 | -102 | -99 | -97 | -93 | | 3 | 16-QAM | 1/2 | 1.3 | 2.9 | 6.0 | 13 | -99 | -97 | -94 | -90 | | 4 | 16-QAM | 3/4 | 2.0 | 4.3 | 9.0 | 20 | -96 | -93 | -90 | -87 | | 5 | 64-QAM | 2/3 | 2.7 | 5.8 | 12 | 26 | -92 | -89 | -86 | -83 | | 6 | 64-QAM | 3/4 | 3.0 | 6.5 | 14 | 29 | -91 | -88 | -85 | -81 | | 7 | 64-QAM | 5/6 | 3.3 | 7.2 | 15 | 33 | -89 | -86 | -83 | -80 | | 8 | 256-QAM | 3/4 | 4.0 | 8.7 | 18 | 39 | -85 | -82 | -79 | -76 | | 9 | 256-QAM | 5/6 | 4.4 | N/A | 20 | 43 | -83 | N/A | -78 | -74 | **4.5.2.2 Adjacent Channel Rejection** Adjacent channel rejection is measured by setting the requested signal’s strength 3 dB above the rate-dependent sensitivity specified in 4.5.2.1 and increasing the power of the interfering signal until a 10% PER is achieved for a PSDU length of 256 bytes. The power difference between the interfering and requested channel is the corresponding adjacent channel rejection. **Table 22: Adjacent channel rejection** | MCS Index | Adjacent Channel Rejection (dB) per BW IEEE Spec | Adjacent Channel Rejection (dB) per BW 1 MHz | Adjacent Channel Rejection (dB) per BW 2 MHz | Adjacent Channel Rejection (dB) per BW 4 MHz | Adjacent Channel Rejection (dB) per BW 8 MHz | Non-Adjacent Channel Rejection (dB) per BW IEEE Spec | Non-Adjacent Channel Rejection (dB) per BW 1 MHz | Non-Adjacent Channel Rejection (dB) per BW 2 MHz | Non-Adjacent Channel Rejection (dB) per BW 4 MHz | Non-Adjacent Channel Rejection (dB) per BW 8 MHz | | --------- | ------------------------------------------------ | -------------------------------------------- | -------------------------------------------- | -------------------------------------------- | -------------------------------------------- | ---------------------------------------------------- | ------------------------------------------------ | ------------------------------------------------ | ------------------------------------------------ | ------------------------------------------------ | | 0 | 16 | 25 | 24 | 24 | 25 | 32 | 47 | 48 | 47 | 46 | | 2 | 11 | 17 | 17 | 17 | 18 | 27 | 39 | 41 | 40 | 40 | | 4 | 4 | 11 | 11 | 11 | 12 | 20 | 32 | 34 | 33 | 33 | | 7 | -2 | 1 | 1 | 11 | 2 | 14 | 23 | 24 | 24 | 23 | | 8 | -7 | 0 | -1 | -1 | -2 | 9 | 18 | 21 | 20 | 19 | | 9 | -9 | -1 | N/A | -1 | -1 | 7 | 17 | N/A | 18 | 17 | **4.5.2.3 Maximum Input Power** The following table specifies the maximum input level at RF\_IN for a specified MCS and PER. **Table 23: Maximum receiver input power** | Condition | Max | Unit | | --------------- | --- | ---- | | MCS=0 , PER <1% | 0 | dBm | #### 4.5.3 Transmitter The following transmit power levels are for IEEE compliance for 802.11ah. They do not consider any backoffs needed for regional spectrum compliance (e.g., FCC, IC, TELEC). TX power in edge channels will be limited by the restricted band edge in the regulatory regions. **Table 24: Mean TX output power** | MCS Index | Power output (dBm) at the filter per BW T A =25 o C, V BAT = V DDIO =3.3 V, IEEE-compliant with 1.5 dB SEM margin 1 MHz | Power output (dBm) at the filter per BW T A =25 o C, V BAT = V DDIO =3.3 V, IEEE-compliant with 1.5 dB SEM margin 2 MHz | Power output (dBm) at the filter per BW T A =25 o C, V BAT = V DDIO =3.3 V, IEEE-compliant with 1.5 dB SEM margin 4 MHz | Power output (dBm) at the filter per BW T A =25 o C, V BAT = V DDIO =3.3 V, IEEE-compliant with 1.5 dB SEM margin 8 MHz | | --------- | ----------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | 10 | 25.5 | N/A | N/A | N/A | | 0 | 25.5 | 25.0 | 23.0 | 22.5 | | 1 | 25.5 | 25.0 | 23.0 | 22.5 | | 2 | 25.5 | 25.0 | 23.0 | 22.0 | | 3 | 25.5 | 25.0 | 23.0 | 22.0 | | 4 | 24.5 | 24.5 | 22.5 | 22.0 | | 5 | 22.0 | 23.5 | 21.5 | 21.5 | | 6 | 22.5 | 21.5 | 21.0 | 20.5 | | 7 | 19.0 | 20.0 | 20.0 | 20.0 | | 8 | 17.5 | 18.0 | 19.0 | 19.0 | | 9 | 16.0 | N/A | 17.0 | 16.5 | ### 4.6 Digital IO Voltage Specifications **Table 25: Digital IO voltage specifications** | Parameters | Description | VDDIO | Min | Max | Unit | | ----------- | ---------------------------------------------------------------- | ----- | --- | ---- | ---- | | V IL\_VDDIO | Low input threshold for all GPIO and SDIO pins | 3.3 | - | 1.2 | V | | V IH\_VDDIO | High input threshold for all GPIO and SDIO pins | 3.3 | 1.7 | - | V | | V OL\_VDDIO | Low output voltage for all GPIO and SDIO pins, with an 8mA load | 3.3 | - | 0.25 | V | | V OH\_VDDIO | High output voltage for all GPIO and SDIO pins, with an 8mA load | 3.3 | 2.9 | - | V | ## 5 Application Circuit ### 5.1 Schematic Figure 12 shows a reference schematic for the MM8108. Each subcircuit is outlined in the sections below. ![Figure 9: Reference schematic diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/uTYtSzRfZozeP23kRmgU/Unknown%20image) Bypass capacitor values should match those used in the reference design to ensure optimal device operation. Quality X5R or better decoupling capacitors are recommended to ensure stability over temperature and the device's lifetime. The 2.2 uH and 1.5 uH buck inductors pass peak currents of 1 A, therefore, Isat and Itemp must be significantly greater than 1 A for these inductors. High-quality, low-DCR inductors are recommended for stability and reliability. The reference design uses the following buck inductors: * L1 (2.2 uH): Murata DFE201612P-2R2M=P2 * L3 (1.5 uH): Murata DFE201612P-2R2M=P2 Regulating VBAT and VBAT\_TX is essential for performance. For a 500 mA load, VBAT should have less than 10 mV of ripple and 50 mV of load regulation. ### 5.2 Routing information #### 5.2.1 Buck Converter Routing Spacing between the VSW (B9) pin and the inductor (L1) should be minimized, with the inductor and the capacitor of the LC filter placed close to one another. A low-impedance connection from the capacitor ground to the chip ground is required. VBUCK and VBUCK\_TX routing should be short and wide. VBUCK\_FB and VBUCK\_TX\_FB routing should connect nearby to the load pins (VBUCK (A5 & B4) and VBUCK\_TX (G3, H2 & J2) pins, respectively) and do not require wide routing, as these are high-impedance and for voltage sensing feedback only. #### 5.2.2 VBAT Routing VBAT capacitors should be placed as close to the pins as possible with short and wide traces, not routing through vias between the capacitor and the VBAT\_PWR (A8) pin. VBAT routing on the board should have low impedance, and more extended traces should be accounted for with increased capacitance at the pin to avoid VBAT sagging during load events. The capacitance illustrated in the application circuit is the minimal requirement for a well-regulated VBAT supply. If an onboard LDO supplies VBAT, the feedback point should be at the VBAT\_PWR\_TX (J8) load pin or capacitor. If a battery is used to supply VBAT directly, wide traces should be used to provide the best low-impedance path from the battery terminal to VBAT\_PWR\_TX (J8). #### 5.2.3 SPI/SDIO/JTAG Routing Care should be taken to avoid coupling to the RF and buck sections. Impedance matching is unnecessary, but consistent trace widths and spacing are recommended to avoid signal integrity issues, with characteristic impedance not less than 50 Ω to avoid excess capacitive loading. #### 5.2.4 RF Routing Impedance control to 50 Ω is required. Reference designs for TX filter and RX matching can be provided by Morse Micro on request, and complete reference designs with a TR switch can be included. Care should be taken to isolate the RF section from all other parts of the circuit with low-impedance grounding and good spacing. For this purpose, a coplanar waveguide with ground is used in reference designs. It is recommended to minimize impedance discontinuity by routing using components with pad sizes equal to or smaller than the 50 Ω trace. For the same reason, the inter-pad distance should be larger than the 50 Ω trace clearance to the coplanar ground. ![Figure 10: Trace diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/QJ1xtczzxjn2CrikSCqq/Unknown%20image) Component placement should target the shortest overall trace length to minimize losses. ### 5.3 RF Section #### 5.3.1 Transmitter The output is purposefully mismatched away from 50 Ω to optimize power consumption and output power. To meet worldwide regulatory requirements, an external harmonic filter, as shown below, must be included in the design. This filter must be copied precisely, as modification negatively affects efficiency and output power. ![Figure 11: Transmission filter diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/mdf635fEJTzIQcsJRE2n/Unknown%20image) The layout recommendations from Figure 13 apply. The reference design uses the following components: * L6 (4.7 nH): Murata LQP03HQ4N7H02D * C16 (4.3 pF): Murata GRM0335C1H4R3WA01D * L2 (10 nH): Murata LQP03HQ10NH02D * C15 (1.8 pF): Murata GRM0335C1H1R8WA01D #### 5.3.2 Transmit/Receive RF Switch The reference design uses 50 Ω TR switches with low insertion loss and high isolation. Note the requirement for DC-blocking capacitors on the TR switch's RF ports. #### 5.3.3 Receiver Matching The receiver is matched to ensure an optimal balance between noise tolerance and signal sensitivity over the usable bandwidth. The reference circuit will result in optimal performance. ![Figure 12: Receiver matching diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/mVNPigTEXvm4u8r91yo5/Unknown%20image) The reference design uses the following components: * L7 (20 nH): Murata LQP03HQ20NH02D * C17 (2.4 pF): Johanson 250R05L2R4BV4T #### 5.3.4 Antenna/Interstage Matching Interstage matching may be required to minimize losses depending on the antenna, TR switch, and external active components used. Standard techniques are recommended to match each port to an intermediate impedance of 50 Ω. Matching to an intermediate of 50 Ω results in a more robust design since each component can be individually matched to 50 Ω without considering inter-device effects. ## 6 Package Information ### 6.1 Package Dimensions ![Figure 13: Package dimensions](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/i0qMI47enZYdvxVVcwOQ/Unknown%20image) ### 6.2 IC Markings ![Figure 14: IC markings diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/wVuzaoYQrn7sVf3OPxKU/Unknown%20image) **Table 26: IC markings overview** | Line | Marking | Example | Description | | ---- | --------- | --------- | -------------------------------------------------------------------------------------------------- | | 1 | MMXXXXDS | MM8108IB | Device number (XXXX); Optional : Custom marketing letter; Temperature grade (D); Package type (S); | | 2 | TA22 YYWW | TA22 2401 | Fab/Assembly codes; 2 digits for Silicon revision (Major, Minor - Internal Only); date code YYWW; | | 3 | XXXXXXX | 341N001 | Assembly lot number | **Table 27: IC markings details** | Marking | Purpose | Example | Description | | ------- | ---------------------- | ------- | ------------------------------------------ | | M | Major silicon revision | 0..9 | Designated by a single number from 0 to 9 | | N | Minor silicon revision | 0..9 | Designated by a single number from 0 to 9 | | D | Temperature grade | I/C | I = -40 o C to 85 o C; C = 0 o C to 70 o C | | S | Package Type code | Q/B | Q: QFN; B: FCBGA/BGA | ### 6.3 Package Thermal Properties **Table 28: Package thermal properties overview** | Ball count | Size | Power (W) | T A ( o C) | Θ JA ( o C/W) | Θ JC ( o C/W) | Θ JB ( o C/W) | Ѱ JB ( o C/W) | Ѱ JT ( o C/W) | | ---------- | --------- | --------- | ---------- | ------------- | ------------- | ------------- | ------------- | ------------- | | 79 | FCCSP 5x5 | 0.5 | 25 | 31.794 | 6.882 | 7.18 | 1.092 | 1.368 | | 79 | FCCSP 5x5 | 0.5 | 55 | 27.084 | 6.882 | 7.17 | 1.164 | 1.366 | TA: Ambient temperature ΘJA: Thermal resistance junction-to-ambient ΘJC: Thermal resistance junction-to-case ΘJB: Thermal resistance junction-to-board ѰJB: Thermal characterization parameter junction-to-board ѰJT: Thermal characterization parameter junction-to-top (of package) Notes: * JESD51 test standards used * PCB is JEDEC 2S2P test board * Board level solder is SAC405 (thickness = 50 um) * The maximum junction temperature must be controlled to <= 125 °C ## 7 PCB Land Pattern ![Figure 15: PCB land pattern](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/S0srII1QZcLgAm8XZewb/Unknown%20image) **Table 29: PCB land pattern dimensions** | Key | Dimension (mm) | | --- | -------------- | | A | 0.5 | | B | 0.5 | | C | 0.3 | | D | 4.0 | | E | 4.0 | ## 8 Solder Stencil Pattern ![Figure 16: Solder stencil pattern](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/EYTO4EDcRPS55TM06VMq/Unknown%20image) **Table 30: Solder stencil pattern dimensions** | Key | Dimension (mm) | | --- | -------------- | | A | 0.5 | | B | 0.5 | | C | 0.275 | | D | 4.0 | | E | 4.0 | ## 9 Recommended Soldering Profile ![Figure 17: Soldering profile](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/1Hq7oWjuKR6yc9SQLTNU/Unknown%20image) **Table 31: Soldering profile details** | Soldering profile feature | Specification | | -------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | | Classification temperature (T C ) | 260 °C | | Min soak temperature ( T smin ) | 150 °C | | Max soak temperature (T smax ) | 200 °C | | Time (t s ) from (T smin to T smax ) | 60-120 seconds | | Liquidus temperature (T L ) | 217 °C | | Maximum ramp-up rate (T L to T P ) | 3 °C per second | | Time (t L ) maintained above T L | 60-150 seconds | | Peak package body temperature (T P ) | For users, T P must not exceed the T C For suppliers, T P must equal or exceed T C | | Time (t P ) within 5 °C of the specified classification temperature (T C ) | For users, a maximum of 30 seconds For suppliers, a minimum of 30 seconds | | Maximum ramp-down rate (T P to T L ) | 6 °C per second | | Maximum time 25 °C to peak temperature (T P ) | 8 minutes | Tolerance for peak profile temperature (TP) is defined as a supplier minimum and a user maximum. In other words, if TC is 260 °C and time tP is 30 seconds, this means the following for the supplier and the user: * For a supplier, the peak temperature must be at least 260 °C, and the time above 255 °C must be at least 30 seconds. * For a user, the peak temperature must not exceed 260 °C, and the time above 255 °C must not exceed 30 seconds. All temperatures refer to the center of the package, measured on the package body surface facing up during assembly reflow (live-bug). If parts are reflowed in a different orientation than the normal live-bug assembly reflow orientation (dead-bug), the TP must be within +/- 2 °C of the live-bug TP and still meet the TC requirements; otherwise, the profile shall be adjusted to achieve the latter. To accurately measure peak package body temperatures, refer to JEP140 for recommended thermocouple use. Reflow profiles in this document are for classification/preconditioning and are not meant to specify board assembly profiles. Actual board assembly profiles should be developed based on specific process needs and board designs and within the parameters above. ## 10 Packaging and Labeling ### 10.1 Tray Specifications **Table 32: Tray specifications** | Term | Definition | | --------------- | ------------------------ | | Product | MM8108 | | Number of units | 490 | | Tray size | 322.6 mm x 135.9 mm | | Vacuum seal | Yes | | Dry bake | 125 o C / 24 hours (ML3) | | Pin 1 indicator | Marked on the chip | ![Figure 18: Tray specifications](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/qbMmCRYCvhlDRAuur3k5/Unknown%20image) ## 11 Handling and Storage The MM8108 IC is a moisture-sensitive device rated at Moisture Sensitive Level 3 (MSL3) per IPC/JEDEC J-STD-20. After opening the moisture-sealed storage bag, ICs that will be subjected to reflow solder or other high-temperature processes must be: 1. Mounted to a circuit board within 168 hours at factory conditions (≤ 30 °C and < 60 % RH) OR 2. Continuously stored per IPC/JEDEC J-STD-033 ICs exposed to moisture and environmental conditions exceeding packaging and storage conditions must be baked before mounting according to IPC/JEDEC J-STD-033. Failure to meet packaging and storage conditions will result in irreparable damage to chips during solder reflow. ## 12 Part Number and Ordering Information **Table 33: Part number and ordering information** | Part Number | Packing Type | M OQ and Order Multiples | Package | Description | Operating Ambient Temperature | | ----------- | ------------ | ------------------------ | --------------- | ----------------------------------------------------------------------------------------------------------------------- | ----------------------------- | | MM8108IB-T | Tray | 490 | BGA 5 mm x 5 mm | Multi-region Wi-Fi HaLow / IEEE 802.11ah Sub-1 GHz SoC with USB Interface and Integrated Power and Low Noise Amplifiers | -40 °C to 85 °C | | MM8108IB-TR | Tape & Reel | 3000 | BGA 5 mm x 5 mm | Multi-region Wi-Fi HaLow / IEEE 802.11ah Sub-1 GHz SoC with USB Interface and Integrated Power and Low Noise Amplifiers | -40 °C to 85 °C | ## 13 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Version 4 | 18 Sep 2025 | Updated formatting Update pin descriptions Updated power management Updated timing graphs Updated electrical specifications Updated RF specifications Added digital IO specifications Added PCB land solder stencil patterns | | DS102 | 8 Jan 2025 | General update | | DS101 | 4 Nov 2024 | Add packaging and handling information Add soldering information Add labeling information | | DS100 | 1 Nov 2024 | Initial release | Morse Micro provides this information "as is" without warranties of any kind, express or implied. No guarantee is made as to the accuracy, completeness, or suitability of this information or Morse Micro’s products for any specific purpose. Use of this information and products is at the user’s sole risk. Morse Micro products are not designed or tested for use in mission-critical systems, and should not be used in such applications. Performance specifications are based on internal testing and are believed to be reliable; however, they are not guaranteed. It is the Buyer’s responsibility to test and validate all product performance, compatibility, and compliance, both in isolation and within end applications. Morse Micro assumes no liability for the use or application of any product, circuit, or information described herein. No license or other rights—express or implied—are granted under Morse Micro’s intellectual property. This document contains proprietary information of Morse Micro and is subject to change without notice. Wi-Fi®, Wi-Fi HaLow™, and the Wi-Fi logo are trademarks of Wi-Fi Alliance. ZigBee™ and Z-Wave™ are trademarks of their respective owners. All other trademarks are the property of their respective owners. # MM6108 Datasheet DS104 [Download as PDF](https://www.morsemicro.com/resources/datasheets/chips/MM6108_Data_Sheet.pdf) ## 1 Product Overview ### 1.1 Introduction Wi-Fi HaLow (pronounced HEYlow) is the first global Wi-Fi standard (IEEE 802.11ah) tailored to meet the Internet of Things (IoT) needs. It’s an open standard wireless network technology operating in the sub-1 GHz license-exempt RF bands (850-950 MHz range), so it doesn’t incur ongoing monthly costs like cellular/mobile network connections. By operating in the sub-GHz range, this ultra-low-power wireless protocol can connect more IoT devices at much longer distances and with much lower power than traditional Wi-Fi. Morse Micro, the world’s leading Wi-Fi HaLow (802.11ah) solutions provider, offers several Wi-Fi HaLow connectivity solutions. The MM6108 SoC is a single-chip solution that includes Radio, PHY, and MAC functions compliant with the IEEE 802.11ah standard and supports data rates up to 32.5 Mbps. The radio in the MM6108 supports programmable operation between 850 MHz and 950 MHz. The MM6108 has been designed for a simplified Wi-Fi HaLow connection to an external host. The RF interface for the MM6108 includes the option to use either the on-chip amplification for typical low-power, low-cost devices or in conjunction with an external PCB mounted power amplifier for ultra-long-reach applications. The RF receiver features a high linearity LNA, making external filters unnecessary in many applications. MM6108 supports security features required for Wi-Fi HaLow product certifications. A combination of features in the MM6108 supports battery-operated applications. The IEEE 802.11ah standard provides extended sleep times of battery-operated Stations (STAs or client devices), with longer durations than other prior IEEE 802.11a/b/g/n/ac generations. It also allows longer extended maximum idle times for clients to conserve energy without being removed from the Access Point’s list of authenticated devices. *** ### 1.2 Features * Single-stream max data rate of 32.5 Mbps (MCS=7, 64-QAM, 8 MHz channel, 4μs GI) * Radio supporting worldwide Sub-1 GHz frequency bands * Frequency range: 850-950 MHz * Channel bandwidth options of 1/2/4/8 MHz * Max output power: 8 dBm * 802.11ah OFDM PHY * BPSK & QPSK, 16-QAM & 64-QAM Modulation * Automatic frequency & gain control * Packet detect & channel equalization * Forward Error Correction (FEC) coding & decoding * Supports Modulation and Coding Scheme (MCS) levels MCS 0-7 and MCS 10 * Supports 1 MHz duplicate mode * Supports optional Traveling Pilots and Short Guard Intervals * 802.11ah MAC supporting WFA HaLow certification * Support for STA and AP roles * Listen-Before-Talk (LBT) access with energy detect * 802.11 power save * 802.11 fragmentation and defragmentation * Packet aggregation * Power-Saving Target Wake Time (TWT) support for long battery life * Restricted Access Window (RAW) * Automatic and manual MCS rate selection * SDIO 2.0 compliant slave interface * SDIO 2.0 Default Speed (DS) at 25 MHz * SDIO 2.0 High Speed (HS) at 50 MHz * Support for both 1-bit and 4-bit data mode * Support for SPI mode operation * Power Management Unit (PMU) for various modes of operation * Power-down (interrupt-driven wake) * Hibernate mode (internal/external wake) * Active Receive / Transmit mode * Integrated DC-DC converter supporting a voltage supply from 3.0V to 3.6V * RF Interface * On-chip 8dBm output power, with option to use external PA or FEM * Option to use an external LNA or FEM * Wide spectrum of security features * AES encryption engine * Hardware support for SHA1 and SHA2 hash functions (SHA-256, SHA-384, SHA-512) * WPA3, including protected management frames (PMF) * Opportunistic Wireless Encryption (OWE) *** ### 1.3 Applications For Internet of Things (IoT) and Machine-to-Machine (M2M) applications such as: * Surveillance Cameras and Sensors * Cloud Connectivity * Low-power Sensor Networks * Building Automation Systems (BAS) * Asset Tracking and Management * Machine Performance Monitors & Sensors * Building Access Control & Security * Drone Video and Navigation Communications * Connected Toys and Games * Rural Internet Access * Agricultural and Farm Networks * Utility Smart Meter and Intelligent Grid * Proximity Sensors * Industrial Automation Controls * Smart Home Automation * EV Car Chargers * Appliances * Construction Site Connectivity * Smart Signs and Kiosks * Retail Point-of-Sale Terminals * Vehicle-to-Vehicle or Vehicle-to-Infrastructure Communications * IP Sensor Networks * Biometric IDs and Keypads * Warehouse Connectivity * Intelligent Lighting Controls * BT/ZigBee(™)/Z-Wave(™) to Wi-Fi HaLow Gateways * Wi-Fi to Wi-Fi HaLow Bridges * Wi-Fi HaLow Client Adapters/Dongles * Smart City Networks *** ## 2 Pin Descriptions The MM6108 device has 48 pins, which are described in this section. The following illustration shows the top view of the MM6108 pin Diagram. ![Figure 1: Pin diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/rhDITRFDNftliH65mTrR/Unknown%20image) *Figure 1: Pin diagram* *** **Table 1: Pin description** | Pin | Pin Name | Type | Description | | --- | ------------------- | ----------- | ------------------------------------------------------------------------------- | | 1 | GND | Ground | Ground | | 2 | GND | Ground | Ground | | 3 | GPAIO | Analog | Analog test pin | | 4 | GND | Ground | Ground | | 5 | RFIN | RF | RF input | | 6 | GND | Ground | Ground | | 7 | RFOUT | RF | RF output | | 8 | CAPR | Power | Bypass capacitor connection for RF supply | | 9 | WAKE \[4] | Input | WAKE from sleep input | | 10 | RESET\_N \[4] | Input | Asynchronous chip reset (active low) | | 11 | VBAT\_PWR | Power | IC Power Supply | | 12 | IND | Analog | Inductor connection for integrated power management | | 13 | VBUCK\_FB | Power | Connection for integrated power management | | 14 | VBUCK | Power | Connection for integrated power management | | 15 | VBAT\_AON | Power | IC Power Supply ( VBAT\_AON and VBAT\_PWR must be connected to the same source) | | 16 | CAPD | Power | Bypass capacitor connection for digital supply | | 17 | BUSY \[5] | Digital I/O | Wi-Fi Busy | | 18 | GPIO1 \[5] | Digital I/O | GPIO | | 19 | GPIO2 \[5] | Digital I/O | GPIO | | 20 | GPIO3 \[5] | Digital I/O | GPIO | | 21 | GPIO4 \[5] | Digital I/O | GPIO | | 22 | GPIO5 \[5] | Digital I/O | GPIO | | 23 | GPIO6 \[5] | Digital I/O | GPIO | | 24 | VDDIO | Power | VDD supply for digital IO | | 25 | SDIO\_D3 \[3]\[5] | Digital I/O | SDIO Data 3 | | 26 | SDIO\_D2 \[3]\[5] | Digital I/O | SDIO Data 2 | | 27 | SDIO\_D1 \[3]\[5] | Digital I/O | SDIO Data 1 | | 28 | EXT\_HOST\_SEL \[5] | Digital I/O | External Host Select | | 29 | SDIO\_D0 \[3]\[5] | Digital I/O | SDIO Data 0 | | 30 | SDIO\_CMD \[3]\[5] | Digital I/O | SDIO Command | | 31 | SDIO\_CLK \[5] | Digital I/O | SDIO Clock | | 32 | GPIO7 \[2]\[5] | Digital I/O | GPIO | | 33 | GPIO8 \[2] \[5] | Digital I/O | GPIO | | 34 | GPIO9 \[2] \[5] | Digital I/O | GPIO | | 35 | GPIO10 \[2] \[5] | Digital I/O | GPIO | | 36 | GPIO11 \[2]\[5] | Digital I/O | GPIO/ RF FEM CTRL | | 37 | GPIO12 \[2]\[5] | Digital I/O | GPIO/ RF FEM CTRL | | 38 | GPIO13 \[2]\[5] | Digital I/O | GPIO/ RF FEM CTRL | | 39 | GPIO14 \[2]\[5] | Digital I/O | GPIO/ RF FEM CTRL | | 40 | GPIO15 \[2]\[5] | Digital I/O | GPIO/ RF FEM CTRL | | 41 | JTAG\_TDO \[1] | Digital I/O | JTAG Data Out | | 42 | JTAG\_TMS \[1] | Digital I/O | JTAG Mode Select | | 43 | JTAG\_TDI \[1] | Digital I/O | JTAG Data In | | 44 | JTAG\_TRST \[1] | Digital I/O | JTAG Reset | | 45 | JTAG\_TCK \[1] | Digital I/O | JTAG Clock | | 46 | XON | Analog | 32 MHz crystal component connection | | 47 | XOP | Analog | 32 MHz crystal component connection | | 48 | XTAL\_BIAS | Analog | Crystal Bias | | - | GND | Ground | Exposed ground pad - must connect to PCB ground | \[1] JTAG pins should be tied to GND via a 10k pull down resistor \[2] All unused GPIO should be tied to GND via a 10k pull down resistor \[3] All SDIO bus pins should be pulled up with a 10k-100k resistor as per the SDIO standard \[4] Supplied from VBAT domain. The VDDIO domain drives other pins. \[5] See Section 4.1 for the GPIO Alternate functions *** ## 3 Functional Description The following sections describe the functions of the MM6108 SoC. ### 3.1 Functional Block Diagram ![Figure 2: Functional Block Diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/U46rdjnA1vNURe09Q0PM/Unknown%20image) *Figure 2: Functional Block Diagram* *** ### 3.2 Clocks The MM6108 uses a 32 MHz crystal component to derive all the clocks used in the system. A Pierce oscillator circuit is used as shown below: ![Figure 3: Crystal circuit](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/OiD4D7DJkAYb8A9adpuz/Unknown%20image) *Figure 3: Crystal circuit* The crystal should be connected between pins XOP & XON. Load capacitors C1 and C2 should be high-accuracy NP0 dielectric. The total capacitance on XOP and XON nodes should be twice that of the load capacitance specified by the crystal component (CL): C1 = C2 = 2 x CL To adhere to 802.11ah standards for frequency offset and achieve specified sensitivity, the crystal component should conform to the following specifications: **Table 2: RF crystal specification** | Parameter | Min | Max | Units | | ------------------- | --- | --- | ----- | | Frequency tolerance | -20 | +20 | ppm | | ESR | 10 | 50 | ohm | *** ### 3.3 Power Management All power is derived from a 3.0V to 3.6V supply on pin VBAT\_PWR and VBAT\_AON. To avoid damage to the device, ensure that VDDIO does not exceed VBAT. An internal buck converter requires a 10uH inductor between pins IND and VBUCK\_FB and ceramic decoupling capacitors as shown below. There are three internal power supplies: RF, Analog, and Digital. Internal circuits regulate these and require ceramic decoupling capacitors on the PCB at CAPR, CAPD, and VBAT\_AON as shown below. For regular boot operation, ensure that the JTAG\_TRST pin is held in reset by pulling it to ground with a 10kOhm resistor. ![Figure 4: Reference schematic diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/la46Sn2v40bBEE5Z4oVP/Unknown%20image) *Figure 4: Reference schematic diagram* *** ## 4 Digital Interfaces ### 4.1 SDIO Device A host interface is available via SDIO 2.0, operating at 3.3V at either default or high speed. To expose the SDIO interface pins, pin 28 EXT\_HOST\_SEL must be pulled up to VDDIO, indicating the presence of an external host. #### 4.1.1 Pins **Table 3: SDIO pin description** | Pin | Name | SDIO 4-bit mode | SDIO 1-bit mode | | --- | -------------- | ------------------------------------------------ | ------------------------------------------------ | | 25 | D3 | Data pin 3 | Unused | | 26 | D2 | Data pin 2 | Unused | | 27 | D1 | Data pin 1 | IRQ | | 28 | EXT\_HOST\_SEL | SDIO/SPI/ QSPI interface enable strap (tie high) | SDIO/SPI/ QSPI interface enable strap (tie high) | | 29 | D0 | Data pin 0 | Data pin 0 | | 30 | CMD | Command pin | Command pin | | 31 | CLK | Clock pin (input) | Clock pin (input) | Note: All SDIO lines should be pulled up to VDDIO with 10 kΩ to 100 kΩ resistors as per the SDIO 2.0 Specification. SDIO\_CLK and unused pins should also be pulled up to achieve ideal sleep/snooze currents if not driven by a host processor. #### 4.1.2 Functions Internally, the SDIO will present two functions (in addition to the mandatory function 0) to access the chip. Functions 1 and 2 only differ in the maximum transfer size they support. Function 1 can perform transactions up to 8 bytes at a time, while function 2 supports up to 512 bytes at a time, making it better suited to bulk data transfers. *** #### 4.1.3 Bus Timing The SDIO interface supports a clock rate up to 50 MHz. ![Figure 5: SDIO bus device input timing diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/6oFOlI93tz4ZJzIRhP2U/Unknown%20image) *Figure 5: SDIO bus device input timing diagram* ![Figure 6: SDIO bus device output timing diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/SULlHLRUfYGncl64jDcq/Unknown%20image) *Figure 6: SDIO bus device output timing diagram* *** **Table 4: SDIO Bus Timing** | Parameter | Min | Max | Units | | -------------------------------------- | --- | --- | ----- | | Clock frequency | 0 | 50 | MHz | | Clock low time (t WL ) | 7 | | ns | | Clock high time(t WH ) | 7 | | ns | | Clock rise time (t LH ) | | 3 | ns | | Clock fall time (t HL ) | | 3 | ns | | Input setup time (t ISU ) | 6 | | ns | | Input hold time (t IH ) | 2 | | ns | | Output delay (t ODLY(max) ) | | 14 | ns | | Output hold time (t ODLY(min) ) | 2.5 | | ns | | Total system capacitance for each line | | 40 | pF | *** ### 4.2 SPI Device The SPI interface uses the physical unidirectional pin layout defined below, and it communicates using the modified SDIO protocol. #### 4.2.1 Pins **Table 5: SPI pin description** | Pin | Name | SPI mode function | | --- | -------------- | ---------------------------------------------------- | | 25 | CS | Chip select (active low) | | 26 | NC | Not connected/unused (tie to VDDIO) | | 27 | INT | Interrupt pin | | 28 | EXT\_HOST\_SEL | S DIO/SPI/QSPI interface enable strap (tie to VDDIO) | | 29 | MISO | Master data in/slave data out | | 30 | MOSI | Master data out/slave data in | | 31 | CLK | Clock pin (input) | #### 4.2.2 Initialization in SPI mode After powering on, the host interface can be either SDIO or SPI. To switch to SPI mode, the host must send a CMD0 while holding CS low (asserted). For further details on the protocol, see SD Specification Part E1, “SDIO Simplified Specification,” version 2.00. #### 4.2.3 SPI Bus Timing The SPI clock rate supports up to 50 MHz. The SPI bus timing is identical to the SDIO bus timing, where MOSI and MISO are input and output timing in the SDIO timing specification. The SPI bus defaults to clock idling at logical 0 (CPOL=0), and data is launched and captured on the positive edges of the clock, as per the SDIO high-speed mode. After being initialized, it may be configured to behave like CPHA=0 (drive output on the negative edge, sample on the positive edge). ### 4.3 GPIO There are 16 GPIO pins. These will be high-impedance at reset and during power save modes. These pins should be pulled up/down or driven to ensure the lowest sleep currents. *** ### 4.4 Sleep/Wake Sequencing #### 4.4.1 Host wakes MM6108 from sleep ![Figure 7: Host-initiated wake sequence diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/lsSm35Vs3VKKNbm1w0y6/Unknown%20image) *Figure 7: Host-initiated wake sequence diagram* 1. The driver raises the wake pin and waits for a static period of 10 ms before initializing the shared communication bus and initiating host interface activity. On MM6108, this period is typically 10 ms. 2. After completing communication, the driver will wait a static period, b, before lowering the wake pin (assuming no further communication has occurred). Depending on the nature of the communication (802.11 data vs. commands), this period can range from 5 to 90ms. 3. After the wake pin has fallen, the MM6108 will wait for a period, c, before initiating hardware sleep. This dynamic period will differ depending on the power-saving protocol and other chip-specific factors. *** #### 4.4.2 MM6108 wakes host from sleep (with host interface disabled) ![Figure 8: Module-initiated wake sequence with host interface disabled diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/xCFPknQVynX4F4FzsYFJ/Unknown%20image) *Figure 8: Module-initiated wake sequence with host interface disabled diagram* 1. The MM6108 wakes from sleep and realizes it needs to pass traffic or an event to the host. It begins by asserting the busy pin. 2. The busy pin will fire an interrupt on the host, after which the host will immediately: 3. Raise the Wake PIN. 4. Wait a static period, 10ms 5. Initializes / enables the shared host interface. 6. After asserting the busy pin, the MM6108 will initiate host interface communication immediately. It does not wait until the host ‘enables’ the shared host interface. This is okay, as the bus transaction will be waiting for the host, and an interrupt should fire as soon as the host enables bus interrupts. 7. The busy pin will drop immediately once the MM6108 no longer needs to converse with the host. The host will wait a static period, b, before dropping the wake pin. 8. After the wake pin has fallen, the MM6108 will wait for a period, c, before initiating hardware sleep. *** #### 4.4.3 MM6108 initiates communication with the host (host interface enabled) ![Figure 9: Module-initiated wake sequence with host interface enabled diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/ei33E9kKf5gQ9lbd7TX7/Unknown%20image) *Figure 9: Module-initiated wake sequence with host interface enabled diagram* 1. The MM6108 was previously woken by the host for communication. 2. Sometime after wake and host->MM6108 communication, the MM6108 realizes it needs to send data back to the host (MM6108->host). It will assert the busy pin. 3. The busy pin will fire an interrupt on the host, after which it will immediately: 4. Process the interrupt but take no further action, as the wake pin has already been asserted and the shared host interface is currently enabled/initialized. 5. After MM6108->host communication completion, hardware sleep will be initiated as described above. *** ## 5 Electrical Characteristics ### 5.1 Absolute Max ratings Stress beyond the absolute maximum ratings may cause permanent damage to the device. Functional operation is guaranteed for recommended operating conditions only. Operating the device outside of recommended conditions may result in reduced lifetime and/or reliability problems, even if the absolute maximum ratings are not exceeded. **Table 6: Absolute max ratings** | Parameter | Min | Max | Unit | | -------------------------- | ---- | ---- | ---- | | VBAT voltage | -0.3 | 4.3 | V | | Voltage on digital I/O pin | -0.3 | 4.3 | V | | Voltage on analog/RF pin | -0.3 | 1.32 | V | | Storage Temperature | -40 | 125 | °C | | RF Input Power (CW) | - | 6 | dBm | ### 5.2 Immunity **Table 7: Immunity** | Parameter | Parameter | Parameter | Min | Max | Unit | | ----------------------------------------- | ----------------------------------------------------- | ------------------------ | ----- | ---- | ---- | | Electrostatic discharge (ESD) performance | Human body model (HBM), per ANSI / ESDA / JEDEC JS001 | RF Input | -500 | 500 | V | | Electrostatic discharge (ESD) performance | Human body model (HBM), per ANSI / ESDA / JEDEC JS001 | All pins except RF Input | -2000 | 2000 | V | | Electrostatic discharge (ESD) performance | Charged device model (CDM), per JESD22-C101 | All pins | -500 | 500 | V | ### 5.3 Recommended Operating Conditions **Table 8: Recommended operating conditions** | Parameter | Min | Typ | Max | Unit | | ------------------------------ | ---- | --- | ----- | ---- | | Ambient Temperature (MM6108IQ) | -40 | 25 | 85 | °C | | V BAT / V BAT\_AON \[2] | 3.0 | 3.3 | 3.6 | V | | VDDIO \[1] | 1.62 | 3.3 | 3.6 | V | | Digital I/O voltage | 0 | 3.3 | VDDIO | V | \[1]VDDIO should not exceed VBAT \[2]VBAT\_AON should be greater than or equal to VBAT during power-up. Performance specifications are achieved under typical operating conditions unless otherwise specified. *** ### 5.4 Power Consumption #### 5.4.1 Transmit power consumption **Table 9: Transmit power consumption** | Mode | Condition: T A =25 o C, V BAT /V DDIO = 3.3V | V BAT Current Min | V BAT Current Typ | V BAT Current Max | Unit | | ----------------------------------------- | -------------------------------------------- | ----------------- | ----------------- | ----------------- | ---- | | Transmit current (MCS7, 3 dBm, 100% D.C.) | 1 MHz channel | 33 | 43 | 53 | mA | | Transmit current (MCS7, 3 dBm, 100% D.C.) | 2 MHz channel | 39 | 45 | 52 | mA | | Transmit current (MCS7, 3 dBm, 100% D.C.) | 4 MHz channel | 46 | 52 | 60 | mA | | Transmit current (MCS7, 3 dBm, 100% D.C.) | 8 MHz channel | 56 | 63 | 76 | mA | | Transmit current (MCS0, 6 dBm, 100% D.C.) | 1 MHz channel | 43 | 58 | 76 | mA | | Transmit current (MCS0, 6 dBm, 100% D.C.) | 2 MHz channel | 37 | 47 | 60 | mA | | Transmit current (MCS0, 6 dBm, 100% D.C.) | 4 MHz channel | 45 | 54 | 62 | mA | | Transmit current (MCS0, 6 dBm, 100% D.C.) | 8 MHz channel | 57 | 67 | 77 | mA | #### 5.4.2 Receive power consumption **Table 10: Receive power consumption** | Mode | Condition: T A =25 o C, V BAT /V DDIO = 3.3 V | V BAT Current Min | V BAT Current Typ | V BAT Current Max | Unit | | ------------------- | --------------------------------------------- | ----------------- | ----------------- | ----------------- | ---- | | Listen | 1 MHz channel | 22 | 26 | 31 | mA | | Listen | 2 MHz channel | 24 | 28 | 33 | mA | | Listen | 4 MHz channel | 27 | 32 | 38 | mA | | Listen | 8 MHz channel | 32 | 37 | 43 | mA | | Active receive MCS7 | 1 MHz channel | 24 | 26 | 35 | mA | | Active receive MCS7 | 2 MHz channel | 28 | 30 | 39 | mA | | Active receive MCS7 | 4 MHz channel | 34 | 40 | 46 | mA | | Active receive MCS7 | 8 MHz channel | 45 | 53 | 61 | mA | | Active receive MCS0 | 1 MHz channel | 20 | 26 | 35 | mA | | Active receive MCS0 | 2 MHz channel | 26 | 28 | 36 | mA | | Active receive MCS0 | 4 MHz channel | 30 | 36 | 46 | mA | | Active receive MCS0 | 8 MHz channel | 45 | 48 | 59 | mA | #### 5.4.3 Sleep power consumption **Table 11: Sleep power consumption** | Mode | Condition: T A =25 o C, V BAT /V DDIO = 3.3 V | V BAT Min | V BAT Typ | V BAT Max | Unit | | ---------- | ------------------------------------------------------------- | --------- | --------- | --------- | ---- | | Snooze | RC Oscillator on, Memory retained, configurable wake up timer | 9.5 | 42 | 370 | uA | | Deep sleep | RC Oscillator on, configurable wake up timer | 0.8 | 1 | 1.8 | uA | | Hibernate | Power off, wait for external interrupt | 0.03 | 0.05 | 1 | uA | *** #### 5.4.4 DTIM3 power consumption **Table 12: DTIM3 power consumption** | Mode | Condition: T A =25 o C, V BAT /V DDIO = 3.3 V, 102.4 ms Beacon Interval | V BAT Min | V BAT Typ | V BAT Max | Unit | | ------------------------------------------------ | ----------------------------------------------------------------------- | --------- | --------- | --------- | ---- | | S1G beacons | 1 MHz channel | 370 | 385 | 395 | uA | | S1G beacons | 2 MHz channel | 370 | 385 | 395 | uA | | S1G beacons | 4 MHz channel | 265 | 275 | 285 | uA | | S1G beacons | 8 MHz channel | 265 | 275 | 285 | uA | | S1G beacons with proprietary DTIM signaling \[1] | 1 MHz channel | 170 | 188 | 200 | uA | | S1G beacons with proprietary DTIM signaling \[1] | 2 MHz channel | 170 | 188 | 200 | uA | | S1G beacons with proprietary DTIM signaling \[1] | 4 MHz channel | 165 | 175 | 185 | uA | | S1G beacons with proprietary DTIM signaling \[1] | 8 MHz channel | 165 | 175 | 185 | uA | #### 5.4.5 DTIM10 power consumption **Table 13: DTIM10 power consumption** | Mode | Condition: T A =25 o C, V BAT /V DDIO = 3.3 V, 102.4 ms Beacon Interval | V BAT Min | V BAT Typ | V BAT Max | Unit | | --------------------------------------------- | ----------------------------------------------------------------------- | --------- | --------- | --------- | ---- | | S1G beacons | 1 MHz channel | 135 | 140 | 155 | uA | | S1G beacons | 2 MHz channel | 135 | 140 | 155 | uA | | S1G beacons | 4 MHz channel | 95 | 105 | 120 | uA | | S1G beacons | 8 MHz channel | 95 | 105 | 120 | uA | | S1G beacons with proprietary DTIM signaling 1 | 1 MHz channel | 80 | 85 | 100 | uA | | S1G beacons with proprietary DTIM signaling 1 | 2 MHz channel | 80 | 85 | 100 | uA | | S1G beacons with proprietary DTIM signaling 1 | 4 MHz channel | 75 | 80 | 95 | uA | | S1G beacons with proprietary DTIM signaling 1 | 8 MHz channel | 75 | 80 | 95 | uA | *** ### 5.5 RF Specifications #### 5.5.1 Frequency Range The MM6108 radio operates in the frequency range from 850 MHz to 950 MHz, covering the upper sub-11 GHz band. **Table 14: Global frequency bands** | Region | Sub 1 GHz bands available (MHz) | Total BW available (MHz) | | --------- | ------------------------------- | ------------------------ | | USA | 902 - 928 | 26 | | Europe | 863 - 868 917.4 -919.4 | 7 | | Australia | 915 - 928 | 13 | | Japan | 915.9 - 928.1 | 11 | | Singapore | 866 - 869 920 - 925 | 8 | | India | 865 - 868 | 3 | *** #### 5.5.2 Receiver **5.5.2.1 Sensitivity** Sensitivities for 10% packet error rate, 1000 byte packets. **Table 15: Receiver sensitivity** | MCS index | Modulation scheme | Coding rate | Phy rate (Mbps) per BW 1 MHz | Phy rate (Mbps) per BW 2 MHz | Phy rate (Mbps) per BW 4 MHz | Phy rate (Mbps) per BW 8 MHz | Minimum receive sensitivity (dBm) 1 MHz | Minimum receive sensitivity (dBm) 2 MHz | Minimum receive sensitivity (dBm) 4 MHz | Minimum receive sensitivity (dBm) 8 MHz | | --------- | ----------------- | ----------- | ---------------------------- | ---------------------------- | ---------------------------- | ---------------------------- | --------------------------------------- | --------------------------------------- | --------------------------------------- | --------------------------------------- | | 10 | BPSK | 1/2 x 2 | 0.17 | N/A | N/A | N/A | -107 | N/A | N/A | N/A | | 0 | BPSK | 1/2 | 0.33 | 0.72 | 1.5 | 3.3 | -105 | -103 | -101 | -97 | | 1 | QPSK | 1/2 | 0.67 | 1.4 | 3.0 | 6.5 | -102 | -100 | -97 | -93 | | 2 | QPSK | 3/4 | 1.0 | 2.2 | 4.5 | 9.8 | -99 | -97 | -95 | -91 | | 3 | 16-QAM | 1/2 | 1.3 | 2.9 | 6.0 | 13 | -96 | -94 | -91 | -88 | | 4 | 16-QAM | 3/4 | 2.0 | 4.3 | 9.0 | 20 | -93 | -90 | -88 | -85 | | 5 | 64-QAM | 2/3 | 2.7 | 5.8 | 12 | 26 | -89 | -87 | -84 | -80 | | 6 | 64-QAM | 3/4 | 3.0 | 6.5 | 14 | 29 | -88 | -85 | -83 | -79 | | 7 | 64-QAM | 5/6 | 3.3 | 7.2 | 15 | 33 | -87 | -84 | -81 | -77 | **5.5.2.2 Adjacent Channel Rejection** Adjacent channel rejection is measured by setting the requested signal’s strength 3 dB above the rate-dependent sensitivity and raising the power of the interfering signal until 10% PER is caused for a PSDU length of 256-byte packets. The power difference between the interfering and requested channel is the corresponding adjacent channel rejection: **Table 16: Adjacent channel rejection** | Bandwidth (MHz) | MCS Index | Modulation Scheme | Coding Rate | Adjacent Channel Rejection (dB) IEEE Spec | Adjacent Channel Rejection (dB) | | --------------- | --------- | ----------------- | ----------- | ----------------------------------------- | ------------------------------- | | 4 | 0 | BPSK | 1/2 | 16 | 34 | | 4 | 2 | QPSK | 3/4 | 11 | 23 | | 4 | 4 | 16-QAM | 3/4 | 4 | 21 | | 4 | 7 | 64-QAM | 5/6 | -2 | 3 | | 8 | 0 | BPSK | 1/2 | 16 | 26 | | 8 | 2 | QPSK | 3/4 | 11 | 24 | | 8 | 4 | 16-QAM | 3/4 | 4 | 23 | | 8 | 7 | 64-QAM | 5/6 | -2 | 10 | *** #### 5.5.3 Transmitter Note: The following transmit power levels are for IEEE compliance for 802.11ah. This does not consider any backoffs needed to adhere to regional spectrum compliance (eg, FCC, IC, TELEC). **Table 17: Transmitter output** | Tx output power (1, 2 MHz BW) | Min (dBm) | Typical (dBm) | Max (dBm) | | ----------------------------- | --------- | ------------- | --------- | | MCS 0 | 5.3 | 6.4 | 7.4 | | MCS 7 | 1.4 | 2.8 | 4.1 | *** ### 5.6 Digital Specifications ![Figure 10: Powering on and reset timing diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/z2WwiCS13SpRQiMEBOdb/Unknown%20image) *Figure 10: Powering on and reset timing diagram* **Table 18: Digital specifications** | Parameters | Description | Min | Max | Unit | | ---------- | ---------------------------------------------------------------- | ---- | --- | ---- | | V IL\_nRST | Reset threshold | 450 | | mV | | t 0 | Time between VBAT brought up (3.3V) and RESET\_N being activated | 50 | | μs | | t 1 | Duration of RESET\_N signal level < VIL\_nRST to reset the chip | 1000 | | μs | | t B | Boot Time | | 6 | ms | *** **Table 19: Digital Specifications** | Parameters | Description | VDDIO | Min | Max | Unit | | ---------- | ------------------------------------------------------------------ | ----- | ---- | ---- | ---- | | V IL\_GPIO | Low input threshold for all GPIO and SDIO pins | 1.8 | -0.3 | 0.63 | V | | V IL\_GPIO | Low input threshold for all GPIO and SDIO pins | 2.5 | -0.3 | 0.7 | V | | V IL\_GPIO | Low input threshold for all GPIO and SDIO pins | 3.3 | -0.3 | 0.8 | V | | V IH\_GPIO | High input threshold for all GPIO and SDIO pins | 1.8 | 1.17 | 3.6 | V | | V IH\_GPIO | High input threshold for all GPIO and SDIO pins | 2.5 | 1.7 | 3.6 | V | | V IH\_GPIO | High input threshold for all GPIO and SDIO pins | 3.3 | 2.0 | 3.6 | V | | V OL\_GPIO | Low output voltage for all GPIO and SDIO pins assuming a 8mA load | 1.8 | 0.13 | 0.38 | V | | V OL\_GPIO | Low output voltage for all GPIO and SDIO pins assuming a 8mA load | 2.5 | 0.10 | 0.27 | V | | V OL\_GPIO | Low output voltage for all GPIO and SDIO pins assuming a 8mA load | 3.3 | 0.08 | 0.18 | V | | V OH\_GPIO | High output voltage for all GPIO and SDIO pins assuming a 8mA load | 1.8 | 1.34 | 1.70 | V | | V OH\_GPIO | High output voltage for all GPIO and SDIO pins assuming a 8mA load | 2.5 | 2.20 | 2.41 | V | | V OH\_GPIO | High output voltage for all GPIO and SDIO pins assuming a 8mA load | 3.3 | 3.07 | 3.23 | V | | V OL\_SDIO | Low output voltage for all SDIO pins assuming a 8mA load | 1.8 | 0.17 | 0.52 | V | | V OL\_SDIO | Low output voltage for all SDIO pins assuming a 8mA load | 2.5 | 0.14 | 0.36 | V | | V OL\_SDIO | Low output voltage for all SDIO pins assuming a 8mA load | 3.3 | 0.11 | 0.24 | V | | V OH\_SDIO | High output voltage for all SDIO pins assuming a 8mA load | 1.8 | 1.19 | 1.67 | V | | V OH\_SDIO | High output voltage for all SDIO pins assuming a 8mA load | 2.5 | 2.10 | 2.39 | V | | V OH\_SDIO | High output voltage for all SDIO pins assuming a 8mA load | 3.3 | 2.99 | 3.21 | V | *** ## 6 Package Information ### 6.1 Package Dimensions ![Figure 11: Package dimensions](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/pFh2CzKf81IbDSFyhjx7/Unknown%20image) *Figure 11: Package dimensions* ### 6.2 Thermal Properties **Table 20: Thermal properties** | PIN | Size | Power (W) | Ta (°C) | Theta JA (°C/W) | Psi JT (°C/W) | Theta JC ( o C/W) | | --- | ------- | --------- | ------- | --------------- | ------------- | ----------------- | | 48 | QFN 6x6 | 1 | 25 | 31.22 | 0.26 | 15.703 | Ta: ambient Temperature, defined as the temperature of the surrounding environment expressed in °C. The temperature range can be found in the recommended operating conditions section of the datasheets. Theta JA: thermal resistance junction-to-ambient Psi JT: thermal characterization parameter between the junction and package top. Theta TJ: junction temperature rise over case in deg C/ Watt of chip power dissipation. Tj = junction temperature (during operation). It is determined by P x theta JA Notes: * Power = power consumed by the device * The maximum junction temperature should be controlled to less than 125oC * The actual maximum junction temperature is determined using Theta JA, and depends on ambient temperature as well as power dissipation in the actual use. JEDEC standards can be found at [www.jedec.org](https://www.google.com/url?q=http://www.jedec.org/\&sa=D\&source=editors\&ust=1783385367403905\&usg=AOvVaw0AVG3Eee4nwdvLKFdHBXom) under the JESD51 standard. *** ### 6.3 IC Markings ![Figure 12: IC marking diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/1OIyzVFg6QvgXzYhFXn5/Unknown%20image) *Figure 12: IC marking diagram* **Table 21: IC markings** | Line | Title | Example | Description | | ---- | ---------- | ---------- | ------------------------------------------------------------------------------------------------- | | 1 | MMXXXXMDSn | MM6108MIQ | Device number; Optional: Custom Marketing Letter; Temperature Grade; Package Type; | | 2 | TA12 YYWW | TA2103 | Fab/Assembly codes; 2 digits for Silicon revision (Major, Minor - Internal Only); date code YYWW; | | 3 | XXXXXXX | MOR946N001 | 8 digits Assy Lot number; | \* All Morse Micro ICs are lead-free | Line | Title | Example | Description | | ---- | ----------------------- | ------- | -------------------------------------------------------- | | 1 | Major silicon revision | 0..9 | Designated by a single number from 0 to 9 | | 2 | Minor silicon revision | 0..9 | Designated by a single number from 0 to 9 | | M | Custom Marketing suffix | M, L | M: 56 pin package (“Medium”) L: 64 pin package (“Large”) | | D | Temperature Grade | I/C | I = -40 o C to 85 o C; C = 0 o C to 70 o C | | S | Package Type code | Q/B | Q: QFN; B: FCBGA/BGA | | n | Bond-Out Option | 0..9 | Designated by a single number 0..9 | ## 7 PCB Land Pattern ![Figure 13: PCB land pattern diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/jq0QDiXXJUtzRep6RhXy/Unknown%20image) *Figure 13: PCB land pattern diagram* | Key | Dimension (mm) | | --- | -------------- | | A | 0.90 | | B | 0.20 | | C | 0.40 | | D | 5.80 | | E | 5.80 | | F | 4.50 | | G | 4.50 | ## 8 Solder Stencil Pattern ![Figure 14: Solder stencil pattern diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/NHR43DDVpWApvuAOeuPa/Unknown%20image) *Figure 14: Solder stencil pattern diagram* | Key | Dimension (mm) | | --- | -------------- | | A | 0.80 | | B | 0.15 | | C | 0.40 | | D | 5.80 | | E | 5.80 | | X | 2.00 | | Y | 2.00 | | Z | 0.50 | ## 9 Recommended Soldering Profile ![Figure 15: Soldering Profile](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/QetXKUfSQW7XTAXxpQqL/Unknown%20image) *Figure 15: Soldering Profile* Pb-free (SAC Alloys) Process - Classification Temperature (TC) **Table 22: Soldering profile** | Package Thickness | Volume (mm 3 ) < 350 | Volume (mm 3 ) 350 - 2000 | Volume (mm 3 ) > 2000 | | ----------------- | -------------------- | ------------------------- | --------------------- | | < 1.6 mm | 260 °C | 260 °C | 260 °C | | 1.6 mm - 2.5 mm | 260 °C | 250 °C | 245 °C | | > 2.5 mm | 250 °C | 245 °C | 245 °C | | Profile Feature | Pb-free Assembly | | -------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | Temperature Min (Tsmin) Temperature Max (Tsmax) Time (ts) from (Tsmin to Tsmax) | 150 °C 200 °C 60-120 seconds | | Ramp-up rate (TL to TP) | 3 °C/second max. | | Liquidus temperature (TL) Time (tL) maintained above TL | 217 °C 60-150 seconds | | Peak package body temperature (TP) | For users TP must not exceed the Classification temp in Table 4-2. For suppliers TP must equal or exceed the Classification temp in Table 4-2. | | Time (tP)\* within 5 °C of the specified classification temperature (TC), see Figure 5-1 | 30\* seconds | | Ramp-down rate (TP to TL) | 6 °C/second max. | | Time 25 °C to peak temperature | 8 minutes max. | | \* Tolerance for peak profile temperature (TP) is defined as a supplier minimum and a user maximum | \* Tolerance for peak profile temperature (TP) is defined as a supplier minimum and a user maximum | Note 1: All temperatures refer to the center of the package, measured on the package body surface that is facing up during assembly reflow (e.g., live-bug). If parts are reflowed in other than the normal live-bug assembly reflow orientation (i.e., dead-bug), TP shall be within +/- 2 °C of the live-bug TP and still meet the TC requirements, otherwise, the profile shall be adjusted to achieve the latter. To accurately measure actual peak package body temperatures refer to JEP140 for recommended thermocouple use. Note 2: Reflow profiles in this document are for classification/preconditioning and are not meant to specify board assembly profiles. Actual board assembly profiles should be developed based on specific process needs and board designs and should not exceed the parameters in Table 5-2. For example, if TC is 260 °C and time tP is 30 seconds, this means the following for the supplier and the user. For a supplier: The peak temperature must be at least 260 °C. The time above 255 °C must be at least 30 seconds. For a user: The peak temperature must not exceed 260 °C. The time above 255 °C must not exceed 30 seconds. Note 3: All components in the test load shall meet the classification profile requirements. Note 4: SMD packages classified to a given moisture sensitivity level by using Producers or Criteria defined within any previous version of J-STD-020, JESD22-A112 (rescinded), IPC-SM-786 (rescinded) do not need to be reclassified to the current revision unless a change in classification level or a higher peak classification is desired. *** ## 10 Packaging and Labeling ### 10.1 Tape & Reel Specification **Table 23: Tape and reel specifications** | Term | Definition | | ---------------------- | ------------------------- | | Product | MM6108 | | # Units | 3,000 | | Reel Size | 13 inches | | Pizza Box | Yes | | Vacuum Seal | Yes | | Dry Bake | 125 o C / 24 hours (MSL3) | | Reel Pocket Dimensions | Refer to Figure 2 | | Pin 1 indicator | Marked on the chip | ### 10.2 Tray Specification **Table 24: Tray specifications** | Term | Definition | | --------------- | ------------------------- | | Product | MM6108 | | # Units | 490 | | Tray Size | 322.6mm x 135.9mm | | Pizza Box | No | | Vacuum Seal | Yes | | Dry Bake | 125 o C / 24 hours (MSL3) | | Pin 1 indicator | Marked on the chip | ### 10.3 Reel Dimensions ![Figure 16: Reel dimensions](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/auxwuDxs5wVB2o3vWDSN/Unknown%20image) *Figure 16: Reel dimensions* ### 10.4 Tape and Device Placement Dimensions ![Figure 17: Tape and device placement dimensions](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/j65TOGuhosjoOtLRsdYP/Unknown%20image) *Figure 17: Tape and device placement dimensions* *** ## 11 Handling and Storage The MM6108IQ IC is a moisture-sensitive device rated at Moisture Sensitive Level 3 (MSL3) per IPC/JEDEC J-STD-20. After opening the moisture-sealed storage bag, modules that will be subjected to reflow solder or other high-temperature processes must be: 1. Mounted to a circuit board within 168 hours at factory conditions (≤30°C and <60% RH)\ OR 2. Continuously stored per IPC/JEDEC J-STD-033 ICs exposed to moisture and environmental conditions exceeding packaging and storage conditions MUST be baked before mounting according to IPC/JEDEC J-STD-033. Failure to meet packaging and storage conditions will result in irreparable damage to modules during solder reflow. ## 12 Part Number and Ordering Information **Table 25: Part number and ordering information** | Part Number | Packing Type | MOQ | Package | Description | Operating Ambient Temperature | | ----------- | ------------ | ---- | ------- | --------------------------------------------------- | ----------------------------- | | MM6108IQ-T | Tray | 490 | QFN 6x6 | IEEE 802.11ah Sub-1 GHz 1/2/4/8 MHz Wi-Fi HaLow SoC | -40 °C to 85 °C | | MM6108IQ-TR | Tape & Reel | 3000 | QFN 6x6 | IEEE 802.11ah Sub-1 GHz 1/2/4/8 MHz Wi-Fi HaLow SoC | -40 °C to 85 °C | ## 13 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | DS104 | 17 Jun 2025 | Added Front End considerations Added PCB layout recommendations Updated formatting | | DS103 | 15 Dec 2023 | Added power sequencing requirements Added Vih, Vil, Voh, and Vol specifications Added solder profile Added packaging Added chip markings Added sleep/wake pin sequencing | | DS102 | 8 Apr 2022 | Updated table 5.5.1 RF Spectrum Range Added PCB land pattern and solder stencil Updated electrical characteristics Added Max/Min values | | DS101 | 4 Nov 2021 | Updated recommended operating conditions Updated Tx and Rx power consumption Updated Adjacent Current Rejection | | DS100 | 1 Jun 2021 | Initial release | Morse Micro makes no warranty, representation, or guarantee regarding the information contained herein or the suitability of its products and services for any particular purpose, nor does Morse Micro assume any liability whatsoever arising out of the application or use of any product or circuit. The products sold hereunder, and any other products sold by Morse Micro have been subject to limited testing and should not be used in conjunction with mission-critical equipment or applications. All performance specifications are provided based on rigorous internal testing and are validated to be accurate. However, these specifications should not serve as a substitute for Buyer’s own testing and verification. The Buyer is responsible for conducting all necessary performance and compatibility testing of the Products, both standalone and when integrated into end-products, to ensure they meet specific application and compliance requirements. The information provided by Morse Micro hereunder is provided “as is, where is” and with all faults, and the entire risk associated with such information is entirely with the Buyer. Morse Micro does not grant, explicitly or implicitly, to any party any patent rights, licenses, or any other IP rights, whether regarding such information itself or anything described by such information. Information provided in this document is proprietary to Morse Micro, and Morse Micro reserves the right to make any changes to the information in this document or to any products and services at any time without notice. *** [\[1\]](#ftnt_ref1) Signaling that indicates whether a power save STA should receive and process an entire beacon # MM8108-MF15457 Datasheet v4 [Download as PDF](https://www.morsemicro.com/resources/datasheets/modules/MM8108-MF15457_Data_Sheet.pdf) ## 1 Product Overview ### 1.1 Introduction Wi-Fi HaLow (pronounced “HEY-low”) is the first global Wi-Fi standard (IEEE 802.11ah) specifically designed to meet the needs of the Internet of Things (IoT). It’s an open standard wireless network technology operating in the sub-1 GHz license-exempt RF bands (850-950 MHz range), so it doesn’t incur ongoing monthly costs like cellular/mobile network connections. By operating in the sub-1 GHz range, this low-power wireless protocol can connect more IoT devices over much longer distances and with significantly lower power than traditional Wi-Fi. Morse Micro, the world’s leading Wi-Fi HaLow solutions provider, offers several Wi-Fi HaLow connectivity solutions. The MM8108-MF15457 is a fully integrated Wi-Fi HaLow module with long range, low power consumption, and excellent RF performance, featuring our second-generation MM8108 Wi-Fi HaLow SoC. It is compliant with IEEE 802.11ah, supporting PHY rates up to 43.3 Mbps, and provides for operation in the sub-1 GHz license-exempt RF bands. The radio in the MM8108 supports programmable operation in these bands worldwide, spanning from 850 MHz to 950 MHz. The MM8108’s integrated power amplifier (PA) offers world-leading transmit performance and energy efficiency with on-chip amplification of up to 26 dBm, which is ideal for low-cost devices. The ultra-high linearity integrated low-noise amplifier (LNA) offers exceptional receive sensitivity. These innovations, combined with digital transmit filtering and pre-distortion circuits, result in an advanced transceiver design that ensures out-of-the-box compatibility with all global Wi-Fi HaLow regulatory environments. MM8108-MF15457 supports a USB 2.0 High-Speed host interface and an SDIO/SPI host interface, offering solution architects flexibility when integrating Wi-Fi HaLow connectivity into their existing solution. With a footprint of only 11 mm x 10 mm, the MM8108-MF15457 module has been designed to showcase the cost and size benefits of the higher level of integration of our second-generation SoC. MM8108-MF15457 supports WPA3 and all standard security features required for Wi-Fi HaLow product certifications. ### 1.2 Features * Single-stream maximum PHY rate of 43.3 Mbps at 8 MHz bandwidth * Radio supporting worldwide Sub-1 GHz frequency bands * Frequency range: 850-950 MHz * Channel bandwidth options of 1/2/4/8 MHz * High power and extremely high efficiency integrated PA with maximum 26 dBm (400 mW) output power at 45% PA efficiency and 37% SoC efficiency * Novel PA architecture maintains efficiency at power backoff * Low-power receiver with integrated LNA, NF < 4 dB * 802.11ah OFDM PHY with Wi-Fi Alliance Wi-Fi HaLow certification * BPSK & QPSK, 16-QAM, 64-QAM and 256-QAM Modulation * Automatic frequency and gain control * Packet detection and channel equalization * Forward Error Correction (FEC) coding and decoding * Modulation and Coding Scheme (MCS) levels 0-10 * 1 MHz duplicate mode * Optional traveling pilots * 802.11ah MAC with Wi-Fi Alliance Wi-Fi HaLow certification * Support for Station (STA) and Access Point (AP) roles * Listen-Before-Talk (LBT) access with energy detection * 802.11 power save * 802.11 fragmentation and defragmentation * Power-Saving Target Wake Time (TWT) support for extended battery life * Automatic and manual MCS rate selection * On-chip software stack assisting with host offload of Wi-Fi connection management * USB 2.0 High-Speed compliant device interface * Integrated USB 2.0 PHY and device interface supporting High-Speed mode at 480 Mbps * SDIO 2.0 compliant device interface * SDIO 2.0 High-Speed at 50 MHz max for 200 Mbps * Support for 1-bit and 4-bit data mode * Support for SPI mode operation at up to 80 MHz for 80 Mbps * Power Management Unit (PMU) supporting various modes of operation * Single supply 3.0-3.6 V for integrated DC-DCs and LDOs * Multiple low-power modes (hibernate, deep sleep, snooze) support extreme power environments * Broad spectrum of security features * Wi-Fi layer security, including Wi-Fi Protected Access version 3 (WPA3), Protected Management Frames (PMF), and Opportunistic Wireless Encryption (OWE) * Hardware support for Advanced Encryption Standard (AES) and Secure Hash Algorithm version 2 (SHA-2) functions (SHA-256, SHA-384, SHA-512) ### 1.3 Applications Ideally suited for Internet of Things (IoT) and Machine-to-Machine (M2M) applications such as: * Surveillance cameras and sensors * Cloud connectivity * Low-power sensor networks * Building automation systems * Asset tracking and management * Machine performance monitors and sensors * Building access control and security * Drone video and navigation communications * Connected toys and games * Rural internet access * Agricultural networks * Utility smart meter and intelligent grid * Proximity sensors * Industrial automation controls * Smart home automation * EV car chargers * Appliances * Construction site connectivity * Smart signs and kiosks * Retail point-of-sale terminals * Vehicle-to-vehicle communications * IP sensor networks * Biometric IDs and keypads * Warehouse connectivity * Intelligent lighting controls * BT/ZigBee™/Z-Wave™ to Wi-Fi HaLow gateways * Wi-Fi to Wi-Fi HaLow bridges * Wi-Fi HaLow client adapters/dongles * Smart city networks ## 2 Pin Descriptions The MM8108-MF15457 module features 38 pins, which are described in this section. The following illustration shows the top view of the module pins. ![Figure 1: Pin diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/ZSaBqxCc0ABBAp13z8b3/Unknown%20image) *Figure 1: Pin diagram* | Pin | Pin Name | Type | Description | Alternative | | --- | -------------- | ----------- | ---------------------------------------- | ----------- | | 1 | GND | Ground | Ground | | | 2 | ANT | Analog | Antenna | | | 3 | GND | Ground | Ground | | | 4 | RESET\_N \[2] | Digital I/O | Asynchronous chip reset (active low) | | | 5 | WAKE \[2] | Digital I/O | External wake from Deep Sleep and Snooze | | | 6 | JTAG\_TMS | Digital I/O | JTAG Mode Select | GPIO15 \[3] | | 7 | JTAG\_TCK | Digital I/O | JTAG Clock | GPIO13 \[3] | | 8 | JTAG\_TDO | Digital I/O | JTAG Data Out | GPIO16 \[3] | | 9 | JTAG\_TDI | Digital I/O | JTAG Data In | GPIO14 \[3] | | 10 | VBAT | Supply | 3.3 V VBAT Supply | | | 11 | GND | Ground | Ground | | | 12 | SDIO\_D0 \[1] | Digital I/O | SDIO Data line | SPI\_MISO | | 13 | SDIO\_D3 \[1] | Digital I/O | SDIO Data line | SPI\_CS | | 14 | SDIO\_D1 \[1] | Digital I/O | SDIO Data line | SPI\_INT | | 15 | SDIO\_D2 \[1] | Digital I/O | SDIO Data line | | | 16 | SDIO\_CMD \[1] | Digital I/O | SDIO Command line | SPI\_MOSI | | 17 | SDIO\_CLK | Digital I/O | SDIO Clock input | SPI\_SCK | | 18 | GPIO5 \[3] | Digital I/O | Programmable digital I/O | | | 19 | GPIO4 \[3] | Digital I/O | Programmable digital I/O | | | 20 | GND | Ground | Ground | | | 21 | GPIO3 \[3] | Digital I/O | Programmable digital I/O | | | 22 | VDDIO | Supply | Host supply for digital I/O | | | 23 | GND | Ground | Ground | | | 24 | VBAT\_TX | Supply | 3.3 V VBAT-TX Supply | | | 25 | VDD\_USB | Supply | USB Supply | | | 26 | GND | Ground | Ground | | | 27 | USB\_D\_N | Digital I/O | USB DM line | | | 28 | USB\_D\_P | Digital I/O | USB DP line | | | 29 | BUSY | Digital I/O | BUSY signal output | | | 30 | GND | Ground | Ground | | | 31 | GPIO1 \[3] | Digital I/O | Programmable digital I/O | | | 32 | GPIO0 \[3] | Digital I/O | Programmable digital I/O | | | 33 | GPIO6 \[3] | Digital I/O | Programmable digital I/O | | | 34 | GPIO7 \[3] | Digital I/O | Programmable digital I/O | | | 35 | GPIO8 \[3] | Digital I/O | Programmable digital I/O | | | 36 | GPIO 9 \[3] | Digital I/O | Programmable digital I/O | | | 37 | GPIO10 \[3] | Digital I/O | Programmable digital I/O | | | 38 | GND | Ground | Ground | | \[1] All SDIO bus pins except SDIO\_CLK should be pulled up with a 10 kΩ to 100 kΩ resistor as per the SDIO standard. \[2] Supplied from VBAT domain. The VDDIO domain drives other digital pins. \[3] GPIOs 0 to 10 may provide alternative functions, including SPI master, I2C master, PWM, and UART. This functionality necessitates custom software, which Morse Micro can develop upon request. For further details, please contact Morse Micro. ## 3 Functional Description The following sections describe the functions of the MM8108-MF15457 module. ### 3.1 Block Diagram ![Figure 2: Functional block diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/sEQAOWfOzDFewLR8esRi/Unknown%20image) *Figure 2: Functional block diagram* ### 3.2 Power Supply Requirements MM8108-MF15457 module power is derived from a 3.0 to 3.6 V supply on pins VBAT and VBAT\_TX. VDDIO sets the IO voltage of the MM8108-MF15457. It has an input voltage range of 2.25 V to 3.6 V and should be connected to the same power supply as the host MCU. There are no strict power-up sequencing requirements. ### 3.3 USB Host Interface A schematic diagram detailing the USB host interface circuit is shown below: ![Figure 3: USB host interface circuit](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/G0ITEV0h4RY4MPPIPrJO/Unknown%20image) *Figure 3: USB host interface circuit* ### 3.4 USB Network Adapter Interface A schematic diagram detailing the USB network adapter circuit is shown below: ![Figure 4: USB network adapter circuit](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/1vjDelkTcx8S9W5z3rXh/Unknown%20image) *Figure 4: USB network adapter circuit* ### 3.5 SDIO Host Interface When selecting a host to interface with the MM8108-MF15457 module via the SDIO interface, ensure the host supports SDIO 2.0 with SDIO clock speeds of up to 50 MHz. Slower clock speeds will impact the maximum achievable throughput. The SDIO data and command lines should be pulled up with 10 kΩ to 100 kΩ resistors per the SDIO 2.0 specification. For proper operation and to take advantage of the module’s power-saving features, connect RESET\_N and WAKE to standard digital outputs (CMOS logic levels). The BUSY signal should be connected to a digital input (also CMOS logic levels). Do not use open-collector or open-drain circuits, as they will cause incorrect behavior. In applications where the module must always be on, and the power-saving features can not be used, such as access points, the WAKE pin can be left not connected, reducing the need for GPIOs on the host processor to only one. A schematic diagram detailing the SDIO host interface circuit using the module’s power-saving features is shown below: ![Figure 5: SDIO host interface circuit using power-saving features](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/KCDqcOpEmlgtqVyMgWBo/Unknown%20image) *Figure 5: SDIO host interface circuit using power-saving features* A schematic diagram detailing the SDIO host interface circuit for always-on applications is shown below: ![Figure 6: SDIO host interface circuit for always-on applications](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/JAdB8RHIz1hfS9UG2QjP/Unknown%20image) *Figure 6: SDIO host interface circuit for always-on applications* ### 3.6 SPI Host Interface When selecting a host to interface with the MM8108-MF15457 module via the SPI interface, consider the following recommendations to achieve the best throughput: * The host must support level-triggered interrupts. * The host must support full-duplex SPI mode. * The host must support DMA-backed transactions on the SPI bus. Standard SPI can achieve up to 25 Mbps at 50 MHz, which will be significantly reduced without DMA support. For example, an SPI interface with an 8-byte buffer per transaction might only achieve 2 Mbps throughput on the SPI bus. For proper operation and to take advantage of the module’s power-saving features, connect RESET and WAKE to standard digital outputs (CMOS logic levels). The BUSY signal should be connected to a digital input (also CMOS logic levels). Do not use open-collector or open-drain circuits, as they will cause incorrect behavior. In applications where the module must always be on, and the power-saving features can not be used, such as access points, the WAKE pin can be left not connected, reducing the need for GPIOs on the host processor to only one. A schematic diagram detailing the SPI host interface circuit using the module’s power-saving features is shown below: ![Figure 7: SPI host interface circuit using power-saving features](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/vfy6yDKEHtx0ADfD2Hcu/Unknown%20image) *Figure 7: SPI host interface circuit using power-saving features* A schematic diagram detailing the SPI host interface circuit for always-on applications is shown below: ![Figure 8: SPI host interface circuit for always-on applications](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/JaWuI1wyM4GPS3f3dgRa/Unknown%20image) *Figure 8: SPI host interface circuit for always-on applications* ### 3.7 Boot/Reset Sequencing #### 3.7.1 Boot Timing ![Figure 9: Powering on and reset timing diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/Fk9wvLynZKeTkBg5ivnn/Unknown%20image) *Figure 9: Powering on and reset timing diagram* **Table 1: Boot timing overview** | Parameters | Description | Min | Max | Unit | | ---------- | ---------------------------------------------------------------- | --- | --- | ---- | | V IL\_nRST | Reset threshold | 450 | | mV | | t 0 | Time between VBAT brought up (3.3V) and RESET\_N being activated | 50 | | μs | | t B | Boot Time | | 10 | ms | #### 3.7.2 Reset Timing ![Figure 10: Powering on and reset timing diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/wlayDvQZtuXQROX8Wj43/Unknown%20image) *Figure 10: Powering on and reset timing diagram* **Table 2: Reset timing overview** | Parameters | Description | Min | Max | Unit | | ---------- | --------------------------------------------------------------- | ---- | --- | ---- | | V IL\_nRST | Reset threshold | 450 | | mV | | t 1 | Duration of RESET\_N signal level < VIL\_nRST to reset the chip | 1000 | | μs | | t B | Boot Time | | 10 | ms | ## 4 Electrical Characteristics ### 4.1 Absolute Maximum Ratings Stress beyond absolute maximum ratings may cause permanent damage to the MM8108-MF15457 module. Operation is only guaranteed within the recommended operation conditions. Operation of the device outside of the recommended conditions may result in a reduced lifetime and reliability problems, even if the absolute maximum ratings are not exceeded. **Table 3: Absolute maximum and minimum voltage ratings** | Parameter | Min | Max | Unit | | ------------------- | ---- | --- | ---- | | VBAT voltage | -0.3 | 3.6 | V | | VBAT\_TX voltage | -0.3 | 3.6 | V | | RESET\_N/WAKE | -0.3 | 3.6 | V | | VDDIO | -0.3 | 3.6 | V | | Analog/RF pin | -0.3 | 1.0 | V | | Storage temperature | -40 | 125 | °C | | RF input power (CW) | - | 6 | dBm | ### 4.2 ESD Immunity **Table 4: ESD immunity specifications** | Parameter | Parameter | Parameter | Min | Max | Unit | | ----------------------------------------- | ----------------------------------------------------- | ------------------------ | ------ | ----- | ---- | | Electrostatic discharge (ESD) performance | Human body model (HBM), per ANSI / ESDA / JEDEC JS001 | RF Input | -1,000 | 1,000 | V | | Electrostatic discharge (ESD) performance | Human body model (HBM), per ANSI / ESDA / JEDEC JS001 | All pins except RF Input | -2000 | 2000 | V | | Electrostatic discharge (ESD) performance | Charged device model (CDM), per JESD22-C101 | All pins | -500 | 500 | V | ### 4.3 Recommended Operating Conditions **Table 5: Recommended operating conditions** | Parameter | Min | Typ | Max | Unit | | ------------------- | ---- | --- | --- | ---- | | Ambient temperature | -40 | | 85 | °C | | Storage temperature | -40 | | 125 | °C | | VBAT | 3.0 | 3.3 | 3.6 | V | | VBAT\_TX | 3.0 | 3.3 | 3.6 | V | | VDDI O | 2.25 | 3.3 | 3.6 | V | ### 4.4 Power Consumption #### 4.4.1 Active Transmit Current Consumption **Table 6: Transmit current consumption for VBAT, VBAT\_TX separated** | MCS Index | Current consumption (mA) per BW at V BAT 100% duty cycle, T A =25 o C, V BAT = V DDIO =3.3 V 1 MHz | Current consumption (mA) per BW at V BAT 100% duty cycle, T A =25 o C, V BAT = V DDIO =3.3 V 2 MHz | Current consumption (mA) per BW at V BAT 100% duty cycle, T A =25 o C, V BAT = V DDIO =3.3 V 4 MHz | Current consumption (mA) per BW at V BAT 100% duty cycle, T A =25 o C, V BAT = V DDIO =3.3 V 8 MHz | Current consumption (mA) per BW at V BAT\_TX 100% duty cycle, T A =25 o C, V BAT = V DDIO =3.3 V 1 MHz | Current consumption (mA) per BW at V BAT\_TX 100% duty cycle, T A =25 o C, V BAT = V DDIO =3.3 V 2 MHz | Current consumption (mA) per BW at V BAT\_TX 100% duty cycle, T A =25 o C, V BAT = V DDIO =3.3 V 4 MHz | Current consumption (mA) per BW at V BAT\_TX 100% duty cycle, T A =25 o C, V BAT = V DDIO =3.3 V 8 MHz | | --------- | -------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------ | | 10 | 51 | N/A | N/A | N/A | 281 | N/A | N/A | N/A | | 0 | 52 | 51 | 50 | 59 | 279 | 243 | 160 | 132 | | 1 | 52 | 51 | 50 | 59 | 278 | 243 | 159 | 131 | | 2 | 51 | 51 | 50 | 59 | 277 | 243 | 158 | 130 | | 3 | 51 | 51 | 50 | 59 | 266 | 242 | 158 | 130 | | 4 | 49 | 50 | 50 | 59 | 221 | 221 | 152 | 130 | | 5 | 44 | 47 | 48 | 58 | 144 | 174 | 128 | 125 | | 6 | 42 | 44 | 46 | 57 | 118 | 119 | 109 | 106 | | 7 | 36 | 39 | 44 | 54 | 88 | 96 | 98 | 95 | | 8 | 34 | 38 | 43 | 52 | 69 | 78 | 83 | 81 | | 9 | 32 | N/A | 40 | 49 | 54 | N/A | 63 | 58 | #### 4.4.2 Active Receive Current Consumption **Table 7: Active receive current consumption** | MCS Index | V BAT + V BAT\_TX + V DDIO Current consumption (mA) per BW 100% duty cycle, T A =25 o C, V BAT = V DDIO =3.3 V, Rx signal at -70dBm 1 MHz | V BAT + V BAT\_TX + V DDIO Current consumption (mA) per BW 100% duty cycle, T A =25 o C, V BAT = V DDIO =3.3 V, Rx signal at -70dBm 2 MHz | V BAT + V BAT\_TX + V DDIO Current consumption (mA) per BW 100% duty cycle, T A =25 o C, V BAT = V DDIO =3.3 V, Rx signal at -70dBm 4 MHz | V BAT + V BAT\_TX + V DDIO Current consumption (mA) per BW 100% duty cycle, T A =25 o C, V BAT = V DDIO =3.3 V, Rx signal at -70dBm 8 MHz | | --------- | ----------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | 0 | 20 | 21 | 24 | 32 | | Max | 20 (MCS9) | 21 (MCS8) | 26 (MCS9) | 34 (MCS9) | #### 4.4.3 Listen Receive Current Consumption **Table 8: Listen receive current consumption** | V BAT + V BAT\_TX + V DDIO Current consumption (mA) per BW T A =25 o C, V BAT = V DDIO =3.3 V, Rx signal at -70dBm 1 MHz | V BAT + V BAT\_TX + V DDIO Current consumption (mA) per BW T A =25 o C, V BAT = V DDIO =3.3 V, Rx signal at -70dBm 2 MHz | V BAT + V BAT\_TX + V DDIO Current consumption (mA) per BW T A =25 o C, V BAT = V DDIO =3.3 V, Rx signal at -70dBm 4 MHz | V BAT + V BAT\_TX + V DDIO Current consumption (mA) per BW T A =25 o C, V BAT = V DDIO =3.3 V, Rx signal at -70dBm 8 MHz | | ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------ | | 19 | 20 | 23 | 29 | #### 4.4.4 Low Power Current Consumption **Table 9: Low power current consumption** | Power Mode | Current Consumption T A =25 o C, V BAT = V DDIO =3.3 V V BAT + V BAT\_TX | Current Consumption T A =25 o C, V BAT = V DDIO =3.3 V V DDIO | Current Consumption T A =25 o C, V BAT = V DDIO =3.3 V Unit | | ---------- | ------------------------------------------------------------------------ | ------------------------------------------------------------- | ----------------------------------------------------------- | | Hibernate | <1 | <1 | μA | | Deep Sleep | <2 | <1 | μA | | Snooze | <20 | <1 | μA | | USB snooze | <500 | <1 | μA | #### 4.4.5 Standby Current Consumption (using SDIO/SPI Host Interface) **Table 10: Standby current consumption** | Mode | Condition: T A =25 o C, V BAT = V DDIO =3.3 V | V BAT + V BAT\_TX | V DDIO | Unit | | ------ | --------------------------------------------- | ----------------- | ------ | ---- | | DTIM3 | 2MHz channel, RTC=RTC\_XTAL, beacon=long | 176 | <1 | μA | | DTIM10 | 2MHz channel, RTC=RTC\_XTAL, beacon=long | 68 | <1 | μA | | DTIM40 | 2MHz channel, RTC=RTC\_XTAL, beacon=long | 33 | <1 | μA | | DTIM3 | 2MHz channel, RTC=RTC\_XTAL, beacon=short | 126 | <1 | μA | | DTIM10 | 2MHz channel, RTC=RTC\_XTAL, beacon=short | 52 | <1 | μA | | DTIM40 | 2MHz channel, RTC=RTC\_XTAL, beacon=short | 29 | <1 | μA | The DTIM (Delivery Traffic Indication Message) number (DTIMx) indicates how often a Wi-Fi HaLow station in power-saving Snooze mode should wake to receive traffic from the access point. It is expressed as a multiple of beacon intervals (multiples of 102.4 ms). For example, DTIM1 indicates that the station should wake up every 102.4 ms, while DTIM40 configures the station to wake up every 4.1 seconds. Configuring DTIM is a complex compromise between power consumption and latency. Increasing the DTIM will reduce the average power consumption, as the station spends a greater proportion of time in Snooze mode, which consumes significantly less power than in Listen mode. However, since the station is unable to receive traffic in Snooze mode, increasing DTIM also increases latency. DTIM settings should be optimized appropriately according to the use case. ### 4.5 RF Specifications #### 4.5.1 Frequency Range The MM8108-MF15457 radio operates in the frequency range from 850 MHz to 950 MHz. #### 4.5.2 Receiver Sensitivities for 10% packet error rate, 256-byte packets. Conditions are VBAT=3.3 V, VBAT\_TX=3.3 V, 25oC **Table 11: Rate vs receiver sensitivity** | MCS index | Modulation scheme | Coding rate | PHYrate (Mbps) per BW 1 MHz | PHYrate (Mbps) per BW 2 MHz | PHYrate (Mbps) per BW 4 MHz | PHYrate (Mbps) per BW 8 MHz | Minimum receive sensitivity (dBm) per BW 1 MHz | Minimum receive sensitivity (dBm) per BW 2 MHz | Minimum receive sensitivity (dBm) per BW 4 MHz | Minimum receive sensitivity (dBm) per BW 8 MHz | | --------- | ----------------- | ----------- | --------------------------- | --------------------------- | --------------------------- | --------------------------- | ---------------------------------------------- | ---------------------------------------------- | ---------------------------------------------- | ---------------------------------------------- | | 10 | BPSK | 1/2 x 2 | 0.1 | N/A | N/A | N/A | -107 | N/A | N/A | N/A | | 0 | BPSK | 1/2 | 0.3 | 0.7 | 1.5 | 3.3 | -106 | -103 | -102 | -98 | | 1 | QPSK | 1/2 | 0.7 | 1.4 | 3.0 | 6.5 | -104 | -101 | -99 | -95 | | 2 | QPSK | 3/4 | 1.0 | 2.2 | 4.5 | 9.8 | -102 | -99 | -97 | -93 | | 3 | 16-QAM | 1/2 | 1.3 | 2.9 | 6.0 | 13 | -99 | -96 | -94 | -90 | | 4 | 16-QAM | 3/4 | 2.0 | 4.3 | 9.0 | 20 | -96 | -93 | -90 | -87 | | 5 | 64-QAM | 2/3 | 2.7 | 5.8 | 12 | 26 | -92 | -89 | -86 | -83 | | 6 | 64-QAM | 3/4 | 3.0 | 6.5 | 14 | 29 | -90 | -87 | -85 | -81 | | 7 | 64-QAM | 5/6 | 3.3 | 7.2 | 15 | 33 | -89 | -86 | -83 | -80 | | 8 | 256-QAM | 3/4 | 4.0 | 8.9 | 18 | 39 | -85 | -82 | -79 | -76 | | 9 | 256-QAM | 5/6 | 4.4 | N/A | 20 | 43 | -83 | N/A | -78 | -74 | #### 4.5.3 Transmitter Note: The following transmit power levels are for IEEE compliance for 802.11ah. They do not consider any backoffs needed for regional spectrum compliance (e.g., FCC, IC, TELEC). TX power in edge channels will be limited by the restricted band edge in the regulatory regions. **Table 12: Mean TX output power** | MCS Index | Power output (dBm) at the module ANT pin per BW T A =25 o C, V BAT = V DDIO =3.3 V, IEEE-compliant with 1.5dB SEM margin 1MHz | Power output (dBm) at the module ANT pin per BW T A =25 o C, V BAT = V DDIO =3.3 V, IEEE-compliant with 1.5dB SEM margin 2MHz | Power output (dBm) at the module ANT pin per BW T A =25 o C, V BAT = V DDIO =3.3 V, IEEE-compliant with 1.5dB SEM margin 4MHz | Power output (dBm) at the module ANT pin per BW T A =25 o C, V BAT = V DDIO =3.3 V, IEEE-compliant with 1.5dB SEM margin 8MHz | | --------- | ----------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | 10 | 25.5 | N/A | N/A | N/A | | 0 | 25.5 | 25.0 | 22.5 | 22.5 | | 1 | 25.5 | 25.0 | 22.5 | 22.0 | | 2 | 25.5 | 25.0 | 22.5 | 22.0 | | 3 | 25.0 | 25.0 | 22.5 | 22.0 | | 4 | 24.0 | 24.5 | 22.5 | 22.0 | | 5 | 21.5 | 23.0 | 21.5 | 21.5 | | 6 | 22.5 | 21.5 | 20.5 | 20.5 | | 7 | 19.0 | 20.0 | 19.5 | 20.0 | | 8 | 17.5 | 18.0 | 19.0 | 19.0 | | 9 | 15.5 | N/A | 17.0 | 16.0 | ### 4.6 Digital IO Voltage Specifications **Table 13: Digital IO voltage specifications** | Parameters | Description | VDDIO | Min | Max | Unit | | ----------- | -------------------------------------------------------------------- | ----- | --- | ---- | ---- | | V IL\_VDDIO | Low input threshold for all GPIO and SDIO pins | 3.3 | - | 1.2 | V | | V IH\_VDDIO | High input threshold for all GPIO and SDIO pins | 3.3 | 1.7 | - | V | | V OL\_VDDIO | Low output voltage for all GPIO and SDIO pins, assuming an 8mA load | 3.3 | - | 0.25 | V | | V OH\_VDDIO | High output voltage for all GPIO and SDIO pins, assuming an 8mA load | 3.3 | 2.9 | - | V | ## 5 Module Dimensions ![Figure 11: Module dimensions](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/9kR75wARF4LNlIbYsyR8/Unknown%20image) *Figure 11: Module dimensions* ## 6 Recommended PCB Footprint ![Figure 12: PCB footprint](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/pZfhMs36LxvEvx5dBfUw/Unknown%20image) *Figure 12: PCB footprint* ## 7 Certification ### 7.1 FCC The MM8108-MF15457 has been tested and found to comply with the limits for a Class B digital device, pursuant to Part 15 of the FCC Rules. These limits are designed to provide reasonable protection against harmful interference in a residential installation. This equipment generates, uses and can radiate radio frequency energy and, if not installed and used in accordance with the instructions, may cause harmful interference to radio communications. However, there is no guarantee that interference will not occur in a particular installation. If this equipment does cause harmful interference to radio or television reception, which can be determined by turning the equipment off and on, the user is encouraged to try to correct the interference by one of the following measures: * Reorient or relocate the receiving antenna * Increase the separation between the equipment and receiver * Connect the equipment into an outlet on a circuit different from that to which the receiver is connected * Consult the dealer or an experienced radio/TV technician for help FCC caution: Any changes or modifications not expressly approved by the party responsible for compliance could void the user’s authority to operate this equipment. This device complies with Part 15 of the FCC Rules. Operation is subject to the following two conditions: (1) this device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may cause undesired operation. #### 7.1.1 FCC Radiation Exposure Statement: This equipment complies with FCC radiation exposure limits set forth for an uncontrolled environment. This equipment should be installed and operated with a minimum distance 20 cm between the radiator and your body. #### 7.1.2 Important Note To Integrators This module is intended for OEM integrators. It is only FCC authorized for the specific rule parts listed on the grant, and the host product manufacturer is responsible for compliance with any other FCC rules that apply to the host not covered by the modular transmitter grant of certification. The final host product still requires Part 15 Subpart B compliance testing with the modular transmitter installed. Additional testing and certification may be necessary when multiple modules are used. #### 7.1.3 End Product User Manual Requirement In the user manual of the end product, the end user has to be informed to keep at least 20 cm of separation with the antenna while this end product is installed and operated. The end user has to be informed that the FCC radio-frequency exposure guidelines for an uncontrolled environment can be satisfied. The end user has to also be informed that any changes or modifications not expressly approved by the manufacturer could void the user’s authority to operate this equipment. This device complies with Part 15 of FCC rules. Operation is subject to the following two conditions: (1) this device may not cause harmful interference and (2) this device must accept any interference received, including interference that may cause undesired operation. #### 7.1.4 End Product Label Requirement The end product must be labeled in a visible area with the following: **Figure 13: End product label requirement** | Contains FCC ID: 2A74O-737B5B This device complies with Part 15 of FCC rules. Operation is subject to the following two conditions: (1) this device may not cause harmful interference and (2) this device must accept any interference received, including interference that may cause undesired operation. | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ### 7.2. IC This device contains licence-exempt transmitter(s)/receiver(s) that comply with Innovation, Science and Economic Development Canada’s licence-exempt RSS(s). Operation is subject to the following two conditions: (1) This device may not cause interference. (2) This device must accept any interference, including interference that may cause undesired operation of the device. Cet appareil contient des émetteurs / récepteurs exempts de licence qui sont conformes au (x) RSS (s) exemptés de licence d’Innovation, Sciences et Développement économique Canada. L’opération est soumise aux deux conditions suivantes: (1) Cet appareil ne doit pas provoquer d'interférences. (2) Cet appareil doit accepter toute interférence, y compris les interférences susceptibles de provoquer un fonctionnement indésirable de l'appareil. This radio transmitter 29791-737B5B has been approved by Innovation, Science and Economic Development Canada to operate with the antenna types listed below, with the maximum permissible gain indicated. Antenna types not included in this list that have a gain greater than the maximum gain indicated for any type listed are strictly prohibited for use with this device. Le présent émetteur radio 29791-737B5B a été approuvé par Innovation, Sciences et Développement économique Canada pour fonctionner avec les types d'antenne énumérés ci-dessous et ayant un gain admissible maximal d'antenne. Les types d'antennes non inclus dans cette liste qui ont un gain supérieur au gain maximal indiqué pour tout type listé sont strictement interdits pour une utilisation avec cet appareil. #### 7.2.1 IC Radiation Exposure Statement: This equipment complies with IC RSS-102 radiation exposure limits set forth for an uncontrolled environment. This equipment should be installed and operated with a minimum distance of 20cm between the radiator & your body. Cet équipement est conforme aux limites d'exposition aux rayonnements IC établies pour un environnement non contrôlé. Cet équipement doit être installé et utilisé avec un minimum de 20 cm de distance entre la source de rayonnement et votre corps. #### 7.2.2 Important Note To Integrators This module is intended for OEM integrators. The OEM integrator is responsible for complying with all the rules that apply to the product into which this certified RF module is integrated. Additional testing and certification may be necessary when multiple modules are used. Any changes or modifications not expressly approved by the manufacturer could void the user's authority to operate this equipment. #### 7.2.3 End Product User Manual Requirement In the users manual of the end product, the end user has to be informed to keep at least 20 cm separation with the antenna while this end product is installed and operated. The end user has to be informed that the IC radio-frequency exposure guidelines for an uncontrolled environment can be satisfied. The end user has to also be informed that any changes or modifications not expressly approved by the manufacturer could void the user's authority to operate this equipment. Operation is subject to the following two conditions: (1) this device may not cause harmful interference (2) this device must accept any interference received, including interference that may cause undesired operation. #### 7.2.4 End Product Label Requirement The end product must be labeled in a visible area with the following: **Figure 14: End product label requirement** | Contains IC: 29791- 737B5B | | -------------------------- | The Host Model Number (HMN) must be indicated at any location on the exterior of the end product, product packaging, or product literature, which shall be available with the end product or online. ## 8 Part Numbers and Ordering Information **Table 14: Part number and ordering information** | Part Number | Packing Type | MOQ and Order Multiples | Part Size (mm) | Description | | -------------- | ------------ | ----------------------- | -------------- | ------------------------------------------------------ | | MM8108-MF15457 | Tray | 100 | 10 x 11 x 2 | IEEE 802.11ah Sub-1 GHz 1/2/4/8 MHz Wi-Fi HaLow Module | ## 9 Handling and Storage The MM8108-MF15457 module is a moisture-sensitive device rated at Moisture Sensitive Level 3 (MSL3) per IPC/JEDEC J-STD-20. After opening the moisture-sealed storage bag, modules that will be subjected to reflow solder or other high-temperature processes must be: 1. Mounted to a circuit board within 168 hours at factory conditions (≤30°C and <60% RH), OR 2. Continuously stored per IPC/JEDEC J-STD-033 Modules exposed to moisture and environmental conditions exceeding packaging and storage conditions MUST be baked before mounting, according to IPC/JEDEC J-STD-033. Failure to meet packaging and storage conditions will result in irreparable damage to modules during the solder reflow process. ## 10 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Version 4 | 30 Sep 2025 | Updated pin descriptions Updated host interface schematic designs | | Version 3 | 18 Sep 2025 | Updated formatting Added USB dongle reference design Updated power management Updated timing graphs Updated electrical specifications Updated RF specifications Added digital IO specifications | | DS101 | 28 Feb 2025 | Added power on and reset timing details Updated standby power consumption | | DS100 | 8 Jan 2025 | Initial release | Morse Micro provides this information "as is" without warranties of any kind, express or implied. No guarantee is made as to the accuracy, completeness, or suitability of this information or Morse Micro’s products for any specific purpose. Use of this information and products is at the user’s sole risk. Morse Micro products are not designed or tested for use in mission-critical systems, and should not be used in such applications. Performance specifications are based on internal testing and are believed to be reliable; however, they are not guaranteed. It is the Buyer’s responsibility to test and validate all product performance, compatibility, and compliance, both in isolation and within end applications. Morse Micro assumes no liability for the use or application of any product, circuit, or information described herein. No license or other rights—express or implied—are granted under Morse Micro’s intellectual property. This document contains proprietary information of Morse Micro and is subject to change without notice. Wi-Fi®, Wi-Fi HaLow™, and the Wi-Fi logo are trademarks of Wi-Fi Alliance. ZigBee™ and Z-Wave™ are trademarks of their respective owners. All other trademarks are the property of their respective owners. # MM8108-M20 Preliminary Datasheet v2 [Download as PDF](https://morse-micro.gitbook.io/morse-micro-docs-v.2/Y6X5n1UqJsVJ6qPvXX2V/data-sheets/mm8108-m20-preliminary-data-sheet) ## 1 Product Overview ### 1.1 Introduction Wi-Fi HaLow (pronounced “HEY-low”) is the first global Wi-Fi standard (IEEE 802.11ah) specifically designed for the Internet of Things (IoT). It’s an open-standard wireless network technology operating in the sub-1 GHz license-exempt RF bands (850-950 MHz range), so it doesn’t incur ongoing monthly costs like cellular/mobile network connections. By operating in the sub-1 GHz range, this low-power wireless protocol can connect more IoT devices over much longer distances and with significantly lower power than traditional Wi-Fi. Morse Micro, the world’s leading Wi-Fi HaLow solutions provider, offers several Wi-Fi HaLow connectivity solutions. The MM8108-M20 is a fully integrated, high-power Wi-Fi HaLow module with long-range and excellent RF performance, featuring our second-generation MM8108 Wi-Fi HaLow SoCs. The MM8108-M20-US module combines our world-leading MM8108 with a powerful external power amplifier (PA) that provides transmit amplification up to 28.5 dBm and a surface acoustic wave (SAW) filter that offers exceptional receive sensitivity tuned to the 902-928 MHz band. These innovations, combined with digital transmit filtering and pre-distortion circuits, result in an advanced transceiver design that ensures maximum performance and out-of-the-box compatibility with most global Wi-Fi HaLow regulatory environments. MM8108-M20 supports a USB 2.0 High-Speed host interface and an SDIO/SPI host interface, offering solution architects flexibility when integrating Wi-Fi HaLow connectivity into their existing solution. With a footprint of only 18.5 mm x 14 mm, the MM8108-M20 module has been designed to maximize the performance of our second-generation SoCs. MM8108-M20 supports WPA3 and all standard security features required for Wi-Fi HaLow product certifications. ### 1.2 Features * Single-stream maximum PHY rate of 43.3 Mbps at 8 MHz bandwidth * Radio supporting worldwide Sub-1 GHz frequency bands * Frequency range: 902-928 MHz * Channel bandwidth options of 1/2/4/8 MHz * High power PA with a maximum 28.5 dBm (700 mW) output power * Low-power receiver with integrated LNA, NF < 4 dB * 802.11ah OFDM PHY with Wi-Fi Alliance Wi-Fi HaLow certification * BPSK & QPSK, 16-QAM, 64-QAM and 256-QAM Modulation * Automatic frequency and gain control * Packet detection and channel equalization * Forward Error Correction (FEC) coding and decoding * Modulation and Coding Scheme (MCS) levels 0-10 * 1 MHz duplicate mode * Optional traveling pilots * 802.11ah MAC with Wi-Fi Alliance Wi-Fi HaLow certification * Support for Station (STA) and Access Point (AP) roles * Listen-Before-Talk (LBT) access with energy detection * 802.11 power save * 802.11 fragmentation and defragmentation * Power-Saving Target Wake Time (TWT) support for extended battery life * Automatic and manual MCS rate selection * On-chip software stack assisting with host offload of Wi-Fi connection management * USB 2.0 High-Speed compliant device interface * Integrated USB 2.0 PHY and device interface supporting High-Speed mode at 480 Mbps * SDIO 2.0 compliant device interface * SDIO 2.0 High-Speed at 50 MHz max for 200 Mbps * Support for 1-bit and 4-bit data mode * Support for SPI mode operation at up to 80 MHz for 80 Mbps * Power Management Unit (PMU) supporting various modes of operation * A single 3.0-3.6 V supply for integrated DC-DCs and LDOs * A dedicated 5.0 V supply for the PA * Multiple low-power modes to reduce average power consumption * Broad spectrum of security features * Wi-Fi layer security, including Wi-Fi Protected Access version 3 (WPA3), Protected Management Frames (PMF), and Opportunistic Wireless Encryption (OWE) * Hardware support for Advanced Encryption Standard (AES) and Secure Hash Algorithm version 2 (SHA-2) functions (SHA-256, SHA-384, SHA-512) ### 1.3 Applications Ideally suited for Internet of Things (IoT) and Machine-to-Machine (M2M) applications such as: * Surveillance cameras and sensors * Cloud connectivity * Low-power sensor networks * Building automation systems * Asset tracking and management * Machine performance monitors and sensors * Building access control and security * Drone video and navigation communications * Connected toys and games * Rural internet access * Agricultural networks * Utility smart meter and intelligent grid * Proximity sensors * Industrial automation controls * Smart home automation * EV car chargers * Appliances * Construction site connectivity * Smart signs and kiosks * Retail point-of-sale terminals * Vehicle-to-vehicle communications * IP sensor networks * Biometric IDs and keypads * Warehouse connectivity * Intelligent lighting controls * BT/ZigBee™/Z-Wave™ to Wi-Fi HaLow gateways * Wi-Fi to Wi-Fi HaLow bridges * Wi-Fi HaLow client adapters/dongles * Smart city networks ## 2 Pin Descriptions The MM8108-M20 modules feature 51 pins, which are described in this section. The following illustration shows the top view of the module pins. ### 2.1 Default Pin Layout ![Figure 1: Default pin layout diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/p8icvA6houaZ21FqpqWV/Unknown%20image) *Figure 1: Default pin layout diagram* ### 2.2 Pin Descriptions **Table 1: Pin description** | Pin | Default Function Pin Name | Default Function Type | Default Function Description | Alternate Function Pin Name | | --- | ------------------------- | --------------------- | ---------------------------------------- | --------------------------- | | 1 | GND | Ground | Ground | | | 2 | GND | Ground | Ground | | | 3 | GPIO1 | Digital I/O | Programmable digital I/O | | | 4 | GPIO0 | Digital I/O | Programmable digital I/O | | | 5 | GPIO6 | Digital I/O | Programmable digital I/O | | | 6 | GPIO7 | Digital I/O | Programmable digital I/O | | | 7 | GPIO8 | Digital I/O | Programmable digital I/O | | | 8 | GPIO9 | Digital I/O | Programmable digital I/O | | | 9 | RESET\_N \[2] | Analog | Asynchronous chip reset (active low) | | | 10 | WAKE \[2] | Analog | External wake from Deep Sleep and Snooze | | | 11 | JTAG\_TMS | Digital I/O | JTAG Mode Select | | | 12 | JTAG\_TCK | Digital I/O | JTAG Clock | | | 13 | JTAG\_TDO | Digital I/O | JTAG Data Out | | | 14 | GND | Ground | Ground | | | 15 | JTAG\_TDI | Digital I/O | JTAG Data In | | | 16 | VDD | Supply | 3.3V VDD Supply | | | 17 | SDIO\_D0 \[1] | Digital I/O | SDIO Data line | SPI\_MISO | | 18 | SDIO\_D1 \[1] | Digital I/O | SDIO Data line | SPI\_INT | | 19 | SDIO\_D3 \[1] | Digital I/O | SDIO Data line | SPI\_CS | | 20 | SDIO\_D2 \[1]\[3] | Digital I/O | SDIO Data line | | | 21 | SDIO\_CMD \[1] | Digital I/O | SDIO Command line | SPI\_MOSI | | 22 | SDIO\_CLK | Digital I/O | SDIO Clock input | SPI\_SCK | | 23 | GPIO5 | Digital I/O | Programmable digital I/O | | | 24 | GND | Ground | Ground | | | 25 | GND | Ground | Ground | | | 26 | GPIO4 | Digital I/O | Programmable digital I/O | | | 27 | GPIO3 | Digital I/O | Programmable digital I/O | | | 28 | VDDIO | Supply | Host supply for digital I/O | | | 29 | GND | Ground | Ground | | | 30 | VDD\_TX | Supply | 3.3 V VDD-TX Supply | | | 31 | VDD\_USB | Supply | USB Supply | | | 32 | GND | Ground | Ground | | | 33 | USB\_DN | I/O | USB DN line | | | 34 | USB\_DP | I/O | USB DP line | | | 35 | GND | Ground | Ground | | | 36 | VDD\_EPA | Supply | 5.0 V VDD-EPA Supply | | | 37 | VDD\_EPA | Supply | 5.0 V VDD-EPA Supply | | | 38 | GND | Ground | Ground | | | 39 | GND | Ground | Ground | | | 40 | GND | Ground | Ground | | | 41 | GND | Ground | Ground | | | 42 | GND | Ground | Ground | | | 43 | GND | Ground | Ground | | | 44 | GPIO2 | Digital I/O | Programmable digital I/O | | | 45 | GND | Ground | Ground | | | 46 | GND | Ground | Ground | | | 47 | ANT | Analog | Antenna | | | 48 | GND | Ground | Thermal Ground | | | 49 | GND | Ground | Thermal Ground | | | 50 | GND | Ground | Thermal Ground | | | 51 | GND | Ground | Thermal Ground | | \[1] All SDIO bus pins, except SDIO\_CLK, should be pulled up with a 10 kΩ to 100 kΩ resistor, as per the SDIO standard. \[2] Supplied from the VDD domain. The VDDIO domain drives other digital pins. \[3] Pull up SDIO\_D2 when in SPI or SDIO mode ## 3 Functional Description The following sections describe the module's functions. ### 3.1 Block Diagram ![Figure 2: Functional block diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/o74X09sT3xC6yMQDi6vR/Unknown%20image) *Figure 2: Functional block diagram* ### 3.2 Power Supply Requirements Module power is derived from a 3.0 to 3.6 V supply on pins VDD and VDD\_TX, and a 5.0 V supply on pins VDD\_EPA. VDD\_EPA should be supplied from a clean, filtered, and regulated power supply that is not shared with other components. VDDIO sets the module's IO voltage. It has an input voltage range of 2.25 V to 3.6 V and should be connected to the same power supply as the host MCU. There are no strict requirements for power-up sequencing. ### 3.3 USB Host Interface A schematic diagram detailing the USB host interface circuit is shown below: ![Figure 3: USB host interface circuit](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/f4dEg8w2MZxOacXKt9py/Unknown%20image) *Figure 3: USB host interface circuit* ### 3.4 SDIO Host Interface When selecting a host to interface with the module via the SDIO interface, ensure the host supports SDIO 2.0 and supports SDIO clock speeds up to 50 MHz. Slower clock speeds will impact the maximum achievable throughput. The SDIO data and command lines should be pulled up with resistors ranging from 10 kΩ to 100 kΩ, per the SDIO 2.0 specification. For proper operation and to take advantage of the module’s power-saving features, connect RESET\_N and WAKE to standard digital outputs (CMOS logic levels). The BUSY signal should be connected to a digital input (also CMOS logic levels). Do not use open-collector or open-drain circuits, as they will cause incorrect behavior. In applications where the module must always be on, and power-saving features cannot be used, such as access points, the WAKE pin can be left unconnected, reducing the need for GPIOs on the host processor to only one. A schematic diagram detailing the SDIO host interface circuit using the module’s power-saving features is shown below: ![Figure 4: SDIO host interface circuit using power-saving features](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/dXOECa6AdBE5LW6GZWBx/Unknown%20image) *Figure 4: SDIO host interface circuit using power-saving features* A schematic diagram detailing the SDIO host interface circuit for always-on applications is shown below: ![Figure 5: SDIO host interface circuit for always-on applications](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/i4iRuhy261iW60L81y0Y/Unknown%20image) *Figure 5: SDIO host interface circuit for always-on applications* ### 3.5 SPI Host Interface When selecting a host to interface with the module via the SPI interface, consider the following recommendations to achieve the best throughput: * The host must support level-triggered interrupts. * The host must support full-duplex SPI mode. * The host must support DMA-backed transactions on the SPI bus. Standard SPI can achieve up to 25 Mbps at 50 MHz, but without DMA support, this will be significantly reduced. For example, an SPI interface with an 8-byte buffer per transaction might achieve only 2 Mbps on the SPI bus. For proper operation and to take advantage of the module’s power-saving features, connect RESET and WAKE to standard digital outputs (CMOS logic levels). The BUSY signal should be connected to a digital input (also CMOS logic levels). Do not use open-collector or open-drain circuits, as they will cause incorrect behavior. In applications where the module must always be on and power-saving features cannot be used, such as access points, the WAKE pin can be left unconnected, reducing the need for GPIOs on the host processor to only one. A schematic diagram detailing the SPI host interface circuit using the module’s power-saving features is shown below: ![Figure 6: SPI host interface circuit using power-saving features](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/x8DKc6u0oYslZEeGElai/Unknown%20image) *Figure 6: SPI host interface circuit using power-saving features* A schematic diagram detailing the SPI host interface circuit for always-on applications is shown below: ![Figure 7: SPI host interface circuit for always-on applications](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/mgutnB4lSURfxF4Gx1TX/Unknown%20image) *Figure 7: SPI host interface circuit for always-on applications* ### 3.6 Boot/Reset Sequencing #### 3.6.1 Boot Timing ![Figure 8: Powering on and reset timing diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/QjFi1K3mg99c7ohu7Oqd/Unknown%20image) *Figure 8: Powering on and reset timing diagram* **Table 2: Boot timing overview** | Parameters | Description | Min | Max | Unit | | ---------- | --------------------------------------------------------------- | --- | --- | ---- | | V IL\_nRST | Reset threshold | 450 | | mV | | t 0 | Time between VDD brought up (3.3V) and RESET\_N being activated | 50 | | μs | | t B | Boot Time | | 10 | ms | #### 3.6.2 Reset Timing ![Figure 9: Powering on and reset timing diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/VUNsdVfC6FPxriTGClQO/Unknown%20image) *Figure 9: Powering on and reset timing diagram* **Table 3: Reset timing overview** | Parameters | Description | Min | Max | Unit | | ---------- | --------------------------------------------------------------- | ---- | --- | ---- | | V IL\_nRST | Reset threshold | 450 | | mV | | t 1 | Duration of RESET\_N signal level < VIL\_nRST to reset the chip | 1000 | | μs | | t B | Boot Time | | 10 | ms | ## 4 Electrical Characteristics ### 4.1 Absolute Maximum Ratings Stress beyond absolute maximum ratings may cause permanent damage to the module. Operation is guaranteed only within the recommended operating conditions. Operation of the device outside the recommended conditions may result in reduced lifetime and reliability issues, even if the absolute maximum ratings are not exceeded. **Table 4: Absolute maximum and minimum voltage ratings** | Parameter | Min | Max | Unit | | ------------------- | ---- | ---- | ---- | | VDD voltage | -0.3 | 3.6 | V | | VDD\_TX voltage | -0.3 | 3.6 | V | | VDD\_EPA voltage | -0.3 | 5.25 | V | | RESET\_N/WAKE | -0.3 | 3.6 | V | | VDDIO | -0.3 | 3.6 | V | | Analog/RF pin | -0.3 | 1.2 | V | | Storage temperature | -40 | 125 | °C | | RF input power (CW) | - | 6 | dBm | ### 4.2 ESD Immunity **Table 5: ESD immunity specifications** | Parameter | Parameter | Parameter | Min | Max | Unit | | ----------------------------------------- | ----------------------------------------------------- | ------------------------ | ------ | ----- | ---- | | Electrostatic discharge (ESD) performance | Human body model (HBM), per ANSI / ESDA / JEDEC JS001 | RF Input | -1,000 | 1,000 | V | | Electrostatic discharge (ESD) performance | Human body model (HBM), per ANSI / ESDA / JEDEC JS001 | All pins except RF Input | -2000 | 2000 | V | | Electrostatic discharge (ESD) performance | Charged device model (CDM), per JESD22-C101 | All pins | -500 | 500 | V | ### 4.3 Recommended Operating Conditions **Table 6: Recommended operating conditions** | Parameter | Min | Typ | Max | Unit | | ------------------- | ---- | --- | ---- | ---- | | Ambient temperature | -40 | | 85 | °C | | Storage temperature | -40 | | 125 | °C | | VDD | 3.0 | 3.3 | 3.6 | V | | VDD\_TX | 3.0 | 3.3 | 3.6 | V | | VDD\_EPA | 4.85 | 5.0 | 5.25 | V | | VDDI O | 2.25 | 3.3 | 3.6 | V | ### 4.4 Power Consumption #### 4.4.1 Active Transmit Current Consumption **Table 7: Transmit current consumption for VDD, VDD\_TX, and VDD\_EPA** | MCS Index | Current consumption (mA) per BW at V DD 100% duty cycle, T A =25 o C, V DD = V DDIO = V DD\_TX =3.3 V , V DD\_EPA =5.0 V 1 MHz | Current consumption (mA) per BW at V DD 100% duty cycle, T A =25 o C, V DD = V DDIO = V DD\_TX =3.3 V , V DD\_EPA =5.0 V 2 MHz | Current consumption (mA) per BW at V DD 100% duty cycle, T A =25 o C, V DD = V DDIO = V DD\_TX =3.3 V , V DD\_EPA =5.0 V 4 MHz | Current consumption (mA) per BW at V DD 100% duty cycle, T A =25 o C, V DD = V DDIO = V DD\_TX =3.3 V , V DD\_EPA =5.0 V 8 MHz | Current consumption (mA) per BW at V DD\_TX 100% duty cycle, T A =25 o C, V DD = V DDIO = V DD\_TX =3.3 V , V DD\_EPA =5.0 V 1 MHz | Current consumption (mA) per BW at V DD\_TX 100% duty cycle, T A =25 o C, V DD = V DDIO = V DD\_TX =3.3 V , V DD\_EPA =5.0 V 2 MHz | Current consumption (mA) per BW at V DD\_TX 100% duty cycle, T A =25 o C, V DD = V DDIO = V DD\_TX =3.3 V , V DD\_EPA =5.0 V 4 MHz | Current consumption (mA) per BW at V DD\_TX 100% duty cycle, T A =25 o C, V DD = V DDIO = V DD\_TX =3.3 V , V DD\_EPA =5.0 V 8 MHz | Current consumption (mA) per BW at V DD\_EPA 100% duty cycle, T A =25 o C, V DD = V DDIO = V DD\_TX =3.3 V , V DD\_EPA =5.0 V 1 MHz | Current consumption (mA) per BW at V DD\_EPA 100% duty cycle, T A =25 o C, V DD = V DDIO = V DD\_TX =3.3 V , V DD\_EPA =5.0 V 2 MHz | Current consumption (mA) per BW at V DD\_EPA 100% duty cycle, T A =25 o C, V DD = V DDIO = V DD\_TX =3.3 V , V DD\_EPA =5.0 V 4 MHz | Current consumption (mA) per BW at V DD\_EPA 100% duty cycle, T A =25 o C, V DD = V DDIO = V DD\_TX =3.3 V , V DD\_EPA =5.0 V 8 MHz | | --------- | ------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | 0 | 28 | 30 | 35 | 45 | 9 | 8 | 8 | 8 | 500 | 465 | 450 | 445 | | 7 | 26 | 29 | 34 | 43 | 9 | 8 | 8 | 8 | 280 | 285 | 295 | 295 | | 9 | 26 | N/A | 34 | 43 | 9 | N/A | 8 | 8 | 240 | N/A | 260 | 260 | #### 4.4.2 Active Receive Current Consumption **Table 8: Active receive current consumption** | MCS Index | Current consumption (mA) per BW at (V DD + V DD\_TX + V DDIO + V DD\_EPA ) 100% duty cycle, T A =25 o C, V DD =V DD\_TX = V DDIO =3.3 V, V DD\_EPA =5.0 V, Rx signal at -70 dBm 1 MHz | Current consumption (mA) per BW at (V DD + V DD\_TX + V DDIO + V DD\_EPA ) 100% duty cycle, T A =25 o C, V DD =V DD\_TX = V DDIO =3.3 V, V DD\_EPA =5.0 V, Rx signal at -70 dBm 2 MHz | Current consumption (mA) per BW at (V DD + V DD\_TX + V DDIO + V DD\_EPA ) 100% duty cycle, T A =25 o C, V DD =V DD\_TX = V DDIO =3.3 V, V DD\_EPA =5.0 V, Rx signal at -70 dBm 4 MHz | Current consumption (mA) per BW at (V DD + V DD\_TX + V DDIO + V DD\_EPA ) 100% duty cycle, T A =25 o C, V DD =V DD\_TX = V DDIO =3.3 V, V DD\_EPA =5.0 V, Rx signal at -70 dBm 8 MHz | | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 0 | 18 | 19 | 23 | 31 | | Max | 18 (MCS9) | 20 (MCS8) | 24 (MCS9) | 34 (MCS9) | #### 4.4.3 Listen Receive Current Consumption **Table 9: Listen receive current consumption** | Current consumption (mA) per BW at (V DD + V DD\_TX + V DDIO +V DD\_EPA ) 100% duty cycle, T A =25 o C, V DD =V DD\_TX = V DDIO =3.3 V, V DD\_EPA =5.0 V, Rx signal at -70 dBm 1 MHz | Current consumption (mA) per BW at (V DD + V DD\_TX + V DDIO +V DD\_EPA ) 100% duty cycle, T A =25 o C, V DD =V DD\_TX = V DDIO =3.3 V, V DD\_EPA =5.0 V, Rx signal at -70 dBm 2 MHz | Current consumption (mA) per BW at (V DD + V DD\_TX + V DDIO +V DD\_EPA ) 100% duty cycle, T A =25 o C, V DD =V DD\_TX = V DDIO =3.3 V, V DD\_EPA =5.0 V, Rx signal at -70 dBm 4 MHz | Current consumption (mA) per BW at (V DD + V DD\_TX + V DDIO +V DD\_EPA ) 100% duty cycle, T A =25 o C, V DD =V DD\_TX = V DDIO =3.3 V, V DD\_EPA =5.0 V, Rx signal at -70 dBm 8 MHz | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | 17 | 18 | 21 | 28 | #### 4.4.4 Low Power Current Consumption **Table 10: Low power current consumption** | Power mode | Current consumption T A =25 o C, V VDD = V DDIO =3.3 V, V DD\_EPA =5.0 V V DD + V DD\_TX | Current consumption T A =25 o C, V VDD = V DDIO =3.3 V, V DD\_EPA =5.0 V V DD\_EPA | Current consumption T A =25 o C, V VDD = V DDIO =3.3 V, V DD\_EPA =5.0 V V DDIO | Current consumption T A =25 o C, V VDD = V DDIO =3.3 V, V DD\_EPA =5.0 V Unit | | ---------- | ---------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | | Hibernate | <1 | 1 | <1 | μA | | Deep Sleep | <2 | 1 | <1 | μA | | Sleep 1 | <20 | 1 | <1 | μA | | USB Sleep | <500 | 1 | <1 | μA | #### 4.4.5 Standby Current Consumption (using SDIO/SPI Host Interface) **Table 11: Standby current consumption** | Mode | T A =25 o C, V DD = V DDIO =3.3 V, V DD\_EPA =5.0 V, BW=2 MHz, RTC=RTC\_XTAL Sleep mode | T A =25 o C, V DD = V DDIO =3.3 V, V DD\_EPA =5.0 V, BW=2 MHz, RTC=RTC\_XTAL Beacon | V DD + V DD\_TX | V DD\_EPA | V DDIO | Unit | | ------ | --------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | --------------- | --------- | ------ | ---- | | DTIM3 | 1 | Long | 200 | <1 | 2 | μA | | DTIM10 | 1 | Long | 80 | <1 | 2 | μA | | DTIM40 | 1 | Long | 40 | <1 | 1 | μA | | DTIM3 | 1 | Short | 150 | <1 | 2 | μA | | DTIM10 | 1 | Short | 65 | <1 | 2 | μA | | DTIM40 | 1 | Short | 35 | <1 | 1 | μA | The DTIM (Delivery Traffic Indication Message) number (DTIMx) indicates how often a Wi-Fi HaLow station in power-saving Sleep mode should wake to receive traffic from the access point. It is expressed as a multiple of beacon intervals (102.4 ms). For example, DTIM1 indicates that the station should wake up every 102.4 ms, while DTIM40 configures the station to wake up every 4.1 seconds. Configuring DTIM is a complex compromise between power consumption and latency. Increasing the DTIM will reduce the average power consumption, as the station spends a greater proportion of time in Sleep mode, which consumes significantly less power than in Listen mode. However, since the station cannot receive traffic in Sleep mode, increasing DTIM also increases latency. DTIM settings should be optimized for the use case. ### 4.5 RF Specifications #### 4.5.1 Frequency Range The module operates in the 902 to 928 MHz frequency range. #### 4.5.2 Receiver Sensitivities for 10% packet error rate, 1000-byte packets. Conditions are VDD=3.3 V, VDD\_TX=3.3 V, VDD\_EPA=5.0 V, Ambient Temperature=25oC **Table 12: Rate vs receiver sensitivity** | MCS index | Modulation scheme | Coding rate | PHY rate (Mbps) per BW 1 MHz | PHY rate (Mbps) per BW 2 MHz | PHY rate (Mbps) per BW 4 MHz | PHY rate (Mbps) per BW 8 MHz | Typical receive sensitivity (dBm) per BW 1 MHz | Typical receive sensitivity (dBm) per BW 2 MHz | Typical receive sensitivity (dBm) per BW 4 MHz | Typical receive sensitivity (dBm) per BW 8 MHz | | --------- | ----------------- | ----------- | ---------------------------- | ---------------------------- | ---------------------------- | ---------------------------- | ---------------------------------------------- | ---------------------------------------------- | ---------------------------------------------- | ---------------------------------------------- | | 10 | BPSK | 1/2 x 2 | 0.1 | N/A | N/A | N/A | -107 | N/A | N/A | N/A | | 0 | BPSK | 1/2 | 0.3 | 0.7 | 1.5 | 3.3 | -106 | -102 | -101 | -97 | | 1 | QPSK | 1/2 | 0.7 | 1.4 | 3.0 | 6.5 | -104 | -100 | -99 | -95 | | 2 | QPSK | 3/4 | 1.0 | 2.2 | 4.5 | 9.8 | -101 | -98 | -96 | -92 | | 3 | 16-QAM | 1/2 | 1.3 | 2.9 | 6.0 | 13 | -98 | -95 | -93 | -89 | | 4 | 16-QAM | 3/4 | 2.0 | 4.3 | 9.0 | 20 | -95 | -92 | -90 | -86 | | 5 | 64-QAM | 2/3 | 2.7 | 5.8 | 12 | 26 | -91 | -88 | -85 | -82 | | 6 | 64-QAM | 3/4 | 3.0 | 6.5 | 14 | 29 | -89 | -86 | -84 | -80 | | 7 | 64-QAM | 5/6 | 3.3 | 7.2 | 15 | 33 | -88 | -85 | -83 | -79 | | 8 | 256-QAM | 3/4 | 4.0 | 8.9 | 18 | 39 | -83 | -81 | -78 | -75 | | 9 | 256-QAM | 5/6 | 4.4 | N/A | 20 | 43 | -82 | N/A | -77 | -73 | #### 4.5.3 Transmitter Note: The following transmit power levels are for IEEE compliance for 802.11ah. They do not consider any backoffs needed for regional spectrum compliance (e.g., FCC, IC). The restricted band-edge in regulatory regions will limit TX power in edge channels. **Table 13: Mean TX output power** | MCS index | Power output (dBm) at the module ANT pin per BW T A =25 o C, V DD = V DDIO =3.3 V, V DD\_EPA =5.0 V, IEEE-compliant with 1.5 dB SEM margin 1 MHz | Power output (dBm) at the module ANT pin per BW T A =25 o C, V DD = V DDIO =3.3 V, V DD\_EPA =5.0 V, IEEE-compliant with 1.5 dB SEM margin 2 MHz | Power output (dBm) at the module ANT pin per BW T A =25 o C, V DD = V DDIO =3.3 V, V DD\_EPA =5.0 V, IEEE-compliant with 1.5 dB SEM margin 4 MHz | Power output (dBm) at the module ANT pin per BW T A =25 o C, V DD = V DDIO =3.3 V, V DD\_EPA =5.0 V, IEEE-compliant with 1.5 dB SEM margin 8 MHz | | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ | | 10 | 29.5 | N/A | N/A | N/A | | 0 | 29.0 | 28.5 | 28.5 | 28.0 | | 1 | 29.0 | 28.5 | 28.5 | 28.0 | | 2 | 29.0 | 28.5 | 28.0 | 28.0 | | 3 | 28.0 | 28.0 | 28.0 | 28.0 | | 4 | 27.5 | 27.5 | 27.5 | 27.5 | | 5 | 25.0 | 26.0 | 26.5 | 27.0 | | 6 | 24.5 | 25.5 | 26.0 | 26.0 | | 7 | 24.5 | 24.5 | 25.0 | 25.0 | | 8 | 23.0 | 23.5 | 24.0 | 24.0 | | 9 | 22.5 | N/A | 23.5 | 23.5 | ### 4.6 Digital IO Voltage Specifications **Table 14: Digital IO voltage specifications** | Parameters | Description | VDDIO | Min | Max | Unit | | ----------- | --------------------------------------------------------------------- | ----- | --- | ---- | ---- | | V IL\_VDDIO | Low input threshold for all GPIO and SDIO pins | 3.3 | - | 1.2 | V | | V IH\_VDDIO | High input threshold for all GPIO and SDIO pins | 3.3 | 1.7 | - | V | | V OL\_VDDIO | Low output voltage for all GPIO and SDIO pins, assuming an 8 mA load | 3.3 | - | 0.25 | V | | V OH\_VDDIO | High output voltage for all GPIO and SDIO pins, assuming an 8 mA load | 3.3 | 2.9 | - | V | ## 5 Module Dimensions ![Figure 10: Module dimensions](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/8o6yrDn9MzQZ3YZIKkmq/Unknown%20image) *Figure 10: Module dimensions* ## 6 Recommended PCB Footprint ![Figure 11: PCB footprint](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/kXBrmtdWfaM7GHuhpmkQ/Unknown%20image) *Figure 11: PCB footprint* ## 7 Certification ### 7.1 FCC for MM8108-M20 The MM8108-M20 has been tested and found to comply with the Class B digital device limits pursuant to Part 15 of the FCC Rules. These limits are designed to provide reasonable protection against harmful interference in a residential installation. This equipment generates, uses, and can radiate radio-frequency energy, and, if not installed and used in accordance with the instructions, may cause harmful interference to radio communications. However, there is no guarantee that interference will not occur in a particular installation. If this equipment does cause harmful interference to radio or television reception, which can be determined by turning the equipment off and on, the user is encouraged to try to correct the interference by one of the following measures: * Reorient or relocate the receiving antenna * Increase the separation between the equipment and receiver * Connect the equipment into an outlet on a circuit different from that to which the receiver is connected * Consult the dealer or an experienced radio/TV technician for help FCC caution: Any changes or modifications not expressly approved by the party responsible for compliance could void the user’s authority to operate this equipment. This device complies with Part 15 of the FCC Rules. Operation is subject to the following two conditions: (1) this device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may cause undesired operation. #### 7.1.1 FCC Radiation Exposure Statement: This equipment complies with FCC radiation exposure limits set forth for an uncontrolled environment. This equipment should be installed and operated with a minimum distance 20 cm between the radiator and your body. #### 7.1.2 Important Note To Integrators This module has been tested and found to comply with the following requirements for Modular Approval: * Part 15.247 - Operation within the bands 902-928 MHz #### 7.1.3 End Product User Manual Requirement In the end product, the antenna(s) used with this transmitter must be installed to provide a separation distance of at least 20cm from all persons and must not be co-located or operated in conjunction with any other antenna or transmitter except in accordance with multi-transmitter product procedures. Users and installers must be provided with antenna installation instructions and transmitter operating conditions to satisfy the RF exposure compliance. #### 7.1.4 Antennas This radio transmitter has been approved by the FCC and ISED to operate with the antenna types listed below, with the maximum permissible gain indicated. Antenna types not included in this list, having a gain greater than the maximum gain indicated for that type, are strictly prohibited for use with this device. #### 7.1.5 Antennes Cet émetteur radio a été approuvé par la FCC et ISED pour fonctionner avec les types d'antennes répertoriés ci-dessous avec le gain maximal autorisé indiqué. Les types d'antennes non inclus dans cette liste, ayant un gain supérieur au gain maximum indiqué pour ce type, sont strictement interdits pour une utilisation avec cet appareil. **Table 15: Listen receive current consumption** | Radio | Antenna Type | Frequency (MHz) | Antenna Gain (dBi) | | -------- | -------------- | --------------- | ------------------ | | 802.11ah | Dipole Antenna | 902-928 | 1 | #### 7.1.6 End Product Label Requirement The end product must be labeled in a visible area with the following: **Figure 12: End product label requirement** | Contains FCC ID: 2A74O-ED502A | | ----------------------------- | #### 7.1.7 Test Modes This device uses various test-mode programs for setup, which operate separately from production firmware. Host integrators should contact the grantee for assistance with the test modes required for module/host compliance testing. #### 7.1.8 Additional Testing, Part 15 Subpart B Disclaimer The modular transmitter is only FCC authorized for the specific rule parts (i.e. FCC transmitter rules) listed on the grant, and the host product manufacturer is responsible for compliance with any other FCC rules that apply to the host not covered by the modular transmitter grant of certification. The final host product still requires Part 15 Subpart B compliance testing with the modular transmitter installed. #### 7.1.9 EMI Considerations Note that a host manufacturer is recommended to use the KDB996369 D04 Module Integration Guide, which recommends "best practice" RF design engineering testing and evaluation in case non-linear interactions generate additional non-compliant limits due to module placement relative to host components or properties. For standalone mode, reference the guidance in KDB996369 D04 Module Integration Guide, and for simultaneous mode, see KDB996369 D02 Module Q\&A Question 12, which permits the host manufacturer to confirm compliance. #### 7.1.10 Making Changes Only Grantees may make permissive changes. If the module will be used differently from the granted conditions, please contact us to ensure modifications will not affect compliance. #### 7.1.11 Antenna Trace Design The modular transmitter is configured for monostatic operation, requiring only a single RF I/O pin for full-duplex communication. The output must be routed to the antenna via 50 Ω microstrip or stripline on the OEM PCB. No coupling capacitor is required, given that the RF pin is AC-coupled internally. ### 7.2. IC for MM8108-M20 This device contains license-exempt transmitter(s) / receiver(s) that comply with Innovation, Science and Economic Development Canada’s license-exempt RSS(s). Operation is subject to the following two conditions: (1) This device may not cause interference, and (2) this device must accept any interference, including interference that may cause undesired operation of the device. L’émetteur/récepteur exempt de licence contenu dans le présent appareil est conforme aux CNR d’Innovation, Sciences et Développement économique Canada applicables aux appareils radio exempts de licence. L’exploitation est autorisée aux. Deux conditions suivantes: (1) L'appareil ne doit pas produire de brouillage, et (2) l'utilisateur de l'appareil doit accepter tout brouillage radioelectrique subi, meme si le brouillage est susceptible d'en compromettre le fonctionnement. Caution: Exposure to Radio Frequency Radiation 1. To comply with the Canadian RF exposure compliance requirements, this device and its antenna must not be co-located or operating in conjunction with any other antenna or transmitter 2. To comply with RSS 102 RF exposure compliance requirements, a separation distance of at least 20 cm must be maintained between the antenna of this device and all persons Attention: exposition au rayonnement radiofréquence: 1. Pour se conformer aux exigences de conformité RF canadienne l'exposition, cet appareil et son antenne ne doivent pas être co-localisés ou fonctionnant en conjonction avec une autre antenne ou transmetteur. 2. Pour se conformer aux exigences de conformité CNR 102 RF exposition, une distance de séparation d'au moins 20 cm doit être maintenue entre l'antenne de cet appareil et toutes les personnes #### 7.2.1 Antennas This radio transmitter has been approved by the ISED to operate with the antenna types listed below with the maximum permissible gain indicated. Antenna types not included in this list, having a gain greater than the maximum gain indicated for that type, are strictly prohibited for use with this device. #### 7.2.2 Antennes Cet émetteur radio a été approuvé par la ISED pour fonctionner avec les types d'antennes répertoriés ci-dessous avec le gain maximal autorisé indiqué. Les types d'antennes non inclus dans cette liste, ayant un gain supérieur au gain maximum indiqué pour ce type, sont strictement interdits pour une utilisation avec cet appareil. **Table 16: Listen receive current consumption** | Radio | Antenna Type | Frequency (MHz) | Antenna Gain (dBi) | | -------- | -------------- | --------------- | ------------------ | | 802.11ah | Dipole Antenna | 902-928 | 1 | #### 7.2.3 Required End Product Labeling Any device incorporating this module must include an external, visible, permanent marking or label which states: **Figure 13: End product label requirement** | Contains IC: 29791-ED502A | | ------------------------- | #### 7.2.4 Obligation D'étiquetage Du Produit Final Tout dispositif intégrant ce module doit comporter un externe, visible, marquage permanent ou une étiquette qui dit: **Figure 14: End product label requirement** | Contient IC: 29791-ED502A | | ------------------------- | #### 7.2.5 RF Exposure Considerations In the end product, the antenna(s) used with this transmitter must be installed to provide a separation distance of at least 20cm from all persons and must not be co-located or operated in conjunction with any other antenna or transmitter except in accordance with multi-transmitter product procedures. Users and installers must be provided with antenna installation instructions and transmitter operating conditions for satisfying the RF exposure compliance. ## 8 Part Numbers and Ordering Information **Table 17: Part number and ordering information** | Part Number | Packing Type | MOQ and Order Multiples | Part Size (mm) | Description | | ------------- | ------------ | ----------------------- | --------------- | ----------------------------------------------------------------------------------------- | | MM8108-M20-US | Tray | 100 | 18.5 x 14 x 3.0 | High Power Wi-Fi HaLow / IEEE 802.11ah Sub-1 GHz 1/2/4/8 MHz Module for the US and Canada | ## 9 Handling and Storage The modules are moisture-sensitive devices rated at Moisture Sensitive Level 3 (MSL3) per IPC/JEDEC J-STD-20. After opening the moisture-sealed storage bag, modules that will be subjected to reflow solder or other high-temperature processes must be: 1. Mounted to a circuit board within 168 hours at factory conditions (≤30°C and <60% RH), OR 2. Continuously stored per IPC/JEDEC J-STD-033 Modules exposed to moisture and environmental conditions exceeding packaging and storage conditions MUST be baked before mounting, according to IPC/JEDEC J-STD-033. Failure to meet packaging and storage conditions will result in irreparable damage to modules during the solder reflow process. ## 10 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | --------------------- | | Version 2 | 10 Apr 2026 | Updated Module Height | | Version 1 | 27 Mar 2026 | Preliminary Release | Morse Micro provides this information "as is" without warranties of any kind, express or implied. No guarantee is made as to the accuracy, completeness, or suitability of this information or Morse Micro’s products for any specific purpose. Use of this information and products is at the user’s sole risk. Morse Micro products are not designed or tested for use in mission-critical systems, and should not be used in such applications. Performance specifications are based on internal testing and are believed to be reliable; however, they are not guaranteed. It is the Buyer’s responsibility to test and validate all product performance, compatibility, and compliance, both in isolation and within end applications. Morse Micro assumes no liability for the use or application of any product, circuit, or information described herein. No license or other rights—express or implied—are granted under Morse Micro’s intellectual property. This document contains proprietary information of Morse Micro and is subject to change without notice. Wi-Fi®, Wi-Fi HaLow™, and the Wi-Fi logo are trademarks of Wi-Fi Alliance. ZigBee™ and Z-Wave™ are trademarks of their respective owners. All other trademarks are the property of their respective owners. # MM6108-MF08651-US Datasheet DS102 [Download as PDF](https://www.morsemicro.com/resources/datasheets/modules/MM6108-MF08651-US_Data_Sheet.pdf) ## 1 Product Overview ### 1.1 Introduction Morse Micro provides a complete Wi-Fi HaLow connectivity solution. The MM6108-MF08651-US is a fully integrated Wi-Fi HaLow® module featuring the MM6108 Wi-Fi HaLow SoC. It offers long-range, low-power consumption, and superior RF performance. The MM6108-MF08651-US module is designed in compliance with the IEEE 802.11ah standard. It supports data rates up to 32.5 Mbps and has programmable operation between 902 MHz and 928 MHz. This module includes an ultra-long-reach PA, a high linearity LNA, a SAW filter, a T/R switch, and a 32 MHz crystal oscillator. It has been designed for a simplified Wi-Fi HaLow connection to an external host for applications where customers want to replace their prior RF technology with a Wi-Fi HaLow connection while using the latest WPA3 security protocol. Battery-operated applications are supported by a combination of features inherently supported by the module. The IEEE 802.11ah standard provides extended sleep times for battery-operated stations (STAs or client devices), with longer durations than other prior IEEE 802.11a/b/g/n/ac generations. The standard also allows longer extended maximum idle times for clients to conserve energy without being removed from the access point’s (AP’s) list of associated devices. *** ### 1.2 Features Ultra-long-range, low-power Wi-Fi HaLow module for IoT applications: * Channel bandwidth options of 1/2/4/8 MHz * Single-stream max. data rate of 32.5 Mbps @ 8 MHz or 15 Mbps @ 4 MHz channel * Radio supporting Sub-1 GHz frequency bands * Frequency range: 902-928 MHz * Max output power: 24.5 dBm * 802.11ah OFDM PHY supporting WFA HaLow certification * BPSK & QPSK, 16-QAM & 64-QAM Modulation * Automatic frequency and gain control * Packet detect and channel equalization * Forward Error Correction (FEC) coding and decoding * Support for Modulation and Coding Scheme (MCS) rates MCS 0-7 and MCS 10 * Support for 1 MHz and 2 MHz duplicate modes * Support for Traveling Pilots and Short Guard Intervals * 802.11ah MAC supporting WFA HaLow certification * Support for STA and AP roles * Listen-Before-Talk (LBT) access with energy detect * 802.11 power save * 802.11 fragmentation and defragmentation * Packet aggregation * Power-Saving Target Wake Time (TWT) support for long battery life * Restricted Access Window (RAW) * Automatic and manual MCS rate selection * Support for various interface options * SDIO 2.0 compliant host/slave interface * 2 x UARTs * Power Management Unit (PMU) for various modes of operation * Power-down (interrupt driven wake) * Hibernate mode (internal / external wake) * Active receive / transmit mode * Integrated DC-DC converter supporting a voltage supply from 3.0V to 3.6V * Wide spectrum of security features * AES encryption engine * Hardware support for SHA1 and SHA2 hash functions (SHA-256, SHA-384, SHA-512) * WPA3 including Protected Management Frames (PMF) * Opportunistic Wireless Encryption (OWE) *** ### 1.3 Applications The MM6108-MF08651-US is ideally suited for Internet of Things (IoT) and Machine-to-Machine (M2M) applications such as: * Surveillance cameras and sensors * Cloud connectivity * Low-power sensor networks * Building Automation Systems (BAS) * Asset tracking and management * Machine performance monitors and sensors * Building access control and security * Drone video and navigation communications * Connected toys and games * Rural internet access * Agricultural and farm networks * Utility smart meter and intelligent grid * Proximity sensors * Industrial automation controls * Smart home automation * EV car chargers * Appliances * Construction site connectivity * Smart signs and kiosks * Retail point-of-sale terminals * Vehicle-to-vehicle or Vehicle-to-Infrastructure communications * IP sensor networks * Biometric IDs and keypads * Warehouse Connectivity * Intelligent lighting controls * BT/ZigBee(™)/Z-Wave(™) to Wi-Fi HaLow gateways * Wi-Fi to Wi-Fi HaLow bridges * Wi-Fi HaLow client adapters/dongles * Smart city networks *** ## 2 Pin Descriptions The MM6108-MF08651-US module has 38 pins, which are described in this section. The following illustration shows the top view of the module pins. ![Figure 1: Pin diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/lQ7WldAL7o4PhwPUwfcY/Unknown%20image) *Figure 1: Pin diagram* *** | Pin | Pin Name | Type | Description | Alternate | | --- | --------------- | ------ | ----------------------------------- | --------- | | 1 | GND | Power | Ground | | | 2 | GND | Power | Ground | | | 3 | GND | Power | Ground | | | 4 | JTAG\_TCK | I | JTAG Clock | | | 5 | JTAG\_TDI \[1] | I | JTAG Data In | | | 6 | NC | NC | Do Not Connect | | | 7 | JTAG\_TMS \[1] | I | JTAG Mode Select | | | 8 | J TAG\_TRST \_N | I | JTAG Reset | | | 9 | JTAG\_TDO \[1] | O | JTAG Data Out | | | 10 | NC | I/O | Do Not Connect | | | 11 | GPIO\_10 \[2] | I/O | General Purpose IO10 | | | 12 | GND | Power | Ground | | | 13 | GPIO\_9 \[2] | I/O | General Purpose IO9 | | | 14 | GPIO\_8 \[2] | I/O | General Purpose IO8 | | | 15 | GPIO\_7 \[2] | I/O | General Purpose IO7 | | | 16 | SDIO\_D1 \[3] | I/O | SDIO D1 | | | 17 | SDIO\_D0 \[3] | I/O | SDIO D0 | | | 18 | SDIO\_CLK | I/O | SDIO Clock | | | 19 | VDD\_IO | Power | 3.3V VDD\_IO Supply | | | 20 | GND | Power | Ground | | | 21 | SDIO\_CMD \[3] | I/O | SDIO Command | SPI\_MOSI | | 22 | SDIO\_D3 \[3] | I/O | SDIO D3 | SPI\_CS | | 23 | SDIO\_D2 \[3] | I/O | SDIO D2 | | | 24 | GPIO\_6 \[2] | I/O | General Purpose IO6 | | | 25 | VBAT | Power | 3.3V VBAT Supply | | | 26 | GND | Power | Ground | | | 27 | GPIO\_5 \[2] | I/O | General Purpose IO5 | | | 28 | GPIO\_4 \[2] | I/O | General Purpose IO4 | | | 29 | GPIO\_3 \[2] | I/O | General Purpose IO3 | | | 30 | GPIO\_2 \[2] | I/O | General Purpose IO2 | | | 31 | GND | Power | Ground | | | 32 | VDD\_FEM | Power | 3.3V Frontend Module Supply | | | 33 | GPIO\_1 \[2] | I/O | General Purpose IO1 | | | 34 | BUSY | O | Wi-Fi BUSY | | | 35 | RESET\_N \[4] | I | System Reset | | | 36 | WAKE \[4] | I | Wake | | | 37 | GND | Power | Ground | | | 38 | ANT | Analog | Antenna | | | - | GND | Ground | Exposed ground - Connect to PCB GND | | \[1] JTAG pins should be tied to GND via a 10k pull down resistor \[2] All unused GPIO should be tied to GND via a 10k pull down resistor \[3] All SDIO bus pins except SDIO\_CLK should be pulled up with a 10k-100k resistor as per the the SDIO standard \[4] Supplied from VBAT domain. Other digital pins are driven by the VDDIO domain. *** ## 3 Functional Description The following sections describe the functions of the MM6108-MF08651-US module. ### 3.1 Block diagram ![Figure 2: Functional Block Diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/YsQLRA7Pf7MbAHAms7tS/Unknown%20image) *Figure 2: Functional Block Diagram* *** ### 3.2 Power supply requirements MM6108-MF08651-US module power is derived from a 3.0 to 3.6V supply on the VBAT pin and a 3.0 to 4.3V supply on the VDD\_FEM pin. VBAT powers the module’s internal circuitry, while VDD\_FEM powers the onboard ultra-long-range power amplifier. The module's transmitter power output can be increased by raising the supply voltage on the VDD\_FEM pin to 4.3V, although this will increase overall power consumption. VDDIO sets the IO voltage of the MM6108, which should be connected to the same power supply as the host MCU. The VDDIO voltage must be between 1.62V and 3.6V and must not exceed the voltage applied to VBAT. *** ### 3.3 SDIO host requirements When selecting a CPU host to interface with the MM8108-MF08651 module via the SDIO interface, ensure the host supports SDIO 2.0 with SDIO clock speeds of up to 50 MHz. Slower clock speeds will impact the maximum achievable throughput. The SDIO data and command lines should be pulled up with 10k-100k resistors per the SDIO 2.0 specification. Most applications will benefit from the module's power-saving features. Two GPIOs, set as CMOS outputs, are required to drive the RESET and WAKE signals. A third GPIO, set as a CMOS input, is needed to receive the BUSY signal from the module. In applications where the module must always be on, and the power-saving features can not be used, such as access points, the WAKE pin can be fixed to VBAT, reducing the need for GPIOs on the host processor to only one. A schematic diagram detailing the recommended SDIO host interface circuit using the module’s power-saving features is shown below: ![Figure 3: Recommended SDIO host interface circuit using power-saving features](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/cz6Ymjgez3zm7SZBURFC/Unknown%20image) *Figure 3: Recommended SDIO host interface circuit using power-saving features* *** A schematic diagram detailing the recommended SDIO host interface circuit for always-on applications is shown below: ![Figure 4: Recommended SDIO host interface circuit for always-on applications](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/ZGeeyiyEHFmBhsDGHPS8/Unknown%20image) *Figure 4: Recommended SDIO host interface circuit for always-on applications* ### 3.4 SPI host requirements When selecting a CPU host to interface via SPI to the MM6108-MF08651-US module, consider the following recommendations to achieve the best throughput: * The host should support level-triggered interrupts. * The host should support full-duplex SPI mode. * The host should support DMA-backed transactions on the SPI bus. Standard SPI can achieve up to 25 Mbps at 50 MHz, but this will be significantly reduced without DMA support. For example, an SPI interface with an 8-byte buffer per transaction might only achieve 2 Mbps throughput on the SPI bus. Most applications will benefit from the module's power-saving features. Two GPIOs, set as CMOS outputs, are required to drive the RESET and WAKE signals. A third GPIO, set as a CMOS input, is needed to receive the BUSY signal from the module. In applications where the module must always be on, and the power-saving features can not be used, such as access points, the WAKE pin can be fixed to VBAT, reducing the need for GPIOs on the host processor to only one. *** A schematic diagram detailing the recommended SPI host interface circuit using the module’s power-saving features is shown below: ![Figure 5: Recommended SPI host interface circuit using power-saving features](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/bRbYKcDZzWqk8eEy8XHq/Unknown%20image) *Figure 5: Recommended SPI host interface circuit using power-saving features* *** A schematic diagram detailing the recommended SPI host interface circuit for always-on applications is shown below: ![Figure 6: Recommended SPI host interface circuit for always-on applications](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/m5uUD7riEj9bG4isJpjL/Unknown%20image) *Figure 6: Recommended SPI host interface circuit for always-on applications* ### 3.5 Digital interfaces All unused digital IO pins must be pulled up or down to prevent floating pins. Failure to do so will result in a higher leakage current on the VDDIO supply. *** ### 3.6 Sleep/Wake Sequencing #### 3.6.1 Host initiates wake sequence ![Figure 7: Host-initiated wake sequence diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/lsSm35Vs3VKKNbm1w0y6/Unknown%20image) *Figure 7: Host-initiated wake sequence diagram* 1. The driver raises the wake pin and waits for a static period of 10 ms before initializing the shared communication bus and initiating host interface activity. On MM6108, this period is typically 10 ms. 2. After completing communication, the driver will wait a static period, b, before lowering the wake pin (assuming no further communication has occurred). Depending on the nature of the communication (802.11 data vs. commands), this period can range from 5 to 90ms. 3. After the wake pin has fallen, the MM6108 will wait for a period, c, before initiating hardware sleep. This dynamic period will differ depending on the power-saving protocol and other chip-specific factors. *** #### 3.6.2 MM6108-MF08651 initiates wake sequence with host interface disabled ![Figure 8: Module-initiated wake sequence with host interface disabled diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/xCFPknQVynX4F4FzsYFJ/Unknown%20image) *Figure 8: Module-initiated wake sequence with host interface disabled diagram* 1. The MM6108 wakes from sleep and realizes it needs to pass traffic or an event to the host. It begins by asserting the busy pin. 2. The busy pin will fire an interrupt on the host, after which the host will immediately: 3. Raise the Wake PIN. 4. Wait a static period, 10ms 5. Initializes / enables the shared host interface. 6. After asserting the busy pin, the MM6108 will initiate host interface communication immediately. It does not wait until the host ‘enables’ the shared host interface. This is okay, as the bus transaction will be waiting for the host, and an interrupt should fire as soon as the host enables bus interrupts. 7. The busy pin will drop immediately once the MM6108 no longer needs to converse with the host. The host will wait a static period, b, before dropping the wake pin. 8. After the wake pin has fallen, the MM6108 will wait for a period, c, before initiating hardware sleep. *** #### 3.6.3 MM6108-MF08651 initiates communication with host interface enabled ![Figure 9: Module-initiated wake sequence with host interface enabled diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/ei33E9kKf5gQ9lbd7TX7/Unknown%20image) *Figure 9: Module-initiated wake sequence with host interface enabled diagram* 1. The MM6108 was previously woken by the host for communication. 2. Sometime after wake and host->MM6108 communication, the MM6108 realizes it needs to send data back to the host (MM6108->host). It will assert the busy pin. 3. The busy pin will fire an interrupt on the host, after which it will immediately: 4. Process the interrupt but take no further action, as the wake pin has already been asserted and the shared host interface is currently enabled/initialized. 5. After MM6108->host communication completion, hardware sleep will be initiated as described above. *** ## 4 Electrical Characteristics ### 4.1 Absolute max ratings Stress beyond absolute maximum ratings may cause permanent damage to the MM6108-MF08651-US module. Functional operation is only guaranteed for recommended operating conditions. Operation of the device outside the recommended conditions may result in a reduced lifetime and reliability problems, even if the absolute maximum ratings are not exceeded. **Table 1: Absolute max ratings** | Parameter | Min | Max | Unit | | -------------------------- | ---- | --- | ---- | | VBAT voltage | -0.3 | 4.3 | V | | VDD\_FEM voltage | -0.3 | 4.3 | V | | Voltage on digital I/O pin | -0.3 | 4.3 | V | | Voltage on analog/RF pin | -0.3 | 1.2 | V | | Storage temperature | -40 | 125 | °C | | RF input power (CW) | - | 6 | dBm | ### 4.2. Immunity **Table 2: Immunity** | Parameter | Parameter | Parameter | Min | Max | Unit | | ----------------------------------------- | ----------------------------------------------------- | ------------------------ | ----- | ---- | ---- | | Electrostatic discharge (ESD) performance | Human body model (HBM), per ANSI / ESDA / JEDEC JS001 | RF Input | -1000 | 1000 | V | | Electrostatic discharge (ESD) performance | Human body model (HBM), per ANSI / ESDA / JEDEC JS001 | All pins except RF Input | -2000 | 2000 | V | | Electrostatic discharge (ESD) performance | Charged device model (CDM), per JESD22-C101 | All pins | -500 | 500 | V | *** ### 4.3 Recommended operating conditions **Table 3: Recommended operating conditions** | Parameter | Min | Typ | Max | Unit | | ------------------------ | ---- | --- | ----- | ---- | | Ambient temperature | -40 | 2 5 | 85 | °C | | VBAT | 3.0 | 3.3 | 3.6 | V | | VDD\_FEM | 3.0 | 3.3 | 4.3 | V | | VDDI O \[1] | 1.62 | 3.3 | 3.6 | V | | Digital I/O voltage | 0 | 3.3 | VDDIO | V | | RESET / WAKE I/O Voltage | 0 | 3.3 | VBAT | V | \[1] VDDIO should not exceed VBAT Performance specifications are achieved under typical operating conditions unless otherwise specified. ### 4.4 Power consumption #### 4.4.1 Transmit power consumption **Table 4: Transmit power consumption** | Modulation Coding Scheme | Condition: T A =25 o C, V BAT /V DDIO = 3.3V | V DD\_FEM = 3.3V V BAT Current | V DD\_FEM = 3.3V V DD\_FEM Current | V DD\_FEM = 4.3V V BAT Current | V DD\_FEM = 4.3V V DD\_FEM Current | Unit | | ------------------------ | -------------------------------------------- | ------------------------------ | ---------------------------------- | ------------------------------ | ---------------------------------- | ---- | | MCS 0 | 1 MHz channel | 57 | 152 | 58 | 168 | mA | | MCS 0 | 2 MHz channel | 60 | 152 | 61 | 168 | mA | | MCS 0 | 4 MHz channel | 66 | 151 | 66 | 160 | mA | | MCS 0 | 8 MHz channel | 78 | 147 | 77 | 154 | mA | | MCS 7 | 1 MHz channel | 51 | 104 | 53 | 122 | mA | | MCS 7 | 2 MHz channel | 55 | 104 | 57 | 123 | mA | | MCS 7 | 4 MHz channel | 62 | 102 | 64 | 119 | mA | | MCS 7 | 8 MHz channel | 72 | 99 | 76 | 117 | mA | *** #### 4.4.2 Receive power consumption **Table 5: Receive power consumption** | Mode | Condition: T A =25 o C, V BAT /V DDIO = 3.3V, V DD\_FEM = 3.3V or 4.3V | V BAT Current Min | V BAT Current Typ | V BAT Current Max | V DD\_FEM Current Min | V DD\_FEM Current Typ | V DD\_FEM Current Max | Unit | | ------------------- | ---------------------------------------------------------------------- | ----------------- | ----------------- | ----------------- | --------------------- | --------------------- | --------------------- | ---- | | Listen | 1 MHz channel | 25 | 26 | 35 | 4 | 4.5 | 4.7 | mA | | Listen | 2 MHz channel | 26 | 28 | 35 | 4 | 4.5 | 4.7 | mA | | Listen | 4 MHz channel | 30 | 32 | 40 | 4 | 4.5 | 4.7 | mA | | Listen | 8 MHz channel | 35 | 37 | 46 | 4 | 4.5 | 4.7 | mA | | Active receive MCS7 | 1 MHz channel | 26 | 27 | 36 | 4 | 4.5 | 4.7 | mA | | Active receive MCS7 | 2 MHz channel | 30 | 30 | 40 | 4 | 4.5 | 4.7 | mA | | Active receive MCS7 | 4 MHz channel | 38 | 40 | 49 | 4 | 4.5 | 4.7 | mA | | Active receive MCS7 | 8 MHz channel | 53 | 54 | 67 | 4 | 4.5 | 4.7 | mA | | Active receive MCS0 | 1 MHz channel | 26 | 28 | 37 | 4 | 4.5 | 4.7 | mA | | Active receive MCS0 | 2 MHz channel | 29 | 30 | 39 | 4 | 4.5 | 4.7 | mA | | Active receive MCS0 | 4 MHz channel | 36 | 36 | 47 | 4 | 4.5 | 4.7 | mA | | Active receive MCS0 | 8 MHz channel | 48 | 50 | 63 | 4 | 4.5 | 4.7 | mA | #### 4.4.3 Sleep power consumption **Table 6: Sleep power consumption** | Mode | Condition: T A =25 o C, V BAT /V DDIO = 3.3 V, V DD\_FEM =3.3V or 4.3V | V BAT Current Min | V BAT Current Typ | V BAT Current Max | V DD\_FEM Current Min | V DD\_FEM Current Typ | V DD\_FEM Current Max | Unit | | ---------- | ---------------------------------------------------------------------- | ----------------- | ----------------- | ----------------- | --------------------- | --------------------- | --------------------- | ---- | | Snooze | RC Oscillator o n , Memory retained, wake on timer | 9.5 | 42 | 370 | 0.001 | 0.05 | 0.55 | uA | | Deep sleep | RC Oscillator o n , wake on timer | 0.8 | 1 | 1.8 | 0.001 | 0.05 | 0.55 | uA | | Hibernate | Power off, wait for external interrupt | 0.03 | 0.05 | 1 | 0.001 | 0.05 | 0.55 | uA | *** #### 4.4.4 DTIM3 power consumption **Table 7: DTIM3 power consumption** | Mode | Condition: T A =25 o C, V BAT /V DDIO = 3.3 V | V DD\_FEM = 3.3V V BAT | V DD\_FEM = 3.3V V FEM | V DD\_FEM = 4.3V V BAT | V DD\_FEM = 4.3V V FEM | Unit | | --------------------------------------------- | --------------------------------------------- | ---------------------- | ---------------------- | ---------------------- | ---------------------- | ---- | | S1G beacons | 1 MHz channel | 395 | 47 | 393 | 48 | uA | | S1G beacons | 2 MHz channel | 395 | 47 | 393 | 48 | uA | | S1G beacons | 4 MHz channel | 280 | 25 | 271 | 26 | uA | | S1G beacons | 8 MHz channel | 280 | 25 | 268 | 26 | uA | | S1G beacons with proprietary DTIM signaling 1 | 1 MHz channel | 190 | 13 | 187 | 14 | uA | | S1G beacons with proprietary DTIM signaling 1 | 2 MHz channel | 190 | 13 | 187 | 14 | uA | | S1G beacons with proprietary DTIM signaling 1 | 4 MHz channel | 190 | 9 | 168 | 11 | uA | | S1G beacons with proprietary DTIM signaling 1 | 8 MHz channel | 190 | 9 | 168 | 11 | uA | #### 4.4.5 DTIM10 power consumption **Table 8: DTIM10 power consumption** | Mode | Condition: T A =25 o C, V BAT /V DDIO = 3.3 V | V DD\_FEM = 3.3V V BAT | V DD\_FEM = 3.3V V FEM | V DD\_FEM = 4.3V V BAT | V DD\_FEM = 4.3V V FEM | Unit | | --------------------------------------------- | --------------------------------------------- | ---------------------- | ---------------------- | ---------------------- | ---------------------- | ---- | | S1G beacons | 1 MHz channel | 155 | 15 | 145 | 16 | uA | | S1G beacons | 2 MHz channel | 155 | 15 | 144 | 16 | uA | | S1G beacons | 4 MHz channel | 115 | 8 | 109 | 9 | uA | | S1G beacons | 8 MHz channel | 115 | 8 | 109 | 9 | uA | | S1G beacons with proprietary DTIM signaling 1 | 1 MHz channel | 95 | 5 | 88 | 6 | uA | | S1G beacons with proprietary DTIM signaling 1 | 2 MHz channel | 95 | 5 | 88 | 6 | uA | | S1G beacons with proprietary DTIM signaling 1 | 4 MHz channel | 90 | 5 | 80 | 5 | uA | | S1G beacons with proprietary DTIM signaling 1 | 8 MHz channel | 90 | 5 | 80 | 5 | uA | \[1] Signaling that indicates whether a power-saving STA should receive and process an entire beacon *** ### 4.5 RF Specifications #### 4.5.1 Receiver Sensitivity Sensitivities for 10% packet error rate, 1000 byte packets. **Table 9: Receiver sensitivity** | MCS index | Modulation scheme | Coding rate | Phy rate (Mbps) per BW 1 MHz | Phy rate (Mbps) per BW 2 MHz | Phy rate (Mbps) per BW 4 MHz | Phy rate (Mbps) per BW 8 MHz | Minimum receive sensitivity (dBm) 1 MHz | Minimum receive sensitivity (dBm) 2 MHz | Minimum receive sensitivity (dBm) 4 MHz | Minimum receive sensitivity (dBm) 8 MHz | | --------- | ----------------- | ----------- | ---------------------------- | ---------------------------- | ---------------------------- | ---------------------------- | --------------------------------------- | --------------------------------------- | --------------------------------------- | --------------------------------------- | | 10 | BPSK | 1/2 x 2 | 0.17 | N/A | N/A | N/A | -107 | N/A | N/A | N/A | | 0 | BPSK | 1/2 | 0.33 | 0.72 | 1.5 | 3.3 | -105 | -103 | -101 | -97 | | 1 | QPSK | 1/2 | 0.67 | 1.4 | 3.0 | 6.5 | -102 | -100 | -97 | -93 | | 2 | QPSK | 3/4 | 1.0 | 2.2 | 4.5 | 9.8 | -99 | -97 | -95 | -91 | | 3 | 16-QAM | 1/2 | 1.3 | 2.9 | 6.0 | 13 | -96 | -94 | -91 | -88 | | 4 | 16-QAM | 3/4 | 2.0 | 4.3 | 9.0 | 20 | -93 | -90 | -88 | -85 | | 5 | 64-QAM | 2/3 | 2.7 | 5.8 | 12 | 26 | -89 | -87 | -84 | -80 | | 6 | 64-QAM | 3/4 | 3.0 | 6.5 | 14 | 29 | -88 | -85 | -83 | -79 | | 7 | 64-QAM | 5/6 | 3.3 | 7.2 | 15 | 33 | -87 | -84 | -81 | -77 | #### 4.5.2 Transmitter Output Power Note: The following transmit power levels are for IEEE compliance for 802.11ah. They do not consider any backoffs needed for regional spectrum compliance (eg, FCC, IC, TELEC). **Table 10: Transmitter output** | Channel Bandwidth | Modulation Coding Scheme | V DD\_FEM = 3.3V Min | V DD\_FEM = 3.3V Typical | V DD\_FEM = 3.3V Max | V DD\_FEM = 4.3V Min | V DD\_FEM = 4.3V Typical | V DD\_FEM = 4.3V Max | Unit | | ----------------- | ------------------------ | -------------------- | ------------------------ | -------------------- | -------------------- | ------------------------ | -------------------- | ---- | | 1, 2 MHz | MCS 0 | 20 | 21 | 22 | 22 | 23.5 | 24.5 | dBm | | 1, 2 MHz | MCS 7 | 16 | 17 | 18.5 | 18.5 | 20 | 21 | dBm | | 4 Mhz | MCS 0 | 20.5 | 21 | 22 | 22 | 23.5 | 24.5 | dBm | | 4 Mhz | MCS 7 | 16 | 17 | 18 | 18.5 | 20 | 20.5 | dBm | | 8 Mhz | MCS 0 | 20.5 | 21 | 21.5 | 21.5 | 23 | 24.5 | dBm | | 8 Mhz | MCS 7 | 15.5 | 17 | 17.5 | 18 | 19.5 | 20.5 | dBm | *** ### 4.6 Digital specifications ![Figure 10: Powering on and reset timing diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/z2WwiCS13SpRQiMEBOdb/Unknown%20image) *Figure 10: Powering on and reset timing diagram* **Table 11: Digital specifications** | Parameters | Description | Min | Max | Unit | | ---------- | ---------------------------------------------------------------- | ---- | --- | ---- | | V IL\_nRST | Reset threshold | 450 | | mV | | t 0 | Time between VBAT brought up (3.3V) and RESET\_N being activated | 50 | | μs | | t 1 | Duration of RESET\_N signal level < VIL\_nRST to reset the chip | 1000 | | μs | | t B | Boot Time | | 6 | ms | *** **Table 12: Digital Specifications** | Parameters | Description | VDDIO | Min | Max | Unit | | ---------- | ------------------------------------------------------------------ | ----- | ---- | ---- | ---- | | V IL\_GPIO | Low input threshold for all GPIO and SDIO pins | 1.8 | -0.3 | 0.63 | V | | V IL\_GPIO | Low input threshold for all GPIO and SDIO pins | 2.5 | -0.3 | 0.7 | V | | V IL\_GPIO | Low input threshold for all GPIO and SDIO pins | 3.3 | -0.3 | 0.8 | V | | V IH\_GPIO | High input threshold for all GPIO and SDIO pins | 1.8 | 1.17 | 3.6 | V | | V IH\_GPIO | High input threshold for all GPIO and SDIO pins | 2.5 | 1.7 | 3.6 | V | | V IH\_GPIO | High input threshold for all GPIO and SDIO pins | 3.3 | 2.0 | 3.6 | V | | V OL\_GPIO | Low output voltage for all GPIO and SDIO pins assuming a 8mA load | 1.8 | 0.13 | 0.38 | V | | V OL\_GPIO | Low output voltage for all GPIO and SDIO pins assuming a 8mA load | 2.5 | 0.10 | 0.27 | V | | V OL\_GPIO | Low output voltage for all GPIO and SDIO pins assuming a 8mA load | 3.3 | 0.08 | 0.18 | V | | V OH\_GPIO | High output voltage for all GPIO and SDIO pins assuming a 8mA load | 1.8 | 1.34 | 1.70 | V | | V OH\_GPIO | High output voltage for all GPIO and SDIO pins assuming a 8mA load | 2.5 | 2.20 | 2.41 | V | | V OH\_GPIO | High output voltage for all GPIO and SDIO pins assuming a 8mA load | 3.3 | 3.07 | 3.23 | V | | V OL\_SDIO | Low output voltage for all SDIO pins assuming a 8mA load | 1.8 | 0.17 | 0.52 | V | | V OL\_SDIO | Low output voltage for all SDIO pins assuming a 8mA load | 2.5 | 0.14 | 0.36 | V | | V OL\_SDIO | Low output voltage for all SDIO pins assuming a 8mA load | 3.3 | 0.11 | 0.24 | V | | V OH\_SDIO | High output voltage for all SDIO pins assuming a 8mA load | 1.8 | 1.19 | 1.67 | V | | V OH\_SDIO | High output voltage for all SDIO pins assuming a 8mA load | 2.5 | 2.10 | 2.39 | V | | V OH\_SDIO | High output voltage for all SDIO pins assuming a 8mA load | 3.3 | 2.99 | 3.21 | V | *** ## 5 Physical Dimensions ![Figure 11: Package dimensions](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/bGYpoviUmNQQxXMsa1oc/Unknown%20image) *Figure 11: Package dimensions* *** ## 6 Recommended PCB Footprint ![Figure 12: PCB Footprint diagram](https://content.gitbook.com/content/C7zRQJQJws9WxgXTA97e/blobs/hR6tK6IKEftHfCad1vb6/Unknown%20image) *Figure 12: PCB Footprint diagram* *** ## 7 Certification ### 7.1 FCC This equipment has been tested and found to comply with the limits for a Class B digital device, pursuant to Part 15 of the FCC Rules. These limits are designed to provide reasonable protection against harmful interference in a residential installation. This equipment generates, uses and can radiate radio frequency energy and, if not installed and used in accordance with the instructions, may cause harmful interference to radio communications. However, there is no guarantee that interference will not occur in a particular installation. If this equipment does cause harmful interference to radio or television reception, which can be determined by turning the equipment off and on, the user is encouraged to try to correct the interference by one of the following measures: * Reorient or relocate the receiving antenna * Increase the separation between the equipment and receiver * Connect the equipment into an outlet on a circuit different from that to which the receiver is connected * Consult the dealer or an experienced radio/TV technician for help FCC caution: Any changes or modifications not expressly approved by the party responsible for compliance could void the user’s authority to operate this equipment. This device complies with Part 15 of the FCC Rules. Operation is subject to the following two conditions: (1) this device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may cause undesired operation. #### 7.1.1 FCC Radiation Exposure Statement: This equipment complies with FCC radiation exposure limits set forth for an uncontrolled environment. This equipment should be installed and operated with a minimum distance 20cm between the radiator and your body. #### 7.1.2 Important Note To Integrators This module is intended for OEM integrators. It is only FCC authorized for the specific rule parts listed on the grant, and the host product manufacturer is responsible for compliance with any other FCC rules that apply to the host not covered by the modular transmitter grant of certification. The final host product still requires Part 15 Subpart B compliance testing with the modular transmitter installed. Additional testing and certification may be necessary when multiple modules are used. #### 7.1.3 End Product User Manual Requirement In the user manual of the end product, the end user has to be informed to keep at least 20cm of separation with the antenna while this end product is installed and operated. The end user has to be informed that the FCC radio-frequency exposure guidelines for an uncontrolled environment can be satisfied. The end user has to also be informed that any changes or modifications not expressly approved by the manufacturer could void the user’s authority to operate this equipment. This device complies with Part 15 of FCC rules. Operation is subject to the following two conditions: (1) this device may not cause harmful interference and (2) this device must accept any interference received, including interference that may cause undesired operation. #### 7.1.4 End Product Label Requirement The end product must be labeled in a visible area with the following: **Figure 13: End Product Label Requirement** | Contains FCC ID: 2A74O-DB3F2B This device complies with Part 15 of FCC rules. Operation is subject to the following two conditions: (1) this device may not cause harmful interference and (2) this device must accept any interference received, including interference that may cause undesired operation. | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | *** ### 7.2. IC This device contains licence-exempt transmitter(s)/receiver(s) that comply with Innovation, Science and Economic Development Canada’s licence-exempt RSS(s). Operation is subject to the following two conditions: (1) This device may not cause interference. (2) This device must accept any interference, including interference that may cause undesired operation of the device. Cet appareil contient des émetteurs / récepteurs exempts de licence qui sont conformes au (x) RSS (s) exemptés de licence d’Innovation, Sciences et Développement économique Canada. L’opération est soumise aux deux conditions suivantes: (1) Cet appareil ne doit pas provoquer d'interférences. (2) Cet appareil doit accepter toute interférence, y compris les interférences susceptibles de provoquer un fonctionnement indésirable de l'appareil. This radio transmitter 29791-628C73 has been approved by Innovation, Science and Economic Development Canada to operate with the antenna types listed below, with the maximum permissible gain indicated. Antenna types not included in this list that have a gain greater than the maximum gain indicated for any type listed are strictly prohibited for use with this device. Le présent émetteur radio 29791-628C73 a été approuvé par Innovation, Sciences et Développement économique Canada pour fonctionner avec les types d'antenne énumérés ci-dessous et ayant un gain admissible maximal d'antenne. Les types d'antennes non inclus dans cette liste qui ont un gain supérieur au gain maximal indiqué pour tout type listé sont strictement interdits pour une utilisation avec cet appareil. #### 7.2.1 IC Radiation Exposure Statement: This equipment complies with IC RSS-102 radiation exposure limits set forth for an uncontrolled environment. This equipment should be installed and operated with a minimum distance of 20cm between the radiator & your body. Cet équipement est conforme aux limites d'exposition aux rayonnements IC établies pour un environnement non contrôlé. Cet équipement doit être installé et utilisé avec un minimum de 20 cm de distance entre la source de rayonnement et votre corps. #### 7.2.2 Important Note To Integrators This module is intended for OEM integrators. The OEM integrator is responsible for complying with all the rules that apply to the product into which this certified RF module is integrated. Additional testing and certification may be necessary when multiple modules are used. Any changes or modifications not expressly approved by the manufacturer could void the user's authority to operate this equipment. #### 7.2.3 End Product User Manual Requirement In the users manual of the end product, the end user has to be informed to keep at least 20 cm separation with the antenna while this end product is installed and operated. The end user has to be informed that the IC radio-frequency exposure guidelines for an uncontrolled environment can be satisfied. The end user has to also be informed that any changes or modifications not expressly approved by the manufacturer could void the user's authority to operate this equipment. Operation is subject to the following two conditions: (1) this device may not cause harmful interference (2) this device must accept any interference received, including interference that may cause undesired operation. #### 7.2.4 End Product Label Requirement The end product must be labeled in a visible area with the following: **Figure 14: End Product Label Requirement** | Contains IC: 29791-628C73 | | ------------------------- | The Host Model Number (HMN) must be indicated at any location on the exterior of the end product, product packaging, or product literature, which shall be available with the end product or online. *** ## 8 Part Numbers and Ordering Information **Table 13: Part number and ordering information** | Part Number | Packing Type | Pins | Size (mm) | Description | | ----------------- | ------------ | ---- | ----------------- | ------------------------------------------------------ | | MM6108-MF08651-US | Tray | 38 | 14.0 x 18.5 x 2.1 | IEEE 802.11ah Sub-1 GHz 1/2/4/8 MHz Wi-Fi HaLow Module | ## 9 Handling and Storage The MM6108-MF08651-US module is a moisture-sensitive device rated at Moisture Sensitive Level 3 (MSL3) per IPC/JEDEC J-STD-20. After opening the moisture-sealed storage bag, modules that will be subjected to reflow solder or other high-temperature processes must be: 1. Mounted to a circuit board within 168 hours at factory conditions (≤30°C and <60% RH) OR 2. Continuously stored per IPC/JEDEC J-STD-033 Modules exposed to moisture and environmental conditions exceeding packaging and storage conditions MUST be baked before mounting according to IPC/JEDEC J-STD-033. Failure to meet packaging and storage conditions will result in irreparable damage to modules during solder reflow. *** ## 10 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | -------------------------------------------------------------------------- | | DS102 | 17 Jun 2025 | Updated formatting | | DS101 | 28 Feb 2025 | General updates to layout and formatting Higher voltage VFEM impacts added | | DS100 | 16 Dec 2023 | Initial release | Morse Micro provides this information "as is" without warranties of any kind, express or implied. No guarantee is made as to the accuracy, completeness, or suitability of this information or Morse Micro’s products for any specific purpose. Use of this information and products is at the user’s sole risk. Morse Micro products are not designed or tested for use in mission-critical systems, and should not be used in such applications. Performance specifications are based on internal testing and are believed to be reliable; however, they are not guaranteed. It is the Buyer’s responsibility to test and validate all product performance, compatibility, and compliance, both in isolation and within end applications. Morse Micro assumes no liability for the use or application of any product, circuit, or information described herein. No license or other rights, express or implied, are granted under Morse Micro’s intellectual property. This document contains proprietary information of Morse Micro and is subject to change without notice. # Application notes Application notes provide configuration guidance, implementation examples, and technical recommendations for Morse Micro products. ### Application notes #### [APPNOTE-3 Target Wake Time](/application-notes/appnote-3-target-wake-time) Guidance for using Target Wake Time with Morse Micro devices. #### [APPNOTE-13 Morsectrl Guide](/application-notes/appnote-13-morsectrl-guide) Guide to configuring and managing Morse Micro devices with `morsectrl`. #### [APPNOTE-15 MM6108 SDIO SPI Design Guide](/application-notes/appnote-15-mm6108-sdio-spi-design-guide) Hardware design guidance for MM6108 SDIO and SPI interfaces. #### [APPNOTE-17 Dynamic Channel Selection](/application-notes/appnote-17-dynamic-channel-selection) Guidance for configuring Dynamic Channel Selection. #### [APPNOTE-18 Bringing Up prplMesh on Linux](/application-notes/appnote-18-bringing-up-prplmesh-on-linux) Instructions for bringing up prplMesh on Linux. #### [APPNOTE-20 Thin LMAC](/application-notes/appnote-20-thin-lmac) Overview and integration guidance for Thin LMAC. #### [APPNOTE-21 TCP Keep Alive Offload](/application-notes/appnote-21-tcp-keep-alive-offload) Guidance for configuring TCP keep-alive offload. #### [APPNOTE-24 Linux Porting Guide](/application-notes/appnote-24-linux-porting-guide) Guidance for porting Morse Micro software to Linux platforms. #### [APPNOTE-25 Centralized Authentication Control](/application-notes/appnote-25-centralized-authentication-control) Guidance for configuring centralized authentication control. #### [APPNOTE-26 BCF Overview and Impact on System Performance](/application-notes/appnote-26-bcf-overview-and-impact-on-system-performance) Overview of BCF and its effect on system performance. #### [APPNOTE-28 Morse Micro Rate Control](/application-notes/appnote-28-morse-micro-rate-control) Overview of Morse Micro rate control. #### [APPNOTE-29 Bypass Boobytrap](/application-notes/appnote-29-bypass-boobytrap) Guidance for bypassing Boobytrap. #### [APPNOTE-31 How to Configure EasyMesh](/application-notes/appnote-31-how-to-configure-easymesh) Instructions for configuring EasyMesh. #### [APPNOTE-32 How to Configure 802.11s Mesh](/application-notes/appnote-32-how-to-configure-802.11s-mesh) Instructions for configuring an 802.11s mesh network. #### [APPNOTE-33 2.4GHz Range Extension Using HaLow](/application-notes/appnote-33-2.4ghz-range-extension-using-halow) Guidance for extending 2.4 GHz range with Wi-Fi HaLow. #### [APPNOTE-34 Measuring Low Power Wi-Fi HaLow](/application-notes/appnote-34-measuring-low-power-wi-fi-halow) Guidance for measuring low-power Wi-Fi HaLow performance. #### [APPNOTE-35 How to Configure a Starlink LTE Dongle Internet Uplink Connection](/application-notes/appnote-35-how-to-configure-a-starlink-lte-dongle-internet-uplink-connection) Guidance for configuring Starlink and LTE dongle internet uplinks. #### [APPNOTE-36 How to Do a Sniffer Capture](/application-notes/appnote-36-how-to-do-a-sniffer-capture) Instructions for capturing Wi-Fi HaLow network traffic. #### [APPNOTE-37 How to Configure Virtual Wire](/application-notes/appnote-37-how-to-configure-virtual-wire) Instructions for configuring Virtual Wire. #### [APPNOTE-38 Wi-Fi Easy Connect using DPP URIs or QR Codes](/application-notes/appnote-38-wi-fi-easy-connect-using-dpp-uris-or-qr-codes) Guidance for using Wi-Fi Easy Connect using DPP URIs or QR Codes. #### [APPNOTE-39 MM6108 OTP for BCF and MAC Read and Write Guide](/application-notes/appnote-39-mm6108-otp-for-bcf-and-mac-read-and-write-guide) Guide to reading and writing MM6108 OTP for BCF and MAC data. #### [APPNOTE-41 OTP and BCF Selection](/application-notes/appnote-41-otp-and-bcf-selection) Guidance for selecting OTP and BCF configurations. #### [APPNOTE-43 Wi-Fi HaLow RF Test Guide](/application-notes/appnote-43-wi-fi-halow-rf-test-guide) Guidance for cabled RF testing of Wi-Fi HaLow devices. #### [APPNOTE-45 MM IoT SDK Porting Guide](/application-notes/appnote-45-mm-iot-sdk-porting-guide) Guidance for porting the MM IoT SDK to a new microcontroller platform. #### [APPNOTE-50 AP Power Management](/application-notes/appnote-50-ap-power-management) Guidance for access point power management. #### [APPNOTE-51 Linux SPI Driver Porting Guide](/application-notes/appnote-51-linux-spi-driver-porting-guide) Guidance for porting the Linux SPI driver. #### [APPNOTE-56 MM8108 Thermal Protection Mechanism](/application-notes/appnote-56-mm8108-thermal-protection-mechanism) Guidance for using the MM8108 thermal protection mechanism. # APPNOTE-3 Target Wake Time v1 ## MM APPNOTE-03 Target Wake Time v1 ### Table of Contents * [1 Scope](#1-scope) * [2 Theory of Operation](#2-theory-of-operation) * [3 How to Configure](#3-how-to-configure) * [3.1 General Configuration](#31-general-configuration) * [3.2 OpenWrt](#32-openwrt) * [3.3 Linux](#33-linux) * [cat /morse/configs/wpa\_supplicant\_s1g.conf](#cat-morseconfigswpa_supplicant_s1gconf) * [3.4 FreeRTOS (IoT-SDK)](#34-freertos-iot-sdk) * [4 How to Verify](#4-how-to-verify) * [5 What to Expect](#5-what-to-expect) * [6 References](#6-references) * [7 Revision History](#7-revision-history) *** ## 1 Scope This guide shows how to use the Target Wake Time (TWT) feature that is part of the 802.11ah standard. It includes the steps to configure and verify this feature using OpenWrt, Linux, and FreeRTOS based software. ## 2 Theory of Operation The target wake time (TWT) feature allows STAs to go to sleep for longer periods and ignore DTIM beacons, as well as to dynamically negotiate wakeup periods with the AP. These wake up times are known as the TWT service period(SP). It also allows the AP to spread out client traffic so that when a STA device wakes up it won’t need to contend with other devices. This allows the STA device to reduce the required amount of time that it needs to be awake and improves the power utilization. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/nzeJJA5vdKQ5Ur0c4DaA/Unknown%20image) Figure 1 - TWT Service Periods are independent of the AP’s beacon and can be dynamically renegotiated on the fly. *** There are two types of TWT scheduling, and two types of TWT 'flows'. TWT scheduling options: * Implicit - Where the TWT requesting STA calculates the next TWT by adding a fixed value to the current TWT value. This results in a periodic service period. * Explicit - Where the TWT requesting STA wakes and performs a frame exchange and receives the next TWT information in a response from the TWT responder (typically the AP). This allows the interval between service periods to be dynamically set. TWT ‘flow’ options: * Announced - TWT Responders have to wait for QOS Null frames from STAs to deliver buffered data. * Unannounced - TWT Responders don't need to wait for QoS Null frames from STAs to deliver buffered data Negotiation of TWT agreements between a requester and responder occurs through the TWT IE (see 9.4.2.199 TWT element) which can be appended to association frames and/or TWT information frames. Once the STA has successfully negotiated a TWT flow with the AP, it may sleep until the next service period begins. Note: Currently there is support only for implicit TWT scheduling with announced intervals, and this is negotiated at association/re-association. Only individual TWT agreements are supported (between 1 AP and 1 STA), and only one TWT flow per AP/STA pair. ## ## 3 How to Configure ### 3.1 General Configuration The following guidance is provided for setting the TWT parameters. TWT Wake Interval (us) - The current default is 30 seconds. The minimum value is recommended to be longer than the beacon interval (default beacon interval is 100ms) at a minimum, and probably a multiple of beacon intervals. Minimum Wake Duration (us) - can be configured between 1 and 65280us, with the default being the maximum value. Values below 32640 have shown unreliable behaviour in field testing. Setup command - note that only request and response are currently supported, though demand is also defined in the 802.11 standard. This guidance doesn’t account for any duty cycle related restrictions that apply in some regions. ### 3.2 OpenWrt TWT can be configured on STA devices, no changes are required on the AP. To enable TWT on a STA, browse to Network->Wireless in the UI: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/1mw3NvxfOnZ0eM2K5R5L/Unknown%20image) Click ‘Edit’ on the HaLow network:\ ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/Gzz6bF1HpGwo5L7lOcGG/Unknown%20image) Scroll down to the interface configuration section, and select the ‘Power Save’ tab:\ ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/7PFJerZJGqfHZ7Mh7LU0/Unknown%20image) Check the checkbox to enable TWT. Additional options for configuring TWT will become visible. These features are also available for configuration via UCI. * Enable in the interface config as:\ option twt '1' * Parameters have default values set, with:\ setup\_command=0\ wake\_interval=300000000\ min\_wake\_duration=65982 * Note, the twt option does not automatically set:\ vendor\_keep\_alive\_offload=1.\ This should be done by the user in the wifi-device config, as above. * Parameters can be overridden, in the wifi-iface config, as:\ option setup\_command '1'\ option wake\_interval '1000000'\ option min\_wake\_duration '123456' ### ### 3.3 Linux Configuration of TWT is achieved with the inclusion of the following config in a STA’s wpa\_supplicant.conf file: ## cat /morse/configs/wpa\_supplicant\_s1g.conf ctrl\_interface=/var/run/wpa\_supplicant\_s1g ... vendor\_keep\_alive\_offload=1 # LMAC is responsible for transmitting null ipv4 keep-alive frames ... network={ ssid="MorseMicro" psk="12345678" ... twt={ wake\_interval=300000000 # Service Period interval (us) min\_wake\_duration=65280 # Minimum wake duration (us) setup\_command=0 # TWT setup command; 0:Request,\ \# 1:Suggest, 2:Demand. Only 0 & 1\ \# is supported (they behave in\ \# the same way) }\ } Upon association, the STA will request a periodic TWT SP to be every 5 minutes (approximately - rounding will occur), with each SP lasting 65ms. The AP will either accept or reject this request. *** Other than the aforementioned configuration the user must ensure that the following modparams to the driver are set as follows on both the AP and STA: enable\_twt=1 (default) and on the STA: enable\_ps=2 (default) enable\_dynamic\_ps\_offload=1 (default) enable\_mac80211\_connection\_monitor=0 (default) ### ### 3.4 FreeRTOS (IoT-SDK) TWT can be configured in the MM-IoT-SDK using the mmwlan API, see the reference manual and mmwlan.h for more details. TWT configurations are added by invoking the mmwlan\_twt\_add\_configuration() function, an example of which is shown below. TWT configurations should be added after WLAN initialization (mmwlan\_init()), but before connecting to the AP (mmwlan\_sta\_enable()). static void add\_twt\_configuration(void) { enum mmwlan\_status status; struct mmwlan\_twt\_config\_args twt\_config = MMWLAN\_TWT\_CONFIG\_ARGS\_INIT; twt\_config.twt\_mode = MMWLAN\_TWT\_REQUESTER; twt\_config.twt\_setup\_command = MMWLAN\_TWT\_SETUP\_REQUEST; twt\_config.twt\_wake\_interval\_us = 300000000; twt\_config.twt\_min\_wake\_duration\_us = 65280; status = mmwlan\_twt\_add\_configuration(\&twt\_config); if (status == MMWLAN\_SUCCESS) { printf("Successfully added TWT configuration\n"); } else { printf("Failed to set TWT configuration\n"); } } *** ## ## 4 How to Verify The two main tools for verifying TWT operation are the system logs to inspect system behaviour and a packet sniffer to observe over-the-air behaviour. A voltage/current power analyzer can help to better understand the sleep behaviour of the TWT STA, and understand the time spent in sleep, wake, and transmitting. ## 5 What to Expect The intention behind the 802.11ah TWT feature is to provide a mechanism for low-power, low-throughput devices to sleep for long periods of time and then wake up briefly to report some uplink data. The following points outline some points to note when using this functionality. 1. iPerf and other high-throughput traffic will not work well, nor will TCP traffic in general. * TWT-sleeping STAs cannot transmit or receive traffic outside of the configured service period. 2. The AP cannot reliably deliver broadcast traffic to a TWT sleeping STA 3. Service period is signalled by the STA sending a QOS NULL at the start and end of the service period to indicate wake & sleep respectively. Also to ensure that TWT functions as expected, please note the following: * IPv6 can cause unexpected periodic traffic from the STA (due to router solicitation), which will prevent the STA from entering TWT sleep. It is recommended to disable IPv6. * When the PTKSA expires (by default after 12 hours), the STA will need to disconnect and reconnect. Since the STA may be asleep for long periods it may miss this re-key and get disassociated. The STA should re-negotiate a TWT agreement with the AP upon reassociation. If desired, it is possible to disable re-keying, though this is not recommended for production setups. To do this set the following values in hostapd.conf:\ wpa\_ptk\_rekey=0\ wpa\_group\_rekey=0 * HostAPD has a BSS max idle period after which a non-responding STA will be deassociated and deauthenticated. To reduce the amount of wake ups the STA needs to send keepalive frames, this interval should be set to the maximum value. ## 6 References For more details on TWT, refer to the following chapters of the 802.11-2020 and 802.11ax-2021 standard: | Chapter | Title | | --------- | ------------------------------------ | | 10.47 | Target wake time (TWT) | | 9.4.2.199 | TWT Element | | 9.4.1.60 | TWT Information field | | 9.6.24 | Unprotected S1G Action frame details | | 11.2.3.5 | Power management with APSD | | 26.8 | TWT Operation | ## ## 7 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | --------------- | | 01 | 08/04/2024 | Initial release | Approvers: Chad O’Neill (VP of Applications), Matthew Forgie (Director of Software Applications). # APPNOTE-13 Morsectrl Guide v2 [Download as PDF](https://www.morsemicro.com/resources/appnotes/MM_APPNOTE-13_Morsectrl_Guide.pdf) ## 1 Scope This application note applies to products containing the ‘morsectrl’ Linux software package that is run on the Morse Micro MM6108 chip. The Morse Micro package ‘morsectrl’ is a tool created to send and receive commands from/to the Morse Micro chip. This document outlines the most frequently used commands. Please note that ’morsectrl’ is designed for engineering testing and evaluation purposes only. Changing the configuration of the device can break regulatory compliance. For issues or questions, please contact . ## 2 Frequently Used Commands This section outlines the most frequently used commands in the ‘morsectrl’ package, including a brief description, usage and instructions. ### 2.1 Duty Cycle |

duty\_cycle \
configure duty cycle mode. omit command to retrieve settings.
enable \ \[options]
\ set duty cycle in % (0.01-100.00)
-m \ mode of operation (0:spread, 1:burst). default:0
-u \ time unit of each burst record entry (us)
-o enables or disables omitting control responses from the
duty cycle budget.
disable
airtime return remaining airtime (us), (burst mode only)

| | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | The duty cycle is the percentage of time each device type operates or transmits on that channel. The command configures the duty cycle value along with the mode of operation to be used. The firmware supports two modes. * Spread - If an end-device uses the channel to transmit a frame for period Tair, then the duty-cycle restrictions will delay further transmissions by a duration Toff such that the overall duty cycle is not exceeded * Burst - This uses the concept of burst cycle. A burst cycle is a full cycle of Tair and Tidle. Tburst is a configurable duty cycle parameter, used to characterize the duration of a burst cycle. Using different values of Tburst, the duty cycle algorithm can be adjusted to address different use cases. ### 2.2 Version | version prints firmware version | | ---------------------------------------------- | Dumps the version string of firmware and ‘morsectrl’. ### 2.3 Serial | serial reads the chip serial number from OTP (zeroes if none blown) | | ----------------------------------------------------------------------- | Reads the chip serial number. ### 2.4 MCS | mcs \ selects mcs mode(0\~9) or type (auto) for auto rate control | | ---------------------------------------------------------------------------------- | Sets the MCS rate to use from 0-9. If ‘auto’ is selected, the MCS will be determined by the rate control algorithm. The ‘mcs’ command will only fix the MCS index at which the packets are sent. This command is deprecated and the ‘txrate’ command should be used instead. ### 2.5 TX Rate \|

Usage:
morsectrl -i wlan0 txrate \[enable|disable]
'enable' must always be included when configuring a parameter to force
‘disable' will reset all forced rate parameters
-m \ MCS index (0-10) or (-1) to use default in firmware
-b \ tx bandwidth in MHz or (-1) to use default in firmware
-f \ duplicate format (0, 1, 2) or (-1) to use default in
firmware
-t \ traveling pilots (0, 1) or (-1) to use default in
firmware
-s \ short guard interval (0, 1) or (-1) to use default in
firmware

| \| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | The ‘txrate’ command provides more control over the tx rate compared to the aforementioned ‘mcs’ command. This command fixes the rates to use by fixing the MCS, guard interval, bandwidth, travelling pilots and the tx duplicate format. ### 2.6 JTAG | jtag \ \[GPIO] disable\|enable jtag through RPi GPIO pin | | ----------------------------------------------------------------------------- | Enables or disables the JTAG pin on the chip ### 2.7 Statistics |

stats \[options] reads/resets stats (all cores if none were mentioned)
-a App core
-m Mac core
-u Uphy core
-j outputs stats in a json format
-p outputs stats in a human-readable json format
-r resets stats for mentioned cores (resets all if none
were mentioned)
-f "key" filters stats according to the given key (case
sensitive)
-s filename the location of the firmware ELF

| | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | The ‘stats’ command dumps the chip statistics from the app, mac and phy cores. Individual statistics of different core can be obtained by passing the following arguments to ‘morsectrl stats’: * -m (for mac) * -u (for phy) * -a (for app) If none of the above arguments is given then ‘morsectrl’ will dump the statistics from all the cores. Additionally the -r argument can be used to reset the chip statistics. This will reset the stats on all the cores. The -f command can be used to filter out any stats based on the key provided. The table below outlines all statistics dumped by the ‘morsectrl stats’ command. NOTE: During power save operation the PHY statistics will reset each cycle *** ## | App Stats | | | ----------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |

retry table:
Retry Count Avg Time

| Number of retries for a packet. | | commands received | Commands received by the apps core | | commands responded | Commands responded by the apps core | | commands repeated | Number of commands that were repeated | | commands failed | Number of times the device failed to send a command | | commands response failed | Number of time the device failed to respond to a received command | | commands pending | Number of commands pending to be processed | | commands late | Number of times there is a late response for a command which will already have been timed out | | last host ID | | | total\_fh\_page\_irq | Number of times the from host pager interrupt was fired | | total\_fh\_pages | Number of time the device successfully got the data from host after the fromhost interrupt was triggered | | total\_th\_page\_irq | Number of times the to host pager interrupt was fired | | total\_th\_pages | Number of time the device successfully sent the data to host after the to host interrupt was triggered | | Aon clk long calibration | Number of times the Aon clock was calibrated | | Aon clk frequency | Value of the Aon clock frequency in Hz | | Aon sleep duration adjusted for clock tolerance | Increments if the aon-clk cant handle the sleep-duration | | number of PS\_sleep | Number of times the chip when to sleep | | woke from PS (timer) | Number of times the chip woke up due to the timer set by the dynamic ps timeout value | | woke from PS (pin) | Number of times the chip woke up by the host wake up pin | | Pager from\_host reaped | Number of times the from host page has been pushed back to the pager | | Pager to\_host reaped | Number of times the to host page has been pushed back to the pager | | to\_host pages dropped (host in standby) | | | Invalid pages received | Total invalid pages received | | Events to host sent | Number of events sent to the host | | Events to host failed | Number of events the failed to be sent to the host | | ARP requests detected | Information of the ARP packets. This will only be populated if the driver is loaded using enable\_arp\_offload modparam | | ARP requests answered | Information of the ARP packets. This will only be populated if the driver is loaded using enable\_arp\_offload modparam | | ARP requests dropped | Information of the ARP packets. This will only be populated if the driver is loaded using enable\_arp\_offload modparam | | ARP requests let through | Information of the ARP packets. This will only be populated if the driver is loaded using enable\_arp\_offload modparam | | No page for ARP response | Information of the ARP packets. This will only be populated if the driver is loaded using enable\_arp\_offload modparam | | ARP table updated | Information of the ARP packets. This will only be populated if the driver is loaded using enable\_arp\_offload modparam | | ARP gratuitous generated | Information of the ARP packets. This will only be populated if the driver is loaded using enable\_arp\_offload modparam | | tx\_status none to send | Increments when there is no tx status cached | | tx\_status couldnt get page | Increments when there is no cached page for tx status information | | tx\_status dropped | Increments if the tx status was dropped and not sent to host | | tx\_status buffer flushed | Number of times the tx status buffer was flushed as there were no pending tx status | | tx\_status transmission corrupted | Increments if the driver has inadvertently popped the same page twice for use in TX and has likely corrupted the original/new transmission | | Wake action frames handled | | | pageset stats: | | | Pageset 0 | Pages sent from the host to the chip | | allocated | Number of from host pages used | | total | Total number of from host pages used | | Pageset 1 | Pages sent to the host from the chip | | allocated | Number of to host pages used | | total | Total number of to host pages used | | Apps main task unused stack (words) | | | Apps timer task unused stack (words) | | | RTOS heap free bytes | | | IPv4 Packets received | Number of ipv4 packets received | | TCP Packets received | Number of TCP packets received | | UDP Packets received | Number of UDP packets received | | DHCP Packets received | DHCP information. This will only be updated if the driver is loaded with enable\_dhcpc\_offload modparam | | DHCP discoveries sent | DHCP information. This will only be updated if the driver is loaded with enable\_dhcpc\_offload modparam | | DHCP requests sent | DHCP information. This will only be updated if the driver is loaded with enable\_dhcpc\_offload modparam | | DHCP lease updates sent | DHCP information. This will only be updated if the driver is loaded with enable\_dhcpc\_offload modparam | | DHCP leases fully expired | DHCP information. This will only be updated if the driver is loaded with enable\_dhcpc\_offload modparam | | DHCP leases obtained | DHCP information. This will only be updated if the driver is loaded with enable\_dhcpc\_offload modparam | | DHCP leases renewed/rebound | DHCP information. This will only be updated if the driver is loaded with enable\_dhcpc\_offload modparam | | Standby wakeup frame rx | The standby mode requirements will be facilitated by powering off the host when not sending or receiving traffic. The host will be powered on by toggling a GPIO address.This can be enabled by morsectrl standby command | | Standby status frame (standby) tx | The standby mode requirements will be facilitated by powering off the host when not sending or receiving traffic. The host will be powered on by toggling a GPIO address.This can be enabled by morsectrl standby command | | Standby status frame (awake) tx | The standby mode requirements will be facilitated by powering off the host when not sending or receiving traffic. The host will be powered on by toggling a GPIO address.This can be enabled by morsectrl standby command | | To mcu wake pin toggle | The standby mode requirements will be facilitated by powering off the host when not sending or receiving traffic. The host will be powered on by toggling a GPIO address.This can be enabled by morsectrl standby command | | Standby SA Query request tx | The standby mode requirements will be facilitated by powering off the host when not sending or receiving traffic. The host will be powered on by toggling a GPIO address.This can be enabled by morsectrl standby command | | RX corrupt dot11 action frames | Number of corrupted rx action frames | | BSS keep alive tx | Number of keep alive frames transmitted | | TWT failed to flush tx status before umac pause | Number of times the device failed to flush TX status buffer before sending TWT UMAC traffic update | | System uptime (us) | | | **Mac Stats** | | | No A-MPDU candidate | Number of packets not send as an AMPDU | | commands expired in MAC req | Number of requested command failed by mac core | | commands expired in MAC resp | Number of responded command failed by mac core | | MPE reset | Number of times the MPE was reset | | DCF STF fired | Number of time the STF was fired | | DCF LTF fired | Number of time the LTF was fired | | DCF energy detect fired | Number of time the energy detect was fired | | DCF aborted | Number of times the TX was aborted by the mac. This would trigger a backoff for the packet to be TX'ed | | DCF granted | Number of time TX was allowed by the mac | | DCF medium busy before tx | Number of time the chip decided to TX but the medium was busy | | beacon loss | Number of time the beacon loss was reported back to the host | | beacon changed | Number of times the beacon has been changed. This would update if short beacons were being sent along with full beacons | | beacon rssi changed | Beacons rssi change comparing to the last beacon sent | | aid in tim | Number of times the AID bit in the tim information element is set. | | tim contains aid, but STA awake | Number of time the AID bit in the beacon is set but the station is not in sleep state | | tim group address | Number of beacons with bitmap control field in the tim information element is set | | tim nothing | Number of times the beacons do not indicate that there is traffic present for the station | | tim populated | Number of beacons with the block info data in the tim information element | | DTIM\_sleep\_stats | The number of DTIM beacons received by the station | | CTS\_sleep\_stats | | | CTS\_PS frame arrived late | | | AGG N aggregates total | Total number of packets that were allowed to be sent as AMPDU | | AGG N aggregate rounds | Total number of AMPDUS sent | | AGG N aggregates | This stats shows the number of aggregation for every packet sent. The chip supports sending an AMPDU with 16 MPDUS in them. From the stats 46 packets are sent without aggregation, 19 sent with 1 mpdu aggregated, 5 sent with 2 mpdu aggregated and so on | | AGG TX rate is NULL | These stats represent the reasons why the chip has decided to break the aggregation. | | AGG TX rate mcs not same | These stats represent the reasons why the chip has decided to break the aggregation. | | AGG TX param mismatch | These stats represent the reasons why the chip has decided to break the aggregation. | | AGG TX max txop exceeded | These stats represent the reasons why the chip has decided to break the aggregation. | | AGG TX active txop exceeded | These stats represent the reasons why the chip has decided to break the aggregation. | | AGG TX length exceeded | These stats represent the reasons why the chip has decided to break the aggregation. | | AGG crosses tbtt | These stats represent the reasons why the chip has decided to break the aggregation. | | AGG crosses twt sp end | These stats represent the reasons why the chip has decided to break the aggregation. | | AGG crosses RAW slot | These stats represent the reasons why the chip has decided to break the aggregation. | | AGG crosses scheduled tx ts | These stats represent the reasons why the chip has decided to break the aggregation. | | RX Total | Total number of RX frames | | RX Pass FCS | Total number of RX frames with correct FCS | | RX Sig Field Err | Total number of RX frames with signal field errors | | RX buffer unavailable | Number of times the chip did not have RX buffers available | | RX MAC was too slow | Number of times the chip did not RX mac path was slow | | TX Total | Total number of packets sent on air | | TX Revoked | Total number of times the TX was rejected due to STF, LTF or energy present in the medium | | TX non-contending NDP revoked | | | TX Lifetime expired | Total number of times the lifetime timestamp of the packet that expired. This will unschedule and drop the packet | | TX returned to UMAC due to power save | Total number of packet returned to the host for buffing as the station was asleep | | TX dropped due to power save | | | TX pkt lifetime us | Packet lifetime value in microseconds | | TX Malformed frame | Number of packets with invalid mac header length | | TX QoS NULL | Number of QOS null frames sent | | TX ACK Valid | Number of times the TX packet was acknowledged with a valid ACK | | TX ACK Timeout | Number of times the ACK timeout for the packet sent | | TX CTS Timeout | Number of times the CTS was timeout for the RTS frame sent | | Longest delayed TX ACK (in uS):38 | Record the longest delayed ACK time | | TX ACK already finished | The transmission of ACK packet was finished but ack timeout was triggered | | TX ACK Invalid (FCS) | Number of times the ACK is invalid due to FCS failure | | TX ACK Invalid (scrambler) | Number of times the ACK is invalid due to ackid scrambler value was wrong | | TX ACK Invalid (orphaned) | Number of times the chip saw and ACK not meant for it | | TX ACK lost | Total number of ACK that was not received by the device for the packet it sent | | TX CTS lost | Total number of CTS that was not received by the device for the RTS packet it sent | | TX fragment | Total number of packets sent as fragments | | TX BlockAck | Total number of blockack sent | | RX BlockAck | total number of blockack received | | TX NDP ACK | total number of ndp acks (not blockacks) sent | | TX round-trip success % | Percentage of the data sent that were successfully acked by a NDP ack or a blockack | | TX requests | Total number of time the mac has requests the phy to send the packet | | TX avg backoff slots | Average of accumulated backoff slots | | TX medium collisions | Number of times the packet was sent was not acked. | | TX Encryptable pkts | Number of time the chip prepared a frame for encrypted transmit | | TX ReEncryptable pkts | Number of times the chips tries to encrypt the frame that has already been encrypted | | TX Unencryptable pkts | Number of times the chips was not successful in finding a key AND the host marked this packet as being protected | | RX transaction(s) dropped | Number of times the RX frames was dropped | | RX Undecryptable ccmp pkts passed to host | Number of times the frame wasn't decryptable and was passed up to the host. Could be an encrypted frame that chip was unable to find a key for | | RX Decryptable pkts | Total number of RX frames decrypted | | RX Undecryptable pkts | Total number of times the chips was not able to decrypt the RX frames | | Unexpected crypto | Invalid | | RX MPDU delimiters Invalid | Number of delimiters that was corrupted when receiving MPDU's | | RX MPDU delimiters | Number of valid MPDU delimiters | | BEACONS RX | Number of beacons received | | BEACONS TX | Number of beacons sent | | BEACONS TX delayed | Number of beacons that were delayed to be sent on air | | BEACONS late from host | Number of beacons sent late by the host to chip to go out on air eventually | | BEACONS late from host delay (avg uS) | Average time of beacon when the host was late to send it to the chip | | TX NDP Probe Req | Number of NDP probe request sent | | RX NDP Probe Req | Number of NDP probe request received | | TX RTS/CTS max attempts reached | Number of time the chips reached it maximum retry limit for RTS/CTS exchange | | TX RTS | Total RTS frames sent | | TX CTS | Total CTS frames sent | | RX RTS | Total RTS frames received | | RX CTS | Total CTS frames received | | RX CTS Invalid (orphaned) | Number of CTS frames that were not meant for the device that received it | | TX RTS/CTS success | Percentage of successful RTS CTS exchange | | MPE started | Invalid | | MPE Rx peeked for key | Invalid | | RX no key found in key inspection | Invalid | | MPE Rx loaded key | Invalid | | MPE Rx done | Invalid | | MPE IRQ count | Number of time the MPE interrupt was fired | | MPE YDS in-queue pre-start | Invalid | | RX transaction(s) total | Number of times the phy informed the mac of an available RX packet | | RX NDP total | Number NDP packets received | | RX A-MPDU/S-MPDU | Number of AMPDU/SMPDU that were received | | RX Non-A-MPDU/Non-S-MPDU | Number of packets received that were not AMPDU's/SMPDU's | | Total RX MPDUs found by MPE | | | Total RX empty delims | Number of MPDU with their delimiter empty | | RX transactions without any MPDUs to process | | | RX no valid first frame | Number of times the first MPDU receives is not valid | | RX MPDUs with FCS fail | Number of times the RX MPDU failed with wrong FCS | | RX MPDUs with MIC fail | Number of times the RX MPDU failed with wrong MIC | | RX MPDUs with unknown MAC header | RX with invalid mac header | | RX YDS alloc fail | Invalid | | RX PV1 MPDUs | Invalid | | MPE RX which could be decrypted with a 2nd pass | Invalid | | RX transactions without any response | Invalid | | RX MPDUs not for us | Number of frames that were not meant for the device receiving it. | | RX AMPDU bitmap 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 | Number of bits set in the bitmap field of the blockack received. | | TXOP: TXOP count | Number of packets that are in TXOP | | Total TXOP time | This is the TXOP end time minus the TXOP start time | | Average TXOP time | This is the average TXOP end time minus the TXOP start time for all packets | | Total TXOP Tx packets | Number of packets that are in TXOP | | Average TXOP Tx packets | Average number of packets that are in TXOP | | RAW: | | | RAW Assignments | | | Valid | Number of RAW assignments. Currently only supporting up to 8 assignments | | Truncated by tbtt | Number of times an assignments that get truncated due to the next tbtt | | Invalid | Number of invalid assignments (/unsupported) observed | | Already past | Number of assignments that are valid but system time has already passed | | Delayed due to RAW | | | From aci queue | ACI delayed frames due to RAW | | From bc/mc queue | Broadcast / Multicast delayed frames due to RAW | | From abs time queue | Absolute time frames delayed due to RAW | | Frame crosses slot | Frames that could've been sent in the RAW but were too long for slot | | CALIB: | | | Managed Calibration | | | Quiet calibration granted | A quiet calibration was granted | | Quiet calibration rejected | A quiet calibration was rejected | | Quiet calibration cancelled | A quiet calibration was in progress, but then cancelled | | Non-Quiet calibration granted | A non-quiet calibration was granted | | Calibration complete | A quiet/non-quiet calibration completed | | Duty Cycle: | | | Duty Cycle Target (%) | Configured duty cycle restriction | | Duty Cycle TX On (us) | Total transmitter 'on air' (Tair) time in usec | | Duty Cycle TX Off (Blocked) (us) | Total transmitter 'blocked' (Toff) time in usec | | Duty Cycle Max toff (us) | Maximum time the t\_off timer is started for | | Duty Cycle Early Frames | Number of packets ignoring duty cycle restrictions | | Duty Cycle illegal transmission | Increments if there was a transmission outside the duty cycle used | | Duty Cycle traffic dropped (NDP) | Number of NDP frames dropped because of duty cycle restrictions | | Duty Cycle traffic dropped | Number of non NDP frames dropped because of duty cycle restriction | | WUP QosNull not acked | Number of times the QOS Null frames was not acked | | QosNull resent | Number of times the QOS null frames was re transmitted | | QosNull queued behind another | Number of times there are multiple QOS null framed queued to be sent | | QosNull tx backing off | Number of times QOS null frame fails before the MAC gives up on trying to send PS updates | | MAC State: | These are the states that the mac core stores internally. | | | | | RX state | These are the states that the mac core stores internally. | | TX state | These are the states that the mac core stores internally. | | Channel config | These are the states that the mac core stores internally. | | Managed calibration state | These are the states that the mac core stores internally. | | Powersave enabled :1 | These are the states that the mac core stores internally. | | Dynamic powersave offload enabled :1 | These are the states that the mac core stores internally. | | STA PS state | These are the states that the mac core stores internally. | | Is waiting on dynamic powersave timeout | These are the states that the mac core stores internally. | | TX blocked by host cmd | These are the states that the mac core stores internally. | | Is waiting for medium sync | These are the states that the mac core stores internally. | | N packets in QoS queues | These are the states that the mac core stores internally. | | Stale AID removed | These are the states that the mac core stores internally. | | MAC main task unused stack (words) | | | MAC timer task unused stack (words) | | | TWT sta num sp entered | Number of times the device enters the TWT service period | | TWT sta enters sp too early | Number of times the device enters the TWT service period early | | TWT sta missed sp (already over) | Number of times the device completely missed the TWT service period | | TWT sta missed start of sp (already started) | Number of times the device missed the start of the service period | | TWT sta sp already active on ps wake | Number of times the device is in active TWT and is out of powersave | | TWT announcement delay from sp start (avg us) | Average time for the service period delayed from its start | | TWT operation halted | Number of times the TWT operations is halted | | TWT operation resumed | Number of times the TWT operations is resumed | | TSF for sta has been (re)set | TSF timer has been reset | | Standby exit from wakeup frame | Standby frames stats | | Standby exit for association | Standby frames stats | | Standby exit from userspace | Standby frames stats | | Standby SA Query response rx | Standby frames stats | | Standby SA Query response timeouts | Standby frames stats | | Standby deep sleep enter | Standby frames stats | | Standby deep sleep exit (assoc) | Standby frames stats | | Standby deep sleep exit (no assoc) | Standby frames stats | | Vendor IEs matching OUI filter | Increments if the vendor information element has a matching oui (Organizationally unique identifier) | | PHYPSM MAC IRQ status zero count | Invalid | | PS scheduled after beacon miss | Number of times the device would go into power save if it misses a beacon | | PS scheduled after pin wake | Number of times the device would go into power save after the host indicated to be awake via the wake pin | | **Phy Stats** | | | Temperature(Celcius):45 | Temperature of the chip | | Vbat(mV) |


Shows the voltage of the battery. This is updated every 60 second and should remain constant

| | PMU Switched to Vbat setting (mV) | VBAT calibration and sets the PMU settings accordingly | | Vbuck Trim | Shows the stats for buck voltage, for transmission (TX) it should be highest 12, for ideal or receiving (RX) state it should be 5 and for power save mode it should be 0. | | Current RF frequency Hz | Current channel information | | Current Operating BW MHz | Current channel information | | Current Primary Channel BW MHz | Current channel information | | DCF medium went busy after go | Number of times the medium went busy after the PHY decided to transmit the frame | | DCF medium went busy during start | Number of times the medium went busy when the PHY decided to transmit the frame | | DCF time in past | Number of times the time for the frame to be sent was in the past | | MPE RX overflow | Number of time the RX source buffer overflowed | | MPE RX underflow | Number of time the RX source buffer underflowed | | RX detected less than guard IFS | Shows that the receiver detects the data faster and not enough Interface frame spacing. | | TX Scrambler Init Value | The TX scrambler init value | | RX Scrambler Decoded Byte | Shows the decoded scrambler value which is based on the TX Scrambler Init Value in the received packet. | | Signal Field Error | Signal field errors reported from PHY | | Packet Detect Fired STF | Number of times the STF was fired | | Packet Detect Fired LTF | Number of times the LTF was fired | | Packet Detect Timestamp (us) | Time at which the last packet detect was triggered | | Non-NDP PSDU Rx | Number of PSDU that are not NDP | | Coarse Frequency Offset | Shows the coarse frequency offset as an angle. Coarse frequency offset in Hz | | Final Frequency Offset:-540 | Shows cores + fine value and it shows the Frequency Offset of local oscillator, unit (Hz). | | Detected Sub-Band | Winning STF Correlator. If a wrong correlator is triggered, the classification algorithm corrects it for LTF search and before writing to statistics. | | Corr0 Power | The accumulated max peak power of every peak detected up to STF triggering | | Corr1 Power | The accumulated max peak power of every peak detected up to STF triggering | | Corr2 Power | The accumulated max peak power of every peak detected up to STF triggering | | Corr3 Power | The accumulated max peak power of every peak detected up to STF triggering | | Corr4 Power | The accumulated max peak power of every peak detected up to STF triggering | | Corr5 Power | The accumulated max peak power of every peak detected up to STF triggering | | Corr6 Power | The accumulated max peak power of every peak detected up to STF triggering | | Corr7 Power | The accumulated max peak power of every peak detected up to STF triggering | | Corr8 Power | The accumulated max peak power of every peak detected up to STF triggering | | AGC Gain | Value of the AGC gain used | | AGC LNA Status | Value of the LNA status | | AGC FEM Rx Gain | Value of FEM rx gain | | AGC LNA Bypass | If LNA bypass is used | | AGC Interference Detected | If interference was detected by the AGC | | Received Power:-37 | Signal strength of the last received frame | | Detected Channel BW | This is the detected channel bandwidth ( also referred to as Primary channel bandwidth) of the received signal | | STF Status | This parameter indicates which correlators reached min peaks by the STF triggering time and it’s been used in mode classification algorithm | | Energy Meter Reading | This parameter denotes the total in-band energy for a Rx signal at the time of STF triggering | | Energy Meter threshold | Energy meter threshold value used | | Noise dBm | Noise level of the medium | | Detected RX Mode | The format of the packet received by the device. The values can be s1g format, Duplicate 1MHz format, Duplicate 2MHz format or a long format | | Oper BW Indicator | Denotes the detected operating channel bandwidth of the received signal | | Corr2S Energy | Indicates the energy in the secondary 2MHz subchannel. | | Corr4S Energy | Indicates the energy in the secondary 4MHz subchannel. | | Noise Metric 2 | This is the noise metric for correlator C2P | | Signal Metric 2 | This is the signal metric for correlator C2P | | Range Select | This parameter indicates the starting bit position to select 8 bit range out of the 16 bits as the input range for packet detect | | TX Abort(s) | if value is greater than 1, it's the number of times tried for transmission and aborted. The value will be 0 is transmission was successful | | TX Stale(s) | Increments if a stale TX is detected | | TX Underflow(s) | Shows how many times the mac that requested date to TX to the PHY and the PHY was unable to get the data fast enough | | RX Filtered | Number of time the PHY received data that was not meant for it | | DGC Energy Meter Pwr dB | Invalid | | DGC Inband Pwr dB | Invalid | | DGC Diff Pwr dB | Invalid | | DGC BackOff Pwr dB | Invalid | | DGC CoffFactor Pwr dB | Invalid | | DGC Multiplier | Invalid | | DGC Shift | Invalid | | TX Traveling Pilots | Number of times the packet was transmitted using traveling pilots | | Max Stack Used | | | min\_neset | The minimum noise estimate of the medium | | NB INTRF Detected | If there was interference detected | | NB INTRF Subc nulled | Shows that the sub carrier are null or not. | | NB INTRF Num Subc nulled | Shows how many sub carrier are null. | | NB INTRF Index | Shows which sub carrier is determined by interference detection to have interference. | | NB INTRF Num | Shows how many times we have detect interference. | | NB INTRF SIR dB | Shows the signal to interference ratio , unit (dB). | | NB INTRF Power dBm | Shows the received interference power on a narrow band in dBm. | | FSG tx rounds | shows the count of fast symbol generator transmit. | | DC locked state I | Shows the state of the high pass filter for I (IQ samples). | | DC locked state Q | Shows the state of high pass filters and Q (IQ samples). | | LTF Corr Power | Shows the power of a long training field. | | STF number of peaks | shows the number of peaks on a short training field. | | Avg ring osc freq mhz | show the average frequency of ring osc which is used to identify the process corner chips. | | ring osc0 count | show the count of ring osc 0 which is used to identify the process corner chips | | ring osc1 count | show the count of ring osc 1 which is used to identify the process corner chips | | ring osc2 count | show the count of ring osc 2 which is used to identify the process corner chips | | ring osc3 count | show the count of ring osc 3 which is used to identify the process corner chips | | ring osc4 count | show the count of ring osc 4 which is used to identify the process corner chips | | Tx subband centre frequency Hz | Invalid | | Tx subband operating BW MHz | Invalid | | Tx subband primary channel BW MHz | Invalid | | Tx subband primary index | Invalid | | Tx subband channel changed count | Invalid | | SIG\_FIELD\_FAIL BAD STF | Number of bad STF detected | | SIG\_FIELD\_FAIL BAD LTF | Number of bad LTF detected | | SIG\_FIELD\_FAIL CRC Error | Number of failed CRC check | | Servo Gain | Invalid | | I trim | Invalid | | Q trim | Invalid | *** ### 2.8 Channel \|

channel \[options]
sets channel parameters or read associated or full channel frequency if none of \[-c|-o|-p|-n] given
-a prints all the channel i.e. Full, DTIM and current
-c \ channel frequency in kHz
-o \ operating bandwidth in MHz
-p \ primary bandwidth in MHz
-n \ primary 1 MHz channel index
-r ignores regulatory max tx power
-j prints full information in easily parsable JSON format

| \| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | The ‘channel’ command is used to set or dump the channel information for the device. If no options are given then the command will dump the current channel information that is being used by the device. If the above arguments are used then the command will configure the device to use the specified channel information. ### 2.9 FSG (Fast Symbol Generator) |

fsg \
enable \ \ \[ifs]
iterations number of transmissions, set to -1 for
infinite
duty cycle the duty cycle to maintain between
transmissions %(0.01-99.99)
ifs inter-frame spacing between PSDUs in
microseconds (default:160us)
disable

| | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | For FCC and other regional-specific certification testing at high duty cycle and is enabled by using the testing firmware version titled ‘mm6108\_dvt.bin’’. This command will configure the firmware to transmit data at the given duty cycle with the provided IFS either indefinitely or for the given number of iterations. The content of the transmission contains valid LTF+STF+SIG fields, but not necessarily valid 80211 data. PSDU content can be random or pseudo-random (i.e. incrementing, non-zero). *** ### 2.10 MAC Address WARNING: Once set, this is not reversible It is important that VDDIO be provided as 2.5V before writing the MAC address.\ For more information, please refer to the ‘MAC OTP Read and Write’ guide. |

macaddr \[-w \] reads the MAC address of the chip if -w was
not passed
-w \ writes the given 'XX:XX:XX:XX:XX:XX' MAC
address to the chip (this is not reversible)

| | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | Read and write the MAC address that the WLAN interface will be configured to. |

Example usage:
# morsectrl macaddr -w 0c:bf:74:05:dc:71
Chip MAC address: 0c:bf:74:05:dc:71
# ifconfig
wlan0 Link encap:Ethernet HWaddr 0C:BF:74:05:DC:71
inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0

| | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ### 2.11 Wakeaction |

wakeaction \ \
sends a wake action frame of given payload to a
destination mac address.

| | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | This command sends a wakeaction frame from the AP to the desired station. On reception of the wake action frame a GPIO can be toggled which in turn could be used to wake the host up. This command requires the GPIO to be set by the Board Configuration File (BCF). *** ### ### 2.12 DHCP \|

dhcpc \[enable | discover | get | clear | renew | rebind | update]
configure DHCP client
enable - enable DHCP client
discover - do a discovery and obtain a lease
get - get the current lease
clear - clear the current lease
renew - renew the current lease
rebind - rebind the current lease
update - send a lease update to the driver

| \| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | This command is only applicable if the driver has been loaded with enable\_dhcp\_offload modparam. With this feature enabled the leases can be renewed without having to wake up the host processor. Through this method, assuming a DHCP server is running somewhere on the network, the station should receive, and automatically apply, an IP address within 10 seconds of associating. If currently leased address needs to be updated, it can be triggered with the following ‘morsectrl’ command: | # morsectrl dhcpc update | | ------------------------ | Note that this will only apply a lease if enable\_dhcpc\_offload is set to 1.\ The lease can be obtained manually as well but note that this is intended only for testing and verification purposes and should not be used in normal operations. The steps to manually do this: * On an associated, running station, enable the DHCP client with the following ‘morsectrl’ command: | # morsectrl dhcpc enable | | ------------------------ | * Within 10 seconds, the client should automatically perform a discovery and obtain a lease.\ To shortcut this, and perform a discovery now, execute the following command: | # morsectrl dhcpc discover | | -------------------------- | * The lease can be retrieved using: | # morsectrl dhcpc get | | --------------------- | * To force a DHCP renewal or rebinding sequence with the following commands: |

# morsectrl dhcpc renew
# morsectrl dhcpc rebind

| | ---------------------------------------------------------- | Note that if the DHCP client is enabled and does not have a lease, it will attempt a discovery sequence every 1-10 seconds, as per the RFC. ### *** ### ### 2.13 QoS |

qos \[options] \ sets/reads QOS parameters for given queue ID
-c \ number of AIFS slots to wait for
-t \ maximum possible TX OP in us
-m \ \ contention window MIN,MAX values

| | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | This command sets access category parameters or reads the current values of the different access categories. There are 4 access categories that can be read or configured :- 1. Best effort 2. Background 3. Video 4. Voice If configuring the access category the following options can be uses along with the queue that wants to be configured: * -c: AIFS slots (Arbitration Inter Frame Spacing) - The minimum wait time before accessing the medium. * -t: TX OP - The Transmission Opportunity (TXOP) is an interval of time, in milliseconds, when a client has the right to initiate transmissions towards the AP. * -m: Contention window values - The window defines the min and max contention time of various stations who contend with each other for access to channel *** ### ### 2.14 Random Packet Generator (RPG) |

rpg \
start \[options] starts rpg
-l listening mode (other options are overlooked)
-c \ number of packets to send (default unlimited)
-s \ specifies the size of the packets to be sent (min: 24).
Random if not specified.
-d disables random packet contents (for casim)
stop terminates rpg (if started)
stats \[options] reads rpg stats collected (if started)
-r reset the rpg stats (if started)
srcaddr \[mac address] sets source mac address of rpg packets
dstaddr \[mac address] sets destination mac address of rpg packets
ampdu \[number] force using ampdu with \[number] mpdu

| | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | This is a random packet generator (RPG) that is enabled by using the testing firmware version titled ‘mm6108\_dvt.bin’’. This feature is mainly used for test, debugging and development purposes. When using RPG, TX packets originate from the Apps core - not from the driver. On the RX side it counts the number of packets that were received and were successfully decoded. ### 2.15 Bandwidth \|

bw \ sets bandwidth(1|2|4|8) or reads current bandwidth if no
arguments were given

| \| ---------------------------------------------------------------------------------------------------------------- | Sets the bandwidth value. Once the devices are associated the bandwidth value cannot be changed. This is deprecated. ### 2.16 TX Scaler |

txscaler \ scales tx power (takes values -15 to +15 dB)

| | ---------------------------------------------------------------------------- | The ‘txscaler’ command is used mainly for bench evaluation and experimentation purposes. This command takes the values in dB and boosts or backs off the default transmit power by the given value. It can take the values from -15 dB to +15 dB. Note that this should not be used for normal operation as it can break region specific regulatory rules. ### 2.17 OTP WARNING: It is important that VDDIO be provided as 2.5V before writing to OTP.\ For more information, please refer to the ‘MAC OTP Read and Write’ guide. |

otp \ \[-w \] read/write OTP bank given from chip
bank\_num bank number to read/write from/to. eg.: for
610x \[0-7]
-w \ burns the value to the OTP bank

| | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | The ‘otp’ command can be used to read and write the OTP bits programmed to the chip. |

# morsectrl otp 0
OTP Bank(0): 0x0

| | -------------------------------------------- | To read the OTP bits for all the banks \[0-7]: |

# morsectrl otp \[0-7]
Output:
OTP Bank(0): 0x0
OTP Bank(1): 0x0
OTP Bank(2): 0x800000
OTP Bank(3): 0x0
OTP Bank(4): 0x0
OTP Bank(5): 0x60daf38d
OTP Bank(6): 0x0
OTP Bank(7): 0x0

| | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | To write the bits in decimal value: |

# morsectrl otp 3 -w 4194304
Output:
OTP Bank(3): 0x400000 (Hex value)

| | ----------------------------------------------------------------------------------- | To write the bits in hex value: |

# morsectrl otp 0 -w 0x700000
Output:
OTP Bank(0): 0x700000

| | ------------------------------------------------------------------------ | ### 2.18 A-MPDU \|

ampdu \[enable|disable]
'enable' will enable AMPDU sessions. Must be run before
association.
'disable' will disable AMPDU sessions. Must be run before
association.

| \| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | The ‘ampdu’ command is responsible for enabling or disabling the AMPDU feature in the chip. This command should be executed before the device is associated. The command will show no effect if executed after association. ## 3 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | --------------------------- | | 01 | 26/06/2023 | Initial document release | | 02 | 16/12/2024 | Revised document formatting | # APPNOTE-15 MM6108 SDIO SPI Design Guide v5 [Download as PDF](https://www.morsemicro.com/resources/appnotes/MM_APPNOTE-15_MM6108_SDIO_SPI_Design_&_Troubleshooting_Guide.pdf) ## 1 Overview The purpose of this guide is to assist in the design and troubleshooting the bring up of an MM6108 module interfaced via SDIO or SPI on Linux-based host systems. The guide addresses the key requirements for selecting parts in a design, and outlines how to diagnose issues as well as expected behaviour. With these in hand, it should be possible to quickly resolve issues in new designs. ## 2 SPI A SPI interface provides a simple and common interface to a host processor. Compared to SDIO, it has fewer signals and is unidirectional instead of bidirectional. A SPI interface is specified at a physical layer and as such, the data transfer is less standardised than SDIO. Below are some key considerations from a hardware and software perspective. ### 2.1 Hardware When selecting a CPU host to interface via SPI to the MM6108, consider the following requirements: * The host should have a SPI compliant controller with support for SPI mode 0. * The host must support level-triggered interrupts. * The host must support full-duplex mode, as this is required by MM6108 for the SPI interface. * The SPI interface can run at up to 50 MHz clock rate, per the specification. * The host must support DMA backed transactions if full throughput is required on the SPI bus. Standard SPI can achieve up to 25Mbps at 50MHz, but this will reduce significantly if there is no DMA support. For example, an SPI interface with an 8-byte buffer per transaction might only achieve 2Mbps throughput on the SPI bus. * The PCB trace length should be kept as short as possible, as extra delay can be caused which will result in lower throughput on the SPI bus. * The MM6108 launches data on the negative edge. It is preferable to have a SPI host-side that launches on the negative edge, and samples on the positive edge in order to allow for the necessary delays. The following pins are required for SPI: | Pin | Name | SPI mode function | | --- | -------------- | ----------------------------------------------- | | 31 | CLK | Clock pin (input) | | 30 | MOSI | Master data out/slave data in | | 29 | MISO | Master data in/slave data out | | 28 | EXT\_HOST\_SEL | SDIO/SPI/QSPI interface enable strap (tie high) | | 27 | INT | Interrupt pin | | 26 | Unused | Tie High | | 25 | CS | Chip select (active low) | Note: if the waveform shape is abnormal or the timing is irregular, ensure that nothing other than the MM6108 chip and the host CPU is connected on the lines to prevent unintended interference. ### 2.2 Software #### 2.2.1 Linux-based systems * The MM6108 SPI interface adheres to the definition in the SDIO 2.0 specification * The implementation departs from the SDIO specification in two ways: 1. At least 8 clocks with CS deasserted and MOSI held high immediately after reset are required to take the SPI device hardware out of reset and allow it to power up internally. 2. CMD63 can be sent to skip the entire initialization routine of the SDIO specification. This is implemented by the Morse Micro host-side driver, so the host system does not need to handle it. The chip will return an all (8) zeros response to CMD63 indicating success of initialisation. * CS needs to be stable after being asserted, or it will prematurely finish the transaction * The MOSI line should NOT be toggled while waiting for a command response as this may interrupt the transaction * Sample waveform: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/wYGW4gtvVLDlleHie4rX/Unknown%20image) * Need to ensure just one byte of clocks is sent and then immediately deassert the MOSI and then start the command transaction * SPI mode - data clocked in on the rising edge, shifted out on the falling edge (ie SPI Mode 0) Note: MOSI state doesn't matter if there is no clock running #### 2.2.2 FreeRTOS/Microcontroller-based systems This is quite similar to the above outlined for Linux, but with a couple of differences: 1. Hard reset the device 2. Transmit at least 74 SPI clock pulses (we do this by writing 0xff with CS deasserted 16 times) 3. Write CMD63 4. If CMD63 was not successful, write CMD0 and go to step 3 above. 5. Read chip ID to validate success. *** ## 3 SDIO The SDIO protocol is a higher level protocol compared to SPI. It has a more well-defined specification that leads to less variance in implementation. As a result it requires less effort debugging of differences between the master and slave devices, and a faster turnaround to do the initial board bringup. It requires more signal connections which are mainly bi-directional. Below are some key considerations from a hardware and software perspective. ### 3.1 Hardware * Ensure that the SDIO data and command lines are pulled up by an external pull-up resistor. The expected range of the pull-up resistance should be between 10k and 100k ohms as per the SDIO Physical Specification (section 6.6.4), with 10k providing the strongest pull-up. * The voltage of the SDIO line should be 3.3V±0.3 ; if the voltage is too low, ensure that no internal pull-up resistors have been enabled on the host. * It is advisable to stress test the bus (eg iperf test) and check the rise and fall time of the SDIO lines to ensure no oddities are observed. ### 3.1 Software (Linux) * Check the toolchain/build environment to see if the MMC/SDIO/SDHCI interface is enabled * Please check the MMC/SDIO/SDHCI interface that the MM6108 module is connected to is enabled in the device tree. For example: |

\&sdhci {
status = "okay";

| | ---------------------------------------- | * Check that MM6108 is added to the device tree; either as an overlay or added to the DTS of the device. Templates for our DTS are provided in the porting guide and need to be modified for the target host system * The DTS configuration can be included as a fragment if the host system supports it. For example, on the Raspberry Pi: |

/dts-v1/;
/plugin/;
/ {
compatible = "brcm,bcm2835";
fragment\@0 {
target = <\&mmc>;
wifi\_ovl: **overlay** {
pinctrl-0 = <\&sdio\_ovl\_pins \&mm\_sdio\_pins>;
pinctrl-names = "default";
non-removable;
bus-width = <4>;
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
mm6108\_sdio: mm6108\_sdio\@0 {
compatible = "morse,mm610x";
reset-gpios = <\&gpio 5 0>; /
power-gpios = <\&gpio 3 0>, // WAKE
<\&gpio 7 0>; // BUSY or GPIO0
status = "okay";
reg = <2>;
bus-width = <4>;
};
};
};
fragment\@1 {
target = <\&gpio>;
**overlay** {
sdio\_ovl\_pins: sdio\_ovl\_pins {
brcm,pins = <22 23 24 25 26 27>;
brcm,function = <7>; /\* ALT3 = SD1 */
brcm,pull = <0 2 2 2 2 2>;
};
mm\_sdio\_pins: mm\_sdio\_pins {
brcm,pins = <1>; /* CHIP-IRQ \*/
brcm,function = <0>;
brcm,pull = <2>;
};
};
};
};

| | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | * The module can also be integrated into the device tree directly without the use of overlays. For example, the below integration with a Mediatek host: |

\&sdhci {
status = "okay";
mediatek,cd-poll;
mm6108\_sdio: mm6108\_sdio\@0 {
compatible = "morse,mm610x";
reset-gpios = <\&gpio 40 0>;
power-gpios = <\&gpio 39 0>,
<\&gpio 41 0>;
status = "okay";
reg = <2>;
bus-width = <4>;
};
};

| | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | *** ## 4 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | ------------------------------------------ | | 1 | 22/11/2022 | Initial release | | 2 | 27/04/2023 | Added section on FreeRTOS debugging | | 3 | 22/09/2023 | Revised pin assignments in code example | | 4 | 03/11/2023 | General revision and updates - Doc Control | | 5 | 28/11/2024 | Make Pin26 explicitly tied high | # APPNOTE-17 Dynamic Channel Selection v2 [Download as PDF](https://www.morsemicro.com/resources/appnotes/MM_APPNOTE-17_Dynamic_Channel_Selection_Guide.pdf) ## 1 Introduction This application note applies to products containing the Dynamic Channel Selection (DCS) feature that is run on the Morse Micro MM6108 chip. The DCS allows an AP to periodically scan available channels while a BSS is running, and seamlessly switch to a new channel if the RF conditions are better on the new channel. DCS is integrated as a module in Smart Manager, which is a Morse Micro proprietary Access Point userspace daemon. For issues or questions, please contact . *** ## 2 Workflow Smart manager tells the MM6108 chip which channels to scan, when to scan them, collate the results (Measure), decide on the best channel (Selection) and trigger the move to the new channel (Channel Switch). DCS is accomplished by periodically performing Off Channel Scans (OCS). This process consists of the AP configuring a RAW window with an unused AID, which causes all associated stations to stop transmitting during this window. During this time, the AP will temporarily switch to the off channel in question, and perform an assessment using the PHY channel metric. The PHY will then start sampling the medium, and compute a metric to be reported back to Smart Manager. This metric takes into account noise floor, interference, and WLAN traffic. It returns an opaque number between 0 and 100, with 100 being an ‘ideal’ channel. These channel metrics are then fed into an algorithm which will average them over time, and decide if/ when the channel needs to be changed. If a decision is made to change channels, the AP will signal this using an ECSA (extended channel switch announcement). ECSA is an 802.11 feature which adds an information element into the beacon which contains the parameters of the new channel, and a count-down which is decremented each successive beacon. When this countdown reaches zero, the AP and all stations will seamlessly move to the new channel and continue service as normal. Note: Smart Manager is released in binary form only. ### 2.1 DCS algorithm flow chart ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/raDK7EGmNNkBdAkhWZiA/Unknown%20image) ### 2.2 Measurement Smart Manager will utilize an Off Channel Scan (OCS) to make periodic measurements of all channels. The available channels will be queried from hostapd/mac80211 and stored prior to scanning. Once Smart Manager triggers a scan, it will send a command with the requested channel to scan to the MM6108 chip. After the scan completes, the driver emits a MORSE\_VENDOR\_EVENT\_OCS\_DONE event via netlink, containing the scan results, which will be captured and stored by Smart Manager. This operation will iterate on all candidate channels to get an accurate view of the channel conditions. Multiple measurements will be taken over time, as traffic and interference may be sporadic. The scan results will need to be analysed by Smart Manager and a metric established to gauge the quality of the channel. ### 2.3 Selection Once sufficient channel data has been obtained, Smart Manager will make a decision on whether it should trigger an ECSA based on the measurement (e.g. each channel’s quality, adjacent channels, channel's historic readings etc.). Currently, Smart Manager will only try to switch within the channels which have the same bandwidth. If considering changing operating BW, it is also important to take into consideration the maximum throughput of the network, which will be dependent on RSSI of stations and the traffic profile of the BSS. ### 2.4 Channel Switch Once the “best” new channel has been selected, Smart Manager will trigger an Extended Channel Switch Announcement (ECSA). This will inform all currently associated stations to switch to the new channel at the coordinated time. After the channel switch, Smart Manager will continue to evaluate alternative channels, thus ensuring the optimal channel is used for BSS operation. *** ## 3 Configuration ### 3.1 OpenWRT The following configuration is tested using Morse Micro EKH01 firmware version V2.3.3. This feature can be enabled by the following steps: Via webUI DCS can be configured in the settings under the Network->Wireless menu: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/sDxUysvROvAtvPLz1Xzz/Unknown%20image) Select ‘Edit’ next to the HaLow network that is to be configured: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/rIawDXfAPT3mH2vxhpev/Unknown%20image) Then tick the ‘Dynamic Channel Selection’ option to enable DCS: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/sTvLD3YfFaBlGuINN16n/Unknown%20image) Sample of the smart\_manager.radio0.conf configuration file: |

interface\_name = "wlan0"
logging: {
level = 2
}
backends: {
hostapd: {
control\_path: "/var/run/hostapd\_s1g"
}
}
datalog: {
root\_dir = "/var/log"
dcs: {
enabled = false
}
}
dcs: {
algo\_type = "ewma"
ewma: {
ewma\_alpha = 30
rounds\_for\_csa = 10
threshold\_percentage = 5
sec\_per\_scan = 2
sec\_per\_round = 10
}
trigger\_csa = True
dtims\_for\_csa = 10
}

| | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ### 3.2 Generic The following is an example configuration file that can be used by Smart Manager for DCS on a generic Linux platform such as buildroot. |

# Copyright Morse Micro 2023
# Morse Micro Smart Manager configuration file
# HaLow WLAN interface name
interface\_name = "wlan0"
# Log levels as follows:
# NONE 0
# ERROR 1
# WARN 2
# INFO 3
# DEBUG 4
# VERBOSE 5
logging: {
level = 2
colours = True
}

# Backend specific configuration
backends: {
# Hostapd config
hostapd: {
# Control path for hostapd CLI
control\_path : "/var/run/hostapd\_s1g"
}
}
# Datalog configuration. If not specified, datalogs will default to off
datalog: {
# Root directory to store data logs
root\_dir = "/var/log/smart\_manager"
dcs : {
enabled = true
}
nl80211: {
enabled = false
}
hostapd: {
enabled = false
}
morsectrl: {
enabled = false
}
}
# Dynamic channel selection configuration
dcs : {
# Currently enabled algorithm. Options are:
# - "ewma"
# - "sample\_and\_hold"
algo\_type: "ewma"
# Exponential weighted moving average function. Evaluates every scan round.
ewma: {
# DCS EWMA weight for the channel metric (max 100)
ewma\_alpha = 30
# Threshold percentage of channel score to be considered better
threshold\_percentage = 5
# Number of scan rounds in a row with a better channel to trigger a switch
rounds\_for\_csa = 10
# Time to wait between scanning each channel within a scan round
sec\_per\_scan = 2
# Time to wait before starting another scan round
sec\_per\_round = 10
}
# Accumulated mean. Evaluates after 'rounds\_for\_eval' rounds.
sample\_and\_hold: {
# Number of scan rounds until evaluating and potentially triggering a switch
rounds\_for\_eval: 20
# Threshold percentage of channel score to be considered better
threshold\_percentage: 5
# Time to wait between scanning each channel within a scan round
sec\_per\_scan = 2
# Time to wait before starting another scan round
sec\_per\_round = 10
}
# enable / disable CSA
trigger\_csa = True
# number of DTIM beacons to include channel switch announcement IE before actually moving
dtims\_for\_csa = 10
# Test mode parameters
test :
{
# Test mode enabled
enabled = False
# Filepath to test mode samples
filepath = "test\_samples.csv"
}
}

| | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## 4 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | -------------- | | 01 | 03/11/2023 | 1st release | | 02 | 21/10/2024 | Second release | # APPNOTE-18 Bringing Up prplMesh on Linux v2 ## 1 Overview This application note details the procedures for integrating prplMesh on Linux. The original prplMesh open-source implementation lacks built-in support for the HaLow (802.11ah) standard. Consequently, Morse Micro has customized the open-source prplMesh to extend its support for HaLow wireless interfaces. Given that prplMesh operates as an application within the wireless platform, achieving 11ah compatibility on the platform necessitates the utilization of Morse Micro version of hostapd and wpa\_supplicant. ## 2 Prerequisites ### 2.1 Hardware requirements This guide assumes that you already have a suitable platform with the MM6108 HaLow chip integrated via SDIO or SPI and running successfully in Linux. If you do not have this please reach out to support to discuss the options, or consider using an evaluation kit as a starting point. All OpenWrt-based EVKs from Morse Micro support prplMesh (known by its standard name ‘EasyMesh’) out of the box. ### 2.2 Software Requirements The following section outlines the software components that are required for integrating prplMesh with HaLow support into Linux. #### 2.2.1 hostapd\_s1g and wpa\_supplicant\_s1g Ensure that both these packages are compiled and installed on the intended Linux device. These are customized versions that support HaLow interfaces, and should already be present as part of the basic HaLow integration on the platform. #### 2.2.2 UCI, ubus, and libubox: Not all Linux systems include UCI, ubus and libubox by default, as these are generally specific to OpenWrt-based systems. However they are integral components of the Morse Micro adaptation of prplMesh, and will need to be included. prplMesh relies on UCI as its configuration interface and requires ubus for DHCP events. While the absence of ubus events may not cause significant functional issues, it is essential for successfully building the SDK. *** #### 2.2.3 Host Machine Compilation and Installation Requirements: The following host packages should be installed before compiling UCI and ubus: sudo apt install lua5.1 sudo apt install liblua5.1-0-dev sudo apt install libjson-c-dev Once the host dependencies above are installed, follow the steps below to retrieve and compile the source code for each of the packages for the host machine and install on the host: * libubox: $ git clone git://git.openwrt.org/project/libubox.git $ cd libubox $ cmake . $ sudo make install * ubus: $ git clone git://git.openwrt.org/project/ubus.git $ cd ubus $ cmake . $ sudo make install * UCI: $ git clone git://git.openwrt.org/project/uci.git $ cd uci $ cmake . $ sudo make install *** #### 2.2.4 Target Machine Compilation and Installation Requirements: For the target machine, the following packages downloaded on the host must be again re-compiled for the target and installed on the target with the specified commands: * libubox: $ cmake -DCMAKE\_C\_COMPILER= . $ make $ install ‘libubox.so’in ‘/usr/local/lib/libubox.so’ on the target * ubus: $ cmake -DCMAKE\_C\_COMPILER= . $ make $ install ‘libubus.so’in ‘/usr/local/lib/libubus.so’ on the target * UCI: $ cmake -DCMAKE\_C\_COMPILER= . $ make $ install ‘libuci.so’in ‘/usr/local/lib/libuci.so’ on the target Note: Ensure to pass the appropriate cross compiler option for the target using the CMAKE\_C\_COMPILER flag. for e.g: cmake -D[C](https://www.google.com/url?q=https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_COMPILER.html%23variable:CMAKE_%253CLANG%253E_COMPILER\&sa=D\&source=editors\&ust=1783410947084383\&usg=AOvVaw1aaKzzBmi5QNAoaar3vd1c)MAKE\_C\_COMPILER=arm-elf-gcc . *** #### 2.2.5 Other Packages Refer to the prplMesh README.md file for additional package requirements. At time of writing this includes: * binutils * cmake * gcc * git * libjson-c-dev * libncurses-dev * libnl-3-dev * libnl-genl-3-dev * libnl-route-3-dev * libssl-dev * ninja-build * pkg-config * python * python-yaml * python3 * python3-yaml * bison * curl * flex * libevent-dev * libyajl-dev * lua5.1 * liblua5.1-0-dev * build-essential * clang-format * gcovr * bridge-utils * ebtables * iproute2 * net-tools * psmisc * uuid-runtime ## 3 Building the code ### 3.1 Download and extract the prplMesh source Obtain the prplMesh source tar file from the Morse Micro DocSend release folder and extract it, using the following command: tar xvzf prplmesh-rel\_1\_10\_2\_2023\_Nov\_22.tgz ### 3.2 Update CMakeLists.txt Add the following extra CFLAGS \[highlighted in blue] to the CMakeLists.txt file present in the top directory: \# Default Compiler flags set(CMAKE\_C\_FLAGS "${CMAKE\_C\_FLAGS} -Wall -Wextra -Werror -pthread -Wno-comment -Wno-unused-parameter -Wno-missing-field-initializers -Wno-error=deprecated-declarations -Wno-error=maybe-uninitialized") set(CMAKE\_C\_FLAGS\_RELEASE "${CMAKE\_C\_FLAGS\_RELEASE} -s -O2 -Wformat -Wformat-security -Wl,-S -fPIC -fPIE") \# Compiler specific flags *** ### 3.3 Build the code From the top level directory invoke cmake as follows, cmake -DCMAKE\_C\_COMPILER= -DCMAKE\_BUILD\_TYPE=Debug -DCMAKE\_INSTALL\_PREFIX=build/install -DTARGET\_PLATFORM="MorseMicro" -DBEEROCKS\_BRIDGE\_IFACE="br-prpl" -DBWL\_TYPE="NL80211" -DBUILD\_SHARED\_LIBS=OFF -H. -B./build Note: Use appropriate bridge name for -DBEEROCKS\_BRIDGE\_IFACE. Once cmake is successful, run make to finish the compilation make -C ./build install ### 3.4 Copy the files into the target Transfer the contents of '\/build/install/\*' to the target device, maintaining the identical directory structure. ## 4 Running prplMesh ### 4.1 Start prplMesh Controller and Agent * Navigate to the scripts directory: cd /scripts * Start prplMesh Controller (default mode is Mesh Controller): sudo ./prplmesh\_utils.sh start \ (or)\ sudo ./prplmesh\_utils.sh --mode CA start ### 4.2 Run only as Mesh Agent * From the /scripts directory run the following command: sudo ./prplmesh\_utils.sh --mode A start ## 5 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | ------------------------------------------------ | | 01 | 02/02/2024 |
  • Initial release
| | 02 | 28/11/2024 |
  • Revised formatting for release
| # APPNOTE-20 Thin LMAC v3 [Download as PDF](https://www.morsemicro.com/resources/appnotes/MM_APPNOTE-20_Thin_LMAC.pdf) ## 1 Scope Thin LMAC mode allows a Morse Micro 802.11ah Access Point (AP) to associate with more stations than is possible in the standard SoftMAC mode (which could be called ‘Fat LMAC’). The trade-off is that more processing must be performed on the host CPU. No changes are required on the stations; only the AP needs to be set up to use Thin LMAC mode. The standard SoftMAC mode allows the AP to associate with up to 200 stations. Using Thin LMAC will allow the AP to associate with up to 2,007 stations. Thin LMAC is supported from Release 1.10.2 onwards (OpenWrt release 2.4.4), but Release 1.14.0 or higher is recommended, because it includes enhancements for reducing the time for a large number of stations to associate. ## 2 Theory of Operation Thin LMAC operation is achieved by reducing the per-station memory footprint in the firmware, primarily by moving encryption and decryption of unicast frames from the firmware to the host device. For that reason, the host device should have a suitable cryptographic processor. Note however, that supporting a large number of simultaneous stations does not intrinsically require more processing power, because it does not impact the total number of packets that can be sent and received per second. In fact, the total achievable throughput will tend to be lower for a large number of stations, due to contention and back-off of over-the-air traffic to/from each station. ## 3 How to Configure ### Installing Thin LMAC Thin LMAC mode uses a variant of the mm6108.bin firmware binary, named mm6108-tlm.bin. Make sure this binary image is present in the /lib/firmware/morse directory. mm6108-tlm.bin may be installed already. If not, it must be obtained from Morse Micro and copied into the above location. ### Enabling Thin LMAC ⚠️ Do not enable Thin LMAC for a device that will be put into Station mode. Enabling Thin LMAC is documented in the Eval Kit User Guide supplied with the OpenWrt software. ### Considerations #### Reduce incidental traffic When deploying a large number of stations, it is important to minimize the amount of incidental traffic. 2,000 stations each sending and receiving a 1kB packet every minute will generate 546 kbps (2,000 stations \* 1,024 bytes \* 2 directions \* 8 bits / 60 seconds) of traffic, or far more in bursts if the traffic is not distributed evenly over time. **Reduce keep-alive message frequency** The default interval for sending a keepalive (empty data) frame to each station is 300 seconds. Set option “max\_inactivity” on the appropriate wifi-iface. For example: uci set wireless.default\_radio0.max\_inactivity=600 **Disable IPv6 traffic** Using a single network IP protocol (e.g. IPv4) will reduce network traffic, as the devices will not need to negotiate a second time for the additional protocol address. IPv6 also sends regular neighbour discovery packets that are not useful if only IPv4 is required in the network. Add option ipv6 '0' to the config interface ‘ahwlan’ section of the /etc/config/network file. MM-IOT-SDK stations If using the Morse Micro IoT SDK, disable IPv6 with the LWIP\_IPV6=0 build time configuration setting. **Use static IP addresses** If practical, using static IP addresses instead of DHCP will reduce network traffic during association. **Increase ARP table entry timeout** The default ARP entry timeout is 30 (+/-15) seconds. This example increases timeout to 60 (+/-30) minutes. This command requires the Wi-Fi interface to have been brought up, by loading the driver. sysctl -w net.ipv4.neigh.wlan0.base\_reachable\_time\_ms=3600000 **Reduce IPv4 garbage collection frequency** These settings control the number of entries maintained in the ARP cache. The default values are inadequate for large scale deployments, and will cause ARP entries to constantly be removed, triggering a large number of ARP protocol exchanges between the AP and stations. gc\_thres1: The minimum number of entries to keep in the ARP cache. gc\_thres2: The soft maximum number of entries to keep in the ARP cache. The garbage collector will allow the number of entries to exceed this for a few seconds before collection will be performed. gc\_thres3: The hard maximum number of entries to keep in the ARP cache. The garbage collector will always run if there are more than this number of entries in the cache. In this example, the above values are set high enough to avoid unnecessary ARP table clean-up for the maximum possible number of stations. sysctl -w net.ipv4.neigh.default.gc\_thresh1=2048 sysctl -w net.ipv4.neigh.default.gc\_thresh2=2048 sysctl -w net.ipv4.neigh.default.gc\_thresh3=2048 **Disable unnecessary ARP responses** These settings minimize responses to ARP requests for IP addresses that are not on the HaLow interface’s subnet. They may need adjusting for a given application. Refer to [https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt](https://www.google.com/url?q=https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt\&sa=D\&source=editors\&ust=1783410470312763\&usg=AOvVaw1a5MVmFuvOyfXZdMHqOuRC) for more information. sysctl -w net.ipv4.conf.all.arp\_ignore=1 sysctl -w net.ipv4.conf.all.arp\_announce=2 **Disable Anti-clogging** Anti-clogging is a hostapd/wpa\_supplicant feature that provides minimal protection against DoS by spoofing authentication management frames. When the number of simultaneous association requests exceeds a threshold, hostapd rejects authentication requests and provides a token to the stations. The station must then restart the authentication exchange, supplying the token. This results in at least two extra authentication frames per association, which are significantly larger. The mechanism provides only superficial DoS support, because it is easily circumvented (by responding to the token requests, but can be detrimental in a large HaLow network. It can be effectively disabled by setting a high threshold in the AP’s hostapd.conf file. E.g. anti\_clogging\_threshold=10000 CAC (see below) can reduce the number of simultaneous association requests, but must be configured aggressively to completely prevent anti-clogging measures from being triggered. **Other** Check for any other application-generated traffic and consider whether it can be disabled or sent less frequently. #### Scaling measures **Local IPv4 port range** The default number of allocated local UDP/TCP ports on the Linux host may not be adequate to handle a high number of simultaneous associations. The range of usable ports can be increased as follows. sysctl -w net.ipv4.ip\_local\_port\_range="32768 65535" **Enable CAC** Centralised Authentication Control can reduce the time taken for a large number of stations to associate, by throttling the number of stations that attempt to associate simultaneously, and thereby minimizing contention of time-sensitive association and authentication frame exchanges. ℹ️ CAC is described in MM APPNOTE-24 CAC. **Reduce association retry time** In very large deployments, or in those with limited bandwidth or duty cycle, some stations may require repeated attempts to associate due to congestion causing timeout of time-sensitive association and authentication frame exchanges. By default, wpa\_supplicant\_s1g waits for progressively longer intervals between association failures with the same BSS before retrying. The default intervals are 10, 20, 30, 60, 90, and up to 300 seconds for each successive association attempt. These values may be appropriate in more general environments, for example, to avoid thrashing when there is a password mismatch between AP and stations, but can cause significant delays in bringing up a large scale HaLow network. The following example adds a backoffs parameter to wpa\_supplicant\_s1g.conf on the stations, to reduce the backoff interval to a maximum of 32 seconds (plus a random fuzz factor) for the first 12 association attempts. The maximum value of 300 seconds is applied thereafter. These numbers are a tradeoff between having some stations take a very long time to associate and introducing more congestion because of many stations continually attempting to associate at the same time. ... network={ ssid= … backoffs=8 8 8 16 16 16 24 24 24 32 32 32 } Because of the large number of variants in any given environment, it’s not possible to provide general recommendations regarding the best configuration to use, but the above settings may be helpful if stations are observed to take too long to associate. *** ## 4 How to Verify When Thin LMAC mode has been enabled, more than 200 stations will be able to associate to the device. Confirm the device is in Thin LMAC mode by using the following command. A value of 1 indicates that Thin LMAC is enabled. ## cat /sys/module/morse/parameters/thin\_lmac 1 The following message will be logged when the morse.ko driver loads if INFO level debugging has been enabled. morse\_mac\_init: Enabling thin LMAC mode If the firmware is attached to a UART console, the following messages can also be seen during start-up when Thin LMAC is enabled. ## cat /var/log/ttyAMA1.log Booting from MM6108A1 chip master-2f903a9b0d-NFP 0x56624f24 2024-10-29 09:38 Thin LMAC mode *** ## 5 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | ------------------------------------ | | 01 | 2024-04-19 | Initial version | | 02 | | Updates | | 03 | 2024-11-28 | Rework and update for release 1.14.0 | # APPNOTE-21 TCP Keep Alive Offload v1 [Download as PDF](https://www.morsemicro.com/resources/appnotes/MM_APPNOTE-21_MM6108_TCP_Keep_Alive_Offload.pdf) ## 1 Scope The TCP keepalive offload feature provides the ability for the firmware to support TCP keepalive functionality for an active TCP session. This includes both responding to keepalives from the remote TCP endpoint and also to generate TCP keepalives as required. The main aim is to keep the TCP session active without requiring action from the local host’s TCP stack. The feature is not specific to Standby mode and is available on both HaLow station and AP modes, but the intended use is for station mode specifically. The TCP keepalive offload feature is available in MM6108 Software Release Package 1.12.x onward. ## 2 Theory of Operation The feature assumes control of all TCP keepalive operations on behalf of the local TCP stack to make sure the remote endpoint does not drop the connection, particularly when the host is suspended. It doesn’t process other TCP packets, apart from snooping them to gather the latest values for things like sequence numbers, so it can process and generate keepalive frames correctly. It needs to have at least one valid TCP exchange processed by the local host before it can start to operate. That could be a keepalive or data exchange. The basic operation is the feature will respond to TCP keepalives from the remote endpoint. It will only generate a TCP keepalive if nothing is seen from the remote endpoint during the configured period. The host is required to enable and disable the feature when the TCP session is established (or as needed) and when the session completes (or the feature is no longer needed) via a morse\_cli command. When enabling the feature the addresses for the TCP endpoints (both local and remote) need to be provided. If all TCP keepalive retries fail and nothing is received from the remote TCP endpoint then the feature will wake the host with an event identifying that the TCP connection has been lost. An API needs to be agreed with the customer to pass the TCP connection lost event back to the host application managing the TCP connection. One TCP session at a time is supported. ### 2.1 Other Considerations For proper operation it requires the local host’s TCP stack to be configured with large keepalive timeouts, so the host will not start to generate keepalive frames of its own. When using the feature with Standby mode, the related offload features that ensure the association and relevant ARP entries are maintained need to be used. ## 3 How to Configure The command to configure the feature is: morse\_cli tcp\_keepalive \[-h] \[-p ] \[-c ] \[-i ] \[-s ] \[-d ] \[-S ] \[-D ] {enable|disable}\ Configure TCP keepalive offload parameters\ -h, --help display this help and exit\ -p Period in seconds - range 1-65535\ -c Number of retries - range 0-255\ -i Seconds between retries - range 1-255\ -s Source IP address in dotted decimal notation\ -d Destination IP address in dotted decimal notation\ -S TCP source port - range 1-65535\ -D TCP destination port - range 1-65535\ {enable|disable} enable/disable TCP keepalive offload  The parameters are defined below: * Period - the time in seconds between locally generated TCP keepalive packets * Retry Count - the number of retries to be attempted before deciding the connection is lost * Retry Interval - the number of seconds between retries * Src IP - the IP address of the remote TCP endpoint (will be the source IP address for received TCP packets) * Src Port - the port number of the remote TCP endpoint * Dest IP - the IP address for the local TCP endpoint * Dest Port - the port number for the local TCP endpoint * enable - activate the feature * disable - deactivate the feature and clear all TCP session information To enable the feature you need to specify the source and destination IP addresses and ports. Only the TCP stream matching those values will be processed for TCP keepalives. In this context, source refers to the addresses of the remote TCP endpoint and destination is for the local endpoint. Below are two examples of setting up TCP keepalive: * morse\_cli tcp\_keepalive -p 5 -c 4 -i 2 -s 192.168.1.1 -S 5001 -d 192.168.1.2 -D 45003 enable * Enables the feature with a keepalive period of 5 seconds, retries every 2 seconds and the maximum number of retries is 4. The TCP stream will be for local IP address 192.168.1.2 and local port 45003 and remote IP address 192.168.1.1 and remote port 5001. * morse\_cli tcp\_keepalive -s 10.57.23.7 -S 5050 -d 10.57.23.45 -D 37003 enable * Enables the feature with the default period, etc settings. The TCP stream will be for local IP address 10.57.23.45 and local port 37003 and remote IP address 10.57.23.7 and remote port 5050. To disable the feature simply use the command: morse\_cli tcp\_keepalive disable ## 4 How to Verify Several statistics are provided to help identify if the feature is working: # morse\_cli stats -a | grep "TCP keepalive" TCP keepalives answered: 6147\ TCP keepalives to host: 33\ TCP keepalives generated: 468\ TCP keepalive connection lost: 1  TCP keepalives answered The number of TCP keepalive ACK framessent from the feature. This shows the feature is receiving TCP keepalives from the remote TCP endpoint and is responding. TCP keepalives to host This counter increments when keepalives are forwarded to the host during synchronisation with the TCP session, but may increment faster than the number of keepalives actually forwarded. Once keepalive offload is operational, this value should not increase. TCP keepalives generated The number of TCP keepalive exchanges initiated by the local TCP keepalive feature. If this increments it means TCP keepalives have not been received from the remote side within the configured period. TCP keepalive connection lost This increments if the feature fails to get a response after exhausting the keepalive retries. If the chip is in Standby mode it will wake the host. ## 5 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | ---------------- | | 01 | 02/05/2024 | Initial release. | Approvers: Chad O’Neill (VP of Applications), Matthew Forgie (Director of Software Applications) # APPNOTE-24 Linux Porting Guide v2 [Download as PDF](https://www.morsemicro.com/resources/appnotes/MM_APPNOTE-24_Linux_Porting_Guide.pdf) ## 1 Scope This guide will demonstrate the steps required to integrate Morse Micro Wi-Fi HaLow into an existing Linux based target platform. This document does not intend to be a tutorial for building Linux based firmware from scratch, nor will it discuss integration details into build systems such as Yocto, OpenWrt, or Buildroot. Additionally, this document focuses on artefacts delivered by Morse Micro, and will not cover how to compile dependencies, and other, general, software utilities which may be required for wireless devices. ## 2 Requirements Before integrating HaLow into a project, a developer should ensure they have the following resources prepared: * a toolchain for the target platform; * the Linux kernel source, checked out to a compatible version; * the Linux kernel configuration, as required for their target; * compiled user space libraries such as OpenSSL and libnl, required for the Morse Micro user space software utilities; * compiled user space applications, such as iw and ip (BusyBox ip is sufficient). Morse Micro will provide: * the MM6108 driver source; * kernel patches for a list targeting compatible kernel versions, below; * hostapd/wpa\_supplicant source modified for 802.11ah support; * morse\_cli source - the user space control utility for MM6108; * MM6108 firmware binaries; * BCF binaries for Morse Micro designed HaLow modules - to be used as a reference. Note that HaLow modules from other manufacturers using MM6108 may require a different BCF. The developer should consult the manufacturer. Devices directly incorporating MM6108 into their design will need to create their own BCF binaries. This guide will use the 1.15.3 driver and associated files, available for download from [https://github.com/MorseMicro](https://www.google.com/url?q=https://github.com/MorseMicro\&sa=D\&source=editors\&ust=1783470657716308\&usg=AOvVaw054g65abgDK4BSczSaOL52). *** The MorseMicro software releases are designed around the following kernels from [https://github.com/raspberrypi/linux](https://www.google.com/url?q=https://github.com/raspberrypi/linux\&sa=D\&source=editors\&ust=1783470657716533\&usg=AOvVaw1Of6k6cqgKbhNhm7cm_B0P): | Version | git tag | | ------- | -------------------------------- | | 4.9.80 | raspberrypi-kernel\_1.20180313-1 | | 4.14.98 | raspberrypi-kernel\_1.20190401-1 | | 4.19.66 | raspberrypi-kernel\_1.20190819-1 | | 5.4.83 | raspberrypi-kernel\_1.20210108-1 | | 5.10.11 | raspberrypi-kernel\_1.20210201-1 | | 5.15.61 | 1.20220830 | | 6.1.21 | 1.20230405 | | 6.6.19 | stable\_20240529 | However, to demonstrate Linux integration more generally, the remainder of this document will provide examples based on a 6.1.137 Linux Kernel and a 1.15.3 Morse Micro software release. *** ## 3 Applying Kernel Modifications Before compiling the Linux kernel, a small number of modifications are required to enable various S1G features. These patches can be seen in the linux repository at: [https://github.com/MorseMicro/linux/](https://www.google.com/url?q=https://github.com/MorseMicro/linux/\&sa=D\&source=editors\&ust=1783470657719135\&usg=AOvVaw3l5VmpOpehX1vh1byHQXNI) Note that there are different branches for different kernel versions, but unless your kernel version is exactly the same you may have to make minor adjustments when integrating them with your kernel. Therefore the easiest path is to build this kernel as you would normally for your platform. However, if you need to apply these changes to your existing kernel, follow one of the sections below. ### 3.1 Existing git repository If you have an existing git repository that is a fork of the normal Linux repository, you can add this repository as a remote and merge the appropriate branch. For instance, if you were using a 6.1 kernel: |

git remote add mmlinux
git fetch mmlinux
git merge mm/linux-6.1.21/1.15.x

| | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | Alternatively, you may wish to cherrypick only the relevant commits, particularly if your kernel tree isn’t based on the normal Linux one: | git cherry-pick v6.1.21..mmlinux/mm/linux-6.1.21/1.15.x | | ------------------------------------------------------- | ### 3.2 Using patch files If you would prefer to apply patch files, you can either use the github web interface to generate them by adding .patch to commit URLs in the history - e.g. [https://github.com/MorseMicro/linux/commit/73969e73764a93bdffa28928c236ac5101ed25d0.patch](https://www.google.com/url?q=https://github.com/MorseMicro/linux/commit/73969e73764a93bdffa28928c236ac5101ed25d0.patch\&sa=D\&source=editors\&ust=1783470657720885\&usg=AOvVaw3b_8PFvYY44y1-XOFkhvId) - or clone the repository and use git format-patch: |

git clone
cd linux
git checkout mm/linux-6.1.21/1.15.x
git format-patch v6.1.21

| | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | This will generate a number of patch files in the same directory which you can apply with git am or patch. ## 4 Compiling the Driver Before compiling the driver, please ensure you’ve compiled your kernel as normal with appropriate ARCH and CROSS\_COMPILE environment variables configured as required. The Morse Micro driver produces two modules. * morse.ko is the core driver for both SPI and SDIO attached devices. It provides core bus communication logic and network device registration. * dot11ah.ko the shim layer, responsible for translating 802.11ah channel and rate information into 802.11ac, including 802.11ah specific frames such as S1G probe requests. If the Morse Micro driver is recompiled, it is strongly recommended to update both modules in the system. Failure to do so can result in significantly reduced throughput or, possibly, a complete communication failure. To compile the driver, execute the following commands |

git clone
cd morse\_driver
git checkout
git submodule update --init --recursive
make KERNEL\_SRC=../linux \
CONFIG\_WLAN\_VENDOR\_MORSE=m \
CONFIG\_MORSE\_USER\_ACCESS=y CONFIG\_MORSE\_VENDOR\_COMMAND=y

| | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | This will compile morse.ko and dot11ah.ko which can be installed into /lib/modules/\/ of the target rootfs. Additional compile time configuration options are available. For an up-to-date list, and detailed descriptions of the fields, inspect the Kconfig file in the source. Notably, to compile the driver for an SDIO or SPI attached device, one would need to use CONFIG\_MORSE\_SDIO=y or CONFIG\_MORSE\_SPI=y. To enable test modes set CONFIG\_MORSE\_ENABLE\_TEST\_MODES=y. ## 5 Firmware Binaries Before the module can be inserted, in a running platform, two binary files need to be installed into /lib/firmware/morse of the rootfs: * the chip firmware; * a board configuration file (BCF) to provide calibration constants. You may need to acquire this from the manufacturer of the module separately, but be aware that if you have an old BCF you may be forced to use an old release of the driver; you should ask the module manufacturer for an up-to-date BCF. \|

mkdir $STAGING\_DIR
curl -sL \
| tar xv
curl -sL \
| tar xv
rm LICENSE

| \| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | On insertion of the morse.ko kernel module, there are three paths the driver might take for selecting which BCF to use. 1. Use the file specified in the bcf module parameter - e.g. bcf=bcf\_mf08651.bin 2. For modules with the board type ID programmed into OTP, use the file with name bcf\_boardtype\_.bin 3. Use bcf\_default.bin Some modules, including MM6108-MF08651-US, are shipped with the board type ID programmed into OTP. To support this it is recommended the developer adds the following symbolic link to their rootfs/target platform. |

ln -s /lib/firmware/morse/bcf\_mf08651.bin \
$STAGING\_DIR/lib/firmware/morse/bcf\_boardtype\_0801.bin

| | ------------------------------------------------------------------------------------------------------------------- | For other modules the developer should run the following command |

ln -s /lib/firmware/morse/$BCF.bin \
$STAGING\_DIR/lib/firmware/morse/bcf\_default.bin

| | ---------------------------------------------------------------------------------------------------- | where $BCF matches the appropriate BCF for the target platform. *** ## 6 User Space Software A device integrating HaLow requires more than just the driver. * wpa\_supplicant - user space wireless client, including 802.11s mesh points * hostapd - user space daemon for access points * morse\_cli - Morse Micro’s user space control utility. It is required that this is installed on the target system for the correct function of hostapd and wpa\_supplicant provided by Morse Micro. * morsectrl - Morse Micro’s advanced user space control utility. This utility provides extra commands useful for testing radio performance. The installation of morsectrl is not recommended for image builds targeting end users, and is not distributed as open source. The above utilities have dependencies on additional software libraries which must be compiled for the target platform. This guide will not provide instructions on how to prepare these dependencies. For hostapd to function correctly at run-time, two cryptographic APIs need to be enabled in the Linux kernel configuration. Also, please also ensure the kernel includes the following configuration. * CONFIG\_CRYPTO\_CCM=y * CONFIG\_CRYPTO\_GCM=y Additionally, standard networking utilities such as iw or ip may be required during bring up. This guide won’t discuss the compilation and installation of these utilities, but a developer should add them to their platform. ### 5.1 hostapd and wpa\_supplicant #### 5.1.1 Dependencies Please ensure the following dependencies are compiled, and if required, installed into the staging directory of your build environment. * libnl-3 (tested with 3.11.0), including libnl-route-3 and libnl-genl-3 * openssl (tested with 3.5.0) #### 5.1.2 Checkout Clone the repository and checkout the appropriate branch using git: |

git clone
cd hostap
git checkout 1.15.3

| | ----------------------------------------------------------------------------------------------- | #### 5.1.2 Configuration The Morse Micro hostap repository provides a default configuration for hostapd and wpa\_supplicant for a minimal release. |

cp wpa\_supplicant/defconfig wpa\_supplicant/.config
cp hostapd/defconfig hostapd/.config

| | --------------------------------------------------------------------------------------------------- | Depending on the application, additional configuration options may need to be enabled. The options available are extensive, and out of scope for this document. Consult the .config file for more information on the available configuration options #### 5.1.3 Compilation Compiling wpa\_supplicant and/or hostapd requires the above mentioned dependencies be made accessible to the build. In this example, libnl-3 and openssl were “installed” into the staging directory with make install. The below command also assumes your CC flag is set appropriately for your target. If additional CFLAGS, LDFLAGS, or other environment variables are required for your platform, add them as required. Compiling wpa\_supplicant: |

CFLAGS="-Wno-error=sign-compare -Wno-error=deprecated-declarations -I $STAGING\_DIR/include/libnl3 -I $STAGING\_DIR/include/" \
LDFLAGS="-L $STAGING\_DIR/lib/ -L $STAGING\_DIR/lib64/" \
DESTDIR="$STAGING\_DIR" BINDIR=/usr/sbin \
make MORSE\_VERSION=rel\_1\_15\_3\_2025\_Apr\_16 -C wpa\_supplicant/

| | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | Compiling hostapd: |

CFLAGS="-Wno-error=sign-compare -I $STAGING\_DIR/include/libnl3 -I $STAGING\_DIR/include/" \
LDFLAGS="-L $STAGING\_DIR/lib/ -L $STAGING\_DIR/lib64/" \
DESTDIR="$STAGING\_DIR" BINDIR=/usr/sbin \
make MORSE\_VERSION=rel\_1\_15\_3\_2025\_Apr\_16 -C hostapd/

| | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | #### 5.1.4 Installation Installation with a staging directory appropriately set is done by adding the install as a target to the above make commands. If performing a manual installation on an existing device, you can install the following binaries into /usr/sbin: * wpa\_supplicant\_s1g * wpa\_cli\_s1g * wpa\_passphrase\_s1g * hostapd\_s1g * hostapd\_cli\_s1g ### 5.3 morse\_cli/morsectrl #### 5.3.1 Dependencies Please ensure the following dependencies are compiled, and if required, installed into the staging directory of your build environment. * libnl-3 (tested with 3.11.0) * libusb (tested with 1.0.28; this may also require libudev) #### 5.3.2 Compilation Compiling morse\_cli requires the above mentioned dependencies be made accessible to the build. In this example, libnl-3 and libusb were installed into the staging directory with make install. The below command also assumes your CC flag is set appropriately for your target. If additional CFLAGS, LDFLAGS, or other environment variables are required for your platform, add them as required. |

git clone
cd morse\_cli
git checkout 1.15.3
CFLAGS="-I$STAGING\_DIR/include/libnl3/ -I$STAGING\_DIR/include/libusb-1.0" \
LDFLAGS="-L $STAGING\_DIR/lib/" \
make CONFIG\_MORSE\_TRANS\_NL80211=1

| | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | If you have the morsectrl source, it can be compiled in a similar way, and will also generate a copy of morse\_cli (morse\_cli contains a subset of morsectrl commands). #### 5.3.3 Installation To install morse\_cli, copy the compiled binary to /usr/bin of your device or target rootfs. *** ## 6 Defining the Hardware for SDIO/SPI ### 6.1 Configuration In order for the driver to detect and communicate with the chip via SDIO or SPI, the hardware must be described to the kernel. This ensures all necessary clocks, pins, power regulators, and necessary host bus peripherals are correctly configured for the target platform. This hardware configuration is described to the kernel using devicetree, which is compiled and passed to the kernel as a binary blob. A developer may choose to modify an existing board devicetree file (.dts), compiling the changes into a single Flattened Device Tree (FDT) binary (.dtb). Alternatively, a device tree “fragment” can be composed and a device tree overlay compiled (.dtbo) allowing that hardware configuration to be changed on boot. Below is a small snippet from the Morse Micro EKH03 devicetree (.dts) file, redacted for brevity and to highlight the required properties and nodes to describe an SDIO connected MM6108. |

...
\&sdhci {
...
cap-sd-highspeed;
cap-mmc-highspeed;
non-removable;
disable-wp;
cap-sdio-irq;
...
mm6108\_sdio: mm6108\_sdio\@0 {
compatible = "morse,mm610x";
reset-gpios = <\&gpio 12 0>;
power-gpios = <\&gpio 7 0>,
<\&gpio 8 0>;
status = "okay";
reg = <2>;
bus-width = <4>;
};
};
...

| | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | For SPI devices, the MM6108 device tree node looks slightly different. The snippet below, taken from the MorseMicro EKH01 EVK, demonstrates how a developer might prepare a devicetree overlay to describe an MM6108 connected to the first SPI bus of the host processor. Of particular note is the different compatible, and the spi-irq-gpios parameter. |

/dts-v1/;
/plugin/;
/ {
compatible = "brcm,bcm2835", "brcm,bcm2836", "brcm,bcm2708", "brcm,bcm2709", "brcm,bcm2711";
fragment\@0 {
target = <\&spi0>;
frag0: **overlay** {
pinctrl-0 = <\&spi0\_pins \&spi0\_cs\_pins>;
cs-gpios = <\&gpio 8 1>;
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
mm6108: mm6108\@0 {
compatible = "morse,mm610x-spi";
reg = <0>; /\* CE0 \*/
reset-gpios = <\&gpio 5 0>;
power-gpios = <\&gpio 3 0>,
<\&gpio 7 0>;
spi-irq-gpios = <\&gpio 25 0>;
spi-max-frequency = <50000000>;
status = "okay";
};
};
};
};

| | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | *** | Property | Note | | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | cap-sdio-irq | Enable SDIO IRQ signalling on this bus | | compatible |

Must be “morse,mm610x” in the MM6108 node to correctly probe the SDIO driver
Must be “morse,mm610x-spi” in the MM6108 node to correctly probe the SPI driver.

| | reset-gpios | GPIO descriptor connected to the MM6108 RESET line. | | power-gpios | GPIO descriptor list connected to the MM6108 WAKE and BUSY pins, respectively | | spi-irq-gpios | GPIO descriptor connected to the MM6108 SPI\_INT pin. | | status | Must be “okay” to enable the device! | Due to the target specific requirements of booting a device, there is no one specific approach a developer should use to compile and deploy changes to the device tree. The next 3 subsections describe 3 common methods for which device tree changes may be incorporated into a target platform. ### 6.2 Compilation #### 6.2.1 Example 1 (FDT Blob in KBuild) In some cases, for some targets, the Linux kernel can ease the compilation of and “installation” of the FDT Blob by specifying the device tree file to load in the kernel config. This is useful for targets with limited bootloaders which are unable to hand the FDT blob to the kernel at boot time. As an example, if we wanted to add HaLow support to the VoCore 2 module, we could add the EKH03 device tree change above to arch/mips/boot/dts/ralink/vocore2.dts. A kernel checkout configured for a VoCore 2 will have the following kernel options set: * CONFIG\_BUILTIN\_DTB * CONFIG\_DTB\_VOCORE2 The Kbuild Makefile arch/mips/boot/dts/ralink/Makefile handles compilation of the FDT blob. For the ambitious reader, it’s worth noting again that the EKH03 snippet above is incomplete and will not function as-is when applied to the vocore2.dts file in the kernel tree. Morse Micro recommends consulting the OpenWrt SDK for more complete examples. #### 6.2.2 Example 2 (Out-of-Tree Compilation) Devicetree files may also be composed outside of the kernel build tree. As above, the EKH03 device tree change should be added to an out-of-tree board.dts file. Compilation of the FDT blob will follow steps similar to below |

# preprocess #includes and #defines
$(CPP) -nostdinc -x assembler-with-cpp $(DTS\_CPPFLAGS) \
-I$(LINUX\_DTS\_DIR) -I$(LINUX\_DTS\_DIR)/include \
-I$(LINUX\_DIR)/include -undef -D\_\_DTS\_\_ \
-o board.dtb.tmp board.dts
# compile FDT
$(DTC) -O dtb $(FLAGS) -o board.dtb board.dtb.tmp

| | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | The FDT blob can simply be appended to the kernel image for “installation”, prior to any image compression. | cat board.dtb >> kernel.bin | | --------------------------- | For devices with an FDT aware bootloader, the compiled FDT blob can be handed to the kernel at boot time by the bootloader. The specific details of how this is carried out are platform specific. #### 6.2.3 Example 3 (Devicetree Overlay) If flexibility in the hardware configuration is required, devicetree overlay fragments, similar to the fragment used for the EKH01 shown above, can be loaded by FDT aware bootloaders to modify the behaviour of the device FDT. Steps to compile an overlay fragment into a .dtbo mirror the compilation of the FDT blob. |

# compile FDT overlay
$(DTC) -@ -O dtb $(FLAGS) -o overlay.dtbo overlay.dts

| | ------------------------------------------------------------------------------------- | ## 7 Bring Up The configuration options for hostapd and wpa\_supplicant are extensive. Certain options may also depend on compile time configuration. This guide aims to provide a minimal bring up of the HaLow interface, and recommend a developer look to the hostapd documentation for detailed descriptions of the configuration available. ### 7.1 Interface Before bringing up an access point, ensure the dot11ah and morse kernel modules are inserted. |

modprobe mac80211
modprobe crc7
insmod dot11ah/dot11ah.ko
insmod morse.ko country=AU

| | ---------------------------------------------------------------------------------------------------- | Confirm that your kernel logs show the device being correctly registered. A new phy and associated network device (eg wlan0) should now be registered with the kernel. You can now bring up the interface. If you’re not using a DHCP client daemon, you should also set an IP address on the interface using ip: |

ip addr add 192.168.1.1/24 dev wlan0
ip link set wlan0 up

| | ------------------------------------------------------------------- | Remember to choose a different IP in the same subnet for the AP and the Station. There are a number of module parameters supported by the Morse Micro driver. The full list can be found by querying the driver with modinfo or by inspecting the files in sysfs. However, the following module parameters are often beneficial for testing. * country - adjust the default region for which the device should operate; * spi\_clock\_speed - controls the SPI clock speed requested by the driver; * test\_mode - execute one of the test modes in the table below | test\_mode | Identifier | Description | | ---------- | ---------------------------------- | --------------------------------------------------------------- | | 0 | DISABLED | normal boot | | 1 | DOWNLOAD\_ONLY | downloads the firmware | | 2 | DOWNLOAD\_AND\_GET\_HOST\_TBL\_PTR | downloads the firmware and gets the location of the host table | | 3 | GET\_HOST\_TBL\_PTR\_ONLY | only get the location of the host table | | 4 | RESET | chip reset | | 5 | BUS | perform block reads and writes to profile the communication bus | *** ### 7.2 Access Point Make sure the Morse Micro driver is inserted as described in 7.1 Interface, and make sure morse\_cli is in your path. Then start hostapd\_s1g with the minimal config file below. Make sure to change the name of wlan0 if necessary. | hostapd\_s1g hostapd.conf | | ------------------------- | hostapd.conf: |

ctrl\_interface=/var/run/hostapd\_s1g
interface=wlan0
driver=nl80211
hw\_mode=a
ieee80211ah=1
channel=44
op\_class=71
country\_code=AU
s1g\_prim\_chwidth=1
s1g\_prim\_1mhz\_chan\_index=0
ssid=MorseMicro
beacon\_int=100
dtim\_period=1
ap\_max\_inactivity=65536
s1g\_capab=\[SHORT-GI-ALL]
wpa=2
wpa\_key\_mgmt=SAE
rsn\_pairwise=CCMP
sae\_password=12345678
ieee80211w=2
wnm\_sleep\_mode=1
sae\_pwe=1

| | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | You may find the -B (daemonise) and -s (output logs to syslog) options useful once you’ve confirmed that association is working. *** ### 7.3 Station Make sure the Morse Micro driver is inserted as described in 7.1 Interface. Then start wpa\_supplicant\_s1g with the minimal config file below. Make sure to change the name of wlan0 if necessary. |

wpa\_supplicant\_s1g -D nl80211 -i wlan0 \
-c wpa\_supplicant.conf

| | ------------------------------------------------------------------------------- | wpa\_supplicant.conf |

ctrl\_interface=/var/run/wpa\_supplicant\_s1g
#update\_config=1
pmf=2
sae\_pwe=1
network={
ssid="MorseMicro"
key\_mgmt=SAE
pairwise=CCMP
psk="12345678"
}

| | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | You may find the -B (daemonise) and -s (output logs to syslog) options useful once you’ve confirmed that association is working. ## 8 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | ------------------------------------ | | 01 | 20/08/2024 | Initial release | | 02 | 30/05/2025 | Update for 1.15.3 and github release | # APPNOTE-25 Centralized Authentication Control v1 [Download as PDF](https://www.morsemicro.com/resources/appnotes/MM_APPNOTE-25_Centralized_Authentication_Control.pdf) ## 1 Scope Centralised Authentication Control (CAC) can be used to reduce the time taken for a large number of stations to associate, by throttling the number of stations that attempt to associate simultaneously, and thereby minimizing contention of time-sensitive association and authentication frame exchanges. CAC is recommended for use in moderate (more than 40 stations) to large HaLow networks, particularly when operating in low capacity environments, for example in regulatory domains that only allow 1 MHz or 2 MHz bandwidth, or that have duty cycle limitations. ## 2 Theory of Operation The following explanation is taken from Wi-Fi HaLow for the Internet of Things: An Up-to-date Survey on 802.11ah. In Centralized Authentication Control (CAC), the AP dynamically changes the portion of stations that are allowed to send AuthReq messages. Specifically, the AP sets a threshold and broadcasts it to all stations by sending beacon frames. The beacon frame is a management frame and contains the information about the network, it is transmitted periodically by the AP to announce the presence of a wireless network and to synchronize all the stations of the network. When a station is initialized, it generates a random value from the interval \[0, 1022], and tries to send an AuthReq to the AP if the random value is smaller than the threshold obtained from the received beacon. Otherwise, it postpones authentication/association until the next beacon arrives. The threshold should be adjusted dynamically by the AP to limit the number of stations accessing the channel in one beacon interval, and make sure all stations can associate as fast as possible. ## 3 How to Configure ### Enabling CAC on an AP Centralised Authentication Control can reduce the time taken for a large number of stations to associate, by throttling the number of stations that attempt to associate simultaneously, and thereby minimizing contention of time-sensitive association and authentication frame exchanges. To enable CAC, add cac ‘1’ to the wifi-iface section. ### Enabling CAC on stations CAC is enabled on stations by adding cac=1 to the network block in wpa\_supplicant\_s1g.conf. ... network={ ssid= ... cac=1 } Any stations that do not have CAC configured will be able to associate with an AP that has CAC enabled, and will not be constrained by CAC restrictions imposed by the AP. ### Further CAC configuration (AP) If over-the-air capacity is limited, such as when using 1MHz bandwidth and/or a low duty cycle (for example, in JP, EU and IN regulatory domains), it may also be necessary to modify the CAC thresholds, by using the morse\_cli cac command. *** $ morse\_cli cac --help cac \[-v] \[{get|set|enable|disable}] \[-d ,]... \[-i ,]... Configure Centralized Authentication Control {get|set|enable|disable} Subcommand get - get configured rules set - set rules (default) enable|disable - for internal use by wpa\_supplicant only -d, --decrease=, Auth Req Frames per Sec above which to decrease threshold by Decrease rules must be specified in descending ARFS order (match highest first) -i, --increase=, Auth Req Frames per Sec below which to increase threshold by Increase rules must be specified in ascending ARFS order (match lowest first) Up to 8 decrease or increase rules can be configured -v, --verbose Verbose output #### Default configuration Use the morse\_cli cac get command to see the current configuration. These are the default settings. root\@mazda1:\~$ morse\_cli cac get When ARFS is greater than 16, decrease threshold by 25% When ARFS is greater than 12, decrease threshold by 12% When ARFS is greater than 10, decrease threshold by 6% When ARFS is less than 4, increase threshold by 25% When ARFS is less than 6, increase threshold by 12% When ARFS is less than 8, increase threshold by 6% #### Sample configuration for a bandwidth-constrained network These are more aggressive settings, which may be suitable for a large or bandwidth-constrained network. root\@mazda1:\~$ morse\_cli cac -v -d5,60 -d4,50 -d3,40 -i2,12 -i3,6 When ARFS is greater than 5, decrease threshold by 60% When ARFS is greater than 4, decrease threshold by 50% When ARFS is greater than 3, decrease threshold by 40% When ARFS is less than 2, increase threshold by 12% When ARFS is less than 3, increase threshold by 6% ### Considerations #### Thin LMAC Thin LMAC is required for associating more than 200 stations, and is described in MM APPNOTE 20. That document also contains useful information for improving performance in moderate to large scale networks. *** ## 4 How to Verify ### AP Confirm CAC is enabled by using the following command. A value of 1 indicates that CAC is enabled. `# cat /sys/module/morse/parameters/enable_cac` 1 #### AP-side log messages Info level (6) or debug level (7) driver debugging can be enabled with the following commands. `# phy=$(ls -d /sys/kernel/debug/ieee80211/phy\*)` `# echo 6 >$phy/morse/logging/cac` or `# echo 7 >$phy/morse/logging/cac` Whenever the CAC threshold changes (i.e. when many stations attempt to associate at the same time, up until most stations have associated and a threshold is no longer being set), messages such as the following are written to the AP’s syslog. `# dmesg|grep -w CAC` \[ 205.593166] morse\_sdio mmc1:0001:2: CAC ARFS=13 period=600 adjust=-2 idx=14 threshold=896 \[ 206.523164] morse\_sdio mmc1:0001:2: CAC ARFS=11 period=800 adjust=-1 idx=13 threshold=832 \[ 206.963164] morse\_sdio mmc1:0001:2: CAC ARFS=11 period=400 adjust=-1 idx=12 threshold=768 \[ 208.073159] morse\_sdio mmc1:0001:2: CAC ARFS=2 period=1000 adjust=4 idx=16 threshold=1024 The fields in these messages are: * ARFS: authentication request frames received in this period * period: period over which the ARFS were received (max will be 1 second) * adjust: change to the threshold index * idx: new index, which is used to set the new threshold * threshold: threshold now being advertised in beacons and probe responses ### Station When CAC is enabled on both the AP and STAs, and the AP starts advertising a CAC threshold (the above log messages are seen), messages like the following can be seen in the wpa\_supplicant log if INFO level debug messages are enabled. SVT\_mercedes27\_10.53.53.37# grep CAC /var/log/morse\_wpa\_supplicant.log 202.791642: wlan1: Auth disallowed by CAC for 0c:bf:74:59:bf:11, threshold=896 random=936 205.889910: wlan1: Auth allowed by CAC for 0c:bf:74:59:bf:11, threshold=1023 random=936 The fields in these messages are: * threshold: threshold from the most recently received beacon or probe response * random: the current random value used by this STA *** ## 5 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | --------------- | | 01 | 2024-03-18 | Initial version | # APPNOTE-26 BCF Overview and Impact on System Performance v1 [Download as PDF](https://www.morsemicro.com/resources/appnotes/MM_APPNOTE-26_BCF_Overview_and_Impact_on_System_Performance.pdf) ## 1 What is a BCF and why is it needed? A Board Configuration File (BCF) is a specialized configuration file used by the Morse Micro firmware to define and control hardware behavior and system parameters. Its primary role is to provide a layer of abstraction between the hardware and firmware, allowing system configuration to be customized without requiring firmware changes. A BCF file contains detailed settings that define how the hardware components should operate. These include control mappings for GPIO (General Purpose Input/Output) pins, transmit power levels across MCS rates, and state transitions of the Front-End Module (FEM) during transmit and receive modes. By externalizing hardware configuration, BCFs enable customization for different hardware variants, regional compliance requirements, and performance optimization. This centralized approach simplifies development, deployment, and updates while maintaining compatibility and traceability, significantly reducing the complexity and cost of managing Wi-Fi HaLow systems. *** ## 2 Key Functions of a BCF A BCF is loaded by the Morse Micro firmware at runtime, allowing the firmware to precisely configure system parameters to ensure optimal performance of the Morse Micro chip. A correctly calibrated and configured BCF provides significant benefits in terms of performance, compliance, and operational reliability. The following outlines the key functions covered by BCF configurations: Front-End Module (FEM) Control\ A BCF governs the seamless transitions of the Front-End Module (FEM) between states such as transmit, receive, and sleep modes. Properly defined GPIO mappings facilitate features like Low Noise Amplifier (LNA) bypass in Rx mode, enabling precise signal handling and gain management Output Power Optimization\ A BCF defines MCS-specific power backoffs and frequency-specific power offsets, optimizing the power amplifier's operation across Modulation and Coding Schemes (MCS) and bandwidths. This ensures effective power output control while maintaining signal integrity. Flattened Power Output Across Frequency\ By applying frequency-specific power offsets, a BCF flattens the power output curve across the frequency range. This function maintains consistent transmit power, aligning with both performance standards and regulatory requirements. Compliance of Regulatory Standards A BCF ensures the device operates within regulatory constraints by managing power levels, particularly for band-edge channels, to adhere to spectral emission limits. A correctly configured and calibrated BCF is critical for achieving optimal performance, ensuring regulatory compliance, and maintaining reliable operation. Proper validation and implementation of the BCF unlock the full potential of Morse Micro systems while minimizing risks and operational challenges. ### 2.1 Impact of a Misconfigured BCF The use of an incorrect or poorly configured BCF can lead to several negative outcomes, including: * Reduced Output Power: Suboptimal power settings result in diminished signal strength. * Limited Connection Range: Improperly configured FEM receive states degrade the device's ability to detect and process incoming signals. * Decreased Throughput: Inefficient MCS rate power configurations hinder data transmission performance. * Regulatory Non-Compliance: Improper settings can cause spectral emission mask (SEM) violations, leading to non-compliance with regulatory standards. *** ## 3 Where Can I Access the Correct BCF File for My Device? The correct BCF required for your device depends on the source of the hardware being used. Sources of BCF files may include: * Morse Micro Evaluation Kits: If you have purchased an evaluation kit directly from a stocking distributor (e.g. Mouser), the appropriate BCF file is provided alongside the kit or available for download from the Morse Micro support portal. * Morse Micro Module Vendors: For devices incorporating a Morse Micro chip through third-party module vendors, the vendor provides a customized BCF tailored to their specific hardware configuration. Using this vendor-supplied BCF is essential for ensuring proper operation. * OEM Products with Morse Micro Chips: If the device is part of an OEM product, the BCF file will be preloaded on the device by the OEM. In this instance, there is no need for the customer or user to have any interaction with the BCF. When using a third-party vendor module, it is essential to use the vendor-provided BCF. Module vendors carefully optimize their BCFs to ensure the best performance for their specific hardware. Relying on a generic or incorrect BCF can negate these optimizations, potentially causing non-compliance, degraded performance, or system instability. *** ## 4 BCF and Firmware Dependencies BCF files are closely linked to the system's firmware (FW) version, with compatibility governed by a structured versioning system. BCFs are versioned using a major.minor.patch format. A change in the major version indicates incompatibility with previous FW versions, requiring users to update both the firmware and BCF to the newer compatible versions. Minor and patch updates maintain compatibility but may introduce parameter or feature changes. When transitioning to a new FW version, it is critical to ensure that the corresponding BCF version is also updated to maintain optimal system performance and compatibility. # APPNOTE-28 Morse Micro Rate Control v2 [Download as PDF](https://www.morsemicro.com/resources/appnotes/MM_APPNOTE-28_Morse_Micro_Rate_Control.pdf) ## 1 Scope This document covers the design of the Morse Micro Rate Control (MMRC) system. It covers the key mechanisms used by MMRC to choose the best rate and provide a set of rates for the driver to apply to transmit packets. MMRC selects the rates specifically for unicast data packets. ## 2 History Originally Morse Micro used the Minstrel rate control algorithm supplied with the mac80211 driver in the linux kernel. This algorithm works reasonably well, however it was decided to write our own algorithm for the following reasons: 1. In testing Minstrel was not working optimally for 802.11ah. The expectation is that the rate algorithm should be able to get very close to the best fixed-rate throughput at each attenuation point. See the comparison in Figure 1. 2. Minstrel doesn’t support the 802.11ah rate MCS 10. 3. Minstrel is slow to react to changes in the environment. 4. Designing a new rate control algorithm gives Morse Micro the ability to customize and improve the rate control algorithm beyond what Minstrel provides. ## 3 Overview MMRC controls the MCS, bandwidth and guard interval used for the transmission of packets. It uses recent statistics to determine the PER for various rates and from that decides which rate is best for the highest throughput. The statistics are averaged over time to minimize the impact of minor fluctuations in conditions on the rate. The rates are applied to each packet at the driver, before they are passed to the chip for transmission. The firmware honors the rates set and does not modify them (unless fixed rates are set in the firmware). Alternate rates, close to the current best rate, are sampled periodically to check if another rate could be better in the current conditions. ## 4 Details ### 4.1 Initialization When a device associates a new set of rate structures are assigned in MMRC and initialized. The range of rates, bandwidth, and guard intervals allowed (from the S1G capabilities of both devices) are used to determine all the available rates for this association. Also at this time the initial best rate is selected. It is chosen based on the maximum bandwidth of the association and the averaged RSSI of the received association frames. The initial best rates are set as follows | Average RSSI (dBm) | Initial Best Rate | | | | | ------------------ | ----------------- | ----- | ----- | ----- | | Association BW | 1MHz | 2MHz | 4MHz | 8MHz | | -70 or more | MCS 7 | MCS 7 | MCS 7 | MCS 7 | | -71 to -85 | MCS 3 | MCS 3 | MCS 3 | MCS 3 | | -86 or less | MCS 3 | MCS 3 | MCS 0 | MCS 0 | Table 1 - Initial Best Rates ### 4.2 Statistics #### 4.2.1 General Statistics are gathered from each transmit packet. The number of attempts and successes for each rate are tallied over a rate cycle period (100ms). These are then processed each rate period to generate the exponential weighted moving average (EWMA) of the percentage of successful attempts. This is done for each rate currently in use. The EWMA is used to debounce the statistics to avoid changing rates due to temporary volatility. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/n6DzDecyHONCFnaVHXPn/Unknown%20image) Figure 2 - Statistics Processing The statistics are usually collected and processed over the 100ms rate period, however if traffic volumes are not sufficient, the statistics will continue to accumulate over more rate periods until a minimum number of statistics is collected for that rate. #### 4.2.2 Collision Data As much as possible MMRC avoids collecting statistics for packet attempts that most likely failed due to collisions rather than the rate itself. This includes collisions due to non Wi-Fi/802.11ah as well as competing 80211ah transmissions. It does this by using only statistics from acknowledged A-MPDUs as long as there are at least some successful MPDUs at that rate. So if the whole A-MPDU is lost MMRC ignores the failed MPDUs for the purpose of its statistics as long as some A-MPDUs do receive a block ACK. That way we don’t penalise a rate because of collisions. Dropping rates while there are collisions is only likely to result in more collisions as the lower rate packets have larger airtime. Additionally, as the receiver can decode the rate, so the issue doesn’t lie with the rate itself. Obviously, if all packets at that rate fail, then we use all the packet statistics so we avoid using that rate. ### 4.3 Sampling In order to improve the best rate to higher a MCS in favourable scenarios, MMRC samples other rates. Basically, other rates close to the current best rate are attempted periodically. While doing this the best rate is used as the first retry rate to minimise disruption if the sampled rate is no good. Sampling is done periodically, with a high 1 in 5 sampling frequency used immediately after association (to help rates converge faster) and a much slower (1 in 50 or 100) used after convergence is achieved. Generally higher rates are sampled, as lower rates are naturally attempted when retries are required, which mostly covers the case where a lower best rate is optimal. The rate to sample within these parameters is chosen randomly. Sampling will try other guard interval settings and if the MCS is low it will try lower bandwidths as well. ### 4.4 Decision Logic #### 4.4.1 General The choice of best rate is made by looping through all the rates with recent statistics, calculating a simplified “expected throughput” per rate and comparing them to pick the rate with the highest expected throughput. The “expected throughput” is calculated by taking the success percentage for the rate and multiplying it by the physical data rate. This obviously will overstate the throughput, but works for comparing rates because each rate is equally affected. It also ignores * packet sizes * A-MPDU aggregate sizes * fragmentation * overheads (preamble, headers, SIFS, backoff, ACKs, etc) #### 4.4.2 Volatile Conditions Detection and Handling MMRC detects unstable environments (such as those with sporadic interference) by comparing the current PER for the best rate to the averaged PER. If the current PER varies up and down from the average PER by more than 5% (over time) then we subtract the EWMA of the absolute PER variation from the PER when calculating the “expected throughput”. This is only done for the best rate since it is the rate normally being used and therefore the rate whose statistics are most affected by the variations. ### 4.5 Applying Rates Each packet is allocated a set of rates to use should multiple attempts be required to transmit the packet successfully. In general, a packet is allocated up to 4 different rates. For most packets the rates allocated will be the best rate, then the next MCS down, then the next down from that and finally the MCS down from the 3rd rate. So if the best rate is MCS 7, the rates allocated would be MCSs 7, 6, 5, 4. The bandwidth and guard interval would remain the same in this case. *** | Entry | MCS | Attempts | | ----- | --- | -------- | | 1 | 7 | 2 | | 2 | 6 | 2 | | 3 | 5 | 2 | | 4 | 4 | 2 | Table 2 - Example of a Standard Rate Table Under normal circumstances, each of these 4 rates would be attempted twice, giving a total number of attempts of 8 for each packet. As mentioned above in the sampling section, when sampling a new rate the sample rate will be the first attempted, then followed by the best rate. After that the same 3rd and 4th rates as the normal case. So if MCS 5 is the best rate, normally a packet would use MCSs 5, 4 3 and 2. However, if MMRC is sampling MCS 7, the rates attempted would be MCSs 7, 5, 3 and 2. So the rate table for the sampled packet would be: | Entry | MCS | Attempts | | ----- | --- | -------- | | 1 | 7 | 1 | | 2 | 5 | 2 | | 3 | 3 | 2 | | 4 | 2 | 2 | Table 3 - Example of a Sampling Rate Table *** ## 5 Statistics MMRC accumulates statistics into debugfs files. Two files are created, they are 1. mmrc\_table: this contains a readable table of the statistics for each rate. 2. mmrc\_table\_csv: this is the mmrc\_table in CSV format. To generate these files you will need to mount debugfs on the device. The files are located on the device in the directory: /sys/kernel/debug/ieee80211/phy\*/morse *** Here is a sample of part of the mmrc\_table from MCS 5 to 7 ``` Morse Micro S1G RC Algorithm Statistics: Peer 0c:bf:74:cb:45:51 bw guard evid rate_sel mcs#/ss index airtime TP(max) TP(avg) prob l ast_rty last_suc last_att tot_suc tot_att mpdu_suc mpdu_fail 1MHz LGI 0 MCS5 /1 40 5800 0.00 0.00 0 0 0 0 0 0 0 0 1MHz SGI 0 MCS5 /1 41 5216 0.00 0.00 0 0 0 0 0 0 0 0 2MHz LGI 0 MCS5 /1 42 2640 0.00 0.00 0 0 0 0 0 0 0 0 2MHz SGI 0 MCS5 /1 43 2374 0.00 0.00 0 0 0 0 0 0 0 0 4MHz LGI 0 MCS5 /1 44 1240 0.00 0.00 0 0 0 0 0 0 0 0 4MHz SGI 0 MCS5 /1 45 1115 0.00 0.00 0 0 0 0 0 0 0 0 8MHz LGI 0 MCS5 /1 46 560 23.40 23.39 100 0 0 0 3 3 0 0 8MHz SGI 0 P MCS5 /1 47 503 26.00 25.99 100 0 0 0 5 5 0 0 1MHz LGI 0 MCS6 /1 48 4360 0.00 0.00 0 0 0 0 0 0 0 0 1MHz SGI 0 MCS6 /1 49 3921 0.00 0.00 0 0 0 0 0 0 0 0 2MHz LGI 0 MCS6 /1 50 2000 0.00 0.00 0 0 0 0 0 0 0 0 2MHz SGI 0 MCS6 /1 51 1798 0.00 0.00 0 0 0 0 0 0 0 0 4MHz LGI 0 MCS6 /1 52 920 0.00 0.00 0 0 0 0 0 0 0 0 4MHz SGI 0 MCS6 /1 53 827 0.00 0.00 0 0 0 0 0 0 0 0 8MHz LGI 0 MCS6 /1 54 440 26.32 26.32 100 0 0 0 3 3 0 0 8MHz SGI 0 B MCS6 /1 55 395 31.00 29.24 100 0 0 0 1769 1786 0 0 1MHz LGI 0 MCS7 /1 56 3840 0.00 0.00 0 0 0 0 0 0 0 0 1MHz SGI 0 MCS7 /1 57 3453 0.00 0.00 0 0 0 0 0 0 0 0 2MHz LGI 0 MCS7 /1 58 1760 0.00 0.00 0 0 0 0 0 0 0 0 2MHz SGI 0 MCS7 /1 59 1582 0.00 0.00 0 0 0 0 0 0 0 0 4MHz LGI 0 MCS7 /1 60 840 0.00 0.00 0 0 0 0 0 0 0 0 4MHz SGI 0 MCS7 /1 61 755 0.00 0.00 0 0 0 0 0 0 0 0 8MHz LGI 0 MCS7 /1 62 360 29.25 29.24 100 0 0 0 4 4 0 0 8MHz SGI 0 A L MCS7 /1 63 323 37.37 31.84 98 0 0 0 107288 110173 0 0 1MHz LGI 0 MCS10/1 64 64000 0.00 0.00 0 0 0 0 0 0 0 0 1MHz SGI 0 MCS10/1 65 57562 0.00 0.00 0 0 0 0 0 0 0 0 Amount of packets sent: 111111 including: 865 look-around packets ``` Figure 3 - Example mmrc\_table output Note, in the mmrc\_table the look-around rate is the sampled rate. The table below describes each field | Parameter | Description | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | bandwidth | The bandwidth of the rate (eg. 1, 2, 4, 8 MHz) | | guard | The guard interval of the rate (SGI, LGI) | | evidence | An internal metric of ‘evidence’ which reflects how relevant a rate is depending on how many times it has been attempted recently. Takes values between 0 and 100 with 100 being most relevant. | | rate\_selection |

Indicates what rates have been selected the last time the rate selection was updated. Takes on the following values:
A - Rate has the best throughput
B - Rate is 1 MCS lower than the best rate
C - Rate is 2 MCSs lower than the best rate
P - Rate is 3 MCSs lower than the best rate
L - Look around (or sampled) rate
Note that multiple letters could appear in a single row.

| | mcs | The MCS index of the rate. | | ss | The number of spatial streams of the rate | | index | The unique index of the rate into the MMRC table (each unique combination of rate parameters maps to a unique index) | | airtime | The transmit time in microseconds at this rate of a packet with the ‘default packet size’ (9600 bits or 1200 bytes) | | max\_throughput | Maximum throughput seen at this rate in Mbps. (Theoretical max tput \* probability percentage) | | average\_throughput | The average throughput seen at this rate in Mbps (based on theoretical throughput \* probability percentage, averaged over time) | | probability | Percentage probability that the rate will succeed (integer, 0-100) | | last\_retry | Number of retries at this rate since last table update | | last\_success | Number of successful transmissions at this rate since last table update | | last\_attempts | Number of times this rate was attempted since last table update | | total\_success | Total number of times this rate had a successful transmission | | total\_attempts | Total number of times this rate was attempted | | mpdu\_success | The number of successful MPDUs in acknowledged A-MPDUs at this rate since last table update | | mpdu\_failures | The number of failed MPDUs in acknowledged A-MPDUs at this rate since last table update | | mac\_address | The mac address of the peer that this rate applies to | Table 4 - MMRC debugfs Field Descriptions ## 6 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | ------------------------ | | 01 | 08/08/2024 | Initial release. | | 02 | 3/06/2025 | revised MMRC description | # APPNOTE-29 Bypass Boobytrap v1 [Download as PDF](https://www.morsemicro.com/resources/appnotes/MM_APPNOTE-29_Bypass_Boobytrap.pdf) ## 1 Scope This App Note applies to Morse Micro module reference designs incorporating an external power amplifier (PA) (e.g. MM6108-MF08651 Bailey\_v13) ## 2 Introduction High-frequency circuit performance is often influenced by unintended parasitic impedances, which can introduce variability in signal behavior across different boards. In RF designs, even minor variations in component tolerances, PCB layout, or assembly processes can lead to significant differences in circuit performance. Understanding these parasitic effects is critical to ensuring reliable and consistent operation. This application note examines the impact of parasitic impedances in the MM6108-MF08651-US (Bailey 13.3) reference design, specifically within the front-end module (FEM). The observed variability in insertion loss and gain is attributed to components operating in their parasitic region, where impedance parameters are not well controlled. This uncontrolled behavior may lead to significant unit-to-unit variation. Through circuit modeling, simulation, and experimental validation, we analyze these effects and propose design modifications to improve performance consistency. The findings of this study highlight the importance of accurately predicting and mitigating parasitic influences in high-frequency circuits. The methodologies presented here—modeling, simulation, and physical validation—provide a systematic approach for addressing similar design challenges in RF applications. ## 3 Parasitic Impedances In electronic circuits, performance variability can arise from multiple sources, including noise, manufacturing tolerances, and parasitic effects inherent in the design and implementation of components. Understanding the cause of such variability is critical to ensuring reliable performance, especially in high-frequency and RF systems where small deviations can have significant effects. This document investigates the root causes of variability observed in MM6108-MF08651-US (Bailey 13.3) reference design circuit, focusing on the role of parasitic impedances in key components. The observed variability manifests on a per-board basis, meaning that individual boards show consistent results when tested repeatedly, but performance differs between boards. This behavior suggests that the issue is not due to random noise but rather due to component tolerances or parasitic phenomena. We aim to analyze the performance of this circuit by modeling and simulating potential sources of variation. By considering parasitic impedances and their effects on circuit performance, we can better understand the observed behavior and validate whether these effects align with experimental data. Ultimately, this analysis provides a foundation for explaining the circuit's performance and identifying strategies to mitigate variability. Parasitic impedances are unintended electrical characteristics that arise due to the physical properties of components and circuit layouts. These parasitic effects are particularly significant in high-frequency circuits, where small inductive or capacitive elements can substantially alter the behavior of a design. In real-world components, idealized behaviors are rarely achieved. For example: * Capacitors exhibit equivalent series inductance (ESL) and equivalent series resistance (ESR) due to their construction and materials. * Inductors can have parasitic capacitances that affect their performance at higher frequencies. The impact of these parasitics is magnified when operating in the RF range, where minor variations can lead to significant performance changes. These variations are influenced by: 1. Manufacturing Tolerances: Variability in the physical dimensions of components, which affect their electrical properties. 2. Assembly Process: Placement of components on the PCB, solder volume, and pad geometries, which can introduce additional parasitics. 3. PCB Design: Trace lengths, via placement, and layer stack-ups that contribute to overall impedance characteristics. *** ### Example: Capacitor Parasitics To illustrate, consider the behavior of capacitors. An ideal capacitor would exhibit a constant capacitance value. However, due to parasitic elements, its impedance varies with frequency, as shown in the following schematic model: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/4yNKQC74tONBOsVjB5Jl/Unknown%20image) In this model: * The nominal capacitance dominates at low frequencies. * Parasitic inductance (ESL) becomes significant at higher frequencies, causing a self-resonant frequency (SRF). * Beyond the SRF, the capacitor behaves inductively rather than capacitively. The following diagram demonstrates how a capacitor’s impedance changes across frequencies, highlighting the self-resonant frequency and the transitions between capacitive and inductive behavior: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/1svjEVCHcCbg3B7gvazK/Unknown%20image) Such parasitic behaviors introduce variability in circuit performance. ## 4 Focus of this Analysis Understanding parasitic effects in a general sense is essential for analyzing their potential impact on a specific circuit. In this investigation, the focus is on a front-end module (FEM) circuit containing capacitors, inductors, and an active device. The goal is to determine how parasitic elements, particularly in capacitors, could explain the variability observed across boards. To provide context, consider the following general schematic representation of the FEM section on the MM6108-MF08651-US (Bailey 13.3): ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/alprL5be3QfShMqY1xet/Unknown%20image) ### Parasitic Effects in the Front End Module In the FEM circuit, we identify the following components and their potential parasitic contributions: 1. C1 and C3: Decoupling capacitors that exhibit parasitic inductance (ESL) and resistance (ESR). Initially we will only model ESL, but later we will see that ESR also plays an important role in this particular circuit. These parasitics influence the behavior of the circuit, particularly at higher frequencies where parasitic effects dominate. 2. L2: An inductor modeled as an ideal component for simplicity, as its parasitics are not suspected to contribute significantly to product performance variability. 3. U1: The active device, suspected to have internal capacitive behavior, particularly at the gate or input stage of its (hypothesized) internal transistor. While details of its implementation are not known, a capacitive model is believed to provide a reasonable approximation. To better understand the role of these components and their parasitic contributions, a minimal circuit model was developed. This simplified representation isolates C1, L2, and C3 to focus on their combined effects on circuit behavior. By modeling these components with their associated parasitic elements, the interaction between the decoupling capacitors and the inductor can be analyzed, particularly at frequencies where parasitics dominate. The following diagram illustrates this minimal circuit: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/IP5vSckI5tZz0Du44vbO/Unknown%20image) In this diagram, P1 represents the RF input (the SKY\_TX net entering pin 1 of U1). We assume that pin 16 of U1 injects a bias onto the RF line and P2 represents the input to the main power amplifier transistor (the signal terminating here gets amplified to become the PA\_OUT signal). The values of ESL (L1 and L3) were selected to approximate typical values found in 0201 component footprints. *** ## 5 Simulation ### Simulating the Effect of Parasitic Variability The value of a capacitor (e.g. 10nF) is a function of the geometry employed. It is affected by the dielectric constant of the material used along with the area and separation of its metallic plates. These parameters are generally tightly controlled in the manufacturing process. However, the value of the parasitic impedances is not controlled nor guaranteed by the manufacturer. We could expect large component to component variation if these parasitic tolerances were the culprit. Furthermore, the manufacturer is not their only source; for example, the placement of the component on its pads or amount of solder used could also affect the parasitic behaviour. To model parasitic variability, we perform a Monte Carlo simulation that allows L1 to fluctuate within 10% of its nominal value. We then measure the insertion loss between P1 and P2 to see how it may be affected. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/Z6YtQGnDlhEbjrsZ3phW/Unknown%20image) Measuring at 915MHz we can see the insertion loss vary between 0.9dB and 1.6dB. From this we can see that a 10% variation in the 250pH parasitic inductance in the 10uF capacitor is sufficient to explain a 0.7dB variation in gain! The so-called ‘bypass boobytrap’ occurs due to the interaction between the smallest decoupling capacitor and the parasitic inductance of the second smallest decoupling capacitor. While this is a simplification—the actual resonance results from the combined influence of all components and parasitics—it highlights an unavoidable reality: a resonance will always exist somewhere. As designers, our responsibility is to predict its location and ensure it does not interfere with device operation, electromagnetic compatibility (EMC) requirements, or other critical considerations. ### Simulating the Current Solution It is well known that replacing the 82pF capacitor with a 100pF variant appears to resolve the issue—but why? An 18pF difference seems insignificant, especially compared to the adjacent 10nF capacitor. However, as our previous analysis has shown, this reasoning overlooks the impact of parasitic impedances. At higher frequencies, such as 900MHz, these parasitic effects become significant, making such assumptions unreliable. Lets update our schematic to match the new situation: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/vH7AUpRy22TDaVlvWjHI/Unknown%20image) We now simulate our circuit and measure the insertion loss between P1 and P2, with L1 still exhibiting a 10% variation: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/xQDs6T9cQA3chMuwgUqE/Unknown%20image) We have pushed the resonant frequency (resulting largely from the interaction between L1 and C3) from approximately 830MHz down to 770MHz. As a result, the variations caused by a 10% component tolerance are reduced to less than 0.1dB across the entire 902MHz to 928MHz range. Alternatively, changing C1 from 0201 to 0402 would increase the value of L1 and this would also shift the resonant frequency down by some amount. With 0201 component sizes, using C3 = 100pF ensures consistent performance when the recommended components are used. *** ## 6 Testing ### Testing the Current Solution This all works very well in theory, but does it actually work? To evaluate the circuit’s parasitic effects, we assembled a bare PCB with only C1, L2, and C3 intentionally omitting C22, C2, C4 and other secondary components. While these components contribute to the overall circuit behavior, their influence does not change the core finding: the variability issue is primarily driven by the resonance formed between C3 and the parasitic inductance of C1. This simplification allows for a direct comparison between empirical measurements and our simulation model, isolating the dominant source of variation. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/Fdqy9lWIMSyFaYULSDxs/Unknown%20image) Updating our prior schematic model, we now need to remove U2 and apply ESR to C1, and C3 because now that we are using real components, they can no longer be neglected. For 0201 components, 100mΩ is a reasonable approximation. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/V7473oOXE1mAirPQMXIo/Unknown%20image) Here a network analyser measurement of the impedance posed by our decoupling circuitry: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/V8hdoNph4eAQ355Lzf3I/Unknown%20image) Here are the results of simulation of our schematic model: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/WycRRWPP1SPqbTtae1Dh/Unknown%20image) By comparing the two graphs, we observe a dampened resonant peak in the 800 MHz to 900 MHz range, confirming that our schematic model captures the key factors influencing circuit behavior. This provides confidence in our approach. Further refining the simulation model to perfectly match the VNA measurement would be unproductive, as it would merely adjust parameters to fit a predetermined outcome rather than provide meaningful insight. Instead, with a viable simulation model in place, we have identified the critical components affecting performance and can anticipate their unintended parasitic behaviors. The model can only be truly validated by measuring actual component values and incorporating them into the simulation. This ensures the model reflects reality rather than simply being tuned to align with observations. Once validated, we can be confident that applying component modifications will resolve the issue, knowing exactly which elements to adjust and by how much. In the case of the MM6108-MF08651-US (Bailey 13.3) reference design, we have simulated and tested over a wide range of components and found component values that provide optimal performance when accounting for such parasitic interactions and component tolerance variations. *** ## 7 Conclusion This analysis has demonstrated that parasitic impedances impact circuit performance in the MM6108-MF08651-US (Bailey 13.3) reference design. The observed performance variability across boards is primarily due to components operating in their parasitic region, where impedance parameters are not well controlled. Through circuit modeling, Monte Carlo simulations, and empirical validation, we have identified the critical role of the C3 decoupling capacitor in contributing to this uncontrolled variability. By adjusting component values, specifically replacing C3 from an 82pF capacitor with a 100pF variant, the circuit shifts into an operating region where parasitic effects no longer cause significant performance variations. Simulation results indicate that this modification moves the resonance frequency outside the critical operating range, contributing to more consistent performance. Testing on physical hardware was used to validate these findings and reinforce the accuracy of the simulation model. ## 8 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | --------------- | | 01 | 10/01/2025 | Initial Release | # APPNOTE-31 How to Configure EasyMesh v1 [Download as PDF](https://www.morsemicro.com/resources/appnotes/MM_APPNOTE-31_How_to_Configure_EasyMesh.pdf) ## 1 Scope Wi-Fi EasyMesh is a standards-based solution for multi-AP Wi-Fi networks, enabling seamless and intelligent wireless coverage across homes and small offices. It simplifies network (re)configuration and device onboarding, requiring minimal user intervention while ensuring self-monitoring and optimized performance. While Wi-Fi EasyMesh by the Wi-Fi Alliance was designed for managing Wi-Fi 2.4GHz, 5GHz, and 6GHz radios, Morse Micro's HaLow-specific extensions enable the Wi-Fi HaLow radio to be managed alongside other Wi-Fi bands. Morse Micro’s OpenWrt uses the open source EasyMesh implementation called prplMesh provided by [prpl Foundation](https://www.google.com/url?q=https://prplfoundation.org/\&sa=D\&source=editors\&ust=1783414481989205\&usg=AOvVaw06W3Jyejl9Jb5qCEwWwAfO). This guide provides instructions for setting up prplMesh to form an EasyMesh network using HaLowLink1. The prerequisites for this application note are: 1. 2 × HaLowLink1 devices 2. Any router supporting 2.4GHz Wi-Fi or Ethernet with an active internet uplink 3. 1 x Laptop By following this application note, the reader will learn: * How to configure HaLowLink1 devices to setup Virtual Wire. * How to validate this is operating correctly. ## 2 Theory of Operation An EasyMesh network always consists of two types of logical entities: * One EasyMesh Controller * One or more EasyMesh Agents The EasyMesh Controller is a logical entity responsible for centralized management of all Wi-Fi access points (APs) within a local network. It acts as a master in the network instructing EasyMesh agent nodes on what to do. The EasyMesh Agent is a logical entity that executes the commands received from EasyMesh Controller and reports measurements and capabilities of the APs. EasyMesh agent interfaces with Wi-Fi subsystem to achieve the commands received from EasyMesh controller. Unlike a fully distributed 802.11s mesh, EasyMesh enforces a tree-based network topology, where all agents are coordinated via a single controller node. This centralised approach enables more predictable and manageable behaviour but differs from peer-to-peer or decentralised mesh networks. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/MgOnx1crKbveXLeyNEZA/Unknown%20image) ### 2.1 Simple EasyMesh Network ![Example EasyMesh Network](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/QyLNoPmPRgAiIxRXJ4PJ/Unknown%20image) *Example EasyMesh Network* To demonstrate the features and capabilities of EasyMesh with Wi-Fi HaLow radio, we will form a simple EasyMesh network with HaLowLink1 as shown in the figure with two nodes where one node must be configured as the EasyMesh controller, while the other node is configured as an EasyMesh agent. An existing router with a 2.4GHz Wi-Fi AP serves as an internet uplink connection, enabling devices in the EasyMesh network to access the internet. ## 3 How to Configure The following sections detail the configuration process for both the EasyMesh HaLow Gateway and EasyMesh Extender, along with their corresponding UCI settings. The Web UI features a configuration wizard page designed to simplify the setup of different modes and switch between them quickly. It uses OpenWrt UCI/UBUS configuration interface to apply the required configuration for a specific mode. These UCI configurations are then used by OpenWrt applications to configure the device. ### 3.1 Getting Access to GUI Connect your computer to HaLowLink1’s LAN port using an Ethernet cable. The default setting in HaLowLink1 assigns your computer an IP address in 192.168.12.x range with the default gateway set to 192.168.12.1. Once your laptop is connected to the HaLowLink’s local network, use a browser to connect to [http://192.168.12.1](https://www.google.com/url?q=http://192.168.12.1\&sa=D\&source=editors\&ust=1783414481995632\&usg=AOvVaw3R89DI7QLMuE3UtFdK_O03). Use the Device Username and Device Password printed on the rear side of the HaLowLink1 device to login. After logging in, the home page should be visible, similar to the below screenshot: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/IKkTxUgi2BqUMbJhYSkT/Unknown%20image) ### 3.2 EasyMesh HaLow Gateway The objective is to configure HaLowLink1 in router mode to function as an EasyMesh HaLow Gateway running the EasyMesh Controller service. The figure below depicts our reference configuration. wlan-prpl is a HaLow AP interface in a lan network. phy0-sta0 is a 2.4GHz Wi-Fi station interface in a wan network for internet uplink. phy0-ap0 is a 2.4GHz Wi-Fi AP interface in lan network WAN Ethernet port attached in wan network. LAN Ethernet port attached to the lan network. EasyMesh HaLow Gateway configuration involves the following high level networking configuration steps (detailed steps shown in following sections): 1. Set up a lan network with a dhcp server with the IP range 192.168.12.x. 2. Set up a wan network with dhcp client service for the uplink internet. 3. Create a bridge interface br-prpl to serve the LAN network. 4. Create an AP interface wlan-prpl on HaLow radio and attach to br-prpl. 5. Create a station interface phy0-sta0 on 2.4GHz radio and add to wan for internet uplink. 6. Attach LAN and WAN Ethernet ports to lan and wan network respectively. 7. Create a lan and wan firewall zone which maps to lan and wan network. 8. Enable forwarding rules between lan and wan network allows lan clients to access the internet. 9. Enable prplMesh in Controller + Agent mode. #### 3.2.1 How to Configure The following steps use the Wizard to create the EasyMesh HaLow Gateway configuration outlined above: 1. Navigate to the Wizard option in the side menu. 2. HaLow Mode : Choose EasyMesh Controller option. 3. Network Mode allows us to choose the preferred uplink. 4. If you have a Wi-Fi route with 2.4 GHz radio, we can select “use 2.4GHz for an uplink”. And refer to the section on how to configure 2.4 GHz Wi-Fi as uplink. 5. If you prefer to use Ethernet as an uplink, select the first option. 6. Click Save & Apply and wait for successful initialization. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/rRs4B8FdKuP9hFaoTRdz/Unknown%20image) #### 3.2.2 Controller Status ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/TGDNQuo4VLb8bgeete7E/Unknown%20image) To confirm the EasyMesh Controller is enabled properly, status information is available on the Home page under EasyMesh Controller card. Agent status active shows a successful configuration of EasyMesh Controller #### 3.2.3 Configure 2.4 GHz Wi-Fi as uplink ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/1LWe5V7UKDeUwF0QlqJs/Unknown%20image) Navigate to the Uplink (2.4 GHz) card from the Home page and click Disconnected cross or use the expand arrow to access the uplink configuration tab. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/IPMiD86gd2LcVgZLlZ2z/Unknown%20image) Clicking the search option lists available Wi-Fi networks. Choose your router’s SSID and update your network settings. Click the Save & Apply button. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/JS9gdlLpxSFjuHBHzzjG/Unknown%20image) The uplink card status should change to Connected with a tick once the uplink connection is successfully established. #### 3.2.4 UCI configuration (Optional) Using the Wizard is easy but it skips over a lot of underlying detail that can help understanding what is going on. This section explains the underlying configuration changes made to setup the EasyMesh HaLow Gateway. UCI configurations generated by following the steps represent the changes from sections from 3.2.1 to 3.2.3. This section can be safely skipped for those that are not interested in the inner workings of UCI configurations. At a high level configuring EasyMesh HaLow Gateway involves: * changes in wireless UCI configuration * configures HaLow radio, * configures an access point interface(wlan-prpl) and attach to lan. * configures 2.4GHz Wi-Fi radio, * configures a station interface(phy0-sta0) and attach to wan * changes in prplmesh UCI configuration, * configures EasyMesh in Controller + Agent mode, and * configures list of wifi-device and wifi-interface to be managed under EasyMesh * changes in network UCI configuration, * creates a network bridge called br-prpl, and * attaches the lan network interface to bridge br-prpl. * changes in firewall UCI configuration, * creates a firewall zone for the lan network, and * enables forwarding rules between lan and wan network. * changes in dhcp UCI configuration * runs a DHCP server in the lan network. * runs a DHCP client in wan to receive an IP address from uplink router The configuration files described below are located in the /etc/config/ directory. | **wireless** | | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | UCI Configuration | Description | |

config wifi-device 'radio1'
option type 'morse'
option path \
option bcf \
option band 's1g'
option hwmode '11ah'
option reconf '0'
option country 'US'
option channel '44'
config wifi-iface 'default\_radio1'
option mode 'ap'
option wds '1'
option device 'radio1'
option network 'lan'
option ssid 'MorseMicro'
option encryption 'sae-mixed'
option key 'Morse\@123'
option disabled '0'
option bss\_transition '1'
option multi\_ap '3'
option ieee80211k '1'
option ieee80211w '2'
option ifname 'wlan-prpl'
option wps\_virtual\_push\_button '1'
option wps\_independent '0'
option auth\_cache '0'

|

wifi-device config section radio1 refers to the physical HaLow radio in a device. The options present in this section describe properties common across all wireless interfaces on this radio device, such as country, channel.

wifi-iface config section provides a means to create an access point or station interface on a radio. This section contains interface specific properties like SSID and network credentials.
wifi-iface config section default\_radio1 creates an access point interface wlan-prpl on a HaLow radio device radio1 and attaches it with a lan network.
The SSID and network credentials specified in this section are propagated to all EasyMesh Agent nodes in the network through the EasyMesh auto configuration process.

| | **prplmesh** | | |


config prplmesh 'config'
option management\_mode 'Multi-AP-Controller-and-Agent'
option operating\_mode 'Gateway'
option enable '1'
option master '1'
option gateway '1'
option wired\_backhaul '1'
config wifi-device 'radio1'
option hostap\_iface 'wlan-prpl'

|

The configuration section for prplmesh contains options that allow users to enable or disable EasyMesh, along with its associated features, and modify EasyMesh behaviour.
Most configurations in the prplmesh config section have default settings shared by both EasyMesh Controller and Agent. The example on the left highlights only the difference between EasyMesh Controller and Agent.
wifi-device section facilitates the addition of wireless interfaces under EasyMesh management.
Example on the left adds AP interface wlan-prpl on HaLow radio device radio1 under EasyMesh management.
prplMesh expects radio1 and wlan-prpl to be preconfigured in the wireless setting.

| | **network** | | |


config interface 'lan'
option device 'br-prpl'
option proto 'static'
option ipaddr '192.168.12.1'
option netmask '255.255.255.0'
option ip6assign '60'
config interface 'wan'
option proto 'dhcp'
config device
option name 'br-prpl'
option type 'bridge'
option macaddr \
list ports 'usblan'
list ports 'lan'

|

interface config section provides a means to create a logical network interface.
In our example,
we create a lan network which is our primary local network in which we attach a HaLow AP interface (wlan-prpl).

We create a wan network and enable dhcp client for uplink internet connectivity to which we attach the 2.4GHz station interface(phy0-sta0) and WAN Ethernet port.
device config section allows us to create a linux network bridge to which we can attach our network ports.

| | **firewall** | | |


config zone
option name 'lan'
list network 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
config zone
option name 'wan'
list network 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu\_fix '1'
config forwarding
option src 'lan'
option dest 'wan'
option enabled '1'

|


zone config section allows us to create a logical firewall zone which corresponds to a logical network we created in network config.
In our example,
We create a firewall zone for the lan network where we should allow input, output and forwarding network traffic.
We create a firewall zone for the wan network where we should allow only egress traffic.
forwarding config section allows to enable/disable the traffic flow between firewall zones.
In this example, we want to route the traffic between the lan to the wan zone which enables devices on the lan network to access the internet.

| | **dhcp** | | |


config dnsmasq
option domainneeded '1'
option localise\_queries '1'
option rebind\_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option cachesize '1000'
option authoritative '1'
option readethers '1'
option localservice '1'
option ednspacket\_max '1232'
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
config dhcp 'wan'
option interface 'wan'
option ignore '1'

|

dhcp config allows us to configure dhcp server and instances in the logical network that we created in network config.
The example shown here enables dhcp server in lan network and disables(option ignore) it in wan network.

| *** ### 3.3 EasyMesh HaLow Extender The objective is to configure HaLowLink1 in extender mode to function as an EasyMesh HaLow Extender running EasyMesh agent service. Setting up the HaLow Extender involves (detailed steps in the following sections): 1. Set up a LAN network and enable DHCP client service to receive IP from EasyMesh Gateway. 2. Create a bridge interface br-prpl to serve the LAN network. 3. Create a station interface (wlan-prpl-1) on HaLow radio and attach to br-prpl. 4. Create an AP interface (wlan-prpl) on HaLow radio and attach to br-prpl. 5. Create an AP interface (phy0-ap0) on 2.4GHz radio and attach to br-prpl. 6. Attach LAN and WAN Ethernet ports to br-prpl. 7. Attaching all these interfaces to br-prpl keeps them in the lan. 8. Enable prplMesh in Controller + Agent mode. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/5dRa9NNOIxpygvRAwW4I/Unknown%20image) wlan-prpl-1 is a HaLow station interface in a lan network providing HaLow Backhaul Link connectivity with EasyMesh HaLow Gateway. wlan-prpl is a HaLow AP interface in a lan network to serve HaLow Clients and to further extend HaLow network phy0-ap0 is a 2.4GHz Wi-Fi AP interface in lan network WAN Ethernet port attached in lan network. LAN Ethernet port attached to the lan network. #### 3.3.1 How to Configure EasyMesh Agent configuration in HaLowLink1 does not require a web interface. It is simplified into the following two steps: 1. Switch HaLowLink1 to extender mode. Refer to below section 3.3.2 Extender mode. 2. Use push button to pair this extender with another HaLowLink1 configured as EasyMesh Controller. Refer to below section 3.3.3 Pairing Extender with Gateway. #### 3.3.2 Extender mode 1. Power on the HaLowLink1 that is to be configured as an extender. 2. Wait until the status LED turns solid green, indicating that the HaLowLink1 has been initialised. 3. Press and hold the mode button until the status LED starts flashing aqua. Initially, the LED will flash green slowly before transitioning to flashing aqua, signaling that the button can be released for extender mode configuration. 4. Wait for the status LED to turn solid aqua, which indicates the successful configuration of extender mode. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/CXned2K1PjwKlCVhHyuf/Unknown%20image) #### 3.3.3 Pairing Extender with Gateway This step allows the extender to connect with HaLowLink1 configured as EasyMesh Gateway. 1. Ensure the extender’s Status LED is in solid aqua mode. 2. Ensure the EasyMesh HaLow Gateway’s status LED in solid green. 3. Press and immediately release the mode button on the bottom of the extender and EasyMesh HaLow Gateway device at the same time.[\[a\]](#cmnt1) 4. At the start of the button press, the Wi-Fi HaLow LEDs on both devices will begin slowly flashing purple. Upon successful pairing, both devices will display a solid purple Wi-Fi HaLow LED. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/leEkpfNOIZtWPSP1Fws2/Unknown%20image) #### 3.3.4 Agent Status ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/thoLHtiUykhKQ14olRKz/Unknown%20image) To confirm the EasyMesh Agent is enabled properly, status information is available on the extender’s Home page under EasyMesh Agent card. Agent status Active shows a successful configuration of EasyMesh Agent. #### 3.3.5 UCI configuration (Optional) This is an informative section intended to explain the EasyMesh Extender’s reference UCI configurations generated by following the steps from sections from 3.3.1 to 3.3.4. This section can be safely skipped for those that are not interested in the inner workings of UCI configurations. At a high level configuring EasyMesh Agent in extender mode involves, * changes in wireless UCI configuration, which * configures HaLow radio, * configures a backhaul station interface, * configures an access point interface and * attaches the access point and station interface with the lan network. * changes in prplmesh UCI configuration, which * configures EasyMesh in Agent mode and * configures list of wifi-device and wifi-interface (accesspoint and backhaul station) to be managed under EasyMesh * changes in network UCI configuration, which * creates a network bridge called br-prpl, * attaches the lan network interface to bridge br-prpl. * changes in firewall UCI configuration, which * creates a firewall zone for the lan network. * changes in dhcp UCI configuration, which * runs a DHCP client in lan to receive ip address from a gateway. *** | **wireless** | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | UCI Configuration | Description | |


config wifi-device 'radio1'
option type 'morse'
option path \
option bcf \
option band 's1g'
option hwmode '11ah'
option reconf '0'
option country 'US'
option channel '44'
config wifi-iface 'default\_bh\_radio1'
option device 'radio1'
option disabled '0'
option mode 'sta'
option multi\_ap '1'
option wds '1'
option ifname 'wlan-prpl-1'
option network 'lan'
config wifi-iface 'default\_radio1'
option mode 'ap'
option wds '1'
option device 'radio1'
option network 'lan'
option ssid 'MorseMicro'
option encryption 'sae-mixed'
option key 'Morse\@123'
option disabled '0'
option bss\_transition '1'
option multi\_ap '3'
option ieee80211k '1'
option ieee80211w '2'
option ifname 'wlan-prpl'
option wps\_virtual\_push\_button '1'
option wps\_independent '0'
option auth\_cache '0'

|


wifi-device config section radio1 refers to the physical HaLow radio in a device. The options present in this section describe properties common across all wireless interfaces on this radio device, such as country, channel.



wifi-iface config section default\_bh\_radio1 creates a backhaul station interface wlan-prpl-1 on a HaLow radio device radio1 and attaches it with a lan network. This interface is used as a backhaul link.



wifi-iface config section default\_radio1 creates an access point interface wlan-prpl on a HaLow radio device radio1 and attaches it with a lan network.
EasyMesh Agent configures wlan-prpl with the SSID and network credentials received from EasyMesh Controller during the Auto configuration process.
For standard EasyMesh operation, AP interface wlan-prpl and backhaul station interface wlan-prpl-1 must be connected to the same network, which in our case is lan.

| | **prplmesh** | | |


config prplmesh 'config'
option management\_mode 'Multi-AP-Agent'
option operating\_mode 'WDS-Repeater'
option enable '1'
option master '0'
option gateway '0'
option wired\_backhaul '0'
config wifi-device 'radio1'
option hostap\_iface 'wlan-prpl'
option sta\_iface 'wlan-prpl-1'

|

Most configurations in the prplmesh config section have default settings shared by both EasyMesh Controller and Agent. The example on the left highlights only the difference between EasyMesh Controller and Agent.
Example on the left adds AP interface wlan-prpl and backhaul station interface wlan-prpl-1 on HaLow radio device radio1 under EasyMesh management.
prplMesh expects radio1 , wlan-prpl and wlan-prpl-1 to be preconfigured in the wireless setting.

| | **network** | | |


config interface 'lan'
option device 'br-prpl'
option proto 'dhcp'
option ipaddr '192.168.12.1'
option netmask '255.255.255.0'
option ip6assign '60'
config device
option name 'br-prpl'
option type 'bridge'
option macaddr \
list ports 'usblan'
list ports 'lan'

|


interface section creates a lan network attached to bridge br-lan, configured to run a dhcp client.



device section creates a linux network bridge br-lan and attaches lan network port to it.

| | **firewall** | | |


config zone
option name 'lan'
list network 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'

|

This example config creates a network zone for lan which is our primary local network where we should allow input, output and forwarding network traffic.
forwarding config section is not needed as the backhaul station interface wlan-prpl-1 is attached to the lan network.

| | **dhcp** | | |


config dhcp 'lan'
option interface 'wan'
option ignore '1'

| This section disables the DHCP server in the lan network. | *** ## 4 How to Verify To verify the successful configuration of Easymesh we can verify each of the below features of EasyMesh are working: * Unified network credentials across all HaLow APs. * EasyMesh Topology Tree ### 4.1 Unified network credentials All HaLow AP's are managed by controller and agent within an EasyMesh network. After the initial pairing process, they are configured with the same SSID and network credentials to ensure seamless connectivity. To verify the configuration 1. Login to EasyMesh extender node’s web UI. 2. we can find the extender’s IP address by clicking the DHCP Leases option under the Local Network card on the Home page. 3. Navigate to the Quick Config page. 4. Check the SSID and network credentials for the HaLow AP interface (wlan-prpl) match the EasyMesh Gateway’s credentials. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/urbXw55aNONQgYMJ9yMj/Unknown%20image) #### 4.1.1 EasyMesh Auto Configuration In an optimal EasyMesh network deployment, network credentials should propagate seamlessly to all EasyMesh agents without causing any disruption. However, since a single HaLow AP is used to serve both fronthaul clients and HaLow extenders, any changes made to the AP credentials on the HaLow Gateway will necessitate manual reconfiguration of the extender. *** ### 4.2 EasyMesh Topology Tree We can view the complete topology of the EasyMesh network through the EasyMesh Gateway’s web UI. Simply navigate to the EasyMesh Controller card on the home page and click the expand option to display the network topology. This page becomes accessible when at least one extender node is connected to the controller. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/yXa7kpl7WRvPUfgc5EgQ/Unknown%20image) ### 4.3 Read-Only Quick Config Page The configuration options for EasyMesh-managed wireless interfaces on the Quick Config page are set to read-only to prevent potential misconfigurations that could disrupt normal EasyMesh functionality. To modify the SSID or network credentials for HaLow interfaces, navigate to the Network-> Wireless page. Ideally, the SSID, security mode, and network key should be editable in the HaLow Gateway’s Quick Config page. However, this limitation in the web UI is not addressed until the OpenWrt 2.8.x release. *** ### 4.4 Useful Commands List the prplMesh applications root\@halowlink1-b19b:\~# ps | grep prpl 9426 root 15700 S /opt/prplmesh/bin/ieee1905\_transport 9427 root 22520 S /opt/prplmesh/bin/beerocks\_controller 9428 root 21844 S /opt/prplmesh/bin/beerocks\_agent 9474 root 17376 S /opt/prplmesh/bin/beerocks\_fronthaul -i wlan-prpl Enable prplMesh debug logs 1. To collect logs syslog (logread), set log\_syslog\_enabled to true in beerocks\_controller.conf and beerocks\_agent.conf located in /opt/prplmesh/config. 2. To collect logs in a text file, set log\_files\_enabled to 3. in the same configuration files, and use the log\_files\_path option to specify the desired file path. Command line Topology view 1. We can use beerocks\_cli to dump the EasyMesh network. root\@halowlink1-b19b:\~# /opt/prplmesh/bin/beerocks\_cli -c bml\_conn\_map GW\_BRIDGE: name: GW\_MASTER, mac: f2:flag\_bb:43:dc:f6:39, ipv4: 192.168.12.1 ETHERNET: mac: 3b:f6:dc:43:bb:f2 RADIO: wlan-prpl mac: 94:flag\_bb:43:dc:f6:39, ch: 44, bw: 8 S1G, freq: 924 MHz bVAP\[0]: wlan-prpl.0 bssid: 94:flag\_bb:43:dc:f6:39, ssid: halowlink1-b19b IRE\_BACKHAUL: mac: 96:flag\_bb:43:dc:f9:89, ch: 44, bw: 8 S1G IRE\_BRIDGE: name: IRE\_f9:89, mac: f2:flag\_bb:43:dc:f9:89, ipv4: 10.22.121.111 ETHERNET: mac: 8b:f9:dc:43:bb:f2 RADIO: wlan-prpl mac: 94:flag\_bb:43:dc:f9:89, ch: 44, bw: 8 S1G, freq: 924 MHz bVAP\[0]: wlan-prpl.0 bssid: 94:flag\_bb:43:dc:f9:89, ssid: halowlink1-b19b 2. We can use the below command to dump the EasyMesh Wi-Fi data elements.\ root\@halowlink1-b19b:\~# ubus call Device \_get '{"depth":10}' ## 6 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | --------------- | | 01 | 11/04/2025 | Initial release | # APPNOTE-32 How to Configure 802.11s Mesh v1 [Download as PDF](https://www.morsemicro.com/resources/appnotes/MM_APPNOTE-32_How_to_configure_802.11s_Mesh.pdf) ## 1 Scope This application note provides a guide on configuring and verifying using the 802.11s Mesh feature on Morse Micro OpenWRT products. This document outlines the configuration of an 802.11s Mesh network designed to provide backhaul connectivity for 802.11bgn Wi-Fi and LAN connections through 802.11ah HaLow links. The described scenario serves as a representative reference configuration. Please note that the latency and throughput of the network will depend on the 802.11ah link performance and the number of hops in the mesh. The prerequisites for this application note are: * 2 x [Morse Micro](https://www.google.com/url?q=https://www.morsemicro.com/end-products/\&sa=D\&source=editors\&ust=1783414770558592\&usg=AOvVaw0s3GXqmH-aKIdVbG-hToxv) [HaLow](https://www.google.com/url?q=https://www.morsemicro.com/end-products/\&sa=D\&source=editors\&ust=1783414770558704\&usg=AOvVaw333llVZQTWYGwTVpcS7RyD)[Link1](https://www.google.com/url?q=https://www.morsemicro.com/end-products/\&sa=D\&source=editors\&ust=1783414770558765\&usg=AOvVaw21RQ1RjXk2qPQsy_uUzkkg) devices, with the latest software installed (this guide was written based on v.2.7.3).[\[1\]](#ftnt1) * 1+ x additional [Morse Micro HaLowLink1](https://www.google.com/url?q=https://www.morsemicro.com/end-products/\&sa=D\&source=editors\&ust=1783414770559110\&usg=AOvVaw0e1tPdOPf75Ji-anReNZ2X) devices are required to test meshing behaviour such as self-healing and dynamic route finding. * 1 x laptop with ping, and traceroute installed. * 1 x internet connection accessible via 2.4GHz Wi-Fi with access credentials known. * Familiarity with accessing and configuring Morse Micro HaLowLink1 devices, as per the User Guide. By following this application note you will learn: * How to configure HaLowLink1 devices to setup an 802.11s mesh; * How to validate the mesh is operating; and * How to validate that the mesh is self-healing. *** ## 2 Theory of Operation 802.11s Mesh is a Wi-Fi feature that allows multiple wireless devices to “interconnect to create a[wireless LAN](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Wireless_LAN\&sa=D\&source=editors\&ust=1783414770560931\&usg=AOvVaw1BYODfbuKIW1r4POhFI1Bz) mesh network”. \[[link](https://www.google.com/url?q=https://en.wikipedia.org/wiki/IEEE_802.11s\&sa=D\&source=editors\&ust=1783414770561049\&usg=AOvVaw00HFe5gAAzE8y10yYWKWnA)] This can be used to extend the area covered by a network by creating wireless links that manage the multiple paths between nodes and is capable of automatically recovering connectivity and dynamically adjusting routes in response to environmental changes.. This application note uses multiple HaLowLink1 devices to create an 802.11s mesh network over the 802.11ah HaLow radios. This application note chooses to target a network that: * uses an 802.11bgn 2.4 GHz radio as a client connecting to a Wi-Fi hotspot running on mobile phone for uplink to the internet * provides a laptop access to the internet via 802.11bgn 2.4 GHz Access Points that are backhauled by the 802.11s mesh network via the 802.11ah HaLow radios. Note: an 802.11s mesh network can extend any network over wireless; can use Ethernet or other wireless for internet access; and can use Ethernet or other wireless as the means for accessing the mesh. This application note chooses the above topology to remove options in order to simplify the guide. The target network architecture from the choices above is shown below: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/SmWKxfHdeFB9yxW8rssH/Unknown%20image)) This network will demonstrate that from a laptop connected to Device 2 via 2.4GHz Wi-Fi can communicate to the internet via the 802.11ah Mesh network. The physical devices will be moved (or mesh thresholds changed) so the network topology changes to rely on a network path through Device 3, as shown in the diagram below: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/IDKd66ukEhsi1CZvC8JF/Unknown%20image)) This topology will demonstrate the mesh self-heals, and will validate that the laptop connected to the 802.11bgn 2.4 GHz can still communicate to the internet via the mesh network. ## 3 How to Configure This guide covers two different ways to configure 802.11s mesh in HaLowLink1 devices: 1. An approach that uses the UI Wizard and push button DPP (Device Provisioning Protocol). This is the easiest method. 2. An approach that uses manual configuration via the UI. This is more involved, but is more tailorable. Both approaches configure the following: * A single device (Device 1) is configured as the Mesh Gate - i.e. the device that provides integration to another distribution system. This device uses its 2.4GHz radio for uplink to an existing Wi-Fi network that has an internet connection. * A number of devices (e.g. Device 2, Device 3) that are configured as mesh nodes. These devices use their 802.11ah HaLow radio to participate in the mesh, and use their 802.11bgn 2.4GHz radio to provide an Access Point. Both approaches are documented below. Note: This guide does not cover setting regulatory domain, or channels for these devices. It is assumed you have set this correctly and are otherwise using the devices with factory defaults. Refer to the HaLowLink1 User Guide for detailed instructions regarding proper configuration of regulatory domain and wireless channels. *** ### 3.1 Recommended Approach - Configuring HaLowLink1 via Wizard and Push Button #### 3.1.1 Overview The HaLowLink1 device supports configuring an 802.11s Mesh and adding Extender devices to the mesh via a UI Wizard and DPP push buttons. This is the easiest way to configure an 802.11s mesh network. Pre-requisites: * 2 x HaLowLink devices, loaded with the latest software (2.7.3+) * Additional HaLowLink1 devices are required if you would like to test a multi-hop mesh and/or mesh self-healing. * 1 x laptop * 1 x mobile phone with Wi-Fi hotspot capability and an internet connection The high-level network architecture is shown in the diagram below: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/gpNv6jjODUcezJESMseA/Unknown%20image)) * Device 1 will provide the uplink to the internet by connecting as a client to the mobile phone’s “uplink” hotspot. Device 1 will operate as a Mesh Gate in the 802.11s mesh. * Device 2 will connect to the 802.11s mesh, will operate as a node in the 802.11s mesh, and will also operate an 802.11bgn Access Point. * The laptop will connect as a client to the 802.11bgn Access Point from Device 2, and will be able to reach the internet by having traffic travel over the mesh to Device 1, and then via the mobile phone to the internet. *** #### 3.1.2 Step-by-step guide for Wizard and Push Button approach The following is a step by step guide to configure and validate a mesh network. The two devices used as examples are HaLowLink1s with the following: * Device 1 - SSID: halowlink1-af0f * Device 2 - SSID: halowlink1-ae6b To provide an uplink for this guide, determine the SSID and password of your 2.4GHz uplink (this guide uses a phone hotspot configured with SSID: uplink and Password: uplink-password). **Step 1: Configuring Device 1 as a Mesh Gate** 1. Connect your laptop to Device 1 via its 802.11bgn 2.4 GHz (e.g. Wi-Fi SSID halowlink1-af0f, password printed on device label ) 2. Access the web UI at [http://192.168.12.1](https://www.google.com/url?q=http://192.168.12.1\&sa=D\&source=editors\&ust=1783414770569146\&usg=AOvVaw35XASRN1eRJj6mEBp4BTfH), login using the “Device Password” (printed on device label) and select the “Wizard” from the menu (direct [link](https://www.google.com/url?q=http://192.168.12.1/cgi-bin/luci/admin/morseapwizard\&sa=D\&source=editors\&ust=1783414770569382\&usg=AOvVaw3vZs6JKv4CAWOjMmD3EKi7)) 3. Choose HaLow Mode: 802.11s Mesh and Network Mode: “...use 2.4 GHz for an uplink”\ ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/gwqY1ftdUHb7dxS9mrkI/Unknown%20image)) 4. Click “Save and apply” 5. The device is now running an Access Point and Mesh Point on its 802.11ah radio and is still running an Access Point on its 802.11bgn radio. The device’s Wi-Fi SSID (halowlink1-af0f) is used as the Access Point SSID, and the Mesh ID. 6. Go to Home ([http://192.168.12.1/cgi-bin/luci/admin/home](https://www.google.com/url?q=http://192.168.12.1/cgi-bin/luci/admin/home\&sa=D\&source=editors\&ust=1783414770570106\&usg=AOvVaw09WItrMrxO0dJ-Q9xjC65-)) 7. Find the Uplink(2.4GHz) card, which should say “Disconnected” 8. Click the word “Disconnected” and provide the uplink network details (uplink / uplink-password)\ ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/JGGL1pxaMCxyom5vfVUE/Unknown%20image)) **Step 2: Validating Internet Connectivity on Device 1** Device 1 should now provide uplink to the internet via the configured 2.4 GHz uplink network. Steps to validate are: 1. Connect to Device 1’s 2.4 GHz Access Point (halowlink1-af0f) with your laptop. 2. Check you can reach the internet (i.e. load [www.morsemicro.com](https://www.google.com/url?q=http://www.morsemicro.com\&sa=D\&source=editors\&ust=1783414770571124\&usg=AOvVaw07biGoHSZKEgRfd9K9h9Ms) in your browser).\ Note: Please ensure that your laptop is not connected to the internet via another network during this test. **Step 3: Configuring Device 2 as a Mesh Extender** For more information, see the “HaLow extender” section in the HaLowLink1 User guide. 1. Put Device 2 into Extender mode by holding down the physical push button until the status light flashes aqua (i.e. 10+ seconds). 2. Wait for Device 2 to reboot into Extender mode (i.e. Status LED is solid Aqua) 3. Pair Device 2 with Device 1 by doing the following: 4. First press and release button on Device 1 to put it into pairing mode (Wi-Fi HaLow Status LED slowly blinks) 5. Press and release button on Device 2 to pair it with Device 1 (Wi-Fi HaLow Status LEDs should slowly blink in both devices). 6. Wait 30+ seconds, and both devices' HaLow status light should stop slow flash, and show solid/blinking traffic. **Step 4: Validating Mesh Connectivity on Device 2** Device 2 should now provide uplink to the internet via Device 1. Steps to validate are: 1. Connect to Device 2’s 2.4 GHz Access Point (halowlink1-ae6b) with your laptop 2. Check you can reach the internet (i.e. load [www.morsemicro.com](https://www.google.com/url?q=http://www.morsemicro.com\&sa=D\&source=editors\&ust=1783414770573091\&usg=AOvVaw0iLZp6qMgYT5PbDWIb2mFB) in your browser) You now have a functioning 802.11s mesh network. **Configure and Validate Additional Devices (e.g. Device 3)** Additional devices (e.g. Device 3) are configured and validated using the same steps as for Device 2. Repeat the “Device 2” process for Device 3 to add another Extender to the mesh. Test the self-healing behaviour of the mesh by moving Device 2 out of range of Device 1, and/or by adjusting the “RSSI threshold for joining” mesh setting (see Troubleshooting section for more information). Note: If testing on your desk, we recommend a cabled test setup with the appropriate attenuation and RF splitter/hubs for the thresholds you set. *** #### #### 3.1.3 Detailed explanation for Wizard and Push Button configuration The following annotates the prior diagram with more details from the example configured, including the 802.11 mesh terminology (as per [Certified Wireless Network Professional 802.11s Mesh guide](https://www.google.com/url?q=https://www.cwnp.com/uploads/802-11s_mesh_networking_v1-0.pdf\&sa=D\&source=editors\&ust=1783414770574837\&usg=AOvVaw2c7Qa2fHFpBThM1NtcFyZ9)): ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/vcgHM9CFzAmudbRWyutK/Unknown%20image)) The points to note are: * Both Device 1 and Device 2 participate in the 802.11s Mesh as Mesh Stations. The Mesh ID and settings come from the Device 1 configuration, and are distributed to Device 2 via DPP (push button). * Device 1 is configured to have a static address 192.168.12.1 and to operate a DHCP server on the lan network (i.e. the mesh; its 802.11bgn 2.4 GHz Access Point; and LAN and USB LAN ports). This is identical to the out-of-the-box configuration for a HaLowLink1. * Device 2 is configured to obtain its address via DHCP. It also has all physical ports (LAN, USB LAN, and WAN), and its 802.11bgn 2.4 GHz Access Point into its lan network. * I.e. connecting to any physical port or the Access Point in Device 2 will provide access to the internet via the mesh->Device1->phone hotspot->phone internet connection. This is a detailed diagram of the two devices, and the resulting configuration from an OpenWRT perspective:![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/kZ5kjx6QbD0o7DylLiu5/Unknown%20image)) ### 3.2 Advanced Approach - Configuring via UI without Wizard #### 3.2.1 Overview The HaLowLink1 supports 802.11s and can be configured without relying on the wizard and push button pairing. This process is more complex. There are many inter-related settings which must be correct - setting incorrect configuration parameters may result in temporary loss of device connectivity or administrative access.. NOTE: We expect this process to be followed by users familiar with configuring 802.11s mesh networks and/or users that are experimenting with 802.11s. It is expected that occasional connectivity issues may occur as part of the learning process. A common cause is being unable to determine the IP address of a device because it changes from using a static IP address to a DHCP provided IP address. See Troubleshooting for more guidance. Common objections to the Wizard and Push Button configuration are: 1. It does not have the SSIDs I want in all of the devices. 2. It does not have an 802.11ah HaLow Access Point as well as an 802.11bgn 2.4 GHz Access Point in all of the devices. 3. I do not know how to incorporate this with other 802.11ah HaLow products that support 802.11s meshing. We will address points 1 and 2 in this section. Point 3 is out of scope for this document, but will be similar to the configuration performed in this guide. Note: This section will perform the full configuration from scratch via the UI - but the approach is similar to adjust the configuration from the previous Wizard and Push Button section to address the objections. *** #### 3.2.2 Requirements for the example via UI The Wizards and Push Button example ignored some of the requirements from the original plan for ease of use. This example will use requirements from an expected IoT deployment where: * REQ1 - There are existing 2.4 GHz only Wi-Fi IoT devices that are configured as clients with SSID: “ot-network” and Password: “ot-network-password”. * REQ2 - These 2.4 GHz only devices are geographically dispersed, and we want to use an 802.11ah HaLow mesh to provide coverage to them, so our 2.4 GHz Access Points must use this SSID. * REQ3 - There are also 802.11ah Wi-Fi IoT devices configured as clients with the same ‘ot-network’ configuration, and we also want the mesh to provide coverage to them. * REQ4 - At the uplink we do not want the uplinking mesh device to also run any 802.11bgn 2.4GHz Access Points, as these will add unnecessary interference, but we do want to run an 802.11ah Access Point at the uplink mesh device. The conceptual architecture for this example is below. Note it includes “IoT Devices” which we will not cover in this guide:![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/GogbugBzK5dRcBvSZUqo/Unknown%20image)) And this is a detailed diagram of the network, including the two HaLowlink devices we will configure :![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/Jlo9Ck956QZ82n1n7y6W/Unknown%20image)) #### 3.2.3 Step-by-step guide for configuring entirely via UI The following is a step by step guide to configure and validate a mesh network. The two devices used as examples are HaLowLink1s running v2.7.3 with the following: * Device 1 - SSID: halowlink1-af0f * Device 2 - SSID: halowlink1-ae6b To provide an uplink for this guide, determine the SSID and password of your 2.4GHz uplink (this guide uses a phone hotspot configured with SSID: uplink and PW: uplink-password). **Configure Device 1 to have 2.4 GHz uplink to internet** 1. Connect your laptop to Device 1 via its 802.11bgn 2.4 GHz\ (e.g. Wi-Fi SSID halowlink1-af0f) 2. Access the web UI at [http://192.168.12.1](https://www.google.com/url?q=http://192.168.12.1\&sa=D\&source=editors\&ust=1783414770581942\&usg=AOvVaw3jhUBa-7mntWNpoByOI_Fs), login using the “Device Password” 3. Select Quick Config page (you may have to toggle “Advanced Config”)\ ([http://192.168.12.1/cgi-bin/luci/admin/config](https://www.google.com/url?q=http://192.168.12.1/cgi-bin/luci/admin/config\&sa=D\&source=editors\&ust=1783414770582237\&usg=AOvVaw2DUNpEPZcsw3nZoT4Yrsfb)) 4. Add a new wireless device to the 802.11b/g/n radio\ ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/i2tSpvM4N9oPsujYOe70/Unknown%20image)) 5. Input the following details: 6. Ensure ‘enabled’ is selected 7. Network: wan 8. Mode: client 9. ESSID: uplink 10. Encryption: Match the security protocol exactly to that configured on the uplink hotspot (commonly WPA2-PSK). 11. Key/Security: uplink-password 12. Remove the wan Ethernet device from the wan network by deselecting ‘wan’ in the Ethernet dropdown.\ ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/XU36spbX164xYM9gLx36/Unknown%20image)) 13. Click Save & Apply Validate Device 1 has an internet 2.4 GHz uplink 1. Ensure your hotspot is enabled. 2. Connect to Device 1’s 2.4 GHz Access Point (i.e. halowlink1-af0f) with your laptop. 3. Check you can reach the internet (i.e. load [www.morsemicro.com](https://www.google.com/url?q=http://www.morsemicro.com\&sa=D\&source=editors\&ust=1783414770583606\&usg=AOvVaw3pGn2Vh7QaKkOyDQBlJzWD) in your browser). **Troubleshooting** * If you cannot see your device’s 802.11bgn 2.4 GHz Access Point, it may be that your hotspot is unavailable or the device has incorrect parameters. * The HaLowLink1 only brings up its 802.11bgn 2.4 GHz Access Point after its 802.11bgn 2.4 GHz client successfully connects to the ‘uplink’ SSID. **Configure Device 1 to have 802.11ah Access Point with “ot-network” SSID** 4. Select Quick Config page\ ([http://192.168.12.1/cgi-bin/luci/admin/config](https://www.google.com/url?q=http://192.168.12.1/cgi-bin/luci/admin/config\&sa=D\&source=editors\&ust=1783414770584502\&usg=AOvVaw2lEPhPTmia0BHJ4eCR7zRm)) 5. Change the settings for the existing Access Point for the 802.11ah radio 6. ESSID: ot-network 7. Key/Security: ot-network-password ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/wBJynIUQJK1njyiGoj1T/Unknown%20image)) 6. Click “Save & Apply” (note you might lose connection and need to reconnect) **Configure Device 1 to have 802.11ah Mesh Point with “ot-mesh” SSID** 7. Select Quick Config page\ ([http://192.168.12.1/cgi-bin/luci/admin/config](https://www.google.com/url?q=http://192.168.12.1/cgi-bin/luci/admin/config\&sa=D\&source=editors\&ust=1783414770585308\&usg=AOvVaw1bKy-zsYnbuK9J0BW2pPFl)) 8. Add a new wireless device to the 802.11ah radio\ ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/IQQodvIrodwe1trIC9EY/Unknown%20image)) 9. Input the following details: 10. Enabled: true 11. Network: lan 12. Mode: Mesh Point (Note: this is called 802.11s mesh in Network > Wireless config page) 13. MeshId: ot-mesh 14. Encryption: WPA3-SAE 15. Key/Security: ot-mesh-password ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/RbQK2AmBulymIa8KG5Mg/Unknown%20image)) 10. Click “Save & Apply” (note you might lose connection and need to reconnect) *** **Validate Device 1 802.11ah configurations** We cannot validate the 802.11ah mesh is working yet, but we can validate by inspecting the expected configuration on the Network > Wireless page\ ([http://192.168.12.1/cgi-bin/luci/admin/network/wireless](https://www.google.com/url?q=http://192.168.12.1/cgi-bin/luci/admin/network/wireless\&sa=D\&source=editors\&ust=1783414770586755\&usg=AOvVaw2kRi1tiJLJ1yGW1scESSa7)). ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/IBmV4OesvhkqDNkzLopL/Unknown%20image)) Note that we have not met REQ4 yet, and are keeping the 802.11bgn 2.4 GHz Access Point configured now to maintain access to Device 1. *** **Configure Device 2 to have ‘ot-network’ for Access Point on both 802.11bgn and 802.11ah radio** 11. Connect your laptop to Device 2 via its 802.11bgn 2.4 GHz (e.g. Wi-Fi SSID halowlink1-ae6b) 12. Access the web UI at [http://192.168.12.1](https://www.google.com/url?q=http://192.168.12.1\&sa=D\&source=editors\&ust=1783414770587567\&usg=AOvVaw3_SjcgmNU9bFcXN6c8NWU_), login using the “Device Password”. 13. Select Quick Config page (you may have to toggle “Advanced Config”)\ ([http://192.168.12.1/cgi-bin/luci/admin/config](https://www.google.com/url?q=http://192.168.12.1/cgi-bin/luci/admin/config\&sa=D\&source=editors\&ust=1783414770587958\&usg=AOvVaw2ibMdoUTDoRhptvonvbZHq)) 14. Change the settings for the existing Access Points for both the 802.11ah and 802.11bgn radios 15. ESSID: ot-network 16. Key/Security: ot-network-password ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/7Bk9Tz0YsoK6dlNKBzI5/Unknown%20image)) 15. Click “Save & Apply”. You will lose connection to Device 2, as its SSID will change from the device default to “ot-network”. Reconnect to Device 2 using “ot-network / ot-network-password”. *** **Configure Device 2 to have 802.11ah Mesh Point with “ot-mesh” SSID** 1. Select Quick Config page\ ([http://192.168.12.1/cgi-bin/luci/admin/config](https://www.google.com/url?q=http://192.168.12.1/cgi-bin/luci/admin/config\&sa=D\&source=editors\&ust=1783414770589051\&usg=AOvVaw2C6xIHlyK_Q0D6tedhJ8N5)) 2. Change the lan network to have: 3. DHCP Server: Disabled 4. Protocol: DHCP Client ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/n8dgvNFOwN12jdVaYjzW/Unknown%20image)) 3. Add a new wireless device to the 802.11ah radio\ ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/IQQodvIrodwe1trIC9EY/Unknown%20image)) 4. Input the following details: 5. Enabled: true 6. Network: lan 7. Mode: Mesh Point (Note: this is called 802.11s mesh in Network > Wireless config page) 8. MeshId: ot-mesh 9. Encryption: WPA3-SAE 10. Key/Security: ot-mesh-password ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/RbQK2AmBulymIa8KG5Mg/Unknown%20image)) 5. Click “Save & Apply” (note you might lose connection and need to reconnect). 6. You will be warned about a connectivity change. Choose “Apply and keep settings”.\ ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/cSjOVrAKifjKV4r96AQt/Unknown%20image)) Note: We will likely lose connectivity for longer than 90 seconds, as Device 2 will get a new IP from Device 1’s DHCP server, but it will take time for us to determine it and get back into the UI. **Validate Device 2 configurations and the mesh network** We have now configured the mesh with two devices, where your laptop has connectivity to the internet. Before we validate, you must check: * The “uplink” hotspot is up and has an active internet connection * Device 1 is powered on (and has all three status lights on - Status & Wi-Fi 2.4 GHz green; Wi-Fi HaLow purple) * Device 2 is powered on (and has all three status lights on - Status & Wi-Fi 2.4 GHz green; Wi-Fi HaLow purple) * Your laptop is connected to the “ot-network” SSID (i.e. the one provided by Device 2) Check connectivity to Device 1 Go to [http://192.168.12.1](https://www.google.com/url?q=http://192.168.12.1\&sa=D\&source=editors\&ust=1783414770591776\&usg=AOvVaw3JqFVrMBapZt_OaiPdLatE) and login with Device 1’s credentials. * Your laptop is connecting to Device 1 through the following path: laptop -> “ot-network” 2.4 AP -> Device 2 -> “ot-mesh” link -> Device 1 If you cannot connect to Device 1, please refer to the troubleshooting section Check connectivity to the Internet Go to [www.morsemicro.com](https://www.google.com/url?q=http://www.morsemicro.com\&sa=D\&source=editors\&ust=1783414770592394\&usg=AOvVaw0vSfGhVvrxK_3kGCTELN6r) in your browser. * Your laptop is connecting to the internet through the same path as to Device 1 Examine traceroute from laptop to see hop via Device 1 Running traceroute 8.8.8.8 (i.e. a Google DNS server) you can see that the first hop is via the 192.168.12.1 link. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/kwqd46cjLEVCTp097Cpo/Unknown%20image)) Inspect DHCP leases in Device 1 to determine Device 2’s address Login to Device 1’s UI, and go to Home\ ([http://192.168.12.1/cgi-bin/luci/admin/home](https://www.google.com/url?q=http://192.168.12.1/cgi-bin/luci/admin/home\&sa=D\&source=editors\&ust=1783414770593643\&usg=AOvVaw02RHgtKakoSG93pHVtD1IP)). Click on “DHCP Leases”, and look for the MAC address of Device 2. For example, here is the table for the two devices used throughout this guide:\ ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/tkqqaaaz1EANha4gIH1M/Unknown%20image)) Use the IP address found here to get to the UI of Device 2. **Configure and validate Device 3** To configure another device, follow the same steps as for Device 2. Any device configured this way will join the mesh network and behave just like Device 2. *** ## 4 Troubleshooting I’m connected to my device, but I don’t know its IP address. How do I find it? There are a few techniques: Method A: Using DHCP Server Leases 1. Log into the device that is running the DHCP server and go to the Home page\ ([http://192.168.12.1/cgi-bin/luci/admin/home](https://www.google.com/url?q=http://192.168.12.1/cgi-bin/luci/admin/home\&sa=D\&source=editors\&ust=1783414770595817\&usg=AOvVaw0JhFHyGRUoBbf8p1vFSG_h)). 2. Click on “DHCP Leases”, and look for the MAC address of the device you want to find. Method B: Accessing via Debug IP (10.22.121.111) 1. HalowLink1 devices bind a static IP address 10.22.121.111/31 for retaining debug access. 2. Add a static IP address to your laptop’s network connection: 10.22.121.110/31 (i.e. with netmask 255.255.255.254) 3. Connect to the debug IP address 10.22.121.111, ensuring your laptop is only connected to one device. I am unable to separate the HaLowLink1 devices sufficiently to test mesh self-healing. What can I do? This is expected, as HaLow’s strength is the extended range! You can see the performance of the mesh in two ways: 1. Move Device 1 and 2 far enough apart that they cannot communicate, so you know they are communicating via Device 3. 2. Move Device 1 and 2 far enough apart so their throughput is low, and see that introducing Device 3 improves the throughput. To achieve “move the devices further apart”, there are a few options: * Physically separating the devices - though this is very impractical for a demo; * Separating the devices in RF isolation chambers with controllable attenuation; * Configuring the “RSSI threshold for joining” mesh advanced option - which will prevent stations for joining a mesh if they are below the threshold; and * Configuring the “mesh\_max\_peer\_links” mesh setting - which will restrict the number of peers a node has. Providing physical or RF separation is out of the scope of this document. *** To adjust the Mesh RSSI threshold for joining: * Go to Network > Wireless settings\ ([http://192.168.12.1/cgi-bin/luci/admin/network/wireless](https://www.google.com/url?q=http://192.168.12.1/cgi-bin/luci/admin/network/wireless\&sa=D\&source=editors\&ust=1783414770600008\&usg=AOvVaw1r0egSJ3LtwyZH1PbSP1k6)) * Click “Edit” on the “ot-mesh” device * Update the RSSI threshold for joining under “Mesh Settings”\ ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/FooprgxLvN1eW3nOMcWj/Unknown%20image)) This threshold determines the minimum RSSI a node must see to establish a peer connection in the mesh. A value of 0 means “peer with any device”. A value of -75 means “peer only with devices that have RSSI greater than -75”. To adjust the mesh\_max\_peer\_links setting: * Log into the device via ssh (e.g. ssh root\@192.168.12.1) * Use an editor to update the file /etc/config/mesh11sd. * Update the mesh\_max\_peer\_links to the value you desire. * Save the file and restart the wireless (e.g. wifi down && wifi up) This setting will limit the number of peer links a node establishes. For example, set this to 2 for a number of devices and they will form a chain. *** ## 5 Frequently Asked Questions (FAQ) Why does this application note use 2.4GHz for the uplink to the internet?\ Multiple methods exist to configure the network topology under examination. This application note utilizes a smartphone-provided hotspot as it is universally accessible and simplifies network testing. We believe this choice is the simplest for any user to test - even in an office environment - as it does not require plugging Ethernet cables into existing infrastructure. Can I use the WAN or LAN Ethernet for uplink to the internet?\ Yes you can. * To use the WAN port - you would connect the WAN port to your uplink gateway (on its ‘lan’ side). You should also ensure the uplink 2.4 GHz client is not connected. * To use the LAN port - this is more complex, as the ‘lan’ side of your uplink gateway is probably running a DHCP server already (to hand out DHCP leases in your network). You should: * Change Device 1’s lan interface to be a DHCP client. * Plug the LAN port into the lan side of your uplink gateway. * Use the DHCP lease table from your uplink gateway to determine the IP addresses given to Device 1 and Device 2. Can I connect to the mesh via the LAN port on the HaLowLink (Device 2 / Device 3) instead of via the 2.4 GHz Wi-Fi network?\ Yes, if your device has an available Ethernet port this is possible. For example EKH01 platforms do not have an additional 2.4 GHz radio, so using the Ethernet port is required. When you connect via a LAN port on Device 2 or 3 your laptop will receive an IP address from the DHCP server on the network (i.e. likely from Device 1). What will the throughput and latency be like?\ As with all wireless links, the throughput and latency will depend on the quality of the radio link (i.e. noise, distance etc). For 802.11s mesh links another factor is the number of hops needed to route frames. For the 802.11ah throughput performance, please refer to the expected data rate \[[link](https://www.google.com/url?q=https://en.wikipedia.org/wiki/IEEE_802.11ah%23Data_rates\&sa=D\&source=editors\&ust=1783414770606733\&usg=AOvVaw2phTezi-Hs85w6PJHilyP9)] and your device capability. *** ## 6 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | --------------- | | 1.0 | 2025-04-02 | Initial release | # APPNOTE-33 2.4GHz Range Extension Using HaLow v1 [Download as PDF](https://www.morsemicro.com/resources/appnotes/MM_APPNOTE-33_2.4GHz_Range_Extension_Using_HaLow.pdf) ## 1 Scope This guide provides a step-by-step process for setting up an internet connection for HaLow devices, specifically the EKH Evaluation Kits and HaLowLink1, covering various uplink options and configuration scenarios. It covers configurations for various internet sources, including: * Starlink: Connecting via Ethernet or Wi-Fi from the Starlink router. * LTE Dongle: Setting up USB or Ethernet-based LTE modems. Hardware & Software Requirements 1. 1 x EKH (Evaluation Kit) or HaLowLink1 running Openwrt version (2.7.0) or above. 2. HaLow Client Devices (e.g., cameras, IoT devices, or another HaLow station such as EKH or HaLowLink1) 3. Internet Source: (Any one of the following) 4. Starlink (Ethernet Adapter + Router or Wi-Fi connection) 5. LTE Dongle (USB or Ethernet-based modem) 6. Laptop (For configuring the HaLow device) 7. Router (For bridging or additional network management, if needed) 8. Power Supply (Sufficient power for all connected devices) ## 2. Theory of Operation ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/pyOghGlz7G6ehULpoxOT/Unknown%20image)) This guide explains how to configure the Uplink connection on a HaLow Access Point device to create a setup like the one shown in the image below. In this setup, Device1 is configured as an HaLow Access Point, providing network access to: * Device2, which acts as a HaLow client connected over the HaLow interface. * A laptop, which connects to Device1’s 2.4GHz Wi-Fi AP. The HaLow Access Point uses a WAN uplink (Starlink, orLTE dongle) to provide internet access to both clients. In a HaLow network, the HaLow Access Point (EKH Evaluation Kit or HaLowLink1) can be configured in two primary modes to handle internet connectivity: Router Mode * The HaLow Access Point acts as a router, using an external internet source (Starlink/ LTE dongle) as its WAN uplink. * It creates a separate internal network (e.g: with IP address 192.168.12.x), where connected HaLow clients are assigned local IP addresses. * NAT (Network Address Translation) is applied, meaning all client traffic is routed through the HaLow device before reaching the WAN. * This mode isolates local devices from the WAN while providing controlled access to the internet. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/5Ore9Vk2E3qGcjwVoF3g/Unknown%20image)) Bridge Mode * The HaLow Access Point acts as a transparent bridge, extending the WAN network to all connected HaLow clients. * Clients are assigned IP addresses directly from the WAN uplink (e.g., the Starlink modem or LTE network). * There is no NAT, and clients can communicate directly with the external network. * This mode is useful when HaLow devices need to be part of an existing network rather than managing their own. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/f1Bs80SObBarRq3Dwsvj/Unknown%20image)) ## 3 How to Configure The configuration process is divided into the following steps: 1. Setting Up the WAN Uplink 2. Starlink Uplink – Connect the HaLow Access Point to the Starlink Modem/Dish. 3. LTE USB Dongle – Configure the HaLow Access Point to utilize an LTE modem. 4. Configuring the HaLow Network 5. Routed to WAN (Router Mode) – HaLow Access Point performs Network Address Translation (NAT) between the WAN uplink and connected clients. 6. Bridged to WAN (Bridge Mode) – HaLow Access Point directly forwards traffic to the WAN, placing all clients on the same network. Each section will provide guidance on configuring HaLow Access Point based on the chosen uplink type and network mode. The setup will use the Device1 (HaLow Access Point) in different network modes while maintaining the following configuration: * Device1 (HaLowLink1 or Eval Kit) functions as the Access Point. * Device2 operates as a HaLow client. * A laptop is connected via Device1's 2.4GHz Wi-Fi AP. * An uplink device (Starlink, or LTE USB dongle) provides internet access. ### 3.1 Setting Up the WAN Uplink The goal of this step is to configure the HaLow Access point to establish an internet connection using one of the available uplink options. By the end of this step, the AP should be able to access the internet, ensuring that it can reach [www.morsemicro.com](https://www.google.com/url?q=http://www.morsemicro.com\&sa=D\&source=editors\&ust=1783415033415985\&usg=AOvVaw0MppCZHOzbryk265hs_CbR). #### 3.1.1 Setup Starlink Uplink The Starlink Standard Kit includes a Starlink Dish Antenna and a Router. There are two ways to connect your HaLow Access Point to Starlink: **3.1.1.1 Connecting to the Starlink Router (Default Setup)** This section provides guidelines to connect a HaLow Access Point - either the HaLowLink1 or the Eval Kit (EKH03) - to the Starlink Router’s Wi-Fi network. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/b9GEd4OjoLefjS2igr9m/Unknown%20image)) 1. Set up the Starlink Router according to the[official guidelines](https://www.google.com/url?q=https://www.starlink.com/au/support/article/412a70ca-0d9a-813e-b18f-75c36b84ec06\&sa=D\&source=editors\&ust=1783415033416763\&usg=AOvVaw2vORf5-ATXjKU6SOCZs_Rc). 2. Ensure the router is broadcasting the correct SSID (e.g. starlink-AP). Steps to connect HaLowLink1 3. Connect HaLow Access Point in this case which is a HaLowLink1 as a client of the Starlink Wi-Fi network. 4. Ensure the HaLow Access Point is in the right mode with its status LED showing green. Refer to the user guide to set up that mode. 5. Connect your laptop to the HaLow Access Point via its 2.4 GHz Wi-Fi SSID which is found on the label of the device. (e.g. Wi-Fi SSID: HaLowLink1-af0f) 6. Access the web UI at [http://192.168.12.1](https://www.google.com/url?q=http://192.168.12.1\&sa=D\&source=editors\&ust=1783415033417480\&usg=AOvVaw20XUOassuVqUQgjEgiuNCu), login using the “Device Password” and select the “Wizard” from the menu (direct [link](https://www.google.com/url?q=http://192.168.12.1/cgi-bin/luci/admin/morseapwizard\&sa=D\&source=editors\&ust=1783415033417631\&usg=AOvVaw19oyBxIt7PTAnRDli5eZRH)). 7. Select the Network mode to use the 2.4GHz Wi-Fi uplink as shown in the image below. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/qo1entDsDXVd1Blv4xT7/Unknown%20image)) Note: If you select this option, the router mode is set as the default, as detailed insection 3.2.1. 5. Go to Home ([http://192.168.12.1/cgi-bin/luci/admin/home](https://www.google.com/url?q=http://192.168.12.1/cgi-bin/luci/admin/home\&sa=D\&source=editors\&ust=1783415033418131\&usg=AOvVaw2QSr4GBDVY21UlqYkUnfl9)) 6. Find the Uplink card, which should say “Disconnected” 7. Click the word “Disconnected” and provide the uplink network details (e.g. SSID: Starlink-WiFi, password: starlink-password) 8. Once connected proceed to section 3.1.1.3 to verify the device’s internet connectivity. Steps to connect EKH03 4. Connect the HaLow Access Point in this case which is an EKH03 as a client of the Starlink Wi-Fi network. 5. Ensure the EKH03 is configured as a HaLow Access Point. Refer to the user guide to set up that mode. 6. Connect your laptop to the HaLow Access Point via the LAN port using an ethernet cable. 7. Access the web UI at [http://10.42.0.1](https://www.google.com/url?q=http://10.42.0.1\&sa=D\&source=editors\&ust=1783415033419116\&usg=AOvVaw2bcTQLyl3GXn036Zpq76H1), and select the “Setup AP/ STA Wizard” from the Wizard menu. 8. On the Access Point wizard, configure the HaLow network as per the user guide, and on the Upstream Network page choose the 2.4GHz Wi-Fi uplink as shown in the image below. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/slzu5Fd28fSRgoC7WtE6/Unknown%20image)) 5. The traffic mode is set to router mode as the default, as detailed insection 3.2.1. 6. Apply the configuration on the final page. 7. Once connected proceed to section 3.1.1.3 to verify the device’s internet Starlink Mini Kit (Wi-Fi Only) If you are using the Starlink Mini Kit, which has integrated Wi-Fi but no separate router, connect the HaLow Access Point directly to the Starlink Wi-Fi network as mentioned above in section 3.1.1.1. **3.1.1.2 Using HaLow Device as a Third-Party Router** The following section describes adding the HaLow Access Point as a third-party router to the Starlink router. Note: In this configuration, bridge mode cannot be enabled on the HaLow Access Point. The steps to configure are as follows, 1. Enable [Bypass Mode](https://www.google.com/url?q=https://www.starlink.com/au/support/article/a0fe8d51-32f7-d2b9-d74a-801e31ad9f6a\&sa=D\&source=editors\&ust=1783415033420595\&usg=AOvVaw2v699dL_vkVnrDC-X3JMun) on the Starlink router. 2. Connect HaLow AccessPoint as the third-party router, via plugging the ethernet cable to the WAN port of the device. 3. Creating a Static Route on the HaLow Access Point is a requirement for using the Starlink app. The following steps will demonstrate how to do this. 4. Navigate to Advanced Config > Network > Routing page ([http://192.168.12.1/cgi-bin/luci/admin/network/routes](https://www.google.com/url?q=http://192.168.12.1/cgi-bin/luci/admin/network/routes\&sa=D\&source=editors\&ust=1783415033421184\&usg=AOvVaw224dyp8mDq8LRw1gT2oRRc)) 5. Click on Static IPv4 Routes and click Add, then add the static route as suggested in the Starlink guide and hit “Save & Apply”. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/JRHzK6gXXMNjhfAP4BJ1/Unknown%20image)) ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/EymJvHVG0LzcgJarkhDE/Unknown%20image)) **3.1.1.3 Verifying HaLow Access Point's internet Connectivity** To confirm that the HaLow Access Point can now connect to the internet through the 2.4 GHz uplink network, follow these steps: 1. Connect your laptop to HaLow Access Point's 2.4 GHz Wi-Fi (e.g. SSID: HaLowLink1-af0f). 2. Check your internet connection by loading a webpage like[www.morsemicro.com](https://www.google.com/url?q=http://www.morsemicro.com\&sa=D\&source=editors\&ust=1783415033421930\&usg=AOvVaw1qxnUThu51zOwIq0F285vy). Ensure your laptop is not connected to a different network. #### 3.1.2 Setup LTE Dongle Uplink This section describes how to configure a LTE USB Dongle for internet Access on Your HaLow Access Point. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/PjPMQbWPQy3wkeJSPpVz/Unknown%20image)) Note: USB LTE Dongles are not supported by the HaLowlink 1 due to the absence of a USB port. However, Evaluation Kits (EKH01, EKH03, or EKH-19) can be used to support this configuration. Most LTE USB dongles on the market support NAT, and very few provide a public IP directly from the LTE provider. Neither scenario will impact how WAN is configured for the HaLow AP, unless the WAN interface is assigned an IP address. Configuration Steps The following configuration steps outline the process using the EKH01 as the HaLow Access Point (Device 1). 1. Connect your laptop to the HaLow Access Point via the Ethernet cable. 2. In a default state, you must be able to reach the device via [http://10.42.0.1/](https://www.google.com/url?q=http://10.42.0.1/\&sa=D\&source=editors\&ust=1783415033423428\&usg=AOvVaw143Gc2xqboBB1KZe7Ad1wU) . 3. Plug-in the LTE USB dongle to the HaLow AP and ensure that the dongle initializes properly with any LED indications as directed by the provider. For example, the “dmesg” logs indicate that a Huawei LTE USB dongle was connected to the EKH01. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/GShUu5AIOihV3r3nnLAv/Unknown%20image)) From the WebUI, go to Services > Terminal, Login to the device and enter “dmesg” on the terminal to view the logs as shown above. Note: This indication may vary depending on the LTE dongle provider. 4. On the HaLow AP navigate to the [Wizards page](https://www.google.com/url?q=http://10.42.0.1/cgi-bin/luci/admin/ekhwizards\&sa=D\&source=editors\&ust=1783415033424131\&usg=AOvVaw0Yod91YKDILa4XkCf78VCT) and select the standard HaLow AP/STA wizard. 5. Select Access Point and proceed to configure the right Wi-Fi credentials and appropriate channel information. 6. On the Upstream Network page select the USB dongle, if you do not see the option it is ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/nACJ5J3QlEf56nkkzUzZ/Unknown%20image))likely that the dongle was not initialized properly. Troubleshoot the dongle and try again. 7. Select the traffic mode as per the requisite, for more information on configuring the traffic mode refer to Section 3.2. 8. Apply the configuration and proceed to verify the internet connectivity.. Verifying HaLow Access Point's internet Connectivity To confirm that the HaLow AP can now connect to the internet through the LTE uplink network, follow these steps: On the Home page, the uplink card shows Connected as shown below: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/Pf6SiDLvO1moR93bIYBp/Unknown%20image))Check your internet connection on your laptop by loading a webpage like[www.morsemicro.com](https://www.google.com/url?q=http://www.morsemicro.com\&sa=D\&source=editors\&ust=1783415033425459\&usg=AOvVaw2C1LPNgyVNGL6Ie-Fqk6tw). Ensure your laptop is not connected to a different network via Wi-Fi. ### 3.2 Configuring the HaLow Network The traffic mode of the HaLow network can be configured in two ways as aforementioned. This section explains the configuration details of each mode and what happens to the network flow in each mode. The configuration wizards for HaLowLink1 and Evaluation Kits enable users to configure both router and bridge traffic modes. However, the available options may differ between different uplink choices. This section will explain how to configure both modes in HaLowLink1 and Evaluation Kits, using both the configuration wizard. #### 3.2.1 Routed to WAN (Router Mode) **3.2.1.1 Configuring HaLowLink1 in router mode** ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/C9vAmUvMmJxqzLCWMaQC/Unknown%20image)) When configuring a HaLowLink1 device from the wizard page, selecting the options (either option 2 or 3) will make the HaLow client devices to obtain IP address on the device’s local network and configures the HaLow Access Point to function as a router. The resulting network configuration on the device will be as depicted in the following diagram. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/7F88Wt8UdNlxPmSsRdY5/Unknown%20image)) **Figure 3.2.1** Network Flow * The HaLow Access Point (HaLowLink1) can establish an internet connection in two ways: * Using option 3, through the WAN interface (phy0-sta0), when connected to the Starlink modem (as per section 3.1.1.1). * Using option 2, through the WAN ethernet interface, when the HaLowLink1 is used as a third-party router (as per section 3.1.1.2). * Clients such as the Mobile, the HaLow client and the Laptop connect to the HaLowLink1 using the interfaces 2.4GHz Wi-Fi, HaLow and ethernet respectively. * HaLowLink1 NATs traffic between the WAN uplink and the connected clients, enabling them to access the internet while remaining on a separate internal network. * This setup ensures that all connected devices can communicate through HaLowLink1, which manages the routing and NAT functionality between the WAN and the local network. **3.2.1.2 Configuring Evaluation Kits in router mode** On the evaluation kit’s wizard page, configure the kit to be an Access Point as per the user guide and while configuring the Upstream Network, set the Traffic Mode to Router or Router with firewall. Selecting this mode segregates the HaLow network from the upstream network, enabling traffic routing between HaLow clients and the upstream router. For EKH03 or evaluation kits equipped with a 2.4GHz Wi-Fi radio, the HaLow network, Ethernet interface, and the 2.4GHz Wi-Fi Access Point are grouped under the LAN interface. The WAN uplink, configured as a 2.4GHz Station, is assigned to the WAN interface. This configuration aligns with the reference setup illustrated in Figure 3.2.1. For evaluation kits without a 2.4GHz Wi-Fi radio, such as the EKH01, connecting an Ethernet cable to the WAN uplink and setting up the router mode results in the HaLow network being included in the LAN interface, while the Ethernet interface is assigned to the WAN network. When using an LTE USB dongle as the uplink, the HaLow network, Ethernet interface, and the 2.4GHz Wi-Fi Access Point (if present) are incorporated into the LAN interface. The WAN uplink, identified as an Ethernet interface enumerated by the USB port, is added to the WAN network. This configuration ensures proper interface grouping and traffic routing based on the evaluation kit's hardware and chosen uplink method. #### 3.2.2 Bridged to WAN (Bridge Mode) The goal of bridge mode is to enable devices on both the HaLow and 2.4GHz networks to obtain IP addresses from the uplink connection (either Starlink Modem or LTE dongle). The LAN ethernet port can function as a management port or be configured to bridge to the uplink network. Note: This mode is not supported when operating the Starlink Modem in bypass mode. **3.2.2.1 Configure HaLowLink1 in bridge mode** Ensure that the HaLow Access Point (HaLowLink1) establishes an internet connection through the WAN ethernet interface, by connecting to an uplink internet modem. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/5sV5um6D7xuUYkDP66f8/Unknown%20image)) **Figure 3.2.2** On the wizard page, select Option 1, to obtain IP on the existing router’s (uplink router) network. The resulting configuration is as depicted above in Figure 3.2.2. Network Flow * The WAN (bridged) network includes the WAN Ethernet interface and HaLow interface passing traffic transparently. * In bridge mode, the LAN network which includes the Ethernet interface and the 2.4GHz Wi-Fi AP has a static IP 192.168.12.1 with a DHCP server for management. * The HaLow interfaces function under the upstream network. **3.2.2.2 Configure Evaluation Kits in bridge mode** To configure the HaLow Access Point as a bridge, allowing traffic to flow between the HaLow client and other end clients (including the 2.4GHz Wi-Fi AP, if present), select 'bridge' as the traffic mode in the wizard on Evaluation Kits. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/vyrPcmrGpOl6wYseObTb/Unknown%20image)) The resulting configuration is as follows. Network Flow * The WAN (bridged) network includes the WAN Ethernet interface and HaLow interface passing traffic transparently. * In bridge mode, the Ethernet interface and the 2.4GHz Wi-Fi AP are bridges together with the HaLow interfaces and obtain IP addresses from the upstream network and pass traffic transparently. ## 4 Frequently Asked Questions (FAQ) 1 Why is the 2.4GHz Wi-Fi uplink not supported in Bridge mode? The wizard on both the Evaluation Kits and the HaLowLink1 sets the device’s traffic mode to Router by default and does not provide an option to configure Bridge mode through the wizard interface. This limitation exists because configuring bridge mode requires utmost caution due to specific restrictions that may prevent proper operation. Notably, the 2.4GHz Station (STA) interface used for the uplink connection must be set to WDS mode to enable bridging. Additionally, the uplink Access Point (AP) that the device connects to must also support and be configured for WDS. Failing to meet these conditions will prevent the bridge configuration from functioning as intended. 2 Configure Ethernet interface to be bridged with the WAN When the traffic mode is set to Bridge, the Ethernet and 2.4GHz Wi-Fi interfaces are not automatically bridged with the WAN network and, in most cases, remain on a separate network. However, if you choose to bridge the Ethernet interface to the WAN uplink, this can be done manually from the Quick Config page of the device. In the Network Interfaces section, remove the lan and usblan interfaces from the Ethernet section of the lan network and add them to the wan network as shown in the example provided. Note: Making this change may result in the loss of connection to your device if you are connected through the lan or usblan interfaces of the HaLow Access Point. To regain access, you can either connect via the 2.4GHz Wi-Fi or identify the IP address assigned to the lan interface by the upstream uplink device and connect directly. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/YKOZE2zf8821nfFd5Bft/Unknown%20image)) ## 5 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | --------------- | | 01 | 2025-03-20 | Initial release | # APPNOTE-34 Measuring Low Power Wi-Fi HaLow v1 [Download as PDF](https://www.morsemicro.com/resources/appnotes/MM_APPNOTE-34_Measuring_Low_Power_Wi-Fi_HaLow.pdf) ## 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\]](#cmnt1). 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\]](#cmnt2)[\[c\]](#cmnt3)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.

Figure 1. Diagram of AP transmitting beacons and DTIM beacons.

*** ### 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.

Figure 2. Calculating DTIM10 sleep time.

While in DTIM sleep, the STA will not wake up to receive the regular beacons. This can be seen by extending the previous diagram.

Figure 3. Station sleeping and waking to receive DTIM beacons. DTIM10 is shown in this figure.

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.

Figure 4. Joulescope capture of DTIM10 measurement.

The image below shows the zoomed in current profile of a single DTIM wakeup, with annotations to show the different stages.

Figure 5. Stages of DTIM wakeup.

#### 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.

Figure 6. Joulescope measurement of WNM sleep enter and exit.

*** ## 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.

Figure 7. Graph showing WNM sleep becomes more efficient than DTIM10 if the device sleeps for more than 80 seconds.

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.

Figure 8. Graph showing WNM sleep becomes more efficient than DTIM40 if the device sleeps for roughly 325 seconds.

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\]](#cmnt4)[\[e\]](#cmnt5) - 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](https://www.google.com/url?q=https://www.joulescope.com/products/js220-joulescope-precision-energy-analyzer?srsltid%3DAfmBOorqNkUiEmqLhkRXtjCQuckK97MCFCGB36ksx1PeZnR1Hiz1sVVw\&sa=D\&source=editors\&ust=1783414931662087\&usg=AOvVaw2ghAWsREjPADopThN-2mBF). 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](https://www.google.com/url?q=https://au.mouser.com/ProductDetail/Morse-Micro/MM-HL1-EXT?qs%3D%25252BHhoWzUJg4Iv3HqaYbEclw%253D%253D\&sa=D\&source=editors\&ust=1783414931662972\&usg=AOvVaw1iYweZ8vcCwF39D7bJvigJ) will be used for the AP, and an [MM6108-EKH05](https://www.google.com/url?q=https://au.mouser.com/ProductDetail/Morse-Micro/MM6108-EKH05-05US?qs%3D%25252BXxaIXUDbq0w%25252BV3gu3rgyA%253D%253D\&sa=D\&source=editors\&ust=1783414931663236\&usg=AOvVaw0L8t64yEIH_Dh5Jd7NaBR-) 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](https://www.google.com/url?q=https://www.morsemicro.com/resources/user_guides/MM6108-EKH05-USER-GUIDE.pdf\&sa=D\&source=editors\&ust=1783414931663617\&usg=AOvVaw0JkmyTD8dqyOwHG7paDcnc). This application note will focus on measuring all HaLow supplies, as shown below by placing the probes across the HALOW header.

Figure 9. Hardware setup used in this application note.

Figure 10. Zoomed in view of an energy analyser measuring HaLow power consumption on MM6108-EKH05.

### 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](https://www.google.com/url?q=https://www.morsemicro.com/resources/user_guides/HaLowLink-1-User-Guide-2.7.5.pdf\&sa=D\&source=editors\&ust=1783414931665568\&usg=AOvVaw1h87Hjk-2Qir2Q1H5nz9jD) for more details.

Figure 11. OpenWRT upgrade tab.

#### 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.

Figure 12. OpenWRT tab to configure channel, bandwidth, and DTIM period.

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.

Figure 13. Setting channel, bandwidth, and DTIM period.

*** ### Station Configuration The primary objective when performing power measurements is to bring the device into a connected, idle state. The [Morse Micro IoT SDK](https://www.google.com/url?q=https://github.com/MorseMicro/mm-iot-sdk\&sa=D\&source=editors\&ust=1783414931668509\&usg=AOvVaw24wtEswmK1p973PvwgeZfl) 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](https://www.google.com/url?q=https://www.morsemicro.com/resources/user_guides/MM6108-EKH05-USER-GUIDE.pdf\&sa=D\&source=editors\&ust=1783414931670170\&usg=AOvVaw2Gu3GUMhv12flmJfuiVQmV) 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](https://www.google.com/url?q=https://www.morsemicro.com/resources/user_guides/UG-Platform-IO-MM-IoT-SDK-User-Guide.pdf\&sa=D\&source=editors\&ust=1783414931671155\&usg=AOvVaw2T4JeStl1cUXim0ldth_YY) 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: | Item | Setting | | --------------------- | ------- | | Baud Rate | 115200 | | Hardware Flow Control | None | | Data Bits | 8 | | Stop Bits | 1 | | Parity | None | 1. **Windows** The STLINK-V3MODS will show up as a Virtual COM port on windows machines.

Figure 14. Identifying COM port to use on Windows machine.

This COM port can then be opened with tools such as PuTTY. | putty -serial COM19 -sercfg 115200 | | ---------------------------------- | 2. **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 | | ---------------------------------------------------------------------------- | 3. **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\ -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”.

Figure 15. CLI application initial start up.

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

| | --------------------------------------------------------------------------------------------------------------------- |

Figure 16. CLI application inputs and outputs when setting parameters.

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.

Figure 17. CLI application connecting to AP.

Figure 18. Joulescope capture after STA has connected to the AP through the CLI application, and the STA is now in DTIM sleep.

To enter and exit WNM sleep, the following commands can be used. |

wlan-wnm\_sleep enter
wlan-wnm\_sleep exit

| | ---------------------------------------------------- |

Figure 19. CLI application showing inputs and outputs when entering and exiting WNM sleep.

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 | | ------------------------- |

Figure 21. CLI commands to place the host in a low power state.

This can be seen by measuring the host power consumption.

Figure 22. Joulescope capture on MCU rail of MM6108-EKH05 showing before and after issuing the “sys-deep\_sleep one\_shot” command.

## 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.

Figure 23. Joulescope capture of DTIM40 sleep, with two unexpected wakeup events spaced 30 seconds apart.

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.

Figure 24. Wireshark screenshot showing 30 second spaced ARP announcements.

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](https://www.google.com/url?q=https://github.com/MorseMicro/mm-iot-sdk/releases/tag/2.7.2\&sa=D\&source=editors\&ust=1783414931695473\&usg=AOvVaw2l_TXJ5BNTd4KoMbWYYyff), 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.

Figure 25. Extended block diagram with sniffer added to the setup.

For details on how to configure the HaLowLink1 to be a sniffer, please refer to [MM APPNOTE 36](https://www.google.com/url?q=https://www.morsemicro.com/resources/appnotes/MM%2520APPNOTE-36%2520-%2520How%2520to%2520do%2520a%2520Sniffer%2520Capture.pdf\&sa=D\&source=editors\&ust=1783414931697209\&usg=AOvVaw1_dGvJ3TljMXZNDw9wlpKD) [- How to do a sniffer capture](https://www.google.com/url?q=https://www.morsemicro.com/resources/appnotes/MM%2520APPNOTE-36%2520-%2520How%2520to%2520do%2520a%2520Sniffer%2520Capture.pdf\&sa=D\&source=editors\&ust=1783414931697453\&usg=AOvVaw0bjO0NO5ZnDWqkhgGh0UGr). 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.

Figure 26. OpenWRT menu to find security settings.

Next, navigate to the Wireless Security tab, and set the Encryption type to No Encryption (open network). Click Save, and then Save and Apply.

Figure 27. Setting security type on OpenWRT.

#### 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.

Figure 28. Setting security type through CLI application.

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:flag\_bb:43:dc:f5:87 | | ------------------------------------ |

Figure 29. Where to input filters on Wireshark.

Some useful filters including the one shown above are as follows: | Filter | Notes | | ----------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | wlan.addr == \ | 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 == \ or wlan.addr == \ | 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.

Figure 30. Where to find AP and STA MAC addresses on OpenWRT.

#### 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/](https://www.google.com/url?q=https://www.geeksforgeeks.org/what-is-packet-colourization-in-wireshark/\&sa=D\&source=editors\&ust=1783414931709240\&usg=AOvVaw3RkSASnVKGzlKdSA4erfS7). 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.

Figure 31. Example colour scheme on Wireshark highlighting different traffic types.

*** ## 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.

Figure 32. Adding a new network interface on OpenWRT.

Set name to “ahwlan”, and Protocol to “Static address”. Leave Device as “unspecified”, and click Create interface.

Figure 33. Creating a new interface.

Click Dismiss on the page that comes next.

Figure 34. Popup menu after creating a new interface.

Navigate to the Quick Config page, and next to ahwlan, click Create Zone. Also input an IP address of 192.168.1.1.

Figure 35. Creating a zone for ahwlan, and entering an IP address.

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.

Figure 36. Setting the 802.11ah radio to use the new isolated network interface.

#### 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.

Figure 37. Joulescope capture showing an example of when a DTIM beacon is missed, and the STA goes back to sleep, and then wakes up to receive the next regular beacon.

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.

Figure 38. Joulescope capture showing zoomed in view of wakeup current spike.

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.

Figure 39. Joulescope capture showing memory retention current spikes.

Figure 40. Joulescope culture showing zoomed in view of memory retention current spike.

## 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.

Figure 41. MM8108 DTIM wakeup zoomed out.

Figure 42. MM8108 wakeup current spike zoomed in.

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 | Abbreviation | Full Term | Description / Context | | ------------ | -------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | 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 | Release Number | Release Date | Release Notes | | -------------- | ------------ | ---------------- | | 01 | 11/06/2025 | Initial release. | # APPNOTE-35 How to configure a Starlink LTE Dongle Internet Uplink Connection v1 [Download as PDF](https://www.morsemicro.com/resources/appnotes/MM_APPNOTE-35_How_to_Configure_a_Starlink_LTE_Dongle_Internet_Uplink_Connection.pdf) ## 1 Scope This guide provides a step-by-step process for setting up an internet connection for HaLow devices, specifically the EKH Evaluation Kits and HaLowLink1, covering various uplink options and configuration scenarios. It covers configurations for various internet sources, including: * Starlink: Connecting via Ethernet or Wi-Fi from the Starlink router. * LTE Dongle: Setting up USB or Ethernet-based LTE modems. Hardware & Software Requirements 1. 1 x EKH (Evaluation Kit) or HaLowLink1 running Openwrt version (2.7.0) or above. 2. HaLow Client Devices (e.g., cameras, IoT devices, or another HaLow station such as EKH or HaLowLink1) 3. Internet Source: (Any one of the following) 4. Starlink (Ethernet Adapter + Router or Wi-Fi connection) 5. LTE Dongle (USB or Ethernet-based modem) 6. Laptop (For configuring the HaLow device) 7. Router (For bridging or additional network management, if needed) 8. Power Supply (Sufficient power for all connected devices) ## 2. Theory of Operation
This guide explains how to configure the Uplink connection on a HaLow Access Point device to create a setup like the one shown in the image below. In this setup, Device1 is configured as an HaLow Access Point, providing network access to: * Device2, which acts as a HaLow client connected over the HaLow interface. * A laptop, which connects to Device1’s 2.4GHz Wi-Fi AP. The HaLow Access Point uses a WAN uplink (Starlink, orLTE dongle) to provide internet access to both clients. In a HaLow network, the HaLow Access Point (EKH Evaluation Kit or HaLowLink1) can be configured in two primary modes to handle internet connectivity: Router Mode * The HaLow Access Point acts as a router, using an external internet source (Starlink/ LTE dongle) as its WAN uplink. * It creates a separate internal network (e.g: with IP address 192.168.12.x), where connected HaLow clients are assigned local IP addresses. * NAT (Network Address Translation) is applied, meaning all client traffic is routed through the HaLow device before reaching the WAN. * This mode isolates local devices from the WAN while providing controlled access to the internet.
Bridge Mode * The HaLow Access Point acts as a transparent bridge, extending the WAN network to all connected HaLow clients. * Clients are assigned IP addresses directly from the WAN uplink (e.g., the Starlink modem or LTE network). * There is no NAT, and clients can communicate directly with the external network. * This mode is useful when HaLow devices need to be part of an existing network rather than managing their own.
## 3 How to Configure The configuration process is divided into the following steps: 1. Setting Up the WAN Uplink 2. Starlink Uplink – Connect the HaLow Access Point to the Starlink Modem/Dish. 3. LTE USB Dongle – Configure the HaLow Access Point to utilize an LTE modem. 4. Configuring the HaLow Network 5. Routed to WAN (Router Mode) – HaLow Access Point performs Network Address Translation (NAT) between the WAN uplink and connected clients. 6. Bridged to WAN (Bridge Mode) – HaLow Access Point directly forwards traffic to the WAN, placing all clients on the same network. Each section will provide guidance on configuring HaLow Access Point based on the chosen uplink type and network mode. The setup will use the Device1 (HaLow Access Point) in different network modes while maintaining the following configuration: * Device1 (HaLowLink1 or Eval Kit) functions as the Access Point. * Device2 operates as a HaLow client. * A laptop is connected via Device1's 2.4GHz Wi-Fi AP. * An uplink device (Starlink, or LTE USB dongle) provides internet access. ### 3.1 Setting Up the WAN Uplink The goal of this step is to configure the HaLow Access point to establish an internet connection using one of the available uplink options. By the end of this step, the AP should be able to access the internet, ensuring that it can reach [www.morsemicro.com](https://www.google.com/url?q=http://www.morsemicro.com\&sa=D\&source=editors\&ust=1783415033415985\&usg=AOvVaw0MppCZHOzbryk265hs_CbR). #### 3.1.1 Setup Starlink Uplink The Starlink Standard Kit includes a Starlink Dish Antenna and a Router. There are two ways to connect your HaLow Access Point to Starlink: **3.1.1.1 Connecting to the Starlink Router (Default Setup)** This section provides guidelines to connect a HaLow Access Point - either the HaLowLink1 or the Eval Kit (EKH03) - to the Starlink Router’s Wi-Fi network.
1. Set up the Starlink Router according to the[official guidelines](https://www.google.com/url?q=https://www.starlink.com/au/support/article/412a70ca-0d9a-813e-b18f-75c36b84ec06\&sa=D\&source=editors\&ust=1783415033416763\&usg=AOvVaw2vORf5-ATXjKU6SOCZs_Rc). 2. Ensure the router is broadcasting the correct SSID (e.g. starlink-AP). Steps to connect HaLowLink1 3. Connect HaLow Access Point in this case which is a HaLowLink1 as a client of the Starlink Wi-Fi network. 4. Ensure the HaLow Access Point is in the right mode with its status LED showing green. Refer to the user guide to set up that mode. 5. Connect your laptop to the HaLow Access Point via its 2.4 GHz Wi-Fi SSID which is found on the label of the device. (e.g. Wi-Fi SSID: HaLowLink1-af0f) 6. Access the web UI at [http://192.168.12.1](https://www.google.com/url?q=http://192.168.12.1\&sa=D\&source=editors\&ust=1783415033417480\&usg=AOvVaw20XUOassuVqUQgjEgiuNCu), login using the “Device Password” and select the “Wizard” from the menu (direct [link](https://www.google.com/url?q=http://192.168.12.1/cgi-bin/luci/admin/morseapwizard\&sa=D\&source=editors\&ust=1783415033417631\&usg=AOvVaw19oyBxIt7PTAnRDli5eZRH)). 7. Select the Network mode to use the 2.4GHz Wi-Fi uplink as shown in the image below.
Note: If you select this option, the router mode is set as the default, as detailed insection 3.2.1. 5. Go to Home ([http://192.168.12.1/cgi-bin/luci/admin/home](https://www.google.com/url?q=http://192.168.12.1/cgi-bin/luci/admin/home\&sa=D\&source=editors\&ust=1783415033418131\&usg=AOvVaw2QSr4GBDVY21UlqYkUnfl9)) 6. Find the Uplink card, which should say “Disconnected” 7. Click the word “Disconnected” and provide the uplink network details (e.g. SSID: Starlink-WiFi, password: starlink-password) 8. Once connected proceed to section 3.1.1.3 to verify the device’s internet connectivity. Steps to connect EKH03 4. Connect the HaLow Access Point in this case which is an EKH03 as a client of the Starlink Wi-Fi network. 5. Ensure the EKH03 is configured as a HaLow Access Point. Refer to the user guide to set up that mode. 6. Connect your laptop to the HaLow Access Point via the LAN port using an ethernet cable. 7. Access the web UI at [http://10.42.0.1](https://www.google.com/url?q=http://10.42.0.1\&sa=D\&source=editors\&ust=1783415033419116\&usg=AOvVaw2bcTQLyl3GXn036Zpq76H1), and select the “Setup AP/ STA Wizard” from the Wizard menu. 8. On the Access Point wizard, configure the HaLow network as per the user guide, and on the Upstream Network page choose the 2.4GHz Wi-Fi uplink as shown in the image below.
5. The traffic mode is set to router mode as the default, as detailed insection 3.2.1. 6. Apply the configuration on the final page. 7. Once connected proceed to section 3.1.1.3 to verify the device’s internet Starlink Mini Kit (Wi-Fi Only) If you are using the Starlink Mini Kit, which has integrated Wi-Fi but no separate router, connect the HaLow Access Point directly to the Starlink Wi-Fi network as mentioned above in section 3.1.1.1. **3.1.1.2 Using HaLow Device as a Third-Party Router** The following section describes adding the HaLow Access Point as a third-party router to the Starlink router. Note: In this configuration, bridge mode cannot be enabled on the HaLow Access Point. The steps to configure are as follows, 1. Enable [Bypass Mode](https://www.google.com/url?q=https://www.starlink.com/au/support/article/a0fe8d51-32f7-d2b9-d74a-801e31ad9f6a\&sa=D\&source=editors\&ust=1783415033420595\&usg=AOvVaw2v699dL_vkVnrDC-X3JMun) on the Starlink router. 2. Connect HaLow AccessPoint as the third-party router, via plugging the ethernet cable to the WAN port of the device. 3. Creating a Static Route on the HaLow Access Point is a requirement for using the Starlink app. The following steps will demonstrate how to do this. 4. Navigate to Advanced Config > Network > Routing page ([http://192.168.12.1/cgi-bin/luci/admin/network/routes](https://www.google.com/url?q=http://192.168.12.1/cgi-bin/luci/admin/network/routes\&sa=D\&source=editors\&ust=1783415033421184\&usg=AOvVaw224dyp8mDq8LRw1gT2oRRc)) 5. Click on Static IPv4 Routes and click Add, then add the static route as suggested in the Starlink guide and hit “Save & Apply”.
**3.1.1.3 Verifying HaLow Access Point's internet Connectivity** To confirm that the HaLow Access Point can now connect to the internet through the 2.4 GHz uplink network, follow these steps: 1. Connect your laptop to HaLow Access Point's 2.4 GHz Wi-Fi (e.g. SSID: HaLowLink1-af0f). 2. Check your internet connection by loading a webpage like[www.morsemicro.com](https://www.google.com/url?q=http://www.morsemicro.com\&sa=D\&source=editors\&ust=1783415033421930\&usg=AOvVaw1qxnUThu51zOwIq0F285vy). Ensure your laptop is not connected to a different network. #### 3.1.2 Setup LTE Dongle Uplink This section describes how to configure a LTE USB Dongle for internet Access on Your HaLow Access Point.
Note: USB LTE Dongles are not supported by the HaLowlink 1 due to the absence of a USB port. However, Evaluation Kits (EKH01, EKH03, or EKH-19) can be used to support this configuration. Most LTE USB dongles on the market support NAT, and very few provide a public IP directly from the LTE provider. Neither scenario will impact how WAN is configured for the HaLow AP, unless the WAN interface is assigned an IP address. Configuration Steps The following configuration steps outline the process using the EKH01 as the HaLow Access Point (Device 1). 1. Connect your laptop to the HaLow Access Point via the Ethernet cable. 2. In a default state, you must be able to reach the device via [http://10.42.0.1/](https://www.google.com/url?q=http://10.42.0.1/\&sa=D\&source=editors\&ust=1783415033423428\&usg=AOvVaw143Gc2xqboBB1KZe7Ad1wU) . 3. Plug-in the LTE USB dongle to the HaLow AP and ensure that the dongle initializes properly with any LED indications as directed by the provider. For example, the “dmesg” logs indicate that a Huawei LTE USB dongle was connected to the EKH01.
From the WebUI, go to Services > Terminal, Login to the device and enter “dmesg” on the terminal to view the logs as shown above. Note: This indication may vary depending on the LTE dongle provider. 4. On the HaLow AP navigate to the [Wizards page](https://www.google.com/url?q=http://10.42.0.1/cgi-bin/luci/admin/ekhwizards\&sa=D\&source=editors\&ust=1783415033424131\&usg=AOvVaw0Yod91YKDILa4XkCf78VCT) and select the standard HaLow AP/STA wizard. 5. Select Access Point and proceed to configure the right Wi-Fi credentials and appropriate channel information. 6. On the Upstream Network page select the USB dongle, if you do not see the option it is
7. likely that the dongle was not initialized properly. Troubleshoot the dongle and try again. 8. Select the traffic mode as per the requisite, for more information on configuring the traffic mode refer to Section 3.2. 9. Apply the configuration and proceed to verify the internet connectivity.. Verifying HaLow Access Point's internet Connectivity To confirm that the HaLow AP can now connect to the internet through the LTE uplink network, follow these steps: On the Home page, the uplink card shows Connected as shown below:
Check your internet connection on your laptop by loading a webpage like [www.morsemicro.com](http://www.morsemicro.com). Ensure your laptop is not connected to a different network via Wi-Fi. ### 3.2 Configuring the HaLow Network The traffic mode of the HaLow network can be configured in two ways as aforementioned. This section explains the configuration details of each mode and what happens to the network flow in each mode. The configuration wizards for HaLowLink1 and Evaluation Kits enable users to configure both router and bridge traffic modes. However, the available options may differ between different uplink choices. This section will explain how to configure both modes in HaLowLink1 and Evaluation Kits, using both the configuration wizard. #### 3.2.1 Routed to WAN (Router Mode) **3.2.1.1 Configuring HaLowLink1 in router mode**
When configuring a HaLowLink1 device from the wizard page, selecting the options (either option 2 or 3) will make the HaLow client devices to obtain IP address on the device’s local network and configures the HaLow Access Point to function as a router. The resulting network configuration on the device will be as depicted in the following diagram.
**Figure 3.2.1** Network Flow * The HaLow Access Point (HaLowLink1) can establish an internet connection in two ways: * Using option 3, through the WAN interface (phy0-sta0), when connected to the Starlink modem (as per section 3.1.1.1). * Using option 2, through the WAN ethernet interface, when the HaLowLink1 is used as a third-party router (as per section 3.1.1.2). * Clients such as the Mobile, the HaLow client and the Laptop connect to the HaLowLink1 using the interfaces 2.4GHz Wi-Fi, HaLow and ethernet respectively. * HaLowLink1 NATs traffic between the WAN uplink and the connected clients, enabling them to access the internet while remaining on a separate internal network. * This setup ensures that all connected devices can communicate through HaLowLink1, which manages the routing and NAT functionality between the WAN and the local network. **3.2.1.2 Configuring Evaluation Kits in router mode** On the evaluation kit’s wizard page, configure the kit to be an Access Point as per the user guide and while configuring the Upstream Network, set the Traffic Mode to Router or Router with firewall. Selecting this mode segregates the HaLow network from the upstream network, enabling traffic routing between HaLow clients and the upstream router. For EKH03 or evaluation kits equipped with a 2.4GHz Wi-Fi radio, the HaLow network, Ethernet interface, and the 2.4GHz Wi-Fi Access Point are grouped under the LAN interface. The WAN uplink, configured as a 2.4GHz Station, is assigned to the WAN interface. This configuration aligns with the reference setup illustrated in Figure 3.2.1. For evaluation kits without a 2.4GHz Wi-Fi radio, such as the EKH01, connecting an Ethernet cable to the WAN uplink and setting up the router mode results in the HaLow network being included in the LAN interface, while the Ethernet interface is assigned to the WAN network. When using an LTE USB dongle as the uplink, the HaLow network, Ethernet interface, and the 2.4GHz Wi-Fi Access Point (if present) are incorporated into the LAN interface. The WAN uplink, identified as an Ethernet interface enumerated by the USB port, is added to the WAN network. This configuration ensures proper interface grouping and traffic routing based on the evaluation kit's hardware and chosen uplink method. #### 3.2.2 Bridged to WAN (Bridge Mode) The goal of bridge mode is to enable devices on both the HaLow and 2.4GHz networks to obtain IP addresses from the uplink connection (either Starlink Modem or LTE dongle). The LAN ethernet port can function as a management port or be configured to bridge to the uplink network. Note: This mode is not supported when operating the Starlink Modem in bypass mode. **3.2.2.1 Configure HaLowLink1 in bridge mode** Ensure that the HaLow Access Point (HaLowLink1) establishes an internet connection through the WAN ethernet interface, by connecting to an uplink internet modem.
**Figure 3.2.2** On the wizard page, select Option 1, to obtain IP on the existing router’s (uplink router) network. The resulting configuration is as depicted above in Figure 3.2.2. Network Flow * The WAN (bridged) network includes the WAN Ethernet interface and HaLow interface passing traffic transparently. * In bridge mode, the LAN network which includes the Ethernet interface and the 2.4GHz Wi-Fi AP has a static IP 192.168.12.1 with a DHCP server for management. * The HaLow interfaces function under the upstream network. **3.2.2.2 Configure Evaluation Kits in bridge mode** To configure the HaLow Access Point as a bridge, allowing traffic to flow between the HaLow client and other end clients (including the 2.4GHz Wi-Fi AP, if present), select 'bridge' as the traffic mode in the wizard on Evaluation Kits.
The resulting configuration is as follows. Network Flow * The WAN (bridged) network includes the WAN Ethernet interface and HaLow interface passing traffic transparently. * In bridge mode, the Ethernet interface and the 2.4GHz Wi-Fi AP are bridges together with the HaLow interfaces and obtain IP addresses from the upstream network and pass traffic transparently. ## 4 Frequently Asked Questions (FAQ) 1 Why is the 2.4GHz Wi-Fi uplink not supported in Bridge mode? The wizard on both the Evaluation Kits and the HaLowLink1 sets the device’s traffic mode to Router by default and does not provide an option to configure Bridge mode through the wizard interface. This limitation exists because configuring bridge mode requires utmost caution due to specific restrictions that may prevent proper operation. Notably, the 2.4GHz Station (STA) interface used for the uplink connection must be set to WDS mode to enable bridging. Additionally, the uplink Access Point (AP) that the device connects to must also support and be configured for WDS. Failing to meet these conditions will prevent the bridge configuration from functioning as intended. 2 Configure Ethernet interface to be bridged with the WAN When the traffic mode is set to Bridge, the Ethernet and 2.4GHz Wi-Fi interfaces are not automatically bridged with the WAN network and, in most cases, remain on a separate network. However, if you choose to bridge the Ethernet interface to the WAN uplink, this can be done manually from the Quick Config page of the device. In the Network Interfaces section, remove the lan and usblan interfaces from the Ethernet section of the lan network and add them to the wan network as shown in the example provided. Note: Making this change may result in the loss of connection to your device if you are connected through the lan or usblan interfaces of the HaLow Access Point. To regain access, you can either connect via the 2.4GHz Wi-Fi or identify the IP address assigned to the lan interface by the upstream uplink device and connect directly.
## 5 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | --------------- | | 01 | 2025-03-20 | Initial release | # APPNOTE-36 How to Do a Sniffer Capture v1 [Download as PDF](https://www.morsemicro.com/resources/appnotes/MM_APPNOTE-36_How_to_do_a_Sniffer_Capture.pdf) ## 1 Scope This document describes how to capture over-the-air (OTA) packet traffic using the MM6108 radio to listen to and capture packets on a Wi-Fi HaLow network. This can be used to observe all traffic being sent on the channel, not just traffic destined for the sniffer device. *** ## ## 2 Theory of Operation Network traffic or packet sniffing is the process of intercepting and logging traffic as it passes across a computer network. For wireless networks this is particularly feasible as the transmissions are visible to any listening radio within range of the device sending the traffic. Many network adaptors and wireless radios can be configured into a monitoring mode where it will passively listen to and log all transmissions on a given channel. Once logged (referred to as a ‘packet capture’), the details of the traffic can be examined using a specialised analyzer application such as Wireshark. Note that encryption can mean that while the packet is intercepted, its contents cannot be read without also having the security key. The MM6108 is able to be configured in a monitor mode, and the following sections outline how to capture traffic and load it into Wireshark. For the purpose of this guide it is assumed that the user has an evaluation kit running OpenWrt from Morse Micro. ## ## 3 How to Configure ### 3.1 Configure Monitor Mode and Channel #### 3.1.1 GUI Configuration For OpenWrt versions 2.7.x and higher, monitor mode can be set from the UI. Select Quick Config, and set the mode of the 802.11ah radio as Monitor. The channel and bandwidth are able to be set here. Click Save & Apply for changes to take effect.
*** To set the primary bandwidth and channel index, these can be set by navigating to Network → Wireless, and clicking Edit on the HaLow radio.
Set the intended Primary channel width and Primary 1MHz channel index, and click Save & Apply. In release 2.7.2 it appears in Advanced Settings:
In release 2.8.2 (and onwards) it has moved under General Setup:
*** #### #### 3.1.2 CLI Configuration Run the following commands to put the device into sniffer mode and configure the channel to sniff on. In this example, the sniffer will look at packets on the 908MHz channel. ### iw dev wlan0 del iw phy phy1 interface add mon0 type monitor ifconfig mon0 up && ifconfig morse0 up `# Configure channel` `# -c channel frequency` `# -o channel bw` `# -p primary bw` `# -n primary ch index` morse\_cli -i mon0 channel -c 908000 -o 8 -p 2 -n 0 *** ### 3.2 Capture with SSHdump Modern versions of Wireshark prompts for the installation of sshdump as an external capture utility. Selecting to install this feature presents the user with an SSH remote capture interface which simplifies (and saves) the connection and authentication configuration and allows for the ability to stop/restart the packet capture natively in Wireshark. To capture with sshdump, select the SSH remote capture interface.
The first time this capture interface is started, Wireshark will prompt for configuration. The required configuration is outlined below. Server:
Configure the IP address and port used to access the device. Authentication:
Configure the SSH details to access the device. Supports access via either the device password or using private keys. If the underlying device for a given IP address regularly changes in the test set up, consider disabling StrictHostKeyChecking for that IP address. Capture:
Set the remote interface to morse0 to capture 802.11ah frames. Use tcpdump on the remote host. The remote capture filter should only be required if connecting to the remote device over HaLow. Wireshark provides a default filter here to eliminate noise from the SSH connection. *** Click ‘Start’ to initiate the capture and observe the results.
*** ### ### 3.3 Alternative Options For legacy purposes, this document retains the previous instructions to call tcpdump directly via SSH and pipe the output to Wireshark. This may be helpful in environments with older versions of Wireshark which do not support configuration of sshdump directly. #### 3.3.1 Launch Wireshark with SSHdump from the command line wireshark -oextcap.sshdump.remotehost:10.42.0.1 -oextcap.sshdump.remoteinterface:morse0 -i sshdump -k #### 3.3.2 Capture with tcpdump Then start tcpdump to capture the packets and write it to a file on the device. tcpdump -i morse0 -w capture.pcap Sniffer captures can become large quickly so make sure there is enough space on the filesystem if you want to do a long capture. Once the capture is done, download the .pcap file to your computer and open it with Wireshark to view the packets. #### 3.3.3 Pipe tcpdump directly to Wireshark on local machine It is possible to pipe the tcpdump output directly into Wireshark on a local machine through an SSH connection to the sniffer device. To do so, run the following command on the local machine: On a Mac: ssh root\@10.42.0.1 tcpdump -i morse0 -U -s0 -w - | /Applications/Wireshark.app/Contents/MacOS/Wireshark -k -i - On Linux: ssh root\@10.42.0.1 tcpdump -i morse0 -U -s0 -w - | sudo wireshark -k -i - On Windows: ssh root\@10.42.0.1 tcpdump -i morse0 -U -s0 -w - | "C:\Program Files\Wireshark\Wireshark.exe" -k -i - This assumes the IP address of the device is 10.42.0.1 and Wireshark is installed in the default location. Once the command is run, Wireshark should open up and start displaying all the captured packets in the channel. ## ## 4 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | --------------- | | 01 | 20/03/2025 | Initial release | # APPNOTE-37 How to Configure Virtual Wire v1 [Download as PDF](https://www.morsemicro.com/resources/appnotes/MM_APPNOTE-37_How_to_Configure_Virtual_Wire.pdf) ## 1 Scope This application note provides a guide on configuring and verifying a Virtual Wire configuration on the Morse Micro HaLowLink 1. The prerequisites for this application note are: * 2 x [Morse Micro HalowLink 1](https://www.google.com/url?q=https://www.morsemicro.com/end-products/\&sa=D\&source=editors\&ust=1783415558201672\&usg=AOvVaw1xSRdoQBPGaqqfrSVNzZPI) devices with the latest software installed (this guide was written based on v2.7.4). * 1 x Ethernet port which connects to a network (e.g. a port on your router or switch). * For validation, we assume this network routes traffic to the internet. * 1 x Laptop with USB-C and ping, traceroute and iperf3 installed. By following this application note you will learn: * How to configure HalowLink1 devices to setup Virtual Wire. * How to validate this is operating correctly. *** ## 2 Theory of Operation Virtual Wire is shorthand for any network appliance that looks like it replaces an Ethernet cable. That is, Layer 1 (Physical) and Layer 2 (Data) traffic is passed through it, and the device itself does not require an IP address. This makes it possible to seamlessly work in any existing network without any need for reconfiguration. The general network topology should look something like this: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/LLhnAfV6Ik4zdb7O8iA4/Unknown%20image)) If you use Wi-Fi HaLow to implement a ‘Virtual Wire’, this means you can extend any existing network over long distances without having to worry about integrating the HaLow devices into your network or giving them any special permissions. ## 3 How to Configure ### 3.1 Configuring the Access Point By default, the HaLowLink 1 is configured as a router with an access point. To make sure it passes traffic directly, you will need to access its web interface so it acts only as an access point: 1. Connect your laptop via USB-C to the device. 2. Connect an Ethernet cable from the port marked WAN on the HaLowLink 1 to the Ethernet port you wish to extend. 3. Wait until the Status LED is solid green or aqua. 4. Make sure the device is reset by holding down the mode button on the bottom of the device until the Status LED starts flashing green. 5. Wait until it’s solid green. 6. Your laptop should detect the HaLowLink 1 as an Ethernet connection. 7. Go to [http://192.168.12.1](https://www.google.com/url?q=http://192.168.12.1\&sa=D\&source=editors\&ust=1783415558204456\&usg=AOvVaw2jX41ZP8y6P7HaJuu3ABmB), and login with the username root and the “Device Password” printed on the sticker. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/1p4Yt47V7igA5Lr3v0cP/Unknown%20image)) 8. Confirm that the Ethernet Uplink is marked as ‘Connected’ on the home page. 9. Click on the Wizard option. 10. Select “HaLow Wi-Fi devices will get an IP on your existing router's network”. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/Gyy2sYPDN8E5YJsZfZqi/Unknown%20image)) 11. Click “Save & Apply” and wait until it finishes “Applying Configuration Changes”. Once you’ve configured the device, you can now disconnect it from your laptop, and use the provided power supply to power it. ### 3.2 Configuring the Extender This device needs to function as a HaLowLink 1 Extender. To ensure it is reset into this mode: 1. Make sure the HalowLink 1 Access Point device is no longer connected to your laptop. 2. Connect your laptop via USB-C to the other HaLowLink 1. 3. Wait until the Status LED is solid green or aqua. 4. Make sure the device is reset by holding down the mode button on the bottom of the device until the Status LED starts rapidly flashing aqua, then release the button. * It will first start slowly flashing green. You must continue holding the button down until it flashes aqua. If you accidentally release it earlier, wait until it’s solid green again. 5. Wait until it’s solid aqua. 6. Leave the Extender connected to your laptop. *** ### ### 3.3 Pairing the two devices After completing 3.1 and 3.2, your devices should be connected this way. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/e3IlttGqbxzgjwYUT4J5/Unknown%20image)) Note that the Extender’s Wi-Fi HaLow status LED is not lit as it is not yet associated with any HaLow network. You are now ready to establish the HaLow connection. 1. On Device 1 (the Access Point), connected to the Ethernet port of the existing router, press and release the mode button on the bottom of the device. The Wi-Fi HaLow LED should start slowly flashing purple. 2. On Device 2 (the Extender), connected to your laptop via USB-C, press and release the mode button on the bottom of the device. The Wi-Fi HaLow LED will start slowly flashing purple. 3. Wait until both devices have a solid purple HaLow LED. This indicates they’re connected. This should usually happen within a minute. If the pairing process fails, the Wi-Fi HaLow LED on Device 2 will eventually stop flashing and turn off. In this case, make sure no-one else is trying to pair a HaLowLink 1 nearby (as for security reasons this will fail), wait 60 seconds, and try again. Once you have successfully paired your devices the Extender’s Wi-Fi HaLow status LED should be solid purple: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/QFUO7vCI4YiWxxTJNqpp/Unknown%20image)) ### 3.4 Validating the connection Your laptop should now act as if it’s physically connected to the Ethernet port, even though all traffic is transmitted over the HaLow Wi-Fi link. To confirm that this is working as you would expect: 1. Make sure that you only have a single Ethernet connection on your laptop (i.e. the one provided by the HaLowLink 1). Disconnect any other Ethernet cables. 2. Disable the Wi-Fi on your laptop. 3. If your normal network has a DHCP server, you may need to disable/enable the HaLowLink 1 network connection to get an address. This is because when it was initially connected to your laptop, the HaLowLinks did not have a connection established. Otherwise, configure your laptop as needed for the network (e.g. with a static IP). 4. Use your normal network; if this is connected to the internet, attempt to access [http://example.com](https://www.google.com/url?q=http://example.com\&sa=D\&source=editors\&ust=1783415558208942\&usg=AOvVaw2OSQD3eVzcPYNO1oZNF_i6) 5. Because your HaLowLink 1 devices are relatively close, you should achieve 18-22Mbps. Confirm this via [https://speed.cloudflare.com/](https://www.google.com/url?q=https://speed.cloudflare.com/\&sa=D\&source=editors\&ust=1783415558209207\&usg=AOvVaw1BG3sg2RasqBAr_DMLR-N5). 6. Validate that traffic is not routed via the HaLowLink 1 (i.e. that the first IP provided is one on your local network, the same as if you had connected directly to the Ethernet port):\ ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/ALxWhgNUYsjxnCfk7AgS/Unknown%20image)) WARNING: this simple setup leaves the devices in DHCP client mode and with their 2.4GHz access points enabled. If you would like to ensure that no-one can connect to these devices directly without physical access, see the FAQ below. ## 4 How this works When configured this way, Linux bridges on the devices are used to connect the physical interfaces. On the HaLowLink 1 Access Point side, the port labelled WAN is bridged with the HaLow access point, and on the Extender side all Ethernet ports are bridged with the HaLow client (or station). This means that any Layer 2 traffic is passed between the Ethernet ports. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/8f616eSBOx0Ef5sUV1md/Unknown%20image)) ### 4.1 Technical details If you SSH to a device (e.g. ssh root@\[deviceip] and use the password on your sticker), you can view this setup from the Linux command line using the brctl show command. On the AP side, it should show something like: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/3c3SMajhTsg0NuZ7Xuhs/Unknown%20image)) Note that the name of the bridge here is br-wlan. This is because the name of the ‘network’ in OpenWrt is a higher level abstraction defined in the UCI network file /etc/config/network: config interface 'wlan' option proto 'dhcp' option device 'br-wlan' config device option name 'br-wlan' option type 'bridge' list ports 'wan’ Even though the wireless interface wlan0 is part of br-wlan, it is not specified here. Because wireless interfaces are dynamically constructed by hostapd or wpa\_supplicant, OpenWrt specifies the wlan network on the wireless side in /etc/config/wireless[\[a\]](#cmnt1)[\[b\]](#cmnt2): config wifi-iface 'default\_radio1' option mode 'ap' option wds '1' option device 'radio1' option network 'wlan' option ssid 'halowlink1-f4a1' On the Extender side, where instead everything is on the lan network, this looks like: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/ynJPoU8aWGBuJR89LECj/Unknown%20image)) Excerpt from /etc/config/network: config device option name 'br-lan' option type 'bridge' list ports 'usblan' list ports 'lan' list ports 'wan' config interface 'lan' option device 'br-lan' option proto 'dhcp' Excerpt from /etc/config/wireless: config wifi-iface 'default\_radio1' option mode 'sta' option wds '1' option device 'radio1' option network 'lan' option ssid 'halowlink1-f4a1' ### 4.2 Wireless Distribution System (4-address mode) You may have noticed the wds option that was set in the above configuration. A normal wireless client would not be capable of attaching to a bridge, whether using HaLow or any other 802.11 wireless interface, as a normal wireless client does not use 4-address mode (also known as WDS, “Wireless Distribution System”). Without 4-address mode, packets originating from or directed to the client/station side of a wireless link must share the MAC address of the wireless interface, whereas 4-address mode allows four distinct addresses: the TA (transmitter address - e.g. wlan0 AP), RA (receiver address - e.g. wlan0 client), a DA (destination address) and SA (source address). For this to work correctly, both access point and client must be in WDS mode. In the setup in Section 3, this has been automatically selected for you. For more information about how to configure this manually, see Section 4. ### 4.3 DHCP client mode The default configuration here leaves your HaLowLinks in DHCP client mode. This makes it easier to access their configuration interface or ssh to them, as if you have a DHCP server on your network they will get a DHCP lease. To discover their IP, refer to the DHCP lease table on your network. However, if you wish them not to be accessible on your network at all, you should change the protocol to unmanaged. You can do this via the network interfaces page: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/HhUALefnsPNoeXg0gCG7/Unknown%20image)) ## 5 Manual Configuration If you would like to better understand the configuration used for Virtual Wire and what settings are critical, you can configure it manually via the following steps. This will also be helpful if you wish to make small modifications to an existing setup (as developed in Section 3). ### 5.1 Configuring the Access Point First, connect to the HalowLink 1 Access Point as in 3.1: 1. Connect your laptop via USB-C to the device. 2. Connect an Ethernet cable from the port marked WAN on the HaLowLink 1 to the Ethernet port you wish to extend. 3. Wait until the Status LED is solid green or aqua. 4. Make sure the device is reset by holding down the mode button on the bottom of the device until the Status LED starts flashing green. 5. Wait until it’s solid green. 6. Your laptop should detect the HaLowLink 1 as an Ethernet connection. 7. Go to [http://192.168.12.1](https://www.google.com/url?q=http://192.168.12.1\&sa=D\&source=editors\&ust=1783415558216121\&usg=AOvVaw2TC5Kfe6erGZ28t36lC9gq), and login with the username root and the “Device Password” printed on the sticker. 8. Confirm that the Ethernet Uplink is marked as ‘Connected’ on the Home page. By default, the HaLow access point is bridged with the local network (192.168.12.x) provided by default. You can see this in the Network Interfaces card on the Home page (if you hover over ‘wlan0’ it will provide more information about this link, and highlight the related cards): ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/aEWT98ZnyXnrImDQIIJt/Unknown%20image)) For Virtual Wire, we instead want to bridge the access point with the uplink connection, which is on the wan port. However, the wan interface (which contains the wan port) is by default configured with a firewall which blocks traffic, as a standard internet router would be. We could amend these firewall rules, but a simpler option is to create an entirely new network interface. To do this, make sure Advanced Config is enabled in the menu, and go to Network -> Interfaces: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/E25zHOmrOpgTFKtZaC7H/Unknown%20image)) Now you can Add new interface…, typing in wlan and selecting DHCP client, leaving Device unspecified: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/7GQMC3ykZXKmksS3qZij/Unknown%20image)) Once you’ve clicked Create Interface, dismiss the dialog that comes up. You should now see UNSAVED CHANGES at the top of the page. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/1BqROUPaXojQtd5CKb2g/Unknown%20image)) At any point when configuring, you can click on UNSAVED CHANGES to view the commands that you would need to use via the CLI: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/KrBXayMaK8skq31laBHw/Unknown%20image)) You do not need to Save & Apply this yet, although it won’t hurt; the frontend allows you to accumulate a large changeset and apply it all at once. Now go to the Quick Config page where we can see we have a new wlan interface (below lan and wan) which doesn’t have any Wireless or Ethernet devices: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/LAPNppHDpkDAKV9xso0c/Unknown%20image)) To set it up, we need to: * click Create Zone to create a firewall zone (which will default to ACCEPT all) * remove the wan port from the wan interface by unticking it * add the wan port to the wlan interface by ticking it It should now look like this:\ ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/i9STLoIJFmFngBhuwdNV/Unknown%20image)) Finally, go down to the ‘Wireless’, section, and change the network of your Morse Micro MM6108 device from lan to wlan: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/KAeUtzzllsAO9dDZzuvS/Unknown%20image)) This change should be reflected in Wireless column of your Network Interfaces section: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/U1ShlvwGLKUMWXneITy4/Unknown%20image)) If you now click Save only, you can again go to UNSAVED CHANGES: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/vkOtLWE8eORXaVf09NiN/Unknown%20image)) Click Save & Apply to make these take effect. Return to the Home page to confirm that the wan port and the wlan0 HaLow interface are bridged: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/B6v0oCAKSuofRzTFntf2/Unknown%20image)) You have now finished configuring your access point. ### 5.2 Configuring the Client First, reset the device and connect to it via Ethernet from your laptop: 1. Connect your laptop via USB-C to the device. 2. Wait until the Status LED is solid green or aqua. 3. Make sure the device is reset by holding down the mode button on the bottom of the device until the Status LED starts flashing green. 4. Wait until it’s solid green. 5. Your laptop should detect the HaLowLink 1 as an Ethernet connection. 6. Go to [http://192.168.12.1](https://www.google.com/url?q=http://192.168.12.1\&sa=D\&source=editors\&ust=1783415558220815\&usg=AOvVaw103db6VVkl72k0zpdgEw1x), and login with the username root and the “Device Password” printed on the sticker. Navigate to the ‘Quick Config’ page. Under wireless you will see the Morse Micro device behaving as an Access Point (WDS) on the lan network. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/1CxOAbNZWEqH24Z7lFtj/Unknown%20image)) Now change the mode to be Client (WDS) and search for the network of the corresponding HaLow access point which you would like to connect to. Once the network appears in the SSID/Mesh ID dropdown, you can select it and enter in the credentials from the sticker on that device, ensuring that you use WPA3-SAE encryption. At this point the morse device is on the lan network, and we would like to remove its static IP. However, if we were to proceed with this change we would immediately lose access to the device, as the 192.168.12.1 IP would be removed. The workaround to this is to move it to the wan network via the dropdown to test the client connection. The admin interface will temporarily remain accessible at [http://192.168.12.1](https://www.google.com/url?q=http://192.168.12.1\&sa=D\&source=editors\&ust=1783415558221978\&usg=AOvVaw0sGTqhHcu3_gnxehthuma_) on the lan network. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/WVydqPpJQ1uvS1u6ODlS/Unknown%20image)) Once the changes have been made to mimic the image above, you can now click Save only, you can again go to UNSAVED CHANGES at the top of the page to see something similar to this: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/JJxgasEEQ8qSedkAKAjS/Unknown%20image)) Click Save & Apply to make these changes take effect. After the changes have been applied and the page is reloaded, navigate to the ‘Home’ page. If you have entered the credentials correctly and the devices have associated you should be able to see the Uplink (HaLow) card indicating a connection with the newly assigned IP (which you should save somewhere accessible) like below: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/Pi7wb8yknbiUIVqxjvUt/Unknown%20image)) The HaLow connection has been made, but the Virtual Wire configuration is incomplete. In the final steps we will consolidate all the available devices onto the lan network and set it up to receive an IP from the HaLow access point. Return to ‘Quick Config’ and modify the Morse Micro wireless device to use the lan network. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/VtfNnwDsCxI2w9PGEzAG/Unknown%20image)) The ‘Network Interfaces’ subsection should now show both your 2.4 GHz and HaLow networks colocated on the lan row under the ‘Wireless’ column. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/kxszF0ycPlwpTkLxDJH5/Unknown%20image)) Unset the DHCP Server slider and select DHCP Client under the protocol drop down to ensure that the Extender will correctly receive an IP from the AP. Then, using the ‘Ethernet’ dropdown options, remove the wan Ethernet device from the wan network to the lan one: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/GPQ20yXeKqVueEF7qkg0/Unknown%20image))![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/e12kQMP9uhMKgcPAfRpb/Unknown%20image)) After clicking Save you should be able to see the following UNSAVED CHANGES: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/vyFOAS2F2dmvtkZhocRm/Unknown%20image)) From here click Save & Apply where you will be warned about losing your access to [http://192.168.12.1](https://www.google.com/url?q=http://192.168.12.1\&sa=D\&source=editors\&ust=1783415558224573\&usg=AOvVaw0gbQlqoT7Y9URXJP7qa3il). Select 'Apply and Keep Settings’ to persist your changes. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/30ghCjNKdIJZbfSbUjEB/Unknown%20image)) You have now configured your Virtual Wire Extender! It will remain accessible at the IP you recorded earlier when the HaLow Wi-Fi was on the lan network. ## 6 FAQ Can I access the HaLowLink 1 admin interface once I’m in this mode? You can access the admin interface on the AP by either: * connecting to the LAN or USB port, and accessing 192.168.12.1 as before. This is because only the HaLow and WAN ports are bridged. * connecting to the AP from your existing network by determining its IP from the DHCP lease table on your DHCP server. You can access the admin interface on the Extender by either: * connecting to the Extender from your existing network by determining its IP from the DHCP lease table on your DHCP server. * connecting to the LAN or USB port, and setting your network connection to have a static IP of 10.22.121.110 and a netmask of 255.255.255.254. You can then access the admin interface at Why do these devices have IPs? I thought Virtual Wire didn’t require any Layer 3 configuration? The default configuration leaves them in DHCP client mode (so the admin interface can still be easily accessed) as above. If you do not want this behaviour, set the protocol on the network interface to unmanaged, as described in 4.3 DHCP client mode. I’ve noticed that the Wi-Fi 2.4GHz LED is on. What is this about? HaLowLink 1s have a 2.4 access point enabled by default for ease of setup. If you do not want this, you should disable the 2.4 AP by going to the Quick Config page and clicking the slider in the ‘Enabled’ column so that it looks like this: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/GolN3QEQn1AqMmEQQnBN/Unknown%20image)) *** How can I make sure the HaLowLink 1 devices are not accessible without physical access? By default, HaLowLink 1 devices provide an HTTP admin interface and SSH access with username root and the password printed on the device. If you do not want them to be accessible over the 2.4 AP or via the network they’re connected to, you should set all appropriate interfaces to ‘unmanaged’ and disable the 2.4GHz AP as described above. For additional hardening, you may want to disable dropbear (the ssh service) or uhttpd (the http service), restrict them to listening on particular interfaces or IPs, or institute appropriate firewall rules. This will make it harder - or impossible - to reconfigure the device without resetting it. To disable services, you can run the commands service dropbear disable and service uhttpd disable or do so via the System -> Startup page in the user interface. Here changes will take effect immediately, so make sure you ‘Stop’ the uhttpd service as your last action. It is safe to disable services initially, as this will just block them on startup: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/McKtZb513jRzPY2EcjFA/Unknown%20image)) ## 7 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | --------------- | | 1 | 11/04/2025 | Initial release | # APPNOTE-38 Wi-Fi Easy Connect using DPP URIs or QR Codes v1 [Download as PDF](https://www.morsemicro.com/resources/appnotes/MM_APPNOTE-38_Wi-Fi_Easy_Connect_using_DPP_URIs_or_QR_codes.pdf) ## 1 Scope This document briefly introduces the rationale for Wi-Fi Easy Connect and provides manual instructions that demonstrate Wi-Fi credential sharing between two HaLowLink devices via a Device Provisioning Protocol (DPP) Uniform Resource Identifier (URI). DPP URIs are frequently printed as QR codes, but the QR code on the HaLowLink label does not contain a DPP URI; it is rather a Wi-Fi credentials URI\[1] which is only useful for devices that can read QR codes directly. Therefore, this App Note will involve using the terminal and manually copying the DPP URI from one device to the other. To make this suitable for end users, you would need to build additional software to automate the process. The prerequisites for this application note are: * 2 x [Morse Micro HalowLink](https://www.morsemicro.com/halowlink/) (1 or 2) devices with the latest software installed (this guide was written based on Morse Micro OpenWrt v2.11) * 1 x Laptop with two USB-C ports (or USB-A to USB-C adapters) *** ## 2 Theory of Operation With traditional computers and mobile devices, users typically enter Wi-Fi credentials through a user interface to connect to a network; in most cases, the user types a known SSID and key into their computer. Devices without an easily accessible user interface need another method to securely obtain Wi-Fi credentials. The Wi-Fi Easy Connect standard defines the Device Provisioning Protocol (DPP) as a way to share credentials. DPP supports several mechanisms, and by default, HaLowLink supports using push buttons to initiate DPP\[2]. Some devices lack buttons or a user interface, so they must use an alternate credential sharing technique - such as by scanning a QR code\[3]; using NFC or Bluetooth\[4]; or by using a trusted third party\[5]. Many of these techniques work by encoding the credential bootstrapping information into a DPP URI\[6] and then sharing that URI securely. In this app note, the DPP URI is shared as a trusted third party that has secure access to both devices via SSH. Designing a production-ready solution depends on a product's deployment and commissioning requirements, but it might involve encoding and scanning QR codes; implementing Bluetooth-based DPP via a smartphone; or distributing DPP URIs via a cloud-based service. The basic principle is that a configurator is provided with the enrollee's public key, which allows the configurator and enrollee to establish a secure, encrypted connection and for the configurator to provide the enrollee with credentials for the Wi-Fi network. Then only the configurator needs a UI; the enrollee (i.e., the new device) does not. In this document, the Access Point (running hostapd) will function as the configurator, and the Clients/Stations (running wpa\_supplicant) will be the enrollees. This will work as follows: 1. A HaLowLink Extender which is configured with a public-private key pair (A-a) 2. A DPP URI is generated containing the HaLowLink Extender’s MAC address and public key (A) 3. A HaLowLink Access Point where hostapd is a DPP Configurator 4. The DPP URI is provided to the DPP Configurator on the Access Point 5. The Extender emits DPP Presence Announcements until the Access Point detects it 6. The DPP Configurator on the Access Point recognizes the Extender as its key (A) was registered in (4) 7. The DPP Configurator on the Access Point securely provides the Extender with credentials In this document, hostapd will act as the DPP Configurator, but depending on requirements, other services can act as the configurator, and indeed may not even be running on the Access Point (which could be an enrollee). For technical details about hostapd’s DPP implementation, refer to [README-DPP](https://github.com/MorseMicro/hostap/blob/415d1757c25357e0d5423fe5f025e4384be7cb1b/wpa_supplicant/README-DPP). For further information about Wi-Fi Easy Connect, refer to: * [Wi-Fi Easy Connect™: Simple and secure onboarding for IoT](https://www.wi-fi.org/beacon/dan-harkins/wi-fi-easy-connect-simple-and-secure-onboarding-for-iot) * [Wi-Fi Easy Connect](https://www.wi-fi.org/discover-wi-fi/wi-fi-easy-connect) * [Wi-Fi Easy Connect Specification v3.0](https://www.wi-fi.org/system/files/members/Wi-Fi_Easy_Connect_Specification_v3.0.pdf) *** ## 3 How to Configure ### 3.1 Configuring the Extender By default, the HaLowLink is configured as a router with an access point. To reset the device into Extender mode: * Connect your laptop to the device via USB-C. * Wait for the Status LED to turn solid green or aqua. * Reset the device by holding down the mode button on the bottom of the device until the Status LED starts rapidly flashing aqua, then release the button. * It will first flash green slowly. Keep holding the button down until it flashes aqua. If you accidentally release it earlier, wait until it’s solid green again. * Wait until it’s solid aqua. Because the device is now in Extender mode, it does not have a DHCP Server. However, you can use the static emergency recovery IP (10.22.121.111) to access it if you manually configure your laptop's Ethernet connection with the IP 10.22.121.110 (subnet mask 255.255.255.0). #### 3.1.1 Accessing the terminal Now, we can use the terminal to set up DPP: ![Figure 1: HaLowLink device sticker](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/9GSqmiJTWq2EMBIOlMHF/Unknown%20image) * Go to and log in using the username and password on your device. * On the left-hand side menu, click Advanced, then go to Services -> Terminal, and use the same password as above to log in #### 3.1.2 Generate a private key Generate the private key (/etc/dpp\_key.pem is the default path used for the dpp\_key variable in our wpa\_supplicant configuration file; it is also possible to get wpa\_supplicant to generate a key at runtime): ``` root@halowlink1-1947:~# openssl ecparam -genkey -name prime256v1 \ -noout -outform PEM > /etc/dpp_key.pem ``` #### 3.1.3 Configure wpa\_supplicant Set the HaLow radio to emit DPP Presence Announcements (which will include the public key), confirming that radio1 is the correct radio (if it’s not, try radio0): ``` root@halowlink1-1947:~# uci show wireless.radio1.type wireless.radio1.type='morse' root@halowlink1-1947:~# uci set wireless.default_radio1.dpp=1 root@halowlink1-1947:~# uci commit root@halowlink1-1947:~# reload_config ``` #### 3.1.4 Record the DPP URI (which includes the public key) Determine the DPP URI beginning with “DPP:” and save this to use it later: ``` root@halowlink1-1947:~# wpa_cli_s1g dpp_bootstrap_get_uri 1; echo Selected interface 'wlan0' DPP:M:94bb43dcf993;V:3;K:MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgADpfVUMGW64skm+qzbmcn1nw3cgZw+fA2oJgEYSI06oAk=;; ``` #### 3.1.5 Confirm that wpa\_supplicant is working Follow the logs to confirm that DPP-TX is happening. We suggest leaving this terminal open while you configure the Access Point: ``` root@halowlink1-1947:~# logread -f wlan0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=5745 type=13 wlan0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=5805 type=13 wlan0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=5865 type=13 wlan0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=5745 type=13 wlan0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=5805 type=13 wlan0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=5865 type=13 ``` ### 3.2 Configuring the Access Point By default, the HaLowLink is configured as a router with an access point. If you have modified the configuration, we suggest performing a factory reset before following this guide: * Connect your laptop to the device via USB-C. * Do not remove the Extender. You should now have two HaLowLink devices connected to your laptop. * Wait for the Status LED to turn solid green or aqua. * Reset the device by holding down the mode button on the bottom of the device until the Status LED starts flashing green. * Wait until it’s solid green. Now, we can make sure it’s a configurator and register the Extender’s public key: * Go to in a new tab/window, and access the terminal as you did for the Extender (but with the Access Point’s username and password) #### 3.2.1 Determine the current Wi-Fi credentials Get the SSID and key as hexadecimal values after confirming that radio1 is correct: ``` root@halowlink1-f4a1:~# uci get wireless.default_radio1.ssid | tr -d '\n' | hexdump -v -e '/1 "%02x"'; echo 68616c6f776c696e6b312d66346131 root@halowlink1-f4a1:~# uci get wireless.default_radio1.key | tr -d '\n' | hexdump -v -e '/1 "%02x"'; echo 6c617a7930387465 ``` Use these hexadecimal values for the SSID and password (pass) in the following section. #### 3.2.2 Configure hostapd and register the DPP URI Connect to hostapd\_cli\_s1g, set it up as a configurator, and register the DPP URI from above. You must use the values that were determined above for dpp\_uri/key/ssid: ``` root@halowlink1-f4a1:~# hostapd_cli_s1g dpp_configurator_add Selected interface 'wlan0' 1 root@halowlink1-f4a1:~# hostapd_cli_s1g set dpp_configurator_params 'conf=sta-sae ssid= pass=' Selected interface 'wlan0' OK root@halowlink1-f4a1:~# hostapd_cli_s1g dpp_qr_code '' Selected interface 'wlan0' 1 ``` #### 3.2.3 Verify that your Extender is correctly provisioned Check the logs: ``` root@halowlink1-f4a1:~# logread -l 100 -f … wlan0: DPP-RX src=28:d0:43:80:f8:d6 freq=5280 type=13 wlan0: DPP-RX src=28:d0:43:80:f8:d6 freq=5805 type=13 wlan0: DPP-RX src=28:d0:43:80:f8:d6 freq=5280 type=13 wlan0: DPP-RX src=28:d0:43:80:f8:d6 freq=5805 type=13 wlan0: DPP-RX src=28:d0:43:80:f8:d6 freq=5280 type=13 wlan0: DPP-CHIRP-RX id=1 src=28:d0:43:80:f8:d6 freq=5280 hash=... wlan0: DPP-TX dst=28:d0:43:80:f8:d6 freq=5280 type=0 wlan0: DPP-TX-STATUS dst=28:d0:43:80:f8:d6 result=SUCCESS wlan0: DPP-RX src=28:d0:43:80:f8:d6 freq=5280 type=1 wlan0: DPP-AUTH-DIRECTION mutual=0 wlan0: DPP-TX dst=28:d0:43:80:f8:d6 freq=5280 type=2 wlan0: DPP-TX-STATUS dst=28:d0:43:80:f8:d6 result=SUCCESS wlan0: DPP-AUTH-SUCCESS init=1 pkhash=... own=-1 peer=1 wlan0: DPP-CONF-REQ-RX src=28:d0:43:80:f8:d6 wlan0: DPP-BAND-SUPPORT 115,118,121,124,125 wlan0: DPP-ENROLLEE-CAPABILITY 1 wlan0: DPP-RX src=28:d0:43:80:f8:d6 freq=5280 type=11 wlan0: DPP-CONF-SENT conf_status=0 wlan0: STA 28:d0:43:80:f8:d6 IEEE 802.11: associated (aid 1) wlan0: WDS-STA-INTERFACE-ADDED ifname=wlan0.sta1 sta_addr=28:d0:43:8 wlan0: AP-STA-CONNECTED 28:d0:43:80:f8:d6 auth_alg=sae wlan0: STA 28:d0:43:80:f8:d6 RADIUS: starting accounting session... wlan0: STA 28:d0:43:80:f8:d6 WPA: pairwise key handshake completed. wlan0: EAPOL-4WAY-HS-COMPLETED 28:d0:43:80:f8:d6 ``` *** ## 4 How to Verify After following the previous steps, the purple Wi-Fi HaLow LED light on the Extender should come on. You can verify that it’s connected to your Access Point by going to the Access Point interface at and clicking on the Access Point card to see the associated Clients: ![Figure 2: Expanded Access Point card with client list](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/xBDRDewbV85MR0z200RK/Unknown%20image) You can also go back to the user interface of the Extender and click on the ‘Uplink’ card to confirm that it now contains the correct credentials. Now that the credentials are stored, DPP has no further role, and you will be able to remove power from the devices, set them up elsewhere, and the Extender will re-authenticate with the Access Point. *** ## 5 FAQs **What happens if I change the SSID/password on an AP after provisioning devices?** With the mechanism described, because they are no longer using DPP and have stored the normal credentials, they will lose access. The devices would have to move back into DPP Presence Announcement mode (i.e., set dpp=1), and because hostapd’s built-in configurator does not persist the DPP URIs, you would need to resubmit the enrollee’s URI. You can and should use the same URI as before. **Can I use DPP URIs with HaLowLinks out of the box?** No, HaLowLink devices do not support this mechanism. This document describes how to experiment with using DPP URIs for those who might like to use them in a product, but there are missing pieces: * HaLowLink devices are not provisioned with a DPP key on the device; * HaLowLink devices do not have a DPP QR code containing the DPP URI printed on the device (the QR code on the device is rather the Wi-Fi credentials QR code); * There is no user-friendly mechanism to read the DPP URI from an Extender and provide it to an Access Point (i.e., hostapd); * When factory reset into Extender mode, they are not set to emit DPP Presence Announcements. **How would I use DPP URIs in a product?** One approach is to use the interaction described in this document, but fix the deficiencies discussed above. However, you may also consider: * Using a custom configurator (e.g., a mobile application) which configures both Access Points and Clients. Depending on the device, this could even use 2.4 GHz Wi-Fi to do the credentials exchange; * Provide the DPP URI of devices via some other mechanism; for instance, a trusted service could pre-populate DPP URIs. See section 5.7 of the Wi-Fi Easy Connect Specification v3.0 for a discussion of approaches. **How can an Access Point ever read a QR code if it doesn’t have a camera?** This could be done via the web UI (if run on a phone with a camera) or via a mobile app which could securely communicate with the Access Point. *** ## 6 Revision History | Version Number | Release Date | Release Notes | | -------------- | ------------ | --------------- | | 1 | 17 Sep 2026 | Initial Release | # APPNOTE-39 MM6108 OTP for BCF and MAC Read and Write Guide v3 [Download as PDF](https://www.morsemicro.com/resources/appnotes/MM_APPNOTE-39_MM6108_OTP_for_BCF_and_MAC_Read_and_Write_Guide.pdf) ## 1 Overview The Morse Micro MM6108 software contains the functionality to read and write the Wi-Fi HaLow MAC address on the chip, as well as a board ID that can be used to select the appropriate board configuration file. The MAC address and board ID is stored in One Time Programmable (OTP) memory. OTP programming is an advanced process that should be conducted in a controlled manufacturing environment by a sophisticated user. #### ## 2 Program Conditions The following conditions must be followed to ensure the device is not damaged. * VDDIO must be driven at 2.5V±10% to program the OTP bits. Voltage set beyond the specified allowance will lead to chip damage. * Each OTP bit can only be programmed once in the chip lifetime. If multiple write instructions are made to the MAC address bits the firmware will report an error. Note: An unprogrammed bit will read as a 0 and a programmed bit will read as a 1. ## 3 Program Conditions Prior to attempting to read the MAC address, ensure that the morse driver is inserted with the wlan0 interface up. To read the MAC address stored in the OTP memory, run the following morsectrl command: `# morsectrl macaddr` ### 3.1 Original factory settings By default, the MM6108 module does not have a MAC address or board ID burned into OTP memory. After running the above command, the expected output should be: `# morsectrl macaddr` Chip MAC address: 00:00:00:00:00:00 If the MAC address has not been burned into the chip, the Morse Micro starting script will load one given the following mapping: #### | MAC Byte | B0 | B1 | B2 | B3 | B4 | B5 | | -------- | ---- | ---- | ----- | ------- | ------- | ------- | | OTP Bits | 7:0 | 15:8 | 23:16 | 31:24 | 39:32 | 47:40 | | Value | 0x0C | 0xBF | 0x74 | eth0 B3 | eth0 B4 | eth0 B5 | The following demonstrates the MAC address allocation in the instance that a MAC address has not been burned into the chip. The highlighted portion indicates that the last three octets of the chip MAC are derived from the eth0 MAC address. `# morsectrl macaddr` Chip MAC address: 00:00:00:00:00:00 `# ifconfig` eth0 Link encap:Ethernet HWaddr DC:A6:32:E1:0C:36 inet addr:10.53.2.10 Bcast:10.53.255.255 Mask:255.255.0.0 inet6 addr: fe80::dea6:32ff:fee1:c36/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2958 errors:0 dropped:562 overruns:0 frame:0 TX packets:979 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:307152 (299.9 KiB) TX bytes:155359 (151.7 KiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:184 errors:0 dropped:0 overruns:0 frame:0 TX packets:184 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:13909 (13.5 KiB) TX bytes:13909 (13.5 KiB) wlan0 Link encap:Ethernet HWaddr 0C:BF:74:E1:0C:36 inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::ebf:74ff:fee1:c36/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:160132 errors:0 dropped:2 overruns:0 frame:0 TX packets:141731 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:201277497 (191.9 MiB) TX bytes:178353026 (170.0 MiB) ## 4 Writing the OTP MAC Address Prior to writing the MAC address, ensure that the Program Conditions are adhered to. This indicates that: The chip must have a VDDIO set to 2.5V, and The MAC OTP bits must only be set once in the chip lifetime. To write the MAC address to the OTP memory, run the following morsectrl command: `# morsectrl macaddr -w ` ⚠️ Note that after setting the MAC address, the return address may not match the MAC address specified until a restart is conducted. After conducting the write command the voltage can be set back to the normal operational level if required. The morse driver must be reloaded for the burned OTP bits to be read correctly. To see the OTP write in effect, reboot the device or run the restart script: \#/etc/init.d/S99morse restart *** After reloading the morse driver, the MAC address will be read from the OTP bits memory. Example usage of this functionality is demonstrated below: `# morsectrl macaddr -w 0C:BF:74:AA:BB:CC` Chip MAC address: cb:4c:83:14:f9:5f ## `# /etc/init.d/S99morse restart` ## `# ifconfig` eth0 Link encap:Ethernet HWaddr DC:A6:32:E1:0C:36 inet addr:10.53.2.10 Bcast:10.53.255.255 Mask:255.255.0.0 inet6 addr: fe80::dea6:32ff:fee1:c36/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:357629 errors:0 dropped:90597 overruns:0 frame:0 TX packets:14481 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:40781633 (38.8 MiB) TX bytes:2412501 (2.2 MiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:188 errors:0 dropped:0 overruns:0 frame:0 TX packets:188 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:15277 (14.9 KiB) TX bytes:15277 (14.9 KiB) wlan0 Link encap:Ethernet HWaddr 0C:BF:74:AA:BB:CC inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::ebf:74ff:fee1:c24/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:11 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:1064 (1.0 KiB) *** ## 5 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | -------------------- | | 01 | 03/08/2022 | First release | | 02 | 20/10/2023 | 1st Doc. Control | | 03 | 14/05/2025 | Updated per template | # APPNOTE-41 OTP and BCF Selection v1 [Download as PDF](https://www.morsemicro.com/resources/appnotes/MM_APPNOTE-41_OTP_and_BCF_Selection.pdf) ## 1 Scope This document describes the steps necessary for Morse Micro’s module partners to support automatic selection of Board Configuration Files (BCFs), and to participate in distribution of said BCFs by Morse Micro alongside our drivers. This document applies to modules manufactured using all variants of the MM6108 and MM810x Wi-Fi HaLow™ chips. For additional information on the BCF itself and its importance to correct operation of the module, please refer to MM APPNOTE-26: BCF Overview and Impact on System Performance. ## 2 OTP Boardtypes The MM6108 and MM810x chips have a small amount of OTP memory used for configuration and calibration data. There is a two-byte field reserved for a “boardtype”. This allows the driver to identify the specific module from software. Morse Micro will now assign a one-byte prefix to each of our module partners. From this range, module partners should assign a one-byte suffix to each type of module. As these identifiers are used to select the BCF, any modification to the module that requires a new, incompatible BCF should get a new suffix. For example, the Morse Micro uses a prefix of 0x08 for its own modules, and the MM6108-MF08651-US reference module has a unique identifier of 0x01. The boardtype for this module is thus 0x0801. ## 3 Driver Behavior When the Morse Micro driver for Linux is loaded it will select a BCF based on the following logic: 1. If the bcf module parameter is set, attempt to load the file named in the modparam. 2. If the serial module parameter is set, attempt to load bcf\_.bin, where is the value of the modparam. 3. If the serial modparam is default, read the OTP boardtype value. 4. If the value is 0x0000 (unset) or 0xFFFF (ignore), then use bcf\_default.bin 5. Attempt to load bcf\_boardtype\_xxxx.bin, where xxxx is the boardtype value 6. If boardtype is set and the file does not exist, abort the driver load. This allows automatic selection of the correct BCF based on boardtype, but retains an ability to override that choice with a module parameter. ## 4 Programming OTP The OTP eFuses on the MM6108 and MM810x can be read by the morse\_cli utility, and read and written using the morsectrl utility. While this section will only cover programming the boardtype value, this manufacturing step would be an excellent opportunity to program the MAC address and any private data required in OTP. ### 4.2 MM6108-specific requirements Certain electrical conditions must be met when writing to OTP on the MM6108. Per the datasheet, VDDIO must be 2.5V ±10% while programming. Attempting to program OTP with VDDIO outside this specification may result in damage to the OTP block. ### 4.2 Reading boardtype To read the boardtype (if any) programmed into OTP, use the following morsectrl command: `# morsectrl boardtype` 0x802 If the boardtype is not set, morsectrl will return Board type is not set \[NOTE: Add output from a board with boardtype set here] ### 4.3 Writing boardtype To write the boardtype use the following morsectrl command: `# morsectrl boardtype -w 0x0801` ## 5 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | --------------- | | 01 | 06/03/2025 | Initial Release | # APPNOTE 43 Wi-Fi HaLow RF Test Guide v1 [Download as PDF](https://www.morsemicro.com/resources/appnotes/MM_APPNOTE-43_HaLow_RF_Test_Guide.pdf) ## 1 Scope This application note offers detailed technical guidance and foundational background for conducting and interpreting cabled RF measurements of MM6108 and MM8108 Wi-Fi HaLow devices. This application note introduces foundational theoretical concepts, including essential RF measurement parameters, HaLow test modes, and the use of Vector Signal Transceivers (VSTs) for conducting Transmit (TX) and Receive (RX) evaluations. It also provides a comprehensive overview of the test environment setup, detailing each critical component—such as LitePoint testers, HaLow devices under test (DUT), and associated RF instrumentation. In addition, it includes guidance on using the RF Tester software package provided by Morse Micro to configure and control the HaLow device under test. By the end of this document, readers should be able to: * Understand the key measurement parameters essential for evaluating the quality of HaLow TX and RX performance * Configure a complete RF test setup for HaLow TX and RX measurement * Execute consistent and repeatable RF measurements using standard equipment * Identify and resolve typical device behavior issues This document is intended for RF test engineers, validation teams, and embedded developers working with Morse Micro’s HaLow chipsets, particularly in environments where accurate wireless performance evaluation is critical. *** ## 2 Background Information ### HaLow Test Modes #### Random Packet Generator (RPG) To evaluate the quality of a Wi-Fi HaLow transmit signal, the Device Under Test (DUT) must actively transmit. Rather than establishing a HaLow connection with another device, the MM6108 and MM8108 offer several test modes designed specifically for this purpose. One such mode is Random Packet Generator (RPG) mode, which enables the DUT to continuously transmit packets with randomized payloads. These packets can then be captured by RF test equipment, and analyzed to evaluate key signal metrics and overall transmit performance. Note: RPG mode is not included in standard production firmware. Specialized test firmware is required. Please contact your Morse Micro representative to obtain access. #### Fast Symbol Generator (FSG) The Fast Symbol Generator (FSG) is a test mode to allow testing of higher duty cycles than is possible with RPG mode. RPG mode is limited to \~90% duty cycle due to interframe spacing requirements, and internal overhead within the HaLow chip. FSG mode is used for regulatory testing where the minimum duty cycle is more than RPG is capable of. Note that FSG packets may not be able to be decoded by VSTs, and this mode should ONLY be used for regulatory testing, not for any transmitter or receiver verification. Note: FSG mode is not included in standard production firmware. Specialized test firmware is required. If needed, contact your Morse Micro representative to obtain access. *** ### Vector Signal Transceiver For Wi-Fi HaLow testing, a Vector Signal Transceiver (VST) is employed as a near-ideal transceiver to both generate the RF transmission signal and receive the response signal, enabling accurate characterization of the device under test (DUT) with minimal distortion or noise introduced by the test equipment. This application note specifically details the use of LitePoint testers as the Vector Signal Transceiver (VST) for RF measurements. Although other test equipment may be compatible, they have not been officially validated by Morse Micro. #### Recommended LitePoint Model The recommended LitePoint model is the [IQxel-MW 7G](https://www.google.com/url?q=https://www.litepoint.com/products/iqxel-mw-7g/\&sa=D\&source=editors\&ust=1783470052532700\&usg=AOvVaw0uyO5q8IUzfIe8mqTE6szp). As the latest generation hardware, it offers full support for all Wi-Fi HaLow features and benefits from ongoing firmware updates and active technical support from LitePoint. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/hrUeMZjCJYu8ql35aSA9/Unknown%20image) Figure 1. LitePoint IQXel-MW 7G model with 8 ports. #### Discontinued LitePoint Models LitePoint no longer supports legacy test instruments such as the [IQxel-MW](https://www.google.com/url?q=https://www.litepoint.com/products/iqxel-mw/\&sa=D\&source=editors\&ust=1783470052534369\&usg=AOvVaw0Osh6iMiIQC3Wz3Az5MQna) and [IQxel-M](https://www.google.com/url?q=https://www.litepoint.com/products/iqxel-m/\&sa=D\&source=editors\&ust=1783470052534615\&usg=AOvVaw3lYL6y1x3lmeE2RDNjFCev). Continued use of these models is not recommended. For full support, ongoing firmware updates, and optimal RF performance, migration to the IQxel-MW 7G is advised. Due to firmware limitations on older models, RF metric reporting differs from that of the IQxel-MW 7G. Comparative testing conducted by Morse Micro shows that transmit power and EVM measurements remain aligned across units. However, SEM results from legacy testers are less accurate due to the inability to upgrade their firmware. At power levels where SEM limits become marginal, inaccuracies from older units may lead to false module failures. In such cases, the module may be operating within acceptable parameters, but the outdated LitePoint model incorrectly reports a failure. To ensure accurate test outcomes, it is recommended IQxel-MW 7G model is used in production workflows. This avoids inconsistencies caused by unsupported hardware and ensures reliable RF performance assessment. #### LitePoint Firmware Version Maintaining up-to-date LitePoint firmware is critical to ensure accurate and reliable RF measurements. As firmware versions may vary by model, it is recommended to contact LitePoint support to verify that the correct and latest version is installed. *** ## 3 Key Measurement Metrics This section outlines key RF metrics captured by VSTs and the HaLow devices to evaluate the quality of TX and RX performance. While not an exhaustive list of all parameters measured by the VST, the metrics presented here represent the core set used by Morse Micro to validate device performance and ensure compliance with the IEEE 802.11ah specification. ### Transmit (TX) Metrics #### Power Description: Power is the strength of the transmitted RF signal; used to verify signal levels and regulatory compliance. There are typically two power measurements of interest, average power and peak power. Average power is calculated over the full packet duration, and is used as the primary indicator of TX output performance. Peak power reflects the highest instantaneous power observed, and is critical for meeting regulatory requirements. Both measurements are specified in dBm. Typical Measurement: On a LitePoint, this is typically observed either through TX Quality Orthogonal Frequency-Division Multiplexing (OFDM) plot, and the spectrum plot. Instructions for accessing these plots are provided in the Performing HaLow Measurements section. Note that the LitePoint reports the channel power, rather than the total power. In the example shown below, this means it is the power across the 8 MHz signal, and does not include any of the sidelobes or harmonics. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/bTnvwvh19KNXzzilnPOY/Unknown%20image) Figure 2. Example power measurement in the LitePoint GUI. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/Ik73rNIM8DS9RgBjvGv2/Unknown%20image) Figure 3. Spectrum plot within the LitePoint GUI. Expected Result: The expected result will vary upon the device being used, bandwidth, channel, and Modulation and Coding Scheme (MCS) rate. Please consult the relevant chip or module datasheet for expected power numbers. The measured power reflects the signal level received at the LitePoint connector. It does not account for any cable losses or external attenuation present in the signal path by default. Instructions for compensating for path loss are found in the Inputting External Attenuation section. Common Failure Modes: * Incorrect or misconfigured Board Configuration File (BCF). * Components on the transmit path with high insertion loss are unaccounted for. * Inaccurate Path loss has been applied. *** #### Error Vector Magnitude (EVM) Description: Error Vector Magnitude quantifies the modulation accuracy of a transmitted OFDM signal. It measures the difference between the ideal (reference) constellation points and the actual received points for the In-phase and Quadrature (I/Q) plane. Mathematically, EVM is expressed as a percentage or in decibels (dB), and is defined as: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/ZnEytHyj6tx7dIafTJWZ/Unknown%20image) Figure 4. EVM Equation Lower EVM values indicate better modulation accuracy and overall signal quality. In Wi-Fi HaLow, maintaining EVM within specified limits is critical for ensuring reliable communication and compliance with the standard's Physical (PHY) layer requirements. Typical Measurement: On a LitePoint tester, this is typically observed using the TX Quality OFDM table as a value or the Constellation OFDM plot. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/qpmHqlCicIcCppmp6HYm/Unknown%20image) Figure 5. Example EVM measurement in the LitePoint GUI. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/xPcAuscdq0SWQjqyU74P/Unknown%20image) Figure 6. Example constellation of a 64-QAM signal. Expected Result: EVM limits are MCS rate dependent. Table 23-30 from the [IEEE 802.11ah specification document](https://www.google.com/url?q=https://standards.ieee.org/ieee/802.11ah/4960/\&sa=D\&source=editors\&ust=1783470052545649\&usg=AOvVaw3GTgi_iBPdDYKY4ibOUqfk) shows the specification limits. An individual device must meet or exceed the IEEE limit in all circumstances. For example: MCS8 must have an EVM ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/6aWMas5NKY7oPy0xZi8X/Unknown%20image) 30dB. ⚠️Important: For volume production, the manufacturer must apply an additional limit margin to accommodate process variation and sample size variability. See Test Margin Considerations for detailed guidance. Table 1. EVM Limits per IEEE 802.11ah specifications | MCS | Limit (dB) | | --- | ---------- | | 10 | -4 | | 0 | -5 | | 1 | -10 | | 2 | -13 | | 3 | -16 | | 4 | -19 | | 5 | -22 | | 6 | -25 | | 7 | -27 | | 8 | -30 | | 9 | -32 | Common Failure Modes: * Incorrect or misconfigured BCF. * Impedance mismatches on the DUT’s transmission line. * Driving the Power Amplifier (PA) near its saturation regions. * Poor cable quality. *** #### Spectrum Emissions Mask (SEM) Description: The spectrum emissions mask specifies the maximum permissible signal power levels at various frequency offsets from the centre frequency of a transmitted signal. The image below is taken from the [IEEE 802.11ah specification document](https://www.google.com/url?q=https://standards.ieee.org/ieee/802.11ah/4960/\&sa=D\&source=editors\&ust=1783470052554642\&usg=AOvVaw05KeBLvY5iohtAwMYc7x96), and shows the mask of an 8 MHz signal. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/wyGakWo1JpTE0c2NQqck/Unknown%20image) Figure 7. Example spectrum mask from the IEEE 802.11ah specification. This measurement is critical to ensure compliance for both specification and regulatory requirements. Note: It is important to clarify that the LitePoint SEM measurement does not report absolute power (in dBm). Instead, it calculates the margin (in dB) between the spectral mask (internal limit) and the measured power levels at various frequency offsets. Typical Measurement: The SEM value is displayed in the Spectrum Mask Margins plot on the LitePoint system. It provides individual margin values for each spectral mask segment. For SEM margin measurements, LitePoint divides the analysis bandwidth into segments based on the IEEE 802.11ah spectral mask. These segments are organized into lower and upper regions relative to the channel center frequency. Each region includes segments 1 through 4, progressing outward from the center frequency. Segment 1 corresponds to the edge of the occupied bandwidth, approximately 0.5 times the channel bandwidth from the center. Segment 2 spans from the edge of segment 1 to 1× the channel bandwidth. Segment 3 extends from 1× to 1.5× the channel bandwidth, and segment 4 covers the region beyond 1.5× the channel bandwidth. If a single SEM value is required, it is typically reported as the minimum margin observed across all spectral mask segments. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/MSi4JnOLQgScN4TRgP4J/Unknown%20image) Figure 8. Example SEM measurement in the LitePoint GUI. In the example above, the lowest (minimum) margin across all measured frequency offsets is 5.85 dB, which is reported as the final SEM result for this segment. Expected Result: All SEM margin points must be ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/iiJISl0RABieLxMdKJJ2/Unknown%20image) 0 dB to be IEEE compliant. ⚠️Important: For volume production, the manufacturer must apply an additional limit margin to accommodate process variation and sample size variability. See Test Margin Considerations for detailed guidance. Common Failure Modes: * Incorrect or misconfigured BCF. * Impedance mismatches on the DUT’s transmission line. * Driving the Power Amplifier (PA) near its saturation regions. * Poor cable quality. * Shielding issues. #### Spectral Flatness (SF) Description: Spectral flatness ensures that the transmitted signal maintains uniform power distribution across its occupied bandwidth. The specification defines allowable power deviations across individual subcarriers, and accordingly, the LitePoint reports spectral flatness measurements in dB per subcarrier. Typical Measurement: This can be seen on the LitePoints Spectral Flatness OFDM measurement. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/zgevxFiHZ1ystg4cJ88Y/Unknown%20image) Figure 9. Example SF measurement in the LitePoint GUI. The lowest (minimum) value across all subcarriers is recorded and compared against the defined spectral flatness limits. Expected Result: All Spectral Flatness measurements must remain within the defined limit lines under all conditions. Similar to SEM, the minimum margin across the subcarriers is typically used as the reported Spectral Flatness value. If this minimum exceeds the limit (0 dB), the Spectral Flatness test passes for that subcarrier. For example, in [Figure 9](#id.555bqvt8y16i) the subcarrier measurement line (purple) is above the lower limit and below the upper red limit line. Therefore, all values pass the SEM requirement. ⚠️Important: For volume production, the manufacturer must apply an additional limit margin to accommodate process variation and sample size variability. See Test Margin Considerations for detailed guidance. Common Failure Modes: * Incorrect or misconfigured BCF. * IQ imbalance or DC offsets in the transmit chain. * Nonlinearities in the power amplifier. * High frequency error and phase noise. #### Frequency Error Description: Frequency error is the difference between the measured frequency and the nominal (expected) frequency. For example, a signal intended to transmit at 924 MHz may actually be transmitting at 924.1 MHz due to frequency error. This measurement is essential for regulatory compliance—ensuring the signal stays within its allocated spectrum—and to reduce RX PER for the receiver. Frequency error can be defined in either Hz or PPM (Parts Per Million). The IEEE 802.11ah specification defines a frequency error limit of ±20 PPM. Frequency error can be converted from Hz to PPM as per: ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/DTJtbMNDJMCGZVNq6jVv/Unknown%20image) Figure 10. Frequency error Hz to PPM equation. Typical Measurement: On a LitePoint tester, frequency error is typically seen on the TX Quality OFDM measurement. Here, the LitePoint presents the measurement in Hz. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/qSwd215fogIvgQoN7BNH/Unknown%20image) Figure 11. Example frequency error measurement in the LitePoint GUI. Using the formula above and a center frequency of 924 MHz, the calculated frequency error is –7.07 PPM. This falls within the ±20 PPM limit and is therefore considered a pass. Expected Result: All frequency error values must be within ±20 PPM in all circumstances. ⚠️Important: For volume production, the manufacturer must apply an additional limit margin to accommodate process variation and sample size variability. See Test Margin Considerations for detailed guidance. Common Failure Modes: * Crystal oscillator inaccuracy. * Incorrect or untuned load capacitors on the crystal oscillator. * Temperature drift. * Increased RX PER for the receiver. #### Local Oscillator (LO) Leakage Description: Local oscillator leakage verifies that the transmitter does not leak significant energy at the carrier frequency when transmitting modulated signals. LO leakage is typically caused by IQ imbalance or Direct Current (DC) offsets in the transmit chain, can impact receiver performance, as well as cause issues for meeting CE regulatory requirements. This is given by the LitePoint in dB. Typical Measurement: This can also be viewed in the TX Quality OFDM measurement. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/EPW7rfpcnva9jdyKH7tw/Unknown%20image) Figure 12. Example LO leakage measurement in the LitePoint GUI. Expected Result: LO leakage must meet or exceed the specified limits under all conditions, as outlined in the table below for each bandwidth. Table 2. LO leakage limits. | Bandwidth (MHz) | Specification Limit (dB) | | --------------- | ------------------------ | | 1 | -14.2 | | 2 | -17.5 | | 4 | -20.6 | | 8 | -23.8 | Common Failure Modes: * Incorrect or misconfigured BCF. * IQ imbalance or DC offsets in the transmit chain. * Improper VSA reference level. * Path loss not accounted for. ### RX Items #### Packet Error Rate (PER) Description: Packet error rate is the ratio of incorrectly received packets to the total number of transmitted packets. It reflects the overall reliability of the communication link and includes the effects of noise, interference, and signal quality. PER is especially useful for validating receiver sensitivity and end-to-end system performance. Typical Measurement: Packet Error Rate (PER) is performed by transmitting a known number of packets from the Vector Signal Generator (VSG)—in this case, the LitePoint tester. The HaLow device tracks statistics indicating how many packets were successfully received. By dividing the number of correctly received packets by the total number sent, the PER can be calculated as a percentage. Detailed steps for configuring both the LitePoint and the HaLow device to perform this measurement are provided in the Performing HaLow Measurements section. Expected Result: The PER will change depending on the bandwidth, MCS rate, and power level of the transmitter. More guidelines on expected RX sensitivity which reflects PER can be found in the RX Sensitivity section. Common Failure Modes: * Low signal power. * Poor Signal to Noise Ratio (SNR). * High EVM. * External RF interference. * Path loss unaccounted for. * Impedance mismatches on the DUT’s transmission line. * Poor cable quality. *** #### RX Sensitivity Description: RX sensitivity, as defined by the IEEE 802.11ah standard, is the minimum signal level at which the packet error rate (PER) remains below 10%. In practical terms, higher sensitivity allows a device to detect weaker signals, improving its performance at longer ranges or in high-interference environments. Typical Measurement: This measurement is typically performed by sweeping the input power across a range of fixed levels while monitoring the PER. The RX sensitivity is defined as the lowest input power at which the PER remains at or below 10%. Results are often presented as a graph, such as the example shown below, which depicts PER versus input power for a 1 MHz, MCS0 signal. The red line at 10% PER serves as the threshold; in this case, the RX sensitivity is determined to be approximately -107 dBm. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/rS1BrJJyqeWb1iMVjsqJ/Unknown%20image) Figure 13. Example RX sensitivity graph for a 1 MHz MCS0 signal. Expected Result: RX sensitivity must meet or exceed the IEEE 802.11ah specification limits across all bandwidths (see [Table 3](#id.iu2sskyhyylb)). Morse Micro devices consistently and significantly surpass these requirements, offering enhanced performance and reliability. Therefore, it is recommended to align with Morse Micro targets rather than the minimum IEEE limits. For the latest approved RX sensitivity targets, please contact your Morse Micro representative. Table 3. IEEE 802.11ah specification RX sensitivity limits. | MCS | IEEE 802.11ah Specification Limit - 1 MHz (dBm) | IEEE 802.11ah Specification Limit - 2 MHz (dBm) | IEEE 802.11ah Specification Limit - 4 MHz (dBm) | IEEE 802.11ah Specification Limit - 8 MHz (dBm) | | --- | ----------------------------------------------- | ----------------------------------------------- | ----------------------------------------------- | ----------------------------------------------- | | 10 | -98 | N/A | N/A | N/A | | 0 | -95 | -92 | -89 | -86 | | 1 | -92 | -89 | -86 | -83 | | 2 | -90 | -87 | -84 | -81 | | 3 | -87 | -84 | -81 | -78 | | 4 | -83 | -80 | -77 | -74 | | 5 | -79 | -76 | -73 | -70 | | 6 | -78 | -75 | -72 | -69 | | 7 | -77 | -74 | -71 | -68 | | 8 | -72 | -69 | -66 | -63 | | 9 | -70 | -67 | -64 | -61 | Common Failure Modes: RX sensitivity shares all the same common failure modes of RX PER. *** ### Test Margin Considerations #### Production Manufacturing For module manufacturing, LitePoint testing is automated using test scripts. Morse Micro has developed a script suite called "Manufacturing Test" to evaluate module performance with the LitePoint system. This suite is maintained by the Morse Micro team and is updated and released as changes are implemented. For more information on Manufacturing Test, please contact your Morse Micro representative. #### Inherent Process Variation All manufacturing processes exhibit inherent variation, typically modeled as a normal distribution characterized by a mean (μ) and standard deviation (σ). This variation results in a statistical spread of measured outcomes for any given parameter (e.g. Power, EVM, SEM), even under controlled conditions. As a theoretical example, transmit power measurements for MCS0 BW1 across 100,000 modules may show a normal distribution with a mean of 25 dBm and standard deviation of 0.2 dB. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/JFCvJpa1jgV51VPQxuMG/Unknown%20image) Figure 14. Transmit Power Normal distribution for MCS0 BW1 across 100,000 modules. #### Tuning RF Parameters for Production Yield For RF devices, transmit power is the primary factor influencing other RF metrics such as EVM and SEM. This is especially critical when tuning for maximum output power, where small variations can significantly impact these parameters. As a result, transmit power should be set at the highest practical level that maintains adequate margin across all key RF parameters, accommodates for process variation, and ensures high yield in volume production. Consider MCS9 BW8, which has an IEEE EVM limit of –32 dB. EVM is typically directly influenced by transmit power; decreasing transmit power likely improves EVM and vice-versa. A non-robust approach is selecting transmit power using a limited sample size (e.g., 5 modules) and targeting an EVM that just meets the –32 dB limit. This approach overlooks process variation and in high-volume production is likely to result in low yield. While the mean EVM may match the small-sample result of –32 dB, the standard deviation was not considered. With a standard deviation of 0.2 dB, the resulting distribution (as shown below) has a yield of approximately 50%. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/X2tx1WMfI7WoQQyolaUN/Unknown%20image) Figure 15. Normal distribution showing the consequences of inadequate margin from IEEE limits. In contrast, the recommended approach is to characterize RF parameters process variation (e.g., EVM, SEM) using a larger sample size (e.g., 100 modules). This allows selection of transmit power levels with sufficient margin to account for both module-to-module and run-to-run variation. In the image below, the transmit power has been reduced so the mean EVM has been improved to -34dB. With the same standard deviation as the previous case, the expected yield in high-volume production is likely 100%. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/MyGYS6xNaLTlZZDuGEhN/Unknown%20image) Figure 16. Normal distribution showing higher yield when designing in margin from IEEE limits. Furthermore, RF parameters are commonly interdependent. For example, a module with poor EVM that exceeds the IEEE limit increases the likelihood of packet errors (PER) under field conditions, resulting in reduced average data throughput in practical environments. #### Importance of Margin in Test Limits To achieve target yield in high-volume production, test limits must be defined with sufficient margin beyond nominal IEEE specifications. This margin accounts for process variation, measurement uncertainty, and run-to-run variability, ensuring yield targets are met. #### Risk of Inadequate Margin Failure to account for process variation during limit definition may result in either low yield (due to over-constraining limits) or poor field performance (due to under-constraining limits). Therefore, test limit definition must be based on a statistical understanding of process capability and aligned with yield targets. Note: All Morse Micro reference designs have undergone test limit selection and validation to achieve strong field performance and high manufacturing yield. Morse Micro limits and recommendations are available upon request. #### Morse Micro Approach to Yield and Limit Optimization The Morse Micro team analyzes module statistical distributions in conjunction with Process, Voltage, Temperature (PVT) data to account for process variation and external factors (e.g. temperature effects). Using measured data, we define performance targets and test limits to ensure high yield and robust field performance. We follow a process of continuous improvement, routinely refining our manufacturing, design, and test methodologies to enhance module performance and yield. As a result, limit recommendations may be updated over time to reflect the latest characterization data. For this reason, this document does not specify Morse Micro limits. For the most current target limits across all RF parameters, please contact your Morse Micro representative. *** ## 4 Test Environment Setup This section will detail the environment setup to perform RF measurements on a HaLow device. This guide will focus exclusively on using an IQxel-MW 7G as the tester, and a Morse Micro [HaLowLink 1](https://www.google.com/url?q=https://au.mouser.com/ProductDetail/Morse-Micro/MM-HL1-EXT?qs%3D%25252BHhoWzUJg4Iv3HqaYbEclw%253D%253D\&sa=D\&source=editors\&ust=1783470052609865\&usg=AOvVaw2v_ARQB2LKIjE5mE-_weVc) as the HaLow device under test. This guide will give limited details into configuring the HaLowLink 1, focusing more on the RF testing process as a whole. ### Block Diagram ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/ZjHs94jmrAiJRFifj4nx/Unknown%20image) Figure 17. Block diagram of an example test setup. An Ethernet connection is required to interface with both the LitePoint tester and the HaLowLink 1 device. A shielded RF cable must be used between the DUT and the LitePoint port to prevent external interference, which can significantly affect measurement accuracy—particularly RX sensitivity. A barrel attenuator should be placed in-line to ensure the received signal does not exceed the LitePoint’s maximum input power. Note that LitePoint does not automatically account for any external attenuation; instructions for manually entering path loss compensation are provided in the LitePoint section of this document. Depending on the cabling, an RP-SMA to SMA adapter may also be required for connecting to the HaLowLink 1. Some recommended parts are listed below: * 20 dB barrel attenuator (500 mW): [CATTEN-0200](https://www.google.com/url?q=https://www.digikey.com.au/en/products/detail/crystek-corporation/catten-0200/1767721\&sa=D\&source=editors\&ust=1783470052612119\&usg=AOvVaw01ebCfYrgxKVVlFAiVz2Gt) * RP-SMA to SMA adaptor: [ADP-RPSM-SMAF-G](https://www.google.com/url?q=https://www.digikey.com.au/en/products/detail/te-connectivity-linx/adp-rpsm-smaf-g/9826664\&sa=D\&source=editors\&ust=1783470052612446\&usg=AOvVaw1P_fetPPb64kjmAka6gAPD) * Shielded cable: [CCSMA-MM-086-18](https://www.google.com/url?q=https://www.digikey.com.au/en/products/detail/crystek-corporation/ccsma-mm-086-18/2683940\&sa=D\&source=editors\&ust=1783470052612700\&usg=AOvVaw3eyBq597D01ShGU0MY9HO_) ⚠️ Important: Ensure barrel attenuator is rated to handle the maximum output power of the device under test. For example, using a DUT that transmits at 30 dBm with an attenuator rated < 1 Watt (W) may result in damage or degraded performance, and should be avoided. Recommended 2W barrel attenuator: BW-S20W2+ (minicircuits) ### Measuring Cable Loss To obtain accurate TX power and RX sensitivity measurements, it is essential to compensate for cable loss between the DUT and the LitePoint tester. The recommended method is to use a Vector Network Analyzer (VNA) to perform an S21 (insertion loss) test. Taking the block diagram from the previous section, the LitePoint and the HaLowLink 1 have been disconnected, and the exact same RF cables—including any intermediate connections or shielded enclosures—are instead connected to a calibrated VNA. This ensures that the measured path loss accurately reflects the real test configuration. Then, an S21 test will characterize the insertion loss across the frequency range of interest and can be used to inform and compensate future measurements. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/1yDjO6NiJHzIUj6UwhVg/Unknown%20image) Figure 18. Block diagram of a path loss measurement with a VNA. *** ### LitePoint #### LitePoint Firmware Version The LitePoint firmware version can be checked by navigating to the LitePoint web Graphical User Interface (GUI), and clicking the Admin → Information tab. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/elTv8ZFugGJn8An8DoiI/Unknown%20image) Figure 19. How to view firmware versions in the LitePoint GUI. The “Instrument SW Version” field indicates the firmware version. As stated earlier, it is recommended to check with LitePoint support that this version remains up to date. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/uiHcLnbz2ewTL39GrQZ6/Unknown%20image) Figure 20. Information tab within the LitePoint GUI. *** #### Inputting External Attenuation (Optional) The LitePoint tester allows users to manually input path loss values to compensate for external attenuation in the RF setup. This adjustment affects only power-related measurements, such as TX output power and RX sensitivity. First, click on the Tools → Port Routing tab. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/dQV54zJOxFZKgQPwyiic/Unknown%20image) Figure 21. Port routing tab within LitePoint GUI. Then, click on the PathLoss Info tab from the window that pops up. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/RmRDU6qZpKreoX5V7JKg/Unknown%20image) Figure 22. Where to configure path loss in the LitePoint GUI. *** Users are presented with the following interface. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/xFyJ7gIebmkAADjOz1cG/Unknown%20image) Figure 23. Blank path loss information within the LitePoint GUI. Begin by setting a “Table Name” for the path loss profile. Then, enter the relevant frequencies (in MHz) and their corresponding correction values (in dB) into the table. For example, if the measured path loss is 11.2 dB at 920 MHz and 11.3 dB at 924 MHz, enter these as separate rows. Once the data is populated, assign the correction table to specific LitePoint ports by selecting the appropriate checkboxes for the desired VSG and/or VSA paths, then clicking Apply. Note: This step must be repeated for each port requiring path loss compensation. In the example below, corrections of the name “Example” are applied to port RF1A for both the VSA and VSG. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/hebfxBU4h5agEYqD6cfS/Unknown%20image) Figure 24. Example path loss inputs for 920 and 924 MHz. Optionally, these settings can also be saved and applied later from the Load and Save buttons. ### RF Tester Software The RF Tester software is a GUI application developed by Morse Micro to support engineers conducting RF measurements. It provides a point and click interface to do the following: * Connect to a DUT. * Set radio parameters such as Bandwidth, Channel, MCS rate etc. * Start/Stop transmitting or receiving packets. * Retrieve the RPG statistics. * Clear the RPG statistics for isolated testing. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/8XKNA59zlFyazioj41cI/Unknown%20image) Figure 25. RF Tester software initial screen. Access to this software is restricted. To obtain access, please contact your Morse Micro representative. *** ## 5 Performing HaLow Measurements ### Transmit Tests To perform TX tests, configure the LitePoint port as a Vector Signal Analyzer (VSA). First, click Technology → WiFi SISO. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/ZZ6VgWvptsq0pXNQCbgP/Unknown%20image) Figure 26. WiFi SISO menu within the LitePoint GUI. Next, click the dots below “LED STATUS”. Then set the port being used to VSA. In this case, RF1A. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/W0lLdX09xGJvWKP5FNmM/Unknown%20image) Figure 27. How to configure the LitePoint port as a VSA. Next the results can be set up to measure the parameters of interest. Click the Results tab, and then drag the options of interest to the empty windows to the right. In this example, the Spectrum, TX Quality OFDM, Spectrum Mask Margins, and Spectral Flatness OFDM tabs are chosen. These give all of the main parameters mentioned in the Key Measurement Metrics section. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/JoANRgf8xMfC4Ms2GXdw/Unknown%20image) Figure 28. Results tab showing different measurement options available. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/3NT7nBAa8uxrqr7LsXtw/Unknown%20image) Figure 29. Example layout with 4 different result tabs open. Next, the user should navigate to the Hardware tab and expand the VSA Settings dropdown. This is where the center frequency is configured to match the transmission frequency of the DUT. The reference level can also be set in this section to optimize signal capture. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/vCtBar9nPsYroEF8u3rB/Unknown%20image) Figure 30. VSA settings menu within the LitePoint GUI. It is also recommended to set the “Symbol Clock Correction Type” to “TIME” in order to achieve best EVM results. This can be found and set in the Settings tab, under the OFDM menu. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/14XOPX5LIGdjssMmydrQ/Unknown%20image) Figure 31. Setting the Symbol Clock Correction Type parameter. Once the settings are confirmed, the Continuous Analysis button can then be clicked to begin continuous measurement acquisition. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/3ty0Wp5Kr3eL3oJZo5bW/Unknown%20image) Figure 32. Continuous analysis button to take measurements. Next, the DUT can be configured through the RF Tester. The first step is to establish a connection to the DUT, then configure the desired radio parameters such as bandwidth and MCS rate. Transmission can then be initiated by clicking the “Start” button. In this example, the DUT is transmitting an 8 MHz, MCS 0 signal at 924 MHz. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/SCR8mLmpvO1iOF8kK4hj/Unknown%20image) Figure 33. RF Tester configuring the DUT to transmit. This signal and associated measurements can then be seen on the LitePoint. The Automatic Gain Control (AGC) button may need to be pressed to set a sensible reference level. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/RPG9oOSKit950CgL0AiY/Unknown%20image) Figure 34. AGC button in the LitePoint GUI. ### Receive Tests To perform receive tests, the LitePoint needs to be configured as a Vector Signal Generator (VSG). To do this, click the two dots below “LED Status” again, and set the port being used to VSG instead of VSA. The VSG menu can then be clicked on the left hand side to open the VSG settings. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/jOsgwMvjgysKRbPZ1PXK/Unknown%20image) Figure 35. How to configure the LitePoint port as a VSG. In this example, the LitePoint is set to transmit on 924 MHz at -20 dBm. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/KrCtbhfu9d9Nf57fuAwH/Unknown%20image) Figure 36. VSG setting menu. Next, the waveform to transmit needs to be selected. This can be done through the Waveforms tab. Here, the Load button is used to select an 8 MHz, MCS0 waveform from the LitePoint memory. Please contact your Morse Micro representative for access to Wi-Fi HaLow example waveforms. Then, a count of 1000 packets is set. Ensure Wave and RF(on) are selected. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/hNLChTZflKyrdkwzmdRt/Unknown%20image) Figure 37. Waveforms menu used to set the parameters of the signal to be transmitted. The channel bandwidth must next be set on the LitePoint. This can be done through the Settings → Technology Module tab. This must match the bandwidth to be transmitted. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/CUgd6ueabV0sm8O0esbr/Unknown%20image) Figure 38. Applying channel bandwidth settings. Next, the DUT can be prepared through the RF Tester. Connect to the DUT, and set the radio parameters that match the waveform to be transmitted by the VSG. After that, the “RX” radio button should be selected, followed by clicking “Start” to set the device into receive mode on the specified channel. It is recommended to click “Clear Stats” before beginning transmission to ensure accurate measurement results. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/T27TsMU2A4znQAhqFHzm/Unknown%20image) Figure 39. Preparing the RF Tester to receive packets. Next, the Play button on the LitePoint can be pressed to begin waveform transmission. The packet count will decrement in real time as packets are transmitted. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/uheNfmDTF4Fs3rK6KSGT/Unknown%20image) Figure 40. Instructing the LitePoint to transmit the loaded waveform. Once all packets have been transmitted, the user can use the RF Tester to retrieve the statistics. In this example, the RX Passed statistic shows 1000 packets, resulting in a PER of 0%. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/nsyAMJOULcqqUDVobXdT/Unknown%20image) Figure 41. Example RX measurement showing 0% PER in the RF Tester. It is important to note that RX Count represents the number of packets for which the header was successfully decoded, whereas RX Passed indicates packets where both the header and payload were correctly decoded. For PER calculations, only RX Passed should be used. *** ## 6 Glossary | Abbreviation | Full Term | Description / Context | | ------------ | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | RF | Radio Frequency | Refers to electromagnetic wave frequencies used in wireless communication. | | VST | Vector Signal Transceiver | Test equipment capable of both signal generation and analysis with magnitude and phase information. | | TX | Transmit / Transmission | The process of sending RF signals from a device. | | RX | Receive / Reception | The process of receiving RF signals by a device. | | DUT | Device Under Test | The hardware unit being tested in RF measurements. | | RPG | Random Packet Generator | A test mode where the DUT transmits random packets without establishing a full connection. | | FAE | Field Application Engineer | Technical specialist providing customer support and guidance on engineering products. | | EVM | Error Vector Magnitude | A key RF metric measuring the modulation accuracy of a signal. | | SEM | Spectrum Emissions Mask | Defines maximum allowed signal power at various frequency offsets from the carrier. | | SF | Spectral Flatness | Measures how evenly power is distributed across all subcarriers in an OFDM signal. | | LO | Local Oscillator | Refers to the signal generator inside the RF system; leakage is an unwanted emission at the carrier frequency. | | PER | Packet Error Rate | The ratio of incorrectly received packets to total packets sent, used to evaluate communication reliability. | | PPM | Parts Per Million | Unit for expressing small frequency variations or tolerances. | | Hz | Hertz | Unit of frequency, indicating cycles per second. | | dB / dBm | Decibel / Decibel-milliwatts | Logarithmic units for expressing signal strength or power level. | | OFDM | Orthogonal Frequency-Division Multiplexing | A modulation scheme used in Wi-Fi and other communication standards. | | MCS | Modulation and Coding Scheme | Defines data rates and robustness in Wi-Fi standards. | | PHY | Physical Layer | The lowest layer in the OSI model, responsible for raw bit transmission over a physical medium. | | BCF | Board Configuration File | A configuration file defining DUT-specific settings for RF testing. | | PA | Power Amplifier | A component that amplifies the RF signal before transmission. | | IQ | In-phase and Quadrature | The two components of a modulated RF signal used to carry information. | | DC | Direct Current | In this context, refers to DC offsets that may distort RF signals. | | AGC | Automatic Gain Control | A feature that adjusts the receiver gain to maintain optimal signal levels. | | VSA | Vector Signal Analyzer | Equipment for analyzing both the amplitude and phase of incoming RF signals. | | VSG | Vector Signal Generator | Equipment that generates modulated RF signals with defined amplitude and phase. | | GUI | Graphical User Interface | A user interface that allows interaction with electronic devices through graphical icons. | | SNR | Signal-to-Noise Ratio | A metric expressing how much stronger a signal is compared to background noise. | | S21 | Scattering Parameter 21 | A measurement of forward transmission gain or loss in a network (used in VNAs). | | VNA | Vector Network Analyzer | Test equipment used to measure S-parameters, especially insertion and return loss. | | USL | Upper Specification Limit | The maximum allowable value of a measured parameter as defined by design or regulatory specifications. | | PVT | Process Voltage Temperature | A reliability and performance verification method that evaluates a device across variations in semiconductor manufacturing process, supply voltage, and operating temperature. | *** ## 7 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | ---------------- | | 01 | 27/06/2025 | Initial release. | # APPNOTE-45 MM IoT SDK Porting Guide Version 1 [Download as PDF](https://www.morsemicro.com/resources/appnotes/MM_APPNOTE_45_MM_IoT_SDK_Porting_Guide.pdf) ## Introduction ### Who this guide is for This guide is for embedded firmware engineers porting the `mm-iot-sdk` to a microcontroller that Morse Micro does not officially support. To follow this guide, you should be comfortable with: * Embedded C and your target’s toolchain and debugger; * Driver-level programming of SPI or SDIO, GPIO interrupts, and DMA on your host; * Basic RTOS concepts (for example, FreeRTOS tasks, queues, and semaphores); * A C build system such as CMake or GNU Make; and * The software environment that comes with your host. You can complete a port without prior knowledge of HaLow, Wi-Fi, or Morse Micro transceivers. ### What this guide covers (and what it doesn’t) This guide helps you do the following using `mm-iot-sdk-2.11.2`: * Check you have a suitable hardware platform, including CPU speed, memory capacities, and peripherals; * Structure your porting code to prepare for future changes and upgrades to the `mm-iot-sdk`; * Implement the necessary HALs; and * Verify behavior and performance at each step. If you have not yet chosen a host chip, a communication protocol, or a Morse Micro transceiver, start with a [supported platform](https://morsemicro.github.io/mm-iot-sdk/framework/doc/html/MMPLATFORMS.html), and iterate on it. For example, Morse Micro offers two variants of the [EKH05 IoT Development Board](https://www.morsemicro.com/evaluation-kits/), one with each of our chips: [MM6108](https://www.morsemicro.com/resources/product_brief/MM6108-Product-Brief.pdf) and [MM8108](https://www.morsemicro.com/resources/product_brief/MM8108-Product-Brief.pdf). These boards come with an STM32U585 MCU host connected via SPI to the Morse Micro transceiver, but can be modified to use SDIO (see the user guides in our [customer portal](https://www.morsemicro.com/downloads-dashboard/)). Morse Micro also provides platform ports for Zephyr, ESP32, and CMSIS. If you are using one of these platforms, see [MCU Platform Ports](https://github.com/MorseMicro#mcu-platform-ports) for more information. Porting the `mm-iot-sdk` to a new platform is only one part of creating your application. This guide provides advice where it can, but it does not cover: * The design and behavior of your application; * Application-specific tradeoffs, such as whether a more capable platform justifies its higher cost; or * Acceptable performance targets (for example, a battery-powered device may tolerate lower throughput if it improves power consumption). Additionally, this guide will not cover porting for versions of the `mm-iot-sdk` earlier than 2.11.2. ### Terminology This guide uses the following terms to avoid confusion: * **Host**: your MCU. The host runs your application and boots the transceiver. * **Transceiver**: the Morse Micro HaLow transceiver that the host communicates with over SPI or SDIO. * **Platform**: either the hardware your application runs on (for example, the EKH05 IoT Development Board), or the broader ecosystem of build system, operating system, drivers, and hardware (for example, a Zephyr platform port). Where the distinction matters, this guide uses **hardware platform** or **platform port**. This guide avoids the term **chip** on its own. The host, the transceiver, and other peripherals such as QSPI flash are all chips, so the term is ambiguous. This guide uses **host**, **transceiver**, or the specific peripheral name instead. ### What “porting” means Porting the `mm-iot-sdk` means making it build, run, and communicate with a Morse Micro transceiver on a host platform that Morse Micro does not provide as a reference. In practice, this involves work across the following layers: * **Build integration**: Create the build scripts, such as Makefiles, and project files for building your application and platform. * **Operating system**: Create the porting layer for your operating system’s primitives, such as tasks, semaphores, and timers. * **Peripherals and communications**: Implement the GPIO, interrupt handling, and communications bus (SPI or SDIO) necessary to interact with the Morse Micro transceiver. The process of porting moves through the tiers of completeness: 1. **Communicates with the Morse Micro transceiver**: the port passes the basic bring-up tests and exchanges messages with the transceiver. Verified by the `porting_assistant` example application. 2. **Reads incoming networking traffic**: the port can read beacons. Verified by the `scan` example application. 3. **Passes network traffic**: the port can transmit and receive traffic from other 802.11ah transceivers. Verified by the `iperf` example. 4. **Optimized for target application**: the port meets the performance requirements of the target application, such as data throughput or power consumption. Verified by your application running successfully; this guide uses `iperf` and other examples as a proxy for your application. This guide helps you work through each tier. ### How to use this guide Read the guide from start to finish. Each section builds on the previous sections: 1. [Requirements](#requirements) helps you check that your hardware and software platform is sufficient for a port. 2. [Porting context](#porting-context) helps you form a high-level view of the parts of a port. 3. [The MM-IoT-SDK](#the-mm-iot-sdk) shows you how to bring the `mm-iot-sdk` into your project. 4. [Porting process](#porting-process) steps through completing the port: the OSAL, the bus driver, build integration, and bring-up verification. Use [Troubleshooting](#troubleshooting) as a reference when something does not work, rather than reading it front to back. Before you start creating the software port, you should have: * Your host development board, debugger, and toolchain set up and building a known-good “hello world” for the target. * Your host platform connected to your Morse Micro transceiver (an evaluation board or module) via SPI or SDIO and the necessary GPIOs. * A copy of `mm-iot-sdk` at the version this guide references (see [Requirements](#sec-requirements)). This guide uses the following typographic conventions: * `monospace` for file paths, directory names, function names, and shell commands. * `monospace` for `mm-iot-sdk` example applications such as `iperf` (as opposed to iPerf, the application `iperf` originates from). * **Code block** ``` Code blocks for multi-line code ``` If you get stuck on something this guide does not cover, ask a question in the [Community Forum](https://community.morsemicro.com/). ## Requirements This part of the guide describes the hardware required and software obligations you must meet to port the `mm-iot-sdk` successfully. ### Hardware components #### Transport bus There are two types of transport bus available for communication with Morse Micro transceivers: * [SPI](https://en.wikipedia.org/wiki/Serial_Peripheral_Interface) * [SDIO](https://en.wikipedia.org/wiki/SD_card#SDIO_cards) Implement the HAL for one of these bus types, not both. Morse Micro has found that porting to SDIO tends to be more straightforward because although the SDIO is more complex, SPI host controllers vary widely in behavior. For more information, see [Bus transport details](#sec-bus-transport-details). Note, the `mm-iot-sdk` does not support sharing the transport bus with other peripherals. #### GPIO pins The host microcontroller requires several GPIO pins to interface with the Morse Micro transceiver. See [Table 1: GPIO pin for host microcontroller](#tab:gpio-pins-on-host) and [Figure 1: GPIO lines required for SPI vs SDIO](#fig:SDIO-SPI-GPIO-lines). **Table 1: GPIO pin for host microcontroller**
MM Transceiver Pin NameData DirectionFunction
BUSYTransceiver → HostPrevents host from sleeping. The host microcontroller must configure this pin as an input that fires an interrupt on a rising edge.
WAKEHost → TransceiverPrevents transceiver from sleeping. This can be permanently set HIGH* until you need to optimize power consumption for your application.
RESET_NHost → TransceiverLOW signal resets the transceiver. Equivalent to a cold boot.
SPI_IRQTransceiver → HostSPI only. Indicates the host should read data from the transceiver. The host must configure this pin as an input that fires an interrupt on a falling edge.
CSSHost → TransceiverSPI only. Software-controlled chip select. Lets the host send a clock training sequence to the transceiver.
* See the important note below.
**Sleep disable note** **Important**\ Your port must call `mmwlan_set_sleep_mode(MMWLAN_SLEEP_DISABLE)` after booting the transceiver, even when WAKE is held permanently HIGH. Otherwise the driver fails to boot.\ See the SPI host requirement or SDIO host requirement section in your transceiver’s datasheet for detailed schematics, electrical, and timing requirements. **Figure 1: GPIO lines required for SPI vs SDIO** ![diagrams-SDIO-SPI-GPIO](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/Bp8n0npU2jzowE7kKzzA/assets/diagrams-SDIO-SPI-GPIO.png) #### Morse Micro transceiver There are two Morse Micro transceivers. Review each datasheet to choose the best transceiver for your application. **Table 2: Available transceivers and associated datasheets** | **Morse Micro transceiver** | **Datasheet** | | --------------------------- | ---------------------------------------------------------------------------------- | | MM6108 | [MM6108 datasheet](https://www.morsemicro.com/download/mm6108-data-sheet/) | | MM8108 | [MM8108 datasheet](https://www.morsemicro.com/download/mm8108-mf15457-data-sheet/) | #### Required memory The `mm-iot-sdk` operates as a SoftMAC, so your host platform is responsible for loading firmware and a BCF onto the Morse Micro transceiver, and for hosting `morselib` — both its code and its runtime RAM. We recommend your porting platform has at least: 1. $`\geq2`$ megabytes of flash memory. 2. $`\geq256`$ kilobytes of SRAM, to support the needs of `morselib` at runtime. These figures are not necessarily the upper or lower limits for your final product, but starting with a platform that comfortably supports debugging builds will make the porting effort more straightforward. See [Flash and RAM requirements explained](#sec:flash-ram-requirements-explained) for the reasoning behind these numbers. ### Recommended host peripherals 1. A PKA cryptographic peripheral to accelerate ECC operations. This shortens association time and reduces RAM usage during cryptographic operations. 2. A random number generator on the chosen platform. ## Porting context The `mm-iot-sdk` operates as a SoftMAC: Morse Micro-supplied firmware running on the transceiver handles the LMAC and PHY, while the UMAC runs in the firmware you build for your host. Your application communicates with the transceiver via the `morselib` driver, provided by Morse Micro. To run `morselib` on your host, you must implement the functions it depends on. Before you write any port code, identify which pieces of the stack you implement and which Morse Micro provides. [Figure 2: Porting context map. Purple boxes are the components you implement; everything else is provided by Morse Micro or by your existing software stack.](#fig:porting-context-map) maps a typical `mm-iot-sdk` application onto the host and the Morse Micro transceiver. The purple boxes — the OSAL, GPIO layer, communications bus driver, and possibly an IP stack driver — are the components **you implement** during the port. `morselib`, the transceiver firmware, and the example applications are provided by Morse Micro. **Figure 2: Porting context map. Purple boxes are the components you implement; everything else is provided by Morse Micro or by your existing software stack.** ![diagrams-ContextMap](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/JjIpXwe6QNiip0IcUSqy/assets/diagrams-ContextMap.png) ### Validating the port with example applications The `mm-iot-sdk` ships with example applications that you run on the host to verify successively larger slices of the stack. Each one exercises a different range of components, as shown in [Figure 3: Validation spans of the example applications. Each application exercises progressively more of the stack, from the host-side porting components alone (`porting_assistant`) up to full end-to-end traffic (`iperf`).](#fig:example-applications-map): * `porting_assistant` validates the host-side components you write during the port: the OSAL, GPIOs, and communications bus. It does not require a working transceiver link. * `scan` validates basic WLAN integration — that the host can boot and use the transceiver. * `iperf` validates the full end-to-end data path. **Figure 3: Validation spans of the example applications. Each application exercises progressively more of the stack, from the host-side porting components alone (`porting_assistant`) up to full end-to-end traffic (`iperf`).** ![diagrams-ApplicationExamples](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/mLgEmu6flMPKnu0BOXZk/assets/diagrams-ApplicationExamples.png) ## The MM-IoT-SDK ### Overview of the MM-IoT-SDK The `mm-iot-sdk` includes example applications and libraries, the Morse Micro driver, and the supported platforms. It also includes firmware for each Morse Micro transceiver, BCF files for some common modules, and the UMAC code. The Morse Micro driver and essential HaLow libraries are called `morselib`. This component is what manages communication with the transceiver. When porting the `mm-iot-sdk` to your own platform, the following components are required: * `morselib` - the core Morse Micro UMAC and driver library; * `firmware` - the Morse Micro transceiver firmware and BCF; * `mmpktmem` - a library for allocating and managing packet memory used by `morselib`; * `mmregdb` - the Wi-Fi HaLow regulatory database; * `mmutils` - a library of helper utilities. Most applications interact with the transceiver via a TCP/IP-capable network stack running on the host. You may provide your own network stack, or use the `lwip` component provided in the `mm-iot-sdk`. This guide uses four example applications as you progress through the porting process; porting assistant, scan, and iPerf. These example applications rely on components which aren’t strictly required for your application. They include: * `mmipal` - the `mm-iot-sdk`’s abstraction over networking and TCP/IP, as well as an `lwip` driver; * `mmconfig` - the `mm-iot-sdk`’s configuration management library; * `mmlog` - the `mm-iot-sdk`’s logging helper library; * `mmiperf` - the `mm-iot-sdk`’s iPerf implementation, with an abstraction layer for extension to other network stacks; #### Morse Micro UMAC and driver library — morselib The Upper MAC in this library implements the Wi-Fi HaLow protocol. It provides functions for converting 802.3 frames into 802.11 data packets, building 802.11 management frames, and managing the state of the Wi-Fi stack. The driver included in this library is a platform-agnostic implementation of the protocol used to communicate with the Morse Micro transceiver. To remain platform-agnostic, you must implement a small number of hardware abstraction layers. These include SPI communication functions, GPIO handlers, operating system primitives and more. `morselib` has dependencies on `hostap` and `mbedtls`, included in the `mm-iot-sdk`. #### Morse Micro transceiver firmware binaries — firmware To boot the Morse Micro Wi-Fi HaLow transceiver, the host-side driver code loads two binaries onto the transceiver: the transceiver firmware itself and the BCF. The `mm-iot-sdk` provides both of these files in a `.mbin` format (see `mm-iot-sdk/framework/morsefirmware`). Module vendors provide BCFs in a `.bin` format. Both formats carry the same information, but the `.mbin` is a compressed format designed to reduce flash memory requirements on MCU hosts. You must convert these to `.mbin` before your application can load them onto the transceiver. See [Converting .bin to .mbin](#sec:converting-bin-to-mbin) for instructions on how to perform a conversion. During porting, you provide the functionality that lets `morselib` read these binaries. #### Morse Micro packet memory — mmpktmem `mmpktmem` provides platform-agnostic memory handling to support the transmitting and receiving of packets. This library provides two implementations that can be used by `morselib` - one using heap memory, and the other using statically allocated memory. You must choose one for your platform. #### Morse Micro regulatory database — mmregdb Regulatory restrictions vary globally for Wi-Fi HaLow. The `mmregdb` defines the operating channels, bandwidths, and maximum power limits for each supported region. The BCF provided to you by your module vendor enforces these restrictions. The regulatory database may include more information than provided by your BCF. Contact your module manufacturer for specific details. No implementation is required from you to include this component in your port. #### Morse Micro utilities — mmutils The helper utilities in `mmutils` parse common elements in beacons and other Wi-Fi management frames. These elements include RSN information, vendor elements, and the S1G operation fields. No implementation is required from you to include this component in your port. #### MM-IoT-SDK contents and structure HTML documentation for the `mm-iot-sdk` is included with each release. The documentation for the latest release can be viewed at [Morse Micro IoT SDK Documentation](https://morsemicro.github.io/mm-iot-sdk/framework/doc/html/index.html). **Table 3: `mm-iot-sdk` package structure** | **Path** | **Description** | | ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------- | | `applications/` `examples/` | Example applications. | | `framework/doc/` | HTML documentation, including Getting Started Guide and API documentation. | | `framework/mk/` | Makefile fragments. | | `framework/morsefirmware/` | Firmware and BCF files for supported Morse Micro transceiver modules. | | `framework/morselib/` | The core part of the SDK. Contains the UMAC and driver. | | `framework/morselib/include/` | Contains the definitions of the core APIs that `morselib` relies on. Part of the porting work is implementing the functions defined in these APIs. | | `framework/src/` | Contains the supporting software components and middleware. | | `framework/src/hostap/` | HostAP project with modifications to support HaLow. | | `framework/src/lwip/` | LwIP project with modifications to improve HaLow performance. | | `framework/src/platforms/` `framework/src/bsps/` | Platform-specific code. Includes microcontroller BSP code, HAL shims, and the OSAL shim. | | `framework/tools/` | Tools that run on your computer to support development and debugging. | ## Porting process To complete a port, we recommend you follow this process: 1. Integrate the `mm-iot-sdk` components into your build system 2. Compile and run PA 1. Implement the OSAL 2. Implement the communication HAL 3. Implement the BCF and firmware collectors 3. Compile and run Scan to test more of the UMAC functionality. 4. Compile and run iPerf to test an application with a full network stack and get a throughput benchmark This moves you through the tiers of completeness outlined in [What “porting” means](#sec-intro-porting-spectrum), and gives you confidence that your port is working correctly at each stage of the process. ### Build integration **Goal**: Integrate the `mm-iot-sdk`, the example applications and your platform with your build system.\ **Success**: You can use your build system to compile and link example applications against the `mm-iot-sdk` using a stub implementation of your platform, and can flash the binary image produced to your host. Command examples in this guide assume the `mm-iot-sdk` Makefile-based system. Adapt them if you use a different build system. #### Integrate the MM-IoT-SDK We recommend you: 1. Implement your application and platform build system so it uses the `MMIOT_ROOT` environment variable to refer to `mm-iot-sdk` components. This lets you move the `mm-iot-sdk` to wherever is most convenient on your filesystem. 2. Create a version-controlled copy of the `mm-iot-sdk` source code in your project directory. This approach helps you: 1. Switch between versions of the `mm-iot-sdk` to upgrade or compare features. 2. Apply and track patches to your copy of the `mm-iot-sdk`. 3. Keep your application logic, your platform SDK, and the `mm-iot-sdk` separate, which can help with support. A recommended project structure is shown in [Figure 4: Recommended project structure: `mm-iot-sdk` outside your project directory](#dir:mm-iot-sdk-setup-reference-external). **Figure 4: Recommended project structure: `mm-iot-sdk` outside your project directory** ``` YOUR_REPOSITORY/ third_party/ mm-iot-sdk-/ your_application/ Makefile include/ src/ targets/ your_port/ mm_shims/ bsp/ platform.mk ``` We strongly recommend that you do **not** place your project inside the `mm-iot-sdk` directory, as shown in [Figure 5: Not recommended project structure: your project inside the `mm-iot-sdk` directory](#dir:mm-iot-sdk-containing-project). Making direct edits to the `mm-iot-sdk` prevents you from switching versions easily and blurs the line between platform and application. **Figure 5: Not recommended project structure: your project inside the `mm-iot-sdk` directory** ``` mm-iot-sdk-/ applications/ framework/ LICENSES/ examples/ iperf/ scan/ … your_project/ Makefile src/ include/ ``` #### Create a platform stub First, create a stub of your platform port for your host. This guide assumes you have: * Copied an example platform stub from the `mm-iot-sdk` into your project, or * Based your platform on the porting-stubs repository provided as a companion resource to this guide (see [Porting Stubs Repository](#sec-porting-stubs-repository) for more information), or * Created your platform in a way that you are familiar with. This guide also assumes you have created a directory structure as shown in [Figure 6: Assumed platform with `mm_shims` and `bsp` structure.](#dir:platform-bsp-and-shims), and that your platform specific files are part of the BSP defined in the `./bsp` directory. **Figure 6: Assumed platform with `mm_shims` and `bsp` structure.** ``` your_port/ mm_shims/ bsp/ platform.mk ``` Creating the `bsp` folder content depends on your platform; consult your platform’s documentation. It will involve configuring host clocks, choosing and configuring peripherals. This guide **cannot** provide guidance on these steps. The result should be a set of C files that provide platform drivers and configuration, plus a `main` function that initializes the platform and then calls `mmosal_main(app_init)`. See the `mm-iot-sdk` example platforms for reference. [The Porting Assistant](#sec-the-porting-assistant) walks you through implementing the functions in the `mm_shims` directory (where most of your port will be). You will likely also modify the `bsp` files to provide the required functionality. #### Build your platform stub Once you have created your platform stub and integrated the `mm-iot-sdk` with your build system, you should be able to build an example application for your platform. Use this command: **Compile** ``` make -C applications/porting_assistant \ MMIOT_ROOT=./third_party/mm-iot-sdk-/framework \ TARGET=targets/your_port ``` This command will: * Compile all of the necessary object files from their source, and * Link the object files to produce a binary image (an ELF file). You should be able to program and run that stub application on your host. **Program to your host** ``` openocd -c "set MM_PROGRAM 1" \ -f targets/your_port \ -c "program applications/porting_assistant/porting_assistant.elf verify reset exit" ``` If you can compile the ELF and program it to your platform you have completed this step. The application is not expected to run at this stage. ### The Porting Assistant The Porting Assistant is an example application in the `mm-iot-sdk` that performs a series of tests to validate that the basic functionality of your port is working. This guide uses it to step through the process of doing the port. The steps are: 1. The Porting Assistant compiles and runs on your platform. 2. The OSAL tests pass. 3. The communications HAL tests pass. 4. The firmware and BCF tests pass. #### Compiling on your platform **Goal**: Your port has the implementations allowing the `porting_assistant` to execute tests and to output the results to a serial port.\ **Success**: The `porting_assistant` runs on your platform, and outputs the failure for all tests. At the end of this step, your serial output should be similar to below. **Captured Serial output of Porting Assistant application - Compile** ``` MM-IoT-SDK Porting Assistant ---------------------------- HW Version: MM-MM8108-EKH05 morselib version: 2.11.2 ---------------------------- Memory allocation [ FAIL ] Memory reallocation [ FAIL ] Passage of time [ FAIL ] Task creation and preemption [ FAIL ] WLAN HAL initialization Hard reset device SDIO/SPI Startup [ FAIL ] Read chip id from the MM chip [ FAIL ] Verify BUSY pin [ FAIL ] Bulk write/read into the MM chip [ FAIL ] Raw throughput test [ FAIL ] Validate MM firmware [ FAIL ] Validate BCF [ FAIL ] ``` The Porting Assistant application consists of 6 source files and 5 header files. 1. `chip_cfg.c` 2. `chip_cfg.h` 3. `config.h` 4. `log.h` 5. `porting_assistant.c` 6. `porting_assistant.h` 7. `sdio_spi.c` 8. `sdio_spi.h` 9. `test_os.c` 10. `test_wlan_fw_bcf.c` 11. `test_wlan_io.c` Follow these steps: 1. Implement `mmhal_log_write`() so that the Porting Assistant can output results to a serial terminal. 2. Provide a function stub for all functions that fail to link. We advise putting `ASSERT(false)` calls inside the stubs to understand the call hierarchy at runtime. Your Porting Assistant example should now compile. Flash the compiled output to your platform and verify you see the output via a serial port. #### Operating system abstraction layer **Goal**: Your port implements the OSAL functions for memory management and basic operating system dependencies.\ **Success**: The Porting Assistant passes the OSAL tests. All other tests fail. At the end of this step, your serial output should be similar to below. **Captured Serial output of Porting Assistant application - OSAL** ``` MM-IoT-SDK Porting Assistant ---------------------------- HW Version: MM-MM8108-EKH05 morselib version: 2.11.2 ---------------------------- Memory allocation [ PASS ] Memory reallocation [ PASS ] Passage of time [ PASS ] Task creation and preemption [ PASS ] WLAN HAL initialization Hard reset device SDIO/SPI Startup [ FAIL ] Read chip id from the MM chip [ FAIL ] Verify BUSY pin [ FAIL ] Bulk write/read into the MM chip [ FAIL ] Raw throughput test [ FAIL ] Validate MM firmware [ FAIL ] Validate BCF [ FAIL ] ``` The porting assistant tests the OS functionality that `morselib` requires: threads, timers, and memory allocation. **Table 4: OSAL functions tested** | **Test** | **Associated function** | | ---------------------------- | ----------------------- | | Memory allocation | `mmosal_malloc_()` | | Memory reallocation | `mmosal_realloc_()` | | Passage of time | `mmosal_get_time_ms()` | | Task creation and preemption | `mmosal_task_create()` | If you are using FreeRTOS for your OS, you can use the `mm-iot-sdk` FreeRTOS OSAL implementation, `mmosal_shim_freertos.c`. Confirm your FreeRTOS version matches the one provided in the `mm-iot-sdk` (v11.2). Otherwise, refer to the FreeRTOS OSAL to understand how to implement the OSAL for your chosen OS. All of the functions in `mmosal.h` and `mmhal_os.h` must be implemented, however note that not all of these functions are tested in the Porting Assistant. #### Communications bus hardware abstraction layer **Goal**: Your port implements the configuration for your communications bus peripheral and implements the HAL functions for communications.\ **Success**: The Porting Assistant passes the OSAL tests and the communications HAL tests. The firmware and BCF validation tests fail. You must have a host that is physically connected to a Morse Micro transceiver for this step. At the end of this step, your serial output should be similar to below. **Captured Serial output of Porting Assistant application - communications HAL** ``` MM-IoT-SDK Porting Assistant ---------------------------- HW Version: MM-MM8108-EKH05 morselib version: 2.11.2 ---------------------------- Memory allocation [ PASS ] Memory reallocation [ PASS ] Passage of time [ PASS ] Task creation and preemption [ PASS ] WLAN HAL initialization Hard reset device SDIO/SPI Startup [ PASS ] Read chip id from the MM chip [ PASS ] Verify BUSY pin [ PASS ] Bulk write/read into the MM chip [ PASS ] Raw throughput test [ PASS ] Validate MM firmware [ FAIL ] Validate BCF [ FAIL ] ``` The communications HAL allows `morselib` to control the selected Morse Micro transceiver. This includes the GPIO lines, RESET, WAKE, BUSY, SPI\_IRQ, as well as the communications protocol (SPI or SDIO). The test and its associated functions are listed in the table below. **Table 5: communications HAL Tests** | **Test** | **Associated functions** | | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | WLAN HAL Initialization | `mmhal_wlan_init()` | | Hard reset device | `mmhal_wlan_hard_reset()` `mmhal_wlan_assert_reset()` | | Verify BUSY pin | `mmhal_wlan_busy_is_asserted()` | | SDIO/SPI Startup |

Implement SPI or SDIO, not both
SDIO

| | Read chip id from the MM chip | `mmhal_wlan_sdio_startup()` `mmhal_wlan_sdio_cmd53_write()` `mmhal_wlan_sdio_cmd53_read()` `mmhal_wlan_sdio_cmd` | | Bulk write/read into the MM chip |

SPI
mmhal\_wlan\_send\_training\_sequence() mmhal\_wlan\_spi\_cs\_assert() mmhal\_wlan\_spi\_cs\_deassert()

| | Raw throughput test | `mmhal_wlan_spi_write_buf()` `mmhal_wlan_spi_read_buf()` `mmhal_wlan_spi_rw()` | We recommend implementing the individual GPIO manipulation functions first. Test each one by calling its `assert/deassert` function from your application code while observing the pin on a logic analyzer. For the purposes of an initial port, the WAKE GPIO can be kept in a permanently high state. It will ensure that the chip can never sleep, or make use of powersave features. Morse Micro has implemented communications HALs for use with a selection of STM32 products. If you’re using an STM32 product, use the reference shims indicated in [Table 6: Supported STM32 platforms](#tab:supported-stm32-platforms) to create your communications HAL. Otherwise, refer to these implementations while writing your own. Please be aware that the reference shims include additional components (such as `mmconfig` and `littlefs`), which are not required to successfully complete your port. **Table 6: Supported STM32 platforms** | **MCU** | **`mm-iot-sdk` platform name** | | ----------- | ------------------------------------- | | STM32H753xx | `mm-ekh08-h753` | | STM32U575xx | `mm-ekh08-u575` | | STM32U585xx | `mm-mm6108-ekh05` / `mm-mm8108-ekh05` | | STM32WB55xx | `mm-ekh08-wb55` | The "Raw throughput test" sends bytes to the transceiver, which echoes them back to the host. On receiving the echoed bytes, the PA verifies that they match the bytes it transmitted. After completing successfully, the throughput test will provide a measure of how fast the transport bus is. Refer to [Porting Assistant completed](#completed-porting-assistant) for what the captured serial looks like for a complete Porting Assistant. Refer to [Porting Assistant benchmarks on supported platforms](#pa-benchmarks) to compare your platform’s performance against the officially supported platforms. #### BCF and firmware **Goal**: Your port provides the firmware and BCF to the transceiver.\ **Success**: The Porting Assistant passes all tests. At the end of this step, your serial output should be similar to below. **Captured Serial output of Porting Assistant application - BCF and Firmware** ``` MM-IoT-SDK Porting Assistant ---------------------------- HW Version: MM-MM8108-EKH05 morselib version: 2.11.2 ---------------------------- Memory allocation [ PASS ] Memory reallocation [ PASS ] Passage of time [ PASS ] Task creation and preemption [ PASS ] WLAN HAL initialization Hard reset device SDIO/SPI Startup [ PASS ] Read chip id from the MM chip [ PASS ] Verify BUSY pin [ PASS ] Bulk write/read into the MM chip [ PASS ] Raw throughput test [ PASS ] Validate MM firmware [ PASS ] Validate BCF [ PASS ] ``` Implement the functions in the table below to handle firmware and BCF files. **Table 7: BCF and Firmware tests** | **Test** | **Associated functions** | | -------------------- | ---------------------------- | | Validate MM firmware | `mmhal_wlan_read_fw_file()` | | Validate BCF | `mmhal_wlan_read_bcf_file()` | See `mmhal_wlan_binaries.c` for a reference implementation of these functions. The transceiver firmware and BCF files are provided in `mm-iot-sdk/framework/morsefirmware/` in an `mbin` format. The most direct way to provide these files is to convert the `mbin` files into C arrays and compile them into your application. **Convert `mbin` to C array** ``` xxd -i | sed 's/unsigned char/const unsigned char/' > ``` Another method to include the BCF in your application is to create an object file from the `.mbin` file and compile it with the other source files. Refer to `framework/mk/morsefirmware.mk` and the build define `INCLUDE_BCF_FILE_IN_APPLICATION` in the `mm-iot-sdk` to see how this works. #### Porting Assistant completed **Captured Serial output of Porting Assistant application - Fully completed** ``` MM-IoT-SDK Porting Assistant ---------------------------- HW Version: MM-MM8108-EKH05 morselib version: 2.11.2 ---------------------------- Memory allocation [ PASS ] Memory reallocation [ PASS ] Passage of time [ PASS ] Task creation and preemption [ PASS ] WLAN HAL initialisation Hard reset device SDIO/SPI Startup [ PASS ] Read chip id from the MM chip [ PASS ] Chip ID: 0x0306 Verify BUSY pin [ PASS ] Bulk write/read into the MM chip [ PASS ] Raw throughput test [ PASS ] Note: This will not be the final WLAN TPUT. See test step for more info. Time spent (ms): 2501 Transaction count: 2572 Bytes Transferred: 7695424 Raw TPUT (kbit/s): 24615 Validate MM firmware [ PASS ] Validate BCF [ PASS ] ``` #### Porting Assistant benchmarks on supported platforms **Table 8: Porting Assistant benchmarks on supported platforms**
Official PlatformTime Spent (ms)Transaction CountBytes TransferredRaw TPUT (kbit/s)
mm-mm6108-ekh0525012254674396821572
mm-mm8108-ekh0525012564767148824538
mm-mm8108-ekh05-sdio25011167034916640111688
### Scan Scan builds upon the previous success with the Porting Assistant by validating that the transceiver and UMAC control paths are functional. Scan works by sending a probe request to nearby access points, then captures the probe response and prints it to the serial terminal. For this example, you need access to another HaLow device that can act as an AP. Good examples include: * HaLowLink1 - [DigiKey](https://www.digikey.de/en/products/detail/morse-micro/MM-HL1-EXT/29272584) * HaLowLink2 - [DigiKey - AU Version](https://www.digikey.com.au/en/products/detail/morse-micro/MM-HL2-EXT-A-AU/29278689) * EKH01 - [DigiKey](https://www.digikey.com.au/en/products/detail/morse-micro/MM8108-EKH01-01/28007242) #### Build integration **Goal**: Compile an example application that uses Wi-Fi HaLow functionality.\ **Success**: The `scan` example builds without errors and is ready to flash to your platform. To compile the `scan` application, run this command: **Compile** ``` make -C applications/scan MMIOT_ROOT=./third_party/mm-iot-sdk-/framework TARGET=targets/your_port ``` Follow these steps: 1. Set `COUNTRY_CODE` to your region in `mm_app_loadconfig.c`. It must be a region that matches the list of domains in `mmregdb.c`\ `struct mmwlan_s1g_channel_list regulatory_db_domains[]`. 2. Remove the following components from the example (they are optional and can be removed without affecting its main functionality): `mmconfig`, `mbedtls`, and `littlefs`. 3. Build the example. If there are build errors or missing files, [Building MM-IoT-SDK examples and morselib](#sec-accessing-files-from-mm-iot-sdk-example) has instructions to identify files used in the build. #### Run example **Goal**: Run the Scan example **Success**: The `scan` example executes, outputting details of Wi-Fi HaLow networks it can hear. Follow these steps: 1. Set up an AP. Refer to the user guide for your particular platform. 2. (Optional) Set up a third HaLow device as a sniffer to see the packets being broadcast on the air. 3. Run the microcontroller platform. Expected output should be similar to below **Scan serial capture** ``` ----------------------------------- HW Version: MM-MM8108-EKH05 BCF API version: 12.1.0 BCF build version: be169c87 ef639c34fd BCF board description: {"module": "mm8108-mf15457"} morselib version: 2.11.2 Morse firmware version: 1.17.8 Morse chip ID: 0x0809 Morse chip name: MM8108B2 ----------------------------------- Scan started on US channels, Waiting for results... MorseMicro-Demonstration Operating BW: 8 MHz BSSID: 0c:bf:74:01:23:45 RSSI: -31 dBm Noise: -107 dBm Beacon Interval(TUs): 100 Capability Info: 0x0031 Security: SAE S1G Operation: Operating class: 4 Primary channel: 26 Primary channel width: 2 MHz Operating channel: 28 Operating channel width: 8 MHz ``` You have now successfully scanned the area for HaLow networks. ### iPerf **Goal**: Validate your platform can pass network traffic.\ **Success**: iPerf successfully runs, outputting a successful throughput result. #### Build integration Follow the same steps outlined in [Build integration](#sec-scan-build-integration). You must configure the iPerf to connect to your AP to run a throughput test. Refer to `iperf/src/mm_app_loadconfig.c` to configure the country code, SSID, passphrase and ensure SECURITY\_TYPE matches the security type on your AP. **Configuration snippet from `iperf/src/mm_app_loadconfig.c`** ``` /* Default Country Code */ #ifndef COUNTRY_CODE /** Country code. (Do not quote; it will be stringified, as it can be passed at build time.) */ /* clang-format off */ #define COUNTRY_CODE US /* clang-format on */ #endif /* Default SSID */ #ifndef SSID /** SSID of the AP to connect to. (Do not quote; it will be stringified.) */ #define SSID MorseMicro #endif /* Default passphrase */ #ifndef SAE_PASSPHRASE /** Passphrase of the AP (ignored if security type is not SAE). * (Do not quote; it will be stringified.) */ #define SAE_PASSPHRASE 12345678 #endif /* Default security type */ #ifndef SECURITY_TYPE /** Security type (@see mmwlan_security_type). */ #define SECURITY_TYPE MMWLAN_SAE #endif ``` Additionally, you can configure the iperf application. Refer to `iperf/src/iperf.c` for configuration options and see the snippet below **Configuration snippet from `iperf/src/iperf.c`** ``` #ifndef IPERF_TYPE /** Type of iperf instance to start. */ #define IPERF_TYPE IPERF_UDP_SERVER #endif #ifndef IPERF_TIME_AMOUNT /** * Duration for client transfers specified either in seconds or bytes. * If this is negative, it specifies a time in seconds; if positive, it * specifies the number of bytes to transmit. */ #define IPERF_TIME_AMOUNT -10 #endif #ifndef IPERF_SERVER_PORT /** Specifies the port to listen on in server mode. */ #define IPERF_SERVER_PORT 5001 #endif ``` #### Run example 1. Set up an AP. Refer to the user guide for your particular platform. Ensure that iPerf (v2.x) is available on it. 2. (Optional) Set up a third HaLow device as a sniffer to see the packets being broadcast on the air. 3. Run the microcontroller platform. **iPerf serial capture** ``` Morse iPerf Demo (Built Jun 2 2026 12:18:02) ----------------------------------- HW Version: MM-MM8108-EKH05 BCF API version: 12.1.0 BCF build version: be169c87 ef639c34fd BCF board description: {"module": "mm8108-mf15457", "s} morselib version: 2.11.2 Morse firmware version: 1.17.8 Morse chip ID: 0x0809 Morse chip name: MM8108B2 ----------------------------------- Initialize IPv4 using DHCP... Morse LwIP interface initialised. Attempting to connect to MorseMicro-Demonstration with passphrase 12345678 This may take some time (~10 seconds) WLAN STA connecting WLAN STA connected Morse STA interface up with MAC address 0c:bf:74:01:23:45 4865 NetIf Link status DOWN 9961 NetIf Link status UP DNS server 0: 10.0.0.1 Link is up. Time: 9961 ms, IP: 10.0.0.232, Net-mask: 255.255.255.0, Gateway: 10.0.0.1, DNS server 01 Iperf UDP server started, waiting for client to connect... Execute cmd on AP 'iperf -c 10.0.0.232 -p 5001 -i 1 -u -b 20M' for IPv4 # iperf -c 10.0.0.232 -p 5001 -i 1 -u -b 20M is executed on the AP # Replace IP with the one provided by your platform Iperf Report Remote Address: 10.0.0.1:48240 Local Address: 0.0.0.0:5001 Transferred: 25 MBytes, duration: 9950 ms, bandwidth: 20867 kbps ``` #### IP traffic benchmarks on supported platforms (EKH05) The following table shows benchmark values for the supported platforms. They are provided for comparison, though your platform may differ. **Table 9: Benchmark TPUT (Mbps) by transceiver and communication protocol**
Transceiver used in APSTA DeviceProtocolUDP DownlinkUDP UplinkTCP DownlinkTCP Uplink
MM6108 APMM6108-EKH05SPI18.0 Mbps18.0 Mbps8.1 Mbps6.4 Mbps
MM6108 APMM6108-EKH05SDIO24.0 Mbps24.0 Mbps9.5 Mbps7.0 Mbps
MM8108 APMM8108-EKH05SPI19.0 Mbps19.9 Mbps9.8 Mbps7.8 Mbps
MM8108 APMM8108-EKH05SDIO30.0 Mbps24.9 Mbps10.5 Mbps8.5 Mbps
## Troubleshooting ### Multiple definition linker errors - HostAP already defined **Symptoms**: Multiple definition linker errors on HostAP symbols. If HostAP is already defined in your project (for example, for a 2.4 GHz wireless interface) but you want to include `morselib` for a 900 MHz interface, you encounter multiple definition linker errors. `morselib` requires the modified HostAP supplied by `mm-iot-sdk`, so you must integrate it into your project. **Resolution**: Name-mangle the Morse Micro HostAP and all references to it in `morselib`. If you require guidance, see [Name mangling HostAP and morselib](#name-mangling). ### Transceiver fails to boot - SPI IRQ not implemented **Symptoms**: `mmwlan_boot()` returns a `mmwlan_status:MMWLAN_ERROR`. In systems using an SPI bus to connect the host and the transceiver, the transceiver indicates data is ready to be retrieved using the `SPI_IRQ` line. If you don’t implement this interrupt correctly, the transceiver fails to boot. **Resolution**: Ensure the SPI\_IRQ line has been implemented correctly. ### Lower than expected data throughput **Symptoms**: Data throughput is significantly lower than expected, or appears capped. There are many factors that affect throughput, including but not limited to the performance of the CPU and memory systems, the speed of the communications bus, and the configured region and bandwidth settings of the Wi-Fi HaLow network. To debug throughput issues we recommend you: * compare your results to the reference platforms, * review the output of the `porting_assistant`, particularly the `Raw TPUT (kbits/s)` result, * use the iPerf example application to baseline your throughput (instead of your application), * enable any optional tests that are present in the `porting_assistant`, * capture a trace of the communications bus with a logic analyzer, and review for inconsistent clock behavior and large delays. Common areas to check: * Ensure you have allocated sufficient packet memory (`mmpktmem`) and buffers for your network stack (LwIP uses `pbufs`). * Ensure the configuration of your communication bus is correct, including that you are using a DMA controller. * Ensure that the settings for your DMA controller are correct and that you are controlling the GPIOs correctly. * Ensure that your interrupt-handling routines return quickly. * Review the “when to use the DMA” optimizations included in Morse Micro’s reference shim implementations (on some platforms it can be more efficient to send small transfers without using the DMA controller). The following are examples of throughput issues we have debugged and resolved: * The default linker script for a platform placed and executed code from XIP flash memory via a QSPI interface. Executing code from this flash memory was a bottleneck for system performance. Using an alternate linker definition provided by the platform vendor to move code into RAM at boot time removed the bottleneck and resulted in satisfactory throughput. * During the port for a platform the default RAM was used at the location for the `mmpktmem` buffers. As the product evolved, these buffers were moved to a different, larger region of chip RAM but these showed worse performance. The issue was eventually diagnosed that the DMA controller was configured to expect 8-bit instead of 32-bit access, which only worked for the default RAM type. Updating the DMA configuration resulted in satisfactory throughput. ### How can I debug SPI? You can implement the R/W functions, and then hard-wire MISO to MOSI, and test that bytes transmitted over MOSI using the `write` function, can be read back over MISO via `read`. ### How to optimize flash and RAM usage? Flash and RAM usage depends heavily on the application. [Flash and RAM requirements explained](#sec-flash-ram-requirements-explained) explores the requirements and provides guidance on how to trim their use. We recommend trimming flash and RAM requirements *after* you have a working port that meets your performance targets. ## Appendix When including different software components use [Table 10: A table highlighting dependencies between components that are involved in porting](#tab:inter-component-dependencies) to identify dependencies between components. **Table 10: A table highlighting dependencies between components that are involved in porting** | **Component** | **Dependencies** | | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | `morselib` | HostAP | | `src/mmutils` | `morselib` | | `src/mmpktmem` | `morselib`, `mmutils` | | `src/mmconfig` | `morselib` | | `src/mmregdb` | `morselib` | | `src/mmipal` | `lwip`, `morselib`, `mmutils`. Requires `IP_STACK=lwip`. | | `src/mmiperf` | `lwip`, `morselib`, `mmutils`. Requires `IP_STACK=lwip`. | | `src/mmping` | `lwip`, `morselib`, `mmutils`. Requires `IP_STACK`. | | `src/lwip` | `mbedtls` (only when `altcp_tls_mbedtls.c` is compiled) | | `src/mbedtls` | `lwip` (via `library/net_lwip.c`, only when `IP_STACK` set), `morselib` | | `src/hostap` | `morselib` (`os_mmosal.c`, `morse_stubs.c`). MbedTLS (`crypto_mbedtls_mm.c`) Drivers/shim in `morselib/src/umac/supplicant_shim` bridge it to `morselib`. | ### Building MM-IoT-SDK examples and morselib Build the examples found in the `mm-iot-sdk` to identify compile information such as source files, include paths, and build flags. The `mm-iot-sdk` uses a Makefile based build system and expects an ARM C compiler for its STM32 based targets. Ensure Make is installed on your development machine and see [`arm-none-eabi-gcc-xpack`](https://github.com/xpack-dev-tools/arm-none-eabi-gcc-xpack) for a compiler which supports the platforms in the `mm-iot-sdk` #### Examples To build an example on a specific platform, use the `make` command shown below. **VERBOSE Build command for `mm-iot-sdk` example** ``` # To identify source files, build defines and include paths for an example in the mm-iot-sdk, # run the following make -C mm-iot-sdk/examples//targets/ \ VERBOSE=1 ``` To build the Porting Assistant, Scan, and iPerf for the `mm-mm6108-ekh05` platform, see the table below. **Table 11: Build commands for example applications on `mm-mm6108-ekh05`**
ExampleWorking directoryCommand
porting
assistant		examples/porting_assistantmake -C targets/mm-mm6108-ekh05 -j12 VERBOSE=1
scanexamples/scanmake -C targets/mm-mm6108-ekh05 -j12 VERBOSE=1
iPerfexamples/iperfmake -C targets/mm-mm6108-ekh05 -j12 VERBOSE=1
Parse the output of `make VERBOSE=1` commands to extract build flags, build defines, include paths, and source files. #### morselib You can add the `morselib` source files to your project and compile them as part of your application. However, you may find it easier to link against the prebuilt `libmorse.a` provided in `mm-iot-sdk/framework/morselib/lib/*`. Note that the prebuilt `libmorse.a` is only available for a limited set of CPU architectures and toolchain configurations. You must use the `NewLib-Nano` implementation of the C Library. You must ensure your CPU architecture and toolchain flags match against one of the options listed below. * arm-cortex-m33f * arm-cortex-m4f * arm-cortex-m7f ### Bus transport details The following functions are defined in `mmhal_wlan.h`. You must implement these functions and configure your communication peripheral (see [SPI](#sec-appendix-bus-transport-spi) and [SDIO](#sec-appendix-bus-transport-sdio)) to pass the communications HAL tests. **Implement only one of SDIO or SPI.** **Table 12: Mandatory `mmhal_wlan.h` functions**
FunctionDescription
Common
mmhal_wlan_wake_assert()Drives the WAKE GPIO high to signal the transceiver to exit sleep mode.
mmhal_wlan_wake_deassert()Drives the WAKE GPIO low, allowing the transceiver to enter sleep modes.
mmhal_wlan_busy_is_asserted()Returns true if the BUSY GPIO is currently asserted (transceiver is performing work).
mmhal_wlan_register_busy_irq_handler()Registers the callback to invoke when the BUSY line is driven high.
mmhal_wlan_set_busy_irq_enabled()Enables or disables the BUSY line interrupt.
mmhal_wlan_assert_reset()Asserts or deasserts the RESET GPIO line.
mmhal_wlan_hard_reset()Toggles the RESET line to perform a hard reset of the transceiver.
SPI (implement SPI or SDIO, not both)
mmhal_wlan_spi_cs_assert()Asserts the SPI chip-select line (drives NSS low).
mmhal_wlan_spi_cs_deassert()Deasserts the SPI chip-select line (drives NSS high).
mmhal_wlan_spi_rw()Transfers a single byte over SPI; returns the received byte.
mmhal_wlan_spi_read_buf()Reads a buffer of bytes from the SPI bus. DMA is recommended for transfers of 16 bytes or more.
mmhal_wlan_spi_write_buf()Writes a buffer of bytes to the SPI bus. DMA is recommended for transfers of 16 bytes or more.
mmhal_wlan_register_spi_irq_handler()Registers the callback to invoke on the SPI IRQ line interrupt.
mmhal_wlan_set_spi_irq_enabled()Enables or disables the SPI IRQ line interrupt.
mmhal_wlan_spi_irq_is_asserted()Returns true if the SPI IRQ line is currently asserted.
mmhal_wlan_clear_spi_irq()Clears the pending SPI IRQ interrupt.
mmhal_wlan_send_training_seq()Send >74 clock pulses with MOSI high while CS is deasserted.
SDIO (implement SPI or SDIO, not both)
mmhal_wlan_sdio_startup()Initializes and enumerates the SDIO card; called once at startup.
mmhal_wlan_sdio_cmd()Issues an SDIO CMD52 single-register read or write command.
mmhal_wlan_sdio_cmd53_write()Performs a CMD53 block/byte-mode write to the transceiver.
mmhal_wlan_sdio_cmd53_read()Performs a CMD53 block/byte-mode read from the transceiver.
Firmware / BCF
mmhal_wlan_read_bcf_file()Reads a region of the Board Configuration File (BCF) from non-volatile storage.
mmhal_wlan_read_fw_file()Reads a region of the Morse Micro firmware binary from non-volatile storage.
#### SPI In SPI mode, the host microcontroller operates as a SDIO device over SPI as per Part 1 SD Physical Layer Specification Section 7.3 and the Morse Micro transceiver (MM6108 or MM8108) is the slave. Morse Micro operates the SPI bus in half-duplex mode. Only SPI mode 0 (CPOL=0, CPHA=0) is supported. The reference shims for support platforms using the SPI bus can be found in\ `mm-iot-sdk/framework/src/platforms/*/mm_shims/mmhal_wlan.c` **Table 13: SPI peripheral requirements on the host microcontroller** | **Parameter** | **Requirement** | | ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Role | Host is SPI master; the Morse Micro transceiver is the slave. | | SPI mode | Mode 0 only (CPOL=0, CPHA=0). | | Bit order | MSB first. | | Frame size | 8-bit data frames. | | Duplex | Half-duplex protocol over a full-duplex pin configuration (both MISO and MOSI must be wired). | | SCK frequency | Refer to the transceiver datasheet for the supported maximum. The reference platforms run between 20 MHz (STM32U575/H753, `mm-mm6108-ekh05`, `mm-mm8108-ekh05`) and 40 MHz (STM32WB55); 20 MHz is a safe starting point for bring-up. | | Chip select | Software-controlled NSS driven from a GPIO. The reference shims do not use the SPI peripheral’s hardware NSS. | | Power-on training | The host must be able to clock the bus with CS deasserted to issue the 74-clock training sequence required before the first transaction (see `mmhal_wlan.h`). | | DMA | Strongly recommended. The reference shims use DMA for any transfer of 16 bytes or more (`DMA_TRANSFER_MIN_LENGTH`) and fall back to polled transfers below that. Without DMA the host will struggle to meet throughput targets and may stall the `morselib` worker thread. | | Buffer alignment | Bulk read/write buffers passed through `mmhal_wlan_spi_read_buf` and `mmhal_wlan_spi_write_buf` must be 32-bit aligned. | | Transfer completion signaling | The driver must be able to block efficiently on transfer completion (DMA-complete interrupt or equivalent) with a per-transfer timeout on the order of 10 ms. | #### SDIO The host microcontroller is always the SDIO host (controller); the Morse Micro transceiver (MM6108 or MM8108) is the SDIO card. The transceiver presents two SDIO functions: function 1 is used for control with an 8-byte block size, and function 2 carries data with a 512-byte block size. Communication uses standard SDIO CMD52 (single-register access) and CMD53 (block / byte multi-access) commands. The reference shims for supported platforms using the SDIO bus can be found at `mm-iot-sdk/framework/src/platforms/*-sdio/mm_shims/mmhal_wlan.c` **Table 14: SDIO peripheral requirements on the host microcontroller** | **Parameter** | **Requirement** | | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Role | Host is SDIO controller; the Morse Micro transceiver is the SDIO card. | | Bus width | 4-bit wide bus is the default and recommended configuration (enabled by the `ENABLE_SDIO_4BIT` build option). 1-bit operation is supported as a fallback. | | Initialization clock | Bus must be driven at 400 kHz during card enumeration (`SD_INIT_FREQ_HZ`). | | DMA | Internal DMA (IDMA, single-buffer mode) is required for data transfers. Transfer buffers must be 32-bit word aligned and the transfer length must be a multiple of 4 bytes. | | Transfer timeouts | The driver must be able to block on completion with timeouts of 750 ms for writes and 1000 ms for reads. | | Card interrupts | The SDIO in-band interrupt (DAT1) must be wired and the SDMMC peripheral configured to deliver `SDIO_IT_SDIOIT`. A separate GPIO is still required for the BUSY signal — it is not carried in-band. | As with SPI, the host must also provide the GPIO lines described above (Reset, Wake, Busy). The SDIO IRQ is delivered in-band on DAT1 by the SDMMC controller, so no additional GPIO interrupt line is needed for that purpose. ### Implementing a network stack driver When porting `mm-iot-sdk` to a platform or project which does not use `lwip` and `mmipal`, you must provide an interface driver. This driver is the bridge between your network stack and the Wi-Fi HaLow UMAC and driver provided by `morselib`. At a minimum, the network stack driver will be responsible for: * Initializing the Morse Micro network interface; * Passing received frames from `morselib` up to your network stack; * Passing outbound frames from your network stack to `morselib` for transmission; and * Reporting link state changes (link up / link down) to your network stack. #### Initialization Your driver’s initialization function should boot the transceiver, configure the network interface, and register the callbacks described in the following subsections 1. Call `mmwlan_boot()` to boot the transceiver. 2. Call `mmwlan_get_mac_addr()` and apply it into your network stack’s interface. 3. Register the receive (`mmwlan_register_rx_cb()`) and\ link state (`mmwlan_register_vif_state_cb()`) callbacks. #### Link State `morselib` calls your link state callback with `MMWLAN_LINK_UP` or `MMWLAN_LINK_DOWN` whenever the connection to the AP changes. The `mmwlan_register_vif_state_cb()` must be registered to communicate these link state changes to your network stack. The callback signature used by `mmwlan_register_vif_state_cb()` is: **Link state callback signature** ``` void link_state_cb(const struct mmwlan_vif_state *state, void *arg); ``` These events should be translated to equivalent notifications used by your network stack. On link up, DHCP should be restarted and the carrier marked active. #### Receive path When `morselib` receives a frame, it delivers it to your registered receive callback. Your callback must pass the frame to your network stack and then release the `morselib` buffer. The callback signature used by `mmwlan_register_rx_cb()` is: **Receive callback signature** ``` void rx_cb(uint8_t *header, unsigned header_len, uint8_t *payload, unsigned payload_len, void *arg); ``` The received frame is split into an 802.3 `header` (the Ethernet header) and a `payload` (the packet). Your interface driver is required to reassemble and deliver both to the network stack. Your callback must: 1. Allocate a buffer from your network stack large enough to hold `header_len + payload_len` bytes. 2. Copy the header and payload into the buffer. 3. Pass the buffer to your network stack’s receive function. 4. Release the buffer on any error path. If your application requires multiple VIF or a zero-copy receive via the `mmpkt` API use `mmwlan_register_rx_pkt_ext_cb` instead. #### Transmit path The network stack will call a transmit function registered by your interface driver. This function must copy the frame into a buffer that `morselib` can transmit. There are two `morselib` transmit APIs. Use the one that suits your application **Table 15: `morselib` transmit APIs** | **Function** | **Use when…** | | ------------------------------ | ------------------------------------------------------------------------------------------------ | | `mmwlan_tx(buf, len)` | Your network stack gives you a flat contiguous buffer, and a single VIF or QoS. | | `mmwlan_tx_pkt(pkt, metadata)` | You need fine-grained control over QoS TID, per-VIF targeting, or zero-copy via the `mmpkt` API. | When using `mmwlan_tx()`: 1. Read the outgoing packet from your network stack into a flat buffer. 2. Call `mmwlan_tx(buf, len)`. 3. Check the returned `mmwlan_status` and translate any error to your network stack’s error type. When using `mmwlan_tx_pkt()` with the extended `mmpkt` API: 1. Call `mmwlan_tx_wait_until_ready()` with a suitable timeout to apply back-pressure when the transceiver is busy. 2. Allocate an `mmpkt` with `mmwlan_alloc_mmpkt_for_tx()`, sizing it to the total frame length. 3. Open a view with `mmpkt_open()`, append each segment with `mmpkt_append_data()`, then close the view with `mmpkt_close()`. 4. Populate a `mmwlan_tx_metadata` structure with the TID and VIF 5. Call `mmwlan_tx_pkt()`. ### Converting .bin to .mbin The `mm-iot-sdk` supplies a script, `convert-bin-to-mbin.py`, to perform this conversion. For example, the Quectel FGH100MH high power module has a BCF distributed by Morse Micro at [Morse Micro - `morse-firmware`](https://github.com/MorseMicro/morse-firmware/blob/main/bcf/quectel/bcf_fgh100mhaamd.bin). Convert it to an `.mbin` with `./convert-bin-to-mbin.py bcf_fgh100mhaamd.bin`. ### Flash and RAM requirements explained The `mm-iot-sdk` recommends 2 megabyte of flash and 256 kilobytes of RAM. These figures are very general, and the space required will vary depending on your application, CPU architecture and platform. [Flash requirements explored](#sec-flash-explored) and [RAM requirements explored](#sec-ram-explored) were written using an ARM Cortex-M33 CPU core for getting flash and RAM estimates. This section provides more detail on the flash and RAM requirements, using the `aws_iot` example application as a basis for comparison. #### Flash requirements explored The main requirements for flash storage in `mm-iot-sdk` based applications are: * Storing the transceiver’s firmware and BCF, * Storing any persistent configuration (for example the `mmconfig` component), and * Storing your application’s code, **Firmware and BCF**\ As of SDK version 2.11.2, the transceiver firmware and BCF together consume approximately 400 kilobytes of space. **Persistent configuration**\ The examples in `mm-iot-sdk` use 16 kilobytes of space for persistent configuration. Your application may need more or less than this. **Application code size**\ The code size of your application depends on many factors including the amount of functionality included, the compile-time optimization settings, and the choice of debug settings. The `aws_iot` example is a large application that uses MQTT to communicate with an AWS service over TLS. The following table shows the flash size of building `aws_iot` for different supported platforms, with different options: **Table 16: Flash usage based on platform and build options**
#CommandFlashComments
1.
make -C targets/mm-mm6108-ekh05 \
BUILDTYPE=production
908 KB390 KB for transceiver firmware, 518 KB for application.
2.
make \
-C targets/mm-mm6108-ekh05-sdio \
BUILDTYPE=production
911 KBSDIO 3 KB larger than SPI build in #1.
3.
make -C targets/mm-mm8108-ekh05 \
BUILDTYPE=production
894 KB377 KB for MM8108 firmware, 517 KB for application. MM8108 firmware smaller than MM6108.
4.
make -C targets/mm-mm6108-ekh05 \
BUILDTYPE=debug
973 KB390 KB for transceiver firmware, 583 KB for application. 65 KB larger than #1 build, but still using optimized morselib.a.
5.
make -C targets/mm-mm6108-ekh05 \
BUILDTYPE=debug \
BUILD_MORSELIB_FROM_SOURCE=y
1018 KB390 KB for transceiver firmware, 628 KB for application. 45 KB larger than #4 build using morselib.a.
6.
make -C targets/mm-mm6108-ekh05 \
BUILDTYPE=debug \
BUILD_MORSELIB_FROM_SOURCE=y


and (specify in Makefile)

BUILD_DEFINES+=MMLOG_LEVEL_OVRD=7
BUILD_DEFINES+=AWS_LOG_LEVEL=3
1104 KB390 KB for transceiver firmware, 714 KB for application.
86 KB larger than #5 due to log levels.
If your host processor cannot be changed, there are two common workarounds for coping with the flash storage requirement of the transceiver firmware and BCF: * **Use external flash** — Store the transceiver firmware and BCF on an external flash device (for example, a QSPI flash), reducing the on-chip flash required on the host processor. * **Compress the firmware and BCF** — Store a compressed copy in flash and decompress on boot. This reduces flash usage at the cost of added port complexity and a longer boot time, since the host must decompress the images before delivering them to the transceiver. #### RAM requirements explored The main requirements for RAM storage in `mm-iot-sdk` based applications are: * Stack and heap space for your running program, and * Data memory for networking functions, such as `mmpktmem`. The `mm-iot-sdk` recommends greater than 256 kilobytes of RAM for your porting platform so that most `mm-iot-sdk` examples can be run on your platform. [Table 17: RAM usage per App with default build options](#tab:ram-usage-per-app) provides details about RAM usage for a small group of applications. **Table 17: RAM usage per App with default build options**
#AppRAM
1.porting_assistant102 KB
2.scan218 KB
3.iperf254 KB
4.aws_iot280 KB
For a fully featured application like `aws_iot`, the largest memory sections are the following: * **Operating system heap** - approximately 120 kilobytes, * **`mmpktmem` packet buffers** - approximately 111 kilobytes, and * **`lwip` packet buffers** - approximately 36 kilobytes. In total, this is 267 kilobytes used in the default build configuration. Expect to see similar sizes in your own application. The operating system and `mmpktmem` APIs provide flexibility to change total RAM usage. Options to change RAM usage include: 1. Packet memory pool - tune `MMPKTMEM_{TX,RX}_POOL_N_BLOCKS` to reduce memory usage. Most `mm-iot-sdk` examples default to 32 blocks. Switch between the static and heap-based implementations to change RAM usage. **Note:** The amount of RAM used for transmit and receive packet buffers (`mmpktmem`) is configurable, but directly affects throughput performance. 2. Trim operating system heap. 3. Cryptographic accelerators - use hardware accelerators for cryptographic operations to reduce RAM usage. ### Name mangling HostAP and morselib This is a general overview of the process needed to mangle hostap and `morselib` symbols. It will vary depending on how your build system works, and which features of hostap and `morselib` you are using. Follow these steps: 1. Generate a list of all conflicting symbols and collate them into a single text file. One symbol per line, a single newline character separating each line. 2. Put an appropriate rename for each symbol on the same line, separated by a space character, to form a symbol pair. See the symbol file snippet below, we recommend prefixing all conflicting symbols with "`mm_`" 3. After compiling, but before linking, call obj-copy on hostap and `morselib` object files, as outlined below. 4. Link against the new redefined object files. **Symbol pairs snippet from a text file** ``` hexstr2bin mm_hexstr2bin hmac_sha256_kdf mm_hmac_sha256_kdf hw_get_freq mm_hw_get_freq hostapd_acl_comp mm_hostapd_acl_comp ``` **Command to redefine symbols** ``` arm-none-eabi-objcopy \ --redefine-syms= \ ``` ### Porting Stubs Repository We have created a porting-stubs repository which contains the following: * A similar folder structure to what is recommended in [Figure 4: Recommended project structure: `mm-iot-sdk` outside your project directory](#dir:mm-iot-sdk-setup-reference-external). * The three applications you will use for testing your port; porting assistant, scan and iperf. * A `makefile` based build system which integrates the `mm-iot-sdk` using the `MMIOT_ROOT` variable. * A platform directory with stubbed `mmhal_wlan*` and `mmosal` files for you to complete. The files in this repository have empty implementations for all of the OSAL and HAL functions, so they can be compiled, linked and loaded onto your platform. However, since they are empty, the application will not run until you provide your port. The purpose of the porting-stubs repository is to supplement the information in this guide. We recommend you either download the stub repository and begin your own project inside it, or use it for guidance on how to create your own application project. The repository is available on our Github page: [Morse Micro: porting-stubs](https://github.com/MorseMicro/mm-iot-sdk-porting-stubs) ## Glossary
TermDefinition
APaccess point
APIapplication programming interface
ARMAdvanced RISC machine
AWSAmazon Web Services
BCFboard configuration file
BSPboard support package
CMakeCMake build tool
CPUcentral processing unit
DHCPdynamic host configuration protocol
DMAdirect memory access
ECCelliptic-curve cryptography
ELFExecutable and Linkable Format
FAEfield application engineer
function stuba trivial function that does nothing, sometimes containing an ASSERT(false) call to mark it as unimplemented
GDBGNU Debugger
GPIOgeneral-purpose input/output
HALhardware abstraction layer
hostthe microcontroller unit running your application
IDEintegrated development environment
IPALinternet protocol abstraction layer
LMAClower media access control
Makefilefile used by the make build tool to describe how to compile and link a program, specifying targets, dependencies, and the commands required to build them
MCUmicrocontroller unit
MMOSALMorse Micro operating system abstraction layer
modulea ready-to-use package containing a Morse Micro transceiver, supporting RF circuitry that has been precertified
MQTTMessage Queuing Telemetry Transport
OoBout of box
OSoperating system
OSALoperating system abstraction layer
PAPorting Assistant
PHYphysical layer
PKApublic key accelerator
platformeither the hardware of a product, or that hardware together with its build system, operating system, and driver software — this guide uses both senses; context indicates which
QoSquality of service
RAMrandom access memory
RSNrobust security network
RTOSreal-time operating system
SDIOsecure digital input output
SDKsoftware development kit
SoftMACSee Linux Wireless Documentation
SPIserial peripheral interface
SSIDservice set identifier
STAstation
TIDtraffic identifier
TLStransport layer security
TLVtype-length-value
TPUTthroughput
transceivera wireless communication device — a Morse Micro HaLow transceiver in this guide
UMACupper media access control
VIFvirtual network interface
XIPExecute In Place, a method of executing programs from long-term storage without copying them to RAM
## Revision History **Table 18: Document revisions** | Version | Date | Changes | | ------- | ---------- | --------------- | | 01 | 2-Oct-2026 | Initial release | ## Legal notices Morse Micro provides this information “as is” without warranties of any kind, express or implied. No guarantee is made as to the accuracy, completeness, or suitability of this information or Morse Micro’s products for any specific purpose. Use of this information and products is at the user’s sole risk. Morse Micro products are not designed or tested for use in mission-critical systems, and should not be used in such applications. Performance specifications are based on internal testing and are believed to be reliable; however, they are not guaranteed. It is the Buyer’s responsibility to test and validate all product performance, compatibility, and compliance, both in isolation and within end applications. Morse Micro assumes no liability for the use or application of any product, circuit, or information described herein. No license or other rights—express or implied—are granted under Morse Micro’s intellectual property. This document contains proprietary information of Morse Micro and is subject to change without notice. Wi-Fi®, Wi-Fi HaLow™, and the Wi-Fi logo are trademarks of Wi-Fi Alliance. ZigBee™ and Z-Wave™ are trademarks of their respective owners. All other trademarks are the property of their respective owners. # APPNOTE-50 AP Power Management v1 ## 1 Introduction This feature is a beta feature and not intended for production use in the 1.17 release. This application note describes how AP power management works, and how to configure and verify its operation. In chapter “11.2.3.17 AP power management” (802.11-2024.pdf, pp.2496-2497), the 802.11 specification describes the power management (PM) procedure for an S1G AP. Control of AP PM is communicated to the BSS by setting the AP PM bit in the frame control field of S1G beacons. The determination of when an AP enters doze is implementation specific, however, the timing of the BSS (i.e. beacon transmission on TBTT) must be maintained. The specification also prescribes the use of the IE "S1G Max Away Duration" (MAD) to communicate how long the AP may be out of reach from STAs on the BSS. ### 1.1. Nomenclature | Term | Description | Example | | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------- | | Doze | The term "doze" comes from the 802.11 specification. The device indicating doze has communicated to the BSS that it will be unavailable. Doze implies that the device will be in a low-power mode (i.e. snooze); however, this may not always be the case. At the chip level, a device that has indicated doze could be snoozing or awake. This means power savings are not guaranteed by the doze indication alone - actual power reduction depends on chip-level snooze behavior. | "The AP indicated doze in the frame control field of the most recent beacon transmission." | | Snooze | Describes the power mode that a Morse Micro Wi-Fi chip will enter to save power (i.e. reduce current consumption). While in snooze, a device cannot send or receive network traffic. | "Upon expiry of the minimum awake duration after beacon TX end, the AP entered snooze to save power." | | BSS | Basic Service Set. The wireless network formed by an AP and its associated STAs. | “All devices on the BSS must comply with the AP’s MAD setting.” | | STA | Station. A Wi-Fi client device that associates with an AP to join its BSS. | “Each STA must configure its max\_away\_duration to match or exceed the AP’s setting.” | | TU | Time Unit. The standard 802.11 time unit is equal to 1.024 milliseconds. Most 802.11 timing parameters (beacon interval, MAD, scan dwell time, etc.) are expressed in TUs. | “A beacon interval of 100 TUs equals approximately 102.4 ms.” | | MAD | Max Away Duration. An 802.11ah information element (IE) used by both APs and STAs to declare the maximum time the device may be unreachable (dozing/snoozing). Configured in units of TUs. | “Set max\_away\_duration=75 in hostap.conf to configure MAD.” | | TBTT | Target Beacon Transmission Time. The scheduled time at which the AP transmits its beacon frame. The AP’s power save timing is anchored to the TBTT. | “The AP beacon must be transmitted on the TBTT to maintain BSS timing.” | | IE | Information Element. A variable-length field included in 802.11 management frames (such as beacons and probe responses) to carry optional parameters. The MAD IE is one such element. | “The MAD IE is present in the probe response frames sent by the AP.” | | BI | Beacon Interval. The time between successive beacon transmissions is measured in TUs. Configured via beacon\_int in hostap.conf. Default is 100 TUs (approximately 102.4 ms). | “Set beacon\_int=100 in hostap.conf for a 102.4 ms beacon interval.” | **Table 1: Table of nomenclature used in this document** ### 1.2. Software Version Support The following table indicates which Morse Micro chip variants support AP power management in each firmware release. MM6108 and MM8108 refer to two Morse Micro 802.11ah (Wi-Fi HaLow) chip families. * A ✅ entry indicates that the feature is present and validated for production release * A ✅ (Beta) entry indicates the feature is present in that release but is in beta status - it is functional but not yet validated for production use. * A ❌ entry indicates the feature is not supported on that chip variant in the listed release. | Release | MM6108 | MM8108 | | ------- | -------- | ------ | | 1.17.8 | ✅ (Beta) | ❌ | ## 2 Theory of Operation This section describes how AP power save works at the protocol level, including how the AP advertises its power save capability, how the snooze timing window is determined, and how the AP handles traffic during the snooze period. For configuration instructions, see Section 3. APs will advertise support for power save by including the MAD IE in the probe and (re)association response frames. STAs who want to join the BSS must declare the maximum AP away duration they are willing to tolerate in the association request frame, also via the MAD IE. If the STA's maximum away duration is less than what the AP has specified, then the association will be rejected with the reason code WLAN\_STATUS\_REJECTED\_MAX\_AWAY\_DURATION\_UNACCEPTABLE (110). This will also occur if the STA does not specify any MAD. Once power save has been configured appropriately, the AP will be free to enter snooze after observing a period, dictated by beacon interval (BI) - MAD, on the beacon transmit end. Assuming no activity on the BSS, this behavior will repeat indefinitely. In plain terms, after transmitting each beacon, the AP stays awake for a window of BI - MAD, then snoozes for the remainder of the interval. For example, with a beacon interval of 100 TUs (102.4 ms) and a MAD of 75 TUs, the AP stays awake for 25 TUs (approximately 25.6 ms) after each beacon before entering snooze. During the snooze window, STAs that are associated with the AP are expected to wait until the AP’s next beacon before attempting to exchange traffic. Figure 1 illustrates the normal (no-traffic) snooze cycle.![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/zZVlj3ZOJGzqE69MPCRO/Unknown%20image) **Figure 1: Normal AP power save cycle (no traffic). Yellow = snooze period; green = wake-ahead period.** If, however, traffic is received or sent by the AP, then the PM bit in the next beacon will be cleared. Clearing the PM bit signals to associated STAs that the AP is now active and that the full beacon interval is available for data exchange. This allows the BSS to fully utilize the beacon interval for passing network traffic. After a period of inactivity, the AP will eventually indicate doze and start snoozing again. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/ko7mXy9CNX2MBAISxJNd/Unknown%20image) **Figure 2: AP power save cycle with traffic. Yellow = snooze period. Pink/red arrows on the AP row indicate incoming frames received during the active window; blue arrows indicate outgoing frames. When traffic occurs, the AP clears its PM bit in the next beacon, allowing a full beacon interval for data exchange before returning to the snooze cycle** ## 3 How to Configure Before applying this configuration, ensure that the Wi-Fi interface is up and that hostapd is running. After modifying hostap.conf, hostapd must be restarted for changes to take effect. To set the max away duration at the AP, include the configuration setting max\_away\_duration in hostap.conf. For example: # Beacon interval in TUs (1.024 ms) (default: 100; range 15..65535)\ beacon\_int=100 `# Max away duration (in TU = 1.024 ms) # If set to a nonzero value, the Max Away Duration field indicates the maximum # duration that the AP can be out of reach from STAs (i.e. AP enters power save).` max\_away\_duration=75 In the above configuration, the AP will at most be dozing/snoozing for 75% of the beacon interval. It is recommended that a reasonable wake window be maintained within the beacon interval to allow STAs to initiate communication with the AP. When choosing the MAD value, consider the trade-offs: setting MAD too high (closer to the beacon interval) reduces power consumption but leaves a very short wake window, which may cause STAs to fail to associate if their own maximum tolerable away duration is lower than the AP’s. Setting MAD too low provides a longer wake window but reduces the power-saving benefit. A value of 75% of the beacon interval is a reasonable starting point for most deployments. After the AP's interface is up, enabling/allowing chip snooze is controlled via the morse\_cli command: $ morse\_cli set ap\_power\_save 1 Argument 1 enables AP power-save mode. Pass 0 to disable it. STAs wishing to join the BSS of a power-saving AP must declare the maximum time they are willing to remain away. This is done via the configuration setting max\_away\_duration in wpa\_supplicant.conf. In most deployments, unless there is an application-specific limitation, it is best to set this field to the maximum: network={\ ...\ max\_away\_duration=65535\ } STAs wishing to join the BSS of a power-saving AP must also configure their scan dwell time to match the AP’s beacon interval plus 30 ms. This ensures the STA will be on the channel during the AP’s BI-MAD window, allowing it to send a probe request and receive the probe response. The dwell period can be configured via wpa\_supplicant.conf: # Scan dwell time (ms): set to beacon\_interval\_ms + 30 ms to ensure probe completes in the AP wake window scan\_dwell=130\ network={\ ...\ `# Max away duration (TUs): set to max (65535) so the STA accepts any AP MAD value` max\_away\_duration=65535\ }  ## 4 How to Verify Wireshark can be used to confirm that an AP is entering doze by checking the 'AP PM' bit in the frame control field of transmitted beacons. ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/Q5dsrX4VcKL1kkI7X4yu/Unknown%20image) **Figure 3: Wireshark screenshot of the packet tree showing the location of the AP PM field within the frame** The highlighted line “1… …. = AP PM: Supported” confirms that the AP has set its power management bit in the beacon frame, indicating the AP is entering doze mode. If this line is not present or shows “Not Supported”, AP power save is not active. The value of MAD can also be confirmed by inspecting the IEs of probe and (re)association response frames. **Figure 4: Wireshark screenshot of the packet tree showing the location of the Max Away Duration field within the frame** ![](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/C6uf9fJD3yiMX5H3ih64/Unknown%20image) The highlighted line “Max Away Duration: 50TUs” shows the MAD value advertised by the AP. 50 TUs equals approximately 51.2 ms (50 × 1.024 ms). This value should match the max\_away\_duration configured in hostap.conf (e.g., if max\_away\_duration=75, you should see 75 TUs here). To determine whether the chip itself is snoozing, morse\_cli can be used to gather chip statistics. $ morse\_cli stats | grep -i woke\ Woke from PS (timer) : 112\ Woke from PS (pin) : 1 The “Woke from PS (timer)” counter increments each time the chip automatically wakes at the scheduled wake-ahead time before the next beacon, indicating that the AP power save cycle is operating normally. The “Woke from PS (pin)” counter increments when the chip is woken early by an external signal (e.g., incoming traffic). A non-zero, incrementing “Woke from PS (timer)” value confirms that the chip is entering and exiting snooze correctly. To verify correct end-to-end operation from the STA’s perspective, confirm that the STA successfully associates with the AP (the STA should complete the association handshake without timing out). Once associated, verify that the STA can exchange data traffic with the AP - a successful ping from the STA to the AP or a remote host confirms the full power save cycle is working correctly. STAs that cannot tolerate the configured MAD value may fail to associate; if this occurs, reduce the max\_away\_duration on the AP side. If verification fails, check the following: 1. If the AP PM bit is not set in Wireshark, confirm that morse\_cli set ap\_power\_save 1 was run after the interface was brought up, and that hostapd was restarted after modifying hostap.conf. 2. If the MAD value in the probe response does not match the configured value, verify the max\_away\_duration setting in hostap.conf and restart hostapd. 3. If the “Woke from PS (timer)” counter is not incrementing, AP power save may not be active - re-run the morse\_cli command and check for errors. ## 5 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | --------------- | | Version 1 | 13 Apr 2026 | Initial Release | Morse Micro provides this information "as is" without warranties of any kind, express or implied. No guarantee is made as to the accuracy, completeness, or suitability of this information or Morse Micro’s products for any specific purpose. Use of this information and products is at the user’s sole risk. Morse Micro products are not designed or tested for use in mission-critical systems, and should not be used in such applications. Performance specifications are based on internal testing and are believed to be reliable; however, they are not guaranteed. It is the Buyer’s responsibility to test and validate all product performance, compatibility, and compliance, both in isolation and within end applications. Morse Micro assumes no liability for the use or application of any product, circuit, or information described herein. No license or other rights—express or implied—are granted under Morse Micro’s intellectual property. This document contains proprietary information of Morse Micro and is subject to change without notice. Wi-Fi®, Wi-Fi HaLow™, and the Wi-Fi logo are trademarks of Wi-Fi Alliance. All other trademarks are the property of their respective owners. # APPNOTE-51 Linux SPI Driver Porting Guide v1 ## 1 Scope This application note guides a software engineer through every step required to port the Morse Micro Linux kernel driver to use the SPI host interface on MM6108 and MM8108 Wi-Fi HaLow chip families. It covers: * Hardware pin mapping, electrical requirements, and SPI bus timing constraints * SPI controller capabilities required on the host * Device tree bindings and kernel configuration * Module parameters for bring-up tuning * The complete bring-up sequence as executed by morse\_spi\_probe() * Low-level SDIO-over-SPI protocol details (CMD63 fast-init, CMD53 data transfers, inter-block padding) * Platform-specific notes for common host SoCs * Known issues, workarounds, and a debug checklist Readers should already be familiar with the Linux SPI subsystem (drivers/spi/), device-tree SPI node configuration, and the basics of the Morse Micro driver source tree. For SDIO-based porting, refer to the standard Morse Micro SDK integration guide. ## 2 System Overview ### 2.1 SPI as a Host Interface The MM6108 and the MM8108 SoC integrate a single physical host-interface block that implements both an SDIO 2.0 slave and a SPI slave on the same physical pins. After powering on, the block is in SDIO mode. The host switches it to SPI mode by sending CMD63 with the chip-select asserted. Once in SPI mode, the device stays in SPI mode until power is cycled or a hardware reset is applied. Both MM6108 and MM8108 can only operate in SPI mode 0 (CPOL=0, CPHA=0). The driver configures the SPI controller to 8-bit mode, with a maximum clock of 50 MHz enforced in software. In practice, the usable frequency depends almost entirely on signal integrity; see Section 10 for guidance on frequency selection. For best performance on the SPI bus, Morse Micro recommends not sharing the bus with other peripheral devices. ### 2.2 SPI-over-SDIO Protocol The SPI interface is a thin wrapper around the SDIO digital block. This has a critical implication for driver porting: the device does not implement a pure SPI slave. It speaks the SDIO command/data protocol over SPI-compatible physical lines. Consequently: * Commands are framed as SDIO CMD packets (6-byte command + R1/R4/R7 response). * Data transfers use CMD53 read/write with 512-byte block granularity (MMC\_SPI\_BLOCKSIZE). * The device's internal address space is 17 bits and is expanded to 32 bits via keyhole registers identical to those in SDIO mode. * Data blocks are validated with CRC16-CCITT. The kernel CRC\_ITU\_T module must be enabled. Timing restrictions that apply to the SDIO block also apply in SPI mode, since the same digital block is clocked. ## 3 Hardware Interface ### 3.1 Pin Mapping The SPI interface reuses the physical SDIO pins. The table below shows the mappings between the MM6108/MM8108 SDIO signal names, the SPI signal names, and the Linux SPI/GPIO driver properties. | MM6108/MM8108 | SPI Signal | Linux SPI Name | Notes | | ------------- | ---------- | --------------- | --------------------------------------------- | | SDIO\_CLK | SCLK | spi-sclk / CLK | Clock, driven by the host | | SDIO\_CMD | MOSI | spi-mosi / TX | Host → chip data | | SDIO\_D0 | MISO | spi-miso / RX | Chip → host data | | SDIO\_D3 | CS\_N | spi-cs / CE | Active-low chip select | | SDIO\_D1 | IRQ | spi-irq-gpios | Open-drain, active-low; needs pull-up on host | | SDIO\_D2 | — | — | Unused; pull HIGH to VDDIO (10 kΩ) | | RESET\_N | nRESET | reset-gpios | Driver: assert low ≥80 ms, then release | | WAKE\_UP | WAKE | power-gpios\[0] | Optional power-save; host output | | BUSY | BUSY | power-gpios\[1] | Optional power-save; chip output | **Table 1: Pin mapping** Note: SDIO\_D2 is unused in SPI mode and must be pulled to VDDIO (nominally 3.3 V) via 10 kΩ resistors on the PCB to prevent the internal SDIO logic from detecting bus-conflict events. ### 3.2 Electrical Requirements All SPI signals are digital I/O operating at VDDIO (2.25 to 3.6 V, typically 3.3 V). If the host SPI controller operates at 1.8 V logic levels, uni-directional level shifters will need to be inserted. For more detailed information, refer to MM8108-MF15457 Hardware Design Guide. ### 3.3 SPI Bus Timing The timing parameters are derived from the SDIO bus timing specification in the MM6108 / MM8108 datasheet. ![Figure 1: SDIO device bus input timing diagram](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/m5SVjkEftvRngq9QTrTd/Unknown%20image) *Figure 1: SDIO device bus input timing diagram* ![Figure 2: SDIO device bus output timing diagram](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/w8WJPVvl9rDbYqG0GM1B/Unknown%20image) *Figure 2: SDIO device bus output timing diagram* The table below lists all parameters relevant to the Linux SPI controller configuration. | Parameter | Min | Max | Notes | | ------------------------------- | ----- | ------ | -------------------------------------------------- | | Clock frequency | 0 MHz | 50 MHz | Hard ceiling in the driver | | CPOL / CPHA | 0 / 0 | 0 / 0 | SPI Mode 0; clock idles low, sample on rising edge | | MOSI setup to SCLK rise (tISU) | 6 ns | — | From the SDIO host-mode timing spec | | MOSI hold after SCLK rise (tIH) | 2 ns | — | | | SCLK rise to MISO valid (tODLY) | — | 14 ns | At chip pins; tightens at > 50 MHz | | CS\_N assert to first SCLK | 0 ns | — | Keep CS asserted for the full transaction | | Inter-block delay for MM6108 | 40 µs | 130 ms | Abort if > 130 ms | | Inter-block delay for MM8108 | 5 µs | 130 ms | Abort if > 130 ms | | Signal capacitance | — | 40 pF | Exceeding this limit requires series termination | **Table 2: Bus timing specifications** ### 3.4 Reset Sequencing The driver controls nRESET via the reset-gpios device-tree property. On probe, morse\_spi\_reset() asserts nRESET low and holds it low for 80 ms before releasing it. This single timing covers both the RESET\_N hold requirement and sufficient time for all chip power rails and the crystal oscillator to stabilize before the first SPI command. The complete board-level power-on sequence is: 1. Assert nRESET low. 2. Ensure all chip power rails (VDD, VDDIO) are within specification. 3. The driver will release nRESET after 80 ms. If your power ramp or crystal startup is longer than 80 ms, delay the module load accordingly. 4. After nRESET is released, the driver waits for the chip's SPI state machine to enter the idle state, then begins the training sequence (Section 9.1.6). ## 4 SPI Controller Requirements The driver calls spi\_setup() with the following fixed settings: * mode: SPI\_MODE\_0 (CPOL=0, CPHA=0): recommended * bits\_per\_word: 8: mandatory; 16- or 32-bit modes are not supported * Max clock: 50 MHz: hard ceiling clipped in morse\_spi\_setup() (spi.c:202) Additional controller requirements and recommendations: * A DMA-capable controller is strongly recommended. The driver issues single transactions up to 8 KB and total transfers up to 64 KB. * CS must remain asserted (low) throughout each transaction. The driver uses a single shared 8 KB DMA buffer for both TX and RX. Do not configure the controller to release CS between words or between DMA segments. * During the 74-clock training sequence, the driver temporarily asserts SPI\_CS\_HIGH to clock out 18 bytes of 0xFF with CS deasserted. Host controllers should support this. If not, the driver logs "can't change chip-select polarity" and skips the sequence. In this case, the chip's subsequent behavior is not deterministic. ### 4.1 Transaction Size Limits * SPI\_MAX\_TRANSACTION\_SIZE = 8 KB: maximum single SPI transaction * SPI\_MAX\_TRANSFER\_SIZE = 64 KB: maximum single bus read/write * MMC\_SPI\_BLOCKSIZE = 512 B: SDIO block size If your SPI controller cannot sustain 8 KB bursts without inserting long inter-block gaps, throughput will suffer, but the link will remain functional. ## 5 Key Specifications All values below are derived from #define constants in spi.c. | Parameter | Value | | ------------------------------- | --------------------------------------------------------------------------------------------- | | Maximum SPI clock | 50 MHz (hard ceiling, driver clips higher values) | | SPI mode | Mode 0 (CPOL=0, CPHA=0) | | Bits per word | 8 | | SDIO block size | 512 bytes | | Driver DMA buffer | 8 KB (single shared TX/RX buffer) | | Maximum single SPI transaction | 8 KB | | Maximum single bus read/write | 64 KB | | Reset assert / hold / release | Drive nRESET low, hold ≥80 ms, release | | 74-clock training burst | 18 bytes of 0xFF with CS deasserted (CS high) | | Default inter-block delay |

\~40 µs for MM6108
\~5 µs for MM8108
(expressed as padding bytes at clock speed)

| | Default post-write status bytes | 4 | | Data integrity CRC | CRC16-CCITT | | IRQ trigger (default) | IRQF\_TRIGGER\_LOW \| IRQF\_ONESHOT | | IRQ trigger (edge mode) | IRQF\_TRIGGER\_FALLING \| IRQF\_ONESHOT | **Table 3: Key specifications** ## 6 Device Tree Bindings ### 6.1 Compatible Strings * "morse,mm610x-spi": for MM6108 family (includes MM6108) * "morse,mm810x-spi": for MM8108 family (includes MM8108) The driver's OF match table is at spi.c:192, and its non-DT SPI ID table is at spi.c:184. ### 6.2 Required Properties * compatible: as above * reg: chip-select index on the parent SPI bus (not a memory address) * spi-max-frequency: SPI bus clock in Hz; must be ≤ 50000000 * reset-gpios: single GPIO specifier for nRESET (active-low). Probe fails if absent (unless mmc-pwrseq is used; see Section 11) * spi-irq-gpios: single GPIO specifier for the chip IRQ output (active-low). Probe fails if absent ### 6.3 Optional Properties * power-gpios: pair of GPIO specifiers (wake, busy) as a single property with two cells. Required only for power-save support. If only one GPIO is listed, the driver logs a warning and disables power-save * interrupts / interrupt-parent: not required; the driver calls gpio\_to\_irq() on spi-irq-gpios internally ### 6.4 Example Device Tree Node A complete working example for the RPi Broadcom SPI host: /dts-v1/; /plugin/; / { compatible = "brcm,bcm2835", "brcm,bcm2836", "brcm,bcm2708", "brcm,bcm2709", "brcm,bcm2711"; fragment\@0 { target = <\&spi0>; frag0: **overlay** { pinctrl-0 = <\&spi0\_pins \&spi0\_cs\_pins>; cs-gpios = <\&gpio 8 1>; \#address-cells = <1>; \#size-cells = <0>; status = "okay"; mm6108: mm6108\@0 { compatible = "morse,mm610x-spi"; reg = <0>; /\* CE0 \*/ reset-gpios = <\&gpio 5 0>; power-gpios = <\&gpio 3 0>, <\&gpio 7 0>; spi-irq-gpios = <\&gpio 25 0>; spi-max-frequency = <50000000>; status = "okay"; }; spidev0: spidev\@0 { reg = <0>; /\* CE0 \*/ status = "disabled"; }; spidev1: spidev\@1 { reg = <1>; /\* CE1 \*/ status = "disabled"; }; }; }; fragment\@1 { target = <\&gpio>; **overlay** { spi0\_cs\_pins: spi0\_cs\_pins { brcm,pins = <8>; brcm,function = <1>; /\* BCM2835\_FSEL\_GPIO\_OUT \*/ brcm,pull = <2>; /\* SET SPI PINS AS PULL HIGH \*/ }; spi0\_pins: spi0\_pins { brcm,pull = <2 2 2>; /\* SET SPI PINS AS PULL HIGH \*/ }; }; }; }; Notes: * Developers should not set spi-cpol or spi-cpha in the DT node. Mode 0 is the correct default. Setting either flag selects a different SPI mode, and the chip will not respond. * SDIO\_D2 pull-ups should be placed on the PCB, not controlled by software. Confirm the schematic includes 10 kΩ pull-up resistors on these two lines. ## 7 Kernel Configuration ### 7.1 Morse Driver Kconfig Options * CONFIG\_MORSE\_SPI=y (or =m) — builds the SPI bus support. Required. * CONFIG\_MORSE\_SPI\_RK3288=y — Rockchip RK3288 platforms only (see Section 12). * CONFIG\_MORSE\_DEBUG\_MASK= — debug verbosity bitmask: 1=debug, 2=info, 4=warning, 8=error (default). Set to 15 (0x0F) during bring-up for maximum verbosity. * CONFIG\_MORSE\_ENABLE\_TEST\_MODES=y — enables the test\_mode module parameter used by the bus integrity test (Section 12). ### 7.2 Required Kernel Subsystems * CONFIG\_SPI — SPI master framework * CONFIG\_OF — device tree support * CONFIG\_OF\_GPIO — GPIO bindings used by morse\_of\_probe() * CONFIG\_CRC\_ITU\_T — CRC16-CCITT used by the SPI data integrity check ## 8 Module Parameters (Bring-Up Tuning) All parameters may be passed on the insmod / modprobe command line or persisted in /etc/modprobe.d/morse.conf using the options directive. | Parameter | Default | Description | | ------------------------------- | ---------- | ---------------------------------------------------------------------------------------------------------------------- | | spi\_clock\_speed | 0 (use DT) | Override spi-max-frequency from the device tree. Values above 50 MHz are clipped. | | spi\_inter\_block\_delay\_bytes | auto | Override auto-calculated inter-block delay bytes. Raise if CRC errors occur. | | spi\_post\_write\_status\_bytes | 4 | Additional 0xFF cycles after CMD53 write for chip response token. Raise to 8 or 16 on older kernels. | | spi\_use\_edge\_irq | 0 | 0 = IRQF\_TRIGGER\_LOW (level). 1 = IRQF\_TRIGGER\_FALLING (edge). Use the edge only if the host cannot level-trigger. | | enable\_ext\_xtal\_init | 0 | Set to 1 on boards booting from a slow (e.g., 32 kHz) external crystal. Adds +2 KB 0xFF padding to writes. | **Table 4: Bring-up tuning parameters** Examples: `# insmod — full set of bring-up overrides` insmod morse.ko spi\_clock\_speed=5000000 spi\_use\_edge\_irq=1 enable\_ext\_xtal\_init=1 `# modprobe.d — persist a 25 MHz clock` echo "options morse spi\_clock\_speed=25000000" >> /etc/modprobe.d/morse.conf ## 9 Bring-Up Sequence This section describes exactly what happens when morse\_spi\_probe() runs (spi.c:1387). You can correlate kernel log output with each phase. ### 9.1 Step-by-Step Probe Sequence #### 9.1.1 Step 1: Compatible / ID Match The driver matches "morse,mm610x-spi" or "morse,mm810x-spi" from the DT, or "mm610x-spi" / "mm810x-spi" from the non-DT SPI id table, and selects the chip series. #### 9.1.2 Step 2: SPI Controller Setup Calls morse\_spi\_setup(): sets Mode 0, 8 bpw, clips clock to 50 MHz, and calls spi\_setup(). Failure here means the host controller rejected the settings. #### 9.1.3 Step 3: Driver Structures and DMA Buffer Allocates an 8 KB buffer used as a shared TX/RX DMA region. Initializes the spi\_message / spi\_transfer structures used for every transaction. #### 9.1.4 Step 4: Device Tree GPIO Parse morse\_of\_probe() reads reset-gpios, spi-irq-gpios, and optional power-gpios. #### 9.1.5 Step 5: Hardware Reset Calls morse\_spi\_reset (asserts nRESET low, waits 80 ms, releases). #### 9.1.6 Step 6: 74-Clock Training Sequence (skipped on RK3288) Temporarily asserts SPI\_CS\_HIGH and clocks out 18 bytes of 0xFF (≥ 74 clock pulses) with CS deasserted to satisfy the MMC/SD requirement before CMD0. Then restores CS polarity. #### 9.1.7 Step 7: CMD63 SPI Mode Switch Issues CMD63 (SD\_IO\_MORSE\_INIT) — the vendor-specific command that switches the chip from SDIO mode to SPI mode. On failure, falls back to CMD0 (SD\_IO\_RESET) and retries. Up to 3 attempts total. If all attempts fail, log "failed to init SPI with CMD63 (ret:)." #### 9.1.8 Step 8: Chip Detection Reads the chip ID register and validates that it matches the compatible string. On success logs "Morse Micro SPI device found, chip ID=0x". A return of all 0xFF or all 0x00 indicates the initialization sequence failed; see Section 13. #### 9.1.9 Step 9: Inter-Block Delay Configuration Configures inter-block timing based on clock speed (or spi\_inter\_block\_delay\_bytes if overridden). On success logs "clock= MHz, delay bytes=, max block count=". #### 9.1.10 Step 10: Firmware Load Loads the firmware image. #### 9.1.11 Step 11: IRQ Setup Calls morse\_spi\_setup\_irq(): * gpio\_request() and gpio\_direction\_input() on spi-irq-gpios * gpio\_to\_irq() to obtain the Linux IRQ number * CMD52 writes to SDIO CCCR registers 0x04 (IEN) and 0x07 (BIC) to enable chip-side interrupts * request\_threaded\_irq() with IRQF\_TRIGGER\_LOW | IRQF\_ONESHOT (or IRQF\_TRIGGER\_FALLING if spi\_use\_edge\_irq=1) #### 9.1.12 Step 12: MAC Registration Registers the 802.11 MAC layer and starts the health check thread. Beyond this point, the SPI link is up, and the driver is in the MAC domain. Note: If the probe fails, the driver reverses each step in order, unless the chip supports the fast re-probe (reattach) path, which keeps the firmware loaded. ### 9.2 Command Protocol Details #### 9.2.1 0xFF Byte Before Each Command Each SDIO command must be immediately preceded by a single 0xFF byte sent with CS asserted. This is the mandatory 'clock-before-command' byte required by the SDIO-over-SPI protocol, so the chip can detect the command start bit. Omitting it causes intermittent failures, especially on USB-to-SPI bridges with non-deterministic inter-transaction timing. #### 9.2.2 0xFF Padding After Commands After transmitting an SDIO command (while CS is still asserted), include a single 0xFF byte in the same SPI transfer message before polling for the device response. Sending it as a separate transfer can introduce enough delay for MISO to take significantly longer to return high. #### 9.2.3 0xFF Padding for CMD53 Data Phase For CMD53 read/write operations, up to four additional 0xFF bytes may be required between the command status response and the data token (0xFE for single block, 0xFC for multi-block write). The driver must keep sending 0xFF and monitoring MISO for the data start token within this window. ### 9.3 Multi-Block Transfers Multi-block transfers require special handling because the chip needs inter-block time to process received data: * After each block's status/acknowledgment, continue sending 0xFF on MOSI until MISO goes high (the chip is not busy). * If MISO has not returned high within 130 ms, the block transfer has failed — abort and retry from the start of the CMD53 sequence. * The entire multi-block transfer (command + all blocks + padding) must be a single SPI transaction with CS asserted throughout. Toggling CS between blocks causes the chip to lose block-boundary tracking. * Since the inter-block delay is constant, the number of 0xFF inter-block padding bytes varies with clock speed. At lower clocks (e.g., 12.5 MHz), fewer bytes are needed than at 50 MHz. ## 10 Frequency Selection Guidance The absolute maximum SPI clock the driver accepts is 50 MHz. In practice, the usable frequency depends almost entirely on signal integrity: trace length, trace matching, connector quality, and the host SPI controller's output slew rate. Recommended bring-up strategy: 1. First boot: 1 to 5 MHz — at this speed, electrical issues are eliminated as a cause of failure. Start here. 2. Functional test: 10 to 20 MHz — once chip ID reads back correctly and firmware loads, step up to a mid-range clock. Run iperf or the bus test mode (Section 12) for several minutes and watch for CRC errors in dmesg. 3. Target operation: 20 to 25 MHz — the sweet spot for most production designs. 4. Above 25 MHz — possible on well-engineered PCBs with short length-matched traces, clean grounds, and controllers with fast output slew. Validate with an oscilloscope on the MISO/MOSI/SCLK pins. Inter-block delay tuning: the default inter-block delay (40 µs for MM6108 and 5 µs for MM8108) is internally represented as a count of 0xFF padding bytes at the configured clock rate. If you see sporadic "SPI response missing" or CRC errors at a given clock, raise spi\_inter\_block\_delay\_bytes before dropping the clock. Note: Reducing the clock speed does not always improve reliability. At very low clocks (< 12.5 MHz), the inter-block gap is proportionally shorter, and the number of required padding bytes decreases. If debugging SPI issues, test at both the configured speed and at 25 MHz before concluding the issue is clock-rate-independent. ## 11 Tips and Tricks * reset-gpios and spi-irq-gpios must be on host pins that have no bootstrap or alternate function that could drive them during reset. A bootstrap pin forced high can prevent the chip from releasing reset or mask the chip's IRQ. * The chip IRQ (IRQ\_N) is an open-drain, active-low line. Ensure the host input is not configured with an internal pull-down — the interrupt will never deassert. * The IRQ line should be routed to a GPIO that supports wake-from-suspend if system-wide power management is required. * If using mmc-pwrseq to control power and reset instead of reset-gpios, the driver tolerates a missing reset-gpios property and logs an info message rather than failing probe. * On boards with a 32 kHz sleep oscillator as the only clock reference at boot, set enable\_ext\_xtal\_init=1. The driver will pad every write with +2 KB of 0xFF bytes to give the chip time to respond at the slow clock rate. * The driver's DMA buffer is a single 8 KB buffer used for both TX and RX. CS must be held for the full transaction; do not configure the controller to release CS between words. * When swapping between SDIO and SPI on the same hardware, remember SPI requires both reset-gpios and spi-irq-gpios; SDIO requires neither. * For development, always start with spi\_clock\_speed set to a value lower than your DT value. Once the link is stable, remove the override and rely on spi-max-frequency. ## 12 Platform-Specific Notes Raspberry Pi (BCM2835 / 2837 / 2711) Works out of the box at 25 MHz with the standard spi0 or spi1 master. Use a DT overlay to add the morse\_wifi\@0 node. No special Kconfig options are required. Rockchip RK3288 Requires CONFIG\_MORSE\_SPI\_RK3288=y. The driver skips the 74-clock CS-high training sequence (the controller cannot drive CS high) and applies a 1-bit right shift to all received data to compensate for a known controller off-by-one bug. NXP i.MX (i.MX 6 / 7 / 8) Works at Mode 0 on all ECSPI variants. Do not set spi-cpol or spi-cpha in your DT — the defaults (both 0) are correct. The ECSPI maximum usable clock is typically well below 50 MHz, so the driver ceiling is not the limiting factor. TI AM335x / AM57x (McSPI) Check the McSPI cs-word / cs-release behavior. The driver requires CS to be held for the full transaction; verify that the controller does not release CS between DMA segments. Controllers with Long First-Byte Post-CS Delay Some controllers insert gaps after asserting CS. Raise spi\_post\_write\_status\_bytes from 4 to 8 or 16. Any Controller Without 8-bit BPW Support Not supported. The driver requires 8 bits per word. ## 13 Known Issues and Workarounds | Symptom | Cause | Workaround | | --------------------------------------- | ---------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | All MISO bytes are 0xFF after CMD63 | CMD63 not accepted; chip still in SDIO mode | Verify 18-byte 0xFF training with CS high was sent; confirm reset timing (≥80 ms); check SDIO\_D1/D2 pull-ups | | MISO data shifted by exactly 1 bit | Unexpected chip reset (JTAG\_RST, supply drop, GPIO glitch) | Ensure JTAG\_RST is not driven by host tools; check VDD stays above 3.0 V; driver must detect and re-init | | Intermittent CMD53 read failures | Insufficient inter-block padding or single-transaction violation | Raise spi\_inter\_block\_delay\_bytes; ensure entire multi-block transfer uses a single CS assertion | | Truncated / corrupted reads at < 25 MHz | Inter-block gap longer at low clock; DMA buffer too small | Increase driver DMA receive buffer; add extra 0xFF padding to single-block reads | | "SPI response missing" errors | Chip not emitting R1 token in the expected window | Raise spi\_post\_write\_status\_bytes (try 8, then 16); reduce clock speed | | FTDI JTAG\_RST assertion on connect | FT2232H D2XX driver asserts ADBUS7 (JTAG\_RST) at init | Disconnect JTAG\_RST or deassert ADBUS7 before SPI communication begins | | "can't change chip-select polarity" | SPI controller cannot drive CS high for the training burst | Informational only; driver proceeds. If CMD63 also fails, emit 74 clocks externally or use the RK3288 workaround | | CRC errors above 25 MHz | Signal integrity: long traces, capacitance, slew mismatch | Add 22–33 Ω series terminators near the chip; reduce the clock; validate with a scope at chip pins | **Table 5: Known issues and workarounds** ## 14 Troubleshooting ### 14.1 Verify the Driver Loaded and Matched Run dmesg | grep -i morse and look for: "Reading gpio pins configuration from device tree" Then follow the step-by-step messages from Section 9 to identify which probe step failed. ### 14.2 Increase Verbosity Build with CONFIG\_MORSE\_DEBUG\_MASK=0xF or override at runtime via the driver's module parameter debug\_mask=0xF. ### 14.3 Common Error Messages * "Required property reset-gpios not found in device tree" → Add reset-gpios to your DT node. Verify the loaded DTB with /proc/device-tree/. * "Required property spi-irq-gpios not found in device tree" → Add spi-irq-gpios to your DT node. * "Failed to acquire spi irq gpio" → Another driver already claimed the GPIO, or the GPIO number is invalid. Run gpioinfo (libgpiod) to identify the current consumer of the line. See Section 14.5 for more details. * "failed to init SPI with CMD63 (ret:)" → Chip not responding to the init command. Verify SPI wiring, power rails, crystal, nRESET timing (≥ 80 ms), SPI Mode 0, and try spi\_clock\_speed=1000000 to rule out signal integrity. * "SPI response missing" → Chip not emitting R1 response. Try raising spi\_post\_write\_status\_bytes (e.g., 8), then spi\_inter\_block\_delay\_bytes. If persistent, lower the clock. * "SPI response bit shifted" → MISO sampled one bit early/late. On RK3288, fixed by CONFIG\_MORSE\_SPI\_RK3288=y. On other controllers, check CPHA and controller RX sample-delay settings. * "SPI response error" → R1 byte invalid; likely noise or bad CRC. Lower the clock and scope MISO at the chip pins. * "can't change chip-select polarity" → Informational; controller does not support SPI\_CS\_HIGH. Training sequence is skipped. Usually harmless. * "SPI clock MHz is not supported by this chip, clipping to 50 MHz" → Your DT or module param exceeds 50 MHz; the driver clips it. ### 14.4 Physical Layer Sanity Checks With a scope or logic analyzer on the SPI pins measured at the chip: * Confirm SCLK idles low and samples on the rising edge (Mode 0). * Confirm CS is driven low for the entire transaction, not just the first byte. * Confirm the 18-byte 74-clock CS-high training burst appears on MOSI with CS high (absent on RK3288 targets). * Confirm the first CMD bytes match SDIO framing (0x40 | cmd\_index on MOSI). ### 14.5 GPIO Sanity Checks Use gpioinfo (libgpiod) to verify: * reset-gpios: output, currently high after reset release. * spi-irq-gpios: input, currently high when idle (chip releases line when no IRQ pending). Verify that there is no internal pull-down on the host input. * power-gpios wake: output, host-controlled. * power-gpios busy: input, chip-driven. ### 14.6 Confirm the Clock Actually Used Check dmesg | grep "clock=". You should see: "clock=25 MHz, delay bytes=, max block count=". If the clock is lower than your DT setting, a spi\_clock\_speed module parameter may be overriding it. ### 14.7 Bus Integrity Test Build with CONFIG\_MORSE\_ENABLE\_TEST\_MODES=y and load the module with test\_mode=MORSE\_CONFIG\_TEST\_MODE\_BUS. This runs an internal pattern test over the SPI link, exercising the CRC path independent of firmware. A clean pass indicates the bus is healthy. Use MORSE\_CONFIG\_TEST\_MODE\_BUS\_PROFILE to measure throughput versus block size, which is useful for tuning spi\_inter\_block\_delay\_bytes. ## 15 Revision History | Release Number | Release Date | Release Notes | | -------------- | ------------ | --------------- | | Version 1 | 29 May 2026 | Initial release | Morse Micro provides this information "as is" without warranties of any kind, express or implied. No guarantee is made as to the accuracy, completeness, or suitability of this information or Morse Micro’s products for any specific purpose. Use of this information and products is at the user’s sole risk. Morse Micro products are not designed or tested for use in mission-critical systems, and should not be used in such applications. Performance specifications are based on internal testing and are believed to be reliable; however, they are not guaranteed. It is the Buyer’s responsibility to test and validate all product performance, compatibility, and compliance, both in isolation and within end applications. Morse Micro assumes no liability for the use or application of any product, circuit, or information described herein. No license or other rights—express or implied—are granted under Morse Micro’s intellectual property. This document contains proprietary information of Morse Micro and is subject to change without notice. Wi-Fi®, Wi-Fi HaLow™, and the Wi-Fi logo are trademarks of Wi-Fi Alliance. ZigBee™ and Z-Wave™ are trademarks of their respective owners. All other trademarks are the property of their respective owners. | Linux SPI Driver Porting Guide v1 | morsemicro.com \| | | --------------------------------- | ------------------ | # APPNOTE-56 MM8108 Thermal Protection Mechanism [Download as PDF](https://www.morsemicro.com/resources/certification/APPNOTE-56_MM8108_Thermal_Protection_Mechanism.pdf) ## 1 Introduction The MM8108 SoC features an on-chip Power Amplifier (PA) capable of delivering up to 26 dBm average power. At such high output levels, the heat generated can raise the chip's temperature well above ambient. When the ambient temperature is already high, the measured temperature may exceed the chip's maximum rated operating temperature. Operating beyond this limit can cause the device to enter an unstable state, potentially resulting in permanent hardware failure or link disconnection. To prevent this, Morse Micro has built continuous thermal monitoring and a Thermal Protection Mechanism (TPM) into the firmware to keep the device operating reliably. This document explains how this thermal protection mechanism works. ## 2 Thermal Protection Mechanism (TPM) To determine safe operating thresholds, MM8108-based modules undergo thermal characterization in a controlled temperature chamber. During these tests, the module transmits continuously at maximum average power. At the same time, temperature readings are logged every second, tracking how the chip’s temperature rises toward a stable state or, if pushed too far, toward failure. This data is used to define two key thresholds: * the thermal protection activation temperature (Tp\_on), the point at which the protection mechanism activates to keep the chip within safe limits, and * the recovery temperature (Tp\_off), the point at which transmission is allowed to resume. Tp\_off is usually 5 oC lower than Tp\_on. An on-chip sensor provides a direct reading of the chip’s temperature (T\_chip), which can be read in real time via the `morsectrl stats` command. Before each transmission, the firmware checks the current chip temperature (T\_chip) against Tp\_on. If T\_chip is at or above Tp\_on, the firmware suspends transmission; it remains suspended until the chip cools to Tp\_off, at which point transmission resumes. Because the protection mechanism reacts dynamically to temperature, users may see variable, unpredictable throughput whenever it is engaged. In hotter ambient conditions, the chip reaches Tp\_on more quickly, so transmissions are suspended more often and overall data rates drop accordingly. In effect, the mechanism adapts the transmit duty cycle in real time to keep the chip’s temperature in check. In extreme heat, sustained operation can prevent the chip from ever cooling back to Tp\_off, leading to prolonged transmission gaps or total link disconnection. ## 3 Operational Impact This section and the table below explain the state of the Thermal Protection Mechanism (TPM) as it heats towards the key threshold temperatures. | State | Chip Temperature (T\_chip) | TPM Status | Transmission | | ----- | ---------------------------------------------------- | ---------- | ------------ | | 1 | T\_chip << Tp\_on | Off | Normal | | 2 | Tp\_off <= T\_chip <= Tp\_on (TPM not yet triggered) | Off | Normal | | 3 | T\_chip >= Tp\_on | On | Suspended | | 4 | Tp\_off <= T\_chip <= Tp\_on (TPM triggered) | On | Suspended | | 5 | T\_chip <= Tp\_off | Off | Normal | **Table 1: Thermal Protection Mechanism (TPM) states** States 2 and 4 differ in whether the TPM has been triggered and establish the hysteresis loop that the TPM relies on. For example, in a simple case of temperature rising and then falling, state 2 occurs as the temperature rises, while state 4 occurs as the temperature falls. * State 1: (T\_chip is much lower than Tp\_on) * The chip temperature is well below Tp\_on (e.g., \~20 oC in this example), so transmission continues as normal. * State 2: (T\_chip is between Tp\_off and Tp\_on, rising toward Tp\_on) * The chip temperature has risen but is still below Tp\_on, so the protection mechanism has not triggered and transmission continues as normal. * State 3: (T\_chip is at or above Tp\_on) * The chip temperature has reached Tp\_on, so the protection mechanism triggers and suspends transmission. With transmission stopped, the chip should begin to cool. * State 4: (T\_chip is between Tp\_off and Tp\_on, falling toward Tp\_off) * The chip continues cooling but has not yet reached Tp\_off, so transmission remains suspended. * State 5: (T\_chip is at or below Tp\_off) * The chip has now cooled to Tp\_off, so the protection mechanism switches off and transmission resumes. As transmission resumes, the chip temperature rises again, repeating the cycle. ## 4 Validation Testing Procedure This section details how the Thermal Protection Mechanism can be tested in a lab to confirm that it works as intended. ![Figure 1:  Measurement setup overview](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/9SxCxGUNMekJwOlRLHxi/Unknown%20image) *Figure 1: Measurement setup overview* To study the impact of the Thermal Protection Mechanism (TPM), an MM8108-based module is placed inside a temperature chamber. Figure 1 above shows the setup. The chamber is held at 55 oC while the module continuously transmits 1 MHz MCS 0 packets, and chip statistics are read every second. Figure 2 below plots the results: the blue curve shows the measured chip temperature, and the red curve shows the number of packets transmitted per second. From cold start (0 s), the chip temperature rises to around 88 oC after \~70 s. In this example, Tp\_on is set to 90 oC and Tp\_off to 85 oC. Once the chip temperature reaches Tp\_on, the TPM triggers and cycles between suspending and resuming transmission as described above, causing the red curve to fluctuate for the rest of the run instead of holding steady. Note that although the protection mechanism activates instantaneously once the chip temperature reaches 90 oC, logging temperature only once per second means the plotted curve does not always capture the exact instant this threshold is crossed. ![Figure 2: Chip temperature and transmitted packet count.](https://content.gitbook.com/content/RvJAAnftdO8KULGTT4Bk/blobs/V0c0AwfloAeoN8LcC5mS/Unknown%20image) *Figure 2: Chip temperature and transmitted packet count.* ## 5 Conclusion and recommendations A robust Thermal Protection Mechanism (TPM) is essential to preserve the SoC's operational lifespan and prevent it from entering an unstable state. As a result, users should expect time-varying throughput under extreme conditions, since the protection mechanism suspends transmission whenever the chip runs hot. In sustained high temperatures, this can also lead to prolonged transmission gaps or link disconnection. In firmware release 1.17.9, the activation threshold (Tp\_on) is set to 90 oC and the recovery threshold (Tp\_off) to 85 oC. In firmware release 2.0.0 and later, the Tp\_on threshold defaults to 125 oC and can be configured via BCF. Tp\_off is hardcoded to Tp\_on − 5 oC in firmware. ## 6 Revision History | Version Number | Release Date | Release Notes | | -------------- | ------------ | --------------------------------------------------------------------- | | 1 | 31 Aug 2026 | First release of thermal protection mechanism on MM8108 | | 2 | 04 Sep 2026 | Updated information related to BCF parameters and default thresholds. | Morse Micro provides this information "as is" without warranties of any kind, express or implied. No guarantee is made as to the accuracy, completeness, or suitability of this information or Morse Micro’s products for any specific purpose. Use of this information and products is at the user’s sole risk. Morse Micro products are not designed or tested for use in mission-critical systems, and should not be used in such applications. Performance specifications are based on internal testing and are believed to be reliable; however, they are not guaranteed. It is the Buyer’s responsibility to test and validate all product performance, compatibility, and compliance, both in isolation and within end applications. Morse Micro assumes no liability for the use or application of any product, circuit, or information described herein. No license or other rights—express or implied—are granted under Morse Micro’s intellectual property. This document contains proprietary information of Morse Micro and is subject to change without notice. Wi-Fi®, Wi-Fi HaLow™, and the Wi-Fi logo are trademarks of Wi-Fi Alliance. All other trademarks are the property of their respective owners. # Design guides Design guides provide hardware design recommendations, reference layouts, and integration guidance for Morse Micro products. ### Design guides #### [MM8108-MF15457 Hardware Design Guide](/design-guides/mm8108-mf15457-hardware-design-guide) Hardware integration guidance for the MM8108-MF15457 Wi-Fi HaLow module. # MM8108-MF15457 Hardware Design Guide v2 [Download as PDF](https://www.morsemicro.com/resources/design_packages/MM8108-MF15457_Hardware_Design_Guide.pdf) ## 1 Introduction The MM8108-MF15457 is a sub-GHz transceiver system-on-module (SoM) designed for long-range, low-power wireless communication using the IEEE 802.11ah standard. It integrates RF baseband, medium access control (MAC), and digital interfaces into a compact, low-power device optimized for embedded and Internet of Things (IoT) applications. The purpose of this document is to guide hardware integration of the MM8108-MF15457 into custom designs. It covers practical essentials, including power delivery, RF layout, and digital interfaces, to help engineers design products integrating HaLow Wi-Fi. This guide does not cover regulatory certification, application software, or system-level networking architecture. The following sections will focus on implementation details that are typically beyond the scope of high-level documentation. The goal is to complement the datasheet and reference designs by clarifying key layout, functional, and interface considerations relevant to hardware design. ## 2 System Planning and Preparation Time to market depends not only on design choices but also on the order in which they are made. Sequencing tasks so that items with upstream dependencies start early ensures that the necessary information is available when needed. When fundamental details regarding component selection, layout constraints, or system requirements are left unresolved until later, this can lead to redesigns or delays. Resolving these upfront prevents unnecessary blocking of progress. ### 2.1 Impedance Control Contact the PCB manufacturer early in the design process to obtain their recommended coplanar waveguide trace geometry, based on the dielectric constant, loss tangent, and dielectric thickness of their process. The MM8108-MF15457 is designed for 0.6 mm wide traces with 0.4 mm spacing, which makes a 50 Ω characteristic impedance achievable on a 2-layer board; however, a closely spaced ground plane will significantly reduce the need for tapering the main RF trace connection to the module, meaning that a 4-layer stackup can offer signal integrity benefits over a 2-layer design. For FR-4 fiberglass substrate, the thickness of the dielectric between the top copper and ground plane should be in the order of 0.2 mm to 0.4 mm. PCB trace geometry is often limited by the smallest-pitch component in the RF chain. It is advisable to identify these key RF components early and base the impedance-controlled layout around them. Components and connectors with pad widths near 0.6 mm are preferred, as they help minimize impedance mismatches caused by trace-width variation. Impedance calculation tools and formula-based estimators may be useful for approximating trace dimensions. However, these models are not necessarily derived from exact field solutions; many are empirical or quasi-empirical curve fits to simulation and measurement data. Manufacturers typically apply their own field solvers and impedance tuning, so collaboration with them is essential. Coordination with your PCB manufacturer should ideally occur before layout begins; otherwise, you may have to redo routing if trace geometries need to be adjusted later. When using multiple vendors, unique trace geometries are usually required for each vendor. Advanced simulation tools (full-wave 3D solvers) offer greater accuracy than equation-based methods by accounting for geometry, material variation, and board-specific features. This level of modeling is warranted when losses or impedance variations of less than 1 dB are significant to the application. ### 2.2 Component Availability Verify the long-term availability and lead times for critical components early in the design process. This ensures your product’s lifecycle won’t be jeopardized by supply issues or sudden obsolescence. Application examples are provided in Section 6 of this guide. These examples include component lists that may be used as proxies for budgetary purposes or followed directly if the design example matches your application. It can be helpful to address availability risks for rare or non-substitutable parts early in the design process, while deferring broader component ordering until after the PCB has been released for fabrication. This approach is applicable when component lead times are shorter than the PCB turnaround time, allowing part procurement to proceed in parallel with PCB fabrication. ### 2.3 Antenna Selection The antenna will both influence and be influenced by the final enclosure design, which, at the time of hardware design, is likely still evolving. An antenna’s performance depends heavily on its immediate surroundings, including the enclosure, internal cabling, external cabling, nearby metallic structures (including the PCB), and objects in the deployment environment. These factors should be kept in mind throughout the design process to avoid costly redesigns if performance issues are discovered late. It is advisable to obtain antenna samples and begin testing early, even while PCB design is underway. Return loss and radiation pattern (gain vs angle) should be measured using a setup that approximates the final enclosure and cabling. Be aware that changes to your enclosure, cables, or the surrounding environment may require a change in antenna selection, yet those elements themselves depend on a PCB layout that is still in development. This interdependency must be managed throughout development. #### 2.3.1 Antenna Connectors If the product interfaces with a standard 50 Ω RF connector (as opposed to an integrated PCB antenna), there are no specific preparation tasks to complete before design commences. The PCB designer's focus should be on maintaining a consistent 50 Ω impedance throughout the RF path using best-practice layout techniques. System-level testing should be considered early, as interactions among the antenna, enclosure, cabling, and nearby conductive structures will influence performance and shape choices regarding antenna type, connector placement, and enclosure design. #### 2.3.2 Off-The-Shelf Antennas When selecting an off-the-shelf antenna for a Wi-Fi HaLow (IEEE 802.11ah) module, it is critical to ensure compatibility with the sub-GHz frequency range (typically 860 to 930 MHz, depending on the region) and a bandwidth of at least 8 MHz (depending on the region). Wi-Fi HaLow operates on a wider bandwidth than other common ISM-band technologies (such as LoRa), so care must be taken to check the antenna's operating bandwidth if it is advertised for use with one of these other technologies. For general-purpose deployment and consistent coverage, a dipole antenna is recommended due to its omnidirectional radiation pattern in the azimuth plane. This facilitates uniform signal strength around the antenna, which is ideal for applications where client devices can be readily distributed. Key parameters to consider include antenna gain (typically 1 to 3 dBi for dipoles), connector type (must match the end-product’s or module’s RF interface), mechanical form factor, and environmental rating. #### 2.3.3 Electrically Small Antennas At 915 MHz, antennas shorter than approximately 30 mm are considered electrically small. Designs in this range are especially difficult, with significant trade-offs in efficiency, bandwidth gain, and susceptibility to detuning from nearby materials. More generally, any antenna smaller than a quarter wavelength (approximately 80 mm) should be approached with caution. As physical size decreases below this point, impedance matching becomes more sensitive, performance becomes less predictable, and it becomes more dependent on enclosure design and nearby conductors. Early validation and testing are strongly recommended for antennas below this size threshold. Plan for extensive impedance matching, validation, and possibly iterative tuning of the matching network and physical layout to ensure acceptable performance. #### 2.3.4 PCB Antennas The performance of a PCB antenna design depends on the manufacturing process, PCB material, enclosure, cabling, and other nearby structures. Design parameters, such as the required gain for the PA and LNA, and the recommended matching topology, are best determined with knowledge of the antenna’s impedance and radiation characteristics. It is recommended to plan to design and build early prototypes specifically for antenna evaluation, even before laying out the full product. These can include the enclosure, dummy connectors, cabling, and the antenna section, while omitting other circuitry. Such setups enable return-loss and antenna-pattern measurements that put the design in the right ballpark. While further adjustments may be expected, this process reduces uncertainty and enables more informed decisions before significant investment in the final layout. ## 3 Module Pinout This section provides the details required to create a PCB footprint and schematic symbol for the MM8108-MF15457. It includes a visual overview of the module land pattern and a table of pin functions. ### 3.1 Component Land Pattern Square pads of uniform size and spacing are recommended. ![Figure 1: Land pattern for the MM8108-MF15457 module](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/uceYM2l9wXhG1REfBa5Y/Unknown%20image) *Figure 1: Land pattern for the MM8108-MF15457 module* Dimensions are provided in mm. Alternative dimensions in mil (thou) have been provided for convenience. Where ambiguity exists (due to rounding, for example), the mm dimensions should be treated as the source of truth. | | | | | ---------------- | -------------- | --------------- | | Key | Dimension (mm) | Dimension (mil) | | Package X | 11.0 | 433 | | Package Y | 10.0 | 394 | | Pad X | 0.6 | 24 | | Pad Y | 0.6 | 24 | | Pad Spacing X | 1.0 | 39 | | Pad Spacing Y | 1.0 | 39 | | Package to Pad X | 0.5 | 20 | | Package to Pad Y | 0.5 | 20 | **Table 1: Key Dimensions associated with Figure 1** ### 3.2 Schematic Symbol The diagram below shows a top view of the module package with each pin numbered and labeled. Pins are numbered clockwise around the package. Signal names are annotated alongside each pin. ![Figure 2: Diagram showing pinout information for the MM8108-MF15457 module](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/C8pzl2nLJlCleWkHQfnP/Unknown%20image) *Figure 2: Diagram showing pinout information for the MM8108-MF15457 module* An example schematic element is provided below, with pins approximately grouped by function. ![Figure 3: Schematic symbol showing pinout information for the MM8108-MF15457 module](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/HBIgj7xLHOSqF0BxwhZM/Unknown%20image) *Figure 3: Schematic symbol showing pinout information for the MM8108-MF15457 module* The table below lists all pads, along with their signal names, electrical types, and functional descriptions. The "Type" column identifies each signal’s role, such as an analog interface, a power supply, or a ground return, to support interpretation during circuit design and layout. Descriptions are included to clarify functionality, particularly where the signal name alone may not indicate intended use. | | | | | | | --- | --------- | ----------- | --------------------------------------------- | ----------- | | Pin | Name | Type | Function | Alternative | | 1 | GND | Ground | Ground | | | 2 | ANT | Analog | Antenna | | | 3 | GND | Ground | Ground | | | 4 | RESET\_N | Digital I/O | Asynchronous chip reset (active low) | | | 5 | WAKE | Digital I/O | External wake from Deep Sleep and Snooze | | | 6 | JTAG\_TMS | Digital I/O | JTAG Mode Select | GPIO15 | | 7 | JTAG\_TCK | Digital I/O | JTAG Clock | GPIO13 | | 8 | JTAG\_TDO | Digital I/O | JTAG Data Out | GPIO16 | | 9 | JTAG\_TDI | Digital I/O | JTAG Data In | GPIO14 | | 10 | VDD | Supply | 3.3V Supply | | | 11 | GND | Ground | Ground | | | 12 | SDIO\_D0 | Digital I/O | SDIO Data Line | SPI\_MISO | | 13 | SDIO\_D3 | Digital I/O | SDIO Data Line | SPI\_CS | | 14 | SDIO\_D1 | Digital I/O | SDIO Data Line | SPI\_INT | | 15 | SDIO\_D2 | Digital I/O | SDIO Data Line | | | 16 | SDIO\_CMD | Digital I/O | SDIO Command Line | SPI\_MOSI | | 17 | SDIO\_CLK | Digital I/O | SDIO Clock Input | SPI\_SCK | | 18 | GPIO5 | Digital I/O | Programmable digital I/O | | | 19 | GPIO4 | Digital I/O | Programmable digital I/O | | | 20 | GND | Ground | Ground | | | 21 | GPIO3 | Digital I/O | Programmable digital I/O | | | 22 | VDDIO | Supply | Host Supply for digital I/O | | | 23 | GND | Ground | Ground | | | 24 | VDD\_TX | Supply | 3.3V Supply | | | 25 | VDD\_USB | Supply | 3.3V USB Supply | | | 26 | GND | Ground | Ground | | | 27 | USB\_DN | Digital I/O | USB D- Line | | | 28 | USB\_DP | Digital I/O | USB D+ Line | | | 29 | BUSY | Digital I/O | The module is transmitting or processing data | | | 30 | GND | Ground | Ground | | | 31 | GPIO1 | Digital I/O | Programmable digital I/O | | | 32 | GPIO0 | Digital I/O | Programmable digital I/O | | | 33 | GPIO6 | Digital I/O | Programmable digital I/O | | | 34 | GPIO7 | Digital I/O | Programmable digital I/O | | | 35 | GPIO8 | Digital I/O | Programmable digital I/O | | | 36 | GPIO9 | Digital I/O | Programmable digital I/O | | | 37 | GPIO10 | Digital I/O | Programmable digital I/O | | | 38 | GND | Ground | Ground | | **Table 2: MM8108-MF15457 pin descriptions** ## 4 Schematic Design An example schematic design is shown below. It includes all critical components for a typical MM8108-MF15457 design. ![Figure 4: Typical application schematic for the MM8108\_MF15457 and surrounding circuitry](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/u5CKC20VxZQv7kN2tyGL/Unknown%20image) *Figure 4: Typical application schematic for the MM8108\_MF15457 and surrounding circuitry* A recommended schematic design workflow is to begin with the RF signal path, followed by the USB signal path. Once these are in place, complete the power supply, decoupling capacitors, I/O configuration, diagnostics, and protection circuitry. ### 4.1 Radio Frequency The RF section should be the primary design consideration. It is the device's core functionality and one of the more challenging aspects of the design. #### 4.1.1 Impedance Control RF nets between the module and antenna should be designated as impedance-controlled (50 Ω characteristic impedance) in the schematic editor to ensure that the correct routing constraints are applied during layout. #### 4.1.2 Antenna and Associated Matching If an off-the-shelf 50  Ω antenna is used (or the RF output is simply routed to a 50  Ω connector), then matching is not required; the best performance is achieved by routing directly, with a short trace from the RF output to the connector. However, many designers choose to include a placeholder pi or tee network. This introduces a performance trade-off (wider pads, extra trace length, and additional components leading to added mismatch, loss, and cost) in exchange for the flexibility that, if issues arise later in the development process, these footprints may allow for filtering or attenuation. ![Figure 5: A pi network](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/P2veWCk80ZANfLgRqWbE/Unknown%20image) *Figure 5: A pi network* If the antenna is not 50 Ω (as is often the case with electrically short PCB antennas), impedance matching becomes mandatory. A generic pi or tee network can be included to facilitate matching, which poses minimal effort for a roughly matched system. However, the optimal matching circuitry will depend on the antenna's exact impedance, including the PCB, the enclosure, and the deployment scenario. It is advisable to produce antenna-only PCB prototypes and utilize a VNA to measure the system performance; this data will be needed to implement optimized front-end matching. Antenna Design Considerations: When designing a small-form-factor PCB antenna, changes in antenna geometry will affect the load presented by the antenna (i.e., the unmatched antenna). To the extent this may be influenced by design decisions, the top region of the Smith chart is recommended (Figure 6), as it can be matched purely capacitively, which behaves more ideally (exhibiting less loss and less magnetic coupling) than inductive matching. ![Figure 6: Target impedance region on the Smith chart for small-form-factor PCB antennas](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/2wzHVKnKU01hu32rrDCM/Unknown%20image) *Figure 6: Target impedance region on the Smith chart for small-form-factor PCB antennas* ### 4.2 Radio Frequency Front End For most applications, the only component required at the antenna port is a single 50 Ω antenna operating from 902 MHz to 928 MHz (or 863 MHz to 868 MHz in the EU). Advanced applications may wish to apply additional circuitry, the discussion of which is outside the scope of this hardware design guide. ### 4.3 Universal Serial Bus The USB design considerations are discussed here (rather than in Section 4.6) so that USB signals are considered early and given high design priority. Signal integrity considerations for USB should be addressed early in the design process to produce a more reliable and robust product. You should treat the USB signals as the second priority, where RF traces are the highest priority. An example schematic layout for USB host interfacing is provided below: ![Figure 7: USB host interface to the MM8108-MF15457](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/u5CKC20VxZQv7kN2tyGL/Unknown%20image) *Figure 7: USB host interface to the MM8108-MF15457* USB nets between the module and connector must be designated as length-matched to within 100 ps (where 1 mm is recommended) and impedance-controlled (90  Ω differential characteristic impedance) in the schematic editor to ensure the correct routing constraints are applied during layout. For USB-C, the CC lines should be designated as impedance-controlled (50 Ω characteristic impedance), and these signals should receive particular attention to schematic design elements that may produce reflections on the signal line. ⚠️USB signal integrity issues can be particularly hard to find because they often result in subtle non-specific error modes such as slower data rates or intermittent unexpected behavior; as such, it is recommended that they be designed with best practice principles to avoid difficulty later. Specific care should be taken when placing any components in series with the USB lines (such as ESD protection or switching). These components must be specifically designed for USB 2.0 applications, as general-purpose components can significantly degrade USB signal integrity. ### 4.4 Decoupling Capacitors The VDD, VDD\_TX, and VDD\_USB pins should be decoupled with 10 μF and 100 nF ceramic capacitors, each rated for at least 6.3 V. Either X7R or X5R capacitors are recommended. ![Figure 8: Decoupling capacitors required for VDD, VDD\_TX, and VDD\_USB](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/8jyejqH5hDao52UUr8bV/Unknown%20image) *Figure 8: Decoupling capacitors required for VDD, VDD\_TX, and VDD\_USB* ![](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/IER5I3sf2tR9OaxB7f06/Unknown%20image) ![](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/sNISKOhNSokI0nfGtwao/Unknown%20image) The VDDIO pin should be decoupled with a 100 nF ceramic capacitor, rated for at least 6.3 V. Either X7R or X5R capacitors are recommended. ![Figure 9: Decoupling capacitor required for VDDIO](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/aai6X5ro8daMX6b5TO8O/Unknown%20image) *Figure 9: Decoupling capacitor required for VDDIO* ⚠️Note: the effective capacitance of ceramic capacitors can drop significantly under applied DC bias, especially in smaller packages. For example, a nominal 4.7 µF capacitor in a 0402 package may deliver less than 2 µF at 3.3 V. When selecting capacitors for bulk storage, consult the manufacturer’s bias derating curves to ensure that sufficient capacitance remains available under load. If necessary, use a larger case size or a higher voltage rating to reduce the percentage loss. ### 4.5 Power Supply The performance of the MM8108-MF15457 depends critically on the quality and stability of its power supply. While the device includes internal regulators to generate the required internal voltages, it is sensitive to droop, ripple, and noise on the primary voltage supply. ![Figure 10: Simplified system block diagram showing power path](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/25sQ6kOYP9vMLDLzk9a4/Unknown%20image) *Figure 10: Simplified system block diagram showing power path* The voltage supply should remain within the 3.0 to 3.6V range across all load conditions (from sleep currents to peak TX current) and under expected variations in input supply. Gradual shifts in the power supply voltage (e.g., from a discharging battery) are tolerated by the internal LDO and buck converters. However, high-frequency noise on the supply remains a critical consideration for RF performance. Note that VDDIO is tolerant of voltages as low as 2.25 V. Appropriate level-shifting circuitry must be used when interfacing with systems operating at lower voltages (such as 1.8 V). The MM8108-MF15457 is typically powered by an external voltage regulator, which should have an output ripple below 30 mV peak-to-peak and supply at least 500 mA continuously. If a switch-mode power supply is used, it is strongly recommended to include a footprint for an RF shielding can that fully encloses its perimeter. This allows a shield to be fitted, if required, to suppress radiated emissions and preserve receiver sensitivity. ### 4.6 Interfacing #### 4.6.1 USB Universal serial bus signal integrity considerations are discussed in Section 4.3. #### 4.6.2 SDIO / SPI The MM8108-MF15457 supports SDIO and SPI communication (depending on which firmware is loaded). Information about the hardware pin configuration is given in the following table. | | | | | | | --- | --------- | ----------------- | --------------- | --------- | | Pin | Name | SDIO 4-bit mode | SDIO 1-bit mode | SPI mode | | 12 | SDIO\_D0 | Data pin 0 | Data pin | SPI\_MISO | | 13 | SDIO\_D3 | Data pin 3 | - | SPI\_CS | | 14 | SDIO\_D1 | Data pin 1 | IRQ | SPI\_INT | | 15 | SDIO\_D2 | Data pin 2 | - | 1 | | 16 | SDIO\_CMD | Command pin | | SPI\_MOSI | | 17 | SDIO\_CLK | Clock pin (input) | | SPI\_SCK | **Table 3: Pinout for SPI and SDIO interfacing** 1 In SPI mode, SDIO\_D2 must be pulled high via an external pullup resistor. ⚠️ Note: A typical SPI clock speed is 25 MHz. Take extra care if any clocks in your design operate at or near this frequency. The 37th harmonic of 25 MHz is 925 MHz, which falls within the sub-1 GHz bands used by Wi-Fi HaLow. ⚠️ Morse Micro doesn't recommend SPI bus sharing with other peripheral devices. **4.6.2.1 SPI** An example schematic layout for SPI host interfacing is provided below. ![Figure 11: SPI host interface to the MM8108-MF15457](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/VsxGhuxLrIJqmvq6Qb1l/Unknown%20image) *Figure 11: SPI host interface to the MM8108-MF15457* When selecting a host to interface with the MM8108-MF15457 module via the SPI interface, consider the following recommendations to achieve the best throughput: * The host must support level-triggered interrupts. * The host must support full-duplex SPI mode. * The host must support DMA-backed transactions on the SPI bus. Standard SPI can achieve up to 25 Mbps at 50 MHz, but without DMA support, performance will be significantly reduced. For example, an SPI interface with an 8-byte buffer per transaction might achieve only 2 Mbps of throughput on the SPI bus. For proper operation and to take advantage of the module’s power-saving features, connect RESET\_N and WAKE to standard digital outputs (CMOS logic levels). The BUSY signal should be connected to a digital input (also CMOS-level). Do not use open-collector or open-drain circuits, as they will cause incorrect behavior. **4.6.2.2 SDIO** An example schematic layout for SDIO host interfacing is provided below. ![Figure 12: SDIO host interface to the MM8108-MF15457](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/zmB0mAl7FF6gpxzr2Snp/Unknown%20image) *Figure 12: SDIO host interface to the MM8108-MF15457* The SDIO\_CLK line must not include a pull-up resistor. The remaining SDIO lines (SDIO\_CMD, SDIO\_D0, SDIO\_D1, SDIO\_D2, and SDIO\_D3) must be pulled up to VDDIO with 10 kΩ to 100 kΩ resistors. The responsibility for providing these resistors falls on the host side; however, if the host does not provide them or their implementation is uncertain, it is acceptable to place the resistors on the peripheral side (the MM8108-MF15457) to ensure correct logic levels. SDIO traces should be routed with 50 Ω characteristic impedance. Basic length matching to within 10 mm is also required. If signal integrity issues are observed, such as excessive trace length or overshoot, series damping resistors in the range of 10 Ω to 100 Ω may be beneficial. When signal behavior is unknown at design time, footprint provisions for 0 Ω resistors can be included to preserve the option to correct signal-integrity issues discovered during verification. As a layout best practice, place SDIO devices close enough that transient pulses arising from any impedance mismatch will resolve well within a clock cycle. It is recommended that the SDIO trace length be kept under 50 mm to minimize signal integrity concerns. ![Figure 13: Placeholder series damping resistors for SDIO](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/9sSg2AfE0OQ9tNqm6yvB/Unknown%20image) *Figure 13: Placeholder series damping resistors for SDIO* When multiple host controllers are supported through different build options, it is critical to include explicit 0 Ω resistors (or similar jumpers) to disconnect unused signal paths from the SDIO lines. Simply leaving an unused host controller interface unpopulated is not enough; the signal traces should be physically isolated to prevent unterminated stubs that can cause signal reflections and degrade SDIO signal integrity. ![Figure 14: Selection of SDIO host controller via 0 Ω resistors](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/fAiICNlBcq9tMKibPFfj/Unknown%20image) *Figure 14: Selection of SDIO host controller via 0 Ω resistors* For host controllers operating at IO below 2.5 V, level shifters are recommended when interfacing with the MM8108-MF15457. Figure 15 demonstrates an example circuit layout using the Texas Instruments TXS02612, which can level-shift SDIO signals down to 1.1V. ![Figure 15: SDIO level shifting circuit](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/PQ3ThIFwn9eRVUGRMhGT/Unknown%20image) *Figure 15: SDIO level shifting circuit* #### 4.6.3 GPIO GPIO may be used in specialized applications and are not user-programmable. Most GPIO signals operate at low speeds and do not typically require strict routing constraints for signal integrity. However, in applications with high edge rates, attention should be paid to trace length, return-path continuity, and termination. **4.6.3.1 WAKE Pin Considerations** The wake pin allows an input signal into MM8108-MF15457 to bring the module out of deep sleep and snooze modes. This is part of the VDD analog domain and cannot be driven by anything below 3.0 V. Caution is required when the host controller operates with VDDIO below 3.0 V to ensure appropriate level-shifting is used when driving WAKE. **4.6.3.2 RESET\_N Pin Considerations** The active-low reset pin should be connected to a power-on reset network consisting of a 220 kΩ pull-up resistor and a 2.2 µF capacitor to ground. This ensures that the MM8108-MF15457 is properly initialized upon power-up. The RESET\_N pin can also be driven low by an external device to reset the device. ### 4.7 Diagnostics #### 4.7.1 Preferred Diagnostics For robust design and enhanced troubleshooting capability, it is advisable to include a 16-pin header (Morse Micro uses the Samtec FTSH-108-01-F-D-K) with the pinout shown below to enable diagnostic access. ![Figure 16: Standard pinout for diagnostics connector](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/KSeBOBa1eo53vNEkppVq/Unknown%20image) *Figure 16: Standard pinout for diagnostics connector* The following pin configurations are recommended: | | | | | --- | -------------- | ------------------------------ | | Pin | Net | Description | | 1 | VDDIO | Digital domain power rail | | 2 | GND | Ground | | 3 | MM\_JTAG\_TDI | JTAG TDI | | 4 | MM\_JTAG\_TDO | JTAG TDO | | 5 | MM\_JTAG\_TCK | JTAG TCK | | 6 | MM\_JTAG\_TMS | JTAG TMS | | 7 | MM\_JTAG\_TRST | JTAG Test Reset (Not required) | | 8 | MM\_RESET\_N | Device Reset | | 9 | MM\_GPIO2 | Debug | | 10 | MM\_GPIO3 | Debug | | 11 | MM\_SD\_CLK | SPI CLK | | 12 | MM\_SD\_CMD | SPI MOSI | | 13 | MM\_SD\_D0 | SPI MISO | | 14 | MM\_SD\_D3 | SPI CS | | 15 | - | Not connected | | 16 | MM\_WAKE | Wake up | **Table 4: Standard pinout for diagnostics connector** #### 4.7.2 Reduced Diagnostics In designs where a full diagnostics header is not feasible, a reduced interface is supported. This consists of a 10-position 1.27mm pitch connector with the following connections: ![Figure 17: Pinout for alternative diagnostics connector](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/0jNsEj0VkaeJamYStWbH/Unknown%20image) *Figure 17: Pinout for alternative diagnostics connector* ![](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/Z58u9sQT6W6Mlz3Uovw3/Unknown%20image) A diagnostics port is not required for normal device operation. However, if no debug access is provided in the design, Morse Micro's ability to support, diagnose, or resolve technical issues will be reduced. ### 4.8 Protection This section refers to protection against unexpected conditions, such as electrostatic discharge (ESD), reverse polarity, overvoltage, overcurrent, brownout, etc. Standard best-practice ESD protection is recommended on all nets exposed to the external environment. This includes placing protection at the outermost connectors rather than directly at the MM8108-MF15457 pins. Avoiding ESD components on the RF trace helps preserve signal integrity by minimizing parasitic shunting and impedance discontinuities. For the antenna trace in particular, 1 kV of ESD protection is already provided by the module. If additional ESD protection is required, the selected TVS diode must have an input capacitance less than 0.2 pF, and its footprint should preserve controlled-impedance geometry without introducing abrupt transitions on the PCB RF trace. The MM8108-MF15457 is rated for 3.0 to 3.6 V. For nominal operation at 3.3 V, clamping the supply voltage to 3.4 to 3.6 V is sufficient to protect the device from supply transients. The module does not include reverse-polarity protection, so this must be implemented externally in systems where reverse polarity may occur (for example, when a user inserts a battery backward). When adding voltage clamping or reverse-polarity protection to a design, consider any trade-offs, such as increased leakage current. This is particularly important for low-power or battery-operated applications, where minimizing power consumption is critical. ## 5 PCB Layout The following sections of this guide are organized to match the recommended workflow for a PCB layout engineer, addressing each area in turn, starting with placement, then routing, from the most critical elements (RF) down to the least (GPIO). By completing one section before moving to the next, this process naturally ensures that the most important parts receive the most favorable design trade-offs. ### 5.1 Radio Frequency The RF section should be the primary consideration in the layout. It’s recommended to route it first to ensure it naturally receives the most favorable design trade-offs. #### 5.1.1 Placement Guidelines It is advisable to start by placing the antenna, followed by any other RF components (if applicable), and then the Wi-Fi HaLow transceiver module. This allows the RF section to be tightly packed with short, direct traces. During this process, many design trade-offs will emerge. The following section outlines the key considerations when placing the RF components. **5.1.1.1 Path Length** Place RF components close to keep traces as short as possible. This will reduce insertion loss, improve transient settling, and minimize electromagnetic interference. Longer traces introduce greater resistive and dielectric loss, which reduces efficiency. A shorter trace also limits the round-trip path for reflections, allowing signals to settle more quickly after a transition. Shorter paths reduce the physical aperture available for radiated emissions or coupling to adjacent circuitry. As a guideline, RF traces should be kept significantly shorter than one-tenth of the signal wavelength in the PCB dielectric. For typical coplanar waveguide or microstrip traces on FR4 at 915 MHz, this corresponds to approximately 15 mm. Traces longer than this threshold require greater attention to impedance control and layout. However, minimizing length is beneficial in all cases: Ohmic and dielectric losses scale directly with trace length, and even short traces exhibit improved efficiency and reduced insertion loss. **5.1.1.2 Current Loops** Orient and place components that connect to ground (like decoupling capacitors or terminations) so their ground pads are as close as possible to vias or traces leading to the ground plane. Minimize the area enclosed by the signal and its return path, as this reduces loop inductance and magnetic coupling. Component placement should ensure that PCB traces are not routed beneath the antenna, RF feedline, and any other RF front-end circuitry. **5.1.1.3 Separation from Noise Sources** Keep RF components and traces well separated from all other circuitry. As a general guideline, maintain at least 10 mm of clearance from other components and traces, and maximize the distance from switching regulators, high-speed digital lines, and potential electromagnetic interference sources. Layout choices should prioritize clean isolation, especially in sensitive receive paths or matched impedance networks, because even low-level coupling can degrade performance. It is advisable to define explicit keep-out zones around RF traces, matching networks, and the RF front-end module to prevent electromagnetic coupling and preserve circuit isolation. **5.1.1.4 Parasitic Impedances** When placing RF components, remember that PCB traces introduce parasitic inductance, while component pads add parasitic capacitance. Extra trace length is generally less critical for inductors, just as added copper area has less impact on capacitors. Knowing in advance whether a matching network will require inductors or capacitors (rather than relying on generic pi or tee footprints) allows placement and routing to minimize parasitic inductance at capacitors and parasitic capacitance at inductors. **5.1.1.5 Inductor Considerations** Careful placement and orientation of inductors is essential to minimize magnetic coupling, which can degrade RF performance or inject noise into sensitive circuits. When multiple inductors are used in close proximity (such as RF matching inductors and DC-DC converter inductors), their coils should be oriented orthogonally. Avoid placing inductors with parallel coil axes, as this maximizes coupling. Maintaining physical separation between inductors further reduces the risk of coupling. These considerations are especially important during RF reception, when the system is most sensitive to low-level noise. In this state, any coupling between switching inductors and RF paths can compromise receiver performance. In particular, inductors inside matching circuits can act as antennas that pick up radiated noise. **5.1.1.6 Matching Component Considerations** Matching components should be placed as close as possible to the unmatched element (e.g., the antenna). PCB traces before (or between) the matching components should not be viewed as conventional 50 Ω transmission lines, so keeping these traces to a minimum length reduces unwanted impedance transformation. Some advanced matching techniques may intentionally introduce phase shifts using this approach; however, such techniques are outside the scope of this guide. **5.1.1.7 PCB Antenna Considerations** Follow the antenna manufacturer’s recommended keep-out dimensions carefully and measure antenna performance (including return loss and radiation pattern) as part of the design process. Keep in mind that PCB layout, nearby structures, and the enclosure can significantly influence antenna behavior, and the specific interactions of your product are not captured in the antenna datasheet. **5.1.1.8 Shielding Considerations** The MM8108-MF15457 comes with an RF shielding can over the RF circuitry, and additional Wi-Fi HaLow RF shielding is usually not required, except in advanced applications. Switch-mode power supplies may require additional shielding cans. Keep in mind that inductors are particularly prone to radiating and receiving noise, and during RF receive, even low-level coupled noise can degrade sensitivity or introduce spurious responses. The shield should fully enclose the sensitive region, with a solid via-stitched ground perimeter to ensure good RF sealing. Large openings or poorly grounded shields can significantly compromise effectiveness. The primary purpose of shielding is to prevent emissions from other system components (particularly high-speed digital switching, or RF) from coupling into the antenna path and degrading receiver sensitivity. The device can detect down to –107 dBm, so even very weak internal emissions can raise the noise floor and limit system performance. Effective shielding should form a continuous seal. The limiting factor in shielding effectiveness is typically the largest dimension of any aperture or discontinuity in the shield, not the overall coverage percentage. Shielding with large openings often provides little benefit and can introduce resonances or coupling paths that degrade performance. At 915 MHz (λ ≈ 328 mm), the reactive near field extends approximately 50 mm from any source of interference. Within this region, electromagnetic energy can couple into the antenna even in the absence of a direct line-of-sight path (fields can diffract, wrap around shielding edges, or penetrate narrow slots). #### 5.1.2 Routing Guidelines Once component placement is complete, begin routing the RF traces. Each RF trace can significantly impact system performance and EMC/EMI compliance, so route them with particular care and deliberate thought. The major considerations are detailed in the following section. **5.1.2.1 Impedance Control** In Section 2.1, we recommend that you commence communications with your PCB manufacturer early in the design process to establish the required PCB routing rules. In Section 4.1.1, we recommend that you designate RF nets as 50 Ω in your schematic design tool. Now that you are routing the PCB traces, we trust you have heard back from your manufacturer. Be sure to apply these routing rules to the 50 Ω characteristic impedance Wi-Fi HaLow signal traces. **5.1.2.2 Bend Angle** Smoothly curved or 45° bends in RF traces are preferred. Sharp corners can introduce discontinuities, so gradual transitions are recommended to support consistent impedance and clean signal propagation. A 45° bend or continuous curve provides a more uniform current path, reducing the chance of localized reflections or unintended radiation. **5.1.2.3 Reference Plane Integrity** Route RF traces exclusively over an uninterrupted ground plane; do not place RF traces over plane splits, gaps, other traces, or isolated copper pours. An unbroken ground plane provides a consistent return path directly beneath the RF trace, which is essential for stable impedance and minimizing unintended radiation. **5.1.2.4 Via Usage and Transitions** RF paths should remain on the outermost copper layer and avoid layer transitions via vias. Routing RF traces entirely on the surface avoids introducing impedance discontinuities and parasitic via inductances. Layer changes inherently degrade signal integrity and are strongly discouraged in RF paths. If an unavoidable mechanical constraint forces a layer change, only then should a single, properly sized via be used, with minimal stub length, and impedance-matched barrel and antipad dimensions. **5.1.2.5 Via Shielding** Coplanar waveguide (CPW) traces should be flanked on both sides by a continuous fence of closely spaced ground vias. This via fencing confines the electromagnetic fields, suppresses parallel-plate modes, and maintains a robust, continuous return path, thereby minimizing undesired coupling and radiation. Vias should be positioned as close as possible to the edge of the CPW ground plane metal; ideally, within 0.5 to 1.0 mm. Denser via spacing improves mode suppression and helps ensure consistent impedance and field confinement along the CPW structure. **5.1.2.6 Thermal Relief and Power-Plane Intersections** For optimal signal integrity, ground vias associated with RF signals should use a solid copper pour rather than thermal relief patterns. This ensures the lowest possible return path impedance and minimizes parasitic effects. However, solid vias can conduct significant heat during soldering, potentially causing assembly challenges or unreliable joints. Thermal reliefs alleviate this risk by limiting heat conduction, but at the expense of RF performance. We recommend retaining a solid ground connection and addressing assembly concerns through process tuning or other local design adjustments. **5.1.2.7 Component Pad Transitions** When transitioning to a wider pad, an abrupt, well-controlled impedance transition is generally preferable, particularly when coordinated with an appropriate ground return (such as removing some ground layers under the pad, if needed). Tapered transitions may look cleaner, but often do not improve impedance matching and can worsen reflections. ![Figure 18: Transition from RF trace to SMA connector](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/CnBINxsgo79uRFegq4Ak/Unknown%20image) *Figure 18: Transition from RF trace to SMA connector* ![](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/sTcxMO7xKjmLj6cMAd6H/Unknown%20image) In the example shown in Figure 18, the RF feedline is designed for a 50 Ω characteristic impedance, referenced to an internal ground plane. However, the RF connector pad is significantly wider than the feedline. To maintain the 50 Ω impedance at this interface, the internal ground layers beneath the pad are removed, shifting the reference plane to the bottom layer. On the left, an abrupt transition is shown in which the trace width and ground reference shift simultaneously, preserving a consistent 50 Ω impedance across the transition. On the right, a tapered trace is used instead. As the trace widens while still referenced to the internal plane, the impedance gradually drops below 50 Ω before returning to that value once the bottom-layer ground plane takes over at the pad. This non-uniform impedance can introduce reflections and degrade RF performance. The best results are achieved by avoiding unnecessary trace width discontinuities altogether. Selecting components, such as 0402 passives, and connectors whose pad dimensions are as close as possible to the desired trace width is recommended. However, the trace width is also typically constrained by the need to mate with the device's interface geometry (e.g., the required pad or bump size), which may impose a minimum trace thickness. In practice, the thinnest component pad width often determines the trace width, which in turn defines the PCB stackup and transmission line type (e.g., CPW or microstrip). Transitions to larger connector geometries (such as SMA or U.FL) can introduce impedance discontinuities due to pad sizes that differ from the RF trace width. These transitions should ideally be measured using a vector network analyzer to verify return loss and ensure acceptable matching. While a full 3D electromagnetic simulation is not mandatory, it can be a valuable tool for predicting performance and reducing the number of layout iterations needed to optimize RF performance. ### 5.2 Universal Serial Bus With data rates up to 480 Mbps, USB signals are 240 MHz radio-frequency signals and should be treated as such. As a digital signal protocol, signal losses can be mitigated or recovered, making signal loss less critical (compared to an RF antenna trace), but the differential-signal nature means that length matching becomes an important consideration. USB signals must be routed according to the length-matching and impedance-control rules defined in Section 4.3. For USB-C, abrupt transitions in the CC signal traces (including using vias) should be avoided wherever possible. Any imperfections in these signal traces can cause reflections to the host controller, which may incorrectly interpret the discontinuity as indicating no peripheral device is connected. ### 5.3 Decoupling After the RF traces, the next most important consideration is the bypass capacitors. Standard best-practice principles apply, as discussed in the following section. Figure 19 illustrates a typical layout. ![Figure 19: Decoupling capacitor placement](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/TseEOiiLf7bXDycSLwY4/Unknown%20image) *Figure 19: Decoupling capacitor placement* #### 5.3.1 Placement Guidelines Decoupling capacitors are most effective when placed to minimize loop area between the capacitor and its associated supply pin. All capacitors should be located as close as practical to their associated pins or supply nodes. When multiple capacitors are placed in parallel on the same pin (for example, a 100 nF capacitor alongside a 4.7 µF capacitor), it may be acceptable to place them side by side or stack them vertically (i.e., on opposite sides of the PCB with a via connection). What matters most is minimizing the inductance of the conductance path and ensuring both capacitors return to a solid ground plane. For designs with long or resistive VDD supply paths, placing sufficient bulk capacitance close to the device is especially important to ensure that transient current demands are met locally. #### 5.3.2 Routing Guidelines Use short, wide copper traces for both power and ground. A ground via should be placed as close as practical to the capacitor ground terminal to connect directly to a continuous ground plane located on the layer below the chip. This ground plane must be unbroken within the area enclosed by the module's outermost grounding vias and decoupling capacitors to provide a well-defined, low-impedance current-return path. ### 5.4 Power Supply With the decoupling capacitors in place, it is now time to turn our attention to the rest of the power supply architecture. #### 5.4.1 Placement Guidelines Placement should aim to minimize both power-supply noise and series resistance. Any noise on the power supplies may be coupled into the RF section of the design and then radiated out of the antenna. This can impact receive sensitivity and also cause the device to fail certification testing. **5.4.1.1 Equivalent Series Resistance** Equivalent series resistance (ESR) may be reduced by placing the power supply, particularly a low-dropout regulator (LDO), close to the VDD pin. **5.4.1.2 Separating Noisy Sources from Sensitive Circuitry** If using a switch-mode power supply, place it as far from the HaLow module as practical. This applies broadly to any circuitry generating high-frequency currents through inductors or ground paths. If ESR in the main supply path is a concern, providing a Kelvin connection to the voltage feedback pin can help mitigate voltage drops. #### 5.4.2 Routing Guidelines The routing of power supply traces directly influences voltage stability, noise coupling, and the effectiveness of decoupling under dynamic loads. The major considerations are detailed in the following section. **5.4.2.1 Star Topology Distribution** Keep all common-mode impedance to a minimum. Power distribution should avoid daisy-chaining and instead use a star-point or short branch to deliver equal-quality supply to each load. This is required for VDD, VDD\_TX, and VDD\_USB, which serve distinct functional domains and must be routed independently from a shared node. Each branch must include its own local decoupling network placed close to the associated power pin. The physical layout should favor short, direct traces from the star point to each load. First, route traces to the capacitor pads, and then to the device pin. **5.4.2.2 Trace Width and Thickness** Power supply traces should be designed for both low resistance and low inductive impedance to support fast current transients without significant voltage droop. The maximum recommended series resistance on the VDD current path is 50 mΩ. The PCB layout should ensure that this limit is not exceeded, accounting for the resistance of the copper traces and any series components in the power path. Using wider copper traces (or better yet, polygon pours) minimizes voltage drop due to DC resistance and reduces inductive impedance at higher frequencies. This becomes especially important during events such as RF transmission or wake-from-sleep transitions, where dynamic current demand can rise sharply. The supply voltage drop between the regulator and the load should remain below 50 mV under peak-current conditions. Avoid routing supply traces through narrow necks, unnecessary detours, or shared segments that may introduce excess impedance or coupling into other supply domains. Avoid overlapping power traces on adjacent layers, which can create capacitive coupling between supplies. **5.4.2.3 Via Usage** Each via contributes its own resistance and inductance, so distributing current across several vias helps maintain power integrity even during fast load steps. This is particularly important for VDD and VDD\_TX. ### 5.5 SDIO / SPI / JTAG Placement and routing should minimize crosstalk and signal integrity issues across these digital interfaces. It is important to address this carefully during layout, as digital signals may appear functional despite poor integrity, which can lead to intermittent or hard-to-diagnose failures later in development or in the field. The following recommendations help maintain clean digital signaling. #### 5.5.1 Placement Guidelines Wherever possible, arrange subsystems on the PCB to enable direct, uncluttered routing of the SDIO/SPI signals, minimizing crossings with other traces or with themselves. Maintain separation between these signal domains to reduce coupling and simplify layout. #### 5.5.2 Routing Guidelines The SDIO and SPI signals should ideally be routed as 50 Ω coplanar waveguides (on outer layers) or as striplines (on internal layers). To preserve signal integrity, keep trace lengths under 50 mm and match them within ±10  mm. Since these are digital signals, resistive and dielectric losses are not a key concern, so the minimum trace width and dielectric type are not critical. These interfaces operate at tens of megahertz, so tight impedance control is not necessary; however, using a standard PCB calculator to size traces for a nominal 50 Ω impedance is still recommended. Coordination with the PCB fabricator for precise impedance control on these traces is not mandatory. SDIO is a point-to-point protocol and should always be routed directly between the host and the peripheral, with no branches in the signal path. When supporting multiple host devices through different builds (for example, by selectively populating 0 Ω resistors), the stub leading to the unused path should be kept as short as possible to maintain signal integrity. For shared buses, arranging devices in a daisy chain helps minimize reflections and ensures the last device sees the best signal. Note that intermediate devices inevitably see stubs from the onward connections. ### 5.6 GPIO GPIO signals have lower priority than other types, so they are typically routed last, using whatever space remains after higher-priority traces are placed. Ensure their routing doesn’t violate existing layout constraints, for example, avoid cutting ground planes beneath RF traces or disrupting return current loops. GPIOs are general-purpose; their function is defined by special firmware builds and Morse Micro board configuration files (BCFs). If tied to a specific application note, any unique signal requirements will be detailed in that note. Electrically, a GPIO driven on one end is effectively grounded at the driver but floating (high impedance) at the load. From the standpoint of nearby RF traces, it resembles an unterminated length of copper that can easily pick up or reradiate signals. If the trace is long or closely spaced to RF, it can act like a stray antenna. Adding 100 pF capacitors to ground can suppress these effects without impacting low-speed digital performance. For GPIO signals that control external RF front-end devices such as RF switches, front-end modules (FEMs), low-noise amplifiers (LNAs), and power amplifiers (PAs), ensure that 100 pF termination capacitors are placed at the RF front-end device control input pins. These capacitors filter out digital power-supply domain noise and prevent it from coupling into the RF front-end signal path. If GPIO traces need to cross adjacent layers or power traces, ensure they do so at right angles to minimize coupling. GPIO traces should only run directly alongside other traces if those signals are tolerant of digital noise, or if GPIO transitions are guaranteed to occur at times that coupling is not consequential. ### 5.7 Diagnostic Ports Placement and routing of the diagnostics connector should ensure a reliable mechanical fit, allow unobstructed cable access, and maintain a clean integration into the PCB stack-up without compromising nearby traces or ground integrity. Place the diagnostics connector with enough clearance for cables or probes to attach and detach freely, and avoid positions that force sharp cable bends. ### 5.8 Protection Placement and routing of protection components must ensure effective suppression of electrostatic discharge, electromagnetic interference, and conducted noise without compromising impedance control or power delivery. #### 5.8.1 Placement Guidelines Electrostatic discharge protection (ESD) components must be placed to intercept disturbances before they propagate into sensitive areas of the design. ESD protection circuitry should be located at the outermost interface with the external environment, close to connectors or antenna feeds, to ensure transients are quickly shunted through short, direct paths to ground. As signals transition between noisy and quiet domains, chokes and filters confine conducted noise, preserving the integrity of downstream circuits. On impedance-sensitive traces, particularly RF paths, any protection must be positioned to minimize parasitic effects and maintain controlled impedance without introducing discontinuities. Similarly, on power nets, protection layout must accommodate wide copper traces to keep ESR low, preventing voltage drops and avoiding inductive artifacts that could degrade supply stability. #### 5.8.2 Routing Guidelines Route to protection devices with the shortest possible traces to minimize series impedance. Avoid tight corners or via transitions that introduce additional parasitics, particularly on RF or high-current power nets. Ensure ground returns are direct and connect to a solid plane to support effective discharge and filtering. ### 5.9 Grounding Ground layout directly impacts power integrity, electromagnetic interference performance, and RF behavior. The following section describes layout techniques and grounding practices necessary to ensure stable operation. Many of the recommendations are repeated, but they have been kept together here so that this section may act as a final checklist on grounding integrity before the board is sent for manufacture. #### 5.9.1 Solid Ground Plane Dedicate at least one layer (typically an inner layer) as a continuous ground plane. Avoid cutting or slotting the ground plane near critical components or between supply and decoupling points. Keep the ground plane unbroken under the MM8108-MF15457, the associated decoupling capacitors, and the RF trace. If signals must transition between layers, note that several adjacent vias will split the ground plane and must be spaced to prevent this. A single, unified ground plane should be maintained throughout. Do not segment or isolate analog and digital grounds within the module footprint. #### 5.9.2 Ground Via Stitching Use generous ground via stitching to connect all ground regions and layers. Every decoupling capacitor should have at least one ground via placed directly at the capacitor pad. Where possible, via-in-pad is preferred. Ground vias should be densely placed around exposed thermal pads, along the chip periphery, and beneath high-current return paths, such as the buck regulator or RF output. Add ground vias at every ground pad for every grounded component. For RF nets, use a direct connection (not a thermal relief). In systems operating in the 850 MHz to 950 MHz band, the wavelength in FR4 is approximately 150 mm. To effectively confine return currents and suppress cavity resonances, stitching vias should be placed at intervals of at least 15 mm (about λ/10). However, to improve margins and further minimize the risk of electromagnetic interference, a tighter pitch of 6 mm or less (approximately λ/25) is recommended. Along critical signals (such as RF or high-speed traces), vias should be spaced no more than 1.0 mm apart (center-to-center). Recommended dimensions include a minimum drill size of 0.3 mm and a pad diameter of at least 0.6 mm, with annular rings meeting fabrication requirements. Place stitching vias every 3.0 mm along plane boundaries and within 1.0 mm of any cutout or slot. #### 5.9.3 Return-Path Control All high-speed or RF signal traces must have a direct return path on the adjacent ground layer. The return current should remain closely coupled beneath the signal trace. Traces must not cross plane splits. ## 6 Application Examples The following examples are intended to capture the basic usage across the three most common host types: PC (USB dongle), embedded Linux (Raspberry Pi), and ARM-based microcontroller (EKH05). ### 6.1 USB Dongle Application Example The following example is a minimal implementation of the MM8108-MF15457 as a USB Wi-Fi HaLow dongle. This is the most straightforward application example we provide (i.e., the one with the fewest components). #### 6.1.1 Bill of Materials The following table lists the components required to implement a Wi-Fi HaLow USB dongle. | | | | | | | ----------- | ------ | --------------------------- | -------------------- | -------- | | Designator | Value | Manufacturer | Part Number | Quantity | | H2 | USBA | Global Connector Technology | USB1061-GF-L-A | 1 | | D1, D5 | Green | SunLED | XZVGR68W-3 | 2 | | D6 | | STMicroelectronics | ESDALC6V1-1U2 | 1 | | D2, D3 | | LittelFuse | SP3522-01ETG | 2 | | D4 | Red | SunLED | XZMDK68W-2 | 1 | | C1 | 2.2 uF | Murata | GRM155R61E225ME15D | 1 | | C2, C4, C6 | 10 uF | Samsung | CL05A106MP5NUNC | 3 | | C5 | 22 pF | TDK | CGA2B2NP01H220J050BA | 1 | | R2 | 453 kΩ | Vishay | CRCW0402453KFKEDC | 1 | | R7 | 220 kΩ | Yageo | RC0201FR-07220KL | 1 | | C3, C8 | 10 uF | Murata | GRM188R61E106MA73J | 2 | | C7 | 100 nF | KEMET | C0402C104K8RACTU | 1 | | H1 | | Bel Cinch | 142-0761-861 | 1 | | L1 | 2.2 uH | Murata | LQM21PN2R2MGHL | 1 | | R1, R3 | 100 kΩ | Yageo | RC0402FR-07100KL | 2 | | R4, R5, R13 | 330 Ω | Yageo | RC0201FR-07330RL | 3 | | U1 | | Morse Micro | MM8108-MF15457 | 1 | | U2 | | Diodes Inc. | AP3401DNTR-G1 | 1 | **Table 5: Bill of Materials for USB Dongle Application** #### 6.1.2 Reference Schematic The schematic is provided in four parts: the MM8108-MF15457, the required decoupling capacitors, the RF connector, and the reset circuitry. ![Figure 20: USB Dongle Application Example: Schematic of MM8108-MF15457](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/qeFGNwX4c00xsin4lQt3/Unknown%20image) *Figure 20: USB Dongle Application Example: Schematic of MM8108-MF15457* The power supply is taken directly from the 5 V USB VBUS line, and a switch-mode power supply is used to minimize waste heat. ![Figure 21: USB Dongle Application Example: Layout of power supply section](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/lKMpMifyJ8Rx3JpQPe3k/Unknown%20image) *Figure 21: USB Dongle Application Example: Layout of power supply section* Some basic indicator LEDs are provided, along with an (optional) push button for WAKE functionality. ![Figure 22: USB Dongle Application Example: Layout of the IO section](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/SWRcNczRfobE4XmKmzzE/Unknown%20image) *Figure 22: USB Dongle Application Example: Layout of the IO section* #### 6.1.3 Reference Layout The complete PCB is shown below, where the layout of the RF, USB, decoupling, and IO (LED) traces is clearly visible. The power supply and button are not shown; they appear on the underside of the PCB. ![Figure 23: USB Dongle Application PCB Layout](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/rG68VYdMdj6ZzPVTbs73/Unknown%20image) *Figure 23: USB Dongle Application PCB Layout* #### 6.1.4 Additional Resources Complete details for this application example can be found at [www.morsemicro.com](https://www.google.com/url?q=http://www.morsemicro.com\&sa=D\&source=editors\&ust=1783314268592805\&usg=AOvVaw0jy21yMlDdaZqANlKuLrbR) by searching for the [RD09](https://www.google.com/url?q=https://www.morsemicro.com/resources/design_packages/reference_designs/RD09_v4.1.zip\&sa=D\&source=editors\&ust=1783314268592962\&usg=AOvVaw1wjjUK6I75Cl2gBuUJln1v) reference design. ### 6.2 STM32 Microcontroller Application Example Complete details for an ARM microcontroller-based example can be found at [www.morsemicro.com](https://www.google.com/url?q=http://www.morsemicro.com\&sa=D\&source=editors\&ust=1783314268593257\&usg=AOvVaw2mW7MIB0KIuX8KhwN_1Npu) and searching for the [MM8108-EKH05](https://www.google.com/url?q=https://www.morsemicro.com/resources/design_packages/carrier_boards/MM8108-EKH05_v2.1.zip\&sa=D\&source=editors\&ust=1783314268593377\&usg=AOvVaw01TpmUp6yhp-yNyL3N19l8) evaluation kit. ### 6.3 Raspberry Pi Application Example Complete details for an embedded Linux-based example can be found at [www.morsemicro.com](https://www.google.com/url?q=http://www.morsemicro.com\&sa=D\&source=editors\&ust=1783314268593653\&usg=AOvVaw0uyr8Malt85uPmr_1jFTBn) and searching for the [MMECH17](https://www.google.com/url?q=https://www.morsemicro.com/resources/design_packages/carrier_boards/MMECH17_v3.zip\&sa=D\&source=editors\&ust=1783314268593771\&usg=AOvVaw29HujJ5RKFYMXCogZvG5Nz) application example. ## 7 Design-In Checklist This checklist is intended for hardware designers integrating the MM8108-MF15457 Wi-Fi HaLow module into a new design. It defines key items to verify during schematic capture and PCB layout. Refer to the reference designs (Section 6) for complete schematics and PCB layouts across supported host interfaces ### 7.1 Schematic Checklist #### 7.1.1 RF * Including a pi or tee network on the RF path provides the option for additional filtering. * IF the RF path is exposed to the external environment, AND more protection than the in-built 1 kV is required, THEN include an RF-rated ESD diode at the connector pin. * IF maximizing range is paramount, be mindful that everything you put on the main RF signal path (including the above) degrades the signal quality. ![Figure 24: RF Schematic](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/zQaHZK2Li9ZJ6r2FO1ip/Unknown%20image) *Figure 24: RF Schematic* #### 7.1.2 Power Supply * Ensure the module power supply (LDO or SMPS) supports at least 500 mA of current. * Minimum of 10 uF of capacitance on VDD, VDD\_TX, and VDD\_USB. * An additional 100 nF capacitor on VDD, VDD\_TX, and VDD\_USB is recommended. * Minimum of 100 nF of capacitance on VDDIO. ![Figure 25: Module decoupling capacitors](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/qtyq5Zz2EkEPEaG2e64Z/Unknown%20image) *Figure 25: Module decoupling capacitors* #### 7.1.3 Host Interface The MM8108-MF15457 has multiple methods of operation with a host device. Follow the sub-section corresponding to the intended host interface (SDIO, SPI, or USB). **7.1.3.1 SDIO** * Place pull-up resistors (10 to 100 kΩ) on SDIO\_CMD, SDIO\_D0, SDIO\_D1, SDIO\_D2, and SDIO\_D3. * Connect the SDIO pull-up resistors to the VDDIO power rail. * Ensure no pull-up resistor is present on SDIO\_CLK. * (Optional) Provision series-damping resistors on all SDIO lines for signal-integrity tuning. Populate as 0 Ω by default, and substitute with values in the 10 to 100 Ω range if ringing, overshoot, or EMI issues are observed. * Notes on USB: * USB D+/D− can be left unconnected when SDIO is the primary transport. * You must connect VDD\_USB to the VDD power rail even if USB is not used. ![Figure 26: SDIO Schematic](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/oyq2IZo0jMb7216bHEgY/Unknown%20image) *Figure 26: SDIO Schematic* **7.1.3.2 SPI** * Place a pull-up resistor (10 to100 kΩ) on SDIO\_D2 only (required for SPI operation). * Connect the SDIO\_D2 pull-up resistor to the VDDIO power rail. * (Optional) Provision series-damping resistors on all SPI lines for signal-integrity tuning. Populate 0 Ω resistors by default, and substitute with values in the 10 to 100 Ω range if ringing, overshoot, or EMI issues are observed. * Notes on USB: * USB D+/D− can be left unconnected when SPI is the primary transport. * You must connect VDD\_USB to the VDD power rail even if USB is not used. ![Figure 27: SPI Schematic](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/FktJjSebKLctBMsNySkh/Unknown%20image) *Figure 27: SPI Schematic* **7.1.3.3 USB** * ESD protection on USB data lines (D+ and D−) must be specifically designed for USB 2.0 operation (e.g., [SP3401-02UTG](https://www.google.com/url?q=https://www.littelfuse.com/products/overvoltage-protection/tvs-diode-arrays/low-ultra-low-capacitance/sp3401/sp3401-02utg\&sa=D\&source=editors\&ust=1783314268599356\&usg=AOvVaw01oezau_tkLJhqjpXUOxm0)). * Note: SDIO/SPI traces can be left unconnected when USB is the primary transport. ![Figure 28: USB Schematic](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/FqklipmjRsiUZHbRuq82/Unknown%20image) *Figure 28: USB Schematic* #### 7.1.4 JTAG * (Optional) Connect JTAG signals to test points. * Ensure no pull-down resistors are present on JTAG lines. ![Figure 29: JTAG Schematic](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/aFBu6iDETGKuflGbURYN/Unknown%20image) *Figure 29: JTAG Schematic* #### 7.1.5 GPIO * Connect the GPIOs according to the defined pin mapping, as shown below. * If power save mode is used, connect BUSY (GPIO2 on pin 29) directly to a host input GPIO. * Ensure all unused GPIOs are left unconnected. * (Optional) Connect GPIO0 to a test point. ![Figure 30: GPIO Schematic](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/gIZ7u6OQdymPbKudI96D/Unknown%20image) *Figure 30: GPIO Schematic* #### 7.1.6 Wake * IF power saving mode is required, THEN connect the WAKE pin to a host output GPIO. * IF power saving mode is not required, THEN leave the WAKE pin unconnected. #### 7.1.7 Reset * Connect RESET\_N to a host output GPIO. * Include an RC network on RESET\_N with 220 kΩ pull-up and 2.2 µF capacitor to ground. ![Figure 31: Wake and Reset Schematic](https://content.gitbook.com/content/AKrW0iuDGhHzyPH6cNEv/blobs/zbiEVzSkjg7zNH8VhXvk/Unknown%20image) *Figure 31: Wake and Reset Schematic* ### 7.2 PCB Layout Checklist #### 7.2.1 RF * Ensure RF trace impedance is 50 Ω ±10%. * Avoid RF trace right-angle bends. * Minimize RF trace length. * Surround the RF trace with ground stitching vias. * Avoid significant PCB trace width changes through matching components and antenna pads. * Place the RF ESD diode as close as possible to the antenna connector. #### 7.2.2 Power Supply * Place decoupling capacitors as close as possible to the module power supply pins. * Place smaller value capacitors closer to the pin, followed by larger capacitors. * Ensure power traces support at least 1A of (instantaneous) current. * Use multiple vias when transitioning power traces between PCB layers. #### 7.2.3 SDIO/SPI * Ensure SDIO/SPI lines are length matched to ±10 mm. * Controlling SDIO/SPI trace impedance to 50 Ω is recommended. * Ensure no stubs are present on SDIO/SPI signals. #### 7.2.4 USB * Ensure USB data lines are routed as 90 Ω differential pairs. * Ensure USB data lines are length-matched with ≤100 ps skew (within 1 mm recommended). * Ensure compliance with USB 2.0 requirements. ## 8 Revision History | | | | | -------------- | ------------ | ------------------------------------------------------- | | Release Number | Release Date | Release Notes | | Version 2 | 20 June 2026 | Added note on level shifter. Added Design-In checklist. | | Version 1 | 22 Oct 2025 | Initial release | Morse Micro provides this information "as is" without warranties of any kind, express or implied. No guarantee is made as to the accuracy, completeness, or suitability of this information or Morse Micro’s products for any specific purpose. Use of this information and products is at the user’s sole risk. Morse Micro products are not designed or tested for use in mission-critical systems, and should not be used in such applications. Performance specifications are based on internal testing and are believed to be reliable; however, they are not guaranteed. It is the Buyer’s responsibility to test and validate all product performance, compatibility, and compliance, both in isolation and within end applications. Morse Micro assumes no liability for the use or application of any product, circuit, or information described herein. No license or other rights—express or implied—are granted under Morse Micro’s intellectual property. This document contains proprietary information of Morse Micro and is subject to change without notice. Wi-Fi®, Wi-Fi HaLow™, and the Wi-Fi logo are trademarks of Wi-Fi Alliance. ZigBee™ and Z-Wave™ are trademarks of their respective owners. All other trademarks are the property of their respective owners. [\[a\]](#cmnt_ref1)Just a note for the next release of this document. We've update the schematic sheet symbol of this part as the current symbol required connecting a trace to the NC pin which doesn't really make sense. (It won't let me paste the new symbol). Check Altium for latest. # User guides User guides provide setup, configuration, and integration instructions for Morse Micro products. #### [Wi-Fi HaLow Network Adapter User Guide](https://www.morsemicro.com/resources/user_guides/USB_Network_Adapter_User_Guide.pdf) The Wi-Fi HaLow Network Adapter User Guide provides instructions for setting up and configuring the Morse Micro Wi-Fi HaLow USB network adapter. #### [MM6108-EKH01 Evaluation Kit User Guide](https://www.morsemicro.com/resources/user_guides/MM6108-Eval-Kit-User-Guide-2.5.pdf) The MM6108 Evaluation Kit User Guide v2.5 provides comprehensive instructions for deploying and configuring Morse Micro’s Wi-Fi HaLow evaluation hardware under OpenWRT. It covers device setup, operating modes (AP, STA, mesh, virtual-wire), UI and CLI commands, performance testing, and troubleshooting—designed to help engineers evaluate and integrate the MM6108 chipset. #### [MM-IoT CMSIS-Pack User Guide](https://www.morsemicro.com/resources/user_guides/MM-IoT-CMSIS-Pack-User-Guide.pdf) The MM-IoT CMSIS-Pack User Guide shows how to integrate Morse Micro’s Wi-Fi HaLow IoT-SDK into ARM development environments (STM32CubeIDE). It covers installation, example projects, porting, and configuration management between the MM6108 and MM8108. #### [MM6108 OpenWrt Web GUI User Guide](https://www.morsemicro.com/resources/user_guides/MM6108-Eval-Kit-User-Guide-2.6.pdf) The MM6108 Evaluation Kit User Guide v2.6 delivers detailed instructions for deploying Morse Micro’s Wi-Fi HaLow evaluation hardware using OpenWRT. It covers board setup, operating modes (AP, STA, mesh, virtual-wire), CLI/UI commands, performance metrics, configuration options, and troubleshooting tips—helping engineers quickly integrate and evaluate the MM6108 chipset. #### [Platform-IO + MM IoT SDK User Guide]() The Platform-IO MM-IoT SDK User Guide walks through integrating Morse Micro’s Wi-Fi HaLow IoT-SDK using PlatformIO. It covers environment setup, example projects, supported boards, and configuration guidance for MM6108 and MM8108 modules. #### [MM6108-EKH05 User Guide](https://www.morsemicro.com/resources/user_guides/MM6108-EKH05-User-Guide.pdf) The MM6108 EKH05 User Guide provides detailed instructions for deploying and programming Morse Micro’s Wi-Fi HaLow EKH05 evaluation board. It walks through setup, configuration, firmware operations, development options, and troubleshooting for IoT developers. #### [HaLowLink User Guide](https://www.morsemicro.com/resources/user_guides/HaLowLink-User-Guide.pdf) The HaLowLink 1 and 2 User Guide explains how to install, configure, and use Morse Micro’s Wi-Fi HaLowLink devices as routers, extenders, or access points. It covers setup options, interface modes, firmware updates, and troubleshooting for integrators. #### [MM8108-EKH05 User Guide](https://www.morsemicro.com/resources/user_guides/MM8108-EKH05-User-Guide.pdf) The MM8108 EKH05 User Guide provides detailed instructions for deploying and programming Morse Micro’s Wi-Fi HaLow EKH05 evaluation board. It walks through setup, configuration, firmware operations, development options, and troubleshooting for IoT developers. #### [MMx108 Eval Kit User Guide]() The MM6108 / MM8108 Evaluation Kit User Guide v2.9 offers step-by-step instructions for using Morse Micro’s Wi-Fi HaLow evaluation hardware. It covers board setup, configuration, command interfaces, and example usage to help engineers accelerate development with the MM6108 and MM8108 chips. # Downloads Download firmware images, hardware reference design packages, and drivers. ## Design packages #### [MM6108-EKH03 Design Package](https://morsemicro-wpdm.s3.amazonaws.com/all-packages/MM6108_EKH03_v4.zip) Download the Wi-Fi HaLow EKH03 v4 Design Package for the MM6108 + MTK7628 AP platform, including schematics, layout, and BOM. #### [MMECH08 Design Package](https://www.morsemicro.com/resources/design_packages/carrier_boards/MMECH08_v2.zip) The MMECH08 v2 Design Package provides the reference carrier board for Morse Micro’s MM6108-EKH08 IoT development platform. It includes schematics, PCB layout, and BOM files to aid developers integrating the carrier with MM6108 modules. #### [MM6108-EKH05 Design Package]() The MM6108-EKH05 v2 Design Package contains the hardware reference for the EKH05 evaluation board combining the MM6108-MF08651-US module with an STM32 MCU. It provides schematics, board layouts, and BOM for custom hardware development. #### [MM8108-EKH05 Design Package](https://www.morsemicro.com/resources/design_packages/carrier_boards/MM8108-EKH05_v2.1.zip) The MM8108-EKH05 v2 Design Package corresponds to the hardware reference files for Morse Micro’s EKH05 evaluation board, which pairs the MM8108-MF15457 Wi-Fi HaLow module with an STM32 MCU. This package includes schematics, layout assets, and BOM to support custom IoT hardware development. #### [RD09 (Part of MM8108-EKH19) Reference Design Package](https://www.morsemicro.com/resources/design_packages/reference_designs/RD09_v5.0.zip) The RD09 Reference Design Package provides the full USB dongle reference design for Morse Micro’s Wi-Fi HaLow, based on the MM8108 chipset. It includes schematics, layout files, and bill of materials to help customers build compliant USB dongles or embed Wi-Fi HaLow support. #### [MMECH17 Design Package](https://www.morsemicro.com/resources/design_packages/carrier_boards/MMECH17_v4.0.zip) The MMECH17 Design Package is the reference design for the Wi-Fi HaLow Raspberry Pi HAT used in MM8108-EKH01 kits. It includes schematic files, PCB layouts, and BOM to aid engineers building Pi-based IoT solutions with the MM8108 module. #### [MMECH06 Design Package](https://www.morsemicro.com/resources/design_packages/carrier_boards/MMECH06_v8.1.zip) The MMECH06 Design Package provides the reference carrier board files for Morse Micro’s MM6108-EKH01 IoT development kit. It includes schematics, layout files, and BOM to support integrating the carrier with the MM6108 module. ## Images #### [HaLowLink 1 OpenWRT 2.11.12 Firmware Image](https://www.morsemicro.com/resources/software_releases/linux/halowlink1/openwrt-morse-2.11.12-halowlink1.bin) The HaLowLink 1 OpenWRT 2.11.12 Firmware Image contains the latest Wi-Fi HaLow software updates for Morse Micro’s HaLowLink 1, including new features and performance improvements for users of the HaLowLink 1 device. #### [HaLowLink 2 OpenWRT 2.11.12 Firmware Image](https://www.morsemicro.com/resources/software_releases/linux/halowlink2/openwrt-morse-2.11.12-halowlink-2.bin) The HaLowLink 2 OpenWRT 2.11.12 Firmware Image contains the latest Wi-Fi HaLow software updates for Morse Micro’s HaLowLink 2, including new features and performance improvements for users of the HaLowLink 2 device. #### [OpenWrt 2.12.6 MM8108 EKH19 Kit Image](https://www.morsemicro.com/resources/software_releases/linux/eval_kit_images/openwrt-morse-2.12.6-morsemicro-mm8108-ekh19-squashfs-sysupgrade.bin.signed) The OpenWRT 2.12.6 MM8108-EKH19 Kit Image contains the firmware build optimized for Morse Micro’s MM8108-EKH19 USB dongle evaluation kit. Use this image to flash your EKH19 hardware and test Wi-Fi HaLow operation under OpenWRT. #### [OpenWrt 2.12.6 MMx108 EKH01 Kit Image](https://www.morsemicro.com/resources/software_releases/linux/eval_kit_images/openwrt-morse-2.12.6-mmx108-ekh01-sdio-squashfs-sysupgrade.img.gz.signed) The OpenWRT 2.12.6 MMX108-EKH01 Kit Image is the firmware release for Raspberry Pi-based EKH01 evaluation kits using the MM8108 module. Flash this image to run Wi-Fi HaLow on your EKH01 setup under OpenWRT. #### [OpenWrt 2.11.12 MM8108 EKH19 Kit Image](https://www.morsemicro.com/resources/software_releases/linux/eval_kit_images/openwrt-morse-2.11.12-morsemicro-mm8108-ekh19-squashfs-sysupgrade.bin) The OpenWRT 2.11.12 MM8108-EKH19 Kit Image contains the firmware build optimized for Morse Micro’s MM8108-EKH19 USB dongle evaluation kit. Use this image to flash your EKH19 hardware and test Wi-Fi HaLow operation under OpenWRT. #### [OpenWrt 2.11.12 MMx108 EKH01 Kit Image](https://www.morsemicro.com/resources/software_releases/linux/eval_kit_images/openwrt-morse-2.11.12-mmx108-ekh01-sdio-squashfs-sysupgrade.img.gz) The OpenWRT 2.11.12 MMX108-EKH01 Kit Image is the firmware release for Raspberry Pi-based EKH01 evaluation kits using the MM8108 module. Flash this image to run Wi-Fi HaLow on your EKH01 setup under OpenWRT. #### [OpenWrt 2.12.6 MM6108-EKH03 Kit Image](https://www.morsemicro.com/resources/software_releases/linux/eval_kit_images/openwrt-morse-2.12.6-morsemicro-ekh03-v4-squashfs-sysupgrade.bin.signed) Use the OpenWRT 2.12.6 MM6108-EKH03 Kit Image with the MM6108-EKH03 reference access point, powered by the MTK7628 SoC. Flash this image to enable Wi-Fi HaLow functionality on your EKH03 hardware. #### [OpenWrt 3.0.2 MM6108-EKH03 Kit Image](https://www.morsemicro.com/resources/software_releases/linux/eval_kit_images/openwrt-morse-3.0.2-morsemicro-ekh03-v4-squashfs-sysupgrade.bin) Use the OpenWRT 3.0.2 MM6108-EKH03 Kit Image with the MM6108-EKH03 reference access point, powered by the MTK7628 SoC. Flash this image to enable Wi-Fi HaLow functionality on your EKH03 hardware. #### [OpenWrt 2.11.12 MM6108-EKH03 Kit Image](https://www.morsemicro.com/resources/software_releases/linux/eval_kit_images/openwrt-morse-2.11.12-morsemicro-ekh03-v4-squashfs-sysupgrade.bin) Use the OpenWRT 2.11.12 MM6108-EKH03 Kit Image with the MM6108-EKH03 reference access point, powered by the MTK7628 SoC. Flash this image to enable Wi-Fi HaLow functionality on your EKH03 hardware. ## Drivers #### [Wi-Fi HaLow USB Adapter Windows Drivers](https://www.morsemicro.com/resources/software_releases/windows/MM8108HalowInst-1.0.2.0.exe) Windows drivers for Morse Micro Wi-Fi HaLow USB adapters. # Design packages #### [MM6108-EKH03 Design Package](https://morsemicro-wpdm.s3.amazonaws.com/all-packages/MM6108_EKH03_v4.zip) Download the Wi-Fi HaLow EKH03 v4 Design Package for the MM6108 + MTK7628 AP platform, including schematics, layout, and BOM. #### [MMECH08 Design Package](https://www.morsemicro.com/resources/design_packages/carrier_boards/MMECH08_v2.zip) The MMECH08 v2 Design Package provides the reference carrier board for Morse Micro’s MM6108-EKH08 IoT development platform. It includes schematics, PCB layout, and BOM files to aid developers integrating the carrier with MM6108 modules. #### [MM6108-EKH05 Design Package]() The MM6108-EKH05 v2 Design Package contains the hardware reference for the EKH05 evaluation board combining the MM6108-MF08651-US module with an STM32 MCU. It provides schematics, board layouts, and BOM for custom hardware development. #### [MM8108-EKH05 Design Package](https://www.morsemicro.com/resources/design_packages/carrier_boards/MM8108-EKH05_v2.1.zip) The MM8108-EKH05 v2 Design Package corresponds to the hardware reference files for Morse Micro’s EKH05 evaluation board, which pairs the MM8108-MF15457 Wi-Fi HaLow module with an STM32 MCU. This package includes schematics, layout assets, and BOM to support custom IoT hardware development. #### [RD09 (Part of MM8108-EKH19) Reference Design Package](https://www.morsemicro.com/resources/design_packages/reference_designs/RD09_v5.0.zip) The RD09 Reference Design Package provides the full USB dongle reference design for Morse Micro’s Wi-Fi HaLow, based on the MM8108 chipset. It includes schematics, layout files, and bill of materials to help customers build compliant USB dongles or embed Wi-Fi HaLow support. #### [MMECH17 Design Package](https://www.morsemicro.com/resources/design_packages/carrier_boards/MMECH17_v4.0.zip) The MMECH17 Design Package is the reference design for the Wi-Fi HaLow Raspberry Pi HAT used in MM8108-EKH01 kits. It includes schematic files, PCB layouts, and BOM to aid engineers building Pi-based IoT solutions with the MM8108 module. #### [MMECH06 Design Package](https://www.morsemicro.com/resources/design_packages/carrier_boards/MMECH06_v8.1.zip) The MMECH06 Design Package provides the reference carrier board files for Morse Micro’s MM6108-EKH01 IoT development kit. It includes schematics, layout files, and BOM to support integrating the carrier with the MM6108 module. # Images #### [HaLowLink 1 OpenWRT 2.7.6 Firmware Image ](https://www.morsemicro.com/resources/software_releases/linux/halowlink1/openwrt-morse-2.7.6-halowlink1.bin) The HaLowLink 1 OpenWRT 2.11.12 Firmware Image contains the latest Wi-Fi HaLow software updates for Morse Micro’s HaLowLink 1, including new features, performance improvements, and known issues for users of the HaLowLink 1 device. #### [HaLowLink 2 OpenWRT 2.11.12 Firmware Image ](https://www.morsemicro.com/resources/software_releases/linux/halowlink2/openwrt-morse-2.11.12-halowlink-2.bin) The HaLowLink 2 OpenWRT 2.11.12 Firmware Image contains the latest Wi-Fi HaLow software updates for Morse Micro’s HaLowLink 2 including new features, performance improvements, and known issues for users of the HaLowLink 2 device. #### [OpenWrt 2.12.6 MM8108 EKH19 Kit Image ](https://www.morsemicro.com/resources/software_releases/linux/eval_kit_images/openwrt-morse-2.12.6-morsemicro-mm8108-ekh19-squashfs-sysupgrade.bin.signed) The OpenWRT 2.12.6 MM8108-EKH19 Kit Image contains the firmware build optimized for Morse Micro’s MM8108-EKH19 USB dongle evaluation kit. Use this image to flash your EKH19 hardware and test Wi-Fi HaLow operation under OpenWRT. #### [OpenWrt 2.12.6 MMx108 EKH01 Kit Image ](https://www.morsemicro.com/resources/software_releases/linux/eval_kit_images/openwrt-morse-2.12.6-mmx108-ekh01-sdio-squashfs-sysupgrade.img.gz.signed) The OpenWRT 2.12.6 MMX108-EKH01 Kit Image is the firmware release for Raspberry Pi-based EKH01 evaluation kits using the MM8108 module. Flash this image to run Wi-Fi HaLow on your EKH01 setup under OpenWRT. #### [OpenWrt 2.11.12 MM8108 EKH19 Kit Image ](https://www.morsemicro.com/resources/software_releases/linux/eval_kit_images/openwrt-morse-2.11.12-morsemicro-mm8108-ekh19-squashfs-sysupgrade.bin) The OpenWRT 2.11.12 MM8108-EKH19 Kit Image contains the firmware build optimized for Morse Micro’s MM8108-EKH19 USB dongle evaluation kit. Use this image to flash your EKH19 hardware and test Wi-Fi HaLow operation under OpenWRT. #### [OpenWrt 2.11.12 MMx108 EKH01 Kit Image ](https://www.morsemicro.com/resources/software_releases/linux/eval_kit_images/openwrt-morse-2.11.12-mmx108-ekh01-sdio-squashfs-sysupgrade.img.gz) The OpenWRT 2.11.12 MMX108-EKH01 Kit Image is the firmware release for Raspberry Pi-based EKH01 evaluation kits using the MM8108 module. Flash this image to run Wi-Fi HaLow on your EKH01 setup under OpenWRT. #### [OpenWrt 2.12.6 MM6108-EKH03 Kit Image ](https://www.morsemicro.com/resources/software_releases/linux/eval_kit_images/openwrt-morse-2.12.6-morsemicro-ekh03-v4-squashfs-sysupgrade.bin.signed) Use the OpenWRT 2.12.6 MM6108-EKH03 Kit Image with the MM6108-EKH03 reference access point, powered by the MTK7628 SoC. Flash this image to enable Wi-Fi HaLow functionality on your EKH03 hardware. #### [OpenWrt 3.0.2 MM6108-EKH03 Kit Image ](https://www.morsemicro.com/resources/software_releases/linux/eval_kit_images/openwrt-morse-3.0.2-morsemicro-ekh03-v4-squashfs-sysupgrade.bin) Use the OpenWRT 3.0.2 MM6108-EKH03 Kit Image with the MM6108-EKH03 reference access point, powered by the MTK7628 SoC. Flash this image to enable Wi-Fi HaLow functionality on your EKH03 hardware. #### [OpenWrt 2.11.12 MM6108-EKH03 Kit Image](https://www.morsemicro.com/resources/software_releases/linux/eval_kit_images/openwrt-morse-2.11.12-morsemicro-ekh03-v4-squashfs-sysupgrade.bin) Use the OpenWRT 2.11.12 MM6108-EKH03 Kit Image with the MM6108-EKH03 reference access point, powered by the MTK7628 SoC. Flash this image to enable Wi-Fi HaLow functionality on your EKH03 hardware. # Drivers Download drivers for supported Morse Micro hardware. #### [Wi-Fi HaLow USB Adapter Windows Drivers](https://www.morsemicro.com/resources/software_releases/windows/MM8108HalowInst-1.0.2.0.exe) Windows drivers for Morse Micro Wi-Fi HaLow USB adapters.