nRF7002 drops downlink in power save / RPU powers down RX while still advertising PM=0 (no PM=1 Null), so the AP delivers directly and the frame is lost

RE: nRF7002 drops downlink in power save / RPU powers down RX while still advertising PM=0 (no PM=1 Null), so the AP delivers directly and the frame is lost

Simonr — Thu, 06 Aug 2026 06:09:50 GMT

Thank you for the update Valentin

We have some more suggestions you can try after looking into the logs.

1. Please test the CONFIG_NRF70_RPU_PS_IDLE_TIMEOUT_MS Kconfig with values of 50 ms and 100 ms, and check whether either of these make any difference on your end.

2. After that, please enabled the CONFIG_NRF_WIFI_PS_INT_PS=y Kconfig. Since you've already tested with WIFI_PS_PARAM_EXIT_STRATEGY=EVERY_TIM, please try the same setup with CONFIG_NRF_WIFI_PS_INT_PS=y enabled instead of "EVERY_TIM", and observe if there's any change in the behavior.

It appears that the on-air capture does not match the analysis_report from your .zip folder. Can you provide the on-air capture/sniffer trace corresponding to the analysis_report?

Best regards,

Simon

RE: nRF7002 drops downlink in power save / RPU powers down RX while still advertising PM=0 (no PM=1 Null), so the AP delivers directly and the frame is lost

ValentinKunti — Mon, 03 Aug 2026 05:59:43 GMT

Hello simonr,

Yes we can unfortunately the logs are not very help full for this issue since we only sees the device failed and stoped you already have the logs on the last ZIP for the download failed if you want to check the logs + air sniffer.

The issue is active on almost all access point since it's not an access point issue but the nRF7002 that goes to sleep and never wakeup to grab the info !

RE: nRF7002 drops downlink in power save / RPU powers down RX while still advertising PM=0 (no PM=1 Null), so the AP delivers directly and the frame is lost

Simonr — Mon, 03 Aug 2026 05:55:09 GMT

Hello

Marte is out of office, so I have taken over the ticket while she's away. Apologize for the delayed reply, but we had to review this issue and try to recreate it on our end. We saw some issues with select access points, but not with most of them with/without PSM.

It would be helpful if you could upload logs of the issue occurring on your end so we can analyze it further, as well as answer the following questions:

Is this issue occurring with a specific Access Point? If so, which access point? One of the ones we saw issues with was UniFi AP AC Lite for example.
Have you tried reproducing the issue with any other AP models?

Best regards,

Simon

RE: nRF7002 drops downlink in power save / RPU powers down RX while still advertising PM=0 (no PM=1 Null), so the AP delivers directly and the frame is lost

ValentinKunti — Thu, 23 Jul 2026 06:38:50 GMT

Yes, long firmware update with STBC off does not work same as with it ON. this download only works in non low power mode.

We can't see a lot in the air sniffer since the nRF7002 goes to sleep and does not wakeup anymore, the server still send all the data but of course since nRF is in off state we don't have the data and we timeout.

Best regards

RE: nRF7002 drops downlink in power save / RPU powers down RX while still advertising PM=0 (no PM=1 Null), so the AP delivers directly and the frame is lost

Marte Myrvold — Mon, 20 Jul 2026 12:01:17 GMT

Hi,

Have you been able to test long firmware update with STBC disabled?

As far as I understand it, disabling STBC is a workaround or testing to narrow down the issue. As such, this specifically is not something that will be patched. They have not yet found a bug or underlying issue.

Best regards,
Marte

RE: nRF7002 drops downlink in power save / RPU powers down RX while still advertising PM=0 (no PM=1 Null), so the AP delivers directly and the frame is lost

ValentinKunti — Thu, 09 Jul 2026 13:21:44 GMT

Thank you,

The question was most about strange config that resolve some issue like the STBC config.

An other issue we have on the same AP and other AP too, is that on long firmware upfate 900k at arround 15ko/s the nRF7002 just go to sleep and don't wake up anymore for a DTIM so our Firmware download failed : devzone.nordicsemi.com/.../OTA-failed-nRF70.zip

Best regards

RE: nRF7002 drops downlink in power save / RPU powers down RX while still advertising PM=0 (no PM=1 Null), so the AP delivers directly and the frame is lost

Marte Myrvold — Thu, 09 Jul 2026 11:50:10 GMT

Hi,

We have some configuration recommendations based on use cases and desired performance in our documentation here: Wi-Fi stack configuration and performance.

I can also give some additional recommendations. Most of these are default configurations, so you just need to make sure you do not change them.

1. Band selection: Use dual-band (default).

