CubeCell 1/2AA battery problem

I developed a node with a motion sensor. The MCU is woken up by the motion sensor, turn on LED and send out a short LoRa packet for 5 seconds. This program works fine when I powered it by an external 3.6V DC supply.

When I plug in a brand new 1/2AA Lithium Thionyl Chloride battery from Lunggwey 3.6V 1/2AA 1200mAh. The voltage drops to 2.5 V during the 5 seconds on time with LoRa transmission.

Is this a battery problem? Any suggestion?

I did more measurements with the CubeCell 1/2AA board. I compared the results from a DC supply, a D lithium cell and 1/2AA lithium cell. Here are the results:

(1) DC supply - set to 3.6V, 3.2V and 2.8V. The LoRa packet was delivered OK in all 3 settings. Supply voltage dropped about 0.1V from DC source during radio transmission. . Peak current was up to 60-70 mA instantaneously,

(2) D cell - The LoRa packet was delivered OK. Supply voltage dropped from 3.58V to about 3.51V during radio transmission.

(3) 1/2AA cell - The LoRa packet was lost. Supply voltage dropped from 3.5V to about 2.9V during radio transmission.

The CubeCell 1/2AA board comes with a socket for 1/2AA battery. I certainly like to use the built-in 1/2AA battery socket. Any suggestions on how to make the 1/2AA battery to work with the LoRa radio?

1 Like

I would have thought it unlikely that the radio is the problem. The radio, when transmitting, does draw much more current than the processor but these boards are designed to perform these [basic] functions on battery power. However, I am currently (no pun intended) dealing with a problem with a flow sensor that runs just fine (5V or 3.3V) when the processor is powered through the USB connector (i.e. 5V/1A) but dies when running on battery alone (even when the radio is idle).

So my question would be “Are you sure it’s the radio that’s the real cause of the voltage drop, or is it your motion sensor?”

Thank you for your input. I further verified that the problem is due to the 1/2AA Lithium battery which cannot supply sufficient transient current during LoRa radio transmission. I used a 3.7V 700 mAh Li-Ion battery to power the board. it worked fine and voltage did not drop at all, stayed at 3.7V during LoRa transmission.

I’m surprised how little attention this has got from Heltec, using SAFT 3.6v half AA batteries you see a large voltage drop on transmission as well as the two small receive windows for Lorawan - note this is HTCC-AB02A with no additional hardware or sensors attached. Screenshot is voltage not current, although they look almost identical - bottom line is if your trying to do a battery value read this becomes a problem, when running on battery (USB/power supply wont show the issue) the device performs well and measure the correct voltage but after a period (seems random, but within an hour) the device will read about 0.5v drop in voltage - spent an age looking into this, have a few smoothing caps coming tomorrow to see if this helps.

I have tried to code the battery read outside off the radio activity and current spike but everything I’ve tried has failed - the device works perfect except for this one aspect.

I don’t have this exact board but did some power analysis on the AB01 board that uses the same CubeCell version. Using a Nordic Power Profiler Kit II (PPK) I was seeing a range of 60-70 mA at the lowest LoRa power setting to over 160-170 mA at the highest power setting. Looking at the SAFT 1/2AA datasheet is says 100mA for a 100ms pulse. I don’t think the 1/2AA cell can provide enough current to meet demand.

What LoRa TX power does your code have? Maybe try to set that to the lowest level and take new voltage readings.

The large voltage sag has all the markings of lack of supply current vs demand.

Its the SAFT battery that struggles with the current draw yes, the other day I quickly tested a lipo that was poorly charged at 3.3v and there was no voltage drop at all.

The funny thing is all sensors function fine on the SAFT battery even with the voltage drop, the one issue is the battery reading - need to look at a coding solution where the lora module is not powered up when the ADC is read.