Deep Sleep not very deep

[GitBeagle]

I have a test setup with a ThingPulse gateway and a single firebeetle ESP32 node with a BPM280 sensor. FDRS made the setup super easy. Everything worked first time. So far so good. Then I powered the node through a Nordic Power Profiler 2 to record the node power consumption compared to my WiFi deep sleep sketch. The actual ESP-NOW data transmission time is less than 500ms vs an average of nearly 3 seconds for the WiFi sketch. However, my WiFi version power consumption in deep sleep is only about 12-15uA. The FDRS node averages about 600uA. There is a ~3mA peak every ~65ms then a segment ~900uA and an another ~450uA resulting in the ~600uA average(see the attached picture). This negates most of the power saving benefit of the short ESP-NOW data transmission. I am interested in ESP-Now, in part, to extend the life of battery powered sensor nodes. Is there some modification I can make to the FDRS node code to reduce the deep sleep power consumption?

The code structure of the FDRS is way beyond my skill level. I have found a pingFDRSEspNow function which is suspect is the source of the 65ms cycle, but that is just a guess.

John

[timmbogner]

Hi John,
This is interesting. Once the ESP goes to into deep sleep, FDRS is shut off completely. As long as DEEP_SLEEP is enabled, the device follows the following logic to go to sleep:

#ifdef ESP32
  esp_sleep_enable_timer_wakeup(sleep_time * 1000000ULL);
  esp_deep_sleep_start();
#endif
#ifdef ESP8266
  ESP.deepSleep(sleep_time * 1000000);
#endif

It will help to see the WiFi sketch code that you're comparing it to. My initial guess is that you're using a sketch that also shuts down your BMP280 sensor before deep sleeping. FDRS can do this too with POWER_CTRL. (EDIT it actually doesn't exactly do that at the moment, now that I look. I'll look at the sketch and see if that's it.) Maybe to confirm this you can read the power consumption of just the BMP280 and see if it matches the spikes you see during deep sleep.

[timmbogner]

Don't worry, my own formal training ended after I learned BASIC in 3rd grade :o)

Is your sensor connected to a GPIO or to the main battery power? In FDRS you can define a pin in config that will stay unpowered until the system starts, thus only powering your sensor when needed.

[GitBeagle]

I'll try the POWER_CTRL pin. I think the ESP32 pin current rating is enough for the BMP280 but I will verify.
My approach was to modify the BMP280_fdrs sketch using the Adafruit bmp280_forced example. It contains blocking code which may be a no no but I tried it anyway. The results were better than expected. The power consumption of the Firebeetle plus the BMP280 was around 15uA while in deep sleep. The on time was ~75ms longer resulting in an average of ~480uA for a complete 1 minute cycle. The should allow about 80 days of 1 minute cycles from an 1100mAhr LiPo battery assuming a 5%/month self discharge rate. What is the downside of the blocking code in this example?
FirebeetleTest3.ino.txt

On time

Complete 1 minute cycle

[timmbogner]

Alight, so as a disclaimer, this is a first guess, without really researching the BMP280's inner workings.

I believe that the current consumption you are seeing is the sensor operating in its normal continuous mode, where it is constantly cycling and loading up readings. My guess is that the "forced" mode is forcing the sensor to stop operating in continuous mode and only read when forced to. This explains why you don't see the current anymore. This might be a reasonable way to reduce power consumption even further, but I don't know if there are any drawbacks to forced mode. I think that you will see similar success by shutting off the sensor completely, which is what POWER_CTRL does. Again, I don't really know what I'm talking about, just a quick guess. I may have to invest in one of those Nordic gizmos soon.

[GitBeagle]

Using the original BMP280_fdrs sketch and a POWER_CTRL pin was even better. The deep sleep current was still about 15uA most of the minute but the average was down to ~380uA for a complete 1 minute cycle. The on time was ~270ms or about 25ms shorter than the blocking code. That pushes the SWAG estimate to just over 100 days from an 1100mAhr LiPo battery. Trying different BMP standby times had no noticeable impact. Larger batteries may extend the life but the self discharge starts to become a major component. The DFR1075 ESP32 board integrates a solar MPPT charging circuit which looks like a great alternative for battery powered sensors and it is cheap too. Not too helpful for inside nodes:) My next Mouser order will include a couple.

Thanks again for a great EspNow infrastructure. I'm beginning to understand how it structured.

John

[timmbogner]

That's definitely a nice inexpensive board for the price. I've got one of these ePulse C6 boards from ThingPulse on the way. Andreas Spiess has a good video about a DIY solution to solar charging which I'll be using for a project later this year.

[aviateur17]

@GitBeagle, if you have not already, you may want to look at Kevin Darrah's tips for reducing every little ounce of power from microprocessors:
https://www.youtube.com/watch?v=urLSDi7SD8M&ab_channel=KevinDarrah

If not mentioned in this video he also mentions in a similar video about commanding all the GPIO to a specific state instead of letting them float.

[GitBeagle]

My go to reference for Arduino low power in Nick Gammon https://www.gammon.com.au/power.

I have a mailbox notifier that uses a ATtiny85 to shut off the power to an Esp8266. It runs for >1 year on a LiFePo4 14500 cell. Supposedly, the ATtiny only draws ~500nA per his measurement. I did not have the ability to measure low current when I made that device so I cannot confirm that measurement. I will watch the video to see if there are any additional tricks.

Thanks

[GitBeagle]

For anyone interested, I have been running a test using a DFR0654 ESP32 board running the ESPNOW_Sensor sketch for 50 days, The only modifications I made to the sketch was to add reporting of the battery voltage. It wakes up every minute and sends the data to NodeRed which logs the voltage to a text file. I'm using an unprotected 380MaHr battery from an old mini quadcopter. It is the smallest battery I have. The battery was fully charged at the start and measured about 4.2V with a DVM. The sketch reported between 4.014 and 4.106 in the first few minutes. I suspect part or all of the difference is the sketch measures the voltage under load. After 50 days the DVM measures 3.807V and the sketch reports 3.424V. This exceeds the predicted duration from a 380mAHr battery. I plan to end the test when the sketch consistently reports a voltage at or below 3.2V. I will report the results here.

Powering a real sensor will likely require higher current and longer on time. Still, with a protected 1200MaHr battery half a year is a reasonable expectation.

[GitBeagle]

Well, I sort of forgot to follow this test until today. The last reading before the battery died was 98.5 days (141911readings/min/1440min/day). The last battery reading was 2646mV. The meter reading a couple days later was essentially zero. The first reading below 3200mV occurred after 92 days. So there was very little useful life after that point. The transition from 3300 to 3200Mv range occurred after about 88 days.

[timmbogner]

Hey I'm back... Thanks for the test and update! I'm very happy it went so well! I have a history of setting up tests like this, but then losing interest or forgetting after the battery takes longer than I anticipate to drain.

Sooner or later I'll get one the Nordic power profilers and we'll see just how tiny the current really is.

[GitBeagle]

The "answer" to the original question really involved powering the sensor from an ESP32 pin. The rest of the discussion involves optimization and testing. Hopefully, someone will find this useful. In any case I enjoyed the discovery process. The results of the battery duration test far exceeded my expectations. Using reasonable battery cutoff voltage still allows practical battery powered nodes.