At InThings Technologies, we spend a lot of time thinking about the gap between “connected” and “reliably connected” — especially for industrial and outdoor IoT deployments where Wi-Fi's range runs out long before the use case does. Over the past few months, our embedded engineering team has been working with Wi-Fi HaLow (IEEE 802.11ah), a sub-GHz Wi-Fi standard built for exactly this problem: kilometer-plus range, deep building penetration, and power consumption low enough for battery-operated field devices — all while still speaking IP, unlike many low-power radio protocols.
We took on two parallel engineering efforts to bring HaLow into our product line, using Morse Micro's HaLow silicon as our reference hardware. Here's what it took.
Wi-Fi HaLow combines the range and power efficiency of low-power wide-area protocols with native IP networking.
Bringing HaLow to Our Gateway Platform
Our first target was our gateway platform, built around an STM32MP1 system-on-module, where we set out to add a Morse Micro HaLow radio as a new wireless backhaul and access option alongside our existing LoRaWAN connectivity.
The Morse Micro MM8108-EKH19-01 USB dongle used to bring HaLow to the gateway.
Because our gateway runs a custom Yocto Linux BSP, this meant integrating HaLow support at the OS level rather than bolting on a vendor SDK. Our team added three custom packages to our Yocto layer:
• A kernel driver package compiling Morse Micro's out-of-tree driver modules, configured specifically for USB-connected HaLow hardware and tuned to strip out unused SDIO/SPI code paths we didn't need.
• A firmware and calibration package that installs the radio firmware and board calibration files into the correct Linux firmware paths, packaged as architecture-independent so it drops cleanly into our build.
• A control CLI utility for low-level radio diagnostics and configuration, compiled with USB and netlink support and wired into our image as a standard system binary.
On top of that, we made kernel-level configuration changes to satisfy the driver's requirements, set up automatic module loading at boot, and built out a full connection lifecycle: secure network association, DHCP, routing configuration, and a systemd service that brings the HaLow link up automatically and keeps it running, with regulatory settings configured for our target markets. We also built out live diagnostics — signal strength, link state, and radio-level statistics — so the link can be monitored and tuned in the field, not just in the lab.
The result is a gateway that can now offer long-range, sub-GHz Wi-Fi as a first-class connectivity option, integrated into our production BSP rather than running as a one-off proof of concept.
The HaLow stack layered into the gateway's custom Yocto BSP, from radio to network uplink.
Porting HaLow Down to Our Field Device MCU
The second, harder problem: our gateway can afford a Linux-class application processor, but many of our field devices run on a leaner STM32F4 microcontroller. Morse Micro's reference driver and sample code for their HaLow transceiver were written for the STM32U5 — a chip from a completely different, ultra-low-power family. Getting HaLow onto our STM32F4-based hardware meant re-architecting the driver rather than simply recompiling it.
The Morse Micro MM8108-EKH05-01 development board used for the STM32F4 porting work.
A few of the harder problems our team solved along the way:
• DMA architecture. The U5's modern linked-list DMA engine has no equivalent on the F4, which uses the older stream/channel DMA model — the SPI transfer logic that feeds the radio had to be rebuilt from the ground up.
• Power management. The U5 reference design assumes aggressive sleep states; our F4 target runs “always-on,” so the low-power logic had to be stripped out and replaced with a simpler, continuously-active implementation.
• Missing hardware blocks. The U5's hardware random number generator, used by the radio SDK, doesn't exist on the F407 — our team implemented a software fallback to satisfy the SDK's requirements.
• Clock generation. The HaLow transceiver needs a precise 32.768kHz sleep clock. Rather than adding external crystal hardware, we repurposed one of the F4's general-purpose timers to generate it in software.
• RTOS and networking integration. Morse Micro's OS abstraction layer had to be mapped onto our FreeRTOS environment, with careful memory placement to give the TCP/IP stack the buffer headroom it needs.
Five areas of the reference driver that needed re-engineering to run on the STM32F4.
Piece by piece, this turned a reference implementation for one microcontroller family into a working HaLow stack for another — bringing long-range, low-power wireless connectivity within reach of our smaller, cost-sensitive edge devices, not just our gateways.
Why This Matters
Wi-Fi HaLow sits in an interesting spot for us: longer range and lower power than conventional Wi-Fi, but with full IP networking that protocols like LoRaWAN don't offer out of the box. Having it working across both ends of our hardware stack — from gateway to field device — gives us a new connectivity option to bring to industrial monitoring, remote sensing, and other deployments where cellular is costly, Wi-Fi doesn't reach, and low-power IP connectivity matters.
We'll be sharing more as this work moves from engineering validation into our products. If you'd like to talk about HaLow, IoT connectivity, or embedded design in general, reach out to us at info@inthings.tech or visit www.inthings.tech.
