I am sorry for the apparent confusion, it is not my intention to waste anyone’s time, what I mean is that the i2c bus of the TTGo T-BEAM gets stuck after waking up, in this post you are talking about that it is not possible turn on the OLED screen again. I have an accelerometer connected to the 3V3 pin instead of an OLED screen. And my bus i2c get stucked after wake up from deep sleep too.
Github stickbreaker user in link posted previously by @Verkehrsrot (i don’t want to repeat urls previously posted) uses a BSS138 to avoid the problem. The image I uploaded is a 4 Channel Logic Level Shifter using BSS138.
The issue described in this topic is that it is not possible to power up the display again after it has been powered down by the PMU (caused by the display incorrectly pulling the I2C lines low when powered off).
A different issue (‘B’) with problems with ESP32 I2C bus after waking up from deep sleep is described here: Switch off devices attached to board to save energy
That issue appears to be related to configuration of (role assignment) of ESP I2C GPIO pins.
Both issues seem to be unrelated (even while both are related to I2C and both issues become visible after waking up from deep sleep).
Your problem with the accelerometer seems to be issue B related (which is not the subject of this topic).
Actually, both issues may be exactly the same (but described in different topics).
See this post: Switch off devices attached to board to save energy
Sorry for that! other post was created for me, and effectively, i was in problem to configure correctly GPIO Pins, because what i want was manage power with AXP202 library. Finally i did it, now i can choose voltage on DCDC1 pin, and connect/disconnect Lora/GPS etc. thanks to @Verkehrsrot, but, then i think ran in problem of this post. If i include this line before deep sleep:
setPowerOutPut(AXP192_DCDC1, AXP202_OFF);
bus i2c not recover from deep sleep, and is impossible to power up DCDC1 pin again. So i think my problem is the same described above in this post, if not, sorry again for that.
1 Like
I can understand that the problems look similar and they actually may be the same (see above). Both are ESP32 and I2C related and both become visible after waking up deep-sleep.
If your problem is the same as the subject of this topic it can be solved by using one of the three mentioned solutions (using the MOSFET solution described in the GitHub article is actually just a variation of using an I2C bus isolator chip).
The simplest of the three alternatives is to define a second I2C bus for the display (and/or other I2C devices) on different GPIO ports/pins. That solution does not require any additional hardware and will use only little additional memory.
Ik think the issue still needs further testing before real conclusions can be drawn.
Just to add in something we have noticed at least with our V1.0 Tbeams. The 3.3V power rail exposed on the headers actually only outputs 1.8V’s on startup. We had to then communicate with the PMU over I2c to actually give us the required voltage of 3.3V. No massive biggie, but we had a bunch of students using Xbee’s that appeared non-functional at first, until we located the source of that issue!
2 Likes
Using accelerometer in another bus, AXP can now switch on / off my GY-521.
Thanks a lot!!!
1 Like
Hi!
I’m new to both ESP32 and Lora, but very interested in what the possibilities they offer.
I’ve been searching randomly for a good, cheap board for testing range etc, and later consider setting up a gateway at home which I can reach from my boat.
I’d like to use a 18650 battery (or similar) and TTGO T-Beam ESP32 was the first thing I found which also had a battery holder. When I learned about Lora I read 5+ years of battery life, but it seems like you’re lucky with 5 days with a lot of the current devices, as long as they don’t catch fire.
Is the TTGO T-Beam the way to go? I like that it has GPS and display, which is nice for testing, but for a permanent sensor setup, I’d like something as simple as possible with Lora + I/O for a few sensors like temperature and wind etc.
T-Beam is good for evaluation, but not suitable for production use.
There is a broad market for sensor boards. You need to get a clear view on your requirements.
You may take a look at MCCI’s boards. They are on high level of serious engineering.
China products often have a lifecycle of a few months only, then often disappear from the market or version changes. And there are copies with issues etc.
It would be “production use” only for hobby/home automation. So if it can handle that, I’m interested.
I like the idea of putting a 18650 battery in the holder, but I am a bit afraid of fire, reading that some TTGO devices has actually caught fire when charging.
It would be nice with solar panel charging etc, but absolutely not necessary. Mainly I think I’d use the battery for testing range, and as a “UPS”, otherwise always keep it plugged in, charging.
But if I understand this thread correctly, it’s only the included display that has issues?
The battery circuit failure issue was so far seen only with a certain TTGO board. But it shows what can happen. Every TTGO board seen so far had a new or modified circuit for battery charging. Currently they use a dedicated pmu chip AXP192. If you let those boards charge a 18650 in your home unmanned, you take the full risk. Those boards are development units, not products, and they have CE declaration. The supplier nor the importer will pay for any damages, and perhaps your insurance won’t, too.
If you take the risk, at least be sure that you get a 18650 cell with integrated pcb for overheating protection.
I use metal security boxes as supplied e.g. by robbe.com to operate my china boards with Lipos to mitigate the risk.
Myself, especially for projects that will be used in locations which are not regularly monitored, I much prefer to use Alkalines. If the project is designed right you will get a long battery life. Alkalines are not expensive, those from Ikea are very reasonable.
Do you think if is posible to connect a 3AA battery pack directly to battery holder connectors of ttbeam board, or will be needed a voltage converter?
Full charged li-ion 3.7v battery outputs around 4.2v, and full AA battery pack i think outputs around 4.8v.
You never should do this, because the device has a single cell LiIon charging circuit.
Hi Verkehrsrot,
with my T-Beam V1.0 i discovered that i have a SH1106 display. Nothing dramatic that can´t be handled to get it to work.
But so far the display work as expected.
And even on sleeping the display is switched off by sketch and on after a time again.
I am using this at the moment.
It is Arduino stuff not native esp-idf. But it works so far for 15km to next gateway.
Not reliable on permanent base. But some packets strike thru. 
So i think actively powering off the display from axp chip is different from “screen_off();”
Most of the I2C devices are able to put into “off” state or low power consumtion.
Otherwise with some soldering it should be possible to switch the power with a gpo and a transistor from the esp itself. Not clean but most power off you could get then.
with my T-Beam V1.0 i discovered that i have > a SH1106 display.
T-Beam doesn’t have a display on board. It has to be purchased separately. So there is no certain display, it depends on what you buy.
Hi, just in case some encounter the same issue, because of the issue of SSD1306 being “wired” on keeping line up on deep sleep while sharing the main I2C with AXP, I decided to move to the 2nd Hardware I2C on ESP32. I was initially unable to make it work, until I notice that my t-beam v1.0 AXP was outputting 1.72V on the DCDC1 ! After I set it to 3.3V (cf AXP library setVoltage…) at boot the second I2C on pin 13 and 14 works like a charm !
2 Likes
I can confirm that power down of an OLED SSD1306 on i2c bus #1 of TTGO Beam v10 will block the i2c bus, thus communication with PMU AXP192 is no longer possible and we get stuck in a chicken-and-egg problem. Thus, moving display to i2c bus #2 sounds like a reasonable solution, but is it possible to keep the hardware pins for direct 1:1 soldering of display to the TTGO header, without wires?
You can stil use th same position for VCC and GND but will have to wire to the pin 13/14 in deed, not a big issue, the screen stays at the same position. Although I would anyway not consider only soldering th screen to the pin for holding it, I’d rather go with a plastic case / 3D printed case… (like the softserial ones …)
There exist female headers like the one below.
They fit standard Dupont type male header rows and have better, more firm contact than the average flat female header row connectors.
They make it easy to quickly attach and detach the display to the board.
Less suitable for mounting in a case because the display stands off farther from the board than when soldering the pins directly to the board…
Soldering the display (header) directly to the board can be usefull to mount the display while keeping it compact.
