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

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:

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

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?

@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.

2 Likes

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.

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.

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.

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):

1 Like

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?

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.

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

1 Like

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

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 !