Correct power supply for Boron 2G/3G without LiPo battery

[nils]

What is the correct way to power a Boron 2G/3G over the pin header from a DC input without LiPo battery?
There are two input options according to datasheet and schematics:

• VUSB Pin
• Li+ Pin

For powering over USB (or VUSB pin), the datasheet states

For powering the Boron 2G/3G version, you'll either need a USB port that is able support 2A current, or have the LiPo battery plugged in when powering over USB.
https://docs.particle.io/datasheets/cellular/boron-datasheet/#power

I found out this is only half of the truth as the PMIC limits the current input to 500mA per default on the Boron. Without setting this limit to a higher value, a 2A USB/5V supply is useless and the modem will restart caused by voltage drops in high current situations. See https://docs.particle.io/reference/device-os/firmware/boron/#setinputcurrentlimit- for adjusting the input current limit.

@rickkas7 Please have a look if the PMIC hint should be added to the datasheet as using a powerful USB supply alone won't work. Without reconfiguring the PMIC the modem (not the Boron itself) will restart occasionally (can be only once a day) depending on cellular signal conditions but work most of the time. This is very hard to debug.

• What is prefered? Powering via VBUS/5V with increased input current limit or powering via Li+/4.2V?
• What input current limit should be set? Maximum? Boron 2G/3G peak current is listed as 1800mA, so a limit of 2000mA should be enough?
• When powering via Li+, what is the best voltage? 4.2V?

Thank you!

Related posts, but not answering my questions:

Power supply to LiPo plug instead of VBUS

There are some differences between the Boron, which has the bq24195 PMIC, and the Argon and Xenon, which do not have a PMIC. For the Boron, Li+ can be used as a power input. You must never attach a LiPo battery to the JST connector and supply power to Li+ at the same time. It’s best not to supply power by other means like the USB connector or VIN when powering by Li+. If you disable charging in the PMIC, you could use USB for debugging with a normal USB cable. The maximum voltage is…

Boron can't connect to cloud

Judging by the log you don’t have the battery attached. As far as I can see the modem stops responding after AT+COPS=0 command that initiates network registration, which is an indication of insufficient power supply. Please make sure the following conditions (extract from the datasheet) are met: For powering the Boron 2G/3G version, you’ll either need a USB port that is able support 2A current, or have the LiPo battery plugged in when powering over USB. This is because the on-board u-blox m…

[avtolstoy]

I’ve replied in a different thread, but just in case posting here that the 500mA current limit when powered through VUSB pin should be resolved in 1.3.1-rc.1 with https://github.com/particle-iot/device-os/pull/1846

[nils]

If I get this right, you set the input current limit to 900mA. This is ok for charging, but not enough for powering the Boron 2G/3G without battery as the modem peak current goes up to 1800mA.

When powering the Boron exclusively through the VUSB pin, the input current limit must still be increased manually, this does not change for >=1.3.1.

In my opinion this is not a bug, there is no reason to have a higher input current limit than 900mA in standard cases. I just think you should mention the need for increasing the limit manually when powering the 2G/3G model exclusively over USB/VUSB in the power supply section of the datasheet. The datasheet just mentions the necessary current capacity of the power supply, but this is useless without knowing about this internal limit.

I’m also not sure if powering via VUSB or Li+ input is preferred for no-battery applications?

[BDub]

@nils I believe this would really only be necessary for 2G though which is 1800mA peak, 3G is 800mA peak and LTE is even less at 490mA peak. We are using the recommended bulk capacitance by u-blox at the input of the modems, which should handle these peak currents without browning out the supply. We’ll run some tests to double check if under continuous TX/RX, these on-board caps are sufficient in handling the peak currents or if they are able to deplete the bulk caps and drag the VUSB input down below the minimum input voltage set. If that happens, the PMIC will switch over to the BAT input for a backup supply. So if no battery is present the modem would receive a brief power brownout and the PMIC would then switch back to the VUSB/VIN input.

A good solution to avoid this potential issue if you don’t want to use a battery, is to supply the Li+ input with a regulated 4.2V, and disable charging with PMIC().disableCharging(); You can also add a USB connection in a data only configuration, by not connecting the VUSB pin, to avoid the possibility of back-feeding your 4.2V supply when USB is plugged in.

The reason the input current limit is set to 900mA is because there is not enough heat-sinking capability inherently on the boards that use this PMIC. I believe you can also only go up to something like 1200/1300mA as well since there is a HW limiting resistor option stuffed on the board that will ultimately cap the upper end.

[nils]

Thank you, this answers all my questions. For future projects without battery I will prefer powering via Li+ with 4.2V to avoid these issues.

Good to know the reason for the current limit too. I can say for sure that 500mA limit was not enough in my case but perhaps 900mA is enough, I didn’t test the exact limit because waiting for the modem to cause problems takes up to a day in my environment. I had no more problems after setting the limit to 3000mA.

I also didn’t check if my Boron was on a 2G or 3G network. Both are available, but the device is in a building, it probably depends on the signal quality.

[BDub]

@nils

I also didn’t check if my Boron was on a 2G or 3G network. Both are available, but the device is in a building, it probably depends on the signal quality.

You can look back through the Device Diagnostics history at the 'AT' column to figure out what rAT it was on. Maybe though in your case if it was connected it will show a 3G RAT, vs. if it was on 2G maybe it wasn't connecting at all, or just briefly.

I can say for sure that 500mA limit was not enough in my case but perhaps 900mA is enough, I didn’t test the exact limit because waiting for the modem to cause problems takes up to a day in my environment. I had no more problems after setting the limit to 3000mA.

That's good to know and we will look into the reason for this.

