AB02 Low Power Mode consumption 45uA

[Xnet111]

Hi

I have a simple application with an AB02 powering an ultrasonic sensor and periodically sending a LoRa message to a receiver, then going to sleep. Runs on a 3.7V Li-Ion battery connected to the battery connector. The code also checks the battery voltage and when its at a low threshhold sends a final LoRa message and goes into an indefinite deep sleep. In deep sleep mode it is drawing about 45uA which seems higher than it should be. I’m turning off the radio, and VExt in the code so I can’t see why the consumption should be this high. I’m measuring the consumption with the device on battery only - no USB connected etc.

I’d be most grateful if anyone can suggest what I’m doing wrong. A segment of code is below to show where I’m sending the LoRa message and then going to sleep:

…
Radio.Send((uint8_t *)txPacket, BUFFER_SIZE); // Send mail flag + battery voltage + distance
delay(500); // Delay to allow time for radio send to complete
Radio.Sleep(); // Turn off radio
digitalWrite(Vext_PIN, HIGH); // Turn off Vext
if (status == 4) { //battery voltage less than 3401mV
Serial.println(“Going into Low Power mode indefinitely”);
delay(500); // allow time for println to complete
lowPowerHandler();
} else {
Serial.println(“Going to sleep for 10 seconds\n”);
delay(200); // allow time for printf to complete
lowPowerSleep(60000); // Low power sleep for 60 sec
}

[d00m178]

I have the same situation - AB02 + LiPo battery via JST connector, and power consumption about 6mA in sleep mode. Im also turn off radio and Vext…
btw - why this code:

digitalWrite(Vext, HIGH);

turns pin Vext off? Should not it set to LOW state for this?

anyway - in sleep mode I can measure about 2.2V on Vext pin…

also - I dont understand - in this example

HelTecAutomation/CubeCell-Arduino/blob/master/libraries/Basics/examples/LowPower/LowPower_WakeUpByTimer/LowPower_WakeUpByTimer.ino

what lowPowerHandler() do when it runs?

[d00m178]

ok I’ve checked the

HelTecAutomation/CubeCell-Arduino/blob/master/libraries/Basics/examples/Factory_Test/Factory_Test_AB02/Factory_Test_AB02.ino

and changed my onSleep():

void onSleep()
{
  //Serial.printf("Going into lowpower mode, %d ms later wake up.\r\n",timetillwakeup);
  //lowpower = 1;
  //timetillwakeup ms later wake up;
  digitalWrite(Vext, HIGH);    // Turn off the external power before sleeping
                Radio.Sleep( );
                display.stop();
                //detachInterrupt(RADIO_DIO_1);
                turnOffRGB();
                pinMode(Vext,ANALOG);
                pinMode(ADC,ANALOG);
  //curr = millis();
  TimerSetValue( &wakeUp, timetillwakeup );
  TimerStart( &wakeUp );
}

now power consumption is 14uA which is better, but how to get 3.5uA?

[Xnet111]

Thanks for this info - I’ll add those other lines from the factory test sketch into my code and see if my sleep current drops.
The snip below from the Heltec doc says that when powered by the battery connector, sleep current is 11uA which is pretty close to what you have measured. I believe this is because when using battery mode the LDO chip and the battery chip need to operate on the board, so you will only get 3.5uA when powered by VDD (3.3V).

[UniquePete]

btw - why this code:

digitalWrite(Vext, HIGH);

turns pin Vext off? Should not it set to LOW state for this?

Vext, in this context (it should really be labelled Vext_Ctrl), is not the power supply pin, it is a pin that controls a MOSFET switch that in turn controls the power on the Vext pin. Setting this pin HIGH turns the MOSFET switch OFF, setting it LOW turns it ON.

But note that Heltec has not been consistent with the way that ‘Vext’ is used:

Heltec wireless tracker v1.1 no response

