Call-for-Code / Call-for-Code/Prometeo-Pyrrha
Firmware engineer: Hardware/Deep Sleep/Power Consumption Sensor
- Dominant language
- JavaScript
- Stars
- 27
- Forks
- 18
- PR merge metrics
- No merged PRs in 30d
Description
**Parts Used:**
- Az-Delivery ESP32 WROOM
- Dht-11 Sensor
- Mq-7 Carbon Monoxide Sensor
**Problem:**
The sensors connected to the esp32 Board will keep drawing power when the board is in deep sleep mode. In deep sleep mode the esp32 board will power off all the components and cut off all the connections to the gpio pins. The esp32 board has a 5v input from usb, the 3.3v and 5v vcc pins are directly connected to a power rail and there is no way to control the power pins from the board because they are directly connected to the 5v input.
https://cdn.shopify.com/s/files/1/1509/1638/files/ESP_-_32_NodeMCU_Developmentboard_Datenblatt_a3bf98d8-6a53-4d26-8f1c-c61b1c82af39.pdf?76837
| Deep Sleep | Normal
-- | -- | --
Current Usage | 0.13 mah* | 0.16/0.17 mah
Expected | 0.001 | 0.16/0.17 mah
*The sensors are drawing 0.13 mah when the board is in deep sleep mode
Potential Solution
We need to stop the circuit to the Sensors to prevent them from keep drawing power and when the board is in deep sleep. When we wake up the esp32 board we want the sensors to be used again. A solution could be to have a Relay/Switch that gets triggered by a pulse form a gpio pin.
**Notes:**
- When you wake up the sensor does it have enough time to warm up / draw power to work effectively
- For IOS devices when you use deep sleep the board is not able to reconnect to their devices AP because of a security rule
Contributor guide
Research direction
Start with the ESP32 WROOM, DHT-11, and MQ-7 hardware setup described in the issue, along with the linked board datasheet. Determine how sensor power can be controlled during deep sleep and restored on wake, including sensor warm-up timing and the noted iOS reconnection behavior. Done means the proposed hardware and wake/sleep behavior are specified and validated against the expected power use.
Written by the indexing model from the issue text.
Assessment
- Domain
- embedded-iot
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100