nRF7002dk UDP Client Power Consumption

Dear Devzone-Team,

I am working on an nRF7002 based IoT Sensor using the nRF7002DK. I managed to set up the WiFi in STA mode and connect to Raspberry Pi working as AP. The nRF7002 should act as a UDP Client and send data to the AP.  I managed to set up the socket and the communication to the Raspberry is working. 

Now the problem:
When I look at the measurements with the Power Profiler Kit II there is too much power consumption in my opinion. Without UDP transmissions I have roughly the power consumption mentioned in Operating in power save modes and Target Wake Time on the nRF7002 DK for the normal DTIM Mode.
However, it seems that for the UDP transmissions it takes a long time until the sleep mode is activated again (~60mA for around 150ms). Please look at the attached figure from the PPK2, where you can see the UDP transmissions every 1s. The narrow spikes are the DTIM and the broader ones (~150ms) are when the UDP transmission is started.

Maybe you can help me to reduce the power of the UDP transmissions to the absolute minimum. (Maybe the nRF7002 waits for an response by the AP?)

Here is the main file:

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/*
* Copyright (c) 2022 Nordic Semiconductor ASA
*
* SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
*/
/** @file
* @brief WiFi station sample
*/
#include <zephyr/logging/log.h>
LOG_MODULE_REGISTER(sta, CONFIG_LOG_DEFAULT_LEVEL);
#include <nrfx_clock.h>
#include <zephyr/kernel.h>
#include <stdio.h>
#include <stdlib.h>
#include <zephyr/shell/shell.h>
#include <zephyr/sys/printk.h>
#include <zephyr/init.h>
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

and the prj.conf

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#
# Copyright (c) 2022 Nordic Semiconductor ASA
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#
CONFIG_WIFI=y
CONFIG_WIFI_NRF700X=y
# WPA supplicant
CONFIG_WPA_SUPP=y
# Below configs need to be modified based on security
# CONFIG_STA_KEY_MGMT_NONE=y
CONFIG_STA_KEY_MGMT_WPA2=y
# CONFIG_STA_KEY_MGMT_WPA2_256=y
# CONFIG_STA_KEY_MGMT_WPA3=y
CONFIG_STA_SAMPLE_SSID="RSPILAN"
CONFIG_STA_SAMPLE_PASSWORD="silicon123"
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

I am using nrf connect sdk v2.4.1 currently.

Thanks in advance

Julian

Parents
  • Hi Julian,

    I have started looking into this and will get back to you later today.

    Best regards,
    Marte

  • Hi Julian,

    I have not been able to find a way to reduce the awake time for the UDP transmission, but I have asked internally.

    Another thing you do to reduce the power consumption is to use listen interval instead of DTIM as wakeup mode. You can set listen interval with the following:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    struct net_if *iface = net_if_get_default();
    struct wifi_ps_params params = {0};
    params.wakeup_mode = WIFI_PS_WAKEUP_MODE_LISTEN_INTERVAL;
    params.type = WIFI_PS_PARAM_WAKEUP_MODE;
    params.listen_interval = // your interval
    if (net_mgmt(NET_REQUEST_WIFI_PS, iface, &params, sizeof(params))) {
    LOG_ERR("Setting wakeup mode failed. Reason %s",
    wifi_ps_get_config_err_code_str(params.fail_reason));
    return -1;
    }
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Best regards,
    Marte

  • Hi Julian,

    I saw these additional spikes as well when testing yesterday. However, after I updated the Power Profiler app to v4.0.0-beta3 today and I no longer see the spikes when testing. I know there was a fix related to noise in the latest PPK2 firmware, but I do not know if it is related to this or not.

    Can you try updating as well and see if there is a difference? Please note that you will also have to update the firmware of the PPK2. You should get a prompt to update when selecting the PPK2 in the drop-down menu.

    I also saw spikes similar to yours shortly after the UDP transmission, but this was related to Power-Save poll sent from the device to AP and address resolution protocol (ARP) packet from AP to the device. All of this should show up in the Wireshark capture though, so it does not seem to be the case in your test since there are no packets.

    Best regards,
    Marte

  • Hello Marte,

    I updated the PPK2 but I have the same/similar results:

    I am pretty sure that where the marker starts is the start of the UDP transmission and the ACK is directly after that. But I measure nothing after which would explain the second plateau.

    I also observed these ARP messages from your measurement with "who has ...." but not in the one I sent to you. And they are not very frequent.
    Anyway, there is still the chance that I am missing something crucial or doing something wrong in the measurements.

    Additionally, I just saw that there is a (new?) example in the SDK "Wi-Wi: Raw TX packet". Do you think that if I try to create raw UDP packets with this sample I can achieve small transmission peaks without this long time until the device goes to sleep - or would I end up with the same result?

    br
    Julian

  • Hi Julian,

    Have you tested with a different network or different server?

    I am not able to reproduce the behavior you are seeing. I am testing with the Wi-Fi shell sample and sending with net udp send. When sending to an echo server I get two plateaus shortly after each other, and I could verify that the second was due to Power-Save poll and receiving response from the server based on the timing. When testing with a server that did not respond I only saw one plateau for the UDP and ACK.

    JulianKaroliny said:
    Do you think that if I try to create raw UDP packets with this sample I can achieve small transmission peaks without this long time until the device goes to sleep - or would I end up with the same result?

    I do not think this sample will help. By default power saving is turned off in the sample (CONFIG_NRF_WIFI_LOW_POWER=n), so it is not intended to be used with power saving.
    The sample sends raw 802.11 packets, so the fields of the MAC header are manually set in the code and you would have to set the fields of the NWK layer as well for the UDP packet.

    Best regards,
    Marte

  • Hey Marte,

    I will try to use a different server (and maybe also a different AP) and check if the problem is on that end.
    Thanks again for your fast replies and for your help. If I find anything new I will reach out here again or give an update. 

    best,
    Julian

  • Hi Julian,

    Please keep me posted if you find anything! I will do the same.

    I will start my vacation after tomorrow, and will be out of office until 2nd of January. If you have critical issues you can create a new ticket which will be assigned to one of the engineers working next week. Please note that due to reduced staffing there will be an increase in response time during the holidays.

    Happy holidays! Slight smile

    Best regards,
    Marte

Reply
  • Hi Julian,

    Please keep me posted if you find anything! I will do the same.

    I will start my vacation after tomorrow, and will be out of office until 2nd of January. If you have critical issues you can create a new ticket which will be assigned to one of the engineers working next week. Please note that due to reduced staffing there will be an increase in response time during the holidays.

    Happy holidays! Slight smile

    Best regards,
    Marte

Children
No Data