[nils]

@BDub

You can look back through the Device Diagnostics history at the ‘AT’ column to figure out what rAT it was on. Maybe though in your case if it was connected it will show a 3G RAT, vs. if it was on 2G maybe it wasn’t connecting at all, or just briefly.

The device.network.signal.at column has the value 4 most of the time, a small number of entries has 2. Looking at Restrict Boron 2G or 3G connections - #2 by picsil, 4 can be 2G or 3G if I understand correctly.

@BDub

That’s good to know and we will look into the reason for this.

Thank you. On a 2G/3G Boron without battery and 500mA input current limit the VSYS voltage can drop to ~3V, causing the modem to become unresponsive without influencing the nrf52840. As a consequence, the DeviceOS restarts the modem. This happens rarely, about one to ten times a day. I could reproduce this reliable by drawing a current peak on VSYS. Setting a higher input current limit solves this. I chosed 3000mA, probably a lower limit is ok though.

Look here for a detailed description (I discovered this because of a bug):

Memory leak in Gen3 network handling

As I discovered later, the reason for triggering the memory leak bug was a hardware issue. I describe it here to help people in the future having the same problem: I was powering the boron via the VUSB pin with a powerful (3A) supply (always stable 5V here, ensured with scope), but I didn’t increase the PMIC input current limit. The default is 500mA which is not enough for the Boron 2G/3Gs current peaks. More details: Correct power supply for Boron 2G/3G without LiPo battery This lead to volta…

[BDub]

@nils

The device.network.signal.at column has the value 4 most of the time, a small number of entries has 2 . Looking at Restrict Boron 2G or 3G connections - #2 by picsil, 4 can be 2G or 3G if I understand correctly.

The lookup table for this is not the same as the table that u-blox has for the modem, and it should be documented in our Docs (but does not appear to be cc: @zfields @rickkas7). The lookup is translated as follows though:

FROM=========================
//! Ublox-specific RAT
typedef enum {
    UBLOX_SARA_RAT_NONE              = -1,
    UBLOX_SARA_RAT_GSM               = 0,
    UBLOX_SARA_RAT_GSM_COMPACT       = 1,
    UBLOX_SARA_RAT_UTRAN             = 2,
    UBLOX_SARA_RAT_GSM_EDGE          = 3,
    UBLOX_SARA_RAT_UTRAN_HSDPA       = 4,
    UBLOX_SARA_RAT_UTRAN_HSUPA       = 5,
    UBLOX_SARA_RAT_UTRAN_HSDPA_HSUPA = 6,
    UBLOX_SARA_RAT_LTE               = 7,
    UBLOX_SARA_RAT_EC_GSM_IOT        = 8,
    UBLOX_SARA_RAT_E_UTRAN           = 9
} UbloxSaraCellularAccessTechnology;


TO=============
//! Access Technology
typedef enum {
    ACT_UNKNOWN     = 0,
    ACT_GSM         = 1,
    ACT_EDGE        = 2,
    ACT_UTRAN       = 3,
    ACT_CDMA        = 4,
    ACT_LTE         = 5,
    ACT_LTE_CAT_M1  = 6,
    ACT_LTE_CAT_NB1 = 7
} AcT;


WITH FUNCTION=================
AcT toCellularAccessTechnology(int rat) {
    switch (static_cast<UbloxSaraCellularAccessTechnology>(rat)) {
        case UBLOX_SARA_RAT_GSM:
        case UBLOX_SARA_RAT_GSM_COMPACT:
            return ACT_GSM;
        case UBLOX_SARA_RAT_UTRAN:
            return ACT_UTRAN;
        case UBLOX_SARA_RAT_GSM_EDGE:
            return ACT_EDGE;
        case UBLOX_SARA_RAT_UTRAN_HSDPA:
        case UBLOX_SARA_RAT_UTRAN_HSUPA:
        case UBLOX_SARA_RAT_UTRAN_HSDPA_HSUPA:
            return ACT_UTRAN;
        case UBLOX_SARA_RAT_LTE:
            return ACT_LTE;
        case UBLOX_SARA_RAT_EC_GSM_IOT:
            return ACT_LTE_CAT_M1;
        case UBLOX_SARA_RAT_E_UTRAN:
            return ACT_LTE_CAT_NB1;
        default:
            return ACT_UNKNOWN;
    }
}

What's interesting about that though is there is no ACT_CDMA (which equals 4) in that conversion function. So I'm currently at a loss as to how you are getting 4. @zfields do you know how 4 might be returned?

@nils

On a 2G/3G Boron without battery and 500mA input current limit the VSYS voltage can drop to ~3V, causing the modem to become unresponsive

Yes that does sound exactly like the cause. When the PMIC detects an under voltage condition on VIN, it will switch to the BAT input for backup power.

[zfields]

I don’t know off the top of my head, I’ll need to investigate and get back to the thread.

[zfields]

I haven’t forgotten you. I was sick as a dog yesterday, and my cursory investigation didn’t bare any fruit.

[lpnaunau]

@BDub

A good solution to avoid this potential issue if you don’t want to use a battery, is to supply the Li+ input with a regulated 4.2V, and disable charging with PMIC().disableCharging(); You can also add a USB connection in a data only configuration, by not connecting the VUSB pin, to avoid the possibility of back-feeding your 4.2V supply when USB is plugged in.

Hi !

I'm digging up this conversation, I'm currently developing a custom PCB and I'll power it via 24v. I'm already using a DC/DC converter to have a 5V output (https://www.tracopower.com/model/ten-20-2411win) but how would you manage to get the 4.2V on Li+ ? Via a LDO regulator ? Diode ?

Thanks !