This page describes two (2) approaches (Part#1 and Part 2) which can significantly decrease the current consumption of the TTGO Tbeam boards based on the ESP32 both in normal operation and when in deep sleep, down to a minimum of 170 µA. The regions on the main board (T22_V2) for the two modifications are shown below in Figure 1. Each of these proposed changes and their impact are described in more detail below. These change include:
- Removal of R27 SMD
- Removal of R46 SMD
- Wire link jumper from ME6211/EN (Pin 3) to GPIO21 (IO21)
- Resistor connected from TP5400/VCC (Pin 5) to GPIO21 (IO21)
- Fuse reprogramming using the espefuse.py tool
PLEASE NOTE: These modification are for experienced hackers only. Please do not attempt these changes unless you truely understand what I am proposing, understand how to perform the changes and understand the risks. As these are hardware and fuse-setting changes, if you make a mistake you can permanently damage your board. I take no responsibility for damage or problems caused from the information on these pages and as such you need to understand the risks here
The TTGO is an extremely versatile board, providing WiFi, bluetooth, LoRa radio, GPS modules and I/O under the control of an ESP32 processor. The entire board is powered from a 18650 LiPo which nominally is rated at 2600 mA.hr. However during deep sleep the lowest current that has been measured is around 10 mA, so that the maximum operational time is just over 10 days before some form of recharging is required. With the changes outlined here to significantly reduce the power of this board, this operational time could be extended to over a year.
There are two modifications required to lower the power of the TTGO boards.
- The first allows complete shutdown of the NEC 6 GPS, USB Controller and LoRa board during operation, so that only the ESP32 power consumption dominates.
- The second allows shut down off the SPRAM and Flash attached to the ESP32 so that during deep sleep, minimal power is consumed. With these modifications, a maximum of 170 µA is consumed during deep sleep, considerably less than the nominal 10 mA reported,
Deep sleep modes are detailed in the espressif page which describe how to shut down the ESP 32 into low power mode with all but the RTC operational. The RTC needs to be active for the processor to wake on a timed interrupt. The ESP32 Electrical datasheet indicates the power consumption in the various modes as shown in the table below:
Table 1: Power Consumption of the ESP32 processor. This table was extracted from the Espressif Systems ESP32 Datasheet V3.3 where it was originally designed "Table 6: Power Consumption by Power Modes" on page 21 of that document.
The ME6211 is a High Speed LDO Regulator and the TTGO schematic includes 2 of these, namely:
- one (U8) to generate a 3.3V that powers the ESP32 and attached memory and
- one (U5) that generates 3.3V (labelled VCC_3.3V) to power the GPS, USB I/O controller and LoRa board.
Both these ME6211 regulators contain an enable pin that is pulled high to keep the regulators on after power up. During a regular boot sequence, the GPS is on and looks for satellites. This typically draws 180±10 mA and lock can take around 2 minutes. After lock the current consumption is still around 100mA. While the GPS can be shut down in software, it is difficult to lower the current consumption much less than 90 mA during regular operation.
In this first approach to lowering the power consumption the enable pin of IC U5 (the ME6211 that generates VCC_3.3V) is connected to GPIO21 to allow the power supplied to the GPS/LoRa/USB controller to be placed under software control. Once done issuing the command digitalWrite(21, LOW) in the .ino file just before shuting down the ESP32 using esp_sleep_enable_timer_wakeup() shuts down GPS/LoRA/USB-Controller, allowing the entire TTGO to enter an ultra-low power state. This provides much greater flexibility when determining which devices should be powered up and when.
The physical layout of the TTGO Tbeam T22_V22 PCB is shown in Figure 2a with the 10 kΩ resistor R27 identified next to the ME6211 SMD. Without adding additional drivers (FETs or other) it is essential to remove the R27 (10 kΩ) resistor as we need to control the ME6211 by driving it's enable pin (pin 3) low using digitalWrite(21, LOW) while the ESP32 is in deep sleep. As the ESP32 cannot continue to sink current while in deep sleep, leaving the R27 in place will force the ME6211 enable (pin 3) back into a high state, turning back on the GPS/LoRA/USB-Controller significantly the power consumption (see table #2 below). To remove this surface mount resistor I suggest using a small amount on regular lead-tin solder with a flux resin to allow even flow across the small component. I performed this task with a regular electronics style
soldering iron, but it required a magnifying lens with a good light during the process. After R27 is removed, a small piece of solid core Kynar wire (sometimes called wire-wrap wire) was used to connect from ME6211 Pin 3 to GPIO21 on the header connector. Once used, GPIO21 should not be used for another other task. The PCB after R27 removal and the addition of the wire (red) is shown in Figure 2b. The corresponding circuit before and after the PCB modification is shown in Figure 2c and 2d, respectively. Note that in Figure 2b I have also disconnected the GPS antenna as it was found that this add at additional ~7 mA (see table #2). If not using the antenna, best to just disconnect to ensure maximum battery life.
BUT WAIT: Having removed R27 the GPS/LoRA/USB-Controller is entirely under software control. What happens when we go to upload updated fireware to the TTGO via USB connected PC ? With the CP2104 USB-Controller off, the USB connected PC never sees the TTGO board and it can never be reprogrammed (effectively bricked). The solution is to reconnect a resistor (value anywhere from 10-100 kΩ) from ME6211/EN (Pin 3) to TP5400/VCC (Pin 5), the latter pin being connected to the USB 5V supply (VBUS) via a 0.3 Ω (R54). This physical change is shown in Figure 2e, where a 27 kΩ resistor was used. In doing so the ME6211/EN (Pin 3) is now HIGH whenever the USB cable is connected, overriding the software defined state and the USB port is valid when programming the TTGO. Figure 2d shows the jumper used to connect to the ME6211/EN (Pin 3) (actually connected now to GPIO21).
With this change, by default the GPS/LoRa/USB are off unless the USB cable is plugged in. If you want to use the GPS/LoRa/USB in normal operation, include the following in the setup() routine
pinMode(21, OUTPUT);
digitalWrite(21, HIGH);
If you intend to force digitalWrite(21, LOW) to shutdown power to the GPS/LoRa/USB and achieve low power during ESP32 operation you should see the later section Part 3: Push button to enter (all ON) firmware programming mode. If you don't implement the push-botton switch as I suggested in Part 3 then, if the worst happens and you force digitalWrite(21, LOW) and the code you uploaded keeps GPIO21=LOW you will not be able to program the TTGO and it is effectively "bricked". However the simple solution is to remove the ME6211/EN (Pin 5) link to GPIO21 and tie this pin high (3.3V or 5V) via a 10 kΩ resistor. This will re-enable the USB controller and you can upload a modified version of the firmware. To avoid this, I recommend implementing the Push button to enter firmware programming mode.
During extensive software testing, no conditions could be found to lower the power below 2.2mA in deep sleep. It turns out the main schematics for the TTGO Tbeam is very similar to that used for the ESP32 wroom-32 a generic Wi-Fi+BT+BLE MCU module. From those schmatics, it appears that the external SPRAM and Flash could be shut down by powering both via VDD_SDIO which is a voltage generated through the ESP32 itself (it contains an internal LDO regulator). However, on the TTGO Tbeam board the VDD_SDIO is directly connected to 3.3V. This 3.3V is the main battery supplied voltage, which is always on even during sleep. As stated in
Section 2.3 Power Scheme of the ESP32 datasheet
VDD3P3_RTC is also the input power supply for RTC and CPU. VDD3P3_CPU is also the input power supply for CPU. When VDD_SDIO is connected to the same PCB net together with VDD3P3_RTC, the internal LDO is disabled automatically.
Hence connecting VDD_SDIO directly connected to the main 3.3V supply (which supplies VDD3P3_RTC and VDD3P3_CPU) over-rides (bypasses) the internally generated VDD_SDIO voltage (set to 3.3V), so that external SPRAM and Flash (and the associated resistor R35, see schematic) are all drawing current during deep sleep. However this connection from VDD_SDIO to 3.3V is done through R46 (a 0Ω resistor) so I investigated removing the resistor to determine the possible reduction in current during deep sleep.
Using the same approach as described in Figure 2, a standard soldering iron with a small amount of tin-lead solder with a resin flux was used to remove R46. The physical layout of the board is shown in Figure 4a before and 4b after removing of the resistor. In this image I have also added a small wire to VDD_SDIO to monitor what happens during deep sleep. Sure enough , when the code enters a deep sleep using esp_deep_sleep_start(); the voltage VDD_SDIO drops to around 250mV, and jumps up to 3.3 V when the board exits from sleep mode. The relevant section of the circuit schematic have been extracted and shown in Figure 4c and 4d, before and after the modification, respectively.
ISSUES to NOTE: When the above changes were made the following erorr would consistently appear during firmware upload using the arduino IDE:
Configuring flash size...
Warning: Could not auto-detect Flash size (FlashID=0xffffff, SizeID=0xff), defaulting to 4MB
Compressed 8192 bytes to 47...
A fatal error occurred: Timed out waiting for packet content
A fatal error occurred: Timed out waiting for packet content
This error went away when I reconnected VDD_SDIO to 3.3V on the board suggesting the Flash was off during programming. Sure enough, a voltage check of VDD_SDIO indicated that it pulsed off as soon as firmware upload started. The ESP32 wiki on boot-mode-seelction indicated
"If [Ed. MTDI] driven High, flash voltage (VDD_SDIO) is 1.8V not default 3.3V. Has internal pull-down, so unconnected = Low = 3.3V. May prevent flashing and/or booting if 3.3V flash is used and this pin is pulled high, causing the flash to brownout. See the ESP32 datasheet for more details."
The TTGO schematic was confusing, indicating MTDI is pulled high via R19 to 3.3V, but that either R19 was 10 kΩ OR Non-Connected (NC). A quick check of the TTGO Tbeam T22_V07 board indicated R19 was NC.
Given I wanted to minimize any further hardware changes, I investigated a software/firmware fix by setting of the ESP32 fuses through the use of the espefuse.py
tool. After installing this tool I determined the ESP32 initial fuse data by running (from the terminal/command line)
espefuse --port COM37 summary (note my port was COM37, your may be different)
The default fuse settings are here but those relevant to the VDD_SDIO setting are:
Config fuses: XPD_SDIO_FORCE Ignore MTDI pin (GPIO12) for VDD_SDIO on reset = 0 R/W (0x0)
XPD_SDIO_REG If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset = 0 R/W (0x0)
XPD_SDIO_TIEH If XPD_SDIO_FORCE & XPD_SDIO_REG, 1=3.3V 0=1.8V = 0 R/W (0x0)
.
.
Flash voltage (VDD_SDIO) determined by GPIO12 on reset (High for 1.8V, Low/NC for 3.3V).
As expected, given that GPIO12 was not connected, the default state during restart was VDD_SDIO=1.8V which explained the FLASH brownout that was ocuring during fireware upload. This could be fixed by running the command
espefuse --port COM36 set_flash_voltage 3.3V (note my port was COM37, your may be different)
After which, the resulting fused states are given here, those relevant to VDD_SDIO being:
Config fuses: XPD_SDIO_FORCE Ignore MTDI pin (GPIO12) for VDD_SDIO on reset = 1 R/W (0x1)
XPD_SDIO_REG If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset = 1 R/W (0x1)
XPD_SDIO_TIEH If XPD_SDIO_FORCE & XPD_SDIO_REG, 1=3.3V 0=1.8V = 1 R/W (0x1)
.
.
Flash voltage (VDD_SDIO) set to 3.3V by efuse.
After this change, firmware upload proceeded without issue.
Using combinations of a new board, a board with no GPS antenna and the same TTGO in various states of modification (Part #1 and Part #2 above), a combination of tests were performed by running the attached TTGO_PowerEval.ino. The code shut down or turned on various components on the board while the DC current was measured, at 10 second intervals. The results of the testing is shown in Table #2 below where the delay indicates the delay that has passed and the subsequent code/functional-description performed is indicated in column 2 and 3 below.
| Delay after start | Description | code | As New | As New, No GPS antenna | R27 removed, with GPS Antenna | R46 removed, with GPS Antenna | R27 & R46 removed, with GPS Antenna | No GPS antenna, R27 & R46 removed |
|---|---|---|---|---|---|---|---|---|
| ------------- | ------------- | ------------- | unit (mA) | unit (mA) | unit (mA) | unit (mA) | unit (mA) | unit (mA) |
| 0 | START | |
192 | 182 | 193.5 | 192 | 193 | 181.5 |
| 10 | GPS OFF | ShutDownGPS() |
92.7 | 86.4 | 92.8 | 92.7 | 92.1 | 84.9 |
| 20 | WIFI OFF | WiFi.mode(WIFI_OFF) |
92.7 | 86.4 | 92.8 | 92.7 | 92.1 | 84.9 |
| 30 | BLUETOOTH OFF | btStop() |
92.7 | 86.5 | 92.8 | 92.7 | 92.1 | 84.9 |
| 40 | LORA OFF | LoRa.sleep() |
89.4 | 83.2 | 89.5 | 89.4 | 88.9 | 81.7 |
| 50 | ME6211/EN off | digitalWrite(ME6211_EN, LOW) |
78.1 | 71.8 | 73.5 | 78.1 | 73.1 | 76.3 |
| 60 | ME6211/EN on | digitalWrite(ME6211_EN, HIGH) |
89.2 | 82.9 | 89.2 | 89.1 | 88.6 | 81.4 |
| 70 | LED ON | digitalWrite(BUILTIN_LED, HIGH) |
90.3 | 84.1 | 90.4 | 90.3 | 89.7 | 82.6 |
| 80 | LED OFF | digitalWrite(BUILTIN_LED, LOW) |
89.2 | 82.9 | 89.3 | 89.1 | 88.6 | 82.6 |
| 90 | config ESP sleep interrupt | esp_sleep_enable_timer_wakeup() |
89.2 | 82.9 | 89.3 | 89.2 | 88.6 | 81.5 |
| 100 | config RTC | esp_deep_sleep_pd_config(() |
89.2 | 82.9 | 89.3 | 89.1 | 88.6 | 81.4 |
| 110 | enter DEEP sleep | esp_deep_sleep_start() |
19.25 | 12.88 | 2.25 | 17.2 | 0.17 | 0.17 |
The interesting observations from these tests are:
- Shuttign down the GPS immediately in the
setup()routine is essential to prevent high current draw after wake up or restart - Removing the GPS antenna can lower the base current consumption by about 7.2 mA, so that a minimum current of 12.88 mA during deep sleep could be achieved. This current consumption is consistent with other measurements of 10mA consumption
- Removal of R27 and jumpering to GPIO21 which allowed shutdown of the GPS/LoRa/USB controller during deep sleep allows the current during deep sleep to fall to 2.25mA
- Most of this 2.25mA current during deep sleep came from Flash/PSRAM consumption. Removal of R46 and fuse-reprogramming to set VDD_SDIO=3.3V allowed deep sleep current consumption to drop to 170 µA
- Antenna removal in addition to R27 &R46 removal (last column) allowed current consumption during operation to be reduced by 7.2 mA
- best configuration appears to be 73.1 mA during operation from
digitalWrite(ME6211_EN, LOW)with the GPS anyenna attached, and R27 & R46 removed to allow 0.17 mA during deep sleep
I note that when the entire power to the board is turned off via switch 2JP1 in the schematic, the current drawn is only 70 µA. A voltage divider made from R42 and R43 loads the LiPo battery with 200KΩ accounting to 18.5 µA of this current, so that around 51 µA is consumed by the TP5400, a 1A lithium battery and 5V / 1A boost control chip used to convert the 18650 LiPo battery from 3.7 V to 5 V. From the datasheet, the maximum input supply current for this device is 100 µA so the measured value of 51 µA is reasonable. Assuming the same current is consumed when the main power switch 2JP1 is on, then given the measured total of 170 µA when the ESP32 is in deep sleep mode, I can assume that 100 µA is associated with the ESP32 and 70 µA is associated with R42,R43 and the TP5400 power control chip. Reviewing the power listed in Table #1 above from the Espressif Systems ESP32 Datasheet V3.3, this measured value of 100 µA is expected from the ESP32 when in deep sleep but with the ULP enabled (which it is as the processor is this work is arranged to wake on a timed interrupt with ULP and RTC). Hence I believe there is not much more that can be squeezed out of the circuit to minimize the current unless an external interrupt is used. Even if we shut down the ULP, the current consumption is dominated by the 70 µA from R42,R43 and the TP5400, power control chip, so that no more than a x0.6 reduction in total current could be achieved. Given I have dropped the current from an as-new (no GPS antenna) deep sleep current of 12.88 mA to 0.17 mA (a factor of 75) a reduction of x0.6 is hardly worth the effort for further circuit modifications. If a software solution could be found to further lower the current, I would be interested to see the code.
Push button to enter (all ON) firmware programming mode
As an alternative mode of operating, you can sense the unused push buton connected to SENSOR_VN to enter programming mode. See the firmware TTGO_LowPowerSwitchOverRide.ino. As written the code initially senses the state of the SENSOR_VN input (GPIO39). If this is in the high state (default), the code immediately shuts off power to the GPS, LoRa and USB controller (ME6211/EN=GPIO21=LOW) and enters deep sleep. When the board awakes it:
- checks the SENSOR_VN input, and if held on (pushed), applies power to the GPS, LoRa and USB controller (ME6211/EN=GPIO21=HIGH) and the code enters the loop() routine. It never re-enters deep sleep, staying in this state untill the board is reset or the board is reprogrammed via the serial USB
- checks if the board has awoken due to the timer using ESP_SLEEP_WAKEUP_TIMER. If this is the case, it runs
MyInterruptRoutine(), then returns and re-enters deep-sleep.
Current consumption was measured to be 0.18 mA in deep sleep, 57.2-58.1 mA when the board wakes up from deep sleep (with GPS, LoRa and USB controller off, ME6211/EN=GPIO21=LOW) and 189-209 mA when SENSOR_VN input is held low during a wake up event (when GPS, LoRa and USB controller are all on, ME6211/EN=GPIO21=HIGH). This mode of operation if alot more flexible as it does not impact reprogramming and allows the board to stay in the lowest power state until the required device (GPD, LoRa or USB) is required. The next step is to lower the clock speed reduce power, by enabling dynamic frequency scaling. This would allow very low power consumption during general operation until high power operations were actually required.