The nRF7002 supports both 2.4 GHz and 5 GHz. For maximum AP compatibility across diverse customer environments, do not restrict to 2.4 GHz only (i.e., avoid CONFIG_NRF_WIFI_2G_BAND=y or CONFIG_NRF70_2_4G_ONLY). Leaving dual-band enabled ensures the device can connect to the widest range of APs.

2. Power save mode: DTIM-based (default).

DTIM-based power save is the default and offers the best compatibility across all AP types since every AP broadcasts DTIM beacons. Avoid using Target Wake Time (TWT), as it requires the APs to support Wi-Fi 6.

3. Dynamic power save (default)

The dynamic power save feature is enabled by default. It automatically switches between Active and Power Save modes based on traffic, using an inactivity timer (default: 100 ms).

Other than that, I recommend looking at the configurations we use in our samples.

Best regards,
Marte

RE: nRF7002 drops downlink in power save / RPU powers down RX while still advertising PM=0 (no PM=1 Null), so the AP delivers directly and the frame is lost

ValentinKunti — Thu, 09 Jul 2026 09:28:16 GMT

We've just tested it with our device effectively this resolve a lot of our issue with re connection I will also try to see if the long upload (FW update it's solved with this). Here you have a ZIP with all the caputre + device logs and result analysis.

Do you know if this will be patched on a futur SDK ?devzone.nordicsemi.com/.../roomz_5F00_stbc_5F00_ab_5F00_nordic_5F00_20260709.zip

RE: nRF7002 drops downlink in power save / RPU powers down RX while still advertising PM=0 (no PM=1 Null), so the AP delivers directly and the frame is lost

ValentinKunti — Thu, 09 Jul 2026 06:30:34 GMT

Hello,

Thank you for the information I will test this today, also I have a question about the best config for the nRF7002 to work on the most of the AP and platfrom.

In our use case we have a lot of customer with different settings from access point to enterprise network to personal network, Our only restriction is low power, do you have a settings that you know is the more robust for those type of connection and you know works with the most AP ?

Best regards,

Valentin Künti

RE: nRF7002 drops downlink in power save / RPU powers down RX while still advertising PM=0 (no PM=1 Null), so the AP delivers directly and the frame is lost

Marte Myrvold — Thu, 02 Jul 2026 07:49:37 GMT

Hi,

The testing is done with low power mode, i.e., CONFIG_NRF_WIFI_LOW_POWER=y.

Our team observed that when STBC is disabled, retransmissions are dropped. Can you try disabling STBC and see if that affects the behavior? Please upload a sniffer log if possible. You can dsable it with the following Kconfig option:

CONFIG_NRF_WIFI_RX_STBC_HT=n

Best regards,
Marte

RE: nRF7002 drops downlink in power save / RPU powers down RX while still advertising PM=0 (no PM=1 Null), so the AP delivers directly and the frame is lost

ValentinKunti — Wed, 01 Jul 2026 12:46:50 GMT

Yes this is the acces point we have the most issue in and the one we have in our office, I will check other one but for example Swisscom AP works very well on it.

Will check for our client AP configuration, did you find this issue with the pm and AP that are not working with bufferised data when the nRF7002 are in low power mode ? we only have this issue with nRF7002 in low power mode.

Best regards,

Valentin Künti

RE: nRF7002 drops downlink in power save / RPU powers down RX while still advertising PM=0 (no PM=1 Null), so the AP delivers directly and the frame is lost

Marte Myrvold — Wed, 01 Jul 2026 12:44:02 GMT

Hi,

Do you have an overview of which access points work and which do not when you are testing?

Our team is observing a high number of retransmissions with the UniFi AP AC Lite, but not with other access points they are testing with.

Best regards,
Marte

RE: nRF7002 drops downlink in power save / RPU powers down RX while still advertising PM=0 (no PM=1 Null), so the AP delivers directly and the frame is lost

ValentinKunti — Mon, 29 Jun 2026 05:58:53 GMT

Thank you,

If it can help i've seen it happends on different access point, it works perfectly fine on some, and don't work at all on other ones.

RE: nRF7002 drops downlink in power save / RPU powers down RX while still advertising PM=0 (no PM=1 Null), so the AP delivers directly and the frame is lost

Marte Myrvold — Fri, 26 Jun 2026 13:15:38 GMT

Hi,

The developers are trying to reproduce the issue, but they have not seen any disconnects yet. They are observing some retransmissions and are currently investigating them.

Best regards,
Marte

RE: nRF7002 drops downlink in power save / RPU powers down RX while still advertising PM=0 (no PM=1 Null), so the AP delivers directly and the frame is lost

