I’m working on the OpenMV HaLow camera (MM8108 module on our own shield, mm-iot-sdk 2.12.3 / morselib, custom host: STM32N6 running MicroPython with our own network.HALOW driver over SPI). I’m trying to get low-power wake-on-directed-packet working: the host MCU fully powers down (deep sleep), the MM8108 stays powered and holds the link, and an incoming packet addressed to us wakes the host.
Our hardware is already set up for this: the shield keeps the MM8108 powered/un-reset through host deep sleep, and module GPIO8 (BUSY) is wired to the host’s wake pin. Following your community-forum guidance (the WAKE_ACTION_GPIO thread), I set MORSE_CMD_PARAM_ID_WAKE_ACTION_GPIO = 8 and …_PULSE_MS = 200 (GET confirms both), which should pulse that line on wake.
I then drove the standby-offload command family (MORSE_CMD_ID_STANDBY_MODE, 0x0031) directly through our command passthrough. Every command is accepted (status = 0) and the association stays up:
SET_CONFIG — accepted with the V1 layout (cmd=2); cmd=7/V4 returns -32768
SET_WAKE_FILTER (cmd=4), ENTER (cmd=1, with the real BSSID + is_umac_controlled=1), EXIT (cmd=0)
The problem: after ENTER + host deep sleep, sending a directed UDP packet to the STA’s IP:port does not wake the host — the wake line never pulses. I tried both a zeroed and the real monitor_bssid. I also saw in your release notes that “Standby and Offload features of the MMWLAN API are in development and may not be fully functional,” so I want to confirm status before I chase config.
Questions:
Is standby-offload expected to be functional on MM8108 + morselib 2.12.3? Any known limitations or a target release where it’s finalized?
SET_WAKE_FILTER: what is the offset reference point (start of 802.11 frame? de-encapsulated IP frame?), and how do we express “wake on packets addressed to our IP / a specific UDP port”? A concrete example filter would help enormously.
SET_CONFIG (V1): field semantics — especially src_ip/dst_ip byte order, the roles of notify_period_s / deep_sleep_period_s, and whether SET_STATUS_PAYLOAD and/or DHCP-offload must be configured first. Which config version should we use for 2.12.3, and its exact struct?
is_umac_controlled: what does the host supply vs. the chip when this is true vs. false? Is monitor_bssid required, and in which mode?
Host wake in standby: beyond setting WAKE_ACTION_GPIO (param 8), is anything else required for the chip to actually toggle the host wake line when a wake-filter packet arrives?
Host re-attach after full power-down: our host loses RAM in deep sleep and reboots. What’s the intended flow to resume the standby session and learn the wake reason? (We see the wpa_supplicant standby_session_dir persistence — is there an equivalent path for a bare-morselib host that isn’t using your wpa_supplicant integration?)
Happy to share a minimal reproduction or logs. This is the last piece for a genuinely low-power HaLow camera, so any guidance is much appreciated.
We marked standby/offload APIs as deprecated in mm-iot-sdk 2.10 and removed the APIs in release 2.11. At the time the implementation was not production ready (on either SDK nor FW side) and we had several outstanding issues that outweighed the benefit. I believe the FW team have recently picked up several of the offload features to improve the reliability and performance, but it would be several months before that’s made available to the IoT SDK and there’s no plan on the roadmap for us to add support for offload.
The operating model we support today is like on the EKH05 where we run the MCU as normal and have it drop into STOP2 deep sleep when there is no work to do, and we wake from timers elapsing or the SPI interrupt or busy pin being raised by the chip. Depending on your systems traffic profile you can look into various low power modes for the chip such as high DTIM, WNM sleep etc.
So, I was able to get the device to wakeup on the BUSY pin for all traffic on the network. However, I was not able to get the device to filter the packets such that wakeup would only be on something addresses to us. Like, UDP broadcasts were waking us up…
So, is there a solution for this? Like only wakeup on UDP/TCP traffic for our IP address?
Right now, only BUSY is tied to our wakeup pin, but, I can modify our hardware such that IRQ wakes us up too in deepsleep mode.
Traffic is filtered by mac address not IP address and I don’t believe there’s a way to filter broadcast traffic out, technically broadcast traffic is addressed to to the host.
As an FYI, we did have a FW bug where in some instances traffic not for us was passed up. That was fixed in FW2.0 which is available in the IoT SDK 2.13.1 - it would be worth updating either way as FW2.0 had several big improvements. I checked the release notes, seems like we missed adding some of this detail, will try do better next time!
Traffic is filtered by mac address not IP address and I don’t believe there’s a way to filter broadcast traffic out, technically broadcast traffic is addressed to to the host.
You guys need to get that on your roadmap. I’ll be starting MicroPython integration with Newracom after I finish with MorseMicro. I was informed they have this capability. It’s rather important as it allows push notifications from a server to wakeup a device. Quite essential for a battery powered device being able to be waked remotely.
In your original post you indicated you were using SDK 2.12. Does that mean you have since updated to 2.13?
I don’t have a timeline to quote, but I’ve heard this is in the works
I’m a little confused here, how does filtering out broadcast traffic help a server wake a device?
On a separate note, if you’re having power issues due to unwanted broadcast traffic, you can update the AP configuration to filter a lot of this out and minimise the amount of broadcast traffic floating around
The broadcast traffic just wakes the device with each broadcast packet. However, what I want to be able to do is have the device wake up when it receives a non-broadcast packet addressed to it.
I was able to get it working as mentioned and waking up on each packet received, but, not on only non-broadcast packets.
As before, I would strongly recommend updating to 2.13.1 as there was some significant improvements around the chip incorrectly passing up traffic that is not intended for the host. I wouldn’t be surprised if this is impacting this exact issue you’re observing! Morse Micro MM-IoT-SDK release 2.13.1 · MorseMicro/mm-iot-sdk@d637247 · GitHub
