The WM6108 seems to take around 5-6 sec to connect to a network after waking up from sleep. How can this be reduced? Given the high connection time, this device cannot be used with batteries.
Sorry, can you please clarify a bit more? What sort of sleep, DTIM, WNM? And what parameters eg. DTIM timing are you using?
We are not using wnm feature as we want to lower the inactive mode current. We are currently resetting the modem after each communication.
Are you saying if we use wnm mode we will not have to reconnect with AP?
This is a battery-powered application so the goal is to have the lowest sleep current and fastest connect time.
We are currently resetting the modem after each communication.
Resetting the modem, as in essentially power cycling the chip?
Starting from zero each time means not only does the firmware in the chip need to go through the full initialization process, but then the full association process with the AP needs to be redone.
The association process in particular takes a good chunk of time, for example if you cycle standard Wi-Fi on your phone or computer, it takes a good handful of seconds to reestablish connection to the network.
Yes using WNM means that you don’t incur the time and transmit costs of association when the chip comes back up. It does need some configuration on the AP’s side however, both enabling and setting the max timeout, otherwise the AP will drop the STA’s session and it’ll have to reassociate anyways.
Ok, We are using WNM now. DTIM of the AP is set to 3.
Beacon periodicity is 100 ms.
We noticed an improvement in the connection re-establishment (Reactivation). However, when the device drives the chip into WNM sleep mode (with chip_powerdown_enabled) we noticed much higher current (around 6 mA) as compared to the 40uA we could achieve using the Reset Mode.
This is how we are driving the wnm sleep.
wnm_sleep_args.wnm_sleep_enabled = false;
wnm_sleep_args.chip_powerdown_enabled = true;
status = mmwlan_set_wnm_sleep_enabled_ext(&wnm_sleep_args);
Are we doing that right?
From your testing, what should the current of the WNM mode with chip power down be?
That sounds like the chip isn’t actually sleeping, those settings look correct from a first glance.
Looking back at your hardware for this, in your OP you mentioned the WM6108, is this the WIO-WM6108 from Seeed?
If so, looking at the schematic, the wake line is tied high, meaning the chip wouldn’t be able to sleep at all. If you’re comfortable, you should be able to remove R9 and fly wire that (on the side leading to the module, not the reg) to a GPIO on your host. You’ll have to then make sure that pin definition is adjusted.
The module we have is from Vantron. sku - VT-SOM-AH
Ahh yes the VT-SOM-AH should have the hardware setup to sleep then.
On a second look with code formatting added (didn’t register the assignment, just the right flags were there), wnm_sleep_enabled should be set to true, the chip_powerdown_enabled is an extension on top of the wnm sleep, so having sleep disabled also prevents powerdown, so should be:
wnm_sleep_args.wnm_sleep_enabled = true;
wnm_sleep_args.chip_powerdown_enabled = true;
There’s an example in the mm-iot-sdk here.
This is our use case Michael, Sorry I sent you the settings that we use to wake up from WNM sleep.
The sleep entry, however, is :
struct mmwlan_set_wnm_sleep_enabled_args wnm_sleep_args = MMWLAN_SET_WNM_SLEEP_ENABLED_ARGS_INIT;
wnm_sleep_args.wnm_sleep_enabled = true;
wnm_sleep_args.chip_powerdown_enabled = true;
status = mmwlan_set_wnm_sleep_enabled_ext(&wnm_sleep_args);
if (status != MMWLAN_SUCCESS)
{
DIAGNOSTIC_LOG("WNM Enable Failed, Shutting Down Modem ", (uint16_t)(status), radix_decimal, true);
\_ASSERT(MMWLAN_SUCCESS == mmwlan_sta_disable());
}
else
{
tstr_event str_event;
str_event.enu_event_id = event_ap_disconnected;
ncd_wifi_dev_event_handler(str_event);
}
Yup that looks better-
Next question, how long is your device sleeping for? This may be a case where opting for DTIM is better.
There’s a break point where the extra radio usage overhead of negotiating sleep states with the AP obviates the savings from the chip actually sleeping. Section 3 in our Measuring Low Power App note (Section is specifically comparing WNM and DTIM as opposed to taking measurements) is a pretty good comparison of the break point where the TX power cost of WNM negotiation beats out the polling of DTIM. The interval is actually fairly long, eg for DTIM3 as you have set it’d likely be north of 20s.
The duration of the sleeping interval will be determined by end users and can range from 1 minute to 24 hours.
I do not think I get it.
We do not wake the device up every min or so in our testing. Device sleeps at least for 30 mins.
if negotiation takes longer than 20 seconds, the chip should eventually go to power down.
Can you also elaborate on if the mmwlan_set_wnm_sleep_enabled_ext is synch api?
From the documentation, I conclude that it is synchronous API. So once that returns , it means the negotiation is over . . . is that correct?
30 mins is plenty of time for the WNM negotiation’s TX power spikes to be amortized.
Yes, it’s a blocking call, it should wait for an ACK from the AP. Is this where the 20s negotiation that you alluded to occurs? That’d essentially be a timeout failure at that point if so, the chip won’t enter WNM sleep without the AP’s approval.
Would you be able to grab a wireshark capture (pcap) of the device going into and coming out of sleep with a much shorter (few secs) interval?
We have been stuck in this situation for weeks now, can we schedule a call and go over it?
Sorry, the WNM not functioning with your setup would be a relatively new development, as before the chip was being reset which meant an extensive on time for initialization, plus the TX penalty of the fresh association process each time.
We try to keep things in the forums as much as possible, both for resource constraints, but also more importantly this is meant to be a place where people come to find answers, rather than finding things being solved offline out of view.
At this point a call would result in us asking for bunch of missing information, I’ll run you through the things that will be asked for all at once to expedite the process.
1 Network information:
A ) Least invasive, easiest to walk through, did you configure your AP for WNM? It’s default disabled.
B ) AP configuration, specifically the HaLow interface dump, if you’re on openwrt with that’d be uci show wireless.default_radio1 if your HaLow interface is on radio1. Make sure this doesn’t include credentials.
C ) Wireshark capture (pcap) because it can show if/why there is a failure with the WNM sleep negotiation. This is the most comprehensive as it’ll indicate which side of the WNM process is failing.
2 Hardware layout:
A ) Which pins on the Vantron module are you targeting for power profiling
B ) What/where are you measuring across
C ) What device/meter are you using for measurement.
3 Power profiles:
Most self explanatory, having a few detailed power captures for comparison will help narrow things down. Thankfully the Vantron module has the same STM32 U5 family MCU as our MM6108-EKH05 so we do have hardware out in the wild to sanity check this:
Power captures of the sleep process (entering and exiting):
A ) your hardware running you application.
B ) your hardware running the mm-iot-sdk WNM sleep example
C ) your application running on the EKH05-MM6108
The first power capture is ostensibly the easiest, the following two are far more valuable, as the former gives insight into if your hardware is capable of sleep using a known good software implementation, and the latter shows that your application is sleeping on known good hardware. The WNM sleep example has its power consumption profiled on the EKH05 platform as part of our release process so we have something that we’ve validated as a point of reference.
4 More code and debug logs:
A ) How is your host sleeping?
B ) Recompile with debug symbols enabled, get the output of sleep being entered and exited.
For network, we could not see the wnm_sleep_mode as a default setting.
We introduced the entry by uci set. However , it did not change anything.
Our MM AP linux release is BusyBox v1.35.0 (2023-04-27 20:28:15 UTC),
If the entry does not exist by default, does that mean the feature is not supported ?
Why would the AP credentials play any role in this?
My next step is using ur wnm demo (after porting it to ventron).
We are using Digital Scope for power profiling not an io.
Again, the MCU (ST in this case) is sleeping as should, it is the MM Modem that seems to withdraw the current.
Our MM AP linux release is BusyBox v1.35.0 (2023-04-27 20:28:15 UTC),
If the entry does not exist by default, does that mean the feature is not supported ?
Why would the AP credentials play any role in this?
The AP does need to support it, and have it enabled. It’s why a monitory capture of the sleep process or attempt thereof is useful, can more clearly see which device is failing the WNM handshake. The WNM feature isn’t readily visible in the UI and has to manually be added to the config. You should be able to check if the hostapd has any of the wnm related strings included in its binary.
strings /usr/sbin/hostapd 2>/dev/null | grep -E 'wnm_sleep_mode|bss_transition|BSS_TM'
AP creds are often just spat out in plain text in the logs and config files so it was just a quick reminder to comb them before sending anything.
That power capture does look like the chip is idle instead of sleeping. Especially with poweroff that should be much lower.
the output is
root@MorseMicro-6809cd:~# strings /usr/sbin/hostapd 2>/dev/null | grep -E ‘wnm_sleep_mode|bss_transition|BSS_TM’
bss_transition_query_rx
bss_transition_request_tx
bss_transition_response_rx
root@MorseMicro-6809cd:~#
So no wnm related strings.
We are also having problems with even upstream connections:
We have recently switched to your MM AP (MM6108 EKH03) as part of testing wnm. We could not be sure if AsiaRF AP supported wnm as we did not have access to the shell. (They are probably not using OpenWrt)
I followed the instructions given in your guide:
https://www.mouser.com/pdfDocs/UGMM6108-WebGUIUserGuide222.pdf?srsltid=AfmBOorksHhTKpL35aStm_unzv5G8aFnfJlLyYBAcdbzCacru6TvPJlI
to try establish Non-standalone AP with routing so that our units (Stations) can access the internet through the EKH03.
Having configured the EKH03 as AP and followed section 3.3, then connected the LAN cable to the same GW used by AsiaRF AP,
our units could connect to the AP but could not get to the internet !
If we reconfigure our unit to connect to the AsiaRF AP, everything works fine.
The EKH03 we have uses linux kernel 5.10.
Are we missing something?
This is urgent as it is blocking all our testing especially the wnm !
Sorry, rereading that I’ve missed the s1g suffix and targeted the wrong hostap binary with that command, should be:
strings /sbin/hostapd_s1g 2>/dev/null | grep -E ‘wnm_sleep_mode|bss_transition|BSS_TM’
Assuming that command is still not displaying any wmn related lines, hostap wnm flag is disabled by default, so getting the hostap built with CONFIG_WNM=y set should address that. This will have been turned on by default for our OpenWrt 2.2 release onwards.
On your uplink issue, do you have the upstream DHCP server & DNS provisioning denoted in the top of the section 3.14 of the guide you’ve linked? The AsiaRF AP could be providing those out of the box.
Again a packet capture would help a lot here, we’d be able to see both where the WNM exchange first breaks down, and diagnose the potential DHCP and DNS issues from the same capture.
Just adding the @michael.mccandless post - from the power traces you’ve shown it looks like the device is not entering WNM sleep. Please follow the guide at https://www.morsemicro.com/resources/appnotes/MM_APPNOTE-36_How_to_do_a_Sniffer_Capture.pdf with another Morse Micro linux based eval kit so we can assess the negotiation.
While the instructions provided by the guide should work for 2.2, that version of the EKH03 software is quite outdated. You may find newer versions offering wizard based configuration to be more appropriate. See Wi-Fi HaLow EKH03 | OpenWRT Kit Image 2.11.12 for an updated EKH03 image.