Display looks like the one on my board, don’t know what’s getting wrong there. Maybe a i2C problem?
I’m using 450mAh LiPo cell, also looking for a bigger one with snap fit in the case. But didn’t find one yet.
This is very strange, OLED same board with my Scan I2C WiFi works fine with SSD1306 settings.
Recommendation for Lipo is to charge at 0.5 nominal capacity, so charging at 500mA a 450mAh Lipo is really out of spec. Does it works without heating?
Looks like got 2 association problem with OLED
- Both TTGO V2 works with custom Wifi scan (not same OLED library than PAXCounter)
- With PAXCounter, one display fine, the other, display is corrupted.
yes, there sometimes odd OLED display garbage problems, i discovered them on Heltec, too.
No idea how to fix this. I assume the problem comes from running u8x8 in RTos multitasking environment. If you change from hardware to software i2c driver the problems increase. Timing in i2c bus? race condition?
yes it heats up. Schematic says that there are resistors on the board to select battery charge power.
@pixelchain Did you increased the OLED space on top side in V2?
I ordered one from 3D hubs 2 weeks ago and the OLED of my TTGO V2 is too high. I can’t close the enclosure because OLED goes higher than bottom case.
I don’t think that I did any changes on that side. Do you still have the STL files that were sent to the 3d Printing Service? Last changes I did were on 29th an they were related with the antenna issue reported by verkhersrot.
Here’s the measurements of the current model from Thingiverse
You ca try to measure your print and tell me were is the problem. Eventually you can make some photos too.
coming back on the battery topic. I noticed that the battery i’m using has a built in mini pcb with own charge controller. Seems that this keeps fire off when charging with 500mA…
I ordered a second case via 3Dhubs, too. It was produced by a 3D printshop in Mönchengladbach on a Ultimaker. Turns out that the display mask does not fit exactly on the (same as before) TTGOv2 board, ca. 1-2mm offset top and right, see picture. Also the screws did not fit the holes of pcb, again 1mm offset, i fixed it by stretching the pcb holes.
Display on TTGOv2 randomly turns off
I noticed an odd problem with the SSD1306 128x64 OLED display on the TTGOv2 board: it sometimes randomly turns off.
I assume this is not a software caused problem, because
- same code runs on Heltec board (which has same architecture) without display off’s
- while display is off, software is alive, writing to the display (green LED on clk line is blinking)
Assumption: It’s because the RES input of the OLED display is wired to Vcc on TTGOv2. On Heltec board the line is wired to GPIO16 of CPU. hence it can be controlled by the display driver.
Could be, but I have plenty of board with SSD1306 without Reset pin wired and all are working fine.
Would you mind remove line 361 of main.cpp (noot needed, a bad cut&paste from I) it’s a second call that may cause the issue?
u8x8.begin();
If it’s not better add a new line 361 (with always 2nd begin removed) with
// reduce I2C bus speed (must be done after begin)
Wire.setClock(100000);
Let me know how things are going after that
The statements
u8x8.begin();
u8x8.setFont(u8x8_font_chroma48medium8_r);
are crucial for boards without display (no #define HAS_DISPLAY) because without these lines the u8x8 null display causes a guru meditation error. But indeed these lines are now doubled, i will correct this.
And let’s try to reduce i2c speed. Perhaps it solves those odd display problems noticed on some,but not all,china boards.
yeah I know, I was speaking about 2 lines later
I put this in branch test.
But i seems 100000 is anyway the default in Wire.h?
public:
TwoWire(uint8_t bus_num);
void begin(int sda=-1, int scl=-1, uint32_t frequency=100000);
void setClock(uint32_t);
Double lines removed in both branches master and test.
1 Like
A lot of small Lipos have built in circuits for safety reasons to prevent them being abused in circumstances where the charge\discharge is not properly implemented.
Yes, but you can also get those without.
Only few sellers state that in their product description.
Like segor.de does.
Correct, but we don’t know how it’s initialized in u8g that’s why we need to do it again after u8x init 
Yes, we do! Since it is open source, look here
if ( u8x8->display_info->i2c_bus_clock_100kHz >= 4 )
{
Wire.setClock(400000L);
}
Hmm, but this seems to be something different regarding a “Fast mode”.
1 Like
Display error persists, now it’s a “:” and in the last line was the “joined” test incomplete.
Let’s try opposite and speed up to 400000
1 Like