RAK3172 too much consumption in transmit EU868

It’s likely the internal matching circuitry only works with the 22dBm optimized PA settings. It would be complicated, and made even more complicated by their surprising lack of an internal schematic, but it may be possible to add additional external matching circuitry to enable the use of the 14dBm optimized PA settings. It would be great if RAK wireless could spec an external matching circuit for 14dBm optimized PA settings. The difference between 92mA and 45mA could be pretty huge for many applications, especially applications running off of batteries with high series resistance like coin cells.

Jacob,
mind crossing, you beat me, it was exactly my goal when I designed this board I made for CR2450 cell coin I was confident with 45mA peaks but 90mA, not so sure.

Hi @mintenj and @Charles ,

I have no good news to bring here but I hope the info I will share can bring some light. The 90mA is caused by having RF output available only on RFO_HP. Doing this simplifies the design of RAK3172 but with no option with RFO_LP out.

I agree with @mintenj that it can be probably done with optimum RF PA settings with the matching network but it is something we haven’t explored yet.

For everybody’s reference:

This is the optimized current consumption based on STM32WLE5CC datasheet

image

Here is the application note for tuning the RF which can make us lower the peak current of TX if optimized.

This info is useless without the RF matching network of RAK3172 so please have a look here:

I will double-check if all the values are correct. But hopefully, this can give you a glimpse of the RF front-end implementation.

I am excited to see your RAK3172 LoRa device powered by a CR2450 coilcell @Charles . Let’s make it possible :100:

1 Like

@carlrowan this is very interesting thanks.

What is fine is that according datasheet, in HP mode we could do 45mA with 14dBm with optimal settings

And looking at my consumption it’s not the case and we are on 1st case. But even is for now we can’t change board matching network on module we can try changes on firmware side. Even if we surelly have some lost due to matching I’m pretty sure we can deal with is we are able to divider per 2 the consumption.

And in the document you attached here is what is said to do on firmware side

Worth giving a try, I’ll already looked into mbed to add these boards, so I’ll try things in STM32WL_LoRaRadio.cpp around SUBGRF_SetTxParams

ok I think I got it just (quick and dirty for now) change

set_pa_config(0x04, 0x07, 0x00, 0x01);

to

set_pa_config(0x02, 0x02, 0x00, 0x01);

I need to try this tomorrow, don’t have tool to measure current here

3 Likes

@carlrowan could you check with your team what have been done on your original AT Firmware, I suspect same issue :slight_smile:

BTW just tested on my side with mbed fixed, and here we go, got 45mA

What is strange is that now got RSSI more logical compared to other devices near me, so I really suspect regarding RSSI I had before that we were transmitting over 14dBm and thus not respectincg the EU specs.

1 Like

Here the changed code for information (mbed)

void STM32WL_LoRaRadio::SUBGRF_SetTxParams(uint8_t paSelect, int8_t power, radio_ramp_time_t rampTime)
{
    uint8_t buf[2];

    if (paSelect == RFO_LP) {
        if (power == 15) {
            set_pa_config(0x06, 0x00, 0x01, 0x01);
        } else {
            set_pa_config(0x04, 0x00, 0x01, 0x01);
        }
        if (power >= 14) {
            power = 14;
        } else if (power < -17) {
            power = -17;
        }
        write_to_register(REG_OCP, 0x18);   // current max is 80 mA for the whole device
    } else { // rfo_hp
        // Better Resistance of the radio Tx to Antenna Mismatch
        // RegTxClampConfig = @address 0x08D8
        write_to_register(REG_TX_CLAMP, read_register(REG_TX_CLAMP) | (0x0F << 1));

        // We are in rfo_hp ONLY but it's not optimal settings for other than +21dBm or +22dBm
        if (board_rf_switch_config == RBI_CONF_RFO_HP) {
            // so we need to handle settings sot rfo_lp equilavent that we don't have enabled
            // See Section 5.1.2 of Application Note 
            // https://www.st.com/resource/en/application_note/an5457-rf-matching-network-design-guide-for-stm32wl-series-stmicroelectronics.pdf
            if (power > 20) {
                set_pa_config(0x04, 0x07, 0x00, 0x01);
            } else if (power > 17) {
                set_pa_config(0x03, 0x05, 0x00, 0x01);
            } else if (power > 14) {
                set_pa_config(0x02, 0x03, 0x00, 0x01);
            } else {
                set_pa_config(0x02, 0x02, 0x00, 0x01);
            }
        // In this case we have 
        } else {
            set_pa_config(0x04, 0x07, 0x00, 0x01);
        }

        if (power > 22) {
            power = 22;
        } else if (power < -9) {
            power = -9;
        }
        write_to_register(REG_OCP, 0x38);   // current max 160mA for the whole device
    }
    buf[0] = power;
    buf[1] = (uint8_t)rampTime;
    write_opmode_command(RADIO_SET_TXPARAMS, buf, 2);
}