Marte Myrvold — Tue, 23 Jun 2026 09:25:27 GMT

Hi,

I just wanted to let you know that the developers are still looking into this. I do not have an update from them yet, but I will let you know when I have more information.

Best regards,
Marte

RE: nRF7002 drops downlink in power save / RPU powers down RX while still advertising PM=0 (no PM=1 Null), so the AP delivers directly and the frame is lost

ValentinKunti — Fri, 12 Jun 2026 11:41:34 GMT

For the access point we are using a unifi uap ac pro

RE: nRF7002 drops downlink in power save / RPU powers down RX while still advertising PM=0 (no PM=1 Null), so the AP delivers directly and the frame is lost

ValentinKunti — Fri, 12 Jun 2026 11:39:18 GMT

Hi,

Thank you for the response, here is the logs files for the capture !

devzone.nordicsemi.com/.../devzone_5F00_nrf7002_5F00_ps_5F00_rx.zip

best regards

RE: nRF7002 drops downlink in power save / RPU powers down RX while still advertising PM=0 (no PM=1 Null), so the AP delivers directly and the frame is lost

Marte Myrvold — Fri, 12 Jun 2026 11:25:27 GMT

Hi,

I will report this internally.

Can you share a sniffer log of this as a pcap file? If the packets are encrypted, make sure to share the decryption keys.

What access point are you using?

Best regards,
Marte

RE: nRF7002 drops downlink in power save / RPU powers down RX while still advertising PM=0 (no PM=1 Null), so the AP delivers directly and the frame is lost

ValentinKunti — Thu, 11 Jun 2026 12:09:54 GMT

We kept the sniffer running and re-analysed a fresh session at the raw 802.11 layer. Two refinements to the original report, the second one extends it.

1. The clearest reproduction is gateway ARP, no decryption needed at all

Every failed DNS cycle in 10 capture sessions failed with -ENETUNREACH: the DNS server is the gateway, and the gateway's ARP reply is what gets lost. The pattern, one failed and one successful attempt 4 s apart in the same association (device 14:e2:89:11:1e:32, gateway behind the AP 70:a7:41:f7:57:e6, RSSI -60):

failed attempt
40.836  STA → broadcast   ARP request (QoS Data, 134 B)
40.850  GW  → STA         ARP reply, first delivery        +14 ms
40.852  STA → AP          Null PM=1                        sleep announced 16 ms after own TX
40.850 .. 40.870  GW → STA  14 copies, wlan.fc.retry=1, none ACKed, AP gives up
   next beacon TIM: partial virtual bitmap 78bb07 → 7abb07 = AID 1 (us) now buffered
40.938 .. 44.35   STA sends Null PM=0 / PM=1 several times, AP delivers nothing,
                  TIM bit for AID 1 stays set the whole time

successful attempt, same association, 4 s later
44.841  STA → broadcast   ARP request
44.841 .. 44.851  GW → STA  ~20 copies of the reply, STA finally ACKs one ~10 ms in
44.851  STA → GW          DNS query, cycle proceeds normally

In another window the reply arrived 0.7 ms after the device's own transmission and was already lost. So the receiver is off essentially at TX completion, and whether a connection attempt works is a race between the RPU re-opening its RX and the AP exhausting its MAC retry budget (16 to 19 retransmissions in 5 to 10 ms). This also explains why CONFIG_NRF70_RPU_PS_IDLE_TIMEOUT_MS 10/25/100 ms made no difference for us: the reply lands inside any of those windows.

2. When PM=1 is sent, the buffered frame is still never retrieved

This is the part that is new compared to the original post. In the ARP case above the station did announce PM=1 (16 ms after its TX, 2 ms after the first delivery had already died un-ACKed). The AP then does everything right: it buffers the next reply and sets the TIM bit for AID 1, verified in the beacons (78bb07 → 7abb07, bitmap offset 0). The station announces PM=0 several times over the following 3.5 s and the AP delivers nothing; the TIM bit stays set until the station gives up and re-ARPs. So both legs of power save fail: receiving while advertised active, and retrieval of buffered traffic after advertised sleep. Tuning the exit strategy so the AP buffers more (EVERY_TIM) cannot help if the pickup never happens.

One more data point: the station's own Null and data frames are sent 3 to 4 times back to back (retry=1), so it also misses the AP's ACKs to its own transmissions right after TX, consistent with the RX being gated off at TX completion.

This narrows question 2 from the original post: even when the PM=1 Null does go out and the AP buffers correctly, why does the RPU not collect the buffered frame on its next wake?