Your insistence that setting ‘Vext’ HIGH enabled Vext really troubled me but now, having access to the schematic diagram, I can see that the Wireless Tracker is different to other Heltec boards. In this case, Vext is not controlled by a MOSFET, which is switched on by setting ‘Vext’ LOW, but rather now appears to be directly connected to its own regulator, which is indeed enabled by setting ‘Vext’ HIGH—a bit of a trap for old players there… Perhaps it should then also be no surprise if the OLED…

[d00m178]

But note that Heltec has not been consistent with the way that ‘Vext’ is used:

Heltec wireless tracker v1.1 no response LoRa Node

thank you, good to know - Im also have WiFi LoRa 32 (V3) and it based on ESP32 so I suppose that it also will work opposite way - for disable - set Vext to LOW

anyway - 14uA != 11uA… still checking where this 3uA are used

[UniquePete]

No, the Wifi Lora 32 modules all use a MOSFET switch to (de)activate Vext. So far, it seems that the Wireless Tracker is the odd one out, but this may indicate a new direction that Heltec is taking…

[Xnet111]

Hi d00m178 (and Pete)

I tried putting the extra lines in my own sketch (turnOffRGB(); pinMode(Vext,ANALOG); pinMode(ADC,ANALOG); etc but it had no effect on the sleep current. I then loaded up the factory test sketch that you pointed me at and got the same result (actually its now showing about 68uA in sleep mode). As you are getting largely the result that you’d expect (give or take a few uA), I’m starting to get a bit suspicious of my multimeter, which is by no means an expensive model. I did wonder about burden voltage but that would cause a lower, rather than higher reading, I would have thought. My battery is a 14500 (3.7v) and its voltage is now about 3.6v which is higher than when I first tried to measure the sleep current (at which time it was about 3.45v) when I was reading about 45uA or so. I’ve never attempted to read currents in the uA range before so not really sure what the issues might be but it seems strange that we should get such different results on the same board.

[UniquePete]

I’m certainly no authority on the subject, but measuring currents in the µA range can be a non-trivial exercise. The two options I considered were the µCurrent [GOLD] Multimeter Adapter (not sure if these are currently available, no pun intended) and, what I ultimately used, the Nordic Semiconductor PPK2.

[Xnet111]

Thanks Pete. I did ponder on getting a PPK2 but wasn’t sure if it was specialied for Nordic kit or if it was a gen purpose gadget.

[UniquePete]

Just FYI, the following is the PPK2 trace from an AB02 configured with DS18B20 temperature and AJ-SR04M ultrasonic sensors. The processor, which is powered (14500 Li-Ion) through the battery JST connector, reads the battery voltage (currently showing 4.14V), temperature and ultrasonic sensors, transmits each reading in an individual LoRa packet, then calls the lowPowerHandler to sleep for 60 sec.

As the image suggests, the maximum measured current draw is just under 60mA and the sleep current, although not obvious, is around 2.4µA which is even lower than the datasheet suggests. Now, maybe I’m doing something wrong, and these readings do not reflect the real situation, but the relative values would likely be correct regardless. Given that I’ve never measured, by any means, a Node consuming more than about 150mA during a LoRa transmission, if these measurements were out by a factor of 2.5, that’d still be a sleep current of ~6µA.

Whatever the case, some of my nodes have been running for over 12 months now, in similar configurations, admittedly supported by a 50mA solar panel, with no loss of battery charge.

[Xnet111]

That answers my question on the PPK2. Looks excellent - I’ll investigate getting one. Thanks again Pete

[d00m178]

which is powered (14500 Li-Ion) through the battery JST connector,

by a 50mA solar panel,

would you please share the info about these components? where and which exactly to buy?

[UniquePete]

900 mAh 14500 Battery: https://www.aliexpress.com/item/32906830176.html
60 x 44 5V 50mA Solar Panel: https://www.aliexpress.com/item/1005004689060279.html

(That’s a 70mA solar panel in the photo, but 50mA panels achieve the same result in my environment—they keep the battery fully charged)