I have created a printed circuit board using the Particle AB1805 rtc example and a Particle BORON.running OS 5.7
The board works as expected, with the exception of sleep current consumption. The lowest average sleep current I have achieved is 2.5 mA.
The current average is measured using a Nordic Power Profiler. The Profiler samples for six hours, and the Boron wakes up once an hour or if a gpio pin selected changes state. The average/hr includes the current consumed during the very short publish.
I have read all I can find in Particle documents concerning sleep modes and current consumption. I get more confused the more I read.
My customer's requirement is five years operation using 3 4200 mAh 18650 batteries.
Does anyone have an code example or suggestion to help reduce the current?
Battery Capacity(A hr) / current consumption (A) = runtime. (hr)
That is the reason for my question. There has been talk about this situation for several years on the forum.
I could go to LORA and a simple AT328 and a Particle Boron hub. I would like to stick with the single Boron reporting each sensor, if any progress has been made on the sleep current.
This code is basically a copy of code written by Rick at Particle. The code was written to run with the AB1805 rtc board.
My level sensor's voltage is turned off during sleep by a fet. The sensor draws a few mA for 6 seconds per hour.
.My addition to the code is the readSensorAndPublish() function..
The 2.5 mA sleep current and three 4200 mAh 18650 give 7 months runtime. To get 5 years, I calculate it would require 0.25 mA sleep current. This sleep current is possible with other designs, but I like my Particle.
Thanks!!
Here is the code in the loop function.
void loop()
{
ab1805.loop();
if (doSleep)
{
ab1805.stopWDT();
Log.info("going to sleep");
delay(100);
SystemSleepConfiguration config;
config.mode(SystemSleepMode::STOP)
.gpio(D8, FALLING)
.gpio(WKP, RISING)
.duration(60min);
System.sleep(config);
System.reset();
}
if (Particle.connected())
{
if (!cloudConnected)
{
cloudConnected = true;
uint32_t elapsed = (uint32_t)(System.millis() - cloudConnectStarted);
Log.info("cloud connected in %lu ms", elapsed);
}
if (doPublish)
{
doPublish = false;
doSleep = true;
ab1805.put(counterRamAddr, counterData);
readSensorAndPublish(); //My function to read sensor data.
}
if (doWaitForTime && ab1805.isRTCSet())
{
doWaitForTime = false;
doSleep = true;
}
}
else
{
if (cloudConnected)
{
cloudConnected = false;
cloudConnectStarted = System.millis();
Log.info("lost cloud connection");
}
uint32_t elapsed = (uint32_t)(System.millis() - cloudConnectStarted);
if (elapsed > connectMaxTime.count())
{
Log.info("failed to connect to cloud, doing deep reset");
delay(100);
ab1805.deepPowerDown();
}
}
measure the boron power consumption alone, outside the board you produced.
I read that if there is leakage current going in to the boron, it does not fully let it sleep, which correlates to your observation.
So what if you measure it standalone and rule out the boron (or your code) vs the board?
While it does not fix the issue, it narrows down a bit the culprits.
Thanks for your interest! I will do that tomorrow.
I am going to see how the TI TPL5111 will work out switching the entire supply voltage on long enough each hour to transmit the data. The cell connection complications is my big mystery.
250 µA (0.25 mA) sleep current is definitely possible. In ULP sleep it should be around 128 µA with RTC wake. If you're getting 2.5 mA either you're leaking current somewhere else on your board, or the device didn't really go into sleep successfully.
The best way to debug sleep issues is to use Serial1 debugging (TX pin) and a 3.3V serial to USB adapter (FT232). The reason is that on wake in particular, it takes a number of seconds for USB to reconnect and you'll lose a lot of messages before that.
Also be careful with how you measure. If you are using an inexpensive DMM you may find it difficult to impossible to measure properly, because if you use the high range, you can't see the proper sleep current, and in low range it will provide insufficient power for the MCU to fully wake, which also prevents it from going into sleep mode properly.