Can not reach low power state when radio is declared outside of main()

[charlesmodrich-tc]

Description of defect

Inability to enter sleep mode (or at least reach expected sleep mode average current) after calling
static LoRaWANInterface lorawan(radio); when working with NRF52840-DK + SX1262MB2xAS mbed shield

even when building with Develop profile. Results in average "sleep" current of ~6.5mA. Uncommenting all code before main() (except for above line) and removing all code except sleep_for within main() yields expected sleep current (~14uA).

Target(s) affected by this defect ?

NRF52840-DK

Toolchain(s) (name and version) displaying this defect ?

Mbed Studio 1.4.0

What version of Mbed-os are you using (tag or sha) ?

6.3.0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

Mbed CLI 2

How is this defect reproduced ?

Set up 2 NRF52840 DK's: one with PowerProfilerKit, another with SX1262MB2xAS mbed shield. Connect both to PC via microUSB (not nRF USB). Have PPK DK power LoRa shield DK via External supply, switch power on LoRaDK ON, nRF ONLY switch, VEXT->nRF switch to ON. Load up nRF Connect utility for the power profiler kit application, and enable DUT power and monitoring.

Use the default example for this sketch, but remove most of the code such that all that remains looks as below:

#include <stdio.h>

#include "lorawan/LoRaWANInterface.h"
#include "lorawan/system/lorawan_data_structures.h"
#include "events/EventQueue.h"

// Application helpers
#include "SX126X_LoRaRadio.h"
SX126X_LoRaRadio radio(D11,//MOSI
                       D12,//MISO
                       D13,//SCK
                       D7,//CS/NSS
                       A0,//RESET
                       D5,//DIO1
                       D3,//BUSY
                       A1,//FREQ_SEL
                       A2,//DEV_SEL
                       A3,//XTAL_SEL
                       D8);//ANT_SW

#include "mbed.h"

//DigitalOut led1(LED1);
using namespace events;
uint8_t tx_buffer[30];
uint8_t rx_buffer[30];
#define TX_TIMER                        20000
#define MAX_NUMBER_OF_EVENTS            10
#define CONFIRMED_MSG_RETRY_COUNTER     3
#define PC_9                            0

static EventQueue ev_queue(MAX_NUMBER_OF_EVENTS *EVENTS_EVENT_SIZE);
static void lora_event_handler(lorawan_event_t event);
static lorawan_app_callbacks_t callbacks;

static LoRaWANInterface lorawan(radio);

int main()
{       
rtos::ThisThread::sleep_for(1000);
}

change the following in mbed_app.json:

"target_overrides": { "*": { "platform.stdio-convert-newlines": true, "platform.stdio-baud-rate": 115200, "platform.default-serial-baud-rate": 115200, "lora.over-the-air-activation": true, "lora.duty-cycle-on": false, "lora.phy": "US915", "lora.device-eui": "{ 0x00, 0x80, 0xA0, 0xD0, 0x09, 0xEA, 0x82, 0x37 }", "lora.application-eui": "{ 0x70, 0xB3, 0xD5, 0x7E, 0xD0, 0x03, 0xE4, 0x02 }", "lora.application-key": "{ 0xEE, 0xB6, 0x72, 0x7D, 0xEB, 0x52, 0x08, 0x1C, 0x2E, 0x32, 0xC4, 0x3B, 0xB8, 0x96, 0x86, 0x6D }", "target.components_add": ["SX126X"], "lora.app-port": 2, "lora.fsb-mask": "{0xFF00, 0x0000, 0x0000, 0x0000, 0x0002}" },

"macros": ["MBEDTLS_USER_CONFIG_FILE=\"mbedtls_lora_config.h\"", "MBED_TICKLESS=1"]

Now, compile, upload and compare the average currents when static LoRaWANInterface lorawan(radio); is commented, and uncommented. For me, results for commented are ~14uA average sleep current over 52ms period, while uncommented shows an average sleep current of approximately 6.5mA over 52ms period.

[ciarmcom]

Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers.
Internal Jira reference: https://jira.arm.com/browse/IOTOSM-3922

[evandavey]

@charlesmodrich-tc I have similar issues in #222. Did you find a solution? For tcxo control, I am exploring modifying the set_operation_mode call in the driver i.e. set to 0 when RF_OPMODE_SLEEP otherwise 1. But that still leaves a high residual ~300uA.

[charlesmodrich-tc]

Unfortunately no, I wasn't able to find a solution. Ultimately I was forced to move away from Mbed OS for this reason since I wasn't able to get the low current performance all of my devices would require.

…

-- Charles Modrich | Senior Hardware Engineer TeraCode | 405 Cochituate Road | Suite 205 | Framingham MA 01701 M: 847-951-7543 | F: 781-207-0724 http://www.teracode.com | LinkedIn <https://www.linkedin.com/in/charlesmodrich/>

On Sat, Jun 26, 2021 at 4:58 AM Evan Davey ***@***.***> wrote: @charlesmodrich-tc <https://github.com/charlesmodrich-tc> I have similar issues in #222 <#222>. Did you find a solution? For tcxo control, I am exploring modifying the set_operation_mode call in the driver i.e. set to 0 when RF_OPMODE_SLEEP otherwise 1. But that still leaves I high residual. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#227 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARXQAUS7K7DS4CDEOWWATCDTUWQDTANCNFSM435LKRXQ> .

[evandavey]

@charlesmodrich-tc - very frustrating.

[charlesmodrich-tc]

It really is! I spent a lot of time and hope on this before giving up.

[evandavey]

Yes, have been in the same boat! Having to revert back to the manufacturer SDKs is its own path of pain given all the messy #defines to support multiple targets and tight coupling of business logic to SDK logic. It's a shame support resources for MBED seem to have dropped off recently and it is stuck being half a corporate project and half an open source project with neither seeming to have particularly strong momentum.

[evandavey]

@charlesmodrich-tc - I have been doing some more debugging, this time on a Murata ISJ dev board (link). This is a STM32L072 + SX126X radio. With the Murata supplied AT firmware, I measure this board at the expected 2uA, so I know this is the baseline. I am using a new example from scratch, but using the master branch of mbed-os (as I needed to make some non power related changes to the SX126X driver).

With the code below, I am able to achieve an average of 50uA. Interestingly, if I power up the board (which puts the radio to sleep), then re-upload the code with the radio.sleep() line commented out, current falls to 11uA, which is very similar to the 14uA you measured. I think this is related to GPIO/peripheral configuration in sleep but I haven't been able to figure out why, or where I am losing 9uA relative to the AT firmware.

mbed_app.json

{
  "requires": [
    "bare-metal",
    "events",
    "storage",
    "spif-driver",
    "lora",
    "mbedtls",
    "sx1276-lora-driver",
    "SX126X-lora-driver"
  ],
  "target_overrides": {
    "*": {
      "target.macros_add": ["MBED_TICKLESS"],
      "target.lpticker_lptim": 0
    },
    "MURATA_TYPE1SJ_EVB": {
      "SX126X-lora-driver.freq-support": "MATCHING_FREQ_915",
      "SX126X-lora-driver.device-variant": "SX1262"
    }
  }
}

main.cpp

#include "mbed.h"
#include "events/EventQueue.h"
#include "radio.h"
#include "SX126X_LoRaRadio.h"

#define MAX_NUMBER_OF_EVENTS 20

static EventQueue ev_queue(MAX_NUMBER_OF_EVENTS *EVENTS_EVENT_SIZE);

SX126X_LoRaRadio radio(LORA_SPI_MOSI,
                       LORA_SPI_MISO,
                       LORA_SPI_SCLK,
                       LORA_SPI_CS,
                       LORA_RESET,
                       LORA_DIO1,
                       LORA_BUSY,
                       LORA_FREQ_SELECT,
                       LORA_DEVICE_SELECT,
                       LORA_CRYSTAL_SELECT,
                       LORA_ANT_SWITCH);

int main(void)
{

    radio.sleep();
    ev_queue.dispatch_forever();
}

[jeromecoutant]

  "target.lpticker_lptim": 0

This is not tested, not validated, so not recommended...
Keep the default configuration

[evandavey]

@jeromecoutant - this line saves about 30uA . At the moment my objective is to just get current down to 2uA with nothing running, then start adding back functionality to be able to do a full LoRaWAN test so I'll admit I've been trying things such as that line without fulling understanding the impact. The 2uA firmware is written in https://www.st.com/en/embedded-software/i-cube-lrwan.html but I find the structure such a headache to deal with.

[hallard]

That's interesting because I wanted to post a comment this night but went to bed before. In the meantime conversation has new comments.
I'm currently switching to mbed for my lorawan E5 and RAK3172 board because it's really nice simple with lot of features and this lorawan example works.
But my next step is to go to low power testing and seing this makes me feel inconfortable because the goal of LoRaWAN device is to be low lower. I'm going to 1.5uA with old murata one on custom code without mbed so 11uA or 50uA is not an option on my side.
Would be interesting to have @jeromecoutant, or @MarceloSalazar on this point, in the meantime I will give some tries on my boards.

[hallard]

The 2uA firmware is written in https://www.st.com/en/embedded-software/i-cube-lrwan.html but I find the structure such a headache to deal with.

I really don't understand how can this structure give you headache (kidding), but I'm glad I don't feel alone on this ST structure 👍

[evandavey]

@hallard - I have some E5's on order along with the https://www.seeedstudio.com/LoRa-E5-mini-STM32WLE5JC-p-4869.html. Is there a target already that works with this chip and can give low power? I don't care what chip I use at this point as long as I can get something functional - don't know if there is anyone using MBED lorawan in the real world.

As to i-cube-lrwan, honestly my adaptions are relatively minor and I could probably mod it to get it working, but 😱 the business logic would be so tightly coupled with that structure I couldn't deliver in good conscience.

[hallard]

@hallard - I have some E5's on order along with the https://www.seeedstudio.com/LoRa-E5-mini-STM32WLE5JC-p-4869.html. Is there a target already that works with this chip and can give low power?

Sure take a look there (not tested on Low Power yet )

for STM32WL i-cude-lrwan has been replaced by STM32Cube MCU Package for STM32WL series(SDK) may be it was too simple.
More information here but don't dream, file and folder architecture won't remove you any headache

[evandavey]

@hallard thanks for the links. Not Low Power tested is the concern. I've tried the Type ABZ (custom build and DISCO LRWAN1), Type 1SJ and STM32L0/RFM95 (draguino LNS50 node) so far with no luck for easy low power < 10uA (and even struggling for <100uA). I guess the trade-off for using a simplified framework like MBED is you lose that fine-grain control to library implementations. Still, it is such a common problem I'd hope there would be sufficient community support / documentation to get things running at least with a viable battery life for a low power long-term node (i.e. 1 year plus). Especially for dev boards like the DISCO LRWAN1.

[hallard]

Worth looking at this sample code https://os.mbed.com/users/kenjiArai/code/Check_DeepSleep_os6/
For sure need to be adapted for STM32 target (Murata STM32L0 in your case) but could be an excellent starting point because on some boards he got 2uA which is both our target :-)

