nRF7000 sleep current

RE: nRF7000 sleep current

Roman Veselskyi — Fri, 31 Oct 2025 09:02:38 GMT

Hello Elfving, thanks for the update.

We had an issue with Wi-Fi on the previous PCB as well, but that one was related to 3.3V on the IOVDD pin. We have a private ticket about it. In that case, the power consumption was 1 mA, so we created a new revision with 1.8V — which solved the 1 mA issue. However, I’ve noticed that we now have an additional ~100 µA in sleep mode.

RE: nRF7000 sleep current

Elfving — Wed, 29 Oct 2025 14:58:22 GMT

Hi again, and I am so sorry about the wait,

Note that the issue regarding CONFIG_LOCATION_METHOD_WIFI_NET_IF_UPDOWN is fixed now. I assume this can just be cherry picked.

[quote user="Roman Veselskyi"]

I also found this one, will migrate to 3.1.1 and test.

[/quote]

I believe this issue is not just fixed in 3.1, but comes with a set of recommendations regarding pins that needs to be grounded etc. Maybe a previous version had a different IOVDD? Though if you didn't see this issue with a previous version of the board (in which the Wi-Fi part was the same) that is likely not the the cause of the issue you are seeing now, but it is still worth having another look at the schematics with those recommendations in mind.

If you could send the schematics we'd be happy to take a look.

Getting what you are seeing reproduced on a DK could also be an idea, though I understand that is not a tempting route.

[quote user="Roman Veselskyi"]

Exactly this one no, but for the previous revision yes - WIFI part didn't changed.

[/quote]

And the power consumption wasn't an issue in those previous versions?

Regards,

Elfving

RE: nRF7000 sleep current

Roman Veselskyi — Thu, 16 Oct 2025 14:47:23 GMT

Hello Elfving ,

Yes, I see the same behavior on 3 boars I have. For this moment I implement the power down of the interface by us in the location module it saves us 100uA, but I believe to use the library implementation should be more robust.

I checked already the consumption for passive scanning and active, please check.

Passive

Active

RE: nRF7000 sleep current

Elfving — Wed, 15 Oct 2025 15:20:36 GMT

Hi Roman,

CONFIG_LOCATION_METHOD_WIFI_NET_IF_UPDOWN not being easily selectable is a bug, so we are fixing that.

[quote user="Roman Veselskyi"]I didn't write the OTP because we don't need that, we only scan the WIFI network and I am using the CONFIG_WIFI_RANDOM_MAC_ADDRESS=y config option.[/quote]

When it comes to the power consumption, this does look odd. So I am asking the R&D team about that as well. Are you seeing this on multiple boards?

Could you try the wifi shell sample, so that we could look at the consumption when it is scanning?

Regards,

Elfving

RE: nRF7000 sleep current

Roman Veselskyi — Wed, 15 Oct 2025 06:49:57 GMT

HelloElfving ,

Do you have any updates?

RE: nRF7000 sleep current

Roman Veselskyi — Mon, 13 Oct 2025 13:49:54 GMT

Elfving do you have any update?

RE: nRF7000 sleep current

Roman Veselskyi — Fri, 10 Oct 2025 14:57:06 GMT

Migration to the SDK 3.1.1 didn't give any benefits regarding power consumption.

RE: nRF7000 sleep current

Elfving — Fri, 10 Oct 2025 12:30:53 GMT

Nicely spotted! Please do.

Regards,

Elfving

RE: nRF7000 sleep current

Roman Veselskyi — Fri, 10 Oct 2025 11:28:16 GMT

I also found this one, will migrate to 3.1.1 and test.

RE: nRF7000 sleep current

Roman Veselskyi — Fri, 10 Oct 2025 09:38:29 GMT

Hello Elfving ,

I didn't write the OTP because we don't need that, we only scan the WIFI network and I am using the CONFIG_WIFI_RANDOM_MAC_ADDRESS=y config option.

RE: nRF7000 sleep current

Elfving — Wed, 08 Oct 2025 07:23:34 GMT

[quote user="Roman Veselskyi"]Just see it in the SDK.
[/quote]

That not being selectable is likely a bug, though it is surprising that it is not mentioned in documentation either. I'll ask the relevant R&D team what the idea is.

[quote user="Roman Veselskyi"]

Exactly this one no, but for the previous revision yes - WIFI part didn't changed.

[/quote]

Might be worth doing one for this one as well, although I am not so sure how anything there could explain this - so let's hold up on that for now.

Have you commisioned the nRF7 yet, ie. written to the OTP etc?

