questions on minimizing power usage

[ccskevin32]

Hello, I have built the fruity mesh from git hub source and have been running some tests with 2 nodes connected and doing nothing else. I have measured the average power use to be 1.17ma and feel like the equipment and process used is reliable (agiliant 66332A with custom python control code). We would like to reduce the power more for some testing to determine if we can use this mesh in our battery powered research project.

I have tried to reduce the power by turning discovery off, sending the command as follows and getting the response. mhTerm: action 0 node discovery off {"type":"set_discovery_result","nodeId":1870,"module":0} {"type":"set_discovery_result","nodeId":1077,"module":0}

I have then observed no difference in power usage. I have created a vendor module that will log the value of GS->currentDiscoveryState which I am hoping indicates the discovery state, and no matter what it is always a value of 1. so my first question would be how to actually turn the discovery off and verify that it is switching from high to low to off, etc.

my next question would be how to change the parameters the code uses for discovery to conserve power. The documentation discusses this but I have not been able to understand which variables in what files should be changed.

my last question concerns the uart. in our application the uart will not be required and I read in the documentation that disabling it can save power. Please advise if this is the case and if so what steps are required to disable the uart such we can see the power savings.

Finally if there are any other things we can do to minimize power use please advise.

[siretty]

Hello @ccskevin32,

first of all thank you for considering FruityMesh.

In order to help you, I'll need to know which featureset you are using. This will be part of the name of the ..._merged.hex file you used to flash the nRF chip and you might have specified it in the ONLY_FEATURESET CMake variable during configuration.

For the following I'll assume you used the github_dev_nrf52 featureset as it is the one used in the Quick Start guide in the documentation.

After some inspection of the code handling the action ... node discovery ... command, it seems to me that the implementation is not handling the input as it is documented. I will create an internal bug ticket for fixing that and potentially updating the documentation.

For now you should be able to see an automatic switch to low discovery if you put

void SetFeaturesetConfiguration_github_dev_nrf52(ModuleConfiguration* config, void* module)
{
    if (config->moduleId == ModuleId::CONFIG)
    {
        Conf::GetInstance().defaultLedMode = LedMode::CONNECTIONS;
        Conf::GetInstance().terminalMode = TerminalMode::PROMPT;

        Conf::GetInstance().highDiscoveryTimeoutSec = 60; // <<< ADD THIS LINE
    }

into the featureset source file (here fruitymesh/config/featuresets/github_dev_nrf52.cpp). It activates an automatic switch to low discovery mode after 60s. You should also see a log message along the lines of

-- DISCOVERY HIGH --

or about a minute after the nodes have connected

-- DISCOVERY LOW --

in the attached terminal / log viewer.

The default values for many values related to power consumption (e.g. meshAdvertisingIntervalHigh, meshScanIntervalHigh, ...) are set in Config.cpp in Conf::LoadDefaults() and some in the corresponding header Config.h. You can overwrite these just like the highDiscoveryTimeoutSec in the featureset source file. The declarations are well commented in the Config.h file.

The compiled-in functionality available in FruityMesh is directly influenced by the defines in the featureset header. In the version currently available in this reposity you will find the following

//The following can be undefined to drastically change the size of the firmware
#define ACTIVATE_LOGGING 1 //Undefine to remove most human readable logs
#define ACTIVATE_JSON_LOGGING 1 //Undefine to remove json communication over uart
#define ACTIVATE_UART 1 //Undefine to remove the UART terminal
#define ACTIVATE_SEGGER_RTT 1 //Undefine to disable debugging over Segger Rtt

which means that the featureset activates logging and json logging, will log via UART, and makes it possible to view the logs via an attached SEGGER Debugger (e.g. using JLinkRTTViewer). If you don't need the logs on the node you are measuring power on, defining ACTIVATE_UART and possibly ACTIVATE_SEGGER_RTT (although I do not expect that to have as much impact) to 0 (or just removing the defines) will deactivate it.

I hope this will help you get started.

[mariusheil]

Hello, I'll close this as there has not been any more feedback. Feel free to reopen it.