jgromes / RadioLib

Universal wireless communication library for embedded devices
https://jgromes.github.io/RadioLib/
MIT License
1.55k stars 387 forks source link

Too much current consumption on STM32WLx modules without LP support #852

Closed primus192 closed 12 months ago

primus192 commented 1 year ago

IMPORTANT: Check the wiki Before submitting new issue, please check the Wiki and the API documentation. You might find a solution to your issue there.

Describe the bug As we know some modules do not include LP support. We are only able to use HP mode in rf switch tables so only hp_supported is available. This applies for example for Lora E5 or RAK3172 module.

When we look on stm32 dbm to power specification on 868MHz we can see that for example when setting 14dBm power we should be able to get 45mA power consumption despite having only HP mode but when using optimal settings which current version of RadioLib library does not take into account.

For hp the table looks like:

static const uint32_t rfswitch_pins[] = {PA4, PA5, RADIOLIB_NC};
static const Module::RfSwitchMode_t rfswitch_table[] = {
  {STM32WLx::MODE_IDLE,  {LOW,  LOW}},
  {STM32WLx::MODE_RX,    {HIGH, LOW}},
  {STM32WLx::MODE_TX_HP, {LOW,  HIGH}},
  END_OF_MODE_TABLE,
};

We should use optimal settings when power is in bounds of -9 to 20 and use already used mode for power > 20dBm

setPaConfig(0x04, 0x00, 0x07); 

image image

The problem was described here:

https://forum.rakwireless.com/t/rak3172-too-much-consumption-in-transmit-eu868/4781/8

or here:

https://forum.seeedstudio.com/t/lora-e5-fw-bug-tx-eu868-85ma-too-high-consumption/260126

i managed to modify the library to check if it fixes the power consumption and indeed it works.

} else if(hp_supported && !lp_supported) {
    // only HP supported
    RADIOLIB_CHECK_RANGE(power, -9, 22, RADIOLIB_ERR_INVALID_OUTPUT_POWER);
    if (power > 20) {
        state = SX126x::setPaConfig(0x04, 0x00, 0x07);
    } else if (power > 17) {
        state = SX126x::setPaConfig(0x03, 0x00, 0x05);
    } else if (power > 14) {
        state = SX126x::setPaConfig(0x02, 0x00, 0x03);
    } else {
        state = SX126x::setPaConfig(0x02, 0x00, 0x02);
    }
    this->txMode = MODE_TX_HP;
    use_hp = true;

  } else {
    // neither PA is supported
    return(RADIOLIB_ERR_INVALID_OUTPUT_POWER);

  }

To Reproduce Set 14dBm power for board that support only HP. Measure power consumption. It should be ~45mA but it is ~90mA

Expected behavior Power consumption should match optimal settings table

Screenshots If applicable, add screenshots to help explain your problem.

14dBm when using setPaConfig(0x04, 0x00, 0x07); (as it is now in the setOutputPower();)

image

14dBm when using above modification (optimal settings):

image

Additional info (please complete):

primus192 commented 1 year ago

Just a quick add on note here: The optimized settings should be used when your module has an rf matching circuit for exact output power specified in software. So maybe it will be ok if we implement two modes (optimized and not optimized) for different scenarios and we could choose it in the library? So when your board is not optimized we will choose setPaConfig(0x04, 0x00, 0x07); and when optimized we will use settings for exact power

jgromes commented 1 year ago

Thanks for pointing this out, this is very interesting. Overall, I really dislike how the PA configuration in SX126x works, essentially having to rely on some magic numbers ...

Can you verify that with the fix, the module still transmits +14 dBm?

primus192 commented 1 year ago

Hello. The module which i use (Lora E5 from seedstudio) is a ready to use module, so they have decided to do hardware RF matching for 22dB.

Using optimized values set in setPaConfig for this module certainly reduces power consumption by half but the transmitting power is getting worse as it is internally matched for 22dB (it is not halving like current so there is a slight advantage and it is getting worse the lower we go with the power from 22dB).

The real advantage of using this optimized settings is for the bare chip when designing your own board so for example you design matching circuit for 14dBm and with the use of optimized settings you can halve your current consumption without loss of tx power.

Maybe good idea will be to create flag or function to choose between optimized settings for boards that are optimized for certain dBm and between unoptimized settings (22dBm setting (setPaConfig(0x04, 0x00, 0x07);). The user could choose what suits best for his board/current/range needs.

If You think it is not so important or it is niche setting, we can live without it and close this issue just letting people know that this is interesting topic.

jgromes commented 1 year ago

Hmm, I see - in that case, I would rather err on the side of caution. RadioLib has no idea what your matching network looks like, and as you said, it can be optimized differently for different boards. I don't think it's a good idea to introduce a setting optimized for just a single specific board.

What I can do however, is to make the SX126x::setPaConfig method public. That way, the user can configure whatever PA settings they need for their specific board. So after begin or setOutputPower, you would have to reconfigure the PA for your specific board by calling setPaConfig. Is that acceptable?

primus192 commented 1 year ago

Sure. Great idea with letting us set Pa config :)

pt., 20 paź 2023, 18:53 użytkownik Jan Gromeš @.***> napisał:

Hmm, I see - in that case, I would rather err on the side of caution. RadioLib has no idea what your matching network looks like, and as you said, it can be optimized differently for different boards. I don't think it's a good idea to introduce a setting optimized for just a single specific board.

What I can do however, is to make the SX126x::setPaConfig method public. That way, the user can configure whatever PA settings they need for their specific board. So after begin or setOutputPower, you would have to reconfigure the PA for your specific board by calling setPaConfig. Is that acceptable?

— Reply to this email directly, view it on GitHub https://github.com/jgromes/RadioLib/issues/852#issuecomment-1773074822, or unsubscribe https://github.com/notifications/unsubscribe-auth/AVLNJLHRMQCVGFLCC77E46LYAKUAJAVCNFSM6AAAAAA6IX42VGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZTGA3TIOBSGI . You are receiving this because you authored the thread.Message ID: @.***>

jgromes commented 1 year ago

Implemented in the latest commit.