ESP32-C3-MINI-1 Project (Deep sleep, BLE, Wifi)

Hey guys! I am working on a project wherein I have to use wifi and ble capabilities of the ESP32-C3-MINI-1 on small coin cell batteries. Since I want the project to be able to have a lifespan of approximately a year and a half, I decided it would be best to put the ESP in deep sleep (external wake-up caused by a push button) since the wifi and ble only need to be activated upon a specific interaction.

Essentially, I want the MCU to wake up when the button is pressed and have the MCU illuminate a tri-color led (blue for initial pairing of the device, green and red as status indicators once activated for use). My plan was to use a B3F-1110 switch and use state detection code to allow it to be a toggle switch. However, I am having quite a bit of trouble with even getting the ESP to wake up by the external interrupt (that being the button).

I am not sure whether my schematic (KiCAD schematic and Wokwi simulator) is wrong or whether the code I have used to test it (via online simulator: Wokwi ) is wrong. I would appreciate any and all input, thanks!
(Also, my project will use a esp32-c3-mini-1, but the wokwi simulator uses a different esp)


/*
Deep Sleep with External Wake Up
=====================================
This code displays how to use deep sleep with
an external trigger as a wake up source and how
to store data in RTC memory to use it over reboots

This code is under Public Domain License.

Hardware Connections
======================
Push Button to GPIO 33 pulled down with a 10K Ohm
resistor

NOTE:
======
Only RTC IO can be used as a source for external wake
source. They are pins: 0,2,4,12-15,25-27,32-39.

Author:
Pranav Cherukupalli <cherukupallip@gmail.com>
*/

#define BUTTON_PIN_BITMASK 0x200000000 // 2^33 in hex

RTC_DATA_ATTR int bootCount = 0;

/*
Method to print the reason by which ESP32
has been awaken from sleep
*/
void print_wakeup_reason(){
  esp_sleep_wakeup_cause_t wakeup_reason;

  wakeup_reason = esp_sleep_get_wakeup_cause();

  switch(wakeup_reason)
  {
    case ESP_SLEEP_WAKEUP_EXT0 : Serial.println("Wakeup caused by external signal using RTC_IO"); break;
    case ESP_SLEEP_WAKEUP_EXT1 : Serial.println("Wakeup caused by external signal using RTC_CNTL"); break;
    case ESP_SLEEP_WAKEUP_TIMER : Serial.println("Wakeup caused by timer"); break;
    case ESP_SLEEP_WAKEUP_TOUCHPAD : Serial.println("Wakeup caused by touchpad"); break;
    case ESP_SLEEP_WAKEUP_ULP : Serial.println("Wakeup caused by ULP program"); break;
    default : Serial.printf("Wakeup was not caused by deep sleep: %d\n",wakeup_reason); break;
  }
}

void setup(){
  Serial.begin(115200);
  delay(1000); //Take some time to open up the Serial Monitor

  //Increment boot number and print it every reboot
  ++bootCount;
  Serial.println("Boot number: " + String(bootCount));

  //Print the wakeup reason for ESP32
  print_wakeup_reason();

  /*
  First we configure the wake up source
  We set our ESP32 to wake up for an external trigger.
  There are two types for ESP32, ext0 and ext1 .
  ext0 uses RTC_IO to wakeup thus requires RTC peripherals
  to be on while ext1 uses RTC Controller so doesnt need
  peripherals to be powered on.
  Note that using internal pullups/pulldowns also requires
  RTC peripherals to be turned on.
  */
  esp_sleep_enable_ext0_wakeup(GPIO_NUM_33,1); //1 = High, 0 = Low

  //If you were to use ext1, you would use it like
  //esp_sleep_enable_ext1_wakeup(BUTTON_PIN_BITMASK,ESP_EXT1_WAKEUP_ANY_HIGH);

  //Go to sleep now
  Serial.println("Going to sleep now");
  delay(1000);
  esp_deep_sleep_start();
  Serial.println("This will never be printed");
}

void loop(){
  //This is not going to be called
}

Coin cells will hardly deliver the current needed.

1 Like

thats why my schematic has 2 of them in series for nominal voltage ratings and 1 in parallel for an increased current capacity, unless you are talking about the discharge rate being too low, which in that case, what do you think I should do? I am unable to store larger batteries (is there another mcu with wifi and ble and deep sleep available)

The battory arrangement makes no sense. 2x 3 volt in paralell with 1x 3 volt will bias that cell for reverse current and ruin it.
No GND connected to the cells. In the middle down in the pic?
Wifi and BT transmitters consume current, more current then specified for the cells I think. Check the datasheets!