1 Like

Thank you, we are still testing its impact on the transmit power, if OK, we will add this feature in the AT firmware.

Do you have any update regarding this issue? I noticed that the latest AT firmware version is 1.0.2, but the documentation does not include any kind of version history. As a consequence, it is quite difficult to figure out if the latest AT firmware has been changed.

I am still going to use RAK3172 in my future products, but there is a very remarkable difference between 45 and 90 mA. Of course, I could make a custom firmware, which would also remove an external microcontroller from the board, but that solution would take some time. Meanwhile, a simple fix for the AT firmware would be very helpful.

Hi @samimaisniemi ,

Optimizing the RF PA configurations to lessen the power consumption also lessen the RF power out when our team measured it. It can compromise the range reachable by the end device. We are still looking for ways to optimize it which might involve some hardware modification on the RF passive frontend.

Btw, the initial version release is V1.0.2 so there is no change log yet. We will be releasing a new FW soon with the appropriate change log doc.

I just want to confirm @Charles consumption measurements with the modificaciont in set_pa_config: 48mA max

Based on the reports from RAK engineers it would seem this would need to be compared with some measurement of the actual RF output power.

Though it’s entirely possible you’re achieving the output power you need for your application.

Available supply voltage (under load) seems to be something that should be taken into account as well - with insufficient supply, the chip won’t achieve programmed output, and it may well be that it won’t achieve the output with some settings that it could with others.

1 Like

Hi @carlrowan

Thank you for providing the partial schematic. Just a quick question: Is there a difference in schematic between the IPEX and non-IPEX versions, or is the only difference that the IPEX connector is populated?

Reason I ask is I want to prototype with some various options with SMA and the IPEX. Could I purchase the IPEX version and connect only the antenna I intend to use? Whether it be to the IPEX or to the SMA, such as the RAK3272S breakout board design?

I guess what would answer the question is: Would the RAK3272S work just as well if it was populated with the IPEX version?

I’m thinking perhaps the track leading to the SMA connector would need to be disconnected if using the IPEX connector, and the IPEX connector would degrade the performance with an antenna connected to the SMA connector.

Thanks!

Hi @Kappa ,

IPEX and non-IPEX RAK3172 have difference in schematic. A resistor that connects the RF pin (where the SMA of RAK3272S is connected) to the RF switch. Sadly, you cannot just use the IPEX variant to the RAK3272S breakout board (if that’s what you plan) without putting the tiny 0 ohm resistor.

That resistor is R1.

image

Hi everyone,

Any news on this consumption issue ?

Welcome to RAK forum @Cyp .

This has been resolved by introducing RAK3172LP-SIP.

You can get it from our store - RAK3172-SiP | STM32WL Module | LoRa-e5 Module | LoRaWAN SiP - LoRa SiP – RAKwireless Store

You can check the current consumption here - RAK3172-SiP WisDuo LPWAN SiP Datasheet | RAKwireless Documentation Center

@Charles did initial evaluations and now deploying it in their boards :+1:

1 Like

Correct,

Confirmed here you can see transmit 35mA then 2 receive windows 5s/6s after

2 Likes

Thanks for the informations.
Is it possible for you to share the results of the power measurements you made after modification of the RF PA configuration (as describe previously by @Charles) ? I would like to know if this new power would be sufficient for my application.

Thank you for the information.

Are there any plans for introducing a LP Variant for the RAK3172?
Because by using the RAK3172LP-SIP we would need to redesign the matching circuit by ourself and also recertify the output power.
Or I am wrong here?
Currently we are using the RAK3172 using the IPEX Connector.

Thank you
Martin

Welcome to RAK forum @martink ,

Thank you for the interest and sharing your feedback. Currently, there is no plan to release a RAK3172LP version. You can still use an IPEX connector with RAK3172LP-SiP but you need to have a custom board with proper antenna circuit.

1 Like

Ok thank you for the fast reply.

Then I will check if this is possible for us.
Otherwise we can always keep the RAK3172 and accept the higher currents.