[evandavey]

@hallard I have attempted something like the "LowPowerConfiguration" function before. Firstly, I don't think "AHBENR" exists for a L0 target (so I switched for "IOPENR"). Secondly, I think the presence of the radio messes with this code as I have experienced worse performance after calling such a function following radio.sleep (as in mA). Otherwise, I don't see anything obvious in this code that is doing anything I haven't tried before. I haven't found anything documented as to what happens to peripherals/gpio when deep sleep is called.

[evandavey]

BTW, with the exact some code and the LNS50 as a target (so swapping the SX126X driver for SX1276) I see 500uA. But I am not convinced the pin mappings for the SX1276 are correct for the RFM95 module (https://github.com/dragino/Lora/blob/master/LSN50/v2.0/LoRa%20ST%20Sensor%20Node%20v2.0.sch.pdf and https://raw.githubusercontent.com/dragino/Lora/master/LoRaST/v1.0/LoRa%20ST%20v1.0_Sch.pdf).

[hallard]

Ok done some testing on my LoRa-E5 board, after removing all code of the sample (and all GPIO config such as LED and Button) here we go

1.43uA in deep sleep mode, perfect !!

mbed_app.json

{
    "requires": ["bare-metal", "events", "lora", "mbedtls"],
    "target_overrides": {
        "*": {
            "target.printf_lib": "std"
        }
    }
}

code

//  Include --------------------------------------------------------------------
#include "mbed.h"

//  Constructor ----------------------------------------------------------------
//DigitalIn   my_sw(BUTTON1);
//DigitalOut  myled(LED1,1);
static BufferedSerial pc(CONSOLE_TX, CONSOLE_RX, 115200);

//------------------------------------------------------------------------------
//  Control Program
//------------------------------------------------------------------------------
int main()
{
    while (true) {
//        myled = 0 ; // ON
//        ThisThread::sleep_for(1s);
//        myled = 1 ; // Off
//        ThisThread::sleep_for(2s);
        hal_deepsleep();
    }
}

Please not that using ThisThread::sleep_for(2s) instead sleep at 3mA

[evandavey]

@hallard - great, sounds promising. Is this the Seeed Studio dev board or one of your own? I think with bare metal you need to use thread_sleep_for rather than ThisThread::sleep_for for the sleep manager to work (or events.dispatch_forever() like I used). What's happening with the radio? Is it defaulting to off for this board? What are the settings for PeripheralPins.c? What is the system clock configuration?

This code gives me ~1.14mA on the Type 1SJ dev board (which is most likely the radio being on).

[hallard]

@evandavey yes it's my basic own board, pin definitions are here and the radio is included into the STM32WL chip.

hal_deepsleep() may be not the best because I'm not sure we can wake up with a timer, but I'm wondering how the difference between with thread_sleep_for()

As you can see as soon as I'm using this code consumption in sleep goes from 1.5uA to 2.9mA

int main()
{
    while (true) {
          thread_sleep_for(5000);
    }
}

[evandavey]

@hallard - I might be wrong on thread_sleep_for https://forums.mbed.com/t/clarification-on-os-6-empty-vs-os-6-bare-metal-example-programs-1-0-0/8950 and it is equivalent and doesn't call the sleep manager. What do you get using events.dispatch_forever()? Maybe the radio defaults to its sleep state on the STM32WL?

[hallard]

Same thing with

int main()
{
    EventQueue queue;
    queue.dispatch_forever();
}

mbed_app.json => 2.9mA

{
    "requires": ["bare-metal", "events", "lora", "mbedtls"],
    "target_overrides": {
        "*": {
            "target.printf_lib": "std"
        }
    }
}

[evandavey]

Same code but not using bare-metal?

[hallard]

Sorry same code, same config so yes bare-metal

[evandavey]

Sorry, I meant, what do you get running the same code but not in bare-metal?

[hallard]

Murata + I have had similar issues with the Draguino which is STM32L0 + external RFM95W. And the OP who was having issues with an external board as well. But at least some real-world proof that LoRa on MBED is feasible with at least one chip.

Yeah but I’m on another project where I need murata to be to 2uA like with grumpyoldpizza framework so if team could solve this low power issue would be fine

[evandavey]

Certainly something with the init/deinit of pins, and the TCXO control, so at least we've discovered that. I wish they would separate out the MBED specific stuff from the driver stuff so that the driver logic could be kept up-to-date with the Semtech (or other) reference implementation. Kind of what they are moving to with HAL layer in https://github.com/Lora-net/sx126x_driver but looks like a lot of work to implement that with the current MBED way of doing things.

[hallard]

Yeah and lorawan stack in current implementation is 1.0.2 so behind LoRa Mac node current version 1.0.4 and 1.1.0 hope they will be able to update the stack

[hallard]

@evandavey
I've done some testing with old Murata board (STM32L0 + SX1276), deep sleep without declaring Radio instance works at 2/3uA as expected, but as soon as I declare the radio instance (even not using it) I'm not low powering

Quick investigation shows that there is no control of txco off in radio.sleep() but it's present on loramac-node implementation.

loramac-node radio sleep/standby implementation

void SX1276SetSleep( void )
{
    TimerStop( &RxTimeoutTimer );
    TimerStop( &TxTimeoutTimer );
    TimerStop( &RxTimeoutSyncWord );

    SX1276SetOpMode( RF_OPMODE_SLEEP );

    // Disable TCXO radio is in SLEEP mode
    SX1276SetBoardTcxo( false );

    SX1276.Settings.State = RF_IDLE;
}

void SX1276SetStby( void )
{
    TimerStop( &RxTimeoutTimer );
    TimerStop( &TxTimeoutTimer );
    TimerStop( &RxTimeoutSyncWord );

    SX1276SetOpMode( RF_OPMODE_STANDBY );
    SX1276.Settings.State = RF_IDLE;
}

mbed radio sleep implementation

void SX1276_LoRaRadio::sleep()
{
    // stop timers
    tx_timeout_timer.detach();

    // put module in sleep mode
    set_operation_mode(RF_OPMODE_SLEEP);
}

void SX1276_LoRaRadio::standby(void)
{
    tx_timeout_timer.detach();

    set_operation_mode(RF_OPMODE_STANDBY);
    _rf_settings.state = RF_IDLE;
}

I managed tcxo in driver like loramac-node implementation but I did not succeeded to go below 400uA. loramac-node has also de init antenna stuff here and gpio de init also but only for DIO pins and SPI CS pin here that can be interesting

If anyone has an idea of why we can't go below, we take it.

[evandavey]

@hallard - thanks, that agrees with my analysis and the key seems to be the init/deinit code which I could never get working. I've also built a board to test out the AcSIP ST50H http://www.acsip.com.tw/index.php?action=products-detail&fid1=19&fid2=&fid3=&id=151 which should hopefully function the same as the E5 module. Had some board design issues so fixing them up now for testing hopefully in a few weeks.

[hallard]

@evandavey
I tried to change the SX1272 driver (for murata) with GPIO reconfiguration on the fly
You can check changes on this branch if you want to give a try but It did not changed anything on my side, driving me crazy.

Mainly I put the GPIO to type digitalInOut so I can change them in the set_low_power_mode according same pins as grumpyoldpizza. So very little changes but does not works.

/**
 * Sets the module in low power mode by disconnecting
 * TX and RX submodules, turning off power amplifier etc.
 */
void SX1276_LoRaRadio::set_low_power_mode(bool status)
{

    if (radio_is_active != status) {
        radio_is_active = status;

        if (status == true) {

            _chip_select.input();

            if (_rf_ctrls.rf_switch_ctl1 != NC) {
                _rf_switch_ctl1.input();
            }

            if (_rf_ctrls.rf_switch_ctl2 != NC) {
                _rf_switch_ctl2.input();
            }

            if (_rf_ctrls.pwr_amp_ctl != NC) {
                _pwr_amp_ctl.input();
            }

            if (_rf_ctrls.txctl != NC) {
                _txctl.input();
            }

            if (_rf_ctrls.rxctl != NC) {
                _rxctl.input();
            }

            if (_rf_ctrls.ant_switch != NC) {
                _ant_switch.input();
            }

            if (_rf_ctrls.tcxo != NC) {
                _tcxo.input();
            }

        } else {

            _chip_select.output();
            _chip_select = 1;

            if (_rf_ctrls.pwr_amp_ctl != NC) {
                _pwr_amp_ctl.output();
                _pwr_amp_ctl = 0;
            }

            if (_rf_ctrls.rf_switch_ctl1 != NC) {
                _rf_switch_ctl1.output();
                _rf_switch_ctl1 = 0;
            }

            if (_rf_ctrls.rf_switch_ctl2 != NC) {
                _rf_switch_ctl2.output();
                _rf_switch_ctl2 = 0;
            }

            if (_rf_ctrls.txctl != NC) {
                _txctl.output();
                _txctl = 0;
            }

            if (_rf_ctrls.rxctl != NC) {
                _rxctl.output();
                _rxctl = 0;
            }

            if (_rf_ctrls.ant_switch != NC) {
                _ant_switch.output();
                _ant_switch = 0;
            }

            if (_rf_ctrls.tcxo != NC) {
                _tcxo.output();
                _tcxo = 1;
                ThisThread::sleep_for(5);
            }
        }

    }
}

[evandavey]

@hallard - have you pushed up changes in that repo? Not seeing your commits. From when I was testing, I was seeing some power impact deintiing the SPI pins but could never work out how to reinit them. I was trying calling the STM32 HAL calls rather than using MBED initially just to see if that would work. So copy/pasting the relevant init/deint sections from the STM32 Cube LoRaWAN libraries.

[hallard]

This was un unpushed commit sorry, now it's done, but I did not touched SPI pins for now, may be next step de init SPI.

[evandavey]

@hallard - I have just built up a couple of Seeed LoRa E5 based boards and have done a real-world test. Over about 620m from node to gateway (RSSI ~-125-135, SNR: -13-14.5 but urban area with no line of sight and node indoors) so that's looking promising. Sampling (UART based) sensors including using mbed trace and sending via TTN. Seeing ~50uA in sleep but it's installed in a 3rd party carrier board so could be leakage there and 50uA 'good enough for Australia' (as Dave from the EEVBlog would say). Still trying to read VBAT using the ADC but otherwise seems good. Waiting on some AcSIP ST50H chips so I can test those too using the same platform.

[hallard]

@evandavey you still want to sleep at 3uA on Murata with mbed 6? Looks like we looked at the wrong place with GPIO, I don't know how my partner found this one but looks like misconfiguration of DIO registers :-)
just try this branch fix and let me know
https://github.com/hallard/mbed-os/tree/LORA_SX1276_LP_Fix

[hallard]

@evandavey you still want to sleep at 3uA on Murata with mbed 6? Looks like we looked at the wrong place with GPIO, I don't know how my partner found this one but looks like misconfiguration of DIO registers :-)
just try this branch fix and let me know
https://github.com/hallard/mbed-os/tree/LORA_SX1276_LP_Fix

[IoTopenTech]

And success! 2uA in sleep following an uplink. It does beg the question what is different about this target versus the others - newer radio driver that handles the GPIOs?

Dear @evandavey
I'm not able to reduce power consumption below 1.5mA with a RAK3172 (STM32WLE5C), similar to E5, using mbed-os-example-lorawan

Please, could you share how to configure Mbed to get 2uA.
Kind regards

By the way, regarding reading de Vbat, I have done it using this code:

uint16_t vref_cal; double vdd_calibed; double vref_calibed; vref_cal = *(__IO uint16_t *)((uint32_t)0x1fff75aa); vref_calibed = 3.3f * (double)vref_cal / 4096.0f; AnalogIn bat(ADC_VREF); vdd_calibed = vref_calibed / bat.read();

[evandavey]

@IoTopenTech - no special configuration should be needed for the E5/STM32WLE5C using the latest mbed/drivers other than making sure you are not building a debug build. Have you tried the bare minimum code used by Charles above (using https://github.com/ARMmbed/stm32customtargets for the target)?

#227 (comment)

I had some leakage from other components (power regulator) that could also be your issue. Thanks for the VBAT code - this is very similar to what I ended up using:

uint16_t ekidna_hal_vbat_mv(void)
{

    // Read the internal voltage calibration
    float vref_cal = 3.3 * ((*((uint16_t *)VREFINT_CAL_ADDR)) / 4096.0);
    // Read the internal voltage reference
    float vref = adc_vref.read_voltage();
    // Read the raw vbat voltage
    float vbat = adc_vbat.read_voltage();
    // Adjust vbat using calibrated VREF and the protection diode voltage drop.
    vbat = (vbat * (vref_cal / vref) * 3) + VBAT_ADJUST;
    // Return adjusted vbat in milli-volts
    return vbat * 1000;
}

[evandavey]

@hallard - thanks for the Murata info. Will try this when I get a chance.

[IoTopenTech]

Thank you very much @evandavey
Problem solved.
It was probably a soldering issue.

Now I am getting 2.5uA after uplink.

[hallard]

And success! 2uA in sleep following an uplink. It does beg the question what is different about this target versus the others - newer radio driver that handles the GPIOs?

As we though initially with @evandavey it was a matter of GPIO but did not tried to reconfigure GPIO on SX1276 side, magic to do was on SX1276_LoRaRadio.cpp done by @mickael868

        /* FIXME taken from set_modem, it reduces the power consumption
         *from 300µA to 1.5µA */
        write_to_register(REG_DIOMAPPING1, 0x00); // sets DIO0-DI03 in default mode
        write_to_register(REG_DIOMAPPING2, 0x30); // bits 4-5 are turned on i.e.,

[evandavey]

@hallard - will dig up an old Murata ABZ based board to test and report back. The Type 1SJ uses a SX126X radio so exploring how to do the equivalent.

[carriegong]

Any news on this. Working on a project and seeing large sleep current for a similar board.

[evandavey]

@carriegong - which board/radio in particular?

[carriegong]

@evandavey Custom Murata ABZ. I do not tick lora_fsm from start. Until some user input... But on sleep without ticking lora_fsm it seems to draw 3.4mA oddly. Can't seem to find what. Disabled all GPIO/ all inits.. and still the same. Seems like something else in radio needs to be off.

[evandavey]

@carriegong - not sure what you mean by ticking lora_fsm? But a few things to check/try:

1. Try the @hallard build above https://github.com/hallard/mbed-os/tree/LORA_SX1276_LP_Fix
2. Ensure you are building for Release not Debug
3. Try calling

    mbed_file_handle(STDIN_FILENO)->enable_input(false);

4. Try a bare minimum example (where radio is declared, then the queue is dispatched and nothing else - see examples above).
5. Try disconnecting a debugger if you have one connected

[carriegong]

@evandavey Like this lora_fsm
I am using stm32 code. not mbedOS

[evandavey]

@carriegong - the info here is mostly mbed specific so not sure how much help it will be as results vary significantly by framework due to implementation differences (which can be very hard to compare/audit). Have you tried https://github.com/GrumpyOldPizza/ArduinoCore-stm32l0? (see #227 (comment)) or even the Loramac reference implementation https://github.com/Lora-net/LoRaMac-node?

[JenertsA]

@evandavey would you be so kind sharing full LoRa test code
I am starting out with LoRa on MbedOs and the only okay example is the official example.

Currently I am able to produce bare-bones low-power test but can't figure out the full picture.
I am particularly interested in code used for this test:

And success! 2uA in sleep following an uplink. It does beg the question what is different about this target versus the others - newer radio driver that handles the GPIOs?

[evandavey]

@JenertsA - I will try to dig out the exact code I used, but it was pretty much the example in this repo but built for an E5/STM32WLE5C (using https://github.com/ARMmbed/stm32customtargets). What is the exact target/gateway combo you are trying?

[JenertsA]

@evandavey I am using a custom RAK3172 board and RAK3172 target from previously mentioned smt32customtargets.
the end goal is to make a device that reads I2C sensors and sends data ower LoRaWAN to TTN.
For the most part, I just need to spend some time digging through the example code to understand how the all mbedOs lorawan thing works. A bit steep learning curve coming here from 8bit MCUs with simple C++ without many files and APIs around it.

[evandavey]

@JenertsA - the main example is complicated by things like the duty cycle flags and supporting multiple targets but the main thing is that the API is event driven. The LoRa callbacks are hooked in https://github.com/ARMmbed/mbed-os-example-lorawan/blob/master/main.cpp#L110 and then handled https://github.com/ARMmbed/mbed-os-example-lorawan/blob/master/main.cpp#L216.