Where did you get these EKH03s? The EKH03-03 is a pre-release unit which we did not sell on Mouser.
You may be able to still force the upgrade, but you will need change the BCF manually after upgrade. Before doing that, can you check df -h to make sure the device has 32MB of flash?
I’m going to say all this probably isn’t worth it, but upgrading the device so you have access to something which can be used as a sniffer is going to be very helpful when diagnosing further sleep related issues. So instructions for upgrading this pre-release device are as below.
We really would like to see a sniffer capture of the WNM setup sequence.
That’s good, you have a version with 32MB of flash. Force the update with
sysupgrade -F -n -v /tmp/openwrt-morse-2.11.12-morsemicro-ekh03-v4-squashfs-sysupgrade.bin
I would throw away your config and start fresh - 2.2 is quite outdated. That’s the -n flag.
Login to the UI, navigate to System → Administration → SSH Access page and make sure SSH access is enabled.
You will then need to extract https://github.com/MorseMicro/bcf_binaries/releases/download/v1.15.3/morsemicro-bcf-rel_1_15_3_2025_Apr_16.tar and scp the bcf_mf08551.bin to your device’s /lib/firmware/morse/. While an older version of the BCF, it will still be compatible with the firmware used in the 2.11 release.
The radio won’t work straight away, you will need to then edit /etc/config/wireless and add
option bcf 'bcf_mf08551.bin' to the radio configuration of option type morse.
Run reload_config to apply the changes.
As an alternative to what has now become a side-quest, @michael.mccandless will describe DTIM sleep to you, which should be possible to configure on the AsiaRF hardware
Would be a very minor change code wise, and a supported on your AsiaRF AP with the configured uplink. Setting it to a higher DTIM interval eg. 100 (255 should be max from memory since it’s an octet) should net substantial power savings since the settings you’ve mentioned before would have a DTIM snooze of about 307ms and DTIM 100 would bump that to about 10.24s.
On the device end you just need to make sure power save is enabled, which it should be by default but a few bytes worth of instructions for sanity’s sake during testing is worth it.
For DTIM testing just comment out the WNM entry and exit, since it would just be additional TX that isn’t doing much with the AP not supporting it.
This of course would be just for evaluating to see if our hardware’s power save is within or approaching your power budget requirements. WNM is a good power optimization given the traffic patterns of your device, but at this point it’s probably more important getting the ball rolling and unblock your testing. We can continue to drill into WNM if you’re happy with the results
I was able to update the firmware following the instructions @ajudge sent.
However, I still do not see any wnm-related features/settings !!
That’s because those commands aren’t checking for capability. Out of box uci will show the minimum configuration it needs to change the default. Instead see the strings command on hostapd_s1g above.
It should default to being on if it is not in your uci config, but to be sure run
uci set wireless.default_radio1.wnm_sleep_mode='1'
reload_config
And then collect a sniffer capture so we can verify the negotiation is working.
I’m trying to sniff the connection by wireshark, but im having issue connecting to the AP.
I can easily ssh into the AP, but when I follow your sshdump instructions , it says :
I have tried all my keys, none worked. I also tried without keys at all, still not working.
I removed the AP from the knownhosts lists and readded it by sshing from my machine terminal, but wire shark still does not work.
That error reads as if your ssh keys aren’t installed onto the EKH03. I wouldn’t bother with this myself though. Set a password on the device and use password auth in sshdump. Wireshark doesn’t like using un-authed ssh.
Remember the sniffer needs to be a third device in the mix, configured in Monitor mode, not AP. Otherwise we won’t see all the frames on the air.
WNM_test.zip (13.6 KB)
This is the sniff capture of 3 reports, 1 minute apart
What does that tell you?
And what should we look for?
Unfortunately your sniffer is not configured on the same channel as the AP. On the AP run morse_cli -i wlan0 channel to verify the primary channel. eg
# morse_cli -i wlan0 channel
Full Channel Information
Operating Frequency: 918000 kHz
Operating BW: 4 MHz
Primary BW: 2 MHz
Primary Channel Index: 1
Then set your sniffer to the same configuration.
For your benefit, I’ve set up our MM6108-EKH05 as a device which uses WNM sleep using a slightly modified version of our wnm sleep example - one which I can trigger transmission on a button press. I’ve collected a wireshark trace you can use for reference, and a power profiler trace of our HaLow power rail (VDDIO + VBAT). This is by no means super accurate - I just don’t have a Joulescope available to me at this time.
wnm-sleep.pcapng (104.9 KB)
wnm-sleep.ppk2 (4.2 MB)
The first spike of current you will see in my traces is boot and scanning
This correlates somewhere around frames 30-50 of the wireshark trace. There are many probe requests that won’t be shown due to the sniffer focusing on a single channel. This is what was causing your initial long connection time and why you would want wnm sleep. Do this once on first boot and then set the radio quiet.
The second current spike is the association and authentication sequence. On my wireshark capture this starts at frame 180 through to ~280.
The captures you care about for wnm sleep are the third current spike in my power profile capture.
This corresponds to the data transmissions between frames 390 and 464. The important frames we are looking for to verify that wnm sleep is functioning as expected is the WNM Sleep Exit - frames 390 and 395, and the WNM Sleep Entry, frames 460 and 463.
If those action frames aren’t present, the device is not sending the WNM sleep request frames, or the AP is not sending the WNM sleep response frames.
Outside of the transmissions, when our radio is in a suitable sleep mode, current consumption will typically sit ~40uA. Mine is showing an average of 16uA - expect some error here due to the Power Profiler.
You can also check to make sure your AP is configured to support WNM sleep by checking the Extended Capabilities of the Association Response frame (in my capture, inspect frame 243). WNM Sleep mode must be supported.
If you cannot configure WNM sleep on your AP, you may need to consider DTIM sleep - which will result in more frequent wake ups, but doesn’t require the client to send WNM sleep request frames - which below a certain wake interval can actually save power. This is actually on by default, you just need to tune the DTIM interval on the AP to suit your requirements.
If you collect all the above information, and are still seeing high current consumption, then we need to investigate the components around our radio. Is the host micro-controller (included on the Vantron module) correctly configured to enter suitable deep sleep state during idle? Is it configured correctly for tickless idle?