Regards,

Elfving

RE: nRF7000 sleep current

Roman Veselskyi — Mon, 06 Oct 2025 12:18:01 GMT

[quote userid="103347" url="~/f/nordic-q-a/124757/nrf7000-sleep-current/550658"]Have you had a HW review from us on this board?[/quote]

Exactly this one no, but for the previous revision yes - WIFI part didn't changed.

[quote userid="103347" url="~/f/nordic-q-a/124757/nrf7000-sleep-current/550658"]I'll look into this, though did you see any docs for this config btw? Or did you just see it in the SDK?[/quote]

Just see it in the SDK.

RE: nRF7000 sleep current

Elfving — Mon, 06 Oct 2025 08:23:17 GMT

[quote user="Roman Veselskyi"]

It is a custom PCB with nRF9160 + nRF52832 + nRF7000 + nPM1300. I am not sure if flashing the blinky sample will give us the actual sleep current.

[/quote]

I see. I guess it won't but it might show us if there is anything obviously wrong with it.

[quote user="Roman Veselskyi"]

I have the nRF9160DK and nRF7002EK, but to test properly I need to run our firmware on this setup, which will take some time because of the different pin connections.

[/quote]

Yeah when your board is this complex I understand that it won't be that straight forward to test it with a DK.

Have you had a HW review from us on this board?

[quote user="Roman Veselskyi"]How to enable this one for the custom PCB? [/quote]

I'll look into this, though did you see any docs for this config btw? Or did you just see it in the SDK?

Regards,

Elfving

RE: nRF7000 sleep current

Roman Veselskyi — Fri, 03 Oct 2025 14:26:30 GMT

Hello Elfving

It is a custom PCB with nRF9160 + nRF52832 + nRF7000 + nPM1300. I am not sure if flashing the blinky sample will give us the actual sleep current.

For example, this is the blinky sample built for the nRF9160DK (non-secure):

I tested my application with one additional configuration parameter - CONFIG_NRF_WIFI_IF_AUTO_START=n

Here are the results:

The peak consumption at the beginning is the LED indication each10 seconds, then you may see that the floor current is 28uA.

This is the results with CONFIG_NRF_WIFI_IF_AUTO_START=y

I have the nRF9160DK and nRF7002EK, but to test properly I need to run our firmware on this setup, which will take some time because of the different pin connections.

Another point of interest for me is the configuration CONFIG_LOCATION_METHOD_WIFI_NET_IF_UPDOWN. As I understand it, this option disables and then re-enables the nRF7000 interface, which in my opinion would be the ideal scenario for our device. We use the nRF7000 only for scanning in specific situations, and it would be better to keep it disabled at other times.

However, this option is currently disabled, and when I try to enable it I cannot build the application—it gives an error.

error: LOCATION_METHOD_WIFI_NET_IF_UPDOWN (defined at C:/ncs/v3.0.0/nrf\lib\location/Kconfig:45) is
assigned in a configuration file, but is not directly user-configurable (has no prompt). It gets its
value indirectly from other symbols. See
http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_LOCATION_METHOD_WIFI_NET_IF_UPDOWN and/or
look up LOCATION_METHOD_WIFI_NET_IF_UPDOWN in the menuconfig/guiconfig interface. The Application
Development Primer, Setting Configuration Values, and Kconfig - Tips and Best Practices sections of
the manual might be helpful too.

I also tried to debug to make sure this option is disabled. As you can see, the interface shutdown function is not included.

As I understand it is enabled only for the specific boards.

config LOCATION_METHOD_WIFI_NET_IF_UPDOWN
	bool
	default y if (BOARD_THINGY91X_NRF9151 || BOARD_THINGY91X_NRF9151_NS || BOARD_THINGY91X_NRF5340_CPUAPP || BOARD_THINGY91X_NRF5340_CPUAPP_NS)
	depends on LOCATION_METHOD_WIFI_NET_MGMT
	help
	  Use the Network Interface Up/Down APIs for Wi-Fi functionality.

How to enable this one for the custom PCB?

RE: nRF7000 sleep current

Elfving — Fri, 03 Oct 2025 11:59:01 GMT

Hi Roman,

This looks odd. Just to start off, let's confirm that the board has a normal consumption with something default. Could you run the blinky sample for me, and focus on the sleep current, or how low it goes between the peaks?

I assume you do not have a DK on hand? If you did, it would be nice to see if that acts the same way. For all we know this far, both the PPK, its connections, the custom FW, and the PCB could be at fault.

Regards,

Elfving