In the last few days I’ve been attempting to resolve a major design fault on the TTGo T5 eInk display board, where the battery management chip (IP5306) was completely turning off the power to the ESP32, and the other chips, when I put the ESP32 into deep sleep mode.
The problem is a design fault, and is primarily because the battery management chip (IP5306) is designed for “power bank” devices, where a LiPo cell is used to power a 5V USB device, rather than powering a microcontoller or any other 3.3V devices.
The IP5306 only has a datasheet written in Chinese, but I noticed that it had an option to attach a button to pin 5, and grounding this pin, via a resistor, caused the chip to wake up and put 5V on its pin 8.
Also momentarily pressing the button, while the chip was awake, cause it to stay awake even when there ESP32 was in deep sleep and and consuming hardly any current.
So my first idea was to make the the ESP32 “press the button” by connecting one of its GPIO pins to the button pin (5) via a 1k resistor, then make the ESP32 wake up from deep sleep to metaphorically press the button, every 30 seconds, before immediately returning to deep sleep.
This was never going to be a perfect solution, as the IP5306 (battery manager) seemed to need a button press pulse of at least 100 milliseconds, hence the ESP32 would need to be consuming its normal current for 0.1/30 of the time. But this would only be 0.3% of the total time, so I thought if this method worked, it would be adequate.
Unfortunately, although initially this strategy appeared to work OK, I found that if I left the board running from a battery overnight; when I checked in the morning, the IP5306 had turned off.
I think that the IP5306 probably has a maximum operation time, or perhaps a maximum count of the number of button presses which it allows before turning of when there is virtually no load.
But whatever the reason, it became clear that the IP5306 is totally unsuitable for the application to which its been put, and I took the radical decision to remove the chip from the PCB completely and use an external battery charger / protection module instead.
I have a hot air reflow tool, but because I didn’t want to damage any components near the IP5306, I decided to cut its legs, to remove it. However I found that even after cutting all 8 visible pins the chip seemed to be stuck to the board.
What I didn’t realise was that its a 9 pin package with a large Ground terminal on the base of the chip, which probably also acts as a heat sink. Luckily they had not used that much solder paste under the chip and I it came away without too much force and the board was not damaged.
Once the chip had been removed, I was able to solder a wire to the pad for pin 1, which receives 5V when the board is connected to USB (or I presumed powered via the 5v pin on the header), and a wire to pin 8, which was the output (5V which I presume feeds into the EA3036 multi output buck converter), and a third wire to the ground pad in the middle of the IP5306 footprint.
I already have a stock of TP4055 based battery charger modules with built in battery protection. So I soldered the module to these 3 wires, and connected the same 2000mAH LiPo cell to the new battery charger module.
Once everything was connected, I was surprised to find that the battery charger module was only outputting 1V, even though the battery was almost fully charged and measured as 4.15V, and initially I thought perhaps the charger module was faulty; however I found that if I supplied power via USB, not only did the whole TTGO board start working, but when I removed the USB power that it continued to be powered via the LiPo battery.
So it appears that these battery charger / undervoltage protection modules need to be initially primed with 5V on their input before the undervoltage protection is removed.
Running from battery power, of around 4.1V, the TTGO 5T board seemed to work fine, and checking the spec of the EA3036, in theory it will operate with an input voltage as low as 2.7V, which is less than the minimum operating voltage on the LiPo cell, so I think the TTGO board will work fine from battery, however I will leave it running a Wifi server (drawing around 100mA), until the battery voltage gets close to its minimum value, to confirm my supposition.
However before leaving the battery drain program running, I also tested the current being drawn from the battery when the ESP32 was put into deep sleep mode.
Unsurprisingly I found that the TTGO board as a whole was taking around 7mA, but I was not surprised because the red “power” LED was still illuminated and I thought perhaps that accounted for the majority of the current.
But I was wrong…
I removed the LED and found virtually no difference in the current being drawn from the battery. So the next step was to check whether the current was actually being drawn by the TTGO board or by the new battery charger / protection board.
So after a small amount of rewiring and my multi-meter connected between the new battery charger module and the TTGO board, I measured virtually the same current.
By now I wasn’t particularly surprised by this, because the NS4148 class D audio amplifier chip has a typical standby current of 3.5mA, and could potentially be taking more, plus I am not sure how much current will be taken by the EA3036 buck converter even when it has virtually no load on one of its outputs.
So the next set of tests I need to perform are to around the NS4138, and I’ll probably have to find the pullup resistor for its “CTRL” pin, which needs to be pulled low in order for the NS4148 to be put into its low power standby mode.
However I think if putting the NS4148 into standby does not radically reduce the power that is consumed, I will not have much scope to improve things, as the circuit may also include multiple wasteful pullup/ pulldown combinations and these could be hard to track down, and the EA3036 would need to be replaced with something which had very low quiescent current properties, and I’m not quite sure what devices would fit the bill.
BTW. It looks like disabling the outputs on the EA3036 that drive the NS4148 is not practical as the “enable” pins are connected together and only have a short length of track on the PCB before they go to a via, and it will be hard to track down where the via goes.
Also using a 2000mA battery, a 5mA load would in theory last around 16 days, and this is probably adequate for any use I can think of for the whole module.
Anyway, I’ll post another followup article when I have had chance to do a discharge test on the battery and also experimented with the CTRL pin on the audio amplifier.
Update. 11th Oct 2018
I’ve managed to get the current drain down to 1.5mA but I don’t think its practical to get it any power.
I removed the pullup resistor on the NS4148 audio amplifier CTRL (Pin 1) and soldered a 10k resistor to ground instead.
I then connected the IO19 header pin to Pin1 on the NS4148.
This keeps the NS4148 in low power mode, until I drive IO19 high. i.e before I can play any audio, I have to do this, and afterwards set IO19 as high impedance (aka input)
I’ve had a look at the EA3036 multi output buck converter, to see if I could use its ENable pins to shut down part of the chip that was not driving the ESP32, but this would be hard to do, because all the enables seem to be directly connected together and share the same (10k) pullup resistor. So it would take some extremely delicate surgery on the board to cut the track(s) right next to the chip and control the outputs separately.
And I’m not entirely sure whether that would actually help reduce the current, as 2/3 of the EA3036 would still be running
So without a schematic for this board, its going to be very difficult to know what else could be taking any current.
Consequentially, I think I’ll need to live with 1.5mA when the ESP32 is in deep sleep.
PS. I’m still doing battery voltage testing, but since I have a 2000mAH battery attached, its taking ages to flatten it just using the current drain from the ESP32 with its Wifi turned on.
So I’ll either need to leave it on for a few days, or find a way to drain the battery a lot faster.
ken
wow impressive
Roger Clark
Hi Ken
Since I posted this last night, I have left the board running, drawing around 100mA with the Wifi on, and it was still working this morning.
I’ve also modified the board again, by removing the 10k pullup on pin 1 of the audio amplifier and replacing with a non SMD 10k resistor to GND, and also connected this pin to GPIO19 on the header.
This has reduced the current drawn, to 1.5mA in deep sleep mode, as the audio amplifier is now also in low power standby mode unless its enabled
Unfortunately I don’t think its going to be possible to improve this, and get the current drain levels down to the sub 100 uA values that the ESP32 is capable of
Kevin Hester
btw – they seem to have a 1.2 version of this board out and based on the schematic I found they seem to have a much better charge controller. Also my wife reads Chinese and she helped me read the IP5306 datasheet (it shuts down if it doesn’t see at least 150ms of >45mA power consumption in any 32s window). The hack I used in sw to keep it from killing the board was to wake the CPU from deep sleep every 30 seconds have it burn 100mAish of power for 200ms and then go back to sleep (ugly, but no soldering needed).
Roger Clark
Hi Kevin
Does your workaround, work indefinitely ?
I tried something similar, by waking the board up every 30 secs and by simulating pressing the button input to the IP5306 (I connected it to the GPIO)
However it only ran for a few hours before the power turned off.
I presumed that the IP5306 had some other long term timer which was kicking in, because if I power cycled the board it would then run for another few hours.
Kevin Hester
Hi Roger, I ran it for 24 hrs without a failure. Power stayed on all night (with the board mostly in deep sleep). I just shut it down so I can desolder the 4 battery LEDs.
(My board is a T5s, but I assume it is similar to your T5). I have some T5 v1.2 versions on order and when they arrive I’ll see if they can run without this hack (because they ditched the IP5306).
Roger Clark
OK
Perhaps I didn’t wake from sleep long enough.
Looking at my code, I set the time to sleep as 30 seconds.
In my test, when it wakes up, it simulates the “button” input to the IP5306 being pressed (via a GPIO), and then makes a series of beeps via the speaker, which should take just over 1 second.
Perhaps pressing the “button” pin on the IP5306 is the problem, because it seemed to stop working after a few hours.
I bought 2 of these module, but I completely hacked the electronics on the first one to remove the IP5306 and put in a separate charge controller.
BTW. I also looked at the power taken by the other chips on the board, and I think both the charge pump IC and the amplifier chip also run all the time, and take current.
But I gave up on modifying the board to make it any lower power, because I’d have to almost completely remove most of the ICs apart from the ESP32, as the hardware had not been designed for low power operation at all 🙁
Kevin Hester
Alas, pressing the button won’t do it. You have to wake and just draw >60mA for >150ms every 30 seconds. The button does different things (including a flashlight mode for press >2 secs, and power up/down based on 1/2 presses in <1 sec). can you eamil me a note and I'll send you the translation my wife made of the relevant parts of the datasheet.
On my T5s I have to pay 22mA/day for this nasty sleep hack. Which isn't too horrible.
That said I've also ordered 1.2 version of the T5 – according to the schematic they have a proper power mangment ship.
Roger Clark
I would have thought that playing a beep though the speaker etc for 1 second should have drawn enough current for long enough
The only difference I can see is that I was pushing the button down for the whole 1 second it was playing the audio
Anonymous
Roger, Can this display be used in place of the Nextion Screens for the MMDVM hotspots? Also, Is there anyway to display Nextion info on regular screen (HDMI, tablet, etc.)? Thanks and 73’s Joe N2OAD
Roger Clark
Yes.
I’ve been working on a project to do this, however its got some major bugs at the moment, which I’m still trying to sort out.
I’m parsing the Nextion data, with the layout set to ON7LDS L3, as it sends additional information which makes the parsing easier.
Since the display update speed is quite slow, these screens can’t be used exactly the same as the nextion, but instead I’m displaying a list like on the dashboard of PiStar, with Time, TG and Callsign + name
The code is written using the Arduino IDE, so that I can use the ePaper libraries by Jean-Marc Zingg. At the moment I’m running the code on a STM32 BluePill board, connected to the same ePaper display, but the code should be portable to the TTGo display
However, I have some nasty bug in it at the moment, which is possibly a buffer overflow, something to do with calculating the current time (since the display does not get sent it during a QSO , as its only sent when the MMDVM (idle) screen is displayed — (I think))
So I won’t be able to publish the code until this is fixed.
I’m also very busy with the GD-77 now the firmware encryption has been broken, so don’t have so much time to spend on my PiStar display project
Raine™
Where can one find the schematics for these boards? I need to find a 2.7″ display that can property deep sleep.
Roger Clark
They appear to be based on the M3Stack board.
In the original boards, there is no way to completely get them to work in deep sleep mode, because they use a power control chip, which is designed to be use with a battery “power bank” device, and not for low power applications.
Also the other peripherals on the board, like the amplifier don’t have the control lines to put them into low power mode.
So you have to do quite a few electronic modifications to the board to make take very low power when the ESP32 is in deep sleep.
Raine™
Well that’s a pain. I’ve placed an order for one of these to see if the chip is fixed or not. Feel like its a step back. Might have to have something fabricated if I can’t find a simple replacement.
Raine™
Looks like I was able to fix my issue on my v2.1 board which has the IP5306_i2c. Testing now, but don’t know what the voltage draw looks like at sleep since I don’t have the knowledge on how to test that 🙂
https://gist.github.com/rlightner/89396af9f77f776c6b2e6e45ff8dd976
iaraki
Hi, I have a TTGO T5 2,9inch v2.2 display from Tindie. https://www.tindie.com/products/ttgo/ttgo-t5-v22-esp32-29-epaper-plus-e-ink-speaker/ But I am unable to compile the code they provide. I get an error in “boardef.h” “please select board type”. Any idea? Thanks,
Roger Clark
I’m not familiar with the Tindie version and whether its the same as the other TTGO version.
From what I recall you to enable (uncomment) one of the display options, probably in boardef.h
You may have to change the pin mapping as well. But to start with I’d just look in there and enable the display type which most closely the display size etc
ehm.education
bool setPowerBoostKeepOn(int en)
{
Wire.beginTransmission(IP5306_ADDR);
Wire.write(IP5306_REG_SYS_CTL0);
if (en)
Wire.write(0x37); // Set bit1: 1 enable 0 disable boost keep on
else
Wire.write(0x35); // 0x37 is default reg value
return Wire.endTransmission() == 0;
}