Posts made by sohtamei

Re: Short Wifi effective range and IO0=3.9V issue with Lite and Matrix

This issue has been fixed with "IO0-pullup-OFF" firmware for CH552 (GREEN LINE).

https://sohtamei.github.io/docs/esp32AndUsbUartWith5V_IO_Issue.html
https://sohtamei.github.io/docs/esp32AndUsbUartWith5V_IO_Issue2.html
Please translate language on Browser.

I fixed this issue with XCLK=8MHz and x2 clock on ov2640 side.
https://youtu.be/MBOGWK5qrkw
Master clock of 5/10/20MHz by ESP32 reduces Wifi throughput.

FW:

1. burn firmware (customized CameraWebServer)
   https://sohta02.sakura.ne.jp/tukurutch/
   [Add extension]
   -- [M5Camera,ESP32cam,..]
   -- pulldown [burn (M5Camera)] to "unitCam"
   -- click [burn (unitCam)]

2. enter SSID and pass to [connect ssid ..] and click it.

3. click [Wifi Status] and get IP address

4. access to IP address via web Browser

Report(in Japanese):
https://sohtamei.github.io/docs/ESP32CameraIssue.html

Please try my test firmware for this issue. You can try it with any ESP32 device, with&without camera device.

[procedure]

1. burn firmware (customized CameraWebServer)
   https://sohta02.sakura.ne.jp/tukurutch/
   [Add extension]
   -- [M5Camera,ESP32cam,..]
   -- pulldown [burn (M5Camera)] to "testXclockIssue"
   -- click [burn (testXclockIssue)]

2. enter SSID and pass to [connect ssid ..] and click it.

3. click [Wifi Status] and get IP address
   
   I attach source code of this firmware:
   http://sohta02.web.fc2.com/images/testCamWifi.zip

According to above result,

• chip-ESP32 is better than WROOM-32x.
• "aitendo" PCB is good.

The "reworked" unitCam is No.4, the result was not bad, but not enough.

I found the route cause of this issue - XCLK=20MHz of ESP32 makes WIFI-through-rate slow. This issue can be reproduced without ov2640. I prepared dummy network camera firmware, which can run dummy streaming, and can turn on/off XCLK with "AWB" slide bar. Please see following video:
http://sohta02.web.fc2.com/images/esp32CameraWebServerIssue.mp4

I tried following ESP32 devices:

The result was following:

• Max duration and average of "Get Still" for 20~30 cycles [ms]
  

I found better solution.
I tried PCB-rework - cut between DOVDD and 2.8V, then connect DOVDD to 3V.
The transfer rate of Image has been improved, and I succeeded in streaming Video.
JPG: 17013B 407ms
JPG: 17258B 331ms
JPG: 17133B 170ms
JPG: 17062B 154ms
JPG: 17090B 164ms

"Transferring image is very slow" is occurred by PCB design, PCB layout and xclk_freq condition, but I could not fix this issue with xclk=5000000 (lowest?) condition.
config.xclk_freq_hz = 5000000;
// config.xclk_freq_hz = 10000000;
// config.xclk_freq_hz = 20000000;

[guess of root cause]
with ESP32-CAM, which has similar schematics with UnitCam, I can stream video with CameraWebServer.
The differences between UnitCam and ESP32-CAM are port assignment and camera powers.

• DOVDD and AVDD are not separated.

I cannot try PCB-rework for UnitCam, so I'm not sure whether separation of DOVDD-AVDD is root cause. But there may be some HW issue on UnitCam PCB.

[Symptom]

• cannot stream video.
• transferring image is very slow (8~20sec)

[procedure]

1. burn firmware (customized CameraWebServer)
   https://sohta02.sakura.ne.jp/tukurutch/
   [Add extension]
   -- [M5Camera,ESP32cam,..]
   -- pulldown [burn (M5Camera)] to UnitCam
   -- click [burn (UnitCam)]

2. enter SSID and pass to [connect ssid ..] and click it.

3. click [Wifi Status] and get IP address
   

4. connect to UnitCam with Console App(such as TeraTerm) via Uart port.

5. access to IP address of step3 from chrome browser, then push [GetStill].

The transfer rate is displayed on Uart-Console. It's very slow and cannot stream video.
JPG: 17035B 1787ms
JPG: 17147B 10267ms
JPG: 17179B 8910ms
JPG: 17180B 17621ms

[source code]
https://github.com/sohtamei/TuKuRutch.ext/tree/master/libraries/unitCam
https://github.com/sohtamei/TuKuRutch.ext/tree/master/arduinoLib/TukurutchEspCamera

In my evaluation, the effective range from Wifi AP was short:
　Matrix(n=2) - 5m
　Lite(n=2) - 8m, 10m

And also, I found the IO0 port driven by CH552 is 3.9V@ESP32. This level is NG in Absolute Maximum Ratings of ESP32. With another ESP32 device - Wemos D1 R32 - I found same issue and reported it to espressif github issue :
https://github.com/espressif/arduino-esp32/issues/2144#issuecomment-657659077

Just an experiment (NOT solution), I connected IO0 to 3.3V of Lite, then the effective range was expand from 8m(purple) to over 14m(light blue) (n=1).

I wish the improvement by CH552 VCC 5V->3.3V on next board rev of ATOM lite and matrix.