the cells are 1.55V each so two in series for 3.1 V (optimal voltage is 3.3 but will still operate) and 1 in series for a total of 3.1V and 150mAh capacity. The current consumption when using ble or wifi is huge (280mA or so, however I only need to device to survive for approximately 5 mins, then it can "die" and be disposed of (as it is a single use device) which is why the device will remain under deep sleep majority of its lifespan until a user created event (the button being released). I did the math as well, 150 mAh = 150,000uA at a 10uA draw during deep sleep (allows 20 months) or 150mA at a 280 draw (approximately 30 mins of battery)

I also see your point about the reverse current, I am not too sure on why that arises nor how to really fix it (as this is somewhat new to me). From what I understand, I need to add a GND to my schematic down where the 2 batteries are separated by the third parallel battery, is there any other tips you could give me?

What does the spec say about max current delivery? If it doesn't deliver 280 ( looks too small during transmitting) nothing will work.
That one cell doesn't make sense. Remove it.
Drop the resistors.

the spec states 350mA for transmitting at peak performance which is good for 25 minutes of activity (since we are only sending small data - just the states of a device such as ready to use or used - I believe it should work as once it communicates with the app, the device can turn off and the app can function based on the state of the device).

Which cell are you referring to? And by drop the resistors do you mean to take them out of the schematic completely?

Is that the transmitter requirement? I thought about the button cell specifikation.

apologies, that is the transmitter requirement. The button cell delivers at 100uA

100 ua? That sounds too low. Can You post the link to the datasheet?
I recall a 4 cell LED pocket lamp that uses button cells, and LEDs need more then 100 ua. Something is wrong here.
My first replies had the thoughts of the 3 volt litium cells. That was my mistake. Button cells? I need to freshen up their ranges.

Yes of course,
The cells I am using are not lithium - they are silver oxide. The datasheet is below:

This is the link of the LED I will be using:

Thanks. The capacity is 75 mAh. Connecting them in serie doesn't give You more then 75....

Look at the capacity curves for 50 mA discharge. You need almost 8 times that. The battery will go flat in shorter time then a minute.
You have to change that design.

If a human is supposed to go and push a button let that person bring and connect an adequate battery.
Why have something deep sleeping, doing nothing for a long time, and then react to a button pressed?

I get where you care coming from, that is why I had a 3rd battery in parallel with the 2 in series so that we could increase the voltage to 3.1V and the amps to 150mA.

The reason why we do not care much about the device being asleep is because the device only gets used once - that too the usage time is at maximum 5 minutes. After that usability time has ceased, the device is essentially used and cannot be used again thus should be thrown away.

Additionally, there is no human interaction with the button (as it is internal in the device) and so the only way that the button is pressed is when the user decides to take the safety cap off of the device. Removing the safety cap unloads a spring in which the button will be released (from an initially pressed state) thus allowing the device to be awoken.

Once awoken, it sends the current state of the device to the app and after that, the use of the electronics is done. After the device states get passed to the app, the app will allow the user to have options on what he/she/they want to do next (which is what the wifi capability is being used for so that we can use the cloud to send notifications on next steps which can only happen once the app knows that the device has already been used)

Additionally, the real estate inside the device is very very small, only about 15 x 20 mm max. This is why we opted to use the coin cell batteries as we could include multiple of them into the design while not giving up too much real estate. Having a human bring and connect their own battery would defeat the purpose of a single use device as the goal is to make the user go through the simplest (least amount of steps) direction possible.

I am trying to get these components to work together before I give up and try components with a more reasonable power draw (because I have worked with a esp in the past so it is more familiar too me). But I am curious, if this is not possible, what you would do and the components you would recommend given the idea behind this project.

I do hope that my analysis of the power draw is correct and it could last the anticipated time that I would need it to. If the analysis is correct and is feasible, I would appreciate your help in debugging the schematic/code that I have provided pictures of.

Thanks for your help, I do appreciate your time in trying to assist me!

You can't do it that way!

You need to select batteries out of their capability, their temperature changes, not out of size only.

If this is supposed be some kind of rescue /emergency device I wouldn't trust it. You need to take climate and temperature into consideration. Batteries are hugely affected by temperature and electronics by humidity.

Make preliminary test in the lab and see what that gives. Personally I don't approve the powering. It's directly wrong. Apply Ohm's law to it!
A current of Ub/(2R) will go backwards to the single cell and ruin it. One of the two serial cells will run empty. Then the powering voltage is down to 1.5 volt.

Debugging starts by running the code. Dry reading code is very time consuming, calls for detailed knowledge of all hardware. That's not a subject for me.

1